1

Gestione della Qualità

II parte

La produzione del software: metodologia e standards

Scopo di questa parte del corso

• Impostare un progetto software• Scegliere il giusto processo• Garantire la qualità\Valutare la

qualità• Esempio di gestione di un progetto

2

Programma

• Il processo di produzione del software

– Modelli di sviluppo – Processi della produzione del software basati su un

modello di sviluppo– Requisiti software e loro specifica– Principi di progetto– Strumenti di specifica e di progetto per garantire la

qualità– Il ruolo della qualità nel processo di produzione– Verifica statica e dinamica– Il costo della qualità

Programma • Modelli per la qualità del software

– Maturità del processo– Il miglioramento del processo– Standards di qualità: ISO 9000-2000, ISO 12207, ISO 9126,

ISO 15504, SEI-CMM– Metriche per la misura di qualità: del processo, del prodotto.

Metriche per la reliability, per la maintenance, per la availability.

• Un programma per la garanzia della qualità (Qualityassurance) – Il giusto processo da scegliere– I giusti strumenti– Il caso di software con particolari caratteristiche: applicazioni

critiche, applicazioni amministrative, applicazioni embedded.• 12 ore di esercitazioni (2 X 6 settimane) in cui si svolge

un progetto.

3

Riferimenti

• Diapositive • http://www.swebok.org• Articoli interessanti

Introduzione

Qualità del processoQualità del prodotto

4

Software

Computer Programs, Procedures, and possiblyassociated Documentation and Data pertaining to the operation of a computer system

“IEEE Std.610.12-90”

Programmi, Procedure, regole e ogni altradocumentazione relativa al funzionamento di unsistema informatico.

“ESA Software Engineering Standard, 1991”

Situazione iniziale• Il software è un prodotto “artistico”• I computer sono usati per “computare”

– si risolvono problemi matematici– progettisti = utenti– breve tempo di vita

• L’arte della “programmazione”– linguaggi a basso livello– limitate risorse (velocità di calcolo e memoria)

esempio programmi di scacchi

5

Dall’arte all’artigianato• Dal puro calcolo alla gestione delle informazioni• Dilaga la richiesta di software per nuove esigenze

– utenti ≠ progettisti– sorgono le software houses

• Nuovi linguaggi di programmazione “ad alto livello”• Primi grossi progetti e primi fallimenti,

essenzialmente di due tipi:– limiti di tempo saltati, budget sforato, cooperazione umana assente – specifiche sbagliate

Dall’artigianato all’industria

• Sviluppo di metodi e standards• Pianificazione e gestione • Automatizzazione di buona parte delle

procedure • Qualità verificabile• Sviluppo modulare•….

6

Il software è un prodotto industriale

• Industria: produzione organizzata– Per produrre “in grande” (per dimensione o

volume)– Per assicurare la qualità dei prodotti– Per garantire l’efficienza della produzione

• Tipologie di prodotti software– Software su commessa– Pacchetti software– Componenti software– Servizi su sistemi e dati

Un settore in crescita

• Rivoluzione informatica– Cambiamenti radicali nel modo di lavorare– Trattamento di informazioni altrimenti

impossibile– Benefici indiscutibili implicano un processo

inarrestabile• La nuova economia

– Nuove professionalità (e nuove esigenze di formazione)

– Nuove opportunità d’impresa legate allo sviluppo tecnologico

7

Un settore in crescita

• L’industria mondiale del sw è cresciuta negli anni ’90 a tassi di almeno il 10% annuo (dal 2001 è scesa al 3%)

• Molti nuovi servizi di rete si basano su innovazioni tecnologiche software (es. aste online, ecc.)

Dati quantitativi

• Come cresce la dimensione dei sistemi software– 1962 Mercury 1.000.000 LoC– 1965 Gemini 3.000.000 LoC– 1969 Apollo 11.000.000 LoC– 1981 Shuttle 37.000.000 LoC– 1990 Hubble 82.000.000 LoC– Un telefonino contiene 5+ MLoC (fonte Nokia)– Windows XP contiene 40+ MLoC (Windows 95: 11

MLoC)• Quanto spende una nazione industrializzata

– Mld € 2.56, la P.A. italiana per il 2001 (+95% risp. 2000)

– Mld € 1.02 per spese correnti (1.54 per investimenti)

