Approfondimenti
Evoluzione della qualità
Il concetto di Qualità non è mai stato un concetto statico.
Rispetto
al campo di applicazione, questo si è esteso dal settore militare, ad
alcuni settori industriali (a partire dall’industria del nucleare),
fino alle più diffuse applicazioni nell’ambito delle piccole e medie
aziende.
Dal punto di vista dell’ambito di applicazione e dei
principali obiettivi, i passaggi più significativi nella storia della
qualità sono stati:
- 1920: Ispezione finale (Controllo sul prodotto)
- 1950: Controllo di qualità (Controllo sul prodotto)
- 1960: Assicurazione di Qualità (Controllo sull’organizzazione di produzione)
- 1970: Assicurazione del prodotto (Controllo sul progetto e sulla organizzazione di produzioni ad alto rischio)
- 1980: Qualità Totale (Miglioramento continuo)
- 2000: Sistema Qualità e Assicurazione Prodotto (Modo di gestione dell’Azienda e del Prodotto)
L’evoluzione si è sviluppata secondo alcune direzioni principali:
- da problema settoriale a problema aziendale
- da preoccupazione tecnica a preoccupazione globale
- da orientamento al passato (ispezione) a orientamento al futuro (miglioramento continuo)
- da costo a investimento.
(da 'La qualità dei prodotti e servizi IT' di Alfonso Fuggetta)
Le ragioni percambiare
Le
ragioni per muoversi verso la qualità possono nascere da problemi o da
aspettative, da richieste esterne o da decisioni strategiche.
La motivazione principale dovrebbe essere la volontà di miglioramento dei processi e dei prodotti/servizi forniti.
Un esempio di tabella ragionata dei motivi per cambiare, dal punto di vista di:
- motivi interni del personale,
- motivazioni di business,
- motivazioni strategiche.
Il problema della qualità del software
Uno dei tanti articoli introduttivi sul problema della qualità del software.
L’autore,
indiano, parte da un dato numerico preoccupante (solo il 16,2% dei
progetti software viene completato nei limiti di tempo e di budget
previsti) per definire il concetto di qualità del software (secondo la
ISO 9126) e descriverne le principali problematiche.
Interessante il
parallelo con altre branchie dell’ingegneria, ed in particolare
l’evidenziazione delle differenze fra la costruzione di un ponte e di
un prodotto software, così riassumibile:
- l’ingegneria ha 3000 anni
di esperienza nella costruzione di ponti, contro i 30 anni di
esperienza dell’informatica nella produzione del software
-
l’ingegneria si appoggia su solide basi teoriche nel campo della
fisica, mentre l’informatica si deve accontentare di alcune conoscenze
teoriche nel campo della logica e della struttura del software
-
l’ingegneria costruisce il ponte a partire da modelli precisi e da un
progetto basato su formule matematiche ben precise e su requisiti ben
specificati, mentre l’informatica difficilmente parte da progetti ben
definiti e stabili
- la conoscenza della tolleranza e delle capacità
di carico di un ponte è completamente definita prima di iniziarne la
costruzione, mentre è molto difficile prevedere le prestazioni di un
prodotto software prima della conclusione
- eventuali fallimenti
nella costruzione del ponte sono analizzati e investigati fino a
determinarne con precisione le cause, mentre i fallimenti dei progetti
software sono nascosti o comunque ignorati.