verifica e validazione per garantire l'affidabilit del software

Università degli Studi di PadovaDipartimento di Matematica "Tullio Levi-Civita"

Corso di Laurea in Informatica

Verifica e validazione per garantirel’affidabilità del software

Tesi di laurea triennale

RelatoreProf. Tullio Vardanega

LaureandoFabio Massignan

Anno Accademico 2017-2018

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

SommarioIl presente documento descrive il lavoro svolto durante il periodo di stage curricolaredal laureando Fabio Massignan presso l’azienda Pietro Fiorentini Spa con sede adArcugnano (Vicenza). Lo stage è la parte conclusiva del percorso di studi del Corsodi Laurea Triennale in Informatica dell’Università di Padova.

Lo scopo del progetto erano la gestione e l’implementazione delle infrastruttureper il controllo del software in un contesto Kaizen (miglioramento continuo egraduale). In particolare, è stato richiesto lo sviluppo di strumenti di verifica permisurare ed analizzare la qualità del software prodotto, evidenziando e motivandoeventuali punti di non conformità.

Il presente documento ha lo scopo di illustrare i seguenti aspetti: il contestoaziendale e l’organizzazione interna dell’ambiente di lavoro, le attività svolte duranteil progetto, gli obiettivi e i rapporti fra azienda e studente; intende inoltre fornireuna visione completa sulla progettazione e sul prodotto finale; valutare in modoretrospettivo l’esperienza, prendendo in considerazione le competenze acquisite e ledifferenze tra percorso universitario e lavorativo.

Indice

1 Contesto aziendale 11.1 L’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Organizzazione interna . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2.1 Gestione della qualità . . . . . . . . . . . . . . . . . . . . . . 31.3 Processi aziendali . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3.1 Metodologie di sviluppo software . . . . . . . . . . . . . . . 41.3.2 Strumenti a supporto dei processi . . . . . . . . . . . . . . . 6

1.4 L’azienda e l’innovazione tecnologica . . . . . . . . . . . . . . . . . 9

2 Lo stage 112.1 Aspettative personali . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2 Scopo del progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1 CMMI-DEV 1.3 . . . . . . . . . . . . . . . . . . . . . . . . . 132.3 Obiettivi di progetto . . . . . . . . . . . . . . . . . . . . . . . . . . 142.4 Vincoli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.4.1 Vincoli metodologici . . . . . . . . . . . . . . . . . . . . . . 152.4.2 Vincoli temporali . . . . . . . . . . . . . . . . . . . . . . . . 152.4.3 Vincoli tecnologici . . . . . . . . . . . . . . . . . . . . . . . 17

3 Il progetto 193.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2 Stile di codifica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.1 Principi base . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.2 Automazione di controlli . . . . . . . . . . . . . . . . . . . . 223.2.3 Strumenti utilizzati . . . . . . . . . . . . . . . . . . . . . . . 23

3.3 Analisi statica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.3.1 Principi base . . . . . . . . . . . . . . . . . . . . . . . . . . 253.3.2 Tecniche di analisi . . . . . . . . . . . . . . . . . . . . . . . 263.3.3 Automazione di controlli . . . . . . . . . . . . . . . . . . . . 273.3.4 Strumenti utilizzati . . . . . . . . . . . . . . . . . . . . . . . 28

3.4 Analisi dinamica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.4.1 Principi base . . . . . . . . . . . . . . . . . . . . . . . . . . 283.4.2 Tecniche di test . . . . . . . . . . . . . . . . . . . . . . . . . 303.4.3 Attività di test . . . . . . . . . . . . . . . . . . . . . . . . . 313.4.4 Strumenti utilizzati . . . . . . . . . . . . . . . . . . . . . . . 32

3.5 Metriche di qualità . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.5.1 Principi base . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.5.2 Metriche implementate . . . . . . . . . . . . . . . . . . . . . 343.6 Integrazione delle automazioni . . . . . . . . . . . . . . . . . . . . . 343.7 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4 Valutazione retrospettiva 414.1 Bilancio sugli obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . 414.2 Bilancio formativo . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.3 Analisi gap formativo . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Elenco delle figure

1.1 Logo dell’azienda Pietro Fiorentini . . . . . . . . . . . . . . . . . . 11.2 Misuratore di flusso multifasico . . . . . . . . . . . . . . . . . . . . 21.3 Principi fondamentali lean thinking . . . . . . . . . . . . . . . . . . 31.4 Rappresentazione grafica PDCA . . . . . . . . . . . . . . . . . . . . 41.5 Modello evolutivo ISO 12207:1995 . . . . . . . . . . . . . . . . . . . 51.6 Pagina creazione Issue . . . . . . . . . . . . . . . . . . . . . . . . . 61.7 Pagina dashboard in stile KanbanG . . . . . . . . . . . . . . . . . . . 71.8 Pagina storia build Jenkins . . . . . . . . . . . . . . . . . . . . . . . 81.9 Schema architettura strumenti utilizzati . . . . . . . . . . . . . . . 9

2.1 Livelli e obiettivi CMMI-DEV . . . . . . . . . . . . . . . . . . . . . 142.2 Diagramma di Gantt con dettaglio attività di analisi statica . . . . 16

3.1 Efficacia analisi statica - Tratta da: Capers Jones, Software Produc-tivity Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2 Modello a V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3 Esempio di Test Case . . . . . . . . . . . . . . . . . . . . . . . . . . 323.4 Esempio di Test Suite . . . . . . . . . . . . . . . . . . . . . . . . . 323.5 ISO/IEC 9126 - Divisione della qualità . . . . . . . . . . . . . . . . 333.6 Flusso di esecuzione delle automazioni a seguito di un commit . . . 353.7 Esempio report post-commit . . . . . . . . . . . . . . . . . . . . . . 363.8 Esempio report analisi statica . . . . . . . . . . . . . . . . . . . . . 373.9 Report calcolo metriche . . . . . . . . . . . . . . . . . . . . . . . . 383.10 Componente integrato con Redmine - Ricerca per file . . . . . . . . 383.11 Componente integrato con Redmine - Ricerca per segnalazioni stile

di codifica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1 Soddisfacimento requisiti minimi e massimi . . . . . . . . . . . . . . 42

Capitolo 1

Contesto aziendale

1.1 L’azienda

figura 1.1: Logo dell’azienda Pietro Fiorentini

Pietro Fiorentini è un’azienda leader nella realizzazione di prodotti e servizitecnologicamente avanzati per la distribuzione e l’utilizzo del gas naturale.

Fondata nel 1940, l’azienda inizialmente si occupava della produzione di re-golatori e compressori per il pompaggio del gas naturale. In quegli anni, il gasveniva via via sempre più utilizzato come fonte di energia per i motori d’auto, leabitazioni, e l’industria. Al termine della Seconda Guerra Mondiale, a seguito dellascoperta di un vasto giacimento di gas nella Pianura Padana, l’azienda cresce inparallelo alla fase dello sviluppo energetico italiano, passando dalla produzione dipiccole apparecchiature per il consumo domestico alla realizzazione di sistemi didistribuzione ed importanti impianti per le maggiori industrie del nord Italia. Nelcorso degli anni, Pietro Fiorentini ha aumentato il proprio mercato, passando allaproduzione di valvole a farfalla, filtri, valvole a sfera e altri dispositivi.

Dopo l’esperienza accumulata nel settore gas, a partire dagli anni ’80, l’aziendasi è estesa anche al settore del petrolio realizzando sistemi avanzati detti MPFM("MultiPhase Flow Meter"), per misurare con un solo strumento, e in tempo reale,la qualità del petrolio estratto. La richiesta di questi sistemi da parte dell’industriapetrolifera è data dal fatto che il fluido estratto si presenta come una miscelamultifasica composta principalmente da petrolio, acqua e gas, e la separazione fisicadelle diverse componenti risulterebbe ingombrante e troppo dispendiosa in terminidi tempo e manutenzione. Questi metodi non intrusivi di monitoraggio offrono unamisurazione ininterrotta e possono essere installati in ogni posizione lungo condottadel pozzo di estrazione, anche in ambienti ostici come le profondità oceaniche, nelcaso dei sistemi Subsea MPFM, divisione nata nel 2009, all’interno della quale sicolloca lo stage qui descritto.

1

2 CAPITOLO 1. CONTESTO AZIENDALE

Con l’avvento di queste tipologie di strumenti di misurazione, è aumentatasempre più la necessità di rielaborare i dati processati dai sistemi fisici con strumentiinformatizzati, fornendo in tempo reale e da remoto i risultati raggiunti. Lo sviluppodi applicazioni software efficaci e affidabili, ha costretto l’azienda a ricercare delpersonale qualificato nel campo dell’informatica, in grado di fornire le garanzierichieste. Nel caso dei sistemi Subsea MPFM, è richiesta un’affidabilità hardware esoftware del 90% in 25 anni.

Attualmente, l’azienda ha 12 stabilimenti attivi, che si occupano della progetta-zione, realizzazione e installazione di componenti e servizi per il mercato del gasnaturale e petrolio, in tutti e cinque i continenti con più di 1300 dipendenti. Lavision aziendale è la realizzazione di prodotti e servizi tecnologicamente avanzati,tramite soluzioni di sviluppo sostenibile e azioni di miglioramento continuo, persoddisfare le aspettative e le esigenze di tutti i propri clienti.

figura 1.2: Misuratore di flusso multifasico

1.2 Organizzazione internaLa struttura organizzativa aziendale si suddivide, per ogni tipologia di prodotto, indiverse linee di produzione denominate Divisioni, raggruppate a loro volta in ValueStream. Ogni Value Stream è completamente indipendente dalle altre, in mododa rendere i processi di produzione e progettazione più snelli e il più indipendentipossibili. Vi sono dei processi primari comuni alle varie Divisioni, tra cui l’UfficioCommerciale che si occupa della definizione delle politiche di vendita, analizzandoil mercato in modo da individuare le richieste di nuovi prodotti ed effettuareprevisioni commerciali di medio e breve termine.

Altri processi primari, invece, sono interni alle Divisioni, e indipendenti daglialtri:

∗ Project Management: Prevede le attività di pianificazione, coordinamentoe controllo delle attività di commessa.

∗ Ricerca e Sviluppo: Prevede attività di proposta di nuove soluzioni dalanciare sul mercato in merito a prodotti consolidati oppure la predisposizione

1.2. ORGANIZZAZIONE INTERNA 3

di programmi di sviluppo di nuovi prodotti. Lo stage è stato inserito all’internodi questo processo.

∗ Qualità: Si occupa di sorvegliare le attività di collaudo e di emettere lecertificazioni dei prodotti realizzati. Si occupa inoltre di verificare che ladocumentazione sia corretta e conforme agli standard aziendali.

Parallelamente, appartenente ad un’altra Value Stream, vi è anche il repartoSistemi informativi, che ha responsabilità dei Server e dell’infrastruttura di retedell’intera azienda, comprese le sedi estere.

1.2.1 Gestione della qualitàLa gestione della qualità nella realtà industriale, caratterizzata da un costanteaumento della concorrenza estera, risulta ormai essere un requisito fondamentaleper creare dei prodotti di buona qualità che soddisfino pienamente le richieste delcliente. Molte aziende attuano modelli e metodi per la gestione della qualità basatisolamente sull’esperienza o perché obbligati da fattori esterni, ottenendo quindirisultati incerti e provocando una conseguente sfiducia verso queste metodologiedi controllo. Di conseguenza, questa sfiducia porta le aziende ad organizzarsi inmodi errati, il che significa costi eccessivi e rilascio di prodotti non conformi alleaspettative.

Negli ultimi anni, però, le realtà industriali si stanno approcciando sempre piùad un modo di pensare radicalmente diverso, ovvero il Lean Thinking. Si tratta diuna strategia operativa che racchiude insieme le teorie organizzative con l’approcciopratico.

figura 1.3: Principi fondamentali lean thinking

