Tecniche e procedure per l'analisi e lo sviluppo di sistemi software per l'automazione

(1)

UNIVERSITÁ DI PISA

FACOLTÀ DI INGEGNERIA

CORSO DI LAUREA IN INGEGNERIA INFORMATICA

TESI DI LAUREA:

T

ECNICHE

E

P

ROCEDURE PER LO

S

VILUPPO DEL

S

OFTWARE NEI

S

ISTEMI DI

A

UTOMAZIONE

RELATORI:

PROF. CAITI ANDREA...……….………...

PROF. FOGLIA PIERFRANCESCO …...

CANDIDATO:

RENZETTI ERIKA...………...

(2)

(3)

Ringraziamenti

Prima di tutti vorrei ringraziare l’Ing. Andrea Caiti che mi ha sopportato e supportato nel completamento degli studi.

Ringrazio la mia famiglia e tutti coloro che non hanno smesso di credere in me. In particolare i miei amici, che non mi hanno lasciata sola, mi hanno aiutata, sostenuta e mi hanno fatto affrontare con il sorriso tutti i momenti difficili. Grazie veramente di cuore, non ci sono parole per dire quanto gli sono grata, ma spero e sono sicura che loro lo sappiano.

Ringrazio qualcuno che dall’alto mi ha protetta da chi ha tentato in ogni modo di mettermi i bastoni tra le ruote e bloccare il mio cammino.

(4)

INDICE

INDICE DELLE FIGURE... 6

INTRODUZIONE... 7

CAPITOLO 1 PROCESSO SOFTWARE ... 9

1.1. ATTIVITÀ PORTANTI... 9

1.1.2 ANALISI E SPECIFICA DI PROGETTO... 11

1.1.3 SVILUPPO... 13

1.1.4 TESTING... 13

1.1.5 DEPLOYMENT... 14

1.1.6 MANUTENZIONE... 14

1.2 ATTIVITÀ AUSILIARE... 15

1.2.1 PIANIFICAZIONE E CONTROLLO DEL PROCESSO... 16

1.2.2 GESTIONE DELLE CONFIGURAZIONI... 19

1.3 CARATTERISTICHE DEL PROCESSO SOFTWARE... 22

CAPITOLO 2 CICLO DI VITA DEL SOFTWARE ... 23

2.1MODELLO A CASCATA... 23

2.2MODELLO INCREMENTALE... 25

2.3MODELLO ITERATIVO... 27

2.3RATIONAL UNIFIED PROCESS –RUP- ... 28

2.4PROCESSI AGILI... 29

2.4.1EXTREME PROGRAMMING... 30

2.4.2SCRUM... 32

CAPITOLO 3 NORME E QUALITÀ... 34

3.1FAMIGLIA ISO9000 ... 34

3.1.1STRUTTURA DELLA NORMA ISO9001... 35

3.1.2GUIDA ISO9000/3 ... 36 3.2ISO9126... 40 3.3ISO12207 ... 45 3.4S.P.I.C.E.ISO15504... 47 3.5SEI-CMM... 49 3.6MIL-STD-498 ... 50 3.7ALTRE NORME... 52 3.7.1ECSS ... 53 3.7.2METODOLOGIA BOOTSTRAP... 54 3.7.3TRILLIUM... 54 CAPITOLO 4 SPECIFICA ... 55 4.1ATTIVITÀ DI SPECIFICA... 55

4.2TECNICHE E STILI DI SPECIFICA... 56

4.3LINGUAGGI DI SPECIFICA... 56

4.3.1LINGUAGGIO Z... 57

4.3.2RETI DI PETRI... 60

(5)

4.3.4 STRUCTURE A&D... 69 4.3.4.1 Diagrammi E-R ... 70 4.3.4.2 DFD ... 71 4.3.4.3 STRUCTURE CHARTS ... 74 4.3.5IDEF ... 75 4.3.5.1 IDEF0 ... 76 4.3.5.2 IDEF1X... 79 4.3.5.3 IDEF3 ... 80

CAPITOLO 5 UNIFIED MODELING LANGUAGE -UML-... 83

5.1STORIA... 83

5.2APPLICAZIONI... 86

5.3UML2.0 ... 87

5.3.1DIAGRAMMI... 88

5.3.1.1 Diagramma delle classi... 90

5.3.1.2 Diagramma degli oggetti... 96

5.3.1.3 Diagramma dei componenti ... 97

5.3.1.4 Diagramma delle strutture composite... 98

5.3.1.5 Diagramma di deployment ... 99

5.3.1.6 Diagramma dei package ... 101

5.1.3.7 Diagramma dei casi d’uso... 102

5.3.1.8 Diagramma di macchina a stati ... 105

5.3.1.9 Diagramma delle attività... 106

5.3.1.10 Diagramma di sequenza ... 109 5.3.1.11 Diagramma di comunicazione ... 111 5.3.1.12 Diagramma di interazione... 111 5.3.1.13 Diagramma di temporizzazione... 112 CAPITOLO 6 CONCLUSIONI... 114 6.1 SISTEMI DI AUTOMAZIONE... 114 6.1.1APPLICAZIONI... 114 6.2 SVILUPPI FUTURI... 123

(6)

INDICE DELLE FIGURE:

FIGURA 1 MODELLO A CASCATA………..24

FIGURA 2MODELLO INCREMENTALE... 26

FIGURA 3MODELLO ITERATIVO... 27

FIGURA 4EXTREME PROGRAMMING... 30

FIGURA 5SRUTTURA DELLA ISO 9126 ……….40

FIGURA 6 PROCESSO DI VALUTAZIONE DELLA ISO9126 ... 43

FIGURA 7APPROCCIO ALLA QUALITÀ DELLA ISO9126 ... 43

FIGURA 8 ESEMPI DI SCHEMI Z………..59

FIGURA 9 ESEMPIO DI RETE DI PETRI CON MARKING... 61

FIGURA 10 TRANSAZIONE IN SEQUENZA………62

FIGURA 11 TRANSAZIONE IN CONFLITTO………...62

FIGURA 12 TRANSAZIONE IN CONCORRENZA………...63

FIGURA 13ESEMPIO STRUTTURA PER LA FORMULA IN(M)->FUTR(OUT,5) ... 66

FIGURA 14 SCOMPOSIZIONE DELLA DESCRIZIONE DI UN SISTEMA SECONDO LA A&D... 69

FIGURA 15 DIAGRAMMA E-R………...70

FIGURA 16DIAGRAMMA DFD... 72

FIGURA 17PROPOSTA WARD E MELLOR PER LA DESCRIZIONE DEL FLUSSO DI CONTROLLO... 73

FIGURA 18ESEMPIO DI STRUCTURE CHARTS... 74

FIGURA 19BLOCCO IDEF0 ... 76

FIGURA 20 GRAFICO IDEF0... 77

FIGURA 21CONTROLLO A SCOMPOSTO NEI CONTROLLI B E C ... 78

FIGURA 22NOTAZIONE IDEF1X... 80

FIGURA 23ESEMPIO DI PROCESS FLOW DIAGRAM... 81

FIGURA 24ESEMPIO DI OBJECT STATE TRANSITION NETWORK DIAGRAM... 81

FIGURA 25 CLASSE……….90

FIGURA 26ASSOCIAZIONE TRA CLASSI... 92

FIGURA 27EREDITARIETÀ TRA CLASSI... 93

FIGURA 28COMPOSIZIONE... 93

FIGURA 29SOSTITUIZIONE... 94

FIGURA 30INTRFACCIA DI RICHIESTA E FORNITA... 95

FIGURA 31PORTA... 95

FIGURA 32CLASSE ATTIVA... 96

FIGURA 33DIAGRAMMA DEI COMPONENTI... 97

FIGURA 34ESEMPIO DI DIAGRAMMA DEI COMPONENTI... 98

FIGURA 35ESEMPIO DI DIAGRAMMA DELLE STRUTTURE COMPOSITE... 99

FIGURA 36NODO... 100

FIGURA 37ESEMPIO DI DIAGRAMMA DI DEPLOYMENT... 101

FIGURA 38ESEMPIO DI DIAGRAMMA DEI PACKAGE... 102

FIGURA 39CASO D'USO E ATTORI... 104

FIGURA 40COLLEGAMENTO TRA ATTORI E CASI D'USO... 104