8

Caratteristiche dell’industria ICT

• L’industria ICT è di tipo “orizzontale”: i sistemi informatici moderni vengono costruiti scegliendo i componenti preferiti in un mercato organizzato per fasce orizzontali (grazie agli standard)– Servizi di rete: ISP, Web hosting, Application server,

ecc.– Vendita e distribuzione: negozi, superstore, dealer on-

line– Applicazioni: Office, Netscape, SuperMarioBros, ecc.– Middleware: .NET, CORBA, XML/Web-based, ecc.– Sistemi operativi: Windows, Linux, MacOS, ecc.– Computer: IBM, HewlettPackard, Dell, Compaq, ecc.– Processori: Intel, Motorola, ecc.

Come si acquisisce il SW• È molto semplice comprare hardware; acquisire il software "giusto" per risolvere un certo compito è di solito più difficile– comprare un programma– affittare un programma– costruire un programma da soli– far costruire un programma a qualcun

altro

9

Software: un prodotto speciale

• È invisibile e intangibile• È facilmente duplicabile e distribuibile su rete• In Europa non è in sé brevettabile (ma protetto)• Viene acquisito su licenza

– Proprietaria (normale, shareware, freeware)• software commerciale (Es. www.microsoft.com)• software shareware (Es. www.shareware.com)• software freeware (Es. Linux, www.linux.org)

– Public domain• software public-domain (es. www.download.com)

– Open source

Garanzie sul SW

• Garanzie possibili– La verifica garantisce l’aderenza ad

una specifica– La validazione garantisce

l’accettazione da parte del cliente– La certificazione garantisce

l’aderenza a specifiche definite dalla legge

10

Protezione legale del SW

• Protezione del compratore: – Quale protezione ha il compratore da

difetti del prodotto?– Nel software di consumo in teoria NON

c’è alcuna protezione. Il software viene venduto “così com’è”, senza garanzie, e se ci sono difetti il fabbricante non se ne fa carico: lo dice il contratto che si visualizza quando si usa per la prima volta un’applicazione

Protezione legale del SW

• Protezione dell’autore:

– Il software è un’opera dell’ingegno: chi lo produce è un autore che ha diritto ad un compenso

– Copiare software abusivamente è illegale (anche se non lo si fa per profitto) e in Italia costituisce un reato penale

– La legge italiana 248/2000 punisce col carcere da 6 mesi a 3 anni chi duplica abusivamente software

11

Software: un servizio

I costi del SW

• I costi software spesso dominano i costi di produzione di un sistema. In particolare, i costi software sono spesso maggiori dei costi dell’hardware sottostante.

• Il costo di sviluppo di un programma cresce col quadrato delle sue dimensioni [Berra-Meo 2001 ]

12

Problemi dell’industria software

• I progetti software spesso sono in ritardo– Difficoltà nelle fasi iniziali dei progetti– Cambi di piattaforma e tecnologia– Difetti nel prodotto finale

• A volte falliscono clamorosamente– Per obsolescenza prematura– Per incapacità di raggiungere la

conclusione– Per esaurimento dei fondi

La produttività dell’industria software è bassa

• Da un’analisi di 13.522 progetti di costruzione di sw:– 66% di tutti i progetti falliscono (non hanno risultato utile)– 82% dei progetti superano i tempi previsti– 48% dei progetti producono sistemi senza le funzioni richieste dai clienti– 55 miliardi $ di spreco considerando solo i progetti USA

Standish Report 2003

13

Una soluzione ingegneristica

• Aspettative deluse e promesse mancate– I successi del software generano grandi

aspettative– Gli insuccessi generano clamore e delusione– Crisi del software: il software è una strada

sbagliata?• Ingegnerizzare prodotto e produzione

– La strada è giusta, la stiamo percorrendo male– L’industria del software ha bisogno di metodi

From art to industryTerm “software engineering” defined in a NATO conference in Garmisch, Oct. 1968

Approccio ingegneristico: evoluzione

• Fase “artistica”: soluzioni ad-hoc• Intuizione • Approccio “amatoriale”• Continuo ciclo inventa/reinventa

(lenta trasmissione della conoscenza)• Struttura organizzativa e gestionale + tecniche

di produzione • Esiste una produzione routinaria che da’ origine