Tutta l’azienda viene coinvolta in una visione di insieme: dai processi primari diprogettazione fino alla distribuzione e consegna del prodotto finito al cliente. Inquest’ottica, il controllo qualità risulta essere parte integrante di tutta la strategiaoperativa, e alcuni dei 5 principi fondamentali del Toyota Production System, sono


dedicati proprio a indicare la giusta direzione da seguire per ottenere proprio unprodotto di qualità. Il principio che più di tutti si concentra sulla qualità è ilquinto, che si occupa di "Ricercare la Perfezione" e che va interpretato nel senso dimiglioramento continuo Kaizen. Se vengono applicati correttamente tutti i principisi creano delle sinergie che mettono in moto un processo continuo di riduzionedei tempi, degli spazi e dei costi. L’applicazione di questi principi deve esseresistematica e costante per giungere a continui miglioramenti. Una volta finito unciclo, si deve ricominciare per fare emergere nuovi sprechi ed eliminarli.

La linea di pensiero finora illustrata, tuttavia, non può da sola garantire chel’intero processo sia di qualità, per questo Pietro Fiorentini segue anche gli obiettividegli standard di qualità, e nel caso della qualità dei processi è certificata ISO 9001.

figura 1.4: Rappresentazione grafica PDCA

Il pensiero Lean e lo standard ISO 9001 hanno un approccio molto simile alconcetto di miglioramento continuo. L’applicazione sistematica e costante puòessere suddivisa in quattro attività:

∗ Plan: si occupa di individuare e pianificare i processi, identificando anchegli indicatori di prestazione dei processi;

∗ Do: si occupa di agire secondo quanto pianificato;

∗ Check: si occupa di controllare i risultati ottenuti rispetto a quelli attesi;

∗ Act: si occupa di applicare i cambiamenti e le azioni dovute.

Il miglioramento continuo per garantire un’elevata qualità dei prodotti è un idealecondiviso dall’intera azienda, e viene applicato in ogni progetto intrapreso, dal piùpiccolo al più grande; lo stesso stage è stato realizzato in un’ottica di miglioramentocontinuo.

1.3 Processi aziendali

1.3.1 Metodologie di sviluppo softwareLo sviluppo del software, all’interno della divisione MPFM, è stato assegnato aprogrammatori con esperienza nel campo del petrolio con residenza all’estero. Non

1.3. PROCESSI AZIENDALI 5

avendo, dunque, sempre la possibilità di poter comunicare con loro personalmente,principalmente per problemi di fuso orario, è nata la necessita di utilizzare deglistrumenti per la collaborazione e il tracciamento dei compiti e delle funzioni dasvolgere.

Periodicamente sono stati pianificati degli incontri in azienda tra sviluppatori ereparto di Ricerca e Sviluppo per fare il punto sulla situazione, verificare le funzio-nalità ed effettuare le calibrazioni hardware e software che sarebbero difficilmenteattuabili da remoto.

Il software, per i prodotti realizzati dall’azienda, non è un fattore centrale peril business, perciò le tempistiche di rilascio non hanno un peso determinante. Lascelta del modello di ciclo di vita è stata orientata verso un modello che garantissela possibilità di effettuare modifiche o raffinamenti sull’analisi dei requisiti anche incorso d’opera, permettendo la co-esistenza di versioni diverse dello stesso software.Questo modello aiuta a gestire le richieste di piccoli o grandi cambiamenti, prove-nienti molto spesso dai tecnici sul campo, evitando il "code-’n-fix" che porterebbe adun progetto caotico e non gestibile. Il modello adottato segue il modello evolutivo,utile in quanto, prevedendo rilasci multipli e incrementando di volta in volta nuovefunzionalità, permette al reparto di Ricerca e Sviluppo di testare subito il softwaresui misuratori di flusso prodotti. Un altro punto a favore è quello di mantenereuno schema abbastanza rigido per permettere di tracciare quanto è stato fatto equello che ancora rimane da fare. Questo dà agli sviluppatori la possibilità di nonessere sempre presenti nella sede dell’azienda ma di lavorare da remoto. Il modelloevolutivo permette anche di raffinare e rivedere di volta in volta, ad ogni iterazione,i requisiti, rilasciando e mantenendo più versioni del software che sono associate adiverse configurazioni hardware presenti nei misuratori di flusso.

figura 1.5: Modello evolutivo ISO 12207:1995

Questo ciclo di vita non è stato rispettato pienamente per quanto riguarda ladocumentazione, non esistono infatti documenti ufficiali che specificano i requisiti oi dettagli implementativi. Questa mancanza è dettata dal fatto che, al momentoiniziale di sviluppo del software, l’azienda era immatura e non aveva ancora unavisione precisa di quanto il progetto si sarebbe ingrandito. Un processo di ingegne-rizzazione aiuterebbe molto le fasi di sviluppo e progettazione future, e il passaggiodelle mansioni di sviluppo del codice ad altri programmatori. Al momento, soltanto


gli sviluppatori conoscono a pieno le caratteristiche del progetto, ciò ha creato deiproblemi durante l’attuazione dei test dinamici nella fase finale dello stage.

1.3.2 Strumenti a supporto dei processiGestione di progetto

Per la gestione di progetto viene utilizzatoRedmine, uno strumento che permette lacollaborazione di diversi gruppi di persone. L’utilizzo di un sistema di collaborazione,risulta necessario quando le dimensioni del progetto diventano impegnative e gliattori in gioco sono vari. Redmine si occupa tenere in comunicazione e di coordinaretutte le componenti del team di lavoro (gli sviluppatori lavorano da diversi Paesi),attraverso la definizione di tracciatori e l’implementazione di un sistema di ticketing.Questo strumento, attraverso plugin esterni, permette agli utenti di interfacciarsicon il sistema di repository, condividere file e tenere sotto controllo l’avanzamentodel progetto.

figura 1.6: Pagina creazione Issue

Grazie a questo strumento, il Project Manager può assegnare dei nuovi compitiad una o più persone coinvolte nel progetto, che verranno notificate tramite e-mail.Per ogni nuova assegnazione è possibile:

∗ selezionare la tipologia di compito da svolgere, che può essere la segnalazionedi un Bug da risolvere, la necessità di sviluppare una nuova funzionalità,l’aggiunta di un nuovo requisito, richiedere la validazione del prodotto;

∗ inserire il titolo identificativo del compito da svolgere;

∗ inserire la descrizione del compito da svolgere;

1.3. PROCESSI AZIENDALI 7

∗ assegnare la priorità;

∗ associare il destinatario del compito.

Per avere una visione chiara ed immediata del lavoro di tutti i membri del team,viene utilizzato un plugin che implementa una dashboard in stile KanbanG , nellaquale è possibile cambiare lo stato dei compiti, solamente trascinando tra unacolonna e l’altra il riquadro scelto.

figura 1.7: Pagina dashboard in stile KanbanG

Gestione di versione

Per la gestione della versione del codice, viene utilizzato Subversion. È statopreferito questo sistema di versionamento rispetto ad altri sistemi come Git, inquanto permette la gestione delle autorizzazioni d’accesso basate sulle singolecartelle del progetto, e una migliore gestione delle versioni dei file binari generatidurante la compilazione, da caricare sui misuratori di flusso.

Il repository è stato creato su un server aziendale, e ogni sviluppatore e ilpersonale del reparto Ricerca e Sviluppo, hanno un proprio account. La gestionedei privilegi viene gestita a secondo del ruolo aziendale.

In un’ottica di integrazione continua, sono stati collegati Redmine e SVN, in modotale che su Redmine sia possibile visionare e confrontare i vari commit effettuati e,inserendo determinate parole chiave sul testo di un commit, si può far avanzare lostato del compito assegnato su Redmine.

Integrazione continua

Per l’integrazione continua, viene utilizzato Jenkins. Questo strumento si occupadi garantire la qualità del prodotto in tutte le fasi dello sviluppo, attraverso


l’esecuzione di buildG dopo ogni commit. Ad ogni esecuzione, viene verificato seil codice modificato tramite commit su SVN sia valido, e vengono eseguiti i testpianificati, notificandone l’andamento.

I risultati delle esecuzioni dei test vengono notificati attraverso un’appositainterfaccia su Redmine, mentre, i risultati dei controlli sullo stile di codifica, vengonoanche visualizzati direttamente sul client SVN utilizzato dagli sviluppatori, perfornirgli un feedback immediato su quanto è stato fatto.

figura 1.8: Pagina storia build Jenkins

Ambiente di sviluppo

Per la creazione degli applicativi da inserire all’interno dei misuratori di flusso,gli sviluppatori utilizzano IAR System, si tratta di un IDE per lo sviluppo disoftware per sistemi embeddedG . Fornisce strumenti per effettuare il debug del codicee compilatori in C e C++ per lo sviluppo di firmwareG per processori a 8-, 16-,32-bit che sono installati nei misuratori di flusso. Questo strumento è installato suun server aziendale, accessibile da tutti gli sviluppatori sia in locale che da remoto.L’utilizzo di questo IDE è vincolato dal fatto che contiene la licenza necessaria perpoter compilare e caricare, all’interno delle schede elettroniche dei misuratori diflusso, il codice nel modo corretto.

Per la realizzazione degli strumenti per l’esecuzione dei test di analisi statica,dinamica e di controllo di stile sono stati utilizzati principalmente due editor ditesto:

∗ Sublime: editor di testo open sourceG multipiattaforma, che integra stru-menti di autocompletamento del codice, personalizzazione del layout di vi-sualizzazione e consente l’espansione con altri plug-in aggiuntivi forniti dallacomunity.

∗ Notepad++: unico editor di testo disponibile su ambiente Windows Server

Strumenti di coordinamento

Outlook: Client di posta elettronica aziendale che permette la comunicazione tra ivari dipendenti, la gestione di un calendario aziendale globale consultabile da tuttii dipendenti, e la pianificazione di riunioni o corsi.

1.4. L’AZIENDA E L’INNOVAZIONE TECNOLOGICA 9

Strumenti documentazione

Office 365: Suite Microsoft per la produttività. Utilizzabile da applicazioni desktope mobile, permette la creazione, la modifica e la condivisione di documenti.

figura 1.9: Schema architettura strumenti utilizzati

1.4 L’azienda e l’innovazione tecnologicaL’azienda, per essere leader nel settore, ha la necessità di essere sempre all’avan-guardia rispetto al progresso tecnologico, per questo motivo, per ogni Divisione èpresente un reparto che si occupa di Ricerca e Sviluppo che, in base alle richiestedel mercato, cerca soluzioni sempre più innovative da applicare su prodotti esistentio crearne di nuovi.

L’area Ricerca e Sviluppo della Divisione MPFM si occupa di rivedere, edeventualmente riprogettare, le componenti hardware oppure software in caso dimalfunzionamenti. Il reparto è in continua evoluzione dal punto di vista tecnologico:la ricerca di soluzioni innovative per abbattere i costi risulta fondamentale, inquando molto spesso, i misuratori di flusso prodotti vengono installati in zoneostiche e difficili da raggiungere (piattaforme petrolifere, fondali oceanici), doveassicurare la presenza di un tecnico specializzato disponibile in caso di avarie non èsempre possibile.

Per questo motivo, viene impegnato molto tempo alla ricerca di soluzioni chepossano agevolare questo tipo di intervento, come avere la possibilità di visualizzareda remoto non solo i dati rilevati sulla qualità del petrolio, ma anche lo stato dellevarie componenti che compongono il misuratore, suggerendo i possibili malfunziona-menti o rotture che vi possono essere. Per fare ciò è necessaria una ricerca continuaed approfondita delle varie soluzioni hardware e software presenti sul mercato, inmodo tale da utilizzare al meglio le risorse presenti sul campo che molto spessosono limitate.

L’azienda, abituata a produrre per la maggior parte componenti passive, chenon richiedono nessun tipo di elaborazione di dati o sistemi informatici, non ha maiavuto un piano ben preciso su come sviluppare software di qualità.