FIGURA 41INCLUSIONE... 104

FIGURA 42 ESTENSIONE... 104

FIGURA 43DERIVAZIONE... 104

FIGURA 44ESEMPIO DI DIAGRAMMA DI MACCHINA A STATI... 105

FIGURA 45COMPORTAMENTI CONDIZIONALI... 107

FIGURA 46COMPORTAMENTI PARALLELI... 108

FIGURA 47SCAMBIO DI MESSAGGI E ATTIVAZIONE... 109

FIGURA 48ESEMPIO DI DIAGRAMMA DELLE INTERAZIONI... 112

FIGURA 49DIAGRAMMA DI TEMPORIZZAZIONE DEI MESSAGGI... 113

FIGURA 50FASI DEL MODELLO INCREMENTALE PER UN PROGETTO REAL-TIME... 115

FIGURA 51CONTEXT DIAGRAM... 116

FIGURA 52DIAGRAMMA DEI CASI D’USO... 117

FIGURA 53PIANO DEI RILASCI DEI CASI D’USO... 118

FIGURA 54PACKAGES DIAGRAMM... 119

FIGURA 55DIAGRAMMA DI SEQUENZA PER I CASI D’USO AD ALTO LIVELLO... 120

FIGURA 56DIAGRAMMA DI SEQUENZA PER LE INTERAZIONI DELL’OPERAZIONE 1 NEL PACKAGE 2... 120

FIGURA 57SCHEDULAZIONE DEI PROCESSI NECESSARI PER IMPLEMENTARE IL CASO D’USO UNO... 121

FIGURA 58DIAGRAMMA HARDWARE... 122

(7)

Introduzione

Lo sviluppo del software è una attività ancora molto giovane, poco più di cinquanta anni alle spalle; nonostante ciò ha un impatto sempre più grande in molti settori quali industria, istruzione, pubblica amministrazione, medicina, ecc.

La disciplina che si occupa dello studio di tecniche e procedure dello sviluppo del software è l’ingegneria del software.

L’insieme delle attività che devono essere svolte per sviluppare un sistema software è detto processo software ed il modo in cui vengono organizzate prende il nome di ciclo di vita del software. Quest’ ultimo si è evoluto nel tempo seguendo, da prima un modello sequenziale, poi un modello iterativo, metodi agili e processo unificato, con l’intento di rendere sempre più partecipe il committente nelle attività di sviluppo in modo che lo stesso ne risulti soddisfatto (requisito fondamentale per il successo del progetto).

La crescita delle imprese di produzione del software, nell’ultimo decennio, ha aumentato la concorrenza in questo settore e per essere più competitivi si cerca di puntare alla qualità, che deve essere in qualche modo riconosciuta e certificata. A tale scopo esistono enti, norme e standard a cui i committenti, le imprese, gli sviluppatori possono fare riferimento.

Il panorama informatico mondiale è sempre più pervaso dall'approccio di sviluppo object-oriented (OO, iniziato alla fine degli anni ‘80) e per componenti; inoltre si hanno a disposizione tecnologie sempre più avanzate; ciò comporta uno sviluppo di sistemi sempre più complessi ed in cui partecipano vari esperti.

Anche nel campo dell’automazione si è diffuso l’approccio OO ed è sempre più comune la situazione in cui risorse di calcolo, controllo, attuazione, monitoraggio sono distribuite nella macchina, nell’impianto e nell’industria.

In questa nuova ottica cambiano anche le modalità con le quali i progettisti devono affrontare il problema di far interagire in un solo sistema diverse soluzioni tecnologiche e diversi tipi di competenze.

Affrontare problemi complessi, significa avere a che fare con una disparata varietà di persone che hanno distinti interessi e livelli di coinvolgimento nel progetto, inoltre

(8)

programmatori parlano in termini di linee di codice e puntano alla modularità e la semplicità di implementazione.

Per sistemi complessi il 75-90% di tempo è speso nella comunicazione, la quale non avviene più faccia a faccia, ma a causa della dislocazione geografica e la varietà di persone coinvolte, avviene con le nuove tecnologie delle telecomunicazioni e dell’informatica, creando team virtuali.

Diventano fondamentali per la riuscita del progetto, e quindi per il soddisfacimento del cliente, una buona comunicazione tra i diversi partecipanti allo sviluppo del software e una buona attività di modellazione, di specifica e di documentazione.

Uno strumento che aiuta lo sviluppatore software a soddisfare questi requisiti è l’UML, Unified-Modeling Language.

Scopo della tesi è quello di mostrare come lo strumento UML e le sue estensioni risultino essere un valido supporto per sviluppare software di automazione di qualità consentendo di affrontare i vari problemi e le varie soluzioni documentandole e favorendo la comunicazione tra le persone coinvolte.

(9)

CAPITOLO 1 PROCESSO SOFTWARE

Capitolo 1

Processo Software

Tra la fine degli anni sessanta e la decade successiva i sistemi aumentarono di complessità, nacque un vero e proprio mercato del software ed erano richiesti requisiti di qualità (legati all’uso di sistemi informatici in contesti critici quali sistemi aerospaziali, centrali energetiche, ecc..). Da quel momento la creazione di programmi e sistemi software fu vista come un’attività industriale, quindi, come processo complesso da pianificare, controllare e documentare. L’insieme di passi da svolgere quando si realizza un sistema software per ottenere risultati di qualità in un tempo prefissato, è detto processo software.

Le attività si dividono in:

• Attività portanti sono una serie di compiti da svolgere necessariamente

• Attività ausiliare sono quelle che aumentano la qualità di un software e non riguardano il progetto in se ma l'azienda.

Per la trattazione del capitolo sono stati usati i riferimenti [4], [5], [6], [7], [12].

1.1. Attività Portanti

Le fasi da svolgere necessariamente, attività portanti, per la produzione di un buon software sono:

• Analisi e specifica dei requisiti (studio e definizione del problema da risolvere): ha l’obiettivo di capire il contesto in cui il sistema deve inserirsi, le caratteristiche che deve avere, i costi e gli aspetti logistici della sua realizzazione.

• Analisi e specifica di progetto (definizione della soluzione): si studia e progetta la soluzione informatica del problema identificato nella fase precedentemente.

• Implementazione: ha come scopo la creazione del software vero e proprio in accordo con le specifiche del progetto.

(10)

• Manutenzione (evoluzione del prodotto software): comprende un insieme di attività svolte per far evolvere il prodotto software secondo le esigenze dell'utenza (interventi di modifica per correggere errori e ampliare le funzionalità dopo il rilascio). Può includere alcuni aspetti delle fasi precedenti.

1.1.1 Analisi e Specifica dei Requisiti

Nella fase di analisi si cerca di capire il contesto del problema, i bisogni dei committenti e “cosa” il sistema deve fare. Può essere scomposta in sottoattività quali analisi di fattibilità, analisi dei requisiti, analisi e modellazione del dominio applicativo. Lo scopo della specifica dei requisiti è delimitare il dominio applicativo oggetto dello studio, comprendere i termini del problema ed iniziare ad indicare il ruolo che giocherà il software per la sua soluzione.

È una fase delicata e complessa poiché il progetto viene definito di qualità se si avvicina alle aspettative ed ai requisiti formulati dal cliente, ed un errore nella modellazione del dominio si può riflettere in un errore di specifica e conseguentemente nel software realizzato.

Per capire cosa il sistema deve fare avvengono vari incontri tra committenti ed analisti in cui questi ultimi devono capire quale è il contesto del problema e quali sono i bisogni reali dei committenti. A tale scopo l’analista deve aiutare il committente a chiarire progressivamente tutti gli aspetti del problema, attraverso interviste, analisi degli scenari operativi e proposte di lavoro. Il committente viene stimolato e reso consapevole delle diverse possibilità di soluzione, in modo da ottenere una definizione dei requisiti precisa e dettagliata.

In questa fase sono prodotti dei documenti, di tipo testuale ed informale, che descrivono lo scenario applicativo di riferimento del prodotto software, i requisiti funzionali e architetturali, e indica le linee generali per la progettazione e lo sviluppo.

Tale documento, in generale, sarà composto da:

• Una Introduzione: breve descrizione dello scopo e ambito di validità del sistema, la presentazione dell’intero documento un glossario e una lista degli acronimi ed i riferimenti;

• Una Descrizione generale: obiettivi del prodotto, descrizione dell'ambiente operativo, relazioni con altri sistemi e vincoli generali;

(11)

• Una Descrizione dei requisiti: requisiti funzionali, prestazionali, di interfaccia, operativi (modalità di utilizzo del software), di risorse hardware e software di base, vincoli di progetto e di implementazione, di sicurezza e protezione, di portabilità, di qualità, di affidabilità, di manutenibilità, relativi al personale utente e di installazione;

• Una Validazione: riferimento alle procedure per la verifica e validazione dei requisiti alle procedure per il collaudo.

Il documento di specifica dei requisiti deve essere accettato e confrontato con il cliente. I documenti devono essere prodotti in un formato standard. Le parti descrittive sono corredate da diagrammi. In particolare da:

• Un modello di dominio che descrive il mondo supportato dal sistema. Questo ha lo scopo di schematizzare i concetti usati dagli esperti del dominio per parlare e ragionare sul progetto, e rappresentare il modo in cui questi concetti sono collegati tra loro. Serve anche a definire un vocabolario da utilizzare per parlare del dominio, evitando le ambiguità.

• Schematizzazione delle funzionalità principali del sistema attraverso uno o più diagrammi dei casi d'uso. È necessario descrivere i casi d'uso più importanti. I diagrammi non devono essere dettagliati ma devono dare un'idea delle funzioni cui il nuovo sistema dovrà assolvere

• Schematizzazione di massima dell'architettura del sistema attraverso uno o più diagrammi fisici. Occorre mettere in evidenza aspetti di deployment modellando, nei casi in cui il sistema sia distribuito, i nodi computazionali previsti e le relative connessioni di rete.

1.1.2 Analisi e Specifica di Progetto

Con specifica di progetto si indica la definizione dettagliata della struttura del software da sviluppare. L'attività di specifica di progetto si basa sui risultati della specifica dei requisiti e fornisce un insieme di documenti e direttive che indirizzano, organizzano e determinano la successiva fase di costruzione vera e propria della soluzione (codifica o

(12)

realizzare rende sempre più importante l’adozione di tecniche di progetto organiche e strutturate.

In questa fase si procede alla decomposizione in moduli del sistema complessivo e alla specifica delle interazioni tra essi (interfacce tra i moduli). Il processo di scomposizione in moduli viene fatto in maniera iterativa finché non si raggiunge una descrizione sufficiente ad eliminare ogni ambiguità riguardo alla struttura del codice che dovrà essere realizzato.

Il primo obiettivo della fase di progetto è quello di determinare l'architettura software del sistema da sviluppare, cioè la decomposizione di tale sistema in componenti (cioè i costituenti funzionali dell'architettura software) e connettori (cioè le modalità secondo le quali i componenti interagiscono).

Per costruire una specifica di progetto si possono utilizzare diversi tipi di linguaggi. Per esempio si possono utilizzare alcuni dei linguaggi di specifica come il linguaggio Z o alcune delle notazioni di UML. Esiste anche una classe di linguaggi, molti dei quali ancora di tipo sperimentale, che sono stati appositamente concepiti per descrivere architetture software. Tali linguaggi vengono chiamati Architectural Description Languages (ADLs). Un documento di progetto deve prevedere le seguenti voci:

• Introduzione: scopo e ambito di validità del sistema, presentazione del documento, glossario e lista degli acronimi, documenti applicabili e riferiti;

• Standard, procedure e convenzioni: progetto di architettura, progetto di dettaglio, standard di codifica, convenzioni sui nomi, standard di programmazione;

• Progetto dell'architettura di alto livello: architettura complessiva, moduli componenti (nome, tipo, scopo, funzione, dipendenze, interfacce, modalità di implementazione, dati), interfacce interne;

• Progetto di dettaglio: elementi costitutivi (per ogni classe/oggetto nome tipo, scopo funzione, dipendenze, interfacce, modalità di implementazione, dati);

• Codice sorgente: listati di codice sorgente.

La documentazione prodotta in questa fase riguarda due tipologie di documenti. Da un lato un documento testuale che descrive gli aspetti generali della progettazione di dettaglio. Dall'altro lato un documento che descrive la pianificazione delle attività di sviluppo, test e verifica.

La documentazione prodotta durante la progettazione di dettaglio deve contenere almeno:

(13)

• Dettagli generali con riferimento ai vari diagrammi sulle funzionalità, l'architettura e le tecnologie di massima

• Un capitolo per ogni macro modulo che può a sua volta essere diviso in tanti paragrafi quanti sono i suoi sottomoduli. Per ogni modulo o sottomodulo devono essere presenti paragrafi descrittivi delle funzionalità dell'architettura e delle tecnologie

• Un capitolo del documento deve descrivere il piano di sviluppo contenente i tempi di progettazione di dettaglio ed implementazione di tutti i moduli e sottomoduli definiti. Tale documento deve dare i tempi solari di sviluppo i tempi in giorni/uomo, il budget impiegato e la percentuale di budget sul totale.

1.1.3 Sviluppo

Nella fase di sviluppo viene scritto il codice scegliendo un opportuno linguaggio di programmazione, non ci sono particolari indicazioni delle procedure di qualità, comunque è bene scrivere il codice utilizzando standard di codifica comuni all’interno dello stesso progetto. Il software va scritto corredandolo di appositi header, deve contenere un giusto numero di commenti scritti secondo le regole utili per la produzione automatica di documentazione e va utilizzata una notazione standard per l'assegnazione dei nomi agli elementi di una classe.

1.1.4 Testing

Ogni fase del processo software deve includere un’attività di verifica di ciò che è stato prodotto. Per esempio una volta sviluppato il codice dobbiamo verificare che rispetti i requisiti stabiliti nelle specifiche.

L’attività di test può essere di

• Analisi o Verifica statica, nell’esempio del codice questo viene studiato individuandone caratteristiche e proprietà.

(14)

• Durante l’analisi e la specifica dei requisiti: convalidare le specifiche, pianificare test di sistema, creare test funzionali;

• Durante l’analisi e la specifica del progetto: ispezione del progetto di architettura, pianificare test di unità ed integrazione, analisi automatica del progetto di architettura, ispezione del progetto, generare oracoli, generare casi di test, analisi automatica del progetto;

• Durante lo sviluppo: ispezione di codice, esecuzione dei test di entità, creare scaffording, analisi automatica del codice, analisi di copertura;

• Durante il deployment: esecuzione dei test di integrazione, esecuzione dei test di sistema, esecuzione dei test di accettazione, consegna dei test di regressione;

• Durante la manutenzione: esecuzione test di regressione, revisione dei test di regressione.

I test devono essere sviluppati con codice e documentazione e devono essere salvati per la manutenzione.

1.1.5 Deployment

Solo dopo un’accurata fase di testing il sistema può essere rilasciato all’utenza. Il fornitore dovrà provvedere a installare il software presso i committenti, addestrare il personale che lo dovrà utilizzare, e garantire consulenza e manutenzione.

1.1.6 Manutenzione

L’attività di manutenzione è il processo di modifica del software esistente non può essere sottovalutata considerando che assorbe il 70% del budget investito nel software ed occupa il 75% di risorse umane.

Nell’ambito della manutenzione ci sono quattro tipologie di attività:

• Manutenzione correttiva: per la risoluzione di errori riscontrati nel codice

• Manutenzione adattiva: per adeguarlo a modifiche non sostanziali nell’ambiente di elaborazione o nei dati

• Manutenzione evolutiva: per estenderne le funzionalità a seguito di nuove richieste dell’utente, o per migliorarne l’efficienza o la documentazione

(15)

• Manutenzione preventiva: per revisioni interne strutturali del prodotto finalizzate a migliorarne la manutenibilità.

Il servizio di assistenza dovrebbe essere regolamentato contrattualmente fra cliente e fornitore, specificando le modalità di erogazione:

• Modalità di segnalazione del problema

• Tempi di intervento

• Tempi di risoluzione del problema

• Canali di comunicazione tra cliente e fornitore

• Evidenze richieste per documentare le anomalie

• Modalità di intervento

• Procedure da seguire in caso di controversie Un possibile iter del processo potrebbe essere:

• Segnalazione del problema

• Archiviazione della segnalazione

• Assegnazione del problema ad una risorsa

• Analisi del problema

• Eventuale richiesta di documentazione suppletiva

• Eventuale coinvolgimento di specialisti

•

Risoluzione del problema

1.2 Attività Ausiliare

Le attività ausiliare aumentano la qualità del software. Tali attività sono eseguite dalle aziende che puntano ad avere una certa qualità. Non riguardano il progetto in se ma l'azienda:

• Pianificazione e controllo del processo

(16)

1.2.1 Pianificazione e Controllo del Processo

Questa attività si occupa di descrivere le modalità di pianificazione per la realizzazione di un prodotto software e di definire le responsabilità di compilazione dei piani e le relative modalità di gestione nel tempo.

La pianificazione delle attività che devono essere effettuate durante il ciclo di sviluppo di un prodotto software è una attività di fondamentale importanza per garantire la positiva conclusione del progetto. Infatti solo con una attenta pianificazione delle attività si può rispettare i tempi di rilascio previsti, il rispetto degli obiettivi qualitativi, il rispetto delle stime di costo.

La procedura che definisce i piani, che devono essere redatti per la realizzazione di un prodotto software e che ne delinea i contenuti e le modalità di aggiornamento deve essere applicata per tutte le attività di sviluppo e/o acquisto di software, destinato a clienti esterni alla ditta.

Per gli aspetti generali relativi alla qualità ed ingegneria del software si deve rispettare la norma funzionale di riferimento, cioè la normativa sugli aspetti generali della qualità presa in considerazione.

In tale attività ci sono quattro linee di pianificazione principale:

• Pianificazione delle attività di sviluppo: deve definire le attività di sviluppo che devono essere effettuate durante il Ciclo di Sviluppo del prodotto software; la durata e scheduling previsti per ogni attività e le relazioni di precedenza tra le diverse attività; le risorse (sia in termini di personale idoneo che di risorse hardware/software) previste per la realizzazione di ogni attività; le responsabilità di effettuazione di ogni attività di sviluppo; i documenti progettuali che devono essere prodotti per ogni computer software configuration item facente parte del prodotto software; i metodi e gli strumenti che devono essere utilizzati.

• Pianificazione delle Attività di Collaudo: deve definire a quali livelli di integrazione dovrà essere effettuato il collaudo del prodotto software; le attività che devono essere effettuate durante la progettazione e l’esecuzione delle prove; la durata e scheduling previsti per ogni attività; le risorse (sia in termini di personale idoneo che di risorse hardware/software) previste per la realizzazione di ogni attività; l'ambiente hw/sw utilizzato per la esecuzione delle prove; le responsabilità di effettuazione di ogni attività; i documenti di progettazione ed esecuzione delle

(17)

prove che devono essere prodotti per ogni computer software configuration item facente parte del prodotto software; i metodi e gli strumenti che devono essere utilizzati.

• Pianificazione delle Attività di Riesame: deve definire quali riesami devono essere effettuati durante il Ciclo di Sviluppo del prodotto software; quale criterio generale di valutazione deve essere utilizzato nelle attività di riesame; la durata e lo scheduling previsti per ogni riesame; le risorse (sia in termini di personale che di risorse hardware/software) previste per la realizzazione di ogni riesame; le responsabilità di conduzione di ogni riesame; i Rapporti di Riesame che devono essere prodotti; i metodi e gli strumenti che devono essere utilizzati.

• Pianificazione delle Attività di Controllo Configurazione:deve definire la responsabilità di effettuazione delle attività di controllo configurazione; le risorse (sia in termini di personale idoneo che di risorse hardware/software) previste per l'effettuazione del controllo configurazione; gli elementi del prodotto software che devono essere gestiti dal controllo configurazione (elementi soggetti alla configurazione); i metodi di identificazione da utilizzare; le procedure operative di prima consegna degli elementi soggetti alla configurazione e gestione delle modifiche; i metodi e gli strumenti che devono essere utilizzati.

L'attività di pianificazione è resa visibile e tracciabile al management attraverso documenti di progetto detti Piani Operativi. Questi, che devono essere prodotti come risultato di tali attività di pianificazione, sono il Piano Operativo di Controllo Progetto Software (POCP) ed il Piano Operativo delle Prove Software (PLA). Il Piano Operativo di Controllo Progetto Software definisce quali attività devono essere compiute durante il Ciclo di Sviluppo di un prodotto software. Questo documento deve essere redatto in forma preliminare all'inizio del Ciclo di Sviluppo. Deve essere emesso al termine della fase di progetto. Al fine di mantenere tale Piano costantemente aggiornato ed adeguato all'evoluzione della realtà operativa che si manifesta durante il ciclo di sviluppo del prodotto software, deve essere inoltre sottoposto a periodici aggiornamenti. Tale attività di aggiornamento viene realizzata tramite l'effettuazione di riunioni di controllo avanzamento.

(18)

configuration item presenti nel prodotto. Questa soluzione è utile nel caso di progetti di dimensioni molto rilevanti oppure nel caso di sottoprogetti sviluppati da enti distinti. In ogni caso il POPC contiene:

• La descrizione generale del prodotto e l’individuazione dei computer software configuration item interni al prodotto.

• L’identificazione e la gestione di elementi di rischio connessi al progetto.

• Le attività di sviluppo, collaudo e integrazione, controllo configurazione e riesame da effettuare per ogni singolo computer software configuration item

• I tempi previsti per l’esecuzione di ogni singola attività

• Le risorse assegnate per lo svolgimento di ogni attività e le responsabilità della corretta esecuzione.

• qualsiasi requisito contrattuale allocabile al piano.

Nella stesura del POPC è consigliabile adottare metodi di pianificazione avvalendosi possibilmente del supporto di strumenti automatici in grado di mostrare con immediatezza la sequenza temporale delle varie attività e le reciproche interdipendenze. Al fine di controllare il reale stato di avanzamento del progetto rispetto alla sua pianificazione si procederà durante tutto lo svolgimento del ciclo di sviluppo alla effettuazione di periodiche riunioni di Controllo Avanzamento Progetto. Tali riunioni verranno effettuate almeno al termine di ogni riesame e dovranno essere condotte dal Responsabile di Progetto. Durante le riunioni si provvederà a valutare lo stato di avanzamento della realizzazione del prodotto software rispetto a quanto stabilito nel POPC: qualora si rilevi la presenza di ritardi non facilmente recuperabili e/o ritardi lungo il cammino critico (Critical Path) o vi è la necessità di effettuare attività suppletive non inizialmente previste, si provvederà ad apportare le necessarie modifiche al POPC. In tal modo il piano evolve durante tutto il ciclo di sviluppo del software così da essere sempre aderente al reale stato di avanzamento del progetto. Il POPC è il documento che definisce gli obiettivi che devono essere raggiunti nel collaudo del prodotto software ed i criteri che dovranno essere utilizzati per il raggiungimento di tali obiettivi.

Tale piano non definisce le singole prove cui saranno sottoposti i computer software configuration item durante la fase di collaudo, ma i criteri che dovranno essere successivamente utilizzati nelle attività di prova. In tal modo il Piano Operativo delle Prove Software assume il ruolo di documento guida per l'effettuazione della attività dell'Incaricato del collaudo software. Deve essere emesso successivamente alla fase di

(19)

analisi dei requisiti. Definisce la strategia da adottare per le attività di prova del prodotto software:

• la descrizione generale del prodotto e l'individuazione dei computer software configuration item interni al prodotto cui il Piano deve essere applicato;

• l'identificazione e la gestione di elementi di rischio connessi al progetto;

• le attività di Sviluppo, Collaudo e Integrazione, Controllo Configurazione e Riesame da effettuare per ogni singolo computer software configuration item;

• i tempi previsti per l'esecuzione di ogni singola attività;

• le risorse assegnate per lo svolgimento di ogni attività e le responsabilità della corretta esecuzione di tali attività;

• qualsiasi requisito contrattuale allocabile al piano.

L'efficacia dell'attività di collaudo è determinante ai fini della correttezza e dell'affidabilità dei computer software configuration item prodotti. Al fine di garantire la massima efficacia possibile all'attività di collaudo, il PLA deve essere riesaminato nel riesame formale di progetto preliminare.

1.2.2 Gestione delle Configurazioni

Lo scopo principale della gestione della configurazione è quello di mantenere la tracciabilità del progetto e quindi la riproducibilità in tempi brevi ed in qualsiasi suo stato controllato durante tutto il suo ciclo di vita.

La gestione delle configurazioni (Configuration Management) attraversa l'intera vita di un prodotto, ha lo scopo di identificare ed organizzare il prodotto software, controllare e gestire tutte le entità create nel corso delle diverse fasi dello sviluppo del prodotto stesso.

Un prodotto software è costituito da un insieme strutturato di elementi progettuali tali da rendere visibile, ripetibile, gestibile e misurabile il prodotto ed il suo ciclo di sviluppo. Un elemento oggetto delle attività del configuration management viene chiamato configuration item. Per gestire adeguatamente tutti i configuration items è necessario descriverne tutte le possibili tipologie e le operazioni che su di essi possono essere compiute. Esistono degli standard utili a guidare l'attività di definizione di queste entità. I configuration item e le operazioni ad essi associati possono essere descritti utilizzando i

(20)

Una configurazione è un insieme di configuration items logicamente correlati tra loro per costruire una istanza del prodotto. Quando vengono effettuate il test interno o una ispezione una configurazione viene congelata ed è detta baseline. Ogni cambiamento ad una baseline deve essere autorizzato e gestito attraverso un appropriato processo.

La gestione della configurazione consiste nell’effettuare le seguenti attività:

• Identificazione degli articoli di configurazione;

• Gestione delle baselines di configurazione;

• Gestione della configurazione di sviluppo

• Gestione delle modifiche

• Registrazione dello stato di configurazione.

Tutti gli articoli soggetti a gestione configurazione sono detti Articoli di Configurazione, gli articoli di configurazione si suddividono in articoli hardware ed articoli software. Ogni articolo di configurazione software deve essere identificato da un unico codice (o part number) di 11 caratteri alfanumerici, compreso il numero a due cifre che segue il tratto (-) ed indica la versione dell'articolo; tale codice definisce lo stato di intercambiabilità dello stesso. L'indice (o lista) di configurazione del progetto (da considerarsi documento di configurazione con aggiornamento della revisione) dovrà mantenere aggiornate e congruenti le informazioni di configurazione riportando per ogni articolo di configurazione software:

• il livello dell'articolo,

• il part number,

• la denominazione,

• lo stato di modifica,

• il part number dell'articolo di assieme superiore,

• la baseline raggiunta,

• note eventuali;

Inoltre per ogni documento dell'articolo dovrà riportare:

• la sigla,

• il titolo,

• la Specifica di Progettazione (SBA) di riferimento,

• la revisione,

• la fase di riesame,

(21)

• l'identificatore del rapporto di riesame,

• note eventuali.

Per Articolo Non Sviluppato s'intende l'articolo già disponibile e che quindi non va progettato . Fanno parte di questa categoria:

• Articoli commerciali acquisibili a catalogo;

• Articoli già sviluppati e riusabili;

• Articoli forniti dal cliente.

Il progettista non conosce dettagliatamente la struttura interna di un articolo non sviluppato, questo è semplicemente scelto ed usato. Nella Gestione di Configurazione si dovrà identificare l’articolo non sviluppato sia in modo costruttivo (oggetto funzionale) che descrittivo (manuali e documentazione di supporto), integrandola con la documentazione interna. Gli articoli acquistabili da catalogo dovranno essere posti sotto controllo configurazione prima del loro utilizzo nel prodotto (criteri di accettazione/validazione dovranno essere previsti ed attuati. Per identificarli si userà lo stesso codice di identificazione usato dal fornitore, preceduto dall'identificazione del fornitore. Per ogni articolo dovrà essere compilato un indice di configurazione articolo (da considerarsi documento di configurazione con aggiornamento della revisione) riportante:

• Elementi costruttivi: livello, identificativo del fornitore, codice identificativo usato dal fornitore, denominazione, stato di modifica (eventuale), release/data, note.

• Elementi descrittivi: codice identificativo usato dal fornitore, titolo, edizione/data, note.

Per condurre in modo controllato le attività di sviluppo, dovranno essere identificate anche le risorse hw/sw usate per lo sviluppo, il test e l'integrazione.Le risorse software di supporto per il progetto (risorse peculiari) dovranno essere identificate con lo stesso criterio usato per i prodotti software e dovranno seguire lo stesso iter di gestione configurazione degli articoli software di progetto.Per ogni computer software configuration item in sviluppo deve essere individuato l'insieme degli elementi progettuali. Al fine di permettere l'univoca identificazione di tutti gli elementi progettuali è necessario associare a ciascuno di essi un codice di identificazione che lo distingua da tutti gli altri e ne permetta l'immediato riconoscimento.

(22)

1.3 Caratteristiche del Processo Software

Un processo software deve essere:

• Comprensibile, capire perché si è scelto di seguire un modello di sviluppo piuttosto che un altro

• Visibile, si deve capire a che punto si è giunti nello sviluppo seguendo i dati precedentemente riportati sulle documentazioni di ciascuna fase del ciclo di vita del software

• Supportabile, il processo deve essere supportato dagli strumenti che si decide di utilizzare per lo sviluppo del software

• Accettabile, un processo deve risultare accettabile da coloro che lo realizzano

• Robusto, un processo deve risultare robusto, deve essere flessibile ai cambiamenti che potrebbero influenzare lo sviluppo del software

• Rapido, un processo deve essere rapido nel produrre il software desiderato ma tale caratteristica non deve scontrarsi con la visibilità.

(23)

CAPITOLO 2 CICLO DI VITA DEL SOFTWARE

Capitolo 2

Ciclo di vita

del

software

Il modo con cui vengono organizzate e praticate le fasi del processo dei sistemi software è detto ciclo di vita. Chi lavora allo sviluppo o alla modifica di un software, adotta un certo approccio nel modo di relazionarsi con i propri clienti, nell'organizzare il proprio lavoro, nella scelta delle tecniche da utilizzare.

In modo consapevole o meno, ogni sviluppatore software (o gruppo di sviluppatori) ha un proprio modo di lavorare, basato sulla propria esperienza, sulla propria cultura, e sul contesto culturale ed organizzativo in cui si trova ad operare. Ogni processo di sviluppo ha i propri pregi ed i propri limiti. una scelta inadeguata alle esigenze dello specifico progetto può condurre al fallimento dello stesso, o comunque all'insoddisfazione dei clienti/utenti e degli stessi sviluppatori.

Le tipologie di processo di sviluppo software più diffuse sono: • a cascata

• Incrementale • Iterativo

• RUP (Rational Unified Process) • processi agili

• Scrum

• XP (eXtreme Programming)

Per la trattazione del capitolo sono stati usati i riferimenti [5], [12], [13].

2.1 Modello a Cascata

Il modello a cascata è stato ideato da Walzer Royce nel 1970. Ogni fase produce un output che serve da input alla fase successiva.

(24)

Il processo software è visto come una catena di montaggio tipico della produzione industriale.

Per prima cosa si esegue lo studio di fattibilità in tale fase si decide se deve essere intrapreso un nuovo sviluppo. Gli attori coinvolti sono i committenti e l'organizzazione aziendale. Si produce un documento che presenta diversi scenari e soluzioni con una discussione dei compromessi in termini di costi e benefici. Il documento di studio di fattibilità è l'input per l'analisi dei requisiti, in tale fase si cerca di identificare e descrivere i requisiti del sistema. A tale fase partecipano i committenti, gli sviluppatori e l'organizzazione aziendale. Viene prodotto un documento che descrive le caratteristiche del sistema mettendo in evidenza le esigenze del cliente, che sia esaustivo per il progettista. Tale documento deve essere comprensibile, preciso, completo, coerente , non ambiguo e facilmente modificabile. Produce anche il manuale utente ed il piano di test.

Nella fase di progettazione si prende come input il documento di specifica dei requisiti, si definisce l'architettura del sistema. A tale fase partecipano gli sviluppatori. Gli output sono la definizione di massima (architettura di alto livello) e la definizione delle caratteristiche dei singoli componenti.

(25)

La codifica ed il test di modulo hanno come input i documenti di progetto, si implementano i moduli, che costituiscono anche gli output, a tale attività partecipano gli sviluppatori. La fase di integrazione e test di sistema ha in input i moduli codificati, si controlla che i moduli funzionino singolarmente e messi assieme. A tale fase partecipano gli sviluppatori e viene prodotto il sistema funzionante e le tecniche di verifica e validazione. Nella fase di manutenzione si segue il sistema dalla consegna alla sua dismissione.

Tale modello sono è molto semplice da capire, intuitivo; è semplice organizzare il piano di progetto (non ci sono dubbi sulla sequenza delle fasi). Si adatta a logiche organizzative e politiche del personale basate su una divisione del lavoro accentuata.

Gli svantaggi sono dovuti al fatto che le prime verifiche dei risultati arrivano nella fase finale di test e quindi verso la fine del progetto, se c'è qualcosa che non funziona o non sono soddisfatti alcuni requisiti , i tempi ed i costi del progetto salgono notevolmente. Tale modello si basa su assunzioni sbagliate, infatti, non è possibile chiarire tutti i requisiti del sistema nella fase iniziale, una volta ottenuto l'accordo sui requisiti, non è detto che questi non cambino più e che sia possibile definire i requisiti e stimare tempi e costi del progetto senza possedere la competenza necessaria sugli aspetti tecnici ed implementativi. Il modello di sviluppo a cascata è considerato obsoleto anche se serve come base di descrizione per gli altri modelli.

2.2 Modello Incrementale

Una delle prime rappresentazioni del modello incrementale è dovuta a Barry Boehm, nel 1981

(26)

Figura 2 Modello incrementale

Tale modello deriva da quello a cascata.

Completata la fase di analisi, viene svolta l'attività di design dell'architettura. Si effettuano le scelte di alto livello relative alla strutturazione del problema, si definisce le responsabilità di ciascun sottosistema e le modalità di dialogo tra i diversi sottosistemi.

Vengono definite delle priorità sulla base delle quali il progetto viene articolato in una serie di sottoprogetti realizzativi, ciascuno dei quali produrrà uno o più sottosistemi. I sottoprogetti potranno essere condotti in sequenza rigida o essere condotti in parallelo. Le priorità di realizzazione possono essere di natura funzionale, sono relative alle esigenze dei committenti, o di natura architetturale.

Il modello di sviluppo incrementale viene utilizzato in progetti di complessità medio-grande.

Rispetto al modello a cascata ha il vantaggio di arrivare a consegnare qualcosa di concreto prima di aver completato l'intero sistema, si hanno feedback concreti. Si ha una maggiore flessibilità nell'assegnazione delle persone ai compiti progettuali, quando i sottoprogetti vengono pianificati con una parziale sovrapposizione temporale.

In tale modello di sviluppo, si suppone, erroneamente che sia possibile definire tutti i requisiti all'inizio del progetto, senza entrare con i committenti nel merito delle soluzioni concrete, e che i requisiti non cambino dopo che sono stati concordati.

(27)

2.3 Modello Iterativo

Una delle sue prime rappresentazioni è dovuta a Barry Boehm nel 1988.

In ogni ciclo della spirale si eseguono le attività tipiche del processo software, analisi dei requisiti, analisi di progetto, etc...

Si segue una gestione sistematica dei rischi di progetto, per arrivare alla loro progressiva diminuzione: all'inizio del progetto di sviluppo software i rischi sono elevati perché manca la chiarezza sui requisiti, le scelte sulle tecnologie e sulla strutturazione del sistema.

Figura 3 Modello iterativo

Ogni iterazione ha lo scopo di ridurre i rischi del progetto: inizialmente si costruiscono prototipi di iterazione, per affrontare i rischi legati all'incertezza dei requisiti, e prototipi architetturali, per affrontare i rischi legati alla scelte delle tecnologie ed i dubbi sulla strutturazione del problema. Successivamente, quando i rischi principali sono sotto controllo, ogni iterazione ha lo scopo di costruire nuovi porzioni di sistema da integrare

(28)

I vantaggi sono dovuti al fatto che i rischi vengono gestiti attraverso le iterazioni con lo scopo di ridurli, si ha quindi una maggiore qualità dei prodotti e una maggiore produttività dei progetti.

Gli svantaggi sono dovuti al fatto che la pianificazione dei progetti è più complessa, all'inizio è impossibile prevedere il numero, la durata delle iterazioni. Un punto cruciale in questo modello è la collaborazione tra committenti e gruppo di progetto. Il gruppo di progetto deve fornire gli stati di avanzamento del prodotto, dall'altro i committenti devono fornire periodicamente i riscontri concreti ai prototipi ed alle porzioni di sistema realizzate dal gruppo di progetto. Se ciò non avviene non sarà possibile ridurre i rischi.

2.3 Rational Unified Process –RUP-

Il RUP è, tra i processi iterativi, uno dei più diffusi, basato sull’organizzazione di Ivar Jacobson Objectory che si è poi fusa con Rational è stato pubblicato come Unified Process nel dicembre del 1998. La sua diffusione è dovuta al fatto che tra i suoi autori è presente uno degli autori di UML (Booch, Rumbaugh, Jacobson), per la forza commerciale di Rational, perché più che un processo vero e proprio, fornisce un framework di processo, cioè un quadro di riferimento generale da cui si può partire per creare processi specifici adattati alla realtà di una specifica organizzazione di sviluppo software. Come conseguenza, RUP può essere utilizzato in qualunque settore, a prescindere dalla tipologia di sistemi software, dalle tecnologie adottate, dall'impostazione culturale ed organizzativa. In pratica è un’infrastruttura per la definizione di processi. La prima cosa da fare quando si usa RUP è scegliere un caso di sviluppo, che rappresenta il particolare processo adottato per il progetto. A prescindere dal particolare caso di sviluppo RUP è un processo iterativo. Nel processo unificato le fasi per portare un prodotto o sistema dall’ideazione all’implementazione sono quattro:

• Inizio o Avviamento: si identifica il sistema che si vuole sviluppare (si esegue l’analisi iniziale, si discute con l’esperto del campo su come dovrà essere il sistema, si identificano i requisiti per poi modellarli nei diagrammi dei casi d’uso).

• Elaborazione: si esegue una progettazione dettagliata e si identificano le basi del sistema (si deve ottenere un’immagine unifica di come dovrebbe essere realizzato il sistema. Si suddivide iterativamente il sistema in sottosistemi, ciascuno dei quali

(29)

può essere modellato separatamente. Vengono elaborati e trasformati i casi d’uso scoperti nella fase di inizio in un progetto globale del sistema, comprendente i sottosistemi e gli oggetti funzionali a esso correlati. Procedendo iterativamente con la trasformazione di questo modello in un progetto software, utilizzando diagrammi più dettagliati che, alla fine, serviranno a modellare le classi e i relativi membri).

• Costruzione: si scrive il software(Il codice viene sviluppato in porzioni facilmente gestibili e portate avanti con dei piccoli cicli simili all’intero Processo Unificato. Ci possono essere modifiche al progetto e nuove fasi di analisi, si deve essere flessibili, ma anche attenersi al risultato delle fasi precedenti, in modo che il progetto finale non si discosti troppo da quello originale. Spesso si dovrà tornare in dietro per progettare nuovi componenti a cui non si era pensato).

• Transizione:si fornisce il sistema agli utenti (Si installa il prodotto presso i clienti, è seguita da una fase di manutenzione e aggiornamento fino alla fase del tramonto, durante la quale il prodotto sparisce).

È un processo ben documentato. E' molto utilizzato, sia a livello internazionale che italiano. Ed è popolare anche nel mondo accademico ed in quello degli standard. Gli svantaggi derivano dall'essere un framework di processo adattabile più che un processo vero e proprio e può essere interpretato in modi diversi. L'utilizzo di RUP senza adattamenti è sconsigliabile perchè è troppo complesso e si corre il rischio di non riuscire a selezionare ciò che serve veramente nella specifica situazione.

2.4 Processi Agili

I processi agili sono processi iterativi che danno importanza:

• agli individui e alle loro interazioni

• al software funzionante

• alla collaborazione con il cliente

• a rispondere ai cambiamenti

Sono nati nella seconda metà degli anni novanta e quindi sono ancora poco diffusi. I processi agili più noti sono XP (eXtreme Programming) e Scrum.

(30)

2.4.1 Extreme Programming

È uno dei processi agili, è stato ideato nel 1997 da Kent Beck.

Figura 4 Extreme programming

Listening è la specifica delle storie, casi d’uso, da parte del cliente.

Il coding è una attività che ingloba le attività di analisi, progetto e sviluppo. Le attività fondamentali sono:

• Planning, si identificano le “storie” da realizzare nelle successive iterazioni, si identificano le priorità del cliente. Viene effettuata prima dell’inizio di ogni iterazione definendone gli obiettivi.

• Small releases, sono iterazioni brevi (15-60 gg.), ciascuna ha il compito di realizzare un insieme di storie concordato con il cliente.

• Metaphor, si definisce e approva una "metafora" architetturale, che guida la strutturazione del sistema.

• Simple design, si tende a scegliere costantemente la soluzione "più semplice" ad un dato problema, senza porsi il problema dei futuri cambiamenti.

• Testing, si preparano i test, è effettuata in modo sistematico prima della codifica. Vengono utilizzate tecniche di automazione dei test, per verifiche di non regressione.

(31)

• Refactoring, è la ri-strutturazione del codice esistente, per migliorarlo; seguita dalla verifica di non regressione.

• Pair programming viene adottata la programmazione in coppia.

• Collective code ownership, proprietà collettiva del codice da parte dell'intero gruppo di lavoro: chiunque può modificare e migliorare una qualsiasi parte del sistema.

• Continuous Integration, le modifiche effettuate sul sistema vengono sottoposte a test di integrazione.

• 40-hour week, è il divieto di lavoro straordinario poichè nel medio termine diminuisce la produttività del gruppo di lavoro

• On-site customer, il cliente (o un suo rappresentante) deve essere sempre disponibile per chiarimenti sulle storie da realizzare.

• Coding standards, gli standard di codifica vengono rispettati in modo ferreo.

Le caratteristiche più note e più discusse di XP sono una limitata documentazione, infatti questa è costituita dal codice sorgente, che deve essere autoesplicativo, e dai test. L’altra è che non esiste una suddivisione dei ruoli, analista programmatore progettista. I Vantaggi di XP sono dovuti al fatto che, è un processo molto efficiente, e in grado di fare fronte al cambiamento di requisiti. Fornisce prodotti di più qualità rispetto a molti progetti condotti con altri approcci (pratiche sistematiche e quotidiane di testing e di continuous integration). C’è responsabilità collettiva da parte del gruppo di lavoro, ciò rende i team coesi. Gli svantaggi sono che XP è inadatto a contesti progettuali in cui sia richiesta una tracciatura sistematica dei requisiti. L'adozione di XP richiede trasformazioni degli assetti organizzativi e delle politiche del personale, in quanto modifica i ruoli consolidati a livello organizzativo. Richiede anche una trasformazione degli aspetti logistici, poiché il gruppo di lavoro (tipicamente costituito da circa una decina di persone) operi in un singolo locale. E' molto più semplice adottare XP per una software house (in particolare, per una software house appena nata) che non per il settore sistemi di una grande organizzazione. XP richiede che le persone siano capaci di lavorare in gruppo. Richiede inoltre l'utilizzo di strumenti di sviluppo evoluti, per programmare, testare, ri-strutturare il codice in modo estremamente produttivo.

(32)

2.4.2 Scrum

È un processo agile i suoi ideatori sono Ken Schwaber e Jeff Sutherland. Il nome è derivato dal Rugby. Trasforma le relazioni tra clienti e fornitori e le relazioni tra capo progetto e gruppo di progetto. È indicato per progetti in cui gli obiettivi ed i requisiti cambiano continuamente. È di natura iterativa ed incrementale, le attività sono svolte in modo intensivo, non predefinito ed in periodi limitati. Il cliente controlla i periodi di lavoro, ma non dall’interno. I ruoli dello Scrum sono:

• il proprietario del prodotto, è il committente ha il compito di gestire l’elenco delle richieste di aggiunta e di modifica, gestisce i conflitti con le altre parti in causa, quantifica l’impegno delle richieste, stabilisce le priorità partecipa alle revisioni e alle pianificazioni mensili, non può modificare le priorità durante il periodo di lavoro

• altre parti in causa (stakeholders), sono utenti che possono effettuare richieste di evoluzione o modifica del prodotto, possono effettuare una richiesta in qualsiasi momento, che può essere presa in carico successivamente, possono indicare priorità, possono partecipare alle revisioni ed alle pianificazioni mensili.

• il capo progetto, protegge il gruppo di lavoro durante i periodi di lavoro mensili, allinea giornalmente i gruppi di lavoro e gestisce gli allineamenti, rende visibile a tutti l’avanzamento delle attività durante il periodo di lavoro mensile, prende decisioni sulla riduzione o sull’incremento delle cose da fare.

• il gruppo di lavoro, nelle pianificazioni mensili valuta le cose da fare e si impegna a realizzarne una parte, crea un elenco di task da effettuare per raggiungere gli obiettivi nel mese, si auto-organizza nel periodo di lavoro mensile, tiene traccia dell’avanzamento dei task, segnala al capo progetto problemi di allineamento, nelle revisioni mensile presenta i risultati del lavoro.

• Le fasi principali nello Scrum sono:

• allineamento mensile viene verificato il lavoro effettuato durante il mese precedente, si esaminano le criticità, si definiscono i contenuti del prossimo rilascio sulla base delle priorità evidenziate dal proprietario del prodotto e sulle stime di impegno del gruppo di lavoro.

• Allineamento giornaliero, è una riunione quotidiana per identificare i colli di bottiglia, avviene sempre nello stesso luogo ed alla stessa ora, ogni partecipante al progetto informa gli altri partecipanti, su cosa ha fatto il giorno prima cosa farà oggi

(33)

e gli ostacoli alla sua attività.

• Fasi di lavoro mensili, comprendono le attività di sviluppo tradizionali, all’inizio viene creato l’elenco di task da fare per conseguire gli obiettivi del mese; si definiscono le responsabilità sui task, si tiene traccia, giornalmente, del completamento dei task, se l’avanzamento è in ritardo o in anticipo il capo progetto può ridurre o aumentare le cose da fare.

Scrum è vantaggioso nelle situazioni caotiche e confuse. È orientato alla gestione dei cambiamenti e a risultati concreti. Il committente è coinvolto durante tutto il processo. Il gruppo di lavoro è più unito perché la responsabilità è collettiva.

Tale processo non dà indicazioni su come eseguire la gestione dei requisiti, l’analisi ed il disegno, i test, ecc.. quindi si dovrà integrare con altri approcci.

(34)

CAPITOLO 3 NORME E QUALITA’

Capitolo 3 Norme e qualità

Sempre più imprese adottano la certificazione della qualità per migliorare la loro immagine e competitività sui mercati. I committenti, pubblici o privati, richiedono la qualità perché offre maggiori garanzie sui risultati della fornitura e la semplificazione dei metodi di controllo. Per produrre un buon software si deve progettare dettagliatamente il processo di sviluppo che si vuole utilizzare. Per fare questo e per migliorare i processi di sviluppo esistenti ci sono standards, modelli e norme, emessi da diverse organizzazioni con l'obiettivo comune di migliorare la qualità dei prodotti agendo sui processi che li producono. La scelta della norma o standard da seguire è fatta in base alle esigenze ed alle situazioni.

La scelta ISO1 9000 è la scelta più diffusa in Italia. ISO 12207 è orientata in modo più specifico alla definizione dei processi del software; ISO 15504 (SPICE) e SEI-CMM al miglioramento dei processi, ISO 9126 alla definizione dei requisiti qualitativi di un prodotto software, ECSS allo sviluppo di progetti in ambito spaziale, etc. Per la trattazione del capitolo sono stati usati i riferimenti [5], [6], [12].

3.1 Famiglia ISO 9000

Le norme ISO 9000, pubblicate la prima volta nel 1987, costituiscono uno standard di riferimento per la gestione della qualità nelle aziende italiane. Nella versione 1994 comprendeva la ISO9001, ISO9002, ISO9003, ISO9004, poi unificate in un unico modello ISO9001 nella versione 2000. Sono nate nel mondo della produzione industriale, ma si applicano, generalizzandole, ad ogni organizzazione di progettazione, produzione e distribuzione.

Tali norme sono completate da guide per settori merceologici con caratteristiche strutturali diverse. Le norme base descrivono i requisiti che un sistema di qualità deve avere per poter essere certificabile. Le guide danno spunti di come applicare i principi base in uno specifico contesto ed altri requisiti raccomandati, ma non obbligatori per la

1_{ISO è una organizzazione internazionale(International Organisation for Standardsation) che si occupa di definire e}

diffondere standard in tutti i processi produttivi.

(35)

certificazione. I processi informatici sono atipici per questo nel gruppo di lavoro ISO gli informatici sono molto attivi.

Per le aziende software, le norme ISO 9000 sono interpretate dalla guida ISO 9000/3 per l’applicazione della norma ISO9001 allo sviluppo, fornitura, installazione e manutenzione del software.

3.1.1 Struttura della Norma ISO 9001

La norma ISO9001 prevede lo sviluppo in 20 punti, numerati da 4.1 a 4.20: 4.1 Responsabilità della direzione

4.2 Sistema qualità

4.3 Riesame del contratto

4.4 Controllo della progettazione 4.5 Controllo dei documenti e dei dati 4.6 Approvvigionamento

4.7 Controllo del prodotto fornito dal committente 4.8 Identificazione e rintracciabilità

4.9 Controllo del processo 4.10 Prove, controlli e collaudi

4.11 Controllo delle apparecchiature di prova, misurazione e collaudo 4.12 Stato delle prove, controlli e collaudi

4.13 Controlli dei prodotti non conformi 4.14 Azioni correttive e preventive

4.15 Movimentazione, immagazzinamento, imballaggio, conservazione e consegna 4.16 Controllo della registrazione della qualità

4.17 Verifiche ispettive interne della qualità 4.18 Addestramento

4.19 Assistenza

4.20 Tecniche statistiche

(36)

qualità, la struttura del sistema qualità e l’organizzazione nella quale deve essere introdotto.

• Procedure del sistema qualità descrive in modo preciso e secondo schemi e modelli obbligati (template) le modalità di conduzione delle attività e dei processi aziendali.

• Sono dettagliate le istruzioni operative di tipo tecnico seguite dalle diverse tipologie di personale nello svolgimento delle proprie attività.

Nella versione del 2000 sono state introdotte delle novità che enfatizzando:

• La soddisfazione del cliente

• La definizione degli obiettivi e pianificazione per raggiungerli

• Il concetto di misura, analisi e miglioramento, introducendo un nuovo requisito

• La gestione orientata ai processi anziché alle funzioni aziendali (individuati quattro macro-processi principali: responsabilità della direzione, gestione delle risorse, realizzazione dei prodotti e servizi, misura ed analisi per il miglioramento)

• La gestione delle risorse umane dedicate al sistema.

È stato revisionato anche il linguaggio: Il “fornitore” è chiamato “organizzazione”, non si parla più di “prodotto”, ma di “prodotto/servizio”, non si parla più di “assicurazione qualità”, ma di “sistema di gestione della qualità”.

3.1.2 Guida ISO 9000/3

La prima versione (1991) ha avuto dei problemi di applicazione perché la struttura

era diversa da quella della norma e l’esposizione delle raccomandazioni non era chiara. La nuova versione (1998) ha risolto tali problemi. Infatti è impostata in base agli stessi capitoli della ISO 9001 e riporta gli aspetti normativi obbligatori e separatamente, le raccomandazioni facoltative.

I certificatori si riferiscono alla guida ISO 9000/3 e richiedono l’evidenza della sua completa applicazione.

Nel sistema qualità di un’organizzazione software ci sono :

1. La struttura del sistema qualità: responsabilità della direzione, sistema qualità, verifiche ispettive, azioni correttive e preventive.

2. Le attività relative al ciclo di vita del software: riesame del contratto, specifica dei requisiti, pianificazione dello sviluppo, pianificazione della qualità, progettazione e

(37)

realizzazione del software, prova e validazione, accettazione, duplicazione ed installazione, manutenzione.

3. Le attività di supporto (accompagnano l’intero ciclo di vita del software): gestione della configurazione, controllo dei documenti e dei dati, controllo della registrazione della qualità, misure, regole e convenzioni, strumenti e tecniche, approvvigionamenti, prodotti inclusi, addestramento.

I principali contenuti della guida riguardano la raccolta dei requisiti, la progettazione, le attività post-progettazione e la manutenzione del prodotto software. Per quello che riguarda la raccolta dei requisiti la ISO 9001 nel cap 3, riesame del contratto, sancisce di raccogliere ed esplicitare in modo chiaro tutti i requisiti e di sottoporli, prima di sviluppare il prodotto, ad un riesame che ne verifichi la completezza e la capacità di poterli soddisfare. La guida ISO 9000/3 specifica delle raccomandazioni per impostare il documento, allegato tecnico all’offerta o studio di fattibilità del prodotto, che descriva i requisiti del prodotto e le condizioni del progetto realizzativi. I requisiti sono raggruppati in quattro categorie: Commerciali, tecnici, manageriali, legali.

Viene raccomandato di implementare una valutazione del rischio per stimare e dimensionare al meglio i tempi ed i costi di realizzazione. È opportuno riportare gli aspetti della fase negoziale in un documento utilizzato anche come una checklist in modo da approfondire e formalizzare ciò che è disponibile ed evidenziare le carenze informative. I più importanti aspetti commerciali sono:

• Definizione delle responsabilità del cliente-committente nel fornire informazioni, dati o supporto

• Definizione delle modalità di gestione delle modifiche in corso d’opera

• Definizione dei criteri di accettazione del prodotto sviluppato

• Definizione di come gestire le segnalazioni di anomalie e di reclami successivi

• Definizione delle responsabilità di manutenzione correttiva

• Definizione degli impegni e delle modalità di manutenzione evolutiva od adattativi.

Per gli aspetti tecnici, manageriali e legali i più importanti sono:

(38)

• Verifica delle disponibilità delle risorse umane o tecnologiche necessarie

• Accettabilità da parte del cliente del prodotto

• Verifica della disponibilità delle risorse umane o tecnologiche necessarie

• Accettabilità, da parte del cliente, di eventuali “subcontracting”

• Possibilità di ispezioni o revisioni tecniche nel corso del progetto

• Valutazione delle capacità professionale di poter soddisfare tutti i requisiti evidenziati nei tempi richiesti.

In questo modo si ha maggiore chiarezza, più facilità di ottenere dal committente tutte le informazioni necessarie per impostare e condurre le attività di un progetto di sviluppo Software e la tendenza ad avere uno standardizzato e condiviso riferimento contrattuale.

Per la progettazione (cap4 ISO 9001) e produzione (cap 9 ISO 9001), la guida chiarisce, nel cap 4, che i problemi di qualità si concentrano nella fase di progettazione comprendente le fasi di analisi, architettura, disegno, codifica. Nel cap 9 tratta solo le attività di duplicazione, consegna ed installazione.

Le raccomandazioni sono quelle di:

• Utilizzare un ciclo di vita e metodologie di analisi e disegno adatte alla tipologia del progetto di sviluppo

• Effettuare una precisa e rigorosa pianificazione di tutta la progettazione (dimensionamento delle attività, schedulazione temporale dei task, assegnamento delle risorse e suddivisione dei compiti tra i diversi membri del progetto)

• Mantenere costantemente sotto controllo lo stato di avanzamento del progetto (monitorare i risultati, individuare tempestivamente i ritardi)

• Inserire nelle fasi cruciali del ciclo di vita le attività di riesame e di verifica delle attività completate o degli output ottenuti per verificarne la conformità alle procedure e standards aziendali ed il soddisfacimento dei requisiti iniziali.

• Definire per ogni task gli strumenti e le tecniche da utilizzare, permetterne il richiamo automatico e l’eventuale consultazione di guide in linea, o assicurare il coinvolgimento di altre figure professionali nell’ambito di alcuni passi.

Seguendo le raccomandazioni della ISO 9000/3 si fornisce al personale di progetto un’impostazione documentale, che serve da guida e da supporto, limitando la reazione di rigetto alla consultazione ed alla personale interpretazione delle norme procedurali e degli standards.