a due corpi di conoscenza– Scienza di..– Ingegneria …– e produce una pratica migliorata

14

Il ciclo di vita ingegneristico

Nuovi problemiSoluzioni ad-hoc

Folklore(solutioni parziali, euristiche)

Codifica (procedimenti sistematici)

Modelli&TeoriePratica migliorata

Azioni proprie dell’ingegneria

• Progetto routinario– soluzione di problemi noti– riuso di soluzioni precedentemente trovate

Le discipline ingegneristiche mature hanno la caratteristica di catturare, organizzare e condividere la conoscenza di progetto

• Progetto innovativo– nuove soluzioni per problemi nuovi

•

15

Cos’è l’Ingegneria del Software?

• L’approccio sistematico allo sviluppo, all’operatività, alla manutenzione e al ritiro del software. (Glossario IEEE)

• Approccio sistematico• Il software è un prodotto con un proprio

ciclo di vita

Manutenzione

• I prodotti SW hanno bisogno di manutenzione a causa del cambiamento– Perfettiva (65%): miglioramenti del prodotto– Adattiva (18%): risposta a modifiche ambientali– Correttiva (17%): correzione di errori scoperti

dopo la consegna• E’ più costoso mantenere il software che

svilupparlo. Nel caso di sistemi con vita duratura, i costi di manutenzione possono essere un multiplo dei costi di sviluppo.

16

Cos’è l’Ingegneria del Software?

• Technological and managerial discipline of software products that are developed and modified on time and within cost estimates (R. Fairley 1985)

• L’ingegneria del software si preoccupa di produrre software con costi “accettabili”.

Disciplina gestionaleControllo della qualità: costi e risultati definiti

Cos’è l’Ingegneria del Software?

• L’Ingegneria del Sw (Software Engineering) è una disciplina metodologica, cioè studia i metodi di produzione, le teorie alla base dei metodi, e gli strumenti efficaci di sviluppo e misura della qualità di sistemi software complessi

• E’ tuttavia anche una disciplina empirica, cioè che deve essere basata sull’esperienza e sulla storia dei progetti passati

17

Perché l’Ingegneria del SW è difficile?

• Fattori di complessità– Aspetti psicologici e organizzativi– Scarsa formazione specifica sulla produzione SW– Innovazione tecnologica rapidissima– Competizione internazionale

• Principali cause di fallimento: project management inadeguato, requisiti sbagliati, progettazione mediocre

• Parti interessate con interessi e punti di vista diversi

• Molti progetti partono assumendosi rischi alti e poco analizzati

Parti interessate (stakeholders)

• Tipi di stakeholders– Progettisti professionisti– Management– Personale tecnico– Utenti– Finanziatori– …

• Ad ogni stakeholder corrisponde almeno un diverso punto di vista (view)

18

Ingegneria del Software e Ingegneria traditionale

Il software è spesso trattato come qualcosa da progettare da capo piuttosto che riutilizzando cose già fatte

– in questo modo non si cattura ed organizza la conoscenza già acquisita

• L’ingegneria del SW è ancora praticata (e pensata) in modo non sistematico

• È meno stabile e organizzata dell’ingegneria tradizionale

• Non esistono standards per tutte le fasi della produzione del software

Esempio:costruzione di ponti e sviluppo SW

• I ponti sono normalmente costruiti nei limiti di tempo previsti, secondo ilcosto calcolato e non cadono

• Il software è raramente sviluppato nel tempo previsto e, soprattutto con i costi previsti.

Come mai?

19

Ingegneria tradizionale

• Si parte sempre da – Progetto estremamente dettagliato– Progetti alternativi possono essere

provati attraverso modelli – Il progetto è fissato e il

committente ha scarsa possibilità di cambiare le specifiche

– Si seguono procedure (processi) standard

SE: differenze 1

• Il software è una componente fondamentale di applicazioni e servizi che sono il cuore degli affari

• Specifiche e progetti fissati non vanno d’accordo con i cambiamenti che occorrono continuamente nella pratica degli affari

• Il cambiamento e l’evoluzione sono continui

20

SE: differenze 2

• Il progetto di ponti è vecchio di 3000 anni• C’è una vasta quantità di conoscenze con

sottostanti teorie e metodi– questa è la direzione in cui si sta muovendo anche la produzione del SW