La voglia di innovarsi e di fornire prodotti sempre più appetibili sul mercato,però, ha portato l’azienda ad evolversi sempre di più, grazie anche agli stagein collaborazione con l’Università di Padova, cominciando con un processo diingegnerizzazione per assicurare del software di qualità ben progettato e testato,per oltrepassare l’artigianalità con il quale veniva prodotto negli anni passati.Inizialmente questo tipo di richiesta è nata per un processo specifico, ma alla luce


dei risultati raggiunti, è stata estesa a tutti gli altri processi che richiedono delsoftware all’interno della Divisione.

La ricerca di nuove soluzioni viene promossa sia dagli organi dirigenziali che datutti i responsabili delle varie Divisioni, in quanto viene vista come un modo peraccrescere il valore di azienda e prodotti, ma anche di dipendenti, che si sentonocosì più stimolati e partecipi dell’intero ciclo di vita del prodotto.

Avendo un alto numero di dipendenti, ed una Divisione dedicata solamente allaricerca e allo sviluppo di nuove soluzioni indipendenti dai processi produttivi, èpossibile sperimentare soluzioni diverse senza avere pressioni dirette da parte delmercato, testando più soluzioni diverse e arrivando a selezionare quella che bilanciaal meglio l’efficacia e l’efficienza.

Capitolo 2

Lo stage

2.1 Aspettative personaliNon avendo un’esperienza lavorativa nell’ambito dell’informatica, e avendo in-trapreso solamente dei progetti didattici nell’ambiente universitario, ho ritenutonecessario scegliere un’azienda per il progetto di stage, che riuscisse a far collimarequanto ho studiato nel corso degli anni accademici con quanto viene effettivamenterealizzato sul posto di lavoro. Per scegliere questa azienda ho deciso di partecipareall’iniziativa "Stage-IT" organizzata dall’Università di Padova. In questa iniziativa,dedicata all’incontro tra il mondo del lavoro e gli studenti universitari, ho avutol’occasione di conoscere e di presentarmi a molte aziende, discutendo con loro levarie proposte. Considerato il grande numero di aziende presenti a questo evento,ho considerato in primo luogo quelle non strettamente legate al mondo dell’informa-tica e dello sviluppo software, quanto piuttosto quelle che utilizzano gli strumentiinformatici come ausilio ai sistemi produttivi. In questo modo è possibile vederesia lo sviluppo che l’applicazione di prodotti software in un ambiente di lavoro,potendo così incrementare le mie conoscenze nel campo dell’ICT, della gestione deiprocessi produttivi e dell’organizzazione aziendale.

Fatte queste considerazioni, ho effettuato dei colloqui conoscitivi con alcune diqueste aziende, tra cui Pietro Fiorentini S.p.A. Durante questi colloqui l’aziendami ha presentato diversi progetti, tra i quali ne ho selezionati due:

• implementazione di un progetto di scouting e di selezione di tecnologie innova-tive in ambito ICT, con lo scopo di applicarle nel miglioramento dei processiaziendali;

• progettazione e sviluppo di un’infrastruttura per l’automazione nella creazionedi test, con esecuzione e controllo automatizzato dei risultati.

Entrambi i progetti mi sono sembrati molto interessanti, in quanto richiedevanoun’iterazione con altre figure aziendali. Sebbene il primo potesse sembrare piùallettante, vista la completa libertà di ricerca di nuove tecnologie e ambiti di sviluppo,a seguito di un colloquio con il responsabile di tale progetto, ho preferito orientarmisu un’altra tipologia in quanto sembrava poco dettagliato e piuttosto fumoso, e letempistiche di sviluppo non coincidevano con quanto richiesto dall’Università. Ilsecondo progetto, invece, mi è sembrato più fattibile e definito, in quanto forniva la

11

12 CAPITOLO 2. LO STAGE

possibilità di applicare tutte le tecniche e i meccanismi di test in un contesto realee pratico.

Durante il colloquio conoscitivo, avvenuto nella sede dell’azienda, ho avutol’opportunità di conoscere meglio l’azienda stessa e di rivedere e ridefinire alcunipassi della proposta di progetto, anche in relazione alle mie preferenze ed idee. Leaspettative dunque erano tante:

• entrare in contatto un una grande realtà industriale;

• conoscere nuove tecnologie;

• poter lavorare in modo autonomo;

• realizzare un progetto concreto ed utilizzabile;

• apprendere i concetti di gestione qualità.

2.2 Scopo del progettoL’azienda utilizza gli stage come mezzo per acquisire nuova forza lavoro da affiancareai processi produttivi, avendo così la possibilità di percorrere nuove strade senzadoversi preoccupare di sacrificarne altre più cruciali.

La necessità da parte di Pietro Fiorentini S.p.A di avviare questo progetto, incontinuazione altri simili negli anni precedenti, nasce dalla mancanza nell’organicodella divisione MultiPhase Flow Meter, di una figura di riferimento con conoscenzespecifiche nell’ambito dell’ingegneria del software. È stata richiesta, in particolare,la figura di un amministratore di sistema che fosse in grado di configurare egestire correttamente gli strumenti di collaborazione e integrazione continua, e checominciasse ad implementare delle tecnologie per garantire che il software prodottofosse conforme ai processi aziendali, agli standard e alle normative esistenti.

Il progetto a cui sono stato associato, ha per la prima volta posto l’aziendadavanti alla sfida di rilasciare un prodotto software consistente. Tra le richiestedei clienti ricadono specifici standard di qualità e affidabilità, tra cui anche lacertificazione CMMI-DEV di livello 2 (Vedi 2.2.1). Da questa particolare richiesta,è nato il desiderio dell’azienda di porre le basi per uno sviluppo controllato eorganizzato di tutto il software prodotto.

Questo progetto di stage è una continuazione di quanto è stato proposto l’annoscorso ad un altro studente dell’Università di Padova, al quale era stato richiesto direalizzare e implementare degli strumenti per la gestione dei processi come baseper la qualità dei prodotti. In quello stage, infatti, sono stati implementati deglistrumenti di integrazione continua e di collaborazione, ponendo anche delle piccolebasi sugli automatismi di analisi statica e dinamica.

A distanza di un anno dallo stage precedente, ho potuto notare che l’aziendacrede molto nei risultati ottenuti dagli studenti, infatti, i prodotti di collaborazionee gestione di progetto realizzati, sono entrati a far parte integrante dei processi disviluppo aziendali.

Dal punto di vista dell’integrazione continua e dell’analisi del codice, sono statesolamente poste delle basi per una ingegnerizzazione futura, lasciando molti margini

2.2. SCOPO DEL PROGETTO 13

di miglioramento. Non sono state applicate infatti molte regole e metodologiedi analisi sul progetto software sviluppato, ma si è preferito studiare e testare,solamente su piccole parti del prodotto, le diverse tecniche per valutare quale fossela migliore.

La principale attività da me intrapresa, prima di realizzare quanto pianificato dalpiano di lavoro, è stata lo studio approfondito di quanto è stato fatto e di quello chesi sarebbe potuto ancora fare, basandomi anche sugli sviluppi proposti al terminedello stage precedente. Ho riorganizzato poi gli strumenti esistenti, che fino a quelmomento erano disorganizzati e salvati su cartelle diverse del server, in modo taleda avere una base solida ed ordinata sulla quale lavorare.

Lo scopo dello stage è stato dunque realizzare e utilizzare strumenti di verificadelle metriche interne di qualità del software (analisi statica, analisi dinamica, etc),revisionando e analizzando in modo automatizzato i risultati, evidenziando le moti-vazioni e i punti di non conformità. Ho voluto, in accordo con il responsabile, dareuna particolare importanza alla documentazione, producendo, per ogni strumentodi analisi realizzato, un documento che ne spiegasse le motivazioni e le modalità diutilizzo, e che facesse riferimento ad alcune best-practice o normative esistenti. Ilprogetto della durata di 300 ore, comprendeva quattro fasi principali:

• Studio dell’esistente e incremento degli strumenti di analisi sullo stile discrittura del codice;

• Studio dell’esistente e realizzazione degli strumenti di analisi statica;

• Realizzazione degli strumenti di analisi dinamica;

• Realizzazione degli strumenti per la misurazione delle metriche di qualità.

I punti chiave richiesti dall’azienda, per ogni fase del progetto, sono stati larealizzazione di una documentazione chiara, necessaria per gestire ed utilizzare glistrumenti, e l’integrazione dei risultati ottenuti con gli strumenti a supporto delprogetto realizzati negli stage precedenti.

2.2.1 CMMI-DEV 1.3CMMI, acronimo che sta per Capability Maturuty Model Integration, è un modelloche fornisce gli strumenti per per la gestione dei processi. L’obiettivo che si pone,infatti, è guidare la Divisione di Lavoro al miglioramento della gestione dei processistessi, indicando i punti-chiave che devono sempre essere tenuti in considerazione eordinandoli secondo livelli di priorità.

Questo modello permette, quindi, di misurare quanto un processo è adeguatoper gli scopi per cui è stato definito. Diviso in 5 livelli, il CMMI descrive detta-gliatamente i processi richiesti per ogni livello e le relative attività, definendoneobiettivi e scopi.

Grazie agli stage precedenti sono stati coperti e soddisfatti tutti i processi finoal livello 2. Con questo stage, invece, si sono voluti stanziare anche i processi divalutazione e validazione appartenenti al livelli 3.


figura 2.1: Livelli e obiettivi CMMI-DEV

2.3 Obiettivi di progettoAlla fine delle 300 ore pianificate dallo stage, l’azienda si aspettava un insieme distrumenti funzionanti, almeno su alcuni file sorgenti di prova, per avere una basesolida per sviluppi successivi nell’ambito della verifica e validazione del software.All’inizio dello stage ho discusso assieme al tutor aziendale gli obiettivi pianificatiinseriti all’interno del piano di lavoro, modificando solamente l’ordine temporale dialcuni punti. Gli obiettivi concordati con il tutor aziendale sono stati suddivisi indue categorie: minimi e massimi.

• Minimi

– Aggiunte sezione "Documentation Plan" e indicizzazione dei documentisu Software Quality Plan;

– creazione documento Code style guide e implementazione di due regoledi analisi dello stile di codifica;

– creazione documento Code static analysis e implementazione di un nuovocontrollo di analisi statica;

– creazione documento Software quality metrics e implementazione conreportistica di una metrica di qualità del software;

– creazione documento Code dynamic analysis e bozza del piano di testdinamico;

– implementazione degli automatismi per un test dinamico;– presentazione di quanto realizzato.

• Massimi

– Completamento sezione "Measurements" su Software Quality Plan;

2.4. VINCOLI 15

– implementazione completa di 10 regole di analisi dello stile di codifica;– mappatura completa dell’esistente e implementazione di almeno 5 nuovi

controlli di analisi statica;– implementazione con reportistica di quattro metriche di qualità del

software;– definizione di una test-suite con branch coverage del 50%;– implementazione degli automatismi di test dinamici con branch coverage

del 50% e completi di reportistica interfacciata con i software di gestionedi progetto;

– presentazione di quanto realizzato con un live-demo interattivo.

2.4 Vincoli

2.4.1 Vincoli metodologiciPer favorire il dialogo tra studente, tutor aziendale e il resto del team del repartodi ricerca e sviluppo, lo stage si è svolto presso la sede dell’azienda, dandomi cosìla possibilità di confrontarmi personalmente in caso di dubbi o necessità con icolleghi della divisione, e con il reparto che gestisce i sistemi informativi, in caso dimalfunzionamenti del server.

Purtroppo non mi è stato possibile confrontarmi con gli sviluppatori software inquanto, essendo personale esterno all’azienda, non sono mai stati in sede durante ilperiodo di stage.

Al termine di ogni attività, ho redatto dei documenti ufficiali, in linea con lepolitiche aziendali, che ricapitolano quanto è stato svolto in modo tale da renderetracciabile nel miglior modo possibile l’andamento del progetto. Periodicamente,ogni settimana, sono stati effettuati degli incontri con i tutor e il responsabile delreparto di Ricerca e Sviluppo, per verificare lo stato di avanzamento, chiarire gliobiettivi ed affinare il piano di lavoro. Al termine del progetto, ho realizzato unapresentazione interattiva con i tutor aziendali per dimostrare che le attività svoltefunzionano e producono i risultati attesi, elencando i pro e contro delle soluzionitrovate, e proponendo eventuali futuri sviluppi.

2.4.2 Vincoli temporaliLo stage pianificato dal tutor aziendale, in accordo con l’Università di Padova, haavuto una durata di 300 ore distribuite nell’arco di otto settimane, dal 02-10-2017 al24-11-2017. L’orario di lavoro concordato con il reparto Risorse Umane dell’aziendaè stato dal Lunedì al Venerdì dalle 7.30 alle 16.30 con un’ora di pausa pranzo. Ilpiano di lavoro è stato suddiviso in cinque fasi principali, distribuite nelle ottosettimane di lavoro.

• Prima settimana (introduzione)

– presa visione dell’infrastruttura esistente;


– analisi dei requisiti;– stesura documento "Software Quality Plan".

• Seconda settimana (analisi di stile)

– lettura e aggiornamento documentazione esistente sullo stile di codifica;– aggiornamento software esistente già implementato per il controllo di

stile;– verifica automatismi dei report per eventuali non conformità.

• Terza e Quarta settimana (analisi statica)

– revisione strumenti e software di analisi statica esistenti;– definizione e ricerca di nuovi controlli da implementare;– implementazione degli strumenti ricercati e realizzazione della relativa

reportistica;– stesura documento "Code static analysis".

• Quinta e Sesta settimana (analisi dinamica)

– definizione e ricerca di nuovi strumenti e di nuove tipologie di test daimplementare;

– pianificazione e valutazione numero di test necessari a garantire l’ade-guata qualità del software;

– implementazione degli strumenti ricercati e realizzazione della relativareportistica;

– esecuzione dei test pianificati.– stesura documento "Code dynamic analysis".

• Settima settimana (metriche di qualità)

– ricerca e valutazione metriche di qualità;– implementazione delle metriche ricercate e realizzazione della relativa

reportistica;– stesura documento "Software quality metrics".

• Ottava settimana (conclusione)

– incontro per presentare e insegnare ad usare quanto prodotto;– live-demo di tutto il lavoro di stage

figura 2.2: Diagramma di Gantt con dettaglio attività di analisi statica

2.4. VINCOLI 17

Rispetto a quanto pianificato inizialmente, il tutor ed io abbiamo ritenuto didover spostare le attività di misurazione delle metriche di qualità dopo la definizionee l’implementazione dei test dinamici, in modo tale da avere una panoramica piùprecisa su quali metriche applicare, in relazione alla tipologia di test sarebbero statiimplementati.

2.4.3 Vincoli tecnologiciL’azienda non ha posto alcun particolare vincolo tecnologico, se non per quantoriguarda l’utilizzo della suite "IAR System" per la compilazione ed esecuzione deicodici sorgente da caricare sui misuratori di flusso, e il vincolo di utilizzare prodottiopen sourceG per quanto riguarda la realizzazione degli strumenti di analisi.

Le scelte tecnologiche da me effettuate sono state vincolate, però, dalle scelteprogettuali degli scorsi stage, per dare una continuità rispetto quanto è statoprodotto in precedenza. In particolare, per la realizzazione degli script automatizzatida far eseguire in modo del tutto indipendente dal server e da Jenkins, ho utilizzatoil linguaggi Bash e Python. La scelta di utilizzare Bash, seppure non sia un veroe proprio linguaggio di programmazione, è dettata principalmente sul fatto che ilserver su cui vengono eseguite tutte le tecniche di analisi si basa su una distribuzioneLinux. I compiti principali che gli strumenti realizzati dovevano svolgere eranoprincipalmente due:

∗ eseguire in modo ripetitivo uno o più applicativi di analisi;

∗ essere eseguiti in modo automatizzato da altri programmi.

Visto l’ambiente di esecuzione e i principali compiti, che ricadono esattamentenelle caratteristiche principali di questo linguaggio, ho ritenuto che fosse quelloideale per raggiungere lo scopo prefissato dallo stage. Python viene utilizzato perautomatizzare i processi in ambiente Windows Server.

Per quanto riguarda la rappresentazione dei risultati dei report di analisi, sonopassato dalla visualizzazione su un semplice file di testo, all’integrazione su Redmine,tramite un apposito modulo creato ad-hoc. Le tecnologie utilizzate per creare questomodulo sono state Html e CSS per la rappresentazione grafica. Per la parte dinamicadi rielaborazione dei dati storicizzati su un database MySql, ho utilizzato invecePHP (tramite apposite API fornite dal sistema) e Javascript. Queste scelte sonostate vincolate dall’architettura di Redmine, per permettere la massima integrazionetra i due sistemi.

Capitolo 3

Il progetto

3.1 Introduzione

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

La necessità di perseguire una buona qualità dei prodotti software, nasce dallarichiesta 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 softwareper i sistemi Subsea. L’azienda non aveva una grande esperienza sul piano dellaprogettazione e dello sviluppo di un software di qualità, ha quindi prodotto unagrossa quantità di codice incontrollato e difficile da manutenere.

Come prima cosa, in continuazione con quanto è stato fatto nello stage prece-dente, mi sono occupato di definire uno standard interno alla Divisione, contenenteserie di regole stilistiche per la stesura del codice. Queste regole servono a limitarel’eccessiva libertà con la quale gli sviluppatori producevano il software. Abituati alavorare 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 unaparte portano ad uno sforzo maggiore richiesto agli sviluppatori, dall’altra garanti-scono un codice più ordinato e leggibile. Un codice ben scritto è un prerequisitofondamentale per le successive attività di analisi.

Una volta assicurata una certa qualità sulla scrittura del codice, ho potutostudiare 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 dimiglioramento continuo (uno dei pilastri fondamentali sul quale è basata l’azienda),ha visto nelle tecniche di analisi statica e dinamica una possibile area di sviluppo emiglioramento grazie al possibile risparmio di tempo e risorse che si può raggiungeretramite un’applicazione corretta delle tecniche di analisi. Mi sono dunque occupatodi studiare quali metodologie fossero le più utili ed interessanti per raggiungere

19

20 CAPITOLO 3. IL PROGETTO

gli obiettivi posti da queste tecniche, ho poi realizzato una struttura di base ingrado 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 generatouna base dati iniziale con i risultati delle varie applicazioni di questi metodi, hopotuto rendere quantificabili i risultati ottenuti. Ho perciò scelto ed applicato dellemetriche di misurazione di qualità del prodotto software. Grazie a queste metricheè possibile capire immediatamente quanto il prodotto stia migliorando rispettoalle versioni precedenti nelle quali non era stato previsto alcun tipo di controllo.Con queste misurazioni è possibile anche dimostrare al cliente finale che il softwareprodotto è sempre controllato, fornendo un risultato tangibile di qualità.

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

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

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

3.2 Stile di codificaUno 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 diun prodotto software, la maggior parte del tempo viene dedicata alla manutenzione.Solitamente questa attività viene affidata a una persona diversa dallo sviluppatoreche ha scritto quel particolare pezzo di codice, e avere uno stile di scrittura uniformee 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 divisionare ed eventualmente modificare il codice prodotto, evita molti errori banaliaumentando 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 modoe che quindi sia standardizzato permette di facilitare e velocizzare la stesura el’automazione delle procedure di test.

3.2. STILE DI CODIFICA 21

L’utilizzo di uno standard di scrittura è stato richiesto, da parte dell’azienda,anche per garantire un’adeguata documentazione del software prodotto. Questarichiesta nasce perché, all’inizio della realizzazione del progetto software, era statalasciata la massima libertà di lavoro agli sviluppatori, che hanno prodotto unagrande quantità di codice senza nessuna documentazione. Così facendo, alla primaoccasione in cui è stata richiesta una manutenzione, il reparto di Ricerca e Svilupposi è trovato davanti a notevoli difficoltà, e si è accorto che la qualità del softwareprodotto era particolarmente bassa; ha quindi deciso di porre delle regole benprecise per non ripetere gli errori passati.

Per garantire un alto livello qualitativo dei processi e per specificare in dettagliole scelte di progettazione effettuate, ho prodotto un documento denominato Codestyle guide. Questo documento è pensato per raccogliere tutte le regole di stilepreviste ed implementate specificandone le motivazioni e i dettagli implementativi.Una prima bozza di documento era già stata scritta nello stage precedente. Misono occupato principalmente di estendere e modificare alcune delle regole di stilepianificate.

3.2.1 Principi basePer garantire un buon prodotto software è necessario pianificare correttamente cosasi andrà a sviluppare. Per facilitare questa fase è opportuno che gli sviluppatoriprendano in considerazione questi principi prima di cominciare a produrre il codice.

L’utilizzo di questi principi, accompagnato da uno stile di codifica ben definito,garantisce una buona qualità del software prodotto e facilità le successive fasi dianalisi.

KISS Keep It Simple Stupid vuole suggerire al programmatore di svilupparei vari metodi mantenendo un livello di complessità minimo. Ogni attività daprodurre deve essere la più semplice possibile massimizzando la coesione trale componenti e abbassando l’accoppiamento.

SOLID SOLID è un acronimo che fornisce cinque principi fondamentali peruna buona progettazione. Questi garantiscono un codice flessibile, robusto,mantenibile e riutilizzabile.

• Single Responsability Principle: ogni classe dovrebbe avere una eduna sola responsabilità;

• Open-Close Principle: un’entità software dovrebbe essere aperta alleestensioni ma chiusa alle modifiche;

• Liskov’s Substitution Principle: gli oggetti dovrebbero poter esseresostituiti con dei loro sottotipi, senza alterare il comportamento delprogramma che li utilizza;

• Interface Segregation Principle: sono preferibili più interfaccespecifiche, che una singola generica;

• Dependency Inversion Principle: una classe dovrebbe dipenderedalle astrazioni, non da classi concrete.


DRY Don’t Repeat Yourself vuole suggerire al programmatore di evitare discrivere più volte le stesse linee di codice. È meglio infatti massimizzare ilriutilizzo rispetto ad utilizzare una ripetizione del codice.

3.2.2 Automazione di controlliIl linguaggio principale con cui viene sviluppato il software per i misuratori di flussoè il C++. Sono state dunque definite diverse categorie di controlli sull’analisi dellostile di codifica.

• Definizione dei nomi: è importante assegnare un nome corretto e significa-tivo a metodi, classi e attributi, in modo tale da facilitare la comprensionedel loro funzionamento e del loro scopo. Riporto di seguito le più significativetra le regole implementate:

• Nome delle funzioni: il nome , come detto, deve essere significativorispetto allo scopo della funzione e non deve contenere lettere maiuscole.I nomi delle componenti, poi, devono essere separati da un "underscore";

• #define e macro: l’utilizzo delle keyword #define e macro deve esserelimitato solamente all’interno dei file di intestazione (.h);

• Nomi dei file: i nomi dei file non devono contenere spazi;• Nomi variabili puntatore: il simbolo * del puntatore deve essere posto

vicino al tipo della variabile. Il nome del puntatore deve cominciare con:"p_";

• Nomi degli array: il nome degli array deve cominciare con: "a_".

• Definizione della formattazione: definire una indentazione e un patterndi formattazione comuni, in modo tale da avere uno stile unico per tutto ilcodice sorgente scritto. A titolo esemplificativo, riporto alcune delle regoleimplementate:

• Lunghezza massima riga: ogni riga di codice non deve superare i 120caratteri, per garantire una buona lettura;

• Lunghezza massima file: ogni file non deve contenere più di 1000righe di codice

• Evitare le negazioni nella forma ridotta: utilizzare le negazionidella forma ridotta diminuisce la leggibilità del codice.

• Definizione della documentazione: per garantire una corretta manuteni-bilità, e per permettere ad altre persone di leggere e capire il codice scritto,è necessario commentare adeguatamente il codice scritto. A questo scopo èimportante porre la giusta attenzione a:

• Intestazione file: ogni file deve contenere un commento di intestazioneche ne specifichi lo scopo, l’autore, e il nome. Sarà compito del sistemadi versionamento SVN aggiornare automaticamente i campi dati relativialle modifiche effettuate dopo ogni commit;

3.3. ANALISI STATICA 23

• Intestazione funzioni: per ogni funzione sviluppata devono esseredescritti lo scopo, i parametri che richiede in input e la tipologia dirisultato che ritorna.

3.2.3 Strumenti utilizzatiPer effettuare un’analisi completa e approfondita dello stile di codifica, mi sonoservito di alcuni strumenti open sourceG già presenti sul mercato. Si tratta prin-cipalmente di strumenti che eseguono un analisi testuale del codice confrontandoquanto è stato scritto con errori tipici noti.

L’attività che ho svolto è stata articolata in due momenti: inizialmente horicercato gli strumenti più adatti per segnalare le regole pianificate (vedi 3.2.2),successivamente, dopo averli testati, ho analizzato i dati restituiti. Questi strumentigenerano infatti un’enorme quantità di risultati e segnalano migliaia di errori; moltospesso, però, sono solo falsi positivi. Questa bassa accuratezza è alla base dellasfiducia verso tali strumenti e ho voluto quindi lavorare sui loro output con lo scopodi garantire una certa affidabilità alle segnalazioni che verranno effettuate aglisviluppatori, quando li utilizzeranno in modo sistematico. Tra i principali strumentistudiati vi sono:

• Uncrustify: strumento gratuito che permette di definire delle regole di stile,indentare e strutturare i file a proprio piacere. Si occupa principalmente dianalizzare e correggere la formattazione del codice sorgente sviluppato.

• Vera++: è uno strumento per la verifica e l’analisi del codice sorgente scrittoin C++. Si tratta di un parser che analizza le principali keyword tipiche delC++, verificando se il loro utilizzo e la loro posizione rispettano le regoledefinite dal linguaggio. Si occupa principalmente di analizzare l’utilizzo e ladefinizione dei nomi delle varie componenti software realizzate.

Grazie all’integrazione di questi due strumenti, e ad altri parser testuali piùsemplici, ho potuto ricoprire al meglio le regole pianificate di analisi dello stile dicodifica.

Il lavoro che ho fatto di aggregazione fornisce una base solida che può esserefacilmente ampliata aggiungendo ulteriori strumenti esterni di analisi.

Oltre alla realizzazione di strumenti per l’analisi, ho creato uno script eseguibilesia in ambiente Linux che in ambiente Windows in grado di correggere in modoautomatizzato alcuni degli errori segnalati. La responsabilità dell’applicazione diquesto strumento viene lasciata allo sviluppatore il quale può confermare se lemodifiche apportate siano veramente volute e necessarie.

3.3 Analisi staticaNessun linguaggio di programmazione può garantire la verificabilità di ciò che èstato scritto. Visto l’aumento dei software che incorporano funzionalità strategicheo critiche per la sicurezza, ogni falla nel sistema può causare ingenti danni economicie di immagine. È nata così la necessità di avere un codice ben strutturato per


rendere efficaci le attività di verifica, in modo da eliminare qualsiasi situazionecritica che possa creare problemi. Lo scopo dell’analisi statica è proprio quello ditrovare e notificare eventuali errori sulla struttura di un programma. Solitamentequesto tipo di analisi viene utilizzata per verificare la corretta applicazione deglistandard di codifica, per analizzare la complessità con la quale viene scritto ilsoftware oppure per identificare anomalie o difetti.

L’analisi statica aiuta i verificatori a trovare eventuali errori prima che il com-pilatore li trasformi in bug eseguiti a run-time. Alcuni esempi di questi errori,dati molto spesso da inesperienza o distrazione, sono l’utilizzo di una variabilenon inizializzata, oppure l’indicizzazione di un array oltre al limite in cui è statoallocato. Con l’esperienza degli sviluppatori l’incidenza di questi bug diminuisce,ma resta comunque estremamente frustrante e costosa da sistemare.

Questa tecnica si basa sull’analisi del codice in modo statico, senza la suaesecuzione, attraverso un attento esame dell’intero codice sorgente. Grazie a questaanalisi è possibile diagnosticare: violazioni di regole o convenzioni necessarie per lacorretta esecuzione del programma, assicurare una buona manutenibilità, evitareuno stile di programmazione poco sicuro.

figura 3.1: Efficacia analisi statica - Tratta da: Capers Jones, Software ProductivityGroup

"60% of the software faults that were found in released software products couldhave been detected by means of static analysis" - Bloor Research Ltd., UK CASTTools report of 1996

Utilizzare l’analisi statica è un’attività utile sia per il responsabile di progetto cheper gli sviluppatori. Questo tipo di analisi, infatti, aiuta il responsabile a ridurre irischi e i costi derivati da eventuali errori commessi durante lo sviluppo, e riduce icosti e i tempi per la verifica del codice. Lo sviluppatore, invece, è avvantaggiatodurante la fase di debugging in quanto si previene la formazione di bug rendendolivisibili prima che diventino difficili da trovare.

La richiesta da parte dell’azienda di implementare gli strumenti di analisi statica,nasce dalla possibilità di ridurre i costi e il tempo speso per correggere gli errori. Per


rendere davvero efficace questa tecnologia, però, deve essere una parte integrantedel ciclo di vita del software, solo in questo modo si riesce a massimizzare i risultati.

Lo scopo di questa fase di progetto sono state dunque la ricerca e l’implementa-zione degli strumenti utili per l’analisi statica, integrandoli a pieno con i sistemi diintegrazione continua esistenti.

Per garantire un alto livello qualitativo dei processi e per specificare in dettaglio lescelte di progettazione effettuate, ho prodotto un documento denominato Code staticanalysis. Lo scopo di questo documento è descrivere le metodologie utilizzate dianalisi statica del software, definendo le best-practice seguite in modo tale da limitarei problemi durante le fasi di sviluppo e debugging. Mi sono occupato dell’interastesura del documento fornendo anche i dettagli degli strumenti sviluppati

3.3.1 Principi basePer semplificare e rendere più efficienti gli automatismi degli strumenti di analisistatica, abbiamo deciso di sviluppare questi strumenti basandoci sulle seguentiregole, e suggerendo anche agli sviluppatori di applicarle.

The power of Ten: è un documento stilato nel 2006 da Gerard J. Holzmannche elenca 10 regole per scrivere codice in C. Alcune di queste regole sonosimili a quanto già definito durante la fase di analisi dello stile di codificapoichè si basano sugli stessi principi.

1. Utilizzare un controllo di flusso semplice: non utilizzare costruttigoto, setjmp, longjmp ed evitare la ricorsione, sia diretta che indiret-ta. Questa regola rende il codice più chiaro e più semplice, aiutando iverificatori e le persone esterne che potranno in futuro dover modificareil codice scritto.

2. Porre un limite superiore ai cicli: questa regola assicura che nonci sia codice che abbia un comportamento inaspettato o che corrompaaree di memoria esterne al suo scope. I limiti dovranno essere testatistaticamente.

3. Non usare allocazione dinamica della memoria dopo l’inizializ-zazione: questa regola è fondamentalle per ambienti in cui è richiestoun alto grado di sicurezza e affidabilità.

4. Limitare le funzioni a 60 righe di codice: questa regola aiuta lacomprensibilità del codice. Ogni funzione deve essere contenuta in unasingola pagina per garantire una buona visibilità.

5. Nel codice devono essere presenti almeno due asserzioni perfunzione: queste asserzioni devono proteggere da situazioni anomale enon provocare side-effect. Tramite le asserzioni, tipicamente test booleani,si intende testare pre- e post- condizioni delle funzioni, dei parametri,dei valori di ritorno e gli invarianti dei vari cicli.

6. Tutti gli oggetti e le variabili devono essere dichiarati con ilminor scope possibile: questa regola restringe al minimo l’area in cui


un oggetto può essere modificato e corrotto, aumentando la sicurezzadel sistema e semplificando il lavoro di verificatori e debugger.

7. Ogni funzione chiamante deve controllare i valori restituiteledalle funzioni chiamate e ogni funzione chiamata deve control-lare la validità dei parametri passatele dal chiamante: questaregola di programmazione aiuta ad aumentare la sicurezza del sistemaperché verifica i valori passati all’interno del codice del programma.

8. L’uso del pre-processore deve essere limitato all’inclusione difile header e alla definizione di semplici macro: questa regola è po-sta per evitare che il numero di casi da testare aumenti esponenzialmenteall’aumentare della clausole condizionali.

9. L’uso dei puntatori deve essere limitato e non è permesso piùdi un livello di deferenziazione: questa regola è stata posta perchéi puntatori sono spesso usati in modo scorretto e provocano molti erroridi programmazione.

10. Tutto il codice prodotto deve essere compilato, fin dal primogiorno, con tutti i warning attivi. Il codice deve compilaresenza warning: questa regola incentiva la scrittura di codice correttoe suggerisce di utilizzare l’integrazione continua

MISRA C - 2004: è un insieme di linee guida di sviluppo software perlinguaggio di programmazione C sviluppato da MISRA (Motor IndustrySoftware Association). Il suo scopo è di facilitare la sicurezza, la portabilità el’affidabilità del codice nel contesto dei sistemi embeddedG . MISRA C nonè uno standard open sourceG , però ho deciso di utilizzarlo in quanto vienefornito uno strumento di analisi che fa riferimento a queste regole, da partedel compilatore IAR.

3.3.2 Tecniche di analisiA seconda della tipologia di controllo che si vuole implementare e della sua esecuzione,vi sono diverse tipologie di approcci da utilizzare.

Una tipologia di analisi si fa tramite metodo di lettura, cioè analizzando il codicecon tecniche di Inspection o Walkthorugh. Queste tecniche prevedono una letturamirata o a largo spettro di tutto il codice prodotto da parte di un team di personeformato da verificatori e sviluppatori.

Questi metodi, se condotti nel modo corretto, producono dei buoni risultaticon una buona affidabilità, però sono stati scartati in quanto la loro realizzazionerichiederebbe del personale altamente specializzato che al momento manca all’internodell’organico della divisione, e un tempo troppo elevato per analizzare e correggerecompletamente tutto il codice.

Per questo motivo abbiamo deciso di utilizzare dei metodi formali. Questiprevedono l’utilizzo di tecniche che possono essere automatizzate, rendendo piùsemplice il lavoro dei verificatori. Alcune delle tecniche analizzate sono:

• Analisi del flusso di controllo, questa tipologia di analisi assicura che ilcodice sorgente venga eseguito nella giusta sequenza e che tutto il codice


scritto venga eseguito correttamente. Non esisteranno quindi più pezzi dicodice irraggiungibili oppure cicli infiniti che non terminano mai.Alcune delle regole che possono essere implementate riguardano: la verifica chenon ci sia codice irraggiungibile, assicurare la terminazione dei cicli, garantireil corretto utilizzo dei puntatori, evitando i puntatori a null.

• Analisi del flusso dei dati, questa tipologia di analisi identifica se alcuneparti del programma non sono conformi alle regole del linguaggio di program-mazione. Controlla ad esempio se vengono sovra-scritte delle variabili senzaverificarne prima il valore.Alcune delle regole che possono essere implementate riguardano: il controllodei tipi in un’associazione tra variabili, l’utilizzo di variabili non inizializzate.

• Analisi i limite, questa tipologia di analisi viene utilizzata per assicurareche i dati elaborati dal programma rimangano entro i limiti dichiarati dallaprecisione del proprio tipo.Alcune delle regole che possono essere implementate riguardano: il controllodell’indicizzazione negli array, assegnazioni sospette o cast pericolosi.

• Analisi del flusso delle informazioni, questa tipologia di analisi determinaquali dipendenze vi sono tra i parametri in ingesso di una funzione e i risultatiattesi. Sono permesse solamente le dipendenze descritte nelle specifiche.

3.3.3 Automazione di controlliPer facilitare l’inizio delle attività di analisi statica, ho deciso, in accordo con il tutoraziendale, di implementare solamente alcune delle regole inizialmente analizzate,per far capire l’importanza di questo tipo di analisi agli sviluppatori senza peròscoraggiarli, limitando così gli errori riportati nei report. Alcune di queste regolesono:

• Possibile dereferenziazione di un puntatore a NULL: dereferenziare unpuntatore a NULL solitamente comporta la lettura o scrittura di un’area dimemoria non mappata, provocando un segmentation fault o una violazione diaccesso;

• Array oltre al limite: assicura che gli indici utilizzati per l’accesso ai datisiano entro ai limiti della dimensione dell’array;

• MISRA C rule 9.1: assicura che a tutte le variabili sia assegnato un valoreprima del loro utilizzo;

• MISRA C rule 14.1: assicura che non ci sia del codice irraggiungibile;

• MISRA C rule 14.6: assicura che per ogni iterazione vi sia al massimoun solo break per terminare il ciclo. Questa regola garantisce una buonastruttura del programma;


3.3.4 Strumenti utilizzatiLa tipologia di strumenti utilizzati per l’esecuzione dei test di analisi statica èdenominata lint. Si tratta di uno strumento simile ad un compilatore che scansionai file sorgenti C e C++, controllando se sono sintatticamente corretti.

I principali strumenti che ho utilizzato ed integrato per avere un unico sistemadi esecuzione per l’analisi statica del software sono:

• CppCheck: è uno strumento di analisi statica per codice C/C++ che fornisceun’analisi del codice in grado di rilevare dei bug. L’analisi effettuata da questostrumento si concentra soprattutto sulla rilevazione di componenti non bendefinite e sull’utilizzo di costrutti pericolosi utilizzati in fase di codifica.

• IAR MISRA C: il compilatore IAR contiene una licenza per visionare esegnalare eventuali non conformità rispetto ad un set di regole di MISRA C.Queste regole si sono diffuse in tutto il mondo e in vari segmenti del settoreembedded

.

3.4 Analisi dinamicaL’analisi dinamica ha lo scopo di verificare il comportamento del codice durantela sua esecuzione. Il processo di attuazione di questo tipo di analisi può esseresuddiviso in diversi passaggi: preparare i dati da utilizzare come input, eseguire iprogrammi di test, analizzare i risultati prodotti.

Questa tipologia di analisi copre un vasto campo applicativo che non può esserecoperto del tutto in un singolo progetto di stage come quello da me intrapreso.Mi sono dunque focalizzato sull’analisi delle possibili applicazioni provando i varistrumenti esistenti sul mercato e selezionando quelli che, a mio avviso, sono piùvalidi. Una volta selezionati, ho creato un’infrastruttura in grado di analizzaredel codice sorgente, eseguire dei test pianificati e produrre in modo automatizzatoi risultati. Ho applicato questa infrastruttura ad una piccola versione di provadel software prodotto dall’azienda, per dimostrare che ciò che viene solitamentestudiato è realmente applicabile e produce sin da subito dei buoni risultati.

Per garantire un alto livello qualitativo dei processi e per specificare in dettagliole scelte di progettazione effettuate, ho prodotto un documento denominato Codedynamic analysis. Lo scopo di questo documento è definire le tecnologie applicateper l’analisi dinamica del software, in modo tale da evitare errori a run-time e bug.Mi sono occupato dell’intera stesura del documento descrivendo le scelte progettualie dettagliando gli strumenti realizzati per favorire una futura crescita di questotipo di analisi.

3.4.1 Principi basePer comprendere al meglio l’ambito e i limiti dei test e per eseguirli nella manieracorretta, durante la fase di progettazione e selezione delle tecnologie da adottare per

3.4. ANALISI DINAMICA 29

esaminare il software, mi sono basato sul documento Seven principles of doftwaretesting realizzato da Bernard Meyer.

1. Definizione: "Testare un programma significa cercare di farlo fallire". Questoprincipio mantiene il processo di testing focalizzato: il suo unico obiettivoè scoprire gli errori che innescando dei fallimenti. La definizione ci ricordaanche che il testing, a differenza del debugging, non si occupa di correggere iguasti, ma solo di trovarli.

2. Test vs specifiche: "I test non possono sostituire le specifiche." Il pericolodi credere che un insieme di test possa servire come specifica è evidenziatoda diversi disastri software che sono accaduti, questo perché nessuno avevapensato a casi estremi.Anche se le specifiche non garantiscono una copertura massima di tutti i casipossibili, almeno implicano uno sforzo di generalizzazione. In particolare, lespecifiche possono servire a generare test, il contrario però, non è possibile.

3. Test di regressione: "Qualsiasi test che viene fallito, deve essere mantenutoall’interno della test-suite" Questo principio copre tutti i guasti che si verificanodurante lo sviluppo e il test. Suggerisce degli strumenti per trasformareun’esecuzione fallita in un test riproducibile.

4. Applicazione degli oracoli "Gli oracoli dovrebbero essere una parte in-tegrante del codice sviluppato. Determinare il successo o il fallimento deltest dovrebbe essere un processo automatico che consiste nel monitorare lasoddisfazione delle post-condizioni durante l’esecuzione." L’esecuzione di untest è utile solo se è possibile determinare, in maniera automatica (attraversooracoli) e senza ambiguità, il risultato finale.

5. Esecuzione automatica e manuale dei test: "Un processo di test efficacedeve includere sia test prodotti manualmente che automaticamente."I test manuali hanno una buona profondità: riflettono i ragionamenti deglisviluppatori sul dominio del problema e della struttura dei dati.I test automatici hanno una buona capienza: provano molti valori, inclusi gliestremi che gli umani potrebbero perdere.

6. Valutazione empirica delle strategie di test: "Valutare le diverse strate-gie di test attraverso criteri obiettivi ed espliciti per garantire la riproducibilitàdei risultati." I test sono difficili da ricercare e attuare; non tutte le idee in-telligenti si dimostrano utili quando sottoposte a una valutazione obiettiva.Un tipico esempio è il test casuale. Le misure oggettive, come il numero dierrori rilevati, mostrano che i test casuali spesso producono risultati miglioririspetto ad altre idee apparentemente più intelligenti.

7. Criteri di valutazione: "La proprietà più importante di una strategia ditest è il numero di errori scoperti in funzione del tempo." Vogliamo trovaretutti i difetti, non solo uno, l’idea è che il primo errore verrà corretto e ilcriterio applicato ancora. Ma i difetti successivi potrebbero essere di natura


diversa; un processo automatizzato deve innescare quanti più errori possibili,non fermarsi al primo.

3.4.2 Tecniche di testUno dei principali obiettivi del testing è la ricerca del maggior numero possibiledi errori all’interno di un programma. Queste tecniche provano a "rompere" ilprogramma da testare, attraverso un approccio il più sistematico possibile, in gradoquindi, di garantirne la riproducibilità.

La classificazione delle tecniche di analisi ricercate, da applicare al softwarerealizzato dall’azienda, si basa sulle specifiche, sulla struttura del codice e sull’ambitodi utilizzo dell’intero prodotto. Alcune delle tecniche di test adottate sono:

• Test dei valori limite: vengono scelti dei valori vicini ai limiti di dominiodelle variabili utilizzate in input. In questo modo e possibile verificare larobustezza del codice, verificando se il programma è in grado di elaboraredegli input inaspettati o errati.

Ho deciso di implementare questa tecnica di analisi dinamica in quanto,trattandosi di un software che contiene dei contatori che misurano la quantitàdi petrolio estratta, ed elaborando i dati su sistemi embeddedG , si corre ilrischio di raggiungere i limiti massimi previsti dal tipo di dato scelto durantela fase di programmazione. Questo problema comporterebbe il rischio diraggiungere i valori di overflow o underflow dei contatori, generando cosìgrossi problemi sui risultati della misurazione.

• Test random: vengono generati dei test random, passando come valoridi input delle funzioni dei dati random, in modo tale da verificare se ilcomportamento di tale funzione è sempre quello voluto.

Ho deciso di implementare questa tipologia di analisi dinamica per simulare ilmalfunzionamento di uno dei sensori hardware esistenti. In caso di guasto diuno di questi sensori, potrebbero essere passati dei valori random alle funzioni,e voglio garantirne sempre il corretto funzionamento.

• Test dei mutanti: vengono generati dei test per verificare se le funzioni sonostate progettate correttamente. Effettuare test sui mutanti vuol dire, durantel’analisi di una funzione, mutare il codice e confrontare poi il comportamentodella funzione originale e di quella mutata, se è diverso la funzione è stataprogettata bene, altrimenti no.

Si tratta di una tipologia di test che serve a verificare la robustezza del codice.

Per fornire all’azienda una metodologia solida per la pianificazione, la realizza-zione e l’implementazione dei test, ho deciso di adottare il modello a V.

3.4. ANALISI DINAMICA 31

figura 3.2: Modello a V

In questo modello vengono descritti i passi e le sequenze che devono essere seguitedurante l’esecuzione dei test. Le diverse tipologie di test sono state raggruppate indiversi livelli tra cui:

• Test di unità: verificano il funzionamento di ogni singolo elemento softwareseparato degli altri;

• Test di integrazione: verificano la corretta iterazione tra le diverse compo-nenti software;

• Test di sistema: verifica il funzionamento corretto di intere aree del sistema.

3.4.3 Attività di testUna volta definiti i concetti principali che stanno alla base dei test, e le varie tecnicheadottate, è necessario integrare quanto è stato sopra descritto in un processo definitoe controllato. È opportuno dunque definire un processo che supporti le attivitàdi test e fornisca ai verificatori ed agli sviluppatori informazioni riguardanti lapianificazione dei test, la verifica e la valutazione degli output. In questo modo,grazie ad un processo controllato, è possibile garantire che gli obiettivi dei test sonoraggiunti in un modo economicamente conveniente.

Per assicurare un’esecuzione disciplinata e sistematica dei test è stato definitoun Test Plan. Si tratta di un documento ufficiale che definisce le strategie di testche possono essere attuate, l’ambiente di esecuzione dei vari test, e tutti i passi chedevono essere attuati per portare a termine nel modo corretto l’attività di verificatramite tecniche di analisi dinamica. In questo documento vengono anche definitele strutture di due termini chiave nel campo dell’analisi dinamica:

• Test Case: la generazione di Test Case si basa sul livello di test da eseguiree sulle particolari tecniche adottate. I Test Case dovrebbero essere sotto ilcontrollo di configurazione del software e devono includere i risultati previstiper ciascun test.


figura 3.3: Esempio di Test Case

• Test Suite: sono una raccolta di Test Case raggruppati per obiettivi comuni.Una Test Suite spesso contiene istruzioni o obiettivi dettagliati per cui sonostati progettati. Contengono anche informazioni sulla configurazione delsistema da utilizzare durante i test.

figura 3.4: Esempio di Test Suite

3.4.4 Strumenti utilizzatiI principali strumenti che ho utilizzato e integrato per avere un unico sistema perl’esecuzione automatica dei test previsti per l’analisi dinamica sono:

• CMock: permette di creare mock e stub per testare funzioni dipendenti daaltre. Impostando un valore e la rispettiva risposta attesa, si verifica che lafunzione in esame svolga correttamente il proprio compito.

• CUnit: permette di svolgere test di unità, attraverso una serie di asserzionipredefinite fornite da questo strumento. Le asserzioni sono una parte funzio-nante di codice, da inserire durante la stesura dei test, e si occupano di stabilirese la parte di programma testata funziona correttamente, confrontando ilrisultato prodotto con un valore imposto dal verificatore.

• Vagrant: è uno strumento che permette di creare ambienti virtuali tempo-ranei. Questo strumento è necessario in quanto garantisce la ripetibilità deitest. Generando per ogni test un nuovo ambiente, abbiamo infatti la certezzache tutti i test siano svolti nello stesso contesto e nelle medesime condizioni,escludendo quindi eventuali interferenze esterne al programma che possonocausare ulteriori errori.

3.5. METRICHE DI QUALITÀ 33

3.5 Metriche di qualitàL’ultima fase prevista da questo stage richiedeva la ricerca e la valutazione dellemetriche di qualità del software. Attraverso l’attuazione delle metriche di qualità èpossibile definire se il prodotto realizzato è conforme alle aspettative aziendali.

Per garantire un alto livello qualitativo dei processi e per specificare in dettagliole scelte di progettazione effettuate, ho prodotto un documento denominato Softwarequality metrics. Lo scopo di questo documento è fornire un valore numerico peralcuni degli attributi di qualità richiesti definiti nel documento Software quality plan.La misurazione della qualità del software è utile infatti per identificare eventualianomalie delle varie componenti software. Mi sono occupato dell’intera stesura deldocumento, fornendo i dettagli implementativi e, con l’approvazione del responsabiledel Reparto di Ricerca e Sviluppo, ho definito i valori di accettazione delle variemetriche.

3.5.1 Principi baseIl principio fondamentale sul quale mi sono basato per trovare delle metriche diqualità è lo standard ISO/IEC 9126. Questo standard esplora il concetto di qualitàdel prodotto software dividendo la qualità in interna, esterna e d’uso. Questi treaspetti di qualità sono fortemente collegati tra loro e alla qualità dei processi.

figura 3.5: ISO/IEC 9126 - Divisione della qualità

La qualità interna è misurata sui requisiti interni, e considera le componentiinterne del prodotto software.

La qualità esterna, invece, si occupa delle caratteristiche esterne, ovvero dellecaratteristiche software quando questo è eseguito.

La qualità in uso, infine, si occupa di misurare la qualità percepita dall’utenteche si trova di fronte al prodotto finito.

Per la qualità interna ed esterna esistono sei caratteristiche principali che devonoessere garantite dal prodotto software per aderire a questo standard: funzionalità,affidabilità, efficienza, usabilità, manutenibilità e portabilità.


3.5.2 Metriche implementateRiporto di seguito alcune delle possibili misurazioni che possono essere effettuateper garantire un prodotto di qualità. Essendo la prima volta che il Reparto diRicerca e Sviluppo applicava queste metriche, ho deciso di selezionarne solamentealcune. Ho ritenuto opportuno concentrarmi più sui risultati raggiunti che sullaquantità.

• Densità di difetti: è il numero di difetti trovati nel software in un certo periododi esecuzione. Questa metrica permette di definire se il software può essererilasciato o meno. La densità di difetti viene conteggiata in rapporto alle lineedi codice prodotte.

• Copertura del codice: questa metrica viene utilizzata per descrivere il gradodi copertura dei test rispetto al codice eseguito. Un programma con un altogrado di copertura, misurato in percentuale, garantisce una certa sicurezza,in quanto è stato testato quasi tutto il codice scritto.

• Rapporto difetti trovati e corretti: questa metrica misura qual è lo statocorrente dell’esecuzione dei test. Tramite questo rapporto si rappresenta lapercentuale di miglioramento delle attività di test.

• Complessità ciclomatica: questa metrica misura la complessità con la qualeè stato sviluppato il programma. Maggiore è il valore di questa metricamaggiore è la complessità del programma. La complessità ciclomatica indicaanche il numero di test che devono essere effettuati per coprire al 100% ilcodice sviluppato.

• Rapporto linee di codice - linee di commento: questa metrica indica se il codiceè correttamente documentato. Un alto valore di questo rapporto garantisceuna buona manutenibilità.

Una volta identificate le metriche da calcolare, è necessario definire anche deivalori obiettivo di qualità che si desidera raggiungere. In accordo con il responsabiledel Reparto Ricerca e Sviluppo abbiamo definito due range: uno di accettazione,che contiene i valori minimi da raggiungere per considerare il prodotto di qualità,e uno ottimale che contiene i valori richiesti dall’azienda. Di seguito una tabellariassuntiva delle metriche calcolate.

Metrica Range Accettazione Range OttimaleDensità di difetti <15% <5%Copertura del codice <50% <90%Rapporto difetti <70% <90%Complessità ciclomatica 0-15 0-10Rapporto linee di codice, commento >15% >20%

3.6 Integrazione delle automazioniDopo aver analizzato e progettato gli strumenti per l’analisi del codice, ho dovutopianificare attentamente quando e in che modalità eseguire ciò che ho realizzato.

3.6. INTEGRAZIONE DELLE AUTOMAZIONI 35

figura 3.6: Flusso di esecuzione delle automazioni a seguito di un commit

L’applicazione degli strumenti di analisi dello stile di codifica viene effettuatatramite gli hooks di SVN. Con il termine tecnico hooks, si intende una serie di scriptche vengono eseguiti in maniera automatizzata dallo strumento di versionamentoutilizzato. Si dividono in due categorie:

• pre-commit: lo script viene eseguito prima del salvataggio delle modifiche sullarepository. Il salvataggio viene effettuato solamente se il risultato dello scriptha prodotto un esito positivo, altrimenti viene notificato allo sviluppatore unreport con le motivazioni del fallimento.

• post-commit: lo script viene eseguito a seguito del salvataggio sulla repositorydelle modifiche effettuate. Questa tipologia di script non vincola il caricamentodei file, ma notifica soltanto l’esito dell’esecuzione.


Le regole sullo stile di codifica sono state definite ed implementate in un secondomomento rispetto alla prima e principale stesura del codice. Per non scoraggiaregli sviluppatori, rifiutando la maggior parte dei commit contenenti molti erroripregressi ho deciso, in accordo con il responsabile e in linea con quanto pianificato loscorso anno, di mantenere la tecnica di esecuzione degli strumenti tramite l’utilizzodei post-commit hooks. In questo modo gli sviluppatori possono lavorare senzagrossi vincoli, ma con la consapevolezza di dover migliorare lo stile di scrittura.

Sul client SVN utilizzato, a termine del caricamento delle modifiche effettuate,viene visualizzato un report con tutte le tipologie di errori riscontrate durantel’analisi dei file modificati o creati.

figura 3.7: Esempio report post-commit

In coda a questo messaggio di riepilogo degli errori riscontrati viene visualizzatoun link che rimanda ad un report più dettagliato. In questo report vengonovisualizzati tutti i file analizzati con i riferimenti al numero della riga in cui è statotrovato l’errore, in questo modo è possibile, in modo facilitato, trovare e correggeremanualmente la non conformità segnalata.

Parallelamente a questa analisi, vengono eseguiti dal server anche gli strumentirealizzati per l’analisi statica e dinamica.

L’applicazione degli strumenti di analisi statica viene dunque effettuata auto-maticamente, a seguito di ogni commit, tramite il sistema di integrazione continuaJenkins, solamente se la compilazione di tutto il software è stata portata a terminesenza alcun errore.

L’esecuzione delle regole di conformità di MISRA C è stata eseguita in unambiente diverso rispetto a quello dell’esecuzione degli altri strumenti. Questostrumento, fornito internamente all’IDE IAR System, ne richiedeva l’esecuzionesu un sistema operativo Windows, e non Linux, come tutti gli altri strumentiutilizzati. È stato necessario dunque utilizzare due server distinti per garantirel’esecuzione completa di quanto pianificato per l’analisi statica, e uno strumentoche permettesse la comunicazione diretta e immediata tra i due sistemi operativi.Ho quindi utilizzato la tecnologia SSH per lo scambio dei report di analisi dei fileanalizzati.

3.6. INTEGRAZIONE DELLE AUTOMAZIONI 37

figura 3.8: Esempio report analisi statica

L’esecuzione degli strumenti di analisi dinamica viene effettuata come ultimaoperazione automatizzata di Jenkins.

Diversamente da quanto è stato pianificato, l’utilizzo dello strumento Vagrant nonè andato a buon fine in quanto ho avuto delle difficoltà inattese con la virtualizzazioneannidata richiesta dallo strumento, ma non disponibile sul server utilizzato.

Si sono verificati numerosi problemi durante l’esecuzione dei test sull’interoprodotto software realizzato, in quanto il progetto Subsea utilizza compilatore IAR,mentre gli strumenti CMock e CUnit utilizzano il compilatore gcc. Ho preferitodunque effettuare un’analisi approfondita e teorica delle varie tecniche di analisi,applicando quanto studiato su una piccola porzione di progetto modificata e resacompatibile con gcc, per far vedere che comunque la realizzazione dei test è fattibile.

Il calcolo delle metriche, viene invece eseguito quotidianamente ed in modoautomatico da Jenkins.

La misurazione delle metriche di qualità attraverso gli strumenti di analisi èdivisa in due fasi.

Nella prima fase gli strumenti analizzano i report generati durante l’attivitàdi analisi dinamica, in modo tale da garantire un valore numerico sui risultatidell’esecuzione dei test. In questa fase vengono generati i risultati delle metricheassociate ai test, come la densità di difetti o la copertura del codice.

Nella seconda fase poi, vengono calcolate le metriche che non richiedono l’ese-cuzione del software. Alcuni esempi di metriche calcolate in questa fase sono lacomplessità ciclomatica, e il rapporto tra linee di codice e linee di commento.

Queste metriche vengono calcolate dopo la terminazione delle procedure di analisidinamica in modo automatizzato dal sistema di integrazione continua Jenkins.

Il report che viene visualizzato contiene sia dei dei valori medi complessivi cheindicano lo stato qualitativo dell’intero prodotto, sia dei valori specifici per i singolifile analizzati.


figura 3.9: Report calcolo metriche

Una volta creati tutti gli strumenti per coprire le richieste del progetto riguardantianalisi dello stile, analisi statica, analisi dinamica e calcolo delle metriche di qualità,mi sono reso conto che i report generati contenenti i risultati di queste attivitàerano sparsi, difficili da raggiungere ed eccessivamente verbosi.

Dalla figura 3.9 si può vedere che il report che visualizza i risultati di analisistatica è contenuto in un unico file di testo, e vengono visualizzati tutti gli errorisegnalati. In questo caso è veramente difficile e costoso in termini di tempo trovareun particolare tipo di errore segnalato. Ho così deciso, in accordo con il tutoraziendale, di creare un nuovo componente aggiuntivo sul sistema di gestione diprocesso Redmine, fornendo un unico punto di accesso per tutti i report prodotti.

In questo modo, sfruttando le potenzialità di Redmine, ho potuto gestire glierrori segnalati all’interno di una base di dati, nella quale è possibile ricercare efiltrare i risultati a proprio piacimento.

figura 3.10: Componente integrato con Redmine - Ricerca per file

3.7. CONCLUSIONI 39

figura 3.11: Componente integrato con Redmine - Ricerca per segnalazioni stile dicodifica

3.7 ConclusioniLe attività descritte fino a qui sono state portate tutte a termine nei tempi previsti.

Sono stati soddisfatti tutti gli obiettivi minimi previsti e quasi tutti gli obiettivimassimi.

Sono riuscito ad applicare alla totalità dei file prodotti dagli sviluppatori, le tec-niche di analisi dello stile di codifica e di analisi statica. In particolare, ho integratoi risultati forniti dagli strumenti realizzati sia con i sistemi di versionamento, siacon i sistemi di gestione di processi. L’integrazione con i sistemi di versionamentoserviva a dare la possibilità al programmatore di visionare immediatamente le even-tuali non conformità derivati dall’analisi dello stile di codifica, invece l’integrazionecon i sistemi di gestione dei processi, attraverso la realizzazione del componenteaggiuntivo per Redmine, dava una rapida visione degli esiti delle analisi effettuate.

Per quanto riguarda gli obiettivi massimi, associati all’analisi dinamica, invece,non sono riuscito a soddisfarli tutti pienamente. Questo perché, alla luce deiproblemi sopra descritti (Vedi 3.6), derivanti dall’incompatibilità tra gli strumentidi analisi trovati e il compilatore IAR utilizzato dall’azienda, non è stato possibiledefinire una Test Suite con copertura almeno del 50%. Ho comunque realizzatoalcuni test su frammenti di programma, potendo così dimostrare l’efficacia e lapotenza di questo tipo di analisi.

Capitolo 4

Valutazione retrospettiva

4.1 Bilancio sugli obiettivi

Lo stage si prefiggeva di raggiungere, nelle 300 ore previste, una serie di obiettiviche erano stati distinti in obiettivi minimi e obiettivi massimi.

Gli obiettivi minimi si concentravano sull’analisi teorica e sull’implementazionedelle metodologie di verifica e validazione del codice. Successivamente, gli obiettivirichiedevano anche una dimostrazione dell’effettiva efficacia degli strumenti realizzatiattraverso esempi pratici e applicazione di poche regole di analisi.

Gli obiettivi massimi, invece, prevedevano la realizzazione di una solida struttura,integrata con i sistemi aziendali, in grado di analizzare la totalità del codice prodottodall’azienda, fornendo agli sviluppatori e ai componenti del Reparto di Ricerca eSviluppo, degli indicatori qualitativi su ciò che viene prodotto.

Sono riuscito a raggiungere pienamente tutti gli obiettivi minimi, e grazie aduna buona progettazione iniziale, sono riuscito a soddisfare anche buona parte diquelli massimi.

Il mancato soddisfacimento di tutti gli obiettivi massimi, è legato principalmentea problemi imprevisti, e imprevedibili a priori, associati alla compilazione del codiceprodotto dagli sviluppatori aziendali. Non ho potuto, infatti, integrare a pieno glistrumenti realizzati con il software dei sistemi Subsea. In particolare, l’integrazioneè stata bloccata da un problema di compatibilità tra il compilatore IAR utilizzatodall’azienda, e il compilatore gcc utilizzato per effettuare l’analisi del codice, comegià illustrato precedentemente. In un primo momento ho deciso di cercare dellesoluzioni che potessero risolvere questo problema che risultava, a tutti gli effetti,limitante, ma, dopo aver cercato di applicare senza successo le possibili soluzioniattraverso l’utilizzo di strumenti che effettuano il portingG del software tra i duecompilatori, ho deciso, in accordo con il tutor aziendale, di accantonare gli obiettividirettamente ostacolati da questa difficoltà, per poterne portare a termine altri dipiù fattibili. Abbiamo evitato così di perdere ulteriore tempo in un’attività cheavrebbe richiesto una mole importante di lavoro e di risorse.

Prima della fine dello stage, poi, avendo ancora tempo a disposizione, mi sonoconfrontato con il tutor aziendale sulla possibilità di porre un obiettivo aggiuntivo,non previsto inizialmente. Durante le settimane precedenti, infatti, era emersauna difficoltà nella lettura dei report delle analisi effettuate, che avrebbe potuto

41

42 CAPITOLO 4. VALUTAZIONE RETROSPETTIVA

appesantire in maniera notevole il lavoro degli sviluppatori. Valutato il carico dilavoro che risolvere questa difficoltà avrebbe previsto, e alla luce del tempo rimasto,abbiamo quindi deciso di procedere con questo obiettivo aggiuntivo. Concretamentesi trattava di realizzare un componente aggiuntivo, integrato con il sistema digestione di progetto Redmine, in grado di raggruppare in un unico punto tutti i reportgenerati dagli strumenti di analisi. L’implementazione di questo componente hapermesso uniformare tutti i sistemi di analisi precedentemente realizzati, rendendopiù stabile il loro utilizzo.

figura 4.1: Soddisfacimento requisiti minimi e massimi

Durante la presentazione finale, su richiesta del tutor aziendale, ho anche propostoalcuni obiettivi aggiuntivi da applicare nei prossimi progetti. Questi obiettiviservono a garantire un buon grado di miglioramento rispetto alle tecniche di verificae validazione del software.

Una delle aree che potranno sicuramente essere migliorate, dunque, riguardal’applicazione degli strumenti e dei metodi di analisi dinamica. In questo progetto,in questi termini, ho posto infatti solamente delle piccole basi di partenza. In futuro,avendo più tempo a disposizione, sarà possibile analizzare a fondo il problemariscontrato per l’incompatibilità tra i due compilatori, trovando così una soluzionefunzionale che permetta l’esecuzione delle tecniche di analisi dinamica.

Una volta risolto questo, sarà possibile pianificare e realizzare dei test chegarantiscano una buona copertura del codice. Parallelamente, però, vi deve essereanche l’impegno da parte dell’azienda di produrre una documentazione di qualitàsul software da loro prodotto. In questo modo sarà possibile facilitare le proceduredi pianificazione ed esecuzione dei test affidate agli sviluppatori.

4.2 Bilancio formativoIn questo stage ho consolidato le basi poste dai progetti precedenti, e ne ho aggiuntedi nuove, lasciando però ancora molto margine di miglioramento. L’applicazionedegli strumenti di analisi in un progetto già avviato si è dimostrata abbastanzadifficoltosa in quanto mi sono trovato davanti ad un sistema di sviluppo softwarenon ancora ben strutturato. Imporre ed applicare delle regole nuove in un ambientedi lavoro già avviato, poi, ha richiesto molte risorse, in quanto ho dovuto benbilanciare le regole da applicare, suggerite dagli standard, per garantire un prodottodi qualità, con le necessità dell’azienda di non interrompere il flusso di lavorocostringendo gli sviluppatori a sole attività di revisione e modifica del codice. Leregole e le attività di analisi sono state, dunque, pianificate e scelte per garantire

4.3. ANALISI GAP FORMATIVO 43

una buona qualità, e nel frattempo permettere la continuazione del lavoro che eragià avviato.

Lo stage si è rivelato molto interessante e mi ha permesso di mettermi in giocorispetto a diverse tematiche.

Ho innanzitutto imparato a confrontarmi e dialogare con diverse figure all’internodella Divisione di lavoro, e questo ha rafforzato le mie capacità di relazione con altrefigure professionali. Il confronto continuo con persone di altri settori e di esperienzaben più longeva della mia, mi ha anche fatto vedere l’esistenza di ambiti che nonpensavo potessero riguardare l’informatica per come l’avevo conosciuta nelle auleuniversitarie. Penso per esempio ai limiti che la parte hardware e sensoristica dannoall’effettivo sviluppo del codice.

Avendo avuto la massima libertà di pianificazione del lavoro e delle risorsedisponibili poi, ho imparato a gestire nel migliore dei modi i tempi necessari perportare a termine le attività richieste. In questo modo ho appreso delle conoscenzeanche nell’ambito dell’organizzazione del lavoro che penso possano tornarmi moltoutili nel prossimo futuro.

Ho anche potuto approfondire in dettaglio e trovare delle soluzioni reali alletematiche associate all’analisi del software, che solitamente vengono solo accennatedurante le lezioni accademiche. Essermi trovato in un’azienda che crede fermamentein queste tematiche mi ha permesso di crescere molto e di rivalutare quelle attivitàche consideravo inizialmente una "decorazione" del prodotto finale realizzato. Hocominciato, con questo stage a considerarle infatti come attività fondamentali chedevono essere realmente applicate in maniera efficace per garantire un vero softwaredi qualità.

La voglia di miglioramento continuo che l’azienda vive come principio fonda-mentale si è trasposta anche in questo stage, sono stato considerato infatti a tuttigli effetti come un loro dipendente, ho partecipato ai corsi di formazione interninei quali ho appreso nuove conoscenze specifiche nell’ambito della qualità dei loroprodotti e dell’intero ciclo produttivo. In questi corsi ho conosciuto nuovi standarde ne ho approfonditi altri già studiati durante i corsi universitari, incrementandocosì il mio bagaglio conoscitivo.

Dal punto di vista tecnologico, invece, ho appreso delle nuove conoscenze appro-fondite riguardanti i termini di integrazione continua e gestione di processo. Hopotuto imparare in dettaglio il funzionamento dei sistemi Jenkins e Redmine cheall’inizio conoscevo solo marginalmente.

4.3 Analisi gap formativoLo stage mi ha permesso di approfondire e applicare molto di ciò che viene studiatodurante gli anni accademici.

È stato interessante intervenire in un’azienda non specializzata nello svilupposoftware, perché ho potuto così conoscere un modo di lavorare nuovo che è diversoda quello affrontato durante i progetti universitari. L’applicazione dei concettiinformatici nell’ambito industriale mi ha permesso di avere una visione ben più


dettagliata e varia delle possibili proposte di lavoro che potrò valutare una voltaconcluso il corso di studi.

Durante le 300 ore, ho potuto sfruttare al massimo le conoscenze apprese durantegli anni accademici, esprimendo fin da subito e in autonomia giudizi sulle sceltetecnologiche e concettuali pregresse, e prendere delle decisioni ragionate per unosviluppo consapevole del progetto. Oltre a questo, ho potuto integrare autonoma-mente ulteriori concetti riguardanti l’ingegneria del software, quali la scelta dellemigliori tecnologie di analisi, o l’utilizzo delle corrette metriche di misurazione dellaqualità. Questa integrazione personale è stata facilitata dalle tecniche di analisi estudio che sono state apprese durante la mia carriera universitaria.

Ogni corso di indirizzo che ho sostenuto all’università mi ha fornito delle cono-scenze che mi hanno permesso di realizzare e portare a termine tutte le attivitàrichieste da questo stage.

Ritengo, però, che potrebbe essere utile aggiungere all’interno del Corso di Laureain Informatica una tipologia di insegnamento che associ l’utilizzo degli strumentiinformatici ai processi aziendali delle industrie che non sono direttamente legatiai prodotti software. Personalmente credo che una scelta di questo tipo potrebbeaiutare lo studente che si troverà nel vero mondo del lavoro e in ambiti lontani dalsolo sviluppo di codice e darebbe un valore aggiunto al Corso di Laurea alla lucedell’elevata industrializzazione che caratterizza il nord Italia.

Concludendo, mi ritengo molto soddisfatto di quanto ho fatto e di come si èsvolto questo stage in quanto mi ha permesso di apprendere dei concetti moltospecifici dell’ingegneria del software. Non ho avuto alcun problema nell’impararemetodologie di analisi nuove ed ho effettivamente applicato in un ambiente esecutivodei concetti che tipicamente vengono ignorati e considerati di secondo piano, e ciòmi ha dato una positività e una speranza nuove per il mio futuro lavorativo.

Personalmente, poi, credo che anche l’azienda sia soddisfatta dell’andamento diquesto stage visto l’entusiasmo con cui è stata accolta la presentazione finale, e lerichieste e sfide nuove che mi sono state proposte una volta terminati gli studi.

Glossario

BBuild: trasformazione del codice sorgente in software eseguibile (tramite compi-lazione e linking).

EEmbedded: vedi Sistemi embedded

FFirmware: programma, inteso come sequenza di istruzioni, integrato direttamentein un componente elettronico nel senso più vasto del termine (integrati, schedeelettroniche, periferiche). Lo scopo del programma è quello di avviare il componentestesso e consentirgli di interagire con altri componenti tramite l’implementazione diprotocolli di comunicazione o interfacce di programmazione.

KKanban: termine giapponese che letteralmente significa "insegna", indica unelemento del sistema Just in time di reintegrazione delle scorte o dei compiti svoltida un singolo individuo, che mano a mano vengono consumate.

OOpen source: indica che il codice sorgente di un prodotto software è reso acces-sibile da una licenza, essa permette a terzi il diritto di poter studiare, cambiare eridistribuire il software modificato.

PPorting (Portabilità): indica un processo di trasposizione, a volte anche conmodifiche, di un componente software, volto a consentirne l’uso in un ambiente diesecuzione diverso da quello originale.

45


SSistemi embedded: tutti quei sistemi elettronici di elaborazione digitale a micro-processore progettati appositamente per una determinata applicazione ovvero nonriprogrammabili dall’utente per altri scopi, spesso con una piattaforma hardwaread hoc, integrati nel sistema che controllano ed in grado di gestirne tutte o partedelle funzionalità richieste.

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 (SWEBOKV3) 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 Oslohttp://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/

https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)

https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)

http://www.uio.no/studier/emner/matnat/ifi/INF4290/v10/undervisningsmateriale/INF4290-StaticAnalysis.pdf

http://www.uio.no/studier/emner/matnat/ifi/INF4290/v10/undervisningsmateriale/INF4290-StaticAnalysis.pdf

verifica e validazione per garantire l'affidabilit del software

Documents