| Materie: | Appunti |
| Categoria: | Informatica |
| Download: | 483 |
| Data: | 04.10.2001 |
| Numero di pagine: | 116 |
| Formato di file: | .doc (Microsoft Word) |
Download
Anteprima
concetto-qualita-produzione_1.zip (Dimensione: 85.19 Kb)
readme.txt 59 Bytes
trucheck.it_il-concetto-di-qualit+ 326.5 Kb
Testo
Anno scolastico 2000/2001
Classe V A Informatica
Area di progetto
Il concetto di qualità nella produzione
Corso di matematica applicata – calcolo delle probabilità e statistica
Indice
Introduzione . . . . . . . . . 4
Capitolo 1
Il concetto di qualità nelle aziende in generale . . . . . 6
1.1 Il concetto di qualità ed il sistema di qualità . . . . . 6
1.2 Definizione del sistema di qualità . . . . . . 11
1.3 Quality function development – Lo sviluppo della funzione qualità . 12
1.4 L’analisi del rischio . . . . . . . 15
1.5 Il sistema delle informazioni . . . . . . . 17
1.6 La certificazione di qualità . . . . . . . 18
1.6.1 Generalità . . . . . . . 18
1.6.2 Una visione storica . . . . . . . 22
Capitolo 2
Il software: processo e prodotto . . . . . . 25
2.1 Il software: da arte ad artigianato ad industria . . . 25
2.2 Fattori di qualità del software . . . . . 28
2.2.1 Affidabilità . . . . . . 28
2.2.2 Correttezza . . . . . . 28
2.2.3 Robustezza e sicurezza . . . . . . 28
2.2.4 Prestazioni . . . . . . 28
2.2.5 Usabilità . . . . . . 29
2.2.6 Verificabilità . . . . . . 29
2.2.7 Manutenibilità . . . . . . 29
2.2.8 Riusabilità . . . . . . 30
2.2.9 Comprensibilità . . . . . . 30
2.2.10 Interoperabilità . . . . . . 30
2.2.11 Produttività . . . . . . 31
2.3 Il processo di produzione del software . . . . 32
2.4 Modelli di produzione software . . . . . 34
2.4.1 Il modello a cascata (Waterfall Model) . . . . 34
2.4.2 Il modello a ciclo di vita a spirale (Barry Boehm) . . . 38
24.3 I modelli basati sulle trasformazioni . . . . . 39
2.4.4 Il modello basato sulla prototipazione . . . . 40
Capitolo 3
Modelli industriali per la produzione di software. . . . 41
3.1 Introduzione . . . . . . 41
3.2 L’ingegneria del software . . . . . . 43
3.2.1 Analisi: i tre approcci . . . . . . 44
3.2.2 Object Oriented: il paradigma del futuro? . . . . 46
3.2.3 Le valutazioni economiche . . . . . . 47
3.3 Le organizzazioni industriali per la progettazione del software . 48
3.3.1 “Cosa deve essere fatto” e “Come deve essere fatto”. . . 48
3.3.2 I modelli del tipo “Cosa si deve fare” . . . . 50
3.3.2.1 Il modello CMM . . . . . . 50
3.3.2.2 Il modello SPICE . . . . . . 52
3.3.2.3 Struttura organizzativa indotta da CMM e SPICE . . . 55
3.3.3 I modelli del tipo “Come si deve fare” . . . . 58
3.3.3.1 Il modello “Unified Software Development Process” . . 59
3.3.3.2 Il modello “eXtreme Programmino (XP)” . . . . 62
3.3.4 Conclusioni . . . . . . 64
3.4 Lo sviluppo del software ed il controllo di qualità . . . 65
3.4.1 Approcci diversi all’Assicurazione della Qualità nel software – La normativa 65
3.5 Esempio di gestione di un progetto software . . . 70
Capitolo 4
La conferenza e le interviste . . . . . . 73
4.1 La conferenza . . . . . . 73
4.2 Le interviste . . . . . . 74
4.2.1 Alla Fosam S.P.A. . . . . . . 74
4.2.2 Alle Officine Stefanuto . . . . . . 75
4.2.3 Alla Alfa Con s.r.l. . . . . . . 75
4.2.4 Alla Usable Net . . . . . . 77
Bibliografia . . . . . . . . . 78
Introduzione
E’ decisamente attuale il concetto di qualità. Se andiamo ad analizzare con accuratezza, anche i nostri gesti o pensieri più semplici sono permeati da questa esigenza contemporanea. Ma cos’è la qualità? Di primo acchito, senza dare un’occhiata ad un dizionario serio oppure alla letteratura specializzata è difficile rispondere a questa domanda, troppo vaste le sensazioni che suscita.
Però, dopo un primo momento di smarrimento, ci rendiamo conto che esiste tutto un mondo produttivo che regola le proprie azioni secondo questo nuovo concetto.
Ecco, che allora, per dei ragazzi che stanno uscendo dalla scuola secondaria superiore e che in diversi casi affronteranno il mondo produttivo, può risultare culturalmente utile essere preparati su questo argomento, ponendo l’accento su cosa significa il concetto qualità nel mondo aziendale odierno.
Il seguente lavoro si compone essenzialmente di tre parti:
- una prima parte che affronta e chiarisce la definizione del concetto di qualità, e di produzione secondo qualità, in generale, senza alcuna distinzione sul tipo di azienda produttiva;
- una seconda parte si occupa, più dettagliatamente, del concetto di qualità per le aziende di produzione di software, vista la specializzazione di questa classe;
- una parte finale dove vengono riportate le interviste fatte a responsabili aziendali che si occupano di produzione secondo paradigmi di qualità, di quattro aziende di produzione, di diversi settori (una del settore dell’arredamento, una azienda di carpenteria speciale, due aziende di produzione software), che gli allievi hanno visitato insieme all’insegnante, per poter concretizzare le argomentazioni teoriche e confrontarle con la realtà.
Nel primo capitolo vengono chiariti i concetti di qualità e di sistema di qualità aziendale, viene inoltre proposto un esempio di metodologia, per la realizzazione di un sistema di qualità. Vengono inoltre trattati i seguenti argomenti: l’analisi dei rischi aziendali, il sistema delle informazioni, vitale per l’organizzazione aziendale, e la certificazione di qualità, obiettivo ultimo del processo di qualità.
Nel secondo capitolo viene presentato un breve riassunto di come si sia evoluta la produzione del software dai suoi albori fino ai nostri giorni e di come sia fortemente sentita l’esigenza di una industrializzazione della produzione del software e di come essa sia purtroppo estremamente difficile da realizzare. Sempre nel secondo capitolo vengono presentati i fattori che definiscono un codice di buona qualità e quali siano i modelli di produzione del software presentati in letteratura, che hanno anche come obiettivo quello di produrre un codice di buona qualità.
Tutto il terzo capitolo si occupa della presentazione di alcuni modelli industriali per la produzione del software, colti naturalmente dall’esperienza americana, dove le aziende di produzione di codice hanno decisamente dimensioni autorevoli. Viene in questo capitolo presentato anche il modello probabilmente più innovativo, quello orientato alla progettazione e programmazione ad oggetti. Viene inoltre presentato un esempio di gestione di un progetto software.
Nel quarto capitolo vengono raccolte le opinioni espresse da esperti di produzione di vari tipi di aziende, durante una conferenza organizzata in Istituto e durante le quattro visite di istruzione effettuate dagli allievi in aziende presenti nel territorio.
Gli allievi Luca Bet, Matteo De Conti, Federico Fantin, Lorena Lenardon, Matteo Marson, Marzia Mazzolo, Alberto Meneguz, Simone Moret, Alex Polito, Cristian Polloni e Maurizio Rizzo, appartenenti alla classe V A Informatica, si sono occupati di questo lavoro, ciascuno di essi contribuendo in modo personale e diversificato, senza perdere di vista il lavoro d’insieme.
Si ringraziano sia il personale dell’Istituto sia i responsabili delle aziende visitate per la loro disponibilità e collaborazione.
Capitolo 1
Il concetto di qualità nelle aziende in generale
1.1 Il concetto di qualità ed il sistema di qualità
Nel tempo il concetto di qualità ha assunto connotazioni e pesi diversi. Oggi questa parola vanta una sorta di forza magica di attrazione. Si parla continuamente di qualità, gestione della qualità, garanzia della qualità e promovimento della qualità, attribuendo al termine aspettative e significati diverse.
La norma ISO UNI 8402 riporta che la qualità è l’insieme delle proprietà e caratteristiche strutturali di un prodotto o servizio che gli conferiscono l’attitudine a soddisfare bisogni espressi o impliciti.
Ma definire il concetto di qualità e` una cosa molto complessa non riconducibile ad una sola definizione.
Incominciamo dicendo che nel campo della produzione “industriale” la qualità è conformità ai requisiti del cliente ottenuta con la collaborazione congiunta di tutte le funzioni aziendali.
La qualità è una filosofia che deve coinvolgere tutti in azienda.
La qualità va perseguita in ogni fase dei processi aziendali, in ogni parte dell'organizzazione, nel comportamento di ogni singolo individuo.
La qualità è un fatto culturale. Non esistono aziende che possano comprare il proprio modo di gestire il loro “processo aziendale” nel produrre beni di qualità. Si spenderebbero soldi senza ottenere alcun risultato o addirittura si potrebbe peggiorare la situazione, creando confusione. Se, al contrario, il personale interno viene sensibilizzato e messo nelle condizioni di acquisire questa cultura, l’azienda non incontrerà problemi nel definire e attuare il proprio Sistema Qualità; questo, infatti, diviene una conseguenza naturale della nuova mentalità, un’esigenza connessa con la nuova visione dell’azienda.
qualità significa:
1. Priorità assoluta al cliente
Il cliente è il padrone dell'azienda. Dato che senza clienti l'azienda non può sopravvivere, la soddisfazione dell'esigenza del cliente s'impone all'azienda come priorità assoluta.
Qualità significa dunque consolidare e accrescere continuamente la capacità dell'azienda di soddisfare il cliente.
Le procedure più frequentemente utilizzate per la identificazione delle attese del cliente sono:
a- Un brain storming tra esperti;
b- Un’indagine tra i clienti e i consumatori svolta tramite interviste e questionari;
c- Un test di preferenza con campioni di consumatori;
2. Impegno diretto e costante dell'Alta Direzione
Il successo dell'introduzione di un Sistema di qualità dipende totalmente dall'impegno e dall'entusiasmo messi dal Top Management. Impegno ed entusiasmo devono tradursi in una continua azione di leadership volta a guidare tutta l'organizzazione verso il profondo cambiamento che ci si accinge ad affrontare.
3. Miglioramento continuo di tutte le attività aziendali
La soddisfazione del cliente, in quanto essere umano, non ha limiti. Ogni livello qualitativo raggiunto, dopo qualche tempo viene dato per acquisito. Esso perde dunque di valore agli occhi del cliente, le cui aspettative crescono e si modificano continuamente. Ecco quindi l'importanza di lavorare costantemente al miglioramento del proprio prodotto o servizio.
A differenza del miglioramento per innovazione, caratterizzato dal procedere per grandi balzi in avanti, il miglioramento continuo è fatto da piccoli passi.
Esso dipende esclusivamente da ingegno, creatività, esperienza di tutto il personale dell'azienda; proviene, dunque, da una fonte inesauribile ed è inimitabile e illimitato.
Innovazione e miglioramento continuo non sono attività contrapposte, ma, anzi, il miglioramento per gradi consente di amplificare la portata e i risultati ottenibili con l'innovazione tecnologica.
4. Coinvolgimento di tutto il personale dell'azienda
La qualità mobilita le risorse intellettuali di tutto il personale dell'azienda, perché tutti devono essere coinvolti nell'attività di miglioramento.
Occorre valorizzare le capacità delle risorse umane attraverso l’istruzione, la formazione e la motivazione, al fine di consentire la liberazione dell’energia creativa dei singoli individui.
5. Formazione continua
Ciascuno in azienda, grazie alla possibilità di studiare e proporre qualche miglioramento, diventa la fonte di un piccolo ma importante vantaggio competitivo. Le capacità illimitate di ogni essere umano rappresentano in quest'ottica il patrimonio più importante per l'azienda.
Qualità significa appunto investire nella risorsa principale: l'uomo.
6. Attenzione ai processi
La qualità nasce nei processi: la soddisfazione del cliente non è altro che il risultato di tutto ciò che viene svolto in azienda. Prestare attenzione ai processi significa "dominare" ciascun processo, conoscerne a fondo il legame causa – effetto.
7. Prevenzione
Nella qualità l'enfasi è sulla prevenzione piuttosto che sul controllo. La prevenzione ci assicura di fare le cose giuste la prima volta. Svolgere un'efficace attività di prevenzione significa risolvere i problemi alla radice via via che si manifestano.
8. Sistema di controllo
Comprende il concetto di verifica e di intervento. I livelli di controllo sono due: uno occupato dal produttore e uno dal consumatore. La cosa migliore è scomporre ogni attività in un sistema di attività se vogliamo conoscere e controllare efficacemente il sistema complessivo.
Possiamo quindi concludere che per poter progettare un sistema di qualità bisogna prima progettare un sistema di attività. Infatti i sistemi di qualità sono sistemi di attività umane che sono determinate dalla consapevolezza di problemi e dalla volontà di risolverli.
Per progettare il modello concettuale di qualità consono per eliminare la situazione problematica bisogna per prima cosa aver chiarito certe informazioni:
- sapere chi è il proprietario e il beneficiario del sistema;
- quale sistema prodotto-processo si applica il sistema;
- quali sono gli obiettivi e i vincoli;
- quali sono le persone coinvolte e che ruolo occupano.
Una volta entrati in possesso di tutte queste informazioni si può procedere, utilizzando diversi modelli predefiniti, per trovare il proprio “sistema di qualità”.
Ad esempio le norme ISO 9000 sono modelli di sistemi di qualità certamente interessanti, come lo sono molti altri, ma che hanno il difetto di essere diventate “norme”, cioè riferimenti obbligatori.
Diamo qui di seguito un esempio di modello concettuale di sistemi di qualità. La definizione del sistema viene fatta a livelli.
Primo livello
Si parte dall’identificazione delle attese del cliente che, come già evidenziato nel primo punto per la definizione di qualità, sono la cosa più importante.
Il secondo passaggio del modello concettuale consiste nella definizione delle specifiche di prodotto che sono i dati quantificabili che rappresentano le attese del cliente.
E’ opportuno, per una questione di ordini e di completezza, che anche nell’elencare le specifiche si segua una certa regola. Un buon metodo è quello di classificare le specifiche nel linguaggio dei tecnici che operano le verifiche oppure classificarle in base ad un criterio normativo per agevolarne la comprensione da parte dei legali dell’azienda. In questo caso si possono elencare:
- specifiche derivanti da norme obbligatorie;
- specifiche derivanti da norme volontarie (marchi e consorzi di qualità;
- specifiche assunte volontariamente dall’azienda.
Il terzo passaggio è occupato dalla definizione dei fattori critici del processo i quali possono influire in misura significativa sulla qualità del prodotto. Una volta individuati i fattori che condizionano il processo è consigliabile procedere indagando sistematicamente ciascuno di questi fattori, valutando il suo impatto sulla qualità del prodotto e definendo misure efficaci di controllo per ciascuno di essi, questo, spesso, è il vero segreto e significato del sistema di qualità.
A questo punto si procede con l’analisi di processo che permette di conoscere le attese del cliente, le specifiche del prodotto e i fattori critici del processo.
Secondo livello
Spostandoci nel secondo livello del sistema si devono definire tre tipi di verifica:
a) Verifica della soddisfazione delle attese del cliente.
Essenziale e generalmente trascurata dalle aziende.
b) Verifica della conformità del prodotto alle specifiche.
Questa verifica è affidata al laboratorio di analisi che deve porsi in questa fase il problema della rappresentatività delle analisi e definire un appropriato piano di campionamento.
c) Verifica dei fattori critici del processo.
Ciascun fattore critico del processo deve essere sottoposto a verifica. In questo caso le verifiche richiedono metodi diversi in relazione alla diversa natura di ciascun fattore critico.
I dati rilevati con i vari sistemi di verifica sono, in generale, così importanti che è utile o necessario conservarne memoria. Essi possono servire: come prova nei confronti di terzi della regolarità ed efficacia del processo e come elementi di guida verso la standardizzazione del processo o come correzione, miglioramento del sistema.
Con i controlli giungiamo al terzo livello dello schema. Il termine “controllo” è usato nel senso di “intervento” ed ha lo scopo di mantenere un parametro misurato entro limiti prefissati. E’ comunque da ritenere come un fatto assolutamente necessario che ad ogni sistema di verifica debba corrispondere un sistema di controllo (se non ci fosse sistema di controllo, la verifica sarebbe inutile).
Il controllo si realizza con modalità diverse in situazioni diverse. Il primo modo di intervento è quello che si attua quando il sistema funziona regolarmente e i parametri del prodotto o i fattori critici del processo hanno valori normali; correggo le anomalie e tutto funziona per il meglio.
Il sistema di controllo deve essere sempre attivo perché di anomalie in un processo di produzione ne avvengono a decine ogni giorno. Ma a volte le anomalie possono essere gravi.
Alcune norme prevedono che le anomalie debbano essere previste e codificate e così pure le corrispondenti azioni correttive. La capacità di un impresa di individuare tempestivamente le anomalie, di decidere quale azione correttiva intraprendere e di realizzarla rapidamente riportando il sistema nella normalità è di importanza decisiva per il buon funzionamento del processo produttivo dell’azienda stessa.
Con l’analisi del sistema di controllo e delle anomalie siamo passati al livello gestionale del sistema di qualità.
Di questo livello fanno parte due elementi fondamentali: quello dei ruoli/responsabilità e quello della comunicazione.
La definizione dei ruoli in un sistema è molto semplice se il sistema viene adeguatamente dettagliato e se si tiene bene a mente l’organizzazione gerarchica dei sistemi.
Per quanto riguarda il flusso di informazioni fra le varie attività di un sistema è come il sistema nervoso del nostro corpo: li elabora, ne ricava informazioni da cui si originano ordini che vengono trasmessi alle varie agenzie operative. La mancanza o l’inadeguatezza di questo flusso impedisce l’ottimizzazione e l’efficacia del sistema poiché tutte le informazioni sono collegate. Una comunicazione da un’attività all’altra del sistema, per essere efficace, deve contenere un messaggio utile chiamato informazione a chi lo riceve per compiere la sua attività.
L’utilizzatore ricevendo l’informazione è messo in condizioni di operare.
In tal modo egli interviene sul processo e genera nuovi dati chiedendo così il circuito del sistema informativo.
Il modello concettuale, pur derivando da un’analisi approfondita del processo reale, rappresenta un’ipotesi di sistema o, più propriamente, ciò che il sistema dovrebbe essere. Dopo aver confrontato con la realtà il modello si fanno i relativi interventi fattibili e desiderabili. Giunti a questo punto dovrebbe essere facile raccogliere in un documento o “manuale della qualità” tutte le informazioni e le istruzioni che costituiscono il sistema di qualità.
Una volta fatto questo non resta altro che passare all’attuazione pratica del sistema di qualità.
1.2 Definizione del “sistema di qualità”
Dopo detto tutto questo siamo in grado di presentare una definizione di “sistema di qualità”.
La norma ISO 8402 né da la seguente definizione: “Sistema di qualità è la struttura organizzativa, le responsabilità, le procedure, i procedimenti e le risorse messe in atto per la conduzione aziendale per la qualità”.
Questa definizione ha molti difetti ed è forse in parte responsabile del confuso mix di prescrizioni che spesso si trovano nei manuali di qualità e nelle stesse norme. Innanzitutto è sorprendente la genericità dell’espressione che definisce l’obiettivo del sistema di qualità: “la conduzione aziendale per la qualità”.
In realtà un sistema di qualità ha obiettivi più precisi ed in particolare ha quello di consentire la produzione di prodotti conformi alle specifiche, al minor costo.
La seconda critica che si può fare a questa definizione è che non si può fare alcuno specifico riferimento all’assenza del sistema di essere un “sistema di controllo”.
La terza critica è di presentare un elenco indifferenziato e confuso di ciò che costituisce un sistema di qualità, senza alcuna distinzione tra attività tecniche e attività gestionali: a che titolo vengono citate le risorse?
Che differenza ci può essere fra struttura organizzativa e responsabilità? Che differenza fra procedure e procedimenti?
Proponiamo pertanto questa nuova definizione:
Il sistema di qualità è l’insieme dei controlli tecnici e delle attività di gestione che sono attuati in un processo per consentire l’ottenimento di prodotti conformi a specifiche date, al minimo costo.
1.3 Quality function development - Lo sviluppo della funzione qualità
Proponiamo qui di seguito un esempio di metodologia, proposto in letteratura, per la realizzazione di un sistema di qualità.
QFD (Quality Function Development) è:
- un metodo di analisi del sistema processo-prodotto e consente di collegare tutte le attività del sistema all’obiettivo qualità;
- più in generale, è un metodo di organizzazione dei pensieri per confrontare opinioni di persone diverse e scegliere fra diverse alternative nei casi in cui la soluzione è discutibile e opinabile.
Questo metodo si articola in tre fasi:
1. definizione delle attese del cliente;
2. definizione delle specifiche del prodotto;
3. definizione dei punti critici del processo.
1) Ponendo come obiettivo generale una migliore soddisfazione delle ATTESE del cliente, si deve in primo luogo ricercare degli analisti che si preoccupino di realizzare un progetto corretto, ordinato e completo.
La selezione degli analisti e la classificazione secondo l’importanza delle loro opinioni si deve fare utilizzando una matrice di QFD che riporta i nomi e i criteri di valutazione. Dai calcoli eseguiti su questa matrice risulta una graduatoria che mette le persone interessate al progetto in ordine di competenza. In questo modo si evita che chi ha meno autorità prevalga sul resto della commissione. Però deve esserci un leader che gestisca l’analisi che può essere scelto dall’assemblea o nominato dall’esterno.
Quindi si procede alla definizione delle attese sviluppando diversi punti:
- chi è il cliente (consumatore finale, occasione di consumo, …)
- cosa s’intende per prodotto (nudo o con la confezione, specifico o con varianti, …)
- cosa s’intende per qualità (ad esempio per i prodotti alimentari legalità e sicurezza, qualità nutrizionale, sensoriale e presentazione e servizio)
A questo punto ogni soggetto della team è chiamato ad esprimere le attese dedotte e di seguito l’intero team crea un elenco definitivo delle attese.
Infine per ogni attesa si deve attribuire un peso. Questa operazione viene eseguita utilizzando una matrice e ponendo i nomi degli analisti con i relativi punteggi di importanza, e le loro attese. Sommando si ottengono i valori del peso di ciascuna attesa in base al quale verranno definite tutte le attività del sistema.
2) Definizione delle SPECIFICHE cioè dei parametri analitici che rappresentano le attese con indici verificabili e misurabili.
Per questo punto si richiedono competenze scientifiche, tecniche e professionali e perciò è necessario individuare un altro team di analisti seguendo lo stesso metodo matriciale QFD fatto per gli analisti della sezione precedente.
Pure per la definizione delle specifiche viene usata una matrice in cui vengono riprese le attese definite nella fase precedente. Questa matrice ha un’importanza fondamentale e generalmente viene suddivisa in due parti:
• la prima dedicata alle attese di legalità e sicurezza in cui le specifiche sono obbligatorie (generalmente vengono dedotte direttamente dalle relative leggi in vigore). Le specifiche relative a questa parte vengono scelte, e il loro peso stabilito, in base a considerazioni sulla possibilità del rischio che esse non siano soddisfatte;
• la seconda più incerta che viene completata con i parametri analitici che meglio rappresentano le attese. Le specifiche relative vengono selezionate attribuendo un grado di importanza in base a degli indici di correlazione tra attese e le specifiche stesse:
( = correlazione massima valore convenzionale 9
( = correlazione media valore convenzionale 3
( = correlazione limitata valore convenzionale 1
La somma dei valori convenzionali di ogni simbolo determina l’importanza relativa ad ogni specifica e permette di procedere ad eventuali correzioni.
3) Definizione delle ATTIVITA’ di CONTROLLO da effettuare sulle materie prime e sul processo di valutazione della loro importanza al fine di determinare la conformità del prodotto alle specifiche.
Anche in questa fase c’è bisogno di un team di analisti con competenze specifiche. Ovviamente anche questa volta si ricorre al metodo della matrice. In questo caso, oltre che per gli analisti, ma anche per le persone che vorranno attivare il sistema di qualità, la partecipazione al team ha anche un’utile funzione formativa.
In questa fase gli analisti devono cercare quali operazioni, fattori e condizioni sono critici al fine di ottenere la conformità del prodotto alle specifiche. Ponendo in una matrice le specifiche e i fattori del prodotto, si cerca di determinare quali sono i fattori più o meno importante ai fini della qualità e quali sono critici o irrilevanti.
Questo processo permette inoltre di considerare il sistema non in astratto, ma con riferimento ad un particolare prodotto, ad un particolare processo e ad una particolare azienda. E’ necessario considerare attentamente e in modo appropriato il significato delle varie categorie di fattori. Ad esempio: le materie prime devono essere considerate per le loro caratteristiche analitiche e non per la tecnologia di impiego o per il dosaggio che se ne fa nel processo.
Questa parte di controllo consente di trarre conclusioni importanti per l’impostazione dei controlli nel processo. Un aspetto da non sottovalutare è quello di porre un controllo particolarmente accurato ai fattori che hanno un peso predominante e porre una minore attenzione su fattori di importanza marginale.
Il QFD è un metodo di analisi che consente di ricercare in modo razionale e sistematico la soluzione di alcuni problemi che siamo abituati ad affrontare in modo improvvisato e disorganico:
* la ricerca della soluzione ottimale fra opzioni diverse
* la ricerca di correlazioni fra insiemi di cause ed effetti quando più cause concorrono ad un effetto e molti effetti possono derivare dalla stessa causa.
Oltre che in relazione ad un’azienda, questi sono problemi frequenti e sono alla base dei nostri comportamenti.
Possiamo inoltre notare che il QFD è uno strumento utile alla ricerca del consenso ed alla visualizzazione delle opinioni di tutti.
E poi è una metodologia d’analisi molto flessibile e ben adattabile all’approccio sistemico, potendosi applicare con uguale procedura ad un livello molto generale o ad un livello di estremo dettaglio.
Infine il QFD è:
* una metodologia (non un metodo) e, come tale, può applicarsi ai problemi e agli ambiti più disparati;
* una forma di disciplina mentale basato sulla codificazione e standardizzazione delle procedure che il nostro cervello segue intuitivamente quando deve esprimere un giudizio;
* una metodologia sistemica perché in grado di adeguarsi all’infinito ad una realtà costituita da sistemi contenuti in altri sistemi, dalla massima sintesi all’estremo dettaglio.
1.4 L’analisi del rischio
Un sistema di qualità non è buono (cioè completo ed efficiente) se non comprende un efficace sistema di prevenzione dei rischi di processo.
Il QFD serve anche a capire quali sono i punti critici del processo che garantiscono l’ottenimento di un prodotto conforme alle attese del cliente. L’analisi del rischio serve a capire cosa si deve fare per evitare che le attività svolte per conseguire quell’obiettivo abbiano conseguenze negative e finiscano per produrre danni.
E’ importante sottolineare che il RISCHIO è la possibilità che un’attività o un mezzo collegato al processo, producono un serio danno economico, legale, sociale o morale all’azienda.
In questa definizione sono contenute due incertezze:
* la prima riguarda l’entità del danno: quando possiamo considerare un danno come “serio”?
* la seconda riguarda la possibilità che ad un rischio potenziale finisca per corrispondere un danno reale.
Matematicamente la gravità del rischio GR si calcola come prodotto della probabilità P che si verifichi l’evento, per la gravità del danno GD (GR=P x GD).
Se la probabilità che accada un determinato evento è molto alta, l’azienda deve attribuire a questo rischio un’elevata priorità e deve dedicare ad esso un efficace sistema di prevenzione.
Il metodo di analisi dei rischi si articola in tre fasi:
Fase 1: identificazione dei rischi possibili e la loro classificazione secondo una
graduatoria di pericolosità;
Fase 2: identificazione dei fattori (cause) di rischio;
Fase 3: scelta dei sistemi di prevenzione.
FASE 1 Questa fase si suddivide in altre tre parti:
1) identificazione dei RISCHI POSSIBILI: cosa può andare storto nel processo
(metodi analitici)?
Questo è un punto molto importante perché nessun rischio che possa provocare un danno grave all’azienda, può sfuggire all’analisi. E’ pertanto necessario mettere a punto un modello complessivo dei rischi possibili, da utilizzare come riferimento e promemoria nell’analisi del processo.
a. Generalmente il primo aspetto da valutare riguarda i soggetti a rischio. Ad esempio, se facciamo riferimento alla tecnologia alimentare si deve considerare: il consumatore che può essere danneggiato nella salute per sostanze nocive contenute nel prodotto; il lavoratore che può subire conseguenze dalla carenza di sicurezza e salubrità dell’ambiente; l’ambiente stesso che può essere inquinato; e infine il proprietario dell’azienda che può subire danni economici.
b. L’identificazione dei soggetti a rischio permette di elaborare una classificazione dei rischi (per la salute, di contaminazione dell’ambiente, di perdite materiali, di tempo o energetiche, per la qualità nutrizionale e sensoriale del prodotto). E’ bene tenere ora presente che il rischio è, in primo luogo, tutto ciò che mette in pericolo la sopravvivenza e la salute dell’impresa.
c. Per completare l’analisi occorre osservare separatamente le diverse tipologie di rischio e sviluppare, per ciascuna di esse, sistemi di indicazione e di concetti sufficientemente precisi e dettagliati da permetterci di riconoscere la condizione di rischio quando si analizza un processo.
2) valutazione dell’ENTITÀ’ DEL DANNO: se qualcosa va storto, che danni ne possono derivare (conoscenza ed intuizione)?
Una volta identificati i possibili rischi di processo, occorre valutarne la pericolosità. E’ evidente che è molto difficile giungere ad un’esatta valutazione. Infatti, più che di valutazione si dovrebbe parlare di percezione o stima e l’indagine potrebbe consistere nel confronto delle opinioni di esperti e nell’attribuzione di un coefficiente relativo di gravità, ad esempio da 5 come danno gravissimo che porta alla chiusura dello stabilimento, a 1 come danno puramente economico, reversibile.
3) Valutazione della PROBABILITA’ che il rischio si tramuti in DANNO: che probabilità c’è che vada storto (esperienza storica)?
Per determinare la probabilità che un determinato evento accada, generalmente si fa riferimento all’esperienza storica dell’azienda. In questo caso l’azienda dovrebbe quindi disporre di un’agenda relativa a tutti i danni subiti.
Se questa non è stata compilata, o se non esiste un’esperienza passata è necessaria un’analisi approfondita realizzata da persone esperte e competenti.
FASE 2 Questa fase assume un ruolo molto importante perché, ricercando le cause che possono dare origine ad un danno, possiamo progettare i sistemi preventivi più appropriati.
Il primo principio da tenere presente in questa fase è di non confondere le condizioni con le cause del danno. E il secondo è di considerare che ogni causa è in realtà l’effetto di un’altra causa.
Per giungere ad una soluzione si deve applicare un sistema di rappresentazione causa-effetto “a lisca di pesce” inventato da Kaoru Ishikawa, uno dei padri della qualità.
FASE 3 Anche quest’ultima fase è tutt’altro che scontata e semplice e deve fare i conti con due problemi importanti:
1. evitare che l’eliminazione di un rischio crei un altro rischio per cui l’unico rimedio consiste nell’avere la più ampia e completa visione dei problemi e tenere conto di tutto;
2. valutare un bilancio tra costi e benefici per cui ogni volta che ci poniamo di fronte ad una nuova situazione dobbiamo valutare se è più utile ridurre la probabilità di un rischio per il quale sono già in atto sistemi di prevenzione o tentare di ampliare l’area della prevenzione di altri rischi.
In generale dunque si deve determinare quali misure sono in grado di prevenire o ridurre il rischio, quali sono i rischi connessi con le misure preventive proposte e quali sono l’efficacia e il costo di ciascuna misura preventiva.
L’analisi del rischio ci presenta il processo in negativo (ciò che si deve evitare) come il QFD ce lo presenta in positivo (cosa si deve fare). Sono l’una il necessario complemento dell’altro.
1.5
Il sistema delle informazioni
Il sistema delle informazioni è, per un processo, come il sistema nervoso per un organismo: raccoglie i dati prodotti dalle diverse attività, li elabora e ritrasmette le informazioni che derivano da tale elaborazione al sistema, come supporto per lo svolgimento di altre attività. (In questo caso per sistema di informazioni intendiamo sia le informazioni del processo che quelle relative al sistema di qualità).
E’ importante ricordare che la progettazione di un sistema di informazioni efficace deve cominciare dall’identificazione delle informazioni necessarie per svolgere le varie attività (approccio infologico) e non dall’identificazione dei dati prodotti dalle medesime attività (approccio datalogico).
Nella prima fase di creazione di questo sistema informativo, si deve definire con chiarezza il sistema di attività in cui deve essere messo a punto il sistema di informazioni. Il modo migliore per farlo è seguire il metodo di Checkland e Wilson. Esso comprende due parti:
1) formulare una Dichiarazione di Intenti (DI) che indica in generale i termini del sistema (“probesis fil obviat”);
2) formulare un modello concettuale delle attività che compongono il sistema cioè uno
schema di tutte le operazioni che devono essere svolte all’interno di un’azienda
nella situazione supposta.
Nella seconda fase si deve invece provvedere all’individuazione e messa a punto delle informazioni necessarie allo svolgimento delle attività del sistema. Questa operazione viene generalmente schematizzata in una tabella che riassume le varie attività con i relativi input cioè le informazioni necessarie alla loro esecuzione, gli output, cioè le informazioni prodotte in uscita, e gli obiettivi ovvero le attività che devono essere svolte dai direttori dei sistemi di qualità.
Nel 1980 Wilson propose un metodo grafico per rappresentare i sistemi informativi, chiamato croce di Malta, che può essere utile per non perdere di vista l’insieme delle informazioni e dei flussi in un sistema. In essa sono rappresentati i 4 elementi essenziali per la definizione di un sistema informativo:
- nel ramo nord sono elencate le attività (modello concettuale)
- nei rami est e ovest sono elencati i documenti informativi: il ramo ovest rappresenta le informazioni in entrata e il ramo est quelle in uscita di ogni attività. (quindi sono uno l’immagine speculare dell’altro);
- il ramo sud riporta i sistemi di elaborazione messi in atto per gestire i dati disponibili e ricavarne informazioni più significative.
Ponendo i dati nello schema, si generano quattro spazi quadrettati nei quali, con un simbolo, si possono riportare le indicazioni che descrivono i flussi di informazioni cioè quali sono di input o output delle varie attività.
La familiarità con l’uso di questo schema favorisce la pianificazione dei flussi rendendo molto chiaro e immediato chi deve produrre le informazioni e a chi deve trasmetterle.
1.6 La certificazione di qualità
1.6.1 Generalità
Come abbiamo visto, definire il concetto di qualità non è semplice, è legato alla personale concezione aziendale e prodotti che rispettano alti standard di qualità si ottengono solo in aziende caratterizzate da una stretta collaborazione fra i vari apparati.
La qualità va ricercata in tutte le fasi dei processi aziendali, in ogni singola parte del complesso organizzato, e nel comportamento di ogni addetto allo sviluppo e alla produzione.
Per esibire all’esterno dell’azienda un segnale che indichi che all’interno si opera seguendo un determinato iter per la produzione di prodotti di qualità, è necessario che la ditta consegua e poi mantenga una certificazione.
Il certificato di qualità è rilasciato da Società Organizzative esterne alle aziende, esse hanno la funzione di effettuare un controllo completo di tutto il sistema aziendale e alla fine dell’ispezione decidono se dare o meno tale certificazione.
Nel caso un’azienda riceva una certificazione di qualità, dovrà essere periodicamente monitorata dalle Società Organizzative allo scopo di mantenere costantemente alto il livello di qualità nelle aziende, e nel caso in cui il risultato di un controllo risultasse negativo, l’azienda dovrà provvedere a risolvere le proprie lacune organizzative in un certo lasso di tempo, altrimenti la certificazione diviene revocata.
All’interno di ogni azienda certificata esiste un manuale per la definizione del concetto aziendale di qualità e un manuale riguardanti le procedure specifiche delle fasi di lavorazione.
La qualità di un prodotto o di un servizio è rappresentata dalle caratteristiche che gli consentono di soddisfare le attese di chi lo utilizza. Non si può quindi individuare un livello "assoluto" di qualità: sono le esigenze degli utilizzatori a definire di volta in volta le caratteristiche che il prodotto o il servizio deve possedere per soddisfarli. Ecco quindi spiegata l’esistenza di un manuale aziendale (proprio per ogni azienda) per la definizione degli standard qualitativi su cui la produzione della stessa si posiziona.
Se per esempio a prima vista un'auto di grossa cilindrata appare qualitativamente superiore a una utilitaria, ciò non è in assoluto corretto. Se all'acquirente serve un veicolo dai bassi consumi, dalle dimensioni ridotte e di facile utilizzo in città, sarà l'utilitaria a soddisfarlo e quindi ad avere per lui una "qualità" superiore.
Il livello di qualità richiesto dal cliente deve poi essere raggiunto in modo non sporadico, ma costante nel tempo e per questo è necessario che siano coinvolte tutte le funzioni aziendali: è per questo motivo che si parla sempre più frequentemente di Garanzia della Qualità e di Sistemi Qualità.
La qualità non è un fatto solamente tecnico, ma ha aspetti organizzativi e gestionali e va a coinvolgere tutta l'azienda, compresa la direzione: questa deve avere in merito una precisa politica e ne deve curare l'attuazione, anche considerando lo stretto rapporto esistente tra qualità ed efficienza aziendale (e quindi profitto).
La Garanzia della Qualità è nata all'interno delle aziende manifatturiere allo scopo di evitare gli scarti dovuti a errori di lavorazione rilevati successivamente all'esecuzione delle fasi produttive: definire prima della produzione come effettuare la stessa, in questo modo si riduce al minimo la possibilità di errore, così come si riducono enormemente gli scarti e migliora l'efficienza aziendale.
La stessa logica applicata non solo alla produzione in senso stretto, ma a tutta la gestione aziendale secondo il principio di coinvolgimento definito sopra ha portato alla nascita ed alla diffusione di quelli che oggi sono conosciuti come Sistemi Qualità, che sono applicabili non solo alle aziende manifatturiere, ma anche a quelle di servizi.
Quando si parla di Sistema Qualità si intende l'insieme di risorse e comportamenti aziendali e di documenti che descrivono le attività che l'Azienda svolge, come tali attività vengono svolte, chi le tiene sotto controllo e chi ha l'autorità per influire sulla conduzione delle stesse.
Il Sistema Qualità aziendale è una realtà estremamente importante poiché è l'espressione del modo in cui l'azienda opera e tiene sotto controllo le attività svolte.
Descriverlo in documenti, affinché sia certificabile, costituisce il biglietto da visita dell'azienda verso il mondo esterno, il mezzo attraverso il quale essa dichiara, garantisce alla propria committenza che i suoi prodotti sono realizzati attraverso adeguati processi e risorse. Inoltre la documentazione del Sistema Qualità rappresenta uno strumento con il quale la realtà aziendale si confronta in continuo per conseguire un progressivo e certo miglioramento.
Adeguare un Sistema Qualità alle norme UNI EN ISO 9001-2-3 significa renderlo aderente ad un modello noto ed accettato in circa 96 paesi ed aderenti all'International Organization for Standardization (ISO); significa cioè:
• tradurre la propria organizzazione in un linguaggio comprensibile a moltissimi altri paesi;
• fare un'analisi critica del modo di operare di un'azienda scoprendone facilmente punti deboli e sacche di inefficienza, e quindi creando i presupposti per un miglioramento;
• rendere al cliente un'immagine trasparente e di azienda organizzata;
• disporre di un vantaggio competitivo nei confronti dei concorrenti;
• soddisfare a requisiti di legge quando sussistano;
• soprattutto, significa tenere sotto controllo il sistema che, spostando a monte l'individuazione dei possibili errori, anziché ritrovarli come reclamo sul prodotto finito.
La descrizione del Sistema Qualità avviene tradizionalmente attraverso una serie di documenti che hanno differente gerarchia e sono anche diversamente identificati in ambito aziendale:
• il manuale della qualità, il cui scopo è quello di dimostrare come il Sistema Qualità aziendale risponda alla norma;
• le procedure, che hanno lo scopo di descrivere che cosa deve essere fatto e da chi, quando, dove e come e perciò si riferiscono a singoli processi od attività;
• le istruzioni (o metodologie) di lavoro, che dettagliano il modo specifico di condurre un'attività.
L'Azienda che ha formalizzato il proprio Sistema Qualità, cioè l'ha descritto in un manuale, in una serie di procedure e metodologie, da tutto questo lavoro deve trarre utilità. Come?
Applicandolo con continuità il proprio Sistema Qualità, il quale, sia nelle sue componenti che nel suo complesso, deve essere considerato un macro processo, che deve essere controllato attraverso un anello di regolazione chiuso, come qualsiasi parametro elettrico o meccanico.
Facciamo un esempio: consideriamo un'automobile che percorra una strada a velocità costante. Se avviene una perturbazione sul carico (salita o discesa, vento contrario o a favore), l'auto tenderà a rallentare od accelerare.
L'automobile devia dalla velocità prefissata così come un'organizzazione aziendale, che ha predisposto una procedura per sviluppare un certo processo attraverso il quale si ritiene di conseguire determinati risultati, non è più in grado di eseguire tale procedura per i motivi più diversi: trascuratezza del personale, eccessivo carico di lavoro, ferie, complessità del processo o dei documenti che non sono stati adeguatamente compresi ecc. Se la procedura non viene seguita, i risultati del processo possono essere imprevedibili.
Nei due casi illustrati, si è in presenza di un anello di regolazione "aperto" in cui un parametro viene prefissato, ma non se ne verifica il comportamento. Si consideri ora il sistema di regolazione a cui tende il Sistema Qualità: un anello di regolazione "chiuso".
In questo sistema i risultati, i parametri in uscita, vengono misurati continuamente o periodicamente e confrontati con quelli attesi e l'errore, opportunamente rielaborato, consente di correggere nel senso desiderato il valore dei parametri in uscita.
Se il guidatore dell'automobile presa come esempio tiene sotto controllo il tachimetro ed interviene sull'acceleratore in funzione delle variazioni della velocità, egli riporta la velocità al valore prestabilito. In campo aziendale, affinché il risultato di un processo non sia difforme da quanto desiderato, occorre che sistematicamente si faccia una campionatura sui risultati ottenuti, si confrontino con quelli pianificati (riesame) e si intervenga sul sistema (azioni correttive) per portare il processo a fornire i risultati attesi.
Il sistema così monitorato è sotto controllo.
La dicitura ISO 9000 indica la normativa internazionale in edizione originale. In Italia, la traduzione ufficiale della normativa è individuata con la sigla UNI EN ISO 9000.
I significati della sigla sono i seguenti.
UNI (Ente Nazionale Italiano di Unificazione) è l'associazione italiana dotata di riconoscimento giuridico che, ai sensi della direttiva CEE 83/189 del 28/03/83 e recepita in Italia con la legge 21/6/86 n. 317 rappresenta nel settore normativo l'Italia a livello comunitario. L'associazione è stata fondata nel 1921 con il nome di UNIM allo scopo di costituire archivi di norme nazionali ed estere, oltre che ad elaborarle e diffonderle.
EN (Norme Europee) sono le norme emesse o approvate dal Comitato Europeo di Normazione - CEN - cui aderiscono 18 paesi membri della CEE e dell'EFTA. Il CEN ha lo scopo di promuovere le norme internazionali (ISO) e di armonizzare le norme su scala europea per facilitare lo sviluppo degli scambi dei prodotti e dei servizi eliminando gli ostacoli creati da requisiti di natura tecnica.
ISO, International Standard Organization, ha per scopo la promozione della normazione nel mondo. E' stata fondata a Londra nel 1947 e ad essa aderiscono gli enti normatori di 96 paesi. Ai lavori ISO prendono parte ogni anno oltre 20.000 tecnici di tutto il mondo, organizzati in 164 comitati tecnici, 648 sottocomitati, 1606 gruppi di lavoro e 26 gruppi di studio ad hoc.
9000 numero convenzionale di riferimento. Le norme della serie ISO 9000 sono divise in quattro gruppi: di questi quattro gruppi, le norme che costituiscono modello per l'assicurazione qualità e di cui si può richiedere la certificazione sono solamente la 9001, la 9002 e la 9003.
I quattro gruppi sono:
1. criteri di scelta, ISO 9000-1 - Norme di gestione per la qualità e di assicurazione della qualità - guida per la scelta e l'utilizzazione -;
2. assicurazione della qualità ISO 9001 - Sistemi Qualità - modello per l'assicurazione della qualità nella progettazione, sviluppo, fabbricazione, installazione ed assistenza -, ISO 9002 - Sistemi Qualità - modello per l'assicurazione della qualità nella fabbricazione, installazione ed assistenza -, ISO 9003 - Sistemi Qualità - modello per l'assicurazione della qualità nelle prove, controlli e collaudi finali -;
3. guida generale ISO 9004-1 - Gestione per la qualità ed elementi del Sistema Qualità guida generale -;
4. guide per l'applicazione in settori specifici ISO 9000-2 "Norme di gestione per la qualità e di assicurazione della qualità - guida generale per l'applicazione delle ISO 9001,9002,9003" , ISO 9000-3 "Norme di gestione per la qualità e di assicurazione della qualità - guida generale per l'applicazione delle ISO 9001 allo sviluppo, alla fornitura e alla manutenzione del software" ISO 9000-4 "Norme di gestione per la qualità e di assicurazione della qualità - guida per la gestione del programma della fidatezza", ISO 9004-2 "Gestione per la qualità ed elementi del Sistema Qualità - guida per i servizi", ISO 9004-3 "Gestione per la qualità ed elementi del sistema qualità - guida per i materiali da processo continuo", ISO 9004-4 "Gestione per la qualità ed elementi del sistema qualità - guida per il miglioramento della qualità".
Sempre più spesso oggi si sente parlare di "certificazione di qualità", ma esiste ancora molta confusione su questo argomento.
Cosa vuol dire "certificazione di qualità"?
Il prodotto di una società certificata è migliore di quello di una società non certificata?
È obbligatorio per legge certificarsi?
Vale la pena spendere qualche parola per dare risposta a queste domande che sempre più spesso chi lavora nel settore si sente porre.
Prima di tutto: cosa vuol dire certificazione? Il termine "certificare" deriva dal latino certum facere, che significa "rendere certo, evidente". La certificazione è la dichiarazione di un ente terzo (cioè non legato al fornitore o all'acquirente) che il prodotto fornito o il sistema qualità dell'azienda fornitrice sono conformi ad una certa normativa.
Nel caso del Sistema Qualità le norme di riferimento sono quelle della famiglia delle ISO 9000 recepite in Italia come UNI EN ISO 9000.
Impostando la propria attività secondo i criteri indicati nelle norme di riferimento, le aziende possono ragionevolmente assicurare ai clienti che i propri prodotti o servizi raggiungono un determinato livello di qualità e soprattutto sono in grado di mantenerlo nel tempo, con un serio e soprattutto costante impegno al miglioramento ed al rilevamento delle esigenze del cliente.
Il timore delle piccole e medie imprese è che recepire le norme ISO 9000 significhi appesantire con inutili procedure formali una struttura aziendale la cui competitività è basata su caratteristiche di flessibilità e agilità. In realtà un corretto approccio alla norma permette di instaurare un Sistema Qualità efficiente anche in piccole realtà aziendali.
La scelta di ottenere la certificazione del Sistema Qualità di una azienda è sicuramente nella giusta prospettiva rispetto allo sviluppo presente e futuro del mercato nazionale ed estero, perché oltre a costituire un elemento di forte distinzione assicura alle aziende di non essere escluse dai circuiti produttivi delle grandi aziende.
La certificazione ovvero la conformità alla ISO 9000 è come la licenza di caccia: averla non garantisce di riempire il carniere, ma è solo la prequalificazione che permette di partecipare alla competizione.
La certificazione attesta che un prodotto, un processo o un servizio è conforme ad una specifica norma o ad un documento normativo. In seguito alla avvenuta certificazione viene rilasciato un certificato e il diritto d'uso di un marchio.
La certificazione dei Sistemi Qualità viene attuata da appositi organismi che verificano la sussistenza delle caratteristiche del Sistema Qualità dell'azienda, applicando uno schema di certificazione adatto al settore produttivo considerato.
1.6.2 Una visione storica
In questo paragrafo viene proposta una visione storica delle norme internazionali sui sistemi di garanzia della qualità.
Alla fine degli anni ’70, all’interno della Organizzazione Internazionale per la Standardizzazione, ISO, venne fondato il Comitato Tecnico 176 Quality Assurance. L’opera di questo comitato mirava all’unificazione delle norme nazionali e settoriali di tutti i paesi riguardanti i sistemi di garanzia della qualità. Si intendeva soprattutto limitare la molteplicità di tutte le combinazioni possibili tramite la definizione di tre livelli di verifica, nel caso in cui si dovesse dimostrare la conformità di determinati elementi specificati contrattualmente. Inoltre l’ISO si assume il compito di elaborare principi sulla garanzia della qualità sotto forma di norme internazionali.
Dalla fine del 1986 sono state messe a punto già 5 norme internazionali, alla cui elaborazione la DIN ha partecipato nonostante lo scarso appoggio fornito dalla RFT. Nel corso dell’elaborazione, l’atteggiamento di numerose imprese e organizzazioni industriali, in un primo tempo negativo, si è modificato completamente.
La normalizzazione DIN non fu appoggiata a sufficienza, però la notevole dipendenza della RFT della esportazioni fece si che l’importanza di una standardizzazione a livello mondiale e i suoi effetti di razionalizzazione e di risparmio fossero riconosciuti. Anche se in importanti settori continuavano ad esistere notevoli dubbi sull’applicazione corretta di tali norme e timori di natura giuridica, nella fase finale delle consultazioni internazionali ci si impegnò soprattutto per un miglioramento tecnico delle norme.
Il Comitato della garanzia di qualità e di statistica applicata della DIN ha infine accettato di inserire le Norme Internazionali nelle Norme della RFT come Norme DIN ISO:
DIN ISO 9000 Criteri di scelta e di utilizzazione delle norme per il management della qualità, degli
elementi di un sistema di garanzia della qualità e dei gradi di verifica della garanzia della qualità.
Questa norma dà indicazioni sull’applicazione delle norme 20 DIN ISO 9001 fino a 9004.
DIN ISO 9001 Sistemi di garanzia della qualità e elementi di un sistema di garanzia della qualità:
criteri.
Questa norma contiene indicazioni pratiche e generali sulla garanzia della qualità, sull’istruzione e sul mantenimento di un sistema di garanzia della qualità adeguato al tipo di prodotto, al fine di ottenere un elevato livello quantitativo e soddisfare le aspettative degli acquirenti.
DIN ISO 9001 Sistemi di garanzia della qualità; grado di verifica della garanzia della qualità per
progettazione e costruzione ,produzione, montaggio e assistenza;
DIN ISO 9002 Sistemi di garanzia della qualità; grado di verifica della garanzia della qualità per
progettazione e montaggio;
DIN ISO 9003 Sistemi di garanzia della qualità; grado di verifica della garanzia della qualità per i
controlli finali.
Queste norme contengono requisiti di verifica della garanzia della qualità graduati in tre livelli. Tali requisiti riguardano misure di garanzia della qualità, vale a dire del management, della pianificazione, del controllo e del collaudo della qualità e non vanno confusi con i requisiti di qualità del prodotto stesso. E’ necessario dimostrare che tali misure sono state adottate.
Il committente o una norma di Legge possono stabilire un requisito di verifica della garanzia della qualità, in un determinato grado di verifica, requisito sancito da un contratto per la fornitura di un bene o di un servizio. L’esperienza acquisita nel corso degli anni a livello mondiale ha dimostrato che tre gradi di misura sono sufficienti. Queste tre norme costituiscono contemporaneamente la base per determinare l’entità della verifica da concordare contrattualmente nei singoli casi, cioè gli elementi inclusi nei requisiti di verifica del sistema di garanzia della qualità, e per stabilire il grado di accuratezza della verifica.
DIN ISO 9001 trova applicazione in situazioni contrattuali in cui:
- il contratto prevede specificatamente un impegno di progettazione ed i requisiti per il prodotto sono espressi soprattutto in termini di prestazioni e richiedono di essere definiti e
- quando la fiducia nella conformità del prodotto richiede adeguata dimostrazione sulla capacità del fornitore ad eseguire progettazione, costruzione, fabbricazione, installazione e assistenza.
DIN ISO 9002 trova applicazione in situazioni contrattuali in cui:
- i requisiti specifici per il prodotto sono espressi in forma di un progetto o di una specifica definita e quando la fiducia nella conformità del prodotto richiede adeguata dimostrazione circa determinate capacità del fornitore di eseguire fabbricazione e installazione.
DIN ISO 9003 trova applicazione in situazioni contrattuali in cui:
- la conformità del prodotto ai requisiti specificati può essere comprovata con sufficiente affidabilità, e la capacità del fornitore può essere provata in modo soddisfacente mediante prove, controlli e collaudi sul prodotto fornito.
In breve elenchiamo alcuni elementi della garanzia della qualità, che devono essere provati in base a DIN ISO 9001 in un contratto sulla fornitura di un prodotto complesso, ancora da progettare (una verifica in base a DIN ISO 9003 riguarda invece soltanto alcuni degli elementi elencati, cioè quelli di particolare importanza per regolari controlli finali sul prodotti finito):
- definizione della politica della qualità da parte della direzione dell’impresa
- definizione delle competenze (responsabilità e autorità), dei mezzi e del personale addetto all’attività di verifica, designazione di un rappresentante della direzione che assicuri che le prescrizioni delle norme sono applicate
- verifica del sistema di garanzia della qualità da parte della direzione
- istituzione di un sistema documentato di garanzia della qualità
- garanzia della qualità nella fase di progettazione (pianificazione di progettazione e di sviluppo, assegnazione delle attività, interfacce organizzative e tecniche, dati e requisiti, risultati e controllo della progettazione, modifiche alla progettazione)
- controllo della documentazione
- garanzia della qualità nell’approvvigionamento (valutazione dei subfornitori, documenti di acquisto, verifica del prodotto acquistato)
- prodotti forniti dal committente
- identificazione e rintracciabilità del prodotto
- controllo del prodotto di produzione
- prove e collaudi (al ricevimento, durante il processo produttivo, finali; documenti di registrazione relativi)
- controllo delle apparecchiature di controllo, misura e collaudo
- trattamento delle unità non conformi
- azioni correttive
- controllo di movimentazione, immagazzinamento, imballaggio e distribuzione del prodotto
- documenti di registrazione della qualità
- verifiche ispettive interne della qualità
- addestramento
- assistenza
- tecniche statistiche.
Capitolo 2
Il software: processo e prodotto
2.1 Il software: da arte ad artigianato ad industria
L’informatica, scienza per la gestione automatica dell’informazione, è disciplina recente; nasce infatti durate la seconda guerra mondiale sulla spinta dell’esigenza di automatizzare alcune attività di tipo bellico. Le prime applicazioni computerizzate sono state automazioni di procedimenti ripetitivi di calcolo di precisione difficilmente eseguibili manualmente dall’uomo senza incorrere in errore.
I primi utenti dei computer, veri pionieri in questo campo, sono stati matematici, fisici, chimici, ingegneri che richiedevano alla macchina una potenza di calcolo per le proprie applicazioni (i problemi tipici erano risoluzioni di sistemi di equazioni, problemi di calcolo numerico, …).
In questa fase iniziale di utilizzo degli elaboratori elettronici, le caratteristiche principali delle attività svolte erano le seguenti:
- gli strumenti di programmazione sono molti semplici (linguaggi di programmazione a baso livello);
- chi sviluppa il software deve essere un tecnico, con una cultura di tipo matematico, che lo mette in grado di interagire in modo preciso, rigoroso e formalizzato con una macchina povera di strumenti atti all’interazione con la stessa;
- non è necessario che l’applicazione realizzata venga utilizzata a lungo, per tante volte e da utenti diversi dallo stesso sviluppatore.
Questa situazione iniziale si evolve però molto in fretta, sulla spinta delle nuove realizzazioni nel campo dell’hardware e delle esigenze di grosse fette di mercato, nascono i primi gestionali, programmi al servizio di grosse aziende le quali hanno una forte necessità di gestione automatizzata dei propri dati. Il calcolatore, da puro strumento di calcolo, diventa una macchina per la memorizzazione, modificazione e distribuzione di dati correlati fra loro i quali divengono informazione preziosa per le strategie e l’organizzazione aziendali. I campi di utilizzo sono i più svariati, dalla gestione del personale o della produzione, alle informazioni di tipo bancario.
Visto il cambiamento radicale della situazione, le caratteristiche iniziali relative alla produzione del software si modificano radicalmente:
- chi fruisce del programma software non è più il produttore del software, il quale diventa la persona che deve costruire e mantenere programmi i quali sono poi utilizzati da altri,
- le applicazioni che vengono realizzate divengono via via strumenti critici di lavoro, di dimensioni ragguardevoli, che necessitano di un’opera continua di controllo e manutenzione;
- vengono messi a disposizione dei programmatori dei linguaggi di programmazione a più alto livello dei linguaggi iniziali, i quali permettono una scrittura più agevole del codice, vengono inoltre costruiti degli ambienti di sviluppo che agevolano la produzione del software; tutto questo mette il programmatore in grado di affrontare problematiche di maggiore complessità;
- la produzione del software avviene nelle divisioni di sviluppo software delle grosse aziende o grosse società di servizi (centri EDP), oppure nelle software house, aziende di produzione software per il mercato;
- la produzione del software non è più un’arte lasciata all’abilità ed all’ingegno di pochissimi, ma diventa artigianato che coinvolge piccoli gruppi di lavoro specializzati, spesso di alto livello professionale.
A partire da quest’ultimo periodo, anni 50, ad oggi, la situazione si è ulteriormente evoluta, mantenendo però alcune caratteristiche costanti: la diffusione delle applicazioni software è andata crescendo a dismisura in quantità e sono aumentati anche i settori influenzati da questa disciplina, allo stesso tempo sono diventate più rilevanti la complessità, la criticità e quindi la qualità richiesta al prodotto software con evidente difficoltà da parte di chi sviluppa il software.
I produttori software iniziano pertanto una riflessione su temi cruciali quali la produttività delle loro aziende, l’organizzazione del processo di produzione, la qualità del software rilasciato. Temi di estrema importanza per un’azienda che intende porsi in modo serio, stabile e competitivo sul mercato.
Da queste riflessioni nasce l’esigenza che la produzione del software venga vista organizzata come un’industria, dove il lavoro deve essere pianificato e coordinato secondo metodologie prestabilite ed accettate, sempre più coadiuvato da strumenti automatici di supporto alla produzione.
Le necessità di base possono essere sintetizzate nelle seguenti linee guida:
- il prodotto software rilasciato all’utente deve soddisfarne le aspettative e deve essere certificato in modo convincente;
- la produzione deve avvenire secondo metodologie efficaci, collaudate ed accettate in modo da supportare elevati standard di produzione ed assorbire le difficoltà dovute al ricambio di personale;
- la metodologia di produzione software adottata deve permettere la suddivisione di lavori complessi in sottoprogetti ed il relativo assembramento degli stessi, in modo da poter dominare la complessità via via crescente.
Nella seconda metà degli anni ’60 venne concepita tale necessità di evoluzione del software. Infatti nel ’68 in una celebre conferenza NATO si coniò per prima volta la parola “Ingegneria del Software” per testimoniare in modo decisivo come questa disciplina dovesse diventare una disciplina ingegneristica, basata su solide basi teoriche e metodologiche in modo da permettere la progettazione, la produzione e manutenzione, mediante l’uso di risorse previste, di applicazioni che forniscano ben definite caratteristiche di qualità.
Purtroppo anche ai giorni nostri la situazione non è radicalmente cambiata, solo i contorni principali della disciplina cominciano ad emergere, e la motivazione principale del ritardo in questo sviluppo è da ricercarsi nel fatto che la produzione software, oltre ad essere un’attività decisamente complessa e sempre in evoluzione, è un’attività particolarmente recente, soprattutto in confronto alle altre discipline ingegneristiche.
Dal punto di vista economico accanto alla domanda esplicita di software esiste un fenomeno importante che è la “domanda nascosta e inevasa” (il “backlog”), in altre parole si tratta dei ritardi che si manifestano tra il momento nel quale sorge la richiesta di un’applicazione ed il momento nel quale tale richiesta può essere soddisfatta. Tali ritardo hanno attualmente un ordine di grandezza misurabile in anni. Questi ritardi sono dovuti principalmente alla carenza di personale specializzato. Programmatori non esperti sono la causa di cattivo software che una volta immesso sul mercato richiede una notevole sforzo per la manutenzione, causando un’ulteriore carenza di personale. Si tratta di una spirale perversa. Questo è particolarmente evidente se lo si confronta con quanto avviene nel settore dell’hardware, dove le prestazioni sono andate progressivamente migliorando e dove i costi sono andati progressivamente diminuendo, addirittura molto più che in altre industrie manifatturiere.
La motivazione di fondo risiede nel fatto che la produzione di software resta prevalentemente un’attività di tipo intellettuale, scarsamente automatizzata. Si tratta, intrinsecamente, di un’attività in cui è prevalente l’aspetto di progettazione (difficilmente automatizzabile), mentre la componente manifatturiera di confezione del prodotto (parte automatizzabile) risulta del tutto marginale.
Il motivo essenziale è quello della complessità. A parità di dimensione, la complessità per capire, descrivere e progettare un frammento di software è di gran lunga superiore a quella corrispondente per qualunque altro prodotto, con crescita esponenziale della difficoltà di dominio della complessità non appena questa cresce anche di poco. A queste difficoltà di base si aggiungono anche quelle dovute ad approcci inadeguati, non fondati su metodologie rigorose ed accettate, che rendono l’affidabilità del software bassa rispetto a quella che applicazioni sempre più complesse e critiche richiedono.
Perfino definire in termini quantitativi la produttività media di una persona che produce codice software può essere particolarmente difficile. L’unità di misura numero di linee di codice per giorno non è ufficialmente riconosciuta e soprattutto due misurazioni effettuate su tipi di codice diversi spesso non sono confrontabili.
L’ingegneria del Software è quindi un insieme di teorie, metodi, strumenti, che consentono di produrre e mantenere applicazioni con le desiderate caratteristiche di qualità.
Il suo obiettivo è quello di mettere in grado lo specialista di affrontare la complessità dei grossi progetti gestendo in modo produttivo le risorse, specie quelle umane, e sviluppando prodotti che rispecchino le caratteristiche desiderate di qualità entro i vincoli economici e di tempo specificati.
Come accade per ogni altro prodotto, il software viene sviluppato percorrendo un determinato processo produttivo, la cui struttura può avere una forte influenza sulla qualità del prodotto finale.
Rispetto ad altri processi produttivi, la produzione del software ha alcune particolarità, fra queste la difficile determinazione della fine di tale processo, il codice è infatti un prodotto ad elevata evoluzione. Il software per avere una veloce e facile evoluzione deve avere una buona malleabilità, cioè deve essere possibile mediante poche modifiche cambiare significativamente il programma, senza introdurre con le modifiche errori pericolosi.
2.2 Fattori di qualità del software
Come abbiamo visto nel primo capitolo, ogni bene che viene prodotto ha le sue caratteristiche, ed abbiamo tentato di chiarire il concetto di qualità per un bene in senso lato. Cerchiamo ora di chiarire quali sono i fattori di qualità di un prodotto software, le proprietà che esso deve poter garantire.
2.2.1 Affidabilità
Ovvero le funzionalità che ci vengono offerte, corrispondono ai requisiti, e tutte le operazioni eseguite (elaborazione, calcolo, ecc…) producono gli effetti voluti.
2.2.2 Correttezza
Ovvero data una definizione di requisiti che il SW deve soddisfare, questo si definisce corretto se i requisiti sono rispettati, viceversa viene definito scorretto se esiste una forma di malfunzionamento. Ma è importante tenere conto del fatto che non necessariamente se un SW è corretto, lo si può ritenere anche affidabile. Infatti, l’attributo di correttezza viene definito con riferimento a ciò che viene specificato come requisito, ma purtroppo non sempre i requisiti specificano con precisione tutto quello che si ritiene importante.
2.2.3 Robustezza e Sicurezza
Ovvero data una serie di anomalie non previste dai requisiti, il SW si comporta in modo accettabile.Il SW robusto viene anche suddiviso in alcune categorie:viene utilizzato il termine sicurezza quando si parla di sistemi di accesso a informazioni private o protette (grossa enfasi è data a questo fattore negli ultimi tempi per due motivi: la grossa diffusione delle reti e la nuova legge sulla privacy), oppure il termine innocuità in riferimento a sistemi che possono essere critici e pericolosi anche per la vita dell’uomo.Caratteristica comune delle proprietà di sicurezza e innocuità è quella di essere esprimibili come proprietà negative. In entrambi i casi, infatti, ciò che occorre garantire è che il sistema non entri mai in certi stati.
2.2.4 Prestazioni
Ovvero quando un sistema utilizza in modo efficiente le sue risorse (tempo di esecuzione, memoria occupata, ecc…). esistono diversi metodi per valutare le prestazioni di un programma.
Un metodo è quello della teoria della complessità di calcolo, che permette di rilevare e verificare le prestazioni nel caso medio e nel caso peggiore, in termini asintotici rispetto ad alcune grandezze tipiche del programma in esame. E’ ben noto che nel caso peggiore, detta n la lunghezza della sequenza, un algoritmo che scandisce la sequenza in maniera sequenziale ha un andamento asintotico che risulta dell’ordine di n, mentre un algoritmo che esegue una ricerca di tipo binario ha un andamento asintotico dell’ordine di log(n).
Esistono altri modi per valutare le prestazioni di un sistema: un modo consiste nel misurare, mediante appositi strumenti software, il tempo d’esecuzione o l’occupazione di memoria durante esecuzioni-campione del programma, un altro modo consiste nell’effettuare tali misure non mediante esecuzioni reali, ma in ambienti simulati.
Un altro modo ancora consiste nel costruire un modello del sistema sotto esame e nel dedurre le prestazioni operando in maniera analitica sul modello.
2.2.5 Usabilità
Ovvero è previsto che esita un interfaccia-utente “amichevole”, che permetta a colui che utilizza l’applicazione, di lavorare con più semplicità possibile.Ad esempio sono considerate interfacce di tipo grafico i dispositivi di puntamento (mouse), le icone ecc…
E’ comunque indispensabile ricordare che la praticità di una applicazione, non deve limitarsi a fornire elementari gadget grafici, ma deve essere ottenuta facendo in modo che l’utente si trovi costantemente a proprio agio nell’usare l’applicazione stessa. Inoltre è indispensabile la presenza di guide in linea, che illustrino come operare in caso di difficoltà.
La caratteristica d’usabilità è tipica del prodotto più che del processo; essa è inoltre una tipica caratteristica di qualità esterna.
Ovviamente, questa caratteristica di qualità è tanto più rivelante quanto più l’utente previsto per l’uso dell’applicazione è digiuno d’informatica, e deve quindi poter usare l’applicazione senza essere costretto ad imparare termini e concetti a lui estranei.
E’ bene però che questa caratteristica di qualità sia tenuta in considerazione anche nel caso d’applicazioni rivolte ad esperti d’informatica.
2.2.6 Verificabilità
Ovvero deve essere agevole verificare quale sia lo stato di avanzamento di un certo progetto, controllando quanto l’uso delle risorse finanziarie si scosti rispetto alle previsioni iniziali. La verificabilità è una caratteristica sia del processo che del prodotto.
La verificabilità è evidentemente una caratteristica sia del processo che del prodotto.
L’esempio forse più importante di verificabilità del prodotto è quello che permette di valutare in quale misura le funzionalità offerte corrispondono a quelle specificate, come la voce correttezza.
Come esempio ulteriore si consideri invece la facilità con la quale è possibile analizzare quanto i programmatori seguano certi standard previsti di codifica.
2.2.7 Manutenibilità
Ovvero la facilità con cui vengono eseguite le attività che seguono temporalmente il rilascio di un’applicazione, e l’economicità dei relativi processi, queste attività infaati si stimano pesare mediamente più del 50% dei costi complessivi di un’applicazione.
Nei settori tradizionali la manutenibilità è un fenomeno dovuto all’usura e all’affaticamento dei materiali che costituiscono il prodotto; ma, paradossalmente, usura ed affaticamento sono fenomeni del tutto assenti nel software: un’applicazione non si deteriora per il solo fatto di essere eseguita più volte.
E’ possibile classificare le attività di post-rilascio in tre categorie.
La manutenzione correttiva è quella che consiste nell’intervento sull'applicazione che tende ad eliminare gli errori residui, che sono sfuggiti al controllo di qualità che precede il rilascio.
La manutenzione adattativa consiste nelle modifiche a cui l’applicazione deve essere sottoposta per renderla adattabile a cambiamenti nell’ambiente in cui l’applicazione stessa è chiamata ad operare.
La manutenzione perfettiva consiste in ogni restante tipo d’intervento, nell’aggiunta di nuove funzionalità, nell’eliminazione di funzionalità inutili e nel miglioramento d’alcune caratteristiche di qualità.
2.2.8 Riusabilità
Ovvero la possibilità che un’applicazione non venga sviluppata partendo ex-novo, ma impiegando componenti esistenti che vengono assemblati, eventualmente dopo qualche modifica locale. Facendo uso di componenti riusabili standard affidabili, non solo i nuovi sviluppi avvengono a costi più bassi, ma anche la relativa affidabilità è più elevata.
L’obiettivo di ottenere un’elevata riusabilità è tutt’ora più un desiderio che una realtà nel campo del software; di ciò è testimonianza la quantità di investimenti di ricerca e sviluppo industriali che sino ad oggi stanziati per contribuire a un avanzamento delle conoscenze e delle tecnologie in questo settore.
2.2.9 Comprensibilità
La comprensibilità è una qualità che soggiace a molte delle caratteristiche che vengono qui discusse: è fondamentale che il software prodotto sia comprensibile ai fini di poterne garantire la correttezza, di poter facilmente apportare modifiche e di poterlo riusare.
Il progettista deve poter comprendere chiaramente quali sono i requisiti dell’applicazione prima di iniziarne il progetto, e l’architettura di progetto deve essere compresa chiaramente per poter essere implementata correttamente.
Per ottenere la comprensibilità del processo, occorre che questo sia visibile o trasparente.
Ciò significa che le regole del comportamento organizzativo e gestionale devono essere assolutamente chiare, in modo che le persone possono essere responsabilizzate al massimo per l’ottenimento degli obiettivi complessivi del processo.
Un principio fondamentale che favorisce la comprensibilità di un prodotto è quello di modularità.
Un sistema è modulare se è diviso in parti che hanno una sostanziale autonomia individuale e una ridotta interazione con le altre parti, e che possono essere comprese separatamente le une dalle altre.
La comprensibilità diventa massima se i singoli componenti non hanno alcuna interrelazione: ognuno costituisce un’entità autonoma e logicamente separata da ogni altra entità; correlato è il principio dell’astrazione, con ciò s’intende che ciascun componente del sistema modulare può essere caratterizzato astraendo da alcuni dettagli che risultano irrilevanti al fine di comprendere gli altri componenti che fanno parte del sistema.
2.2.10 Interoperabilità
Ovvero il riuso dei programmi, in quanto viene favorita la componibilità con altre applicazioni. La facile componibilità dei programmi favorisce la scrittura di programmi di dimensioni limitate, che sono intrinsecamente caratterizzati da una maggiore facilità di comprensione e maggiore affidabilità.
Con questo termine s’intende caratterizzare un’applicazione che può facilmente integrarsi con altre, al fine di svolgere un compito più complesso e integrato.
Un caso d’interoperabilità è offerto da uno strumento di video-scrittura che può facilmente ed efficacemente integrarsi con uno strumento per la gestione di basi di dati.
2.2.11 Produttività
La produttività nello sviluppo del software è difficile da caratterizzare e misurare; a tutt’oggi, essa viene usualmente definita in termini del numero di linee del codice prodotte per unità di tempo, per esempio facendo riferimento ai giorni.
E’ stato rilevato che la produttività delle persone è soggetta a una larga varianza, che dipende sia dall’area applicativa nella quale si opera, che dalla capacità dei singoli individui.
La caratteristica di produttività è considerato un caso particolare della categoria “Prestazioni” delle caratteristiche di qualità, qualora si faccia riferimento al processo di produzione del SW.
2.3 Il processo di produzione del software
Il prodotto o meglio il pacchetto deve essere messo sul mercato con la massima soddisfazione degli utenti, in tempi e costi controllati; per ottenere, almeno in parte questo obiettivo, viene seguito il processo di produzione qui di seguito descritto..
Lo studio di fattibilità è il primo passo e viene eseguito per controllare a priori i costi di realizzazione, un’analisi molto superficiale ma molto importante, insomma un “preventivo per lo sviluppo del futuro pacchetto software.
Questa fase varia molto da caso a caso soprattutto per alcune ed inevitabili specificità che incontra ogni pacchetto come del resto sono le innumerevoli e diverse richieste di un utente che richiede un prodotto software. In questa fase si analizzano gli eventuali prodotti analoghi già presenti sul mercato confrontandoli con un’ alternativa di sviluppo da zero o con pezzi di codice-prodotto già operativo e valido per diverse operazioni. Si tenta inoltre di riuscire già in qualche modo a carpire i bisogni dell’utente in questione anche se l’analisi vera e propria di tutto il “problema” verrà svolta solo in seguito, e soprattutto sarà molto più dettagliata e curata nei minimi aspetti.
Il contratto di lavoro tra committente e produttore in genere arriva prima di disporre le risorse in campo da parte del produttore: molte volte succede anche che tra utente e produttori ci sia un gioco al ribasso in termini di lavoro umano, tempo e denaro facendo così fallire molti progetti (può accadere ed è accaduto molte volte).
Dopo aver eseguito un accurato studio di fattibilità entra in gioco una componente particolarmente importante, è l’acquisizione dei requisiti funzionali ovvero una analisi specifica dei requisiti che sono stati richiesti dal committente e che dovranno poi risultare nel prodotto finale.
In altre parole esso serve per definire correttamente ed in maniera più chiara ed esaustiva possibile quali sono le necessità dell’ utente pretende dal software fornito dal produttore, pertanto deve essere quanto il più preciso, consistente e completo possibile.
La fase successiva è l’analisi vera e propria atta a comprendere come dovrà essere implementato il prodotto da coloro che poi scriveranno il codice. Il progettista deve essere lasciato poi libero di agire secondo le sue capacità di interpretazione dell’analisi in modo tale che possa effettuare le scelte che riterrà più opportune per i due livelli del software:
- il livello esterno che è il risultato finale, ciò che vede l’utente ed
- il livello interno ovvero il codice, il risultato finale che implementa il progettista.
Dopo l’analisi, finalmente si può incominciare a pensare al codice vero e proprio, a come viene sviluppato in termini di scrittura l’intero pacchetto cercando di farlo evolvere secondo le direttive aziendali, in particolare deve essere sia affidabile che scritto in modo da essere facilmente correggibile in caso di errori o imprevisti.
Il risultato di tutto questo si trova nel documento di specifiche di progetto che contiene la descrizione dell’architettura software realizzata con opportuni linguaggi di specifica di progetto e mediante una sintassi grafica o testuale.
Ultimata la scrittura del software è necessario compiere degli specifici test.
Il prodotto può essere soggetto a due particolari test: alfa test e beta test.
Con il primo si intende che il prodotto è “rilasciato” ma solo all’interno della casa produttrice di software per consentire un collaudo accurato, molto puntiglioso e soprattutto controllato, in tutta sicurezza; con il secondo si intende far collaudare a pochi utenti vicini alla casa e far “provare” loro il software non ancora rilasciato per ricavarne indicazioni più o meno positive sul prodotto appena ultimato con la possibilità inoltre di avere informazioni su un possibile impatto con il mercato.
Se si presentano degli errori nel prodotto ovviamente bisogna intervenire con una manutenzione complessiva sugli errori. Purtroppo in un ciclo di vita di un software i passaggi sono a cascata uno dietro l’altro e perciò risulta difficile tornare sui propri passi per cui le case produttrici si sono adoperate in modo da non rivedere da capo il codice (talvolta è molto difficile individuare l’errore presente in una parte di codice) ma organizzando un sistema di recupero del software: così facendo il prodotto viene implementato con parti di codice in cui non si rivelano errori quindi con questo sistema molte righe di codice vengono risparmiate al progettista, guadagnando tempo utile e con la sicurezza assoluta che in quelle righe di codice non ci sono eventuali errori aumentando così in modo vertiginoso l’affidabilità del pacchetto software.
Ci possono essere inoltre degli errori dovuti ad incomprensioni tra utente e produttore, questi sono tanto più frequenti quanto più frequentemente il committente cambia idea sui requisiti che deve avere il prodotto finale oppure non ha le idee chiare sulle specifiche funzionalità che deve avere il software da lui richiesto, oppure se il produttore software ha una scarsa conoscenza della problematica che il software sarà tenuto a gestire. Tutti questi casi se non sono risolti nel minor tempo possibile possono portare a gravi perdite per l’azienda produttrice, fino ad avere guai di tipo legale.
2.4 Modelli di produzione software
Abbiamo visto in generale quali sono i passi principali da effettuare durante la produzione del software. Presentiamo ora in modo più dettagliato vari modelli di produzione descritti in letteratura.
2.4.1 Il modello a cascata (Waterfall Model)
Generalità
Il modello convenzionale del processo di produzione del software, detto modello a cascata, presentato nella letteratura negli anni '50, fu adottato nella pratica fin dagli inizi degli anni '70. Per quanto riguarda questo tipo di ciclo di vita , ciascuna fase riceve ingressi dalla fase precedente e produce uscite, che sono a loro volta ingressi per la fese seguente.Il ciclo di vita può essere riassunto in una sequenza di fasi. Le uscite intermedie che una fase produce come ingresso per la fase successiva, sono i così detti semilavorati del processo, si tratta sostanzialmente di documentazione di tipo cartaceo, spesso scrittura in linguaggio naturale
Le fasi del ciclo di vita a cascata sono le seguenti:
- studio di fattibilità
- analisi dei requisiti e definizione delle specifiche;
- disegno dell'architettura del software;
- codifica e testing dei moduli software;
- integrazione dei moduli e collaudo del sistema;
- rilascio del sistema e manutenzione.
Esistono diverse varianti del modello che dipendono dallo standard adottato e dallo specifico progetto; i principi di base rimangono comunque gli stessi.
La scelta di una particolare variante di ciclo può dipendere dalla complessità della applicazione: applicazioni più complesse possono prevedere la scomposizione di alcune fasi del progetto al fine di ottenere un controllo più accurato dell'attività di sviluppo. Altre varianti possono dipendere dal grado di specializzazione dell'utente finale; per esempio se il progetto è rivolto ad un utente finale inesperto, esso deve prevedere il materiale di addestramento come parte integrante del prodotto finale, ed una particolare fase di addestramento all'uso dopo il rilascio del prodotto stesso.
Un importante fattore che può influenzare la scelta di una particolare variante del modello di produzione del SW è il differente ruolo che hanno l'utente finale e il programmatore. Si possono considerare i seguenti casi:
* Il programmatore realizza il SW per uso personale;
* Una software house sviluppa SW personalizzato, per particolari richieste di differenti clienti (es: clienti appartenenti a differenti organizzazioni).
* Una organizzazione di sviluppo SW sviluppa SW all'interno della stessa organizzazione.
* Una software house progetta e realizza una applicazione generale da lanciare sul mercato.
Le organizzazioni che adottano il modello a cascata definiscono, per ciascuna fase, opportuni standard per i documenti di ingresso-uscita e, per l'intero processo, uno sviluppo sistematico che costituisce la metodologia di sviluppo del software, ciò al fine di ottenere precisi controlli al rilascio di ciascun documento, garantendo la voluta qualità del prodotto.
Nel seguito vengono illustrate in maggiore dettaglio le singole fasi del processo di produzione.
Studio di fattibilità
Obiettivo di questa fase è la produzione di un documento detto studio di fattibilità che valuta i costi ed i benefici dell'applicazione. A tale scopo è necessario sviluppare uno studio preliminare che identifichi le soluzioni alternative e per ciascuna di queste:
- i costi presunti;
- le prestazioni attese;
- le risorse necessarie;
- le date di consegna.
Lo studio di fattibilità viene fatto in tempi limitati e sotto la pressione dell'utente finale. Ne consegue che, tenuto conto dell'incertezza che l'offerta venga accettata, la necessaria fase di analisi viene talora effettuata con eccessiva superficialità.
Analisi dei requisiti e specifiche
Obiettivo dell'analisi dei requisiti è l'identificazione delle caratteristiche richieste per l'applicazione, cioè quali funzioni il software deve prevedere, indipendentemente dal loro disegno ed implementazione.
Risultato di questa fase è un documento di specifica dei requisiti, designato sulla base dell'analisi effettuata. Tale documento deve essere accettato dall'utente finale e deve essere usato dal programmatore per le fasi successive del processo di produzione. Pertanto esso deve essere comprensibile, preciso, completo, consistente e, per progetti di natura "evolutiva", facilmente modificabile. Tali proprietà verranno discusse nel seguito illustrando i metodi usati in collegamento con questa fase.
Al fine di poter verificare il soddisfacimento dei requisiti di utente, in questa fase viene prodotto un ulteriore documento detto piano di test del sistema.
Normalmente, a ciascun livello forniti i seguenti diagrammi:
* un diagramma di flusso dei dati, che rappresenta le funzioni svolte dal sistema ed i dati che le connettono;
* una specificazione di ciascuna funzione, detta minispecifica, che mostra come i dati di ingresso a ciascuna funzione sono trasformati nei dati di uscita.
Oltre alle specifiche dei requisiti sopra descritti, detti funzionali, è necessario completare le specifiche con la descrizione dei requisiti detti non funzionali, quali ad esempio affidabilità, correttezza, prestazioni, usabilità, ecc... già descritte in precedenza.
Disegno dell’architettura del software
Il disegno prevede la scomposizione del sistema in moduli: il risultato è un documento di specificazione del disegno che contiene la descrizione dell'architettura dell'applicazione e dell'architettura dei dati su cui tale applicazione opera.
E' in generale consuetudine distinguere tra disegno high level detto anche disegno concettuale e disegno low level per distinguere la scomposizione logica del problema dalla scomposizione fisica del programma in unità del linguaggio di programmazione.
Codifica e testing dei moduli
Questa fase consiste nell'implementazione, in un linguaggio di programmazione, dei singoli moduli. Inoltre essa include una precisa definizione del piano di prove, comprendente i criteri di test da seguire (strutturale, funzionale) e le regole per la terminazione del test stesso.
I singoli moduli sono realizzati impiegando metodi di programmazione strutturata quali ad esempio la tecnica del raffinamento a passi. Il piano di prova comprende pertanto anche la verifica dell'aderenza del codice allo stile standard di programmazione scelto dall'organizzazione.
Integrazione dei moduli e collaudo del sistema
Questa fase consiste nell'assemblaggio dell'applicazione a partire da un insieme di componenti, che sono stati precedentemente sviluppati e testati separatamente. Sebbene tale fase può essere integrata nella precedente, se si adottano tecniche di sviluppo incrementali, essa riguarda la progettazione nel suo complesso ed è pertanto concettualmente differente dalla precedente.
Il test di integrazione avviene spesso gradualmente: insiemi di moduli sono assemblati per costituire un sottosistema e questo può essere successivamente integrato con altri moduli e/o sottoinsiemi.
Come fase finale tale tecnica porta al test dell'intero sistema. Lo sviluppatore infine effettua il test del sistema sull'applicazione impiegata nelle condizioni di funzionamento reali (alfa testing).
Rilascio del sistema e manutenzione
Il rilascio del sistema solitamente avviene in due fasi successive: nella prima l'applicazione viene distribuita ad un insieme selezionato di clienti allo scopo di individuare le eventuali modifiche da effettuare prima del rilascio definitivo (beta testing), nella seconda il prodotto viene distribuito ai clienti.
La manutenzione è costituita da un insieme di attività che vengono svolte dopo il rilascio del sistema. Possiamo distinguere tre casi:
- manutenzione correttiva in cui vengono corretti gli errori residui presenti nel sistema.
- manutenzione additiva in cui l'applicazione viene adattata alle modifiche richieste dall'utente.
- manutenzione perfettiva in cui vengono migliorate, cambiate o aggiunte funzionalità e qualità all'applicazione.
Analisi critica del modello a cascata
Il principale pregio del modello a cascata è stato quello di evidenziare che le attività critiche nel processo di sviluppo sono quelle connesse alle fasi di analisi e disegno: una codifica prematura, senza cioè un adeguato approfondimento dei problemi legati a queste fasi,porterebbe a conseguenze disastrose in termini di costo e qualità del prodotto.
Tuttavia, la struttura rigida del modello non è perfetta, specialmente in presenza di applicazioni in cui, nella fase iniziale, i requisiti dell'utente sono definiti in maniera incerta. Inoltre, per molte applicazioni, la fase di realizzazione viene iniziata prematuramente, con conseguenti divergenze tra i requisiti richiesti, le specifiche di progetto e la realizzazione. Ne consegue un elevata attività di manutenzione che può portare ad elevati costi di sviluppo ed addirittura al fallimento del progetto.
Concludendo, le applicazioni con requisiti ben definiti e scarsamente soggetti a modifiche evolutive ben si prestano ad essere sviluppate seguendo un modello rigido quale quello a cascata. Invece le applicazioni che hanno requisiti meno stabili e/o non perfettamente noti si prestano male alla rigidità del modello.
2.4.2 Il modello a ciclo di vita a spirale (Barry Boehm)
Generalità
Il Modello a Spirale è in realtà un Metamodello, nel senso che in esso è selezionabile un qualsiasi ciclo di vita .
L'introduzione del metamodello deriva dalla necessità di dare maggiore "importanza" alle prime due fasi di un qualsiasi ciclo di vita (fasi di alto livello):
1. Pianificazione
Determinazione degli obbiettivi, delle alternative e dei vincoli associati al progetto
2. Analisi dei rischi
Identificazione ed analisi dei problemi e dei rischi associati al progetto
Dopo queste due fasi inizia il ciclo di sviluppo vero e proprio.
La forma " a Spirale" del modello indica infatti la possibilità di:
* Sviluppare il sistema in un solo colpo.
* Sviluppare il sistema in maniera incrementale.
La scelta dipende sia dai requisiti del sistema che dalla capacità organizzativa dell'azienda produttrice.
Un sistema di grande dimensioni potrebbe avere le problematiche legate ad un ciclo di vita a cascata (es: tempi di rilascio, validazione alla fine del processo di sviluppo ecc...).
In questo caso quindi, per diminuire i rischi legati allo sviluppo e per gestire la complessità del progetto, può essere opportuno adottare un sistema di tipo incrementale.
Il metamodello a spirale,permette di percorrere per un certo numero di giri (pari al numero di incrementi pianificati) la spirale.
La prima volta che vengono affrontate le fasi di Pianificazione e di Analisi dei Rischi, si individuano le "slice" del sistema e si realizza un piano di priorità.
Ai giri successivi le prime due fasi costituiscono uno studio approfondito sulla pianificazione dello "slice" corrente da sviluppare.
Punti di forza del ciclo di vita a Spirale:
-Valutazione "periodica" dei rischi.
-Focus sulle "alternative".
-Focus sugli obbiettivi e sui vincoli.
Applicabile sia allo sviluppo che alla manutenzione.
2.4.3 I modelli basati sulle trasformazioni
Generalità
Il modello basato sulle trasformazioni, detto trasformazionale, si basa sul concetto che lo sviluppo del software può essere effettuato mediante una serie di trasformazioni che modificano passo passo una specificazione nel sistema SW finale. Esso utilizza SW specializzato per trasformare "automaticamente" successive versioni nel sistema da sviluppare.
Il primo passo (sviluppo di una specifica formale) richiede una specifica espressa in maniera precisa e completa.
Allo stesso tempo, la specifica deve essere comprensibile all'utente per validare i requisiti. Le esigenze contrastanti derivanti da "formalismo" e "comprensibilità" costituiscono una limitazione nell'applicazione del processo di sviluppo, specie per sistemi a media e larga scala.
Le caratteristiche della specifica formale influiscono sulla fase di trasformazione: ad esempio, una specifica può essere espressa ad alto livello, in termini di oggetti, relazioni e operazioni nel dominio dell'utente. Tale forma di specificazione aumenta la leggibilità e la possibilità di valutazione da parte dell'utente ma è assai distante dalla sua implementazione in un sistema funzionante. In questo caso la fase di trasformazione include operazioni di riduzione di livello. In definitiva esiste un contrasto tra il lavoro speso per sviluppare la specifica formale e lo sforzo speso per trasformare la specifica in un sistema concreto.
La figura mostra che la specifica formale è la base per la costruzione del sistema. In particolare:
* è l'unico oggetto che è validato con i requisiti di utente.
* è il punto di partenza della fase di trasformazione.
* è un oggetto su cui è effettuata la manutenzione: ogni variazione alle funzionalità del sistema è espressa come una variazione della specifica e non del codice.
Il codice è prodotto mediante un processo a due passi:
* vengono eseguite variazioni alla specifica formale attraverso una registrazione della sequenza delle trasformazioni e decisioni (record di sviluppo formale) che devono essere prese per convertire la specifica nel codice originale;
* lo sviluppo formale modificato viene ripassato per produrre una nuova versione del sistema.
Non esiste un unico percorso dalle specifiche al rilascio del sistema. La fase di trasformazione ha infatti differenti realizzazioni dipendenti da:
* grado e natura dell'interazione dell'utente per guidare la trasformazione da applicare;
* ruolo di sistemi esperti basati sulla conoscenza per identificare le trasformazioni candidate, per scegliere le strutture dati, per chiedere all'utente i vincoli necessari.
Poiché le regole di trasformazione necessarie sono espresse formalmente, esse possono essere studiate separatamente per assicurare la correttezza e per eliminare eventuali malfunzionamenti. Il modello trasformazionale porta quindi ad ottenere tre differenti prodotti:
* la specificazione formale;
* il sistema da rilasciare;
* il record di sviluppo formale.
Le specifiche formali ed il record di sviluppo sono elementi necessari per mantenere e reimplementare il sistema.
La specifica formale del modello trasformazionale deve essere una specifica operazionale in modo che le regole di trasformazione possano lavorare su una rappresentazione che produce un comportamento del sistema oggetto di sviluppo, ad ogni stadio del processo di trasformazione.
2.4.4 Il modello basato sulla prototipazione
Generalità
Una possibile strategia di sviluppo incrementale è quella basata sulla tecnica della prototipazione. Un prototipo è un modello approssimato dell’applicazione, il cui obiettivo è fondamentalmente quello di essere mostrato al committente, o usato da questi, al fine di ottenere una indicazione su quanto il prototipo colga i reali fabbisogni. Naturalmente occorre che il prototipo sia sviluppabile economicamente ed in temi brevi, altrimenti è inutile.
Una volta che dal prototipo, che costituisce un primo incremento, si sono derivate tutte le informazioni necessarie, occorre procedere nello sviluppo secondo ulteriori incrementi.
A questo punto si possono seguire due strade alternative. In un primo caso, il prototipo non viene più utilizzato per i passi successivi: si tratta di un prototipo usa e getta (in letteratura, trow-away), in quanto il suo solo obiettivo era quello di contribuire a chiarire i requisiti. Una seconda possibilità è quella che il prototipo si possa trasformare progressivamente nel prodotto: in tal caso si parla di prototipo di tipo evolutivo, e ciò risulta possibile soltanto se il prototipo è stato progettato in modo da essere facilmente modificabile e con la tecnologia adatta al prodotto finale.
I passi successivi dello sviluppo possono procedere per espansioni incrementali, oppure, qualora si ritenga che il prototipo abbia fornito tutte le indicazioni necessarie, e pertanto non possano più sorgere rischi seri nell’iniziare il vero e proprio sviluppo industriale del prodotto, il processo successivo può consistere in un solo passo che effettua tutta la produzione dell’applicazione.
Capitolo 3
Modelli industriali per la produzione di software
3.1 Introduzione
La gestione dei dati aziendali è diventata un fattore critico con la nascita dell'Era Industriale ed il conseguente incremento dimensionale dei rapporti interpersonali che essa ha generato. Come già detto, in precedenza, le aziende, spesso di piccole dimensioni, erano coordinate per adattamento reciproco, cioè la comunicazione avveniva senza l'ausilio di alcun supporto tranne la voce. In questo contesto, il "sistema informativo" era estremamente spartano e semplice da gestire poiché‚ il mutuo adattamento provvedeva al coordinamento delle attività.
Successivamente, Taylor cercò di sistematizzare i processi aziendali, alla ricerca della via da seguire che, a suo dire, doveva essere unica (la teoria della One Best Way introdotta con lo Scientific Management), concepita e progettata per ottimizzare i metodi di lavoro. Ciò portò alla creazione di nuove figure ed attività professionali (l'analista di tempi e metodi, il responsabile della qualità, quello del personale, l'esperto delle lavorazioni meccaniche, il responsabile del controllo di gestione) con la conseguente maggiore necessità e complessità di comunicazione tra i vari attori.
Cominciò così ad acquisire sempre maggiore importanza la corretta gestione delle informazioni che, con il crescere delle dimensioni aziendali e della sempre maggior varietà di prodotti richiesti dal mercato, risultò realmente importante per i processi aziendali. Una conferma di questa valenza arriva dagli ulteriori sviluppi e dalle attuali tendenze di alcune imprese che, puntando verso una maggiore concentrazione sul core business (business principale dell’azienda in questione) e terziarizzando le attività secondarie, focalizzano la loro attenzione sulla gestione e sull'integrazione dei flussi informativi globali, intendendo con ciò sia le informazioni interne all'azienda che quelle esterne.
Con l'avvento degli elaboratori nascono i sistemi software, che rappresentano oggi i sistemi artificiali più complessi mai realizzati dall'Uomo. Cosa si intende, o cosa si dovrebbe intendere, con il termine software? In generale, si può considerare il software come costituito da tre parti mutuamente interagenti:
1. un insieme di istruzioni che, eseguite, permettono di ottenere le funzioni desiderate;
2. un insieme di strutture informative (database) che permettono di gestire tali funzioni;
3. una documentazione di supporto (funzionale, tecnica, di ausilio all'operatività dell'utente).
Il software, a differenza di qualsiasi altro prodotto fisico come l'hardware o un qualsiasi prodotto industriale tangibile, non si logora. Il ciclo di vita dei prodotti industriali viene spesso indicato mediante la caratteristica curva "a vasca da bagno",secondo la quale ad una fase iniziale , soggetta a molti guasti a causa di errori di progettazione o di costruzione, segue una fase di relativa stabilità, dovuta all'eliminazione dei difetti originari. Infine la parte finale del ciclo di vita, dove si evidenzia un nuovo aumento dei guasti dovuti, essenzialmente, alle vicissitudini subite dal componente (stress, vibrazioni, sovratemperature).
La curva del ciclo di vita del software, invece, ha il seguente andamento: ad una fase iniziale caratterizzata da un elevato tasso di guasto (errori applicativi, errate inizializzazioni), segue un lungo periodo nel quale la curva dovrebbe tendere asintoticamente a zero. In realtà l'andamento del tasso di guasto, si discosta notevolmente dalla curva teorica, presentando dei picchi dovuti all'effettuazione di successive modifiche della logica applicativa. Ogni variazione introduce uno o più errori che degradano sempre più il software, fino al punto da renderne necessaria la completa sostituzione.
Vi è un'altra differenza tra il ciclo di vita del software e quello di un prodotto industriale: mentre per quest'ultimo è possibile utilizzare pezzi di ricambio per le parti più usurate, il software è meno facilmente standardizzabile e ciò lo rende, almeno fino ad oggi, più difficilmente costruibile mediante assemblaggio di sue parti, sviluppate all'interno o presso fornitori. Salvo eccezioni, nel caso del software ogni volta viene creato ex novo ogni singolo componente costituente il prodotto finito, e ciò rende ancora più complessa l'attività di progettazione e di manutenzione. Questo limite verrà probabilmente superato dalle nuove metodologie di sviluppo basate sull'Object Oriented Technology o sullo Sviluppo per Componenti (o per Parti).
3.2 L’ingegneria del software
Come premessa all'ingegneria dei sistemi informatici, è opportuno sottolineare il fatto che gli approcci succedutisi nel tempo non sono da considerare mutuamente esclusivi o incompatibili, ma possono essere scelti in funzione delle necessità applicative e usati in sintonia tra loro, integrando opportunamente i risultati.
Per esempio, un progetto particolarmente articolato può richiedere l'utilizzo del prototyping per le parti meno note - per le quali il grado di indecisione su ciò che si desidera ottenere è elevato - mentre le aree che si conoscono più profondamente possono essere affrontate per fasi sequenziali più strutturate e serializzate. In sintesi, va sottolineato il fatto che l'ingegneria del software indica alcune strade che è possibile percorrere per lo studio dei sistemi informatici. Ciò non significa quindi che tutte le aziende devono orientarsi verso i concetti più innovativi ultimamente introdotti (ad esempio l'approccio Object Oriented o il prototyping): vi sono moltissime imprese per le quali, malgrado l'approccio teorico allo studio dei sistemi preveda ancora la stesura di ponderosi e poco funzionali manuali, si possono realizzare dei moduli software funzionali adottando delle metodologie relativamente semplici. Problemi e metodi devono rientrare in un'ottica di analisi degli investimenti e del corrispondente ritorno economico. Spesso si rileva che la soluzione prevista, anche se funzionante, non è efficiente o vantaggiosa, pur richiedendo un notevole impegno di risorse. Mentre nelle organizzazioni più piccole ed informali si tende ancora oggi ad avviare i progetti sulla base di discussioni prevalentemente verbali, nelle aziende di maggiori dimensioni si tenta di rendere l'analisi dei sistemi meno aleatoria e meno soggetta alle iniziative estemporanee dei singoli. Ne discende che si rende necessario identificare o stabilire una standardizzazione più o meno spinta delle attività per rendere i progetti più omogenei, confrontabili tra di loro, e per meglio pianificare e controllare lo stato di avanzamento dei lavori.
L'obiettivo dell'ingegneria del software, proposto da F. Bauer nel corso di un convegno dedicato all'argomento, è la seguente: "[L'ingegneria del software] è l'utilizzo di alcuni principi di ingegneria per produrre software in modo conveniente, affidabile e funzionante in modo efficace su macchine reali".
La Software Engineering segue l'ingegneria dell'hardware e dei sistemi in generale, cercando di utilizzarne i concetti di base. Essa è formata da procedure (serie di attività da svolgere), metodi e strumenti - necessariamente legati tra loro ed interagenti - con lo scopo di rendere controllabile il ciclo di sviluppo del software e di fornire ai professionisti le opportune basi di conoscenza per costruire applicazioni di alta qualità e facilmente manutenibili. I metodi forniti dalla Software Engineering danno una serie di indicazioni sulle modalità per arrivare a costruire software con le caratteristiche indicate da Bauer. Si tratta di concetti riguardanti tutto il ciclo di vita del software che comprende: la gestione della pianificazione e la stima di un progetto, l'analisi dei requisiti, la stesura della documentazione, la progettazione dei database necessari, l'architettura e la stesura dei programmi applicativi, i test di unità e di sistema, la manutenzione. I metodi spesso introducono linguaggi nuovi e proprie notazioni grafiche. Ciò a volte costituisce un limite all'utilizzo di metodologie innovative, dovuto sia ai maggiori costi che questa scelta implica (corsi, istruzione, progetti pilota) sia ad un rifiuto culturale che spinge a guardare con diffidenza ogni novità.
Uno dei concetti mutuati dall'industria è il Concurrent Engineering e riguarda lo sviluppo parallelo delle attività del ciclo di vita delle applicazioni.
Le ragioni per cui si è arrivati a questa sono principalmente le seguenti:
riduzione dei tempi di sviluppo;
possibilità di costruire l'applicazione per approssimazioni successive, verificabili con l'utente, trascurando completamente, nelle fasi iniziali, i dettagli;
possibilità di anticipare i vincoli che il sistema incontrerà (incomprensioni con l'utente, limitazioni tecniche).
Gli strumenti dell'ingegneria del software supportano i metodi, sempre più spesso realizzati in modo automatico, lungo tutto il ciclo di vita del progetto. I tool per il CASE (Computer Aided Software Engineering) - pur senza avere raggiunto completamente gli obiettivi che qualche anno fa sembravano a portata di mano (supporto completo e totalmente integrato alle varie fasi, generazione automatica e totale del codice, utilizzatori in grado di costruire da se‚ gran parte delle applicazioni) - rappresentano comunque un notevole aiuto, specie per progetti complessi che richiedono la partecipazione di molti attori. Essi consentono infatti di memorizzare in un'unica struttura logica i dati di stima, progettazione, analisi, codifica, test. I CASE possono essere paragonati a strumenti di progettazione meccanica che supportano anche la realizzazione ed il montaggio, esattamente come i tool di tipo CAD/CAM/CAE.
Le procedure fanno da collante tra metodi e strumenti, fornendo la sequenza con la quale vanno applicati i metodi ed elencando gli input e gli output che devono contraddistinguere le varie fasi (documenti, grafici, dati). Inoltre, esse indicano i controlli che è necessario effettuare per garantire la qualità complessiva del progetto, la corretta gestione delle modifiche applicative e la stima dello stato avanzamento lavori.
3.2.1 Analisi: i tre approcci
Nel corso della breve storia dell'ingegneria del software, sono stati proposti vari modelli di analisi che si possono ricondurre a tre filoni principali di analisi: l'approccio classico, l'approccio semi-strutturato e l'approccio strutturato.
L'analisi classica (tradizionale). Il ciclo di vita tradizionale è il paradigma di ingegneria del software più datato, ma risulta ancora molto seguito ed utilizzato. E identificato principalmente da una strategia di implementazione di tipo bottom-up e dalla rigida sequenzialità con cui si susseguono i vari passi del progetto.
L'origine di tale metodologia, secondo alcuni studiosi, sembra sia dovuta all'industria automobilistica, ambito nel quale l'approccio è stato introdotto grazie soprattutto all'elevata ripetitività delle fasi di lavoro, che per loro natura sono più facilmente standardizzabili e serializzabili.
L'analisi semi-strutturata. Con tale denominazione viene spesso indicato l'anello di congiunzione tra l'analisi classica e quella strutturata. Questo approccio ha cominciato ad emergere a partire dalla fine degli anni settanta, con la nascita della progettazione e della programmazione strutturate. In tale periodo si è formata una crescente consapevolezza sulla necessità di adeguare ai concetti di strutturazione del codice anche le fasi di analisi più elevate, senza limitarsi alla sola programmazione. Ciò ha portato a ribaltare l'approccio ai problemi utilizzando l'implementazione top-down, che ora viene riconosciuta come più rispondente alle necessità dei progetti informatici.
L'analisi strutturata. Gli anni ottanta vedono la nascita di metodologie di lavoro più efficaci ed efficienti, che eliminano, o perlomeno riducono, alcuni degli svantaggi e dei limiti evidenziati negli approcci precedenti.
Una caratteristica relativa allo studio di nuovi sistemi informatici è l'opinione, tuttora molto diffusa, che prima di iniziare l'analisi del nuovo modello che ci si propone di ottenere sia necessario apprendere quanto più possibile delle vecchie procedure fisiche, modellizzandole e concentrando in questa attività una notevole mole di lavoro e di tempo. Il diverso approccio introdotto dall'analisi strutturata tende invece a ridimensionare tale sforzo, lo ritiene utile solo per le aree critiche e invita a concentrare l'attenzione sul nuovo sistema. E considerata invece ancora valida la suddivisione per fasi, già proposta dall'analisi classica, anche se viene in parte modificata la logica che le lega tra di loro.
I metodi innovativi
Una variante rispetto all'approccio top-down, già discusso, è nota come prototyping ed è stata introdotta principalmente da B. Boar, J. Martin, F. Brooks. Come scrive Boar: "Questa metodologia prevede di determinare un insieme iniziale di esigenze con l'intento di espanderle e rifinirle iterativamente a mano a mano che cresce la reciproca comprensione tra utente e sviluppatore. La definizione del sistema avviene mediante una scoperta graduale ed evolutiva, contrapposta alla previsione onnisciente. Con questo approccio è possibile trattare meglio l'incertezza, l'ambiguità e la volubilità del mondo reale".
Candidati all'utilizzo del prototyping quale strumento di lavoro risultano essere quei sistemi in cui l'utente non è in grado di specificare in dettaglio le proprie esigenze sin dall'inizio e può soltanto determinarle mediante una serie di tentativi ripetuti che possono anche portare ad ottenere un risultato notevolmente diverso dalle ipotesi iniziali.
La differenza principale tra l'approccio top-down e il prototyping consiste nel fatto che, nel primo caso, viene realizzato un modello completo "cartaceo" del sistema - cioè un insieme di documenti formali che lo accompagneranno durante tutta la sua vita e che dovranno essere sottoposti a manutenzioni ed a revisioni - mentre, con il prototyping, viene creato un modello funzionante, dapprima molto grezzo e poi a mano a mano raffinato e corretto secondo le specifiche che vengono successivamente dettagliate. Una volta definiti i dettagli dell'applicazione, alla fine della fase di analisi funzionale, chi ha utilizzato il prototyping quale metodo di lavoro può scegliere di percorrere due diverse strade:
nella prima, il prodotto "grezzo" viene abbandonato e interamente sostituito da un sistema per la produzione. Ciò avviene quando nella costruzione e nel successivo sviluppo del prototipo, non si è tenuta in considerazione la qualità del prodotto o altri fattori determinati in ambito reale. Per esempio, non si è usato un appropriato linguaggio di sviluppo, o un sistema operativo adeguato, oppure non sono stati rispettati criteri di manutenibilità del software o alcuni algoritmi sono stati sviluppati in modo inefficiente al solo scopo di presentare alcune caratteristiche del sistema. In questi casi, il rischio è quello di voler utilizzare comunque il prototipo, eventualmente raffinato mediante rapidi aggiustamenti formali, con il risultato di ottenere un sistema finale altamente inefficiente.
L'altra strada percorribile prevede invece il perseguimento degli standard di qualità lungo tutta la fase di sviluppo del prototipo: in tale caso si otterrà una comprensione del sistema più lenta che nel caso precedente, con il vantaggio però di un prodotto finale già funzionante ed ottimizzato (e quindi immediatamente disponibile).
Non necessariamente il prototyping deve essere utilizzato in alternativa alle fasi di sviluppo strutturate: è possibile avere dei sistemi in cui ad alcune aree ben definite e note se ne contrappongono altre in cui invece la conoscenza è scarsa o lacunosa. Si avranno così sottosistemi che procedono secondo le fasi di sviluppo tradizionali ed altri che invece subiranno una o più iterazioni.
3.2.2 Object Oriented: il paradigma del futuro?
Il motivo principale che spinge gli uomini (e le organizzazioni) al cambiamento di un paradigma o di una tecnologia consiste nel voler risolvere i problemi più velocemente e/o più efficacemente. Dato il costo, anche psicologico, di un cambiamento, è facile che si continuino ad usare i vecchi metodi e le vecchie tecnologie finché‚ non si prospettano cambiamenti di "ordini di grandezza" oppure finché‚ non appaia un nuovo problema che non può essere risolto con i vecchi approcci. Là dove si sviluppa del software utilizzando le GUI (interfacce grafiche), per esempio, risulta estremamente difficoltoso utilizzare le metodologie tradizionali. Un'interfaccia utente composta da tendine, icone, finestre multiple, conduce quasi obbligatoriamente a utilizzare il paradigma Object Oriented per tutte la fasi di sviluppo del software.
Non necessariamente un approccio ad oggetti nelle fasi "alte" di un progetto (analisi e, in parte, progettazione) conduce obbligatoriamente all'uso di un linguaggio di programmazione Object Oriented: anche se tale passaggio sembra naturale e scontato, esistono situazioni in cui è stata percorsa una strada diversa, con l'utilizzo di linguaggi di sviluppo tradizionali. Ciò si è verificato principalmente nello studio di sistemi per i quali il management non ha ritenuto opportuna l'introduzione di troppe innovazioni contemporanee, rischiando di non ottenere un buon risultato finale. Questo modo d'agire, anche se soggetto a limitazioni (il cambiamento di metodologia ha un costo) presenta comunque il vantaggio di permettere l'introduzione in azienda del paradigma Object Oriented in modo "seamless" (traduzione letterale: senza cuciture), evitando i rischi connessi all'utilizzo di linguaggi la cui conoscenza risulta scarsamente diffusa.
Le metodologie di analisi Object Oriented differiscono sensibilmente dagli approcci tradizionali: l'attenzione viene posta sul dato, con significato concettualmente più ampio di quello tradizionale, comprendendo ora anche le operazioni eseguibili su di esso (i "metodi": creazione, modifica, stampa, distribuzione, ...). Ipotizzare il futuro in generale, e quello dell'ingegneria del software in particolare, è un compito arduo, tuttavia si può tentare di prevedere, in base all'attuale mainstream tecnologico, quali potrebbero essere i possibili scenari futuri che caratterizzeranno questa (relativamente) nuova disciplina.
Il "riuso" (o più propriamente la riutilizzazione) del software dovrà divenire un fatto normale, così come avviene ormai da decenni, nelle industrie manifatturiere, per i componenti costruttivi. Nell'industria la tendenza sempre più spiccata è quella di utilizzare, per la realizzazione dei prodotti finiti o dei semilavorati, poche parti accuratamente standardizzate che possono combinarsi tra loro in molteplici modi anziché‚ creare ogni volta dei componenti ad hoc. In questo modo si ottengono notevoli vantaggi, sia in termini di costi di progettazione e produzione che di time to market, che elevano l'immagine aziendale e rendono più spedito il processo produttivo. I sistemi informatici dovranno adeguarsi a questa logica, quindi si può ipotizzare una tendenza sempre più marcata verso la nascita di produttori di software generalizzato, il cui obiettivo sarà la costruzione di parti che non solo potranno essere riutilizzabili più volte ma diverranno oggetto di vendita tra diverse aziende. Estremizzando questa tendenza, si può ipotizzare uno scenario in cui le aziende produttrici si specializzino in aree più o meno vaste di soluzioni, passando da grandi produzioni standardizzate a moduli software particolari o su misura, indirizzati verso specifiche nicchie di mercato.
Si stanno poi verificando forti tendenze verso la creazione di un paradigma di sviluppo unificato che tragga il meglio esistente dalle attuali metodologie di sviluppo e che renda sempre più omogeneo ed indolore il passaggio attraverso le varie fasi.
Per concludere, è auspicabile che, in modo simile a quanto già avviene in campo industriale, in cui la progettazione parallela (Concurrent Engineering) risulta ormai una metodologia consolidata di sviluppo di un prodotto, anche per i progetti software si tenderà ad uno svolgimento parallelo tra le attività di analisi, disegno e codifica, al fine di evitare "salti" logici o semantici che inevitabilmente nascono ove le varie fasi procedano in modo strettamente seriale.
3.2.3 Le valutazioni economiche
Come tutti gli investimenti, anche quelli in tecnologia richiedono un'accurata analisi e valutazione economica, utilizzando le comuni tecniche già ampiamente impiegate in altri ambiti (Discounted Cash Flow, Internal Rate of Return, Analisi di Break Even).
Ciò che rende meno puntuali ed attendibili i risultati di ogni analisi è dovuto all'effettiva difficoltà di quantificare non tanto i costi, quanto i benefici economici ottenibili dall'investimento. Mentre in ambito industriale è relativamente più semplice indicare i vantaggi che si ottengono, per esempio con l'acquisto di un nuovo impianto, nel settore dei servizi esistono difficoltà oggettive di valorizzazione economica. E necessario però superare queste difficoltà, non immediatamente percepibile, cercando di dare un termine quantitativo anche ai cambiamenti di qualità che si prevede saranno indotti dal nuovo sistema. Si potrebbe iniziare il processo di quantificazione valutando i benefici indotti, per esempio, da tre fattori chiave quali: la diminuzione dei lead-time di produzione, il miglioramento del rapporto con i fornitori ed i vantaggi per l'immagine aziendale.
3.3 Le organizzazioni industriali per la progettazione del software
3.3.1 “Cosa deve essere fatto” e “come deve essere fatto”
La produzione industriale del software per rispettare gli obiettivi economici, di qualità e di time to market deve essere realizzata secondo modelli che indicano il "cosa deve essere fatto" ed altri modelli che indicano il "come deve essere fatto". I primi modelli comportano per l’ente che produce il software l’adozione di una ben precisa organizzazione a livello aziendale. Questo fatto non è immediatamente evidente, ma può essere dimostrato. I secondi modelli indicano invece esplicitamente quale deve essere l’organizzazione a livello dei team di progettazioni. L’uso combinato di un modello del tipo "cosa deve essere fatto" e di un altro del tipo "come deve essere fatto" determina in modo preciso l’organizzazione che l’ente produttore del software si deve dare sia a livello aziendale che a livello di team di progettazione.
Introduzione
La produzione del software nell’industria, come del resto la produzione di un qualsiasi altro bene industriale, deve rispettare ben precisi obiettivi di qualità, time to market ed economia di produzione. E’ noto che il prodotto software è spesso carente rispetto a tutti i suddetti obiettivi: non è raro il caso in cui il prodotto software viene consegnato non esente da difetti e generalmente tempi di consegna e costi superano abbondantemente quelli pianificati.
Per evitare i suddetti inconvenienti l’industria ha cercato di migliorare la produzione del software basandosi sia sull’introduzione di nuove tecnologie che su nuove organizzazioni dell’attività lavorativa. Per nuova tecnologia nel caso del software s’intende ad esempio: l’utilizzo di un nuovo tool, l’adozione di macchine con migliori performance, l’impiego di una nuova metodologia di progettazione, ecc. Le nuove tecnologie però spesso non hanno portato i miglioramenti sperati e, alle volte, non è stato nemmeno possibile valutare se l’uso di una nuova tecnologia ha prodotto un miglioramento e in quale misura, perché carenze tecnico - organizzative hanno comportato l’indisponibilità dei dati di confronto. In sostanza è emerso che le nuove tecnologie inserite in un contesto carente danno risultati inferiori alle aspettative, oppure, addirittura, producono danni o portano a risultati non valutabili.
Tutto quanto detto finora è stato riferito all’attività di produzione del software, ma risulta essere altrettanto valido per una qualsiasi altra attività produttiva. La produzione del software ha però rispetto ad altre attività produttive delle peculiarità per cui l’importanza dell’organizzazione risulta ancora più evidente.
L’importanza della organizzazione
La progettazione del software è caratterizzata dal fatto di richiedere, rispetto ad altre attività di progettazione, una più consistente partecipazione umana. Ogni fase di un progetto software, dalla prima impostazione del lavoro fino alla messa a punto ed eliminazione degli ultimi difetti, richiede l’intervento dell’intelletto umano e raggiunge la massima efficienza se viene eseguita direttamente da un solo progettista. Questo dipende dal fatto che l’esecuzione corretta di ogni fase, se non eseguita direttamente dal progettista, necessita del trasferimento di una grossa quantità di informazioni, generalmente esprimibili con difficoltà, che il progettista invece naturalmente possiede come conseguenza delle sue scelte progettuali e della conoscenza approfondita del problema. In un progetto software le opportunità di delegare ad altri alcune delle fasi del lavoro, oppure di utilizzare mezzi automatici per eseguirle, sono quindi abbastanza difficoltose e, generalmente, si riducono all’esecuzione procedurizzata del test del prodotto da parte di terzi o con l’ausilio di tool automatici. Per sua natura cioè un progetto software sarebbe di migliore qualità e verrebbe eseguito con migliore efficienza se fosse eseguito in ogni sua fase direttamente da un solo progettista.
Ovviamente, poiché per un prodotto software di dimensioni non eccessive si parla già di decine di migliaia di linee di codice, un solo progettista, pur raggiungendo la massima efficienza, impiegherebbe un tempo troppo lungo per produrlo, facendo saltare gli obiettivi di "time to market". E’ quindi giocoforza l’utilizzo di team di progettazione, anche molto numerosi per progetti di grosse dimensioni e la conseguente suddivisione del lavoro tra i componenti del team. Questa suddivisione, tenendo presente il ciclo di vita della progettazione software, può essere fatta con un approccio "orizzontale", ossia separando ciascuna fase del ciclo dalle altre ed assegnando a gruppi di progettisti specializzati per fase (progettisti analisti, codificatori, verificatori, ecc..) lo sviluppo di ciascuna di esse, oppure la suddivisione del lavoro può essere fatta in senso "verticale", ossia suddividendo l’intero progetto in più sottoprogetti o funzioni del progetto e assegnando a ciascun progettista o gruppo di progettisti lo sviluppo, eseguito percorrendo tutte le fasi del ciclo di vita, di uno di essi. La scelta tra una suddivisione orizzontale o verticale o tra una qualsiasi gradazione tra i due estremi è determinata essenzialmente dal tipo di prodotto software che deve essere realizzato. Generalmente la scelta della suddivisione orizzontale viene fatta per prodotti di grosse dimensioni, ma ripetitivi e di bassa complessità, per i quali, quindi, il passaggio di informazioni tra gruppi che lavorano a ciascuna fase può essere facilmente risolto, eventualmente ricorrendo a strumenti standard di progettazione. La scelta della suddivisione verticale è fatta per prodotti complessi aventi bassa ripetitività, in cui, cioè, sono isolabili funzioni ben distinte e compiutamente descrivibili, che, preferibilmente, interagiscano poco ed in modo ben definito con le altre funzioni. Ovviamente la scelta della suddivisione verticale non può essere totale poiché, necessariamente, il ciclo di vita del progetto dovrà iniziare con una fase comune di progettazione architetturale avente lo scopo di individuare e descrivere le funzioni e terminare con una fase comune finale di integrazione delle funzioni tra di loro.
Comunque sia organizzata la suddivisione del lavoro tra i componenti del team è l’esistenza stessa del team che comporta l’insorgere di problemi. Le conseguenze del cattivo lavoro di un singolo progettista o di un gruppo di progettisti di un team possono comportare effetti tragicamente dannosi per l’intero progetto. Le cause dei problemi risiedono in genere in carenza di comunicazione tra i componenti del team oppure in mancanza di competenza di alcuni componenti del team. La prima causa può essere affrontata procedurizzando in modo opportuno le comunicazioni, mentre la seconda richiede che ogni progettista sia stato opportunamente addestrato per il ruolo che deve ricoprire. Per evitare però che qualcosa sfugga, ad esempio che le procedure non vengano seguite o che l’addestramento non abbia avuto l’esito sperato, è necessario che sia i processi di progettazione, sia i prodotti dei processi vengano periodicamente ispezionati per verificarne la corrispondenza alle attese. Poiché è comunemente nota l’importanza del rilevamento dei problemi nelle fasi iniziali di un progetto software l’organizzazione delle ispezioni deve essere tale da operare efficacemente su tali fasi.
Già da queste prime note possono trarsi alcune conclusioni relative all’importanza specifica di un’organizzazione per la progettazione industriale del software:
* Deve esistere un’organizzazione dei team che rispecchi la suddivisione in senso orizzontale o verticale del lavoro.
* Le comunicazioni nell’ambito dei team devono essere procedurizzate.
* Deve essere pianificato ed eseguito l’addestramento dei progettisti.
* Ogni progetto deve essere periodicamente ispezionato per la rilevazione dei problemi di processo o di prodotto.
3.3.2 I modelli del tipo “Cosa si deve fare”
Nel paragrafo precedente si è cercato di evidenziare che la produzione industriale del software deve necessariamente basarsi su una opportuna organizzazione e che questa organizzazione deve rispondere almeno ad alcune caratteristiche principali. Per ricavare in modo più completo queste caratteristiche alcuni enti attivi nell’ingegneria del software, basandosi soprattutto sull’operatività di società che producono software con risultati eccellenti, hanno cercato di descrivere per mezzo di un modello quello che deve essere fatto per conseguire i migliori risultati. I modelli in questione descrivono quindi "cosa si deve fare" per riuscire a produrre software a costi contenuti, nei tempi previsti e di ottima qualità.
3.3.2.1 Il modello CMM
Il primo modello, storicamente il più importante ed ancora il più diffusamente utilizzato, è il Capability Maturity Model (CMM) del Software Engineering Institute (SEI) [Pan 93].
Il modello CMM descrive le attività che devono essere fatte per produrre il software assegnandole a 5 livelli di "maturità". Mentre nel primo livello, battezzato come "iniziale", i processi di produzione sono del tutto assenti o immaturi, nel quinto livello i processi presi in considerazione dal modello sono tutti presenti e completamente maturi. Analizzando quindi il modo di operare di un ente per la produzione del software è possibile assegnare ad esso, secondo il modello CMM, un livello di maturità dei processi seguiti. Il modello CMM è quindi un mezzo di valutazione della maturità con cui un ente produce il software, ma, poiché il conseguimento di ogni livello del modello implica che tutti i precedenti livelli siano stati già conseguiti e mantenuti, esso indica anche un percorso di miglioramento lungo il quale si deve operare per arrivare alle condizioni finali ottimali. Essendo quindi il livello 1 il livello di partenza in cui tutti i processi sono mancanti o incompleti, il raggiungimento del livello 2 è un pre - requisito per il raggiungimento del livello 3, e così via per tutti gli altri livelli.
Le attività che devono essere fatte per produrre il software secondo il modello CMM ricadono, in ciascun livello, entro alcune aree chiave del processo globale di produzione del software. Ad esempio, al livello 2, alcune aree chiave di processo, o Key Process Area (KPA), sono: Software Configuration Management, Software Quality Assurance, Software Project Planning, …al livello 3 sono: Organization Process Focus, Organization Process Definition, Training Program, …e così via. Complessivamente il modello CMM prende in considerazione 18 KPA distribuite sui 5 livelli. L’implementazione di ciascuna KPA è definita dal modello CMM da un insieme di attività chiave (key practices) definite nell’ambito di 5 sezioni di aspetti comuni (Common Features) che ricorrono in tutte le KPA. Questi aspetti comuni sono:
* L’impegno (da dare e da assumere) ad eseguire (le attività della KPA).
* La competenza per eseguire (le attività della KPA).
* Le attività (della KPA) da eseguire.
* Le misure e le analisi (sulle attività della KPA).
* La verifica dell’implementazione (delle attività della KPA).
Non è questa la sede per entrare in ulteriori dettagli descrittivi del modo in cui il CMM definisce i singoli livelli di maturità, mentre è invece molto importante capire il significato di ciascun livello, ossia, in pratica, l’obiettivo che l’ente produttore del software raggiunge nel momento in cui consegue un livello di maturità. I principali significati di ciascun livello, tralasciando magari alcuni significati che, in questo contesto, sono di minore rilevanza, sono i seguenti:
Livello 2 (Livello Ripetibile).
I progetti software sono eseguiti per mezzo di processi di gestione ben caratterizzati, basati su esperienze fatte nel condurre precedenti progetti analoghi, che permettono alle organizzazioni di ripetere le esperienze che hanno avuto successo. Un processo di gestione è ben caratterizzato quando è praticato, è documentato, è fatto rispettare, è insegnato, è misurato, e, infine, è in grado di dare miglioramenti. Non è necessario che tutti i progetti software abbiano gli stessi processi di gestione.
Livello 3 (Livello Definito)
A questo livello il processo software è consistente e standard attraverso tutta l’organizzazione, poiché sia l’aspetto ingegneristico del software che le attività di gestione sono stabili e ripetibili. La base di tutto è la comprensione comune ed estesa a tutta l’organizzazione delle attività, dei ruoli e delle responsabilità in un processo software definito. Un processo software definito è costituito da un insieme di processi di ingegneria e di gestione coerenti, integrati e ben stabiliti e quindi comprendenti: i criteri di attivazione, la descrizione degli input, gli standard e le procedure per realizzare il lavoro, i meccanismi di verifica (ossia le ispezioni dei pari livello, o peer review), le descrizioni degli output e i criteri di completamento.
Livello 4 (Livello Gestito)
Questo livello prevede che l’organizzazione riesca ad imporre degli obiettivi quantitativi di qualità sia per i prodotti software che per i processi. Ciò deriva dal fatto che ogni processo software viene misurato secondo metriche ben definite e consistenti, che le misure vengono raccolte in un data base comune a tutta l’organizzazione e che opportune azioni vengono attivate quando i limiti imposti alle misure vengono superati.
Livello 5 (Livello di Ottimizzazione)
A questo livello l’intera organizzazione è focalizzata nel miglioramento continuo del processo. L’organizzazione ha i mezzi per determinare i punti di debolezza e di forza del processo durante l’attività di progetto con lo scopo di prevenire l’insorgenza dei difetti. I miglioramenti sono introdotti nel processo sia con avanzamenti incrementali nel processo esistente, sia con l’introduzione di innovazioni dovute a nuovi metodi e nuove tecnologie.
3.3.2.2 Il modello SPICE
La strada aperta dal modello CMM è stata poi percorsa da altre organizzazioni che hanno proposto ulteriori modelli, basati comunque su concetti molto prossimi a quelli del CMM ed aventi lo scopo di introdurre miglioramenti. Lo sforzo più consistente è stato fatto dalla International Elettrotechnical Commission (IEC) della International Organization for Standardization (ISO) che ha pubblicato il rapporto tecnico ISO/IEC TR 15504 [ISO 97] contenente la struttura e le modalità di impiego del modello che è comunemente indicato con il nome del progetto che ne porta avanti la standardizzazione e la sperimentazione, ossia il progetto: Software Process Improvement and Capability dEtermination (SPICE). Il rapporto TR 15504 precede l’emissione di quello che sarà un "full standard" internazionale per la valutazione (assessment) delle organizzazioni per la produzione del software.
Il modello SPICE, a differenza del modello CMM, non prevede che il livello di una organizzazione per la produzione del software sia determinato dal completo (o quasi) soddisfacimento delle "pratiche" di alcune specifiche aree chiave di processo (KPA), ma che ognuno dei processi appartenenti all’intero processo software possa essere valutato singolarmente e gli possa essere attribuito un livello di maturità o completezza. In questo modo il livello di una organizzazione per la produzione del software è dato dall’insieme, o, come è meglio dire, dal profilo dei livelli raggiunti dai singoli processi del processo software.
Il modello SPICE individua i processi del processo software suddividendoli in 5 categorie Per ciascuna categoria qui di seguito indicata diamo alcuni esempi dei processi appartenenti:
* Cliente-fornitore (selezione del fornitore, monitoraggio del fornitore, supporto al cliente, …)
* Ingegneria (requisiti di sistema, analisi e progetto, analisi dei requisiti software, progetto software, …)
* Supporto (documentazione, configuration management, quality assurance, verification, validation, …)
* Gestione (gestione del progetto, gestione della qualità, gestione dei rischi, …)
* Organizzazione (gestione delle risorse umane, infrastrutture, misure, riuso, …)
La valutazione dei processi viene poi fatta assegnando ad essi un valore di livello, che parte da 0 ed arriva a 5, a seconda del grado di soddisfacimento di una serie di attributi. Gli attributi di ciascun livello sono quelli di tutti i livelli precedenti più alcuni attributi specifici. Il grado di soddisfacimento di un attributo è dato con la seguente scala: non raggiunto, parzialmente raggiunto, largamente raggiunto, completamente raggiunto. Un valore di livello viene assegnato quando tutti gli attributi dei livelli precedenti risultano completamente raggiunti e quelli specifici risultano almeno largamente raggiunti. Qui di seguito diamo la definizione dei livelli e degli attributi ad essi assegnati:
Livello 0 (Incompleto)
Generalmente gli scopi del processo non vengono raggiunti. I prodotti e le uscite del processo sono scarsi o non facilmente identificabili,
Attributi: non ci sono attributi
Livello 1 (Eseguito)
Il processo è eseguito e raggiunge i suoi risultati.
Attributi:
* Esecuzione del processo: misura il grado con cui il processo raggiunge i risultati previsti, trasformando i prodotti identificabili di input per produrre i prodotti identificabili di output.
Livello 2 (Gestito)
Il processo Eseguito come prima descritto è ora realizzato in modo gestito (pianificato, tracciato, verificato e modificato) sulla base di obiettivi definiti.
Attributi: quelli del livello precedente e in più:
* Gestione dell’esecuzione: misura il grado con cui l’esecuzione del processo è gestita per produrre gli output che soddisfino gli obiettivi definiti.
* Gestione dei prodotti dell’attività: misura il grado con cui l’esecuzione del processo è gestita per realizzare i prodotti dell’attività che siano appropriatamente documentati, controllati e verificati.
Livello 3 (Stabilito)
Il processo Gestito come prima descritto è ora realizzato usando un processo definito, basato su principi di software engineering e capace di raggiungere i suoi risultati.
Attributi: quelli dei livelli precedenti e in più:
* Definizione e Tailoring del Processo: misura il grado con cui l’esecuzione del processo usa una definizione di processo basata su un processo standard per raggiungere i suoi risultati.
* Risorse del Processo: misura il grado con cui l’esecuzione del processo è condotta con appropriate risorse (per esempio risorse umane e infrastrutture di processo) che siano adeguatamente allocate per sviluppare il processo definito.
Livello 4 (Predicibile)
Il processo Stabilito come prima descritto viene ora realizzato per raggiungere i suoi risultati entro ben definiti limiti.
Attributi: quelli dei livelli precedenti e in più:
* Misura del Processo: misura il grado con cui gli obiettivi di processo e di prodotto e le metriche sono utilizzati per assicurare che l’esecuzione del processo abbia come fine il raggiungimento di obiettivi definiti in supporto dei corrispondenti obiettivi di business..
* Controllo del Processo: misura il grado con cui il processo è controllato per mezzo della raccolta, analisi ed uso di misure di prodotto e di processo per correggere, quando necessario l’esecuzione del processo per raggiungere gli obiettivi di prodotto e di processo definiti.
Livello 5 (Ottimizzato)
Il processo Predicibile come prima descritto cambia ora dinamicamente e si adatta per raggiungere effettivamente gli obiettivi di business correnti e pianificati per il futuro.
Attributi: quelli dei livelli precedenti e in più:
* Cambiamento del Processo: misura il grado con cui i cambiamenti alla definizione, gestione ed esecuzione del processo sono controllati per raggiungere i corrispondenti obiettivi di business dell’organizzazione.
* Miglioramento Continuo: misura il grado con cui i cambiamenti al processo sono identificati e realizzati per assicurare il miglioramento continuo nel completo soddisfacimento dei corrispondenti obiettivi di business dell’organizzazione.
3.3.2.3 Struttura organizzativa indotta da CMM e SPICE
I modelli del tipo di CMM e SPICE descritti nei paragrafi precedenti indicano "cosa deve essere fatto" perché una organizzazione per la progettazione del software produca economicamente e nei tempi richiesti un software di elevata qualità. Nessun dei due modelli descrive invece esplicitamente "come le cose devono essere fatte" per ottenere i risultati suddetti. In altre parole i modelli non dicono esplicitamente nulla relativamente alle tecniche di progettazione, agli standard, agli strumenti, …ecc. da adottare per ottenere risultati eccellenti, ossia, in altre parole, sono indifferenti rispetto a queste scelte. Relativamente allo studio, sperimentazione e diffusione degli standard, delle tecniche e degli strumenti più efficaci i modelli si limitano cioè a dire soltanto cosa deve essere fatto.
Analogamente i modelli non dicono esplicitamente nulla relativamente al tipo di struttura organizzativa interna da adottare, ma, in questo caso, facendo un’analisi delle "cose da fare" descritte dai modelli, si può dedurre che in realtà essi richiedono implicitamente che venga adottata, almeno a livello generale, una ben precisa organizzazione. Per "organizzazione a livello generale" s’intende la struttura organizzativa a livello più alto dell’intera organizzazione per la progettazione del software, mentre l’organizzazione dei team di sviluppo, a livello del singolo progetto, è lasciata di libera scelta e può dipendere da metodologie e tecnologie utilizzate.
Nel modello CMM ciò risulta evidente quando si opera il passaggio dal livello 2 al livello 3. Infatti, mentre al livello 2 (Ripetibile) l’accento è posto sui "Progetti", per cui ogni team di progetto può comportarsi in modo personalizzato, purché, per quel progetto, esista un ben caratterizzato processo di gestione, nel caso del livello 3 (Definito) è richiesto che il processo software sia consistente e standard attraverso tutta l’organizzazione e sia conosciuto e compreso da tutti allo stesso modo. A livello 2 quindi l’organizzazione può essere poco strutturata, con più linee parallele, magari specializzate per prodotto, che operano ciascuna in modo diverso, facendo tesoro delle esperienze passate e gestendo in tal modo i progetti. A livello 3 invece deve necessariamente esistere un ente operante in modo trasversale rispetto alle linee di tutti i progetti e che si faccia carico di attività come:
* Definire e mantenere le procedure dei processi di ingegneria e di gestione dei progetti.
* Costruire, mantenere e aggiornare il Data Base dei processi.
* Verificare lo stato dei processi utilizzati nel corso dello sviluppo dei progetti e gestire le eventuali opportune azioni correttive, gestire i miglioramenti dei processi e l’introduzione delle nuove tecnologie, diffondere da un progetto agli altri le migliorie di tecnologia e di processo che sono risultate efficaci, …ecc.
* Addestrare tutti i progettisti alla conoscenza comune dei processi e delle tecnologie da utilizzare.
D’altro canto i progettisti che compongono i team dedicati ai progetti devono avere una profonda conoscenza delle procedure dei processi di ingegneria e di gestione dei progetti perché essi devono:
* Applicare le procedure nello sviluppo dei progetti, operando un appropriato "tailoring" alle esigenze specifiche.
* Intervenire come "pari livello" nelle ispezioni sui prodotti delle attività dei progettisti di altri progetti.
* Eseguire l’incarico di sperimentare sui progetti reali le migliorie tecnologiche e di processo.
* Utilizzare i dati del Data Base dei processi (ad esempio per fare i preventivi basandosi sui risultati di precedenti progetti), collaborare alla registrazione dei dati dello specifico progetto. ..ecc.
Le competenze e le necessità dei progettisti si intrecciano quindi profondamente con quelle dell’ente "trasversale ai progetti" di cui si è parlato in precedenza, tanto che l’approccio più ovvio risulta essere quello di costruire l’ente stesso come espressione del gruppo, o "pool", dei progettisti. Il primo evidente vantaggio di questo approccio è quello che, in tal modo, la realizzazione delle procedure sia di processo che di gestione viene fatta dai diretti interessati, che, quindi, tenderanno ad introdurre in esse le modalità correnti di attuazione dei processi e non delle direttive, ben concepite quanto si vuole, ma teoriche, perché realizzate da un organismo avulso dall’ambiente progettuale. Quello che si deve evitare è quindi che l’organizzazione contempli l’esistenza di un ente centralizzato, normalmente denominato di Software Engineering & Quality Assurance, separato dal corpo dei progettisti, che si occupi della procedurizzazione e miglioramento dei processi, della verifica della loro attuazione, dell’addestramento dei progettisti, ..ecc., perché rapidamente questo ente, perdendo il contatto con l’ambiente progettuale, comincerà ad operare su un piano poco realistico e verrà visto dai progettisti più come un ostacolo che come un supporto all’attività.
In pratica l’organizzazione più aderente al modello CMM, tale quindi da permettere di rispettarne in modo più efficiente le direttive di "cosa fare" nel passare dal livello 2 al livello 3, dovrebbe basarsi sui seguenti concetti:
* Tutti i progettisti software dovrebbero essere raccolti in un unico pool e dovrebbero rispondere del loro comportamento nell’applicazione dei processi ad un responsabile denominato "Process Owner". Il Process Owner, operando per mezzo di un gruppo di progettisti del pool di alto livello, costituenti il Software Engineering Process Group (SEPG), curerebbe, ricorrendo ancora all’attività di altri progettisti del pool opportunamente selezionati, la redazione ed il mantenimento delle procedure, la verifica dei processi, le attività di miglioramento, l’aggiornamento del Data Base di processo, l’addestramento dei progettisti, …ecc. Da un punto di vista gerarchico il Process Owner avrebbe poi la responsabilità di gestire nel lungo termine la carriera dei progettisti, ossia gli aspetti relativi alla valutazione dei profili personali, all’assegnazione delle posizioni di responsabilità, agli incrementi retributivi, …ecc.
* Nel momento dell’avvio di un nuovo progetto il Process Owner nomina uno dei progettisti del pool come responsabile software per quel progetto. Se, come spesso accade, il prodotto dell’ente a cui appartiene l’organizzazione di progettazione del software di cui si sta descrivendo l’organizzazione non è un puro prodotto software, ma un sistema complesso in cui il software rappresenta uno dei componenti, la nomina del responsabile del software deve essere fatta in accordo con il capo dell’intero progetto. Il responsabile del software sarà quello che curerà le fasi iniziali del progetto come l’allocazione dei requisiti, la valutazione dei costi, la pianificazione temporale, la valutazione delle risorse tecniche ed umane necessarie, ..ecc. A seconda della complessità del progetto il responsabile software svolgerà queste attività da solo o ricorrendo all’ausilio di altri progettisti del pool. Man mano che il progetto procede il responsabile software formerà sotto la sua gestione un team di progetto, anch’esso ancora costituito da progettisti prelevati dal pool. Il responsabile software con il suo team avranno il compito di realizzare entro i termini pianificati il componente software del prodotto, mentre la responsabilità dell’intero prodotto rimarrà del capo progetto. Nel corso dello sviluppo del progetto si realizza quindi tra capo progetto e responsabile del software una dipendenza funzionale. Questa dipendenza non deve però essere tale da influire sui processi procedurizzati secondo i quali deve essere sviluppato e gestito il progetto del software. Ciò verrà garantito, con opportune attività di ispezione e relative azioni correttive, dal Process Owner per mezzo della sua organizzazione di controllo. La dipendenza tra il responsabile del componente software ed il capo progetto ha anche degli aspetti gerarchici, poiché il capo progetto può trasferire al responsabile del software e quest’ultimo poi ai componenti del team, parte dei suoi obiettivi e quindi assegnare degli opportuni riconoscimenti in base al loro raggiungimento.
* Nel corso dello sviluppo del progetto sia il responsabile del software che i componenti del team possono essere chiamati ad intervenire su altri progetti che, nel frattempo, procedono parallelamente, con altri team, nel loro sviluppo, per eseguire le attività di ispezione di pari livello (peer review). Quando il progetto si avvicina al termine, il team man mano si riduce numericamente, fino ad annullarsi. In pratica ogni componente del team viene riassorbito nel pool dal quale viene poi riallocato su altri progetti. E’ compito del Process Owner fare in modo che le fasi di avvio e di fine dei progetti vengano gestite correttamente, curando, secondo le necessità dei progetti, l’allocazione e la disallocazione dei componenti dei team ed evitando ad essi sia sovraccarichi che vuoti di lavoro.
Nel caso del modello SPICE, se quest’analisi fatta per il modello CMM, venisse ripetuta almeno per i processi delle categorie Gestione, Supporto ed Ingegneria nel passaggio dal livello 2 (Gestito) al livello 3 (Stabilito), darebbe in pratica quasi gli stessi risultati. Quindi i modelli CMM e SPICE non sono indifferenti rispetto al tipo di organizzazione adottato dagli enti che producono il software, ma prediligono il tipo di organizzazione descritto in questo paragrafo. Altri tipi di organizzazioni, ad esempio basate su più raggruppamenti separati di progettisti software, ciascuno dedicato ad una linea di progettazione di prodotto, sui quali agisse, dal punto di vista della definizione e controllo dei processi, un ente separato e centralizzato di "Software Engineering & Quality Assurance", raggiungerebbero i goal dei suddetti modelli con molta maggiore difficoltà, oppure, cosa più probabile, non li raggiungerebbero affatto.
3.3.3 I modelli del tipo “Come si deve fare”
Come si è visto nel paragrafo precedente i modelli analizzati del tipo "cosa si deve fare" inducono sugli enti per la progettazione del software una organizzazione a livello generale. Questa organizzazione emerge quando i processi adottati operano al livello 3 e deve essere mantenuta per i livelli successivi. Un problema che risulta rapidamente evidente nell’uso dei suddetti modelli è che essi fino al livello 3 non richiedono che vengano fatte attività relative alla verifica e all’ottimizzazione dei processi adottati. Solo al livello 4 viene infatti richiesto un uso massiccio delle metriche tale da permettere che il processo software venga indagato nei suoi meccanismi e quindi possa essere migliorato, mentre solo al livello 5 viene introdotto il concetto di processo definito e standard, che cambia dinamicamente e si adatta per raggiungere efficacemente i goal di business (ad esempio economici) correnti e futuri. Il rischio che si corre quindi, se si pone l’accento solo nell’adozione dei modelli del tipo "cosa si deve fare", è che, almeno fino al livello 3, si continui a lavorare con processi inefficienti e dispendiosi, anche se in un ambito in cui questi processi (SPICE): portano alla realizzazione di prodotti che si conformano a standard e requisiti specificati, operano secondo procedure specificate e sono pianificati e tracciati, sono standardizzati per mezzo di risorse specificatamente assegnate attraverso tutta l’organizzazione, esistono possibilità approvate di effettuare il tailoring dei processi standard sulle specifiche implementazioni e, infine, i processi sono basati su buoni principi di software engineering.
L’ultima delle cose elencate è, se intesa correttamente, l’unico aggancio che può permettere di avere già al livello 3 la possibilità di operare secondo canoni di efficienza ed economicità. Il software engineering dà infatti delle regole secondo cui fare bene le cose, ossia, in pratica, dà i principi con cui costruire i processi. Il software engineering non è però univoco, ossia, in altre parole, le soluzioni ingegneristiche per progettare e sviluppare un prodotto software sono numerosissime e ciascuna ha i suoi propri vantaggi e svantaggi. Il problema è quindi quello di scegliere la soluzione ingegneristica che meglio si adatta al prodotto o alla linea di prodotti a cui si dedica l’ente di produzione del software del quale si devono definire i processi. Questo problema è però mastodontico, perché le realtà aziendali in cui esso va calato sono numerosissime e diversissime; esso infatti coinvolge fattori come: i prodotti precedenti ed il know how acquisito, le richieste e le necessità attuali dei clienti, gli investimenti aziendali, il tipo e la pianificazione degli oggetti da consegnare, ..ecc. Sarebbe perciò abbastanza complicato fare l’elenco delle possibili tipiche realtà aziendali ed indicare per ciascuna di esse la migliore scelta ingegneristica.
Senza però entrare nei dettagli delle scelte ingegneristiche si può parlare di alcuni modelli che definiscono il "come si deve fare" con un approccio molto generale da cui poter derivare l’organizzazione dei team di progetto. Mentre quindi, come si è visto nei paragrafi precedenti, i modelli del tipo CMM e SPICE danno delle indicazioni implicite per la definizione dell'organizzazione a livello generale, i modelli del tipo ora considerati danno delle indicazioni sull’organizzazione a livello di team di progetto. L’utilizzo dei due tipi di modelli integrati tra loro porterebbe quindi il vantaggio di utilizzare, anche a livelli inferiori al 4, processi efficienti ed economicamente validi ed inoltre di avere chiaramente prestabilita l’organizzazione a cui tendere sia a livello generale che al livello particolare dei team di progetto.
Nei paragrafi che seguono daremo la descrizione di due modelli che definiscono il "come si deve fare", ossia il modello "Unified Software Development Process" e il modello "eXtreme Programming".
3.3.3.1 Il modello “Unified Software Development Process”
Un processo per lo sviluppo del software comprende tutto l’insieme delle attività che permettono agli sviluppatori di catturare i requisiti di un utente e di trasferirli nella versione finale di un sistema software. Il modello "Unified Software Development Process" [Jac 99] descrive un processo per lo sviluppo del software avendo come uno dei punti di riferimento la metodologia di analisi e progettazione Unified Modeling Language (UML) [BOO 98]. Partendo dall’assunto che, data la complessità degli odierni sistemi software, non è possibile in modo sequenziale definire prima l’intero problema, progettare poi l’intera soluzione, costruire quindi tutto il software ed infine eseguire il test del prodotto completo, il processo in oggetto supporta un approccio iterativo. Secondo questo approccio si raggiunge una crescente comprensione del problema attraverso successivi raffinamenti e quindi facendo incrementalmente crescere una soluzione operativa attraverso iterazioni multiple. La struttura di questo processo, senza troppo entrare nei dettagli, è la seguente: esso suddivide tutto lo sviluppo in quattro fasi, ciascuna delle quali può contenere un numero indeterminato, ma sufficiente a raggiungere lo scopo, di iterazioni delle attività che la compongono. La denominazione e le finalità delle quattro fasi sono qui di seguito in breve riportate:
1. Fase di Avvio (Inception): è la fase con la quale viene portata alla luce una visione originale di un potenziale prodotto e questa visione viene trasformata in un progetto da attuare. Le uscite di questa fase sono essenzialmente i requisiti centrali del prodotto, una valutazione dei rischi, la definizione dei criteri per stabilire il successo del progetto ed una valutazione delle risorse necessarie per completare la fase successiva.
2. Fase di Elaborazione (Elaboration): il principale obiettivo di questa fase è quello di analizzare in modo approfondito il dominio del problema, di definire e stabilizzare l’architettura e di determinare gli elementi di rischio più elevati del progetto. Le uscite di questa fase comprendono almeno: un modello di analisi del dominio con un grado di raffinamento tale da poter costruire sulla sua base un’architettura praticamente completa, un’architettura eseguibile che possa essere considerata una baseline per i successivi sviluppi, i criteri di valutazione per la verifica dei risultati delle prime iterazioni delle attività della fase successiva, un piano di sviluppo software dettagliato e i criteri di valutazione del prodotto finale.
3. Fase di Costruzione (Construction): questa fase si suddivide in più iterazioni in ciascuna delle quali l’architettura baseline si accresce ed evolve a gradini verso il prodotto finale. Le uscite di ciascuna iterazione sono in generale: un documento di descrizione della versione, i casi di test ed i risultati dei test condotti sul prodotto, un piano ed i criteri di valutazione della prossima iterazione. L’ultima iterazione di questa fase comprenderà anche la documentazione per l’utente ed un piano di consegna.
4. Fase di Transizione (Transition): la fase di transizione è la fase in cui il prodotto viene messo nelle mani del cliente finale. Da un punto di vista tecnico le iterazioni continuano con uno o più rilasci (releases): beta releases, correzione di errori, nuove funzionalità, ..ecc. Tipicamente in quest’ultima fase verrà emesso un documento contenente l’analisi dei risultati del progetto tenendo in considerazione i suoi criteri di successo originali e quelli successivamente revisionati.
Da quanto detto deriva che l’organizzazione del team che deve sviluppare un progetto secondo il "Unified Software Development Process" deve essere la seguente.
* Nel corso della prima fase (Inception) l’attività deve essere svolta da un analista software di elevata competenza ingegneristica ed esperto del dominio del problema. Egli, nelle fasi successive, dovrebbe diventare il responsabile dell’intero sviluppo, poiché nella fase di avvio egli definisce per il sistema un insieme di requisiti centrali da rispettare, costituenti un impegno realizzativo che non può essere facilmente delegato ad altri. Nel caso di sistemi molto complessi egli può ricorrere alla collaborazione di un numero limitato di altri analisti da lui dipendenti. Se necessario in questa fase l’analista o i suoi collaboratori possono costruire dei prototipi del sistema, che però non avranno utilizzo nelle fasi successive.
* Nel corso della fase di elaborazione prosegue l’attività di analisi del dominio del problema eseguita dall’analista e dagli eventuali suoi collaboratori, fino alla definizione di un modello che possa essere considerato completo. Sulla base di questo essi devono inoltre realizzare l’architettura eseguibile del sistema, orientata, in un primo momento, alla copertura dei requisiti più critici, e, nelle successive iterazioni, ad una copertura tale da poterla stimare pressoché completa. L’architettura da realizzare deve essere funzionante, nel senso che deve dare una visione del sistema come se esso fosse in funzione, anche se i componenti software che devono eseguire i compiti del sistema sono per ora falsi (dummy), cioè sostituiti da moduli solo consumatori di risorse. La realizzazione dell’architettura completa del sistema presuppone un lavoro completo di progettazione, codifica e test di un programma e quindi richiede al team anche competenze pratiche nell’uso di tool, linguaggi, sistemi operativi, ..ecc. L’architettura del sistema, anche se di struttura generalmente complessa e condizionante tutti gli sviluppi futuri, non è in genere un programma di grandi dimensioni e richiede quindi un team ancora "smilzo". In definitiva la fase di elaborazione dovrebbe essere realizzata da un team composto da poche persone di elevata professionalità, condotte dallo stesso analista della fase di avvio; questi inoltre dovrebbe partecipare anche alle attività pratiche di sviluppo dell’architettura del sistema.
* Nella fase di costruzione, durante la quale vengono realizzati tutti i componenti dummy dell’architettura di sistema prodotta nella fase precedente, il team si ingrandisce notevolmente poiché, in questa fase, viene realizzata la gran parte del codice del sistema. In particolare in questa fase è possibile, per accelerare i tempi di sviluppo del sistema, far lavorare più sotto team in parallelo per la realizzazione di componenti diversi e poco interagenti. I realizzatori dei componenti possono essere di professionalità non molto elevata poiché devono realizzare programmi ben specificati e nella maggioranza dei casi di bassa complessità. E’ bene comunque che essi siano guidati dai componenti del team che ha sviluppato la precedente fase di elaborazione. Sempre questi ultimi avranno poi il principale compito di seguire l’attività di integrazione e test dei componenti nell’architettura.
* Infine, nella fase finale di transizione, il team comincia di nuovo a snellirsi poiché il codice del sistema è stato praticamente tutto realizzato e l’attività degli analisti che hanno eseguito e gestito tutte le fasi precedenti diventa saltuaria e conseguente solo alla rilevazione di problemi o alla necessità di ampliare le funzioni del sistema. In questa fase entrano a far parte del team persone con altre competenze per eseguire i compiti di marketing, controllo configurazione, redazione di monografie, ..ecc.
3.3.3.2 Il modello “eXtreme Programming (XP)”
Il modello eXtreme Programming (XP) [Bec 99] prevede anche esso, come il processo descritto nel precedente paragrafo, un approccio iterativo. Esso in particolare si applica alle fasi che sono state prima indicate come fasi di "Elaborazione" e di "Costruzione" ed è stato messo a punto per programmi realizzati in Smalltalk, tuttavia sembra facile una sua generalizzazione. Mentre lo Unified Software Development Process fa riferimento alla metodologia UML, il modello XP si caratterizza come una metodologia a se stante, con eventuali apporti, quando servono, da altre metodologie. Il modello XP è caratterizzato da una serie di regole comportamentali che, perché esso abbia successo, devono essere seguite puntualmente. Quello che segue è un elenco, non esaustivo, fatto senza necessariamente riferirsi a Smalltalk, di tali regole comportamentali:
* La pratica del testing deve essere molto accentuata. Lo sviluppo delle Unità di software (ad esempio una "Classe" in Smalltalk) deve comprendere un test finale coprente al 100%. A sua volta il prodotto che si costruisce in modo incrementale integrando le unità dopo il loro test deve essere provato in modo integrale con tutti i test funzionali, eventualmente da personale dedicato a tale scopo.
* Deve esistere una procedura che indica, in modo estremamente dettagliato, le modalità di scrittura del codice, ossia le regole di codifica (ad esempio quali costrutti utilizzare e quali no), lo stile di codifica (ad esempio come indentare gli statement), gli standard da seguire (ad esempio come costruire le "label" delle variabili). Questa procedura deve essere tassativamente seguita da tutti e deve rendere il codice facilmente leggibile e quindi immediatamente comprensibile. Questa leggibilità deve essere tale da permettere la pratica eliminazione della documentazione. Le metodologie di progettazione (ad esempio UML) e la relativa documentazione devono servire soltanto al momento dell’impostazione del lavoro di codifica, per raggiungere una visione comune e per il passaggio di informazioni. Dopo il lavoro di codifica questa documentazione non è più necessaria perché il codice è auto - documentante e inoltre, sicuramente, il codice evolverà, divergendo dalla documentazione, che, difficilmente, verrà aggiornata.
* Viene istituzionalizzato il lavoro in coppia. Ossia, una volta decisi in riunioni allargate ed appoggiandosi alla documentazione provvisoria, i requisiti allocati ad un componente, questo deve essere realizzato da due persone che lavorano congiuntamente. Tipicamente una di esse scrive, creando il codice al momento necessario, mentre l’altra osserva tenendo sotto controllo, allo stesso tempo, sia la strategia risolutiva globale che i dettagli minuti (errori di programmazione, di standard di codifica, di nomi, …ecc.).
* Altre regole comportamentali sono le seguenti:
Cercare di fare sempre la cosa più semplice e quello che al momento serve.
Risolvere i problemi facendo l’analisi passo passo del percorso che li causa, senza perdere tempo a cercare di capire a priori come accadono.
Evitare la proprietà del codice: le necessarie varianti ai componenti vanno realizzate da chiunque ne constata la necessità e non solo da chi ha originariamente realizzato i componenti stessi.
* Mentre alcune regole organizzative sono le seguenti:
Ruotare le persone del team da un’area del dominio del problema ad un’altra. Questo permette a tutti i componenti del team di avere una visibilità condivisa del progetto.
Far eseguire il rilascio giornaliero del codice scritto e provato. Se ciò non avviene vuol dire che si stanno verificando dei problemi nella produzione del codice.
Le iterazioni che portano agli incrementi funzionali del prodotto devono avvenire mediamente ogni 3 settimane. Questo è tecnicamente fattibile ed assicura un’ottima visibilità di come procede lo sviluppo del prodotto sia al management che, eventualmente, al cliente.
Da quanto sopra detto deriva che l’organizzazione del team che deve sviluppare un progetto secondo il modello XP non risulterebbe molto dissimile da quella descritta nel paragrafo precedente per il "Unified Software Development Process". Esistono però alcune differenze relativamente ai seguenti punti:
* In particolare nella fase di "Costruzione", nel caso della realizzazione di software di dimensioni non piccole, possono esistere più team in parallelo che operano per la realizzazione di tutti i componenti funzionali del software da sviluppare. Questi team non operano sulla base di documenti architetturali e di dettaglio ben consolidati e sottoposti a riesame, ma sulla base di una documentazione semplificata, generalmente concertata durante riunioni di lavoro. E’ quindi necessario che i team siano composti con persone di buon livello, in grado di dominare sia le tecniche di progettazione che il dominio del problema. Il modello XP non dà cioè molto spazio ad una parcellizzazione del lavoro e quindi non prevede in generale l’impiego di personale di bassa preparazione professionale.
* E’ comunque espressamente consigliato l’utilizzo di personale dedicato al test funzionale del prodotto, dai rilasci parziali che crescono incrementalmente fino al test del rilascio del prodotto finale.
* E’ poi richiesto in modo imperativo che lo sviluppo del codice venga fatta da persone che lavorano in coppia. Quest’ultimo aspetto organizzativo è forse quello che caratterizza, in modo particolare, il modello XP rispetto ad altri modelli.
3.3.4 Conclusioni
Attraverso l’analisi di alcuni modelli del tipo "cosa deve essere fatto" (CMM, SPICE) e di alcuni modelli del tipo "come deve essere fatto" (Unified Software Development Process, XP) si è derivata l’organizzazione aziendale, sia a livello generale che a livello di team di progetto, che viene indotta nel caso della loro adozione. Questa organizzazione è in definitiva quella che meglio si addice ad una struttura basata sui suddetti modelli e che quindi può dare i risultati migliori.
3.4 Lo sviluppo del software ed il controllo di qualità
La natura dello sviluppo del software, data la continua evoluzione tecnologica, la crescente complessità ed interdipendenza da fattori quali la piattaforma tecnologica su cui si basa o la persona che lo utilizza, così come il settore in cui se ne fa uso, hanno richiesto che laddove si sviluppi un sistema qualità in realtà orientate alla realizzazione di software vengano tenute in considerazione particolarità esclusive del settore.
3.4.1 Approcci diversi all’Assicurazione della Qualità nel software
La normativa
La trattazione teorica è incentrata soprattutto sulla qualità del prodotto software preso a sè stante. I modelli di qualità sono importanti per capire quali sono le caratteristiche rilevanti di un prodotto software, ma dal lato pratico, mediante le metriche oggi a disposizione, non è possibile ottenere delle misure univoche e complete, questo soprattutto per quanto riguarda le caratteristiche di qualità.
L'approccio delle normative si incentra principalmente sul processo di sviluppo del software. La qualità viene costruita attraverso il controllo del processo di sviluppo. A questo punto c'è un ulteriore suddivisione:
• le normative di tipo classico nelle quali questo controllo è rigido e spinto fino a prescrivere, in alcuni casi, i formati della documentazione (ad esempio le MIL)
• la normativa ISO che invece utilizza un tipo di controllo più flessibile
La normativa ISO, infatti, risulta applicabile indipendentemente dal modello di ciclo di vita utilizzato e pertanto non prescrive un dato processo di sviluppo.
Ogni normativa, per quanto elastica come la ISO, introduce sempre degli elementi di rigidità che mal si sopportano in azienda.
La necessità è perciò quella di rendere le procedure aziendali descritte nel Manuale della Qualità le più flessibili e nel contempo più rigorose possibili.
In tal senso è stata sviluppata, come riferimento, allo scopo di ridurre la soggettività dei parametri qualitativi per lo sviluppo di software il documento ISO/IEC 9126 in cui vengono riportate le caratteristiche di qualità del software.
Alcune di esse sono:
affidabilità
funzionalità
portatilità
efficienza
manutenibilità
usabilità
Altro documento che deve essere preso in considerazione come strumento integrativo nello sviluppo di un sistema qualità nel software è senz'altro l'ISO 9000-3.
Il software, come precedentemente esposto, è un prodotto atipico. Una via di mezzo tra un prodotto ed un servizio. Infatti è sicuramente intangibile e se da un lato è privo di costi significativi di produzione, dall'altro i costi progettuali diventano altissimi.
Altra caratteristica rilevante è la rapidità con la quale diventa obsoleto il che richiede un continuo lavoro di manutenzione evolutiva.
Quattro sono i fattori che determinano di fatto la qualità del software e sono:
organizzazione
personale
metodologie
strumenti di sviluppo
Ma mentre le metodologie e gli strumenti di sviluppo assumono una rilevanza secondaria,determinanti diventano le motivazioni del personale e soprattutto un'organizzazione orientata alla qualità
La norma ISO 9000-3 - Guida per l'applicazione della ISO 9001 allo sviluppo, alla fornitura, ed alla manutenzione del software è stata concepita specificatamente per essere utilizzata dagli sviluppatori di software.
Il suggerimento che ne possiamo trarre è quello di servirsi prima della norma ISO 9000-3 più vicina alla terminologia ed alle metodologie di sviluppo dell'ingegneria del software, allo scopo di verificare lo stato del proprio processo di sviluppo. Successivamente, per l'implementazione effettiva del Sistema Qualità è opportuno utilizzare la norma ISO 9001.
Contenuto delle sei sezioni che compongono la norma
Le prime tre sezioni riguardano la definizione dei suoi obiettivi e i riferimenti ad altre norme.
All'interno troviamo quattro sottosezioni che riprendono la norma ISO 9001
All'interno troviamo nove sottosezioni, le quali trattano le attività relative ad una o più parti del ciclo di vita del software. Alcune delle corrispondenti sezioni della ISO 9001 non appaiono sostanziali quando applicate al software.
Le attività di questa sezione, che vengono trattate in maniera molto più rispetto a quanto fatto nella norma ISO 9001, includono la gestione della configurazione, la misurazione, le regole, pratiche e convenzioni, e gli strumenti e tecniche.
Da All'interno troviamo quattro sottosezioni che riprendono la norma ISO 9001
All'interno troviamo nove sottosezioni, le quali trattano le attività relative ad una o più parti del ciclo di vita del software. Alcune delle corrispondenti sezioni della ISO 9001 non appaiono sostanziali quando applicate al software, se ne trae in forma sintetica (integrata con ulteriori elementi) alcune delle più importanti attività, relative allo sviluppo del software, da svolgere nell'ambito di un Sistema Qualità suddivise in:
attività relative al ciclo di vita
attività di supporto
procedure per lo sviluppo di software nella gestione del Sistema Qualità
Vengono di seguito analizzate le attività da svolgere nel corso del processo di sviluppo del prodotto software. Il riferimento è sempre la ISO 9000-3
Consiste in un insieme completo e non ambiguo di requisiti funzionali. I requisiti devono essere espressi in termini comprensibili al committente, al quale deve essere fornita tutta l'assistenza necessaria per evitare eventuali incomprensioni sulla terminologia adottata dal fornitore. Inoltre, i requisiti devono essere sufficientemente dettagliati da permetterne la validazione in fase di accettazione del prodotto software.
I requisiti funzionali devono essere definiti e documentati. Eventuali scostamenti dei medesimi dall'offerta iniziale devono essere risolti in questa fase. Solo successivamente si può procedere con le fasi seguenti dello svilupp, e la progettazione può così aver luogo.
Il piano di sviluppo, assieme alla specifica dei requisiti funzionali, è il documento fondamentale di ogni progetto. In esso devono comparire i seguenti elementi:
definizione del progetto (suoi obiettivi e descrizione dei progetti correlati
organizzazione delle risorse necessarie al compimento del progetto, incluse la struttura del gruppo di lavoro e le responsabilità
fasi del progetto (descrizione delle fasi del progetto, dei dati e requisiti necessari in ingresso ad ogni fase e dei risultati attesi in uscita da ogni fase)
programma temporale del progetto (descrizione di tutte le attività, delle loro interrelazioni e delle risorse richieste in termini di tempo, strumenti e personale)
identificazione dei piani correlati (piano di qualità, piano di gestione della configurazione, ecc.)
È questo un documento molto importante in un Sistema Qualità. Gli obiettivi di qualità devono essere identificati ed espressi in termini misurabili ogni qualvolta ciò sia possibile. Devono essere definiti criteri di ingresso/uscita per ciascuna fase dello sviluppo.
Devono essere definite le responsabilità specifiche per l'esecuzione di attività inerenti la qualità, quali riesami e test, gestione della configurazione e controllo delle modifiche, controllo dei difetti ed azioni correttive.
Le non conformità devono essere gestite tramite procedure standard, e le azioni correttive intraprese devono essere registrate.
Il piano di test deve essere preparato prima di intraprendere il test stesso, e deve contenere i seguenti elementi: casi di test, dati di test e risultati attesi, criteri per giudicare il superamento della prova. La progettazione e la realizzazione del prodotto software deve avvenire mediante metodologie stabilite. Ad esempio, per l'analisi dei requisiti si possono utilizzare le metodologie SAM - Structured Analysis Methodology, [De Marco, 1979], e SSADM - Structured System Analysis and Design Methodology utilizzata come standard dal governo britannico.
Spesso tali metodologie sono associate a strumenti automatizzati o CASE (Computer Aided Software Engineering).
Inoltre, i dati di progetto devono essere registrati, prevedendone l'utilizzo in esperienze di progetto future. La progettazione stessa deve avvenire in maniera da facilitare le attività successive, quali test, la manutenzione e l'uso.
I riesami consistono nella verifica del soddisfacimento dei requisiti specificati e nell'applicazione delle metodologie di progettazione stabilite. Se un riesame rivela delle deficienze, queste devono essere registrate e risolte prima di procedere con la realizzazione del prodotto.
Con l'accettazione il committente valida il prodotto, dichiarando che questo è conforme ai requisiti specificati e concordati con il fornitore all'atto della sottoscrizione del contratto. Anche l'accettazione ed il trattamento degli eventuali problemi insorti al momento della stessa devono avvenire tramite procedure precedentemente concordate.
La manutenzione, quando prevista dalle clausole contrattuali, deve avvenire secondo procedure pianificate e concordate con il committente. Sono quattro i tipi di manutenzione che si incontrano [Pressman, 1993]:
manutenzione correttiva
si riferisce all'attività di correzione degli errori individuati successivamente alla consegna del prodotto al cliente
manutenzione adattativa
è l'attività di adattamento del software a seguito dell'evoluzione dell'hardware o dei sistemi operativi in uso
manutenzione perfettiva
avviene con riferimento ad un package di successo. Infatti se il pacchetto s'impone sul mercato, allora è più probabile che il cliente senta la necessità di richiedere nuove funzionalità o di potenziare quelle esistenti
manutenzione preventiva
è dovuta alla necessità di modificare il software al fine di migliorarne la manutenibilità o, l'affidabilità futura, o di fornire una piattaforma migliore per future evoluzioni. È un'attività ancora poco frequente nel mondo del software.
Sono trasversali al ciclo di vita e non dipendono da una singola fase.
Il riferimento è sempre la ISO 9000-3
Ogni elemento software deve essere identificato, controllato, e deve poter essere rintracciato a partire da una data configurazione finale del prodotto software.
Dell'elemento software devono essere indicate:
organizzazioni coinvolte nella preparazione e loro responsabilità
strumenti, tecniche e metodologie impiegate. Questa attività consiste nello stabilire e tenere aggiornate le procedure necessarie al controllo di tutti i documenti in relazione alla norma.
Tali documenti registrano il conseguimento della qualità richiesta e l'efficacia del Sistema Qualità. Inoltre, devono essere correlabili al prodotto ai quali si riferiscono.
La misurazione deve avvenire anche per le caratteristiche di qualità (oltre che per quelle di produttività/costo) del processo e del prodotto, utilizzando le metriche che allo stato dell'arte più si adattano al caso in esame
Fra gli strumenti automatizzati che supportano l'intero ciclo di sviluppo software possiamo citare:
Cohesion - Digital Equipment Co.
Softbench - Hewlett Packard
DCycle - IBM
NSE - Sun Microsystems
L'addestramento, training, è una delle attività fondamentali del Sistema Qualità. Il personale coinvolto nel processo deve conoscere esattamente le proprie mansioni ed essere preparato per svolgerle. Si deve mantenere la registrazione del profilo professionale di ogni dipendente, comprendente tutte le attività di addestramento al quale è stato sottoposto e le esperienze maturate.
3.5 Esempio di gestione di un progetto software
Il Direttore Commerciale, in collaborazione con il committente o con un suo rappresentante, formula una bozza di contratto, che precede una sintesi degli obiettivi, risorse, costi, studio di fattibilità e tempi relativi al software che si vuole sviluppare.
Contestualmente, l'analista di sistema prepara le specifiche funzionali del software. Il documento di specifica dei requisiti include: il dominio delle informazioni, le funzioni, le interfacce, i criteri di validazione ed i vincoli di progetto del software da sviluppare.
A questo punto il Direttore Generale dà l'assenso alla prosecuzione del nuovo progetto.
La bozza di contratto verrà successivamente vagliata nella fase di riesame del contratto, allo scopo di definire e risolvere tutte le ambiguità e le variazioni nelle specifiche del prodotto.
Il piano di sviluppo è costituito da una parte progettuale e da una parte organizzativa. La prima parte, consistente nella definizione delle fasi del progetto e nell'identificazione dei piani correlati (piano della qualità, piano di gestione della configurazione, piano di prova e piano di integrazione) viene redatta dall'analista di sistema, il quale svolgerà anche la successiva fase di progettazione preliminare.
La parte organizzativa, riguardante l'organizzazione delle risorse ed il programma temporale, è invece compito del Direttore di produzione.
A questo punto il piano di sviluppo completo viene approvato dal Direttore Tecnico.
Questa attività è svolta dal Responsabile della Qualità.
In questo senso, la norma ISO 9001, punto 4.1, prevede la figura del Rappresentante della Direzione, il quale è responsabile per la qualità nei confronti dell'utente finale e risponde solo alla Direzione Generale.
Ricordiamo che il piano della qualità deve contenere:
• i criteri d'ingresso/uscita per ogni fase dello sviluppo
• la pianificazione delle attività di prova, verifica e validazione
• le responsabilità specifiche per i riesami e le prove
• la gestione della configurazione
• il controllo dei difetti e le azioni correttive
Nel processo di sviluppo, i punti di controllo sono le attività volte a determinare se sia possibile proseguire o se le fasi già svolte vadano meglio definite.
Il riesame del contratto è quindi il primo punto di controllo; avviene successivamente alle fasi di pianificazione e consiste in una o più riunioni. Il riesame viene condotto dalla Direzione Commerciale, in quanto riguardante le specifiche contrattuali concordate con il committente.
L'analista di sistema partecipa in ragione della propria conoscenza di ulteriori dettagli progettuali. Il Responsabile della Qualità partecipa anch'egli, allo scopo di assicurare il rispetto delle procedure vigenti in azienda; ed infine la Direzione Generale ed il committente approvano la nuova stesura del contratto
Possiamo suddividere l'attività di progettazione in due fasi:
• progettazione preliminare
si concentra sulla trasformazione delle specifiche software nell'architettura software (la rappresentazione della struttura modulare gerarchica del sistema software) e nell'architettura dei dati
• progettazione dettagliata
si focalizza sugli affinamenti della rappresentazione architetturale, che portano alla struttura dettagliata dei rati e delle rappresentazioni algoritmiche [Pressman, 1993].
L'attività di progettazione preliminare viene svolta solitamente dall'analista di sistema che ha redatto le specifiche funzionali del prodotto. Egli, inoltre, gestisce gli aspetti tecnici del progetto nel corso delle successive fasi dello sviluppo, coordinando le esigenze del committente di verifica e cambiamento dei requisiti funzionali con le esigenze di pianificazione e gestione delle risorse che invece ha il Direttore di Produzione. In tal modo l'analista di sistema assume anche il ruolo di account manager; tale ruolo può essere potenziato, includendo ad esempio compiti formalizzati di gestione della configurazione
È questo il secondo punto di controllo, ed ha lo scopo di controllare la consistenza dei dettagli di progetto necessari alla produzione prima di procedere con la fase di progettazione dettagliata. Questo riesame viene condotto dalla Direzione Tecnica, con la partecipazione dell'Analista di Sistema che ha effettuato la progettazione e con la presenza del Responsabile della Qualità per verificare la rispondenza del progetto preliminare alle prescrizioni qualitative.
La progettazione dettagliata viene svolta dai capi progetto della produzione. Essi hanno un doppio riferimento: l'Analista di Sistema per quanto riguarda gli aspetti tecnici ed il Direttore di Produzione per quelli organizzativi. Il loro compito è quello di tradurre la progettazione preliminare in componenti software testati e nel rispetto dei tempi previsti.
Il riesame viene svolto dall'Analista di Sistema responsabile della conduzione tecnica di quel progetto. Il Responsabile della Qualità presenzia per verificare il rispetto del piano di sviluppo e di quello della qualità approvati per quel progetto. Anche il Direttore della Produzione partecipa al riesame, in quanto responsabile dell'organizzazione e gestione del progetto stesso.
La codifica ed il test sono le attività che i programmatori effettuano sotto il controllo dei capi progetto. Il risultato di questa fase è un codice testato a livello di singola unità.
Inoltre i capi progetto hanno un ruolo fondamentale nel mantenere la configurazione del singolo componente software sotto controllo. Questo compito consiste nel controllo delle versioni di ogni singolo componente software e di come questi si integrano per formare una nuova versione del prodotto finale. L'approvazione delle nuove versioni di ogni componente software (siano essi programmi o documentazione) viene fatta dall'Analista di Sistema responsabile della conduzione tecnica di quel progetto. Anche il Direttore della Produzione ha un ruolo in questa attività, ed è quello di coordinare la gestione della configurazione su più progetti.
Seguendo lo schema del piano di prova già presente nel piano della qualità, il Responsabile della Qualità prepara i piani dettagliati di prova, che comprendono le prove di unità, d'integrazione e di sistema.
La documentazione include anche i casi di prova, i dati di prova, i risultati attesi, gli ambienti e strumenti software di prova ed i criteri per considerare le prove superate.
La prova e validazione è un'attività di assicurazione della qualità essenziale. Questa può essere svolta in due fasi.
• Prima fase
il capo progetto con la supervisione del Responsabile della Qualità, effettua le prove d'unità e d'integrazione prescritte nel piano di prova.
• Seconda fase
l'Analista di Sistema che ha redatto le specifiche funzionali e svolto la progettazione preliminare di quel prodotto effettua anche le prove di sistema e la validazione.
La validazione ha lo scopo di verificare che il prodotto software nella sua versione completa sia conforme ai requisiti specificati, e quindi coinvolge anche il Direttore Commerciale in qualità di rappresentante del punto di vista del committente. Il compito del Responsabile della Qualità è quello di fornire una verifica indipendente della rispondenza del prodotto ai requisiti specificati.
È questa in pratica un'attività di validazione, ma svolta dal committente e quindi con valore contrattuale. Le procedure per l'accettazione devono essere previste nel contratto, e devono venire seguite. L'eventuale introduzione di modifiche dei termini di accettazione rende consigliabile l'approvazione di questa fase da parte della Direzione Generale.
La misurazione è un'attività importante prescritta dalla norma ISO 9000-3.
Avviene in corrispondenza delle attività di progettazione preliminare e dettagliata (numero di specifiche prodotte, tempo, ecc.), codifica (LOC/tempo e documentazione/LOC), prova (difetti/LOC).
La misurazione avviene anche dopo il rilascio (MTTF, MTTR, difetti, LOC).
Per la raccolta dei dati indicati dal piano della qualità, possono essere incaricati i capi progetto. Successivamente il Responsabile della Qualità opera una sintesi di tali dati, allo scopo di renderli più significativi. Il compito del Responsabile della Qualità è infine quello di predisporre le procedure e gli strumenti per la misurazione, e quindi controllare che tutto proceda nella maniera stabilita.
Le metriche più semplici che possono essere scelte sono quelle di produttività, costo e qualità.
Capitolo 4
La conferenza e le interviste
4.1 La conferenza
L’Istituto Tecnico Industriale Statale “J. F. Kennedy”, con la collaborazione dell’Associazione Industriali della Provincia di Pordenone, ha organizzato ed ospitato una conferenza sul tema “La certificazione di qualità”. Anche gli allievi della classe “V A Informatica“, interessati a questo lavoro per l’area di progetto, hanno partecipato a tale conferenza, insieme ad altre classi quarte e quinte dell’Istituto.
Tale conferenza è stata organizzata con lo scopo di avvicinare la scuola alle realtà produttive presenti sul territorio, desiderose di incontrare gli studenti degli ultimi anni in quanto consce che fra queste giovani persone dovranno cercare nuove risorse umane per le proprie organizzazioni produttive.
La conferenza è stata presieduta dall’Ing. Antoniolli, Presidente dell’Associazione Industriali ed è stata condotta dal Responsabile del Settore Qualità della ditta Mercury di Caneva (PN), azienda che opera nel settore dell’arredamento, ampiamente presente nel mercato estero.
Sia l’Ing. Antoniolli, che il Responsabile della Mercuri, hanno posto l’accento sui seguenti temi:
- definizione del concetto di qualità, per altro non diverso da quanto presentato in questo lavoro;
- la “ricerca della qualità” in azienda è diventata in questi ultimi anni l’obiettivo principale delle aziende, soprattutto di aziende che si rivolgono al mercato estero, come quelle presenti nella nostra zona;
- la “conquista di un alto livello di qualità” si può ottenere solo se tutti gli elementi aziendali, dal più importante al più semplice, sono concordi nell’operare secondo il “sistema di qualità” che l’azienda si è data;
- il “mantenimento di un alto livello di qualità” si può ottenere solo se il processo aziendale è alla continua ricerca di un miglioramento;
- le aziende ricercano nelle nuove leve quello spirito critico, innovativo, di curiosità e di freschezza per poter lavorare con l’entusiasmo necessario a mantenere in vita il sistema di qualità aziendale.
Durante la conferenza il Responsabile del Settore Qualità della Mercury ha poi portato un esempio di progettazione di un elemento di arredamento, come azione pratica aziendale eseguita nel rispetto di quanto definito dai sistemi di qualità.
4.2 Le interviste
Con l’obiettivo di non lasciare gli argomenti trattati in questo lavoro solo teorici, ma poterli calare nella realtà, con l’opportunità di considerare le inevitabili differenze fra quello che è pura teoria e quello che invece è vita di tutti i giorni, sono state organizzate delle visite a quattro aziende della Regione o di zone confinanti.
Le interviste sono state fatte al responsabile della produzione o del controllo di qualità, questo per poter meglio chiarire la differenza fra letteratura ed azione sul campo.
Le aziende visitate sono state quattro: una del settore dell’arredamento, una azienda di carpenteria speciale, due aziende di produzione software.
4.2.1 Alla Fosam S.p.A
La prima azienda da noi visitata è stata la ditta “Fosam” a Fiume Veneto, un’ azienda, che produce nel settore dei mobili per ufficio, la quale possiede il certificato di qualità da
quasi due anni.
Ad esporci il rapporto che l'azienda ha con il concetto la qualità è stato il signor Zanin, il responsabile della produzione, il quale era molto preparato sull’argomento ed estremamente convinto della politica della sua azienda in merito a quello che lui definiva un vero modo di operare aziendale.
Il signor Zanin ha iniziato parlandoci della certificazione di qualità, tale certificato è
stato rilasciato alla Fosam anche grazie ad una consulenza esterna, prestata da una ditta che guida le aziende decise a raggiungere tale obiettivo nel difficile percorso che esse devono percorrere per ottenerlo, ma soprattutto grazie alla volontà aziendale di produrre con qualità.
Il sig. Zanin ha affermato che per la ditta presso cui lavora è particolarmente importante avere questa certificazione, in quanto è sicuramente un prestigio aziendale, ma lo è soprattutto perché permette di partecipare alle gare di appalto.
Dopo, egli ha cominciato a descrivere il loro modo di operare in modo da garantire standard di qualità prefissati, specificando che per la sua azienda questo significa, alla fine, dare un servizio sempre migliore al cliente.
Per il loro sistema di qualità aziendale è stato creato un manuale interno sulla qualità che coordina tutte le attività sia operative sia di governo, nel quale vengono descritte minuziosamente tutte le procedure interne sia di produzione, che di test sulla stessa, che di acquisizione e controllo di ordini clienti, che di emissione di ordini fornitori con relativo controllo della merce in arrivo.
Alla Fosam sono molto entusiasti del loro sistema di qualità perché in questi ultimi due anni si sono accorti che la qualità paga, cioè, ci racconta il signor Zanin, ci sono meno guasti e resi da clienti, si è costruita una buona immagine dell'azienda.
Infine dopo aver esposto tutto quello che riguarda il rapporto aziendale instaurato con il concetto di qualità, il signor Zanin, con orgoglio, ci ha fatto visitare l'azienda facendoci vedere alcuni processi operativi descritti in precedenza e dettagliati nel manuale della qualità.
4.2.2 Alle Officine Stefanuto S.p.A.
La seconda azienda da noi visitata è stata la ditta “Officine Stefanuto”, con sede a Portogruaro (VE). Si tratta di un’ azienda, certificata da diversi anni, che produce oggetti molto particolari di carpenteria metallica, realizzati su commessa del cliente.
L’intervista è stata fatta al Sig. Marco Coatto, responsabile del sistema informativo e del controllo di gestione, una persona estremamente giovane ed entusiasta del processo di produzione aziendale, ma anche conscia della necessità di un continuo affinamento per una migliore organizzazione aziendale.
Il signor Coatto, è estremamente esperto sulla normativa della certificazione, perché l’azienda presso il quale lavora produce oggetti particolari e delicati, soprattutto per l’esercito e per enti di ricerca, i quali necessitano che i propri fornitori siano obbligatoriamente certificati, vista la criticità delle forniture.
La gran parte dei prodotti che escono da questa grossa carpenteria, sono costruiti su disegno fornito dal committente, è quindi facile immaginare come sia decisivo un controllo di qualità che guidi la produzione dei pezzi, i quali devono corrispondere in modo estremamente preciso alle specifiche del cliente.
L’azienda, che abbiamo volentieri visitato, non è molto grossa e si respira l’aria di un grosso laboratorio artigianale, purtroppo non siamo riusciti a conoscere il capo della produzione, il quale è stato chiamato dal Sig. Coatto “il maestro”, perché non era presente in quel momento. Proprio per questo non è difficile immaginare che, anche per questa azienda, la certificazione di qualità sia si un formalismo per l’esterno, ma soprattutto una formalizzazione di processi di controllo già presenti e ben radicati.
4.2.3 Alla Alfa Con s.r.l.
La terza azienda da noi visitata è stata la ditta “Alfa Con s.r.l”, con sede ad Udine, è un’ azienda che fornisce sistemi informatici gestionali.
L’intervista è stata fatta al Dottor Enzo Re, responsabile del settore di produzione software, il suo settore è attualmente impegnato nella realizzazione di un grosso pacchetto gestionale, in collaborazione anche con Microsoft. L’azienda non possiede un certificato di qualità, ma il Dottor Re è estremamente sensibile rispetto a questo argomento, il quale lo interessa non solo da un punto di vista della sua attuale occupazione, ma anche personalmente, infatti ci spiega che nella sua tesi di laurea aveva trattato la metrica di MacCabe, nell’ambito della qualità del software.
Le domande che gli sono state rivolte sono qui di seguito riportate, ciascuna seguita dalla risposta dell’intervistato.
D: “Che cosa si intende con il termine qualità nel software?”
R:”Esistono diversi fattori di qualità del software, possiamo citarne alcuni: l’affidabilità, la robustezza e la sicurezza, la correttezza, …, ma a mio avviso la caratteristica più importante che deve avere un codice software per essere definito di buona qualità è senza ombra di dubbio la riusabilità. Se un codice è riusabile, si ha la possibilità che un’applicazione non venga sviluppata partendo ex-novo, ma impiegando componenti esistenti che vengono assemblati; facendo uso di componenti riusabili standard affidabili, non solo i nuovi sviluppi avvengono a costi più bassi, ma anche la relativa affidabilità è più elevata.
Il problema grosso è che è veramente molto difficile che un codice possa essere riusabile, per esserlo deve essere scritto veramente in modo intelligente, cioè pensandolo nel modo più generalizzato possibile ed ovviamente deve essere privo (o quasi) di errori, e cosa estremamente importante, deve essere documentato, in modo da essere certi che lo si sta riutilizzando in modo corretto e coerente.
Ritengo che l’approccio object oriented, relativamente nuovo, sia estremamente valido per la definizione e produzione di buon codice. Questo approccio permette di porre l’attenzione sulle caratteristiche fondamentali che un pezzo di codice, visto come una black box, deve fornire all’esterno.
Inoltre un codice così deve essere scritto in modo consono alle regole aziendali, in modo che sia facilmente comprensibile e modificabile all’occorrenza.”.
D:”Quanto sono importanti per voi le attese del cliente?”
R:”Sono naturalmente decisive. Riuscire a consegnare il codice puntualmente e secondo le specifiche decise con il cliente è ovviamente l’obiettivo principale, soprattutto dal punto di vista di immagine ed economico”.
D:”Avete adottato un qualche sistema di controllo della qualità nella vostra
azienda, e se si, in che cosa consiste?”
R:”Sono state decise delle regole precise relative alla scrittura del codice, cioè degli standard di produzione del codice software, ed il controllo di tali regole è demandato a ciascun capogruppo di ogni gruppo di produzione”.
D:”Visto che esiste un processo di controllo di qualità, questo viene applicato a
tutto il processo produttivo, e viene seguito?”
R:”Si, è quello descritto sopra, viene disatteso solo in qualche occasione, consapevolmente e per decisione aziendale, dopo un’accurata valutazione costi/benefici, magari per il completamento di una commessa non posticipabile; può capitare che il codice scritto disattendendo tali regole venga poi interamente riscritto, perché si è consci che non è di buona qualità e potrebbe, con elevata probabilità generare grossi problemi”.
D:”Quando e come ci può essere un connubio tra un sistema di produzione software che produca software corretto, affidabile e robusto e contemporaneamente con alte
prestazioni (del sistema di produzione software)?”
R:”Solo se le regole di produzione del codice sono ben stabilite, accettate e quindi non disattese, è possibili produrre buon codice ed in modo conveniente”.
D:”Come fate a capire se quanto il prodotto soddisfa la clientela?”
R:”Dal tipo di ritorni che ha il codice”.
D:”Quanto influisce il processo per il controllo di qualità, o parte di esso
(esempio solo la fase di test "standardizzata") sul prezzo finale del
prodotto?”
R:”E’ estremamente difficile dirlo, ma se si tiene conto che un buon codice può essere riutilizzato e non deve essere rifatto perché già da subito centra le esigenze del cliente finale, già diviene un grosso investimento”.
Il Dottor Re ha concluso l’intervista ponendo l’accento su quanto sia importante coinvolgere attivamente le persone che sviluppano software.
4.2.4 Alla Usable Net
La quarta azienda da noi visitata è stata la ditta “Usable Net”, con sede ad Udine E’ un’ azienda che produce codice per il controllo di codice già realizzato; più precisamente produce software per il controllo delle pagine ipertestuali da rendere disponibili in Internet. Si tratta quindi di un’azienda estremamente innovativa, composta da persone di elevata cultura informatica.
La persona intervistata è il Sig. Alessio Milan, responsabile del settore ricerca e sviluppo. Si tratta di una persona che lavora nel settore della produzione del software da moltissimi anni, con una decennale esperienza nella produzione di software per procedure di libreria (un lavoro estremamente critico).
Il suo attuale incarico lo porta a lavorare in un ambito “di frontiera” particolarmente interessante, ma ovviamente poco “consolidato”.
Il modello di produzione software che la sua azienda segue in questo momento è quello prototipale. I vantaggi di questa tecnica, ci spiega il Sig. Milan sono, per questo campo d’azione molteplici: in primo luogo il prototipo permette di testare in modo quasi immediato se le esigenze del cliente sono state colte oppure disattese, inoltre, esiste sempre un prodotto software che può essere consegnato, anche se consapevolmente potrebbe non essere questo la sua versione definitiva (al limite potrebbe essere anche interamente riscritto con l’utilizzo di una tecnologia differente).
Secondo la sua opinione, esiste da sempre e probabilmente esisterà sempre, un gap tra un codice “perfetto” e le risorse per realizzarlo. Si deve quindi partire dal presupposto che il codice che viene prodotto, rilasciato e poi utilizzato è sempre un compromesso fra un codice ottimo ed un codice realizzabile con le risorse messe a disposizione. Per assurdo il “codice ottimo” anche se fosse prodotto non sarebbe utilizzabile perché troppo costoso (non vendibile) o rilasciato troppo tardi rispetto alle esigenze.
L’esigenza fondamentale, da cui non si può prescindere, per la produzione di codice “accettabile” dal punto di vista della bontà, è invece il processo di produzione del codice. Non si può produrre codice software di qualità accettabile se il processo di produzione non è consolidato, o perlomeno se le competenze per la produzione dello stesso non sono ben delineate. In un processo di produzione ben definito, si deve sempre essere in grado di individuare chi deve occuparsi della risoluzione di un problema presente nel codice software.
Bibliografia
[ 1 ] Claudio Peri, Qualità: Concetti e Metodi, FrancoAngeli (1998);
[ 2 ] Bernardo Nicoletti, Assistenza tecnica e qualità totale, FrancoAngeli (1995);
[ 3 ] Malarie A. Zeithanel, A. Parasuraman, Leonard L. Berry, Servire qualità, McGraw-Hill (1989);
[ 4 ] Pieradolfo Venturi, Il manuale integrato della qualità, Il Sole24Ore (1998);
[ 5 ] Erika Leonardi, Capire la qualità, Il Sole24Ore (2000);
[ 6 ] Andrea Chiarini, Sistemi Qualità in conformità alle norme ISO 9000, FrancoAngeli (1999);
[ 7 ] James L. Lamprecht, L’applicazione delle norme UNI EN ISO 9000 nelle piccole aziende, FrancoAngeli (1997);
[ 8 ] Laura Carpanese, Franco Ceccarello, La clinica dell’impresa, Edizioni Sapere (1997);
[ 9 ] Dario Ferrari, Progettare un sistema qualità orientato alla VISION 2000, FrancoAngeli (2001);
[ 10 ] A Lisson, Qualità La sfida degli anni novanta, Casamassima (1990);
[ 11 ] A. Fuggetta, C. Grezzi, S. Morasca, A. Morzenti, M. Pezzè, Ingegneria del Software, Mondatori Informatica (1997);
[ 12 ] Pressman, Principi di ingegneria del software, McGraw-Hill (2000);
[ 13 ] E.E. Anderson, “A Heuristic for Software Evaluation and Selection”, Software – Practice and Experience (1989);
[ 14] B.W. Boehm, Software Engineering Economics, Englewood Cliff (NJ), Prentice Hall, (1981);
79
3
Istituto Tecnico Industriale Statale
J. F. Kennedy Pordenone