• Le conoscenze acquisite comprendono anche l’analisi dei fallimenti

– quando si produce SW raramente vengono analizzati i fallimenti

Progetto celebre 1

• London ambulance service– Sistema automatizzato per gestire il

servizio ambulanze– Unificazione di 3 servizi, ottimizzazione

dei percorsi– Guida vocale degli autisti

• Risultati– 3 versioni, costo totale: € 11.000.000– L’ultima versione abbandonata dopo soli 3

giorni d’uso• Analisi errata del problema

21

Progetto celebre 2

• Aeroporto di Denver– Sistema automatizzato di smistamento dei

bagagli– 35 Km di rete, 4.000 carrelli, 5.000

telecamere, 56 lettori– $ 193.000.000 di investimento

• Risultati– Inaugurazione dell’aeroporto ritardata di 7

mesi– $ 1.000.000 al giorno di perdita (costi +

mancati guadagni)• Realizzazione difettosa

Altri progetti celebri

• Ariane 5– Fallimento del primo lancio del vettore

commerciale ESA• Patriot

– Una caserma colpita per un difetto nel sistema di guida

• Therac 25– Il software ha provocato la perdita di vite

umane• Mars Climate Orbiter & Mars Polar Lander

– Difetti nel software hanno causato il fallimento delle missioni

22

Caratteristiche del SE

• Una disciplina complessa e multiforme

– Diverse tematiche tecnologiche• La conoscenza del dominio di applicazione gioca un ruolo

fondamentale nello sviluppo del SW– Per sviluppare un sistema di controllo del volo, uno

deve capire come funziona un aereo• Il software sviluppato a partire da assunzioni sbagliate sul

dominio di applicazione puo’ generare disastri

– Connesse a tematiche economiche e manageriali• L’ingegnere del SW lavora in gruppo, interagisce con un

ambiente esterno che definisce i requisiti e progetta componenti che devono interagire con altri definiti da altri

– Evoluzione del SW in risposta a problemi reali– L’abilità nella programmazione non è tutto

Tematiche principali 1

– Progetto e realizzazione di sistemi softwareI problemi principali che affronta l’Ingegneria del

Software in questo ambito sono• La definizione di metodi di analisi e progettazione dei

prodotti sw– Sistemi grandi

» Space shuttle project» 5.6 million code lines, 22k man year, 1200 Million$

– CityBank teller machine» 780000 code lines, 150 man year, 13.2 Million$

– Critical systems» I fallimenti generani rischi o perdite (denaro, vite)

• Lo sviluppo degli strumenti di produzione del sw

23

Realizzazioni di sistemi software

• Strategie di analisi e progettazione– Tecniche per la comprensione e la soluzione di

un problema– Top-down, bottom-up, progettazione modulare,

OO• Linguaggi di specifica e progettazione

– Strumenti formali per la definizione di sistemi software

– Reti di Petri, Z, UML• Ambienti di sviluppo

– Strumenti per analisi, progettazione e realizzazione

– Strumenti tradizionali, CASE

Prodotti SW

• Prodotti generici (OTS: off the shelf)– Sistemi prodotti da qualche produttore di pacchetti software e venduti sul mercato a qualsiasi cliente

• Prodotti commissionati (“customizzati”)– Sistemi commissionati da un cliente specifico e sviluppati apposta da un qualche fornitore

Della spesa della PA italiana per sw nel 2002 il 65% è stato per software commissionato e il 35% per sw su licenza (fonte Min. IT)

24

Attributi dei prodotti software

• Attributi esterni (visibili all’utente)– Costo (e tipo di licenza)– Prestazioni: esempi (vedi dopo ed anche qualità)– Garanzia

• Attributi interni (visibili ai progettisti)– Dimensione (size)– Sforzo di produzione (effort)– Durata della produzione (dall’inizio alla consegna)– Modularità

Prestazioni dei prodotti software

• Mantenibilità– Se i requisiti cambiano, il sw deve poter evolvere

• Affidabilità– Se si “rompe”, il sw non dovrebbe causare danni

• Efficienza– Il sw non dovrebbe sprecare le risorse di sistema

• Usabilità– Il sw dovrebbe avere interfaccia e documentazione appropriate

25

Bilanciamento degli attributi

• L’importanza relativa degli attributi di prodotto dipende dal prodotto e dall’ambiente in cui verrà usato

• A volte certi attributi sono più importanti– Nei sistemi in tempo reale con requisiti

di sicurezza, gli attributi chiave sono l’affidabilità e l’efficienza

• Se un attributo dev’essere particolarmente curato e “spinto”, i costi di sviluppo tenderanno a crescere esponenzialmente

Tematiche principali 2

– Processo software• Lo studio del processo di sviluppo del

sw– Gli aspetti economici dei prodotti e dei processi

26

Il processo SW

• Insieme strutturato di attività necessarie per creare un sistema software

– Specifica– Progetto e sviluppo– Verifica e validazione– Manutenzione

• Le attività differiscono in funzione del SW da produrre e dell’organizzazione che lo sviluppa

• Per poter gestire le attività esse vanno esplicitamente modellate

Attributi di processo 1

• Comprensibilità– Il processo è definito e comprensibile

• Visibilità– Il processo progredisce in modo visibile

• Sostenibilità– Il processo è sostenuto da strumenti adeguati (ad es. CASE)

• Accettabilità– Le persone implicate nel processo manifestano il loro consenso

27

Attributi di processo 2

• Affidabilità– Gli errori di processo vengono scoperti prima che

• diventino errori di prodotto• Robustezza

– Il processo può continuare anche in presenza di errori

• Mantenibilità– Il processo può evolvere per adattarsi ai cambiamenti nell’organizzazione che lo usa

• Rapidità– Il processo influenza la velocità di produzione del prodotto

Cosa serve conoscere per strutturare il Processo SW

• Organizzazione e gestione dei progetti– Metodi di composizione dei gruppi di lavoro– Strumenti di pianificazione, analisi, controllo

• Cicli di vita del software– Definizione e correlazione delle attività– Modelli ideali di processo di sviluppo

• Modelli del processo di sviluppo– Norme per la definizione delle attività– Strumenti per la definizione dei processi

28

Miti e leggende

• Per cominciare a scrivere un programma, basta un’idea generica dei suoi obiettivi - ai dettagli si pensa dopo

– La cattiva definizione della specifica è la maggior causa di fallimenti progettuali

• Se il progetto ritarda, possiamo aggiungere programmatori e rispettare la consegna

– Legge di Brooks: “Aggiungere personale ad un progetto in ritardo lo fa ritardare ancor di più”

Miti e leggende

• Se i requisiti di un progetto cambiano, non è un problema tenerne conto perché il software è flessibile– In realtà da un costo minimo per cambiamenti nella fase di progetto, si passa a costi altissimi per cambiamenti nella fase di implementazione

29

Miti e leggende

• Se il software “funziona”, la manutenzione è minima e si può gestire errore per errore, quando capitano– In realtà da un costo a budget del 10% per la manutenzione si può passare ad un costo reale del 70%

Principi di un buon processo

• Anticipazione del cambiamento• Rigore e Formalità• Separazione dei problemi• Modularità• Astrazione• Generalità• Incrementalità

30

Anticipazione del cambiamento

• Le modifiche al software sono frequenti– Rimuovere errori– Adeguare a requisiti in evoluzione

• Occorre considerare i probabili cambiamenti futuri come parte della progettazione– Isolare i possibili cambiamenti in moduli specifici– Progettare moduli riusabili

• Modifiche al prodotto ed al processo di sviluppo

Rigore e formalizzazione

• Applicazione di metodi e tecniche ben definite

• Assicurano l’affidabilità del prodotto, permettono il controllo dei costi, aumentano la fiducia dell’utente

• I livelli di rigore e formalità saranno diversi per prodotti diversi, per processi diversi, per parti di sistema diverse

31

Separazione dei problemi

• Molte decisioni sono fortemente correlate ed interdipendenti

• Conviene concentrarsi sui diversi aspetti di un problema separatamente: es. Il sistema operativo, i vincoli di ambiente esecutivo, l’interfaccia utente sono aspetti “separabili”

• La separazione si può fondare sul tempo, le qualità, i punti di vista, la dimensione, il livello di dettaglio, ecc.

Modularità

• Suddividere un sistema complesso in sottosistemi più semplici (divide et impera)

• I componenti dovrebbero essere molto coesi e lascamente accoppiati

• Information Hiding

32

Astrazione

• Identificare gli aspetti importanti di un fenomeno, trascurandone i dettagli meno significativi

• La stessa realtà può essere descritta da diverse astrazioni, ciascuna avente scopo diverso

• L’astrazione guida l’intero processo– Un linguaggio di programmazione è un’astrazione del codice macchina– Un ambiente di ingegneria del software include astrazioni per la specifica, il progetto, la codifica

Generalità, Incrementalità

• Generalità– Le soluzioni di problemi generalizzati sono potenzialmente più riusabili– Occorre bilanciare le decisioni che favoriscono una soluzione generalizzate

• Incrementalità– Procedere passo a passo (senza salti)– Applicato alle qualità software o al processo di sviluppo

33

Tematiche principali 3

– La standardizzazione di processi e tecnologie• Qualità del software

– L’approccio ingegneristico dovrebbe migliorare la qualità

Processo e prodotto

• Il nostro scopo è sviluppare prodotti SW

• Il processo è il modo in cui lo facciamo

• Entrambi sono molto importanti• Entrambi hanno qualità

34

Dimensione della qualità

• Processo \ prodotto• Interna \ esterna

• La qualità del processo influenza quella del prodotto

• La qualità interna influenza quella esterna

Qualità del processo

• Definire il processo– Per controllarlo meglio– Per raccontarlo in modo convincente

• Controllare il processo per migliorarlo– Prodotti rispondenti ai requisiti– Minori costi a parità di qualità– Imparare dall’esperienza

35

Come si assicura la qualità del processo SW

• Organizzazione interna• Diffusione interna• Identificazione dei prodotti intermedi e dei punti di verifica

• Replicabilità dei risultati• Garanzia della qualità

Come si assicura la qualità del prodotto SW

• Metodi di verifica e controllo– Metodi di verifica, criteri di progettazione

delle prove– Controllo della qualità e valutazione del

processo di sviluppo• Modelli di qualità

– Definizione di caratteristiche della qualità– Valutazione dei prodotti

• Metriche software– Unità di misura, scale di riferimento, strumenti– Indicatori di qualità

36

Correttezza del SW

• Il SW è corretto se soddisfa le specifiche

• Se le specifiche sono stabilite formalmente, poiché i programmi sono oggetti formali, anche la correttezza può essere definita formalmente:– Può essere provata come un teorema o non

provata per mezzo di controesempi (testing)• Si può tentare di sviluppare SW a priori

corretto– Giusto processo e giusti tool

Limiti della correttezza

• La correttezza è una qualità assoluta (yes/no)– non c’è nessun concetto di “livello di correttezza”– non c’è alcun concetto di gravità della deviazione dalla correttezza

• E se la specifica è sbagliata?(e.g., a causa di requisiti scorretti o mancata conoscenza del dominio di applicazione)

37

Reliability, robustness

• Reliability– informalmente: „un utente può contare sul SW“– matematicamente può essere definita come „la probabilità di assenza di fallimenti per un certo periodo di tempo“– se la specifica del SW è corretta, tutto il SW corretto è reliable, ma non viceversa (in pratica comunque …)

• Robustness– il software si comporta „ragionevolmente“ anche in circostanze impreviste (ad es. fallimenti hardware)

Performance

• Uso efficiente delle risorse– memoria, tempo di calcolo, …

• Può essere verificata• Analisi di complessità• “performance evaluation” (su un modello, per mezzo di

simulazione)• La performance può influenzare la scalabilità

• una soluzione che funziona su una piccola rete locale, può non funzionare su una rete vasta

• La performance può influenzare l’usabilità• La performance può cambiare con la tecnologia

38

Usabilità

• Termini diversi: ergonomicità, user friendly• Gli utenti attesi trovano il sistema facile da

usare – Importante: definire gli utenti attesi – Facilità di installazione è parte

dell’usabilità (utente=installatore)• Piuttosto soggettiva, difficile da valutare • E’ influenzata essenzialmente

dall’interfaccia utente, ad es. visuale invece che testuale

Altre qualità

• Manutenibilità– E’ possibile modificare il SW nel tempo

• Riusabilità– di solito riferito ai componenti di un

sistema• Portabilità

– adattabilita’ ad ambienti d’uso diversiInteroperabilità– il prodotto SW è in grado di coesistere e cooperare con altre applicazioni