Giuseppe Santucci Qualità nella Produzione del Software 01 ...

QPsw Giuseppe Santucci 01Intro.1

Giuseppe Santucci

Qualità nella Produzione del Software

01- Introduzione


Sommario

• Informazioni generali sul corso

• Sw e qualità del software

• Errori e cause di errori

• Fattori qualità

• Sistema assicurazione qualità

• Rassegna degli standard per la qualità


Qualità nella Produzione del Software (a.a. 07-08)

SINR - SELR - SGER - Canale A-Z

Unico codice d'esame - Prenotazioni tramite SINR

• Prof. Giuseppe Santucci• Orario : 21 aprile - 21 giugno

– lunedì aula 9 14.00 - 15.30– giovedì aula 24 12.00 - 13.30 ... 14.00 - 15.30


Testi di riferimento

• Daniel Galin : “Software Quality Assurance”Pearson – Addison Wesley -2004

• Lucidi e/o dispense– www.dis.uniroma1.it\~santucci\didattica.html


Forme di comunicazione

• Ricevimento : mercoledì 14.30-16.30– controllare sempre gli avvisi sul web !

Via Ariosto 25 secondo piano• [email protected]• telefono ?

– Solo durante l’orario di ricevimento


Modalità di esame• Prova scritta

– Esercizi e domande teoriche– Alla fine del corso verrà discusso un'esempio di compito di esame– Esercitazioni scritte IN AULA

• non obbligatorie• (tipicamente) giovedì pomeriggio• considerate in fase di valutazione della prova scritta (+ 3 punti max)

• Appelli:– 2 appelli tra il 23 giugno ed il 18 luglio– Primo appello recupero 8-26 settembre

• N.B. per gli studenti del vecchio ordinamento la prova scritta corrisponde al superamento di 1/2 esame. Il primo 1/2 esame corrisponde al modulo di Ingegneria del SW di cinque crediti erogato nella laurea triennale.


Programma di massima• Concetti preliminari

– Qualità nel software – Fattori di qualità– Assicurazione qualità

• Il sistema assicurazione qualità sw• Standard per la qualità

– ISO 9126– ISO 9001– CMMI - ISO 25000– ...

• Metriche• Teoria della misura


La qualità del sw


Software ?

• Definizioni ISO 12207 ed IEEE:

• Prodotto sw: “insieme di programmi, procedure, e delladocumentazione e dei dati associati”

• Elemento sw: “parte identificabile di un prodotto sw, ad uno stadio intermedio od allo stadio finale di sviluppo”


4 componenti• Codice …• Procedure: tutte le informazioni necessarie alla corretta

esecuzione del codice (sequenza di esecuzione, persone, ecc.)– Precedenze tra attività– Persone coinvolte, ruoli

• Documentazione– Sviluppatori (requisiti, progetto, descrizione codice)– Utenti (manuale utente/help in linea)– Manutentori (documentazione ad alto livello del codice per cercare le

cause di errori / punti per cambiamenti)

• Dati associati (file di configurazione, file dati (DBMS), test report) • La qualità del codice è solo 1 di 4 fattori!


Errors, faults (or defect), and failuresovvero

Errori, difetti e malfunzionamenti

• L’errore è commesso da un essere umano (errore nelcodice, nella documentazione, nei dati, nelle procedure)

• Il difetto è una caratteristica fisica di una porzione dicodice, di una sezione di di documentazione, di una porzione dei dati, nelle procedure da eseguire che puòmanifestarsi a causa di un errore

• Il malfunzionamento è la conseguenza di un difetto chepuò manifestarsi durante l’utilizzo del prodotto software


Errors, faults, and failuresovvero

Errori, difetti e malfunzionamenti

Il che implica che i malfunzionamenti del SW possono non essere notati o apparire dopo anni di funzionamento corretto(caso famoso: problema anno 2000 (1999?))


Cause di errori (1,2)1. Requisiti difettosi

– Errati– Mancanti (requisiti fondamentali)– Incompleti– Inutili

2. Incomprensioni cliente-sviluppatore– Mancata comprensione dei requisiti ufficiali– Mancata comprensione dei cambiamenti ufficiali– Mancata comprensione dei cambiamenti verbali– Mancata comprensione delle risposte del cliente a problemi di

progetto evidenziati dallo sviluppatore– Scarsa attenzione a richieste di cambiamenti del cliente o a

risposte dello stesso


Cause di errori (3,4)3. Deviazioni deliberate dai requisiti

– Riuso effettuato senza una corretta analisi– Omissioni ufficiali (per motivi di tempo o denaro) di alcune

funzionalità– Omissioni non ufficiali di requisiti valutati meno importanti

4. Errori di progetto– Errori algoritmici– Errori di processo (tipicamente sulle sequenze degli

avvenimenti), spesso legati alla differenti culture analista/cliente

– Errori di condizioni al contorno (valori estremi)– Omissione di stati interni (mancanza di un comportamento

definito per certe situazioni)– Mancata definizione del comportamento del sistema a fronte di

operazioni/input errati


Cause di errori (5,6)5. Errori di codifica

– ...

6. Non aderenza agli standard di codifica e documentazione. Non sono veri e propri errori ma inducono un tasso più alto di errori nei seguenti casi:

– Integrazione di moduli standard con moduli non standard – Riuso di codice o sostituzione di personale– Revisioni formali– Test– Manutenzione


Cause di errori (7,8,9)7. Processo di test affrettato (soldi, tempo, pianificazione

errata)– Piano di test incompleto– Mancata o inadeguata notifica di errori scoperti durante il test– Mancata correzione o correzione incompleta di errori

(negligenza o vincoli stringenti)

8. Errori nelle procedure– Nascono nei sistemi software complessi, dove le attività

vengono effettuate per passi successivi

9. Errori di documentazione– Omissioni, descrizione di funzionalità inesistenti, mancato

allineamento con la versione corrente, spiegazioni errate– Errori nei documenti di progetto e documentazione del sw– Errori nella documentazione utente


Errori nel codice• Durante il processo di ispezione viene tipicamente usata una lista di

errori più comuni.• La lista non deve comprendere aspetti dello stile di programmazione

(ad es., “ci sono abbastanza commenti?”).

• Presentiamo una lista (da [Myers 1979]) che propone una classificazione di errori indipendente dal linguaggio di programmazione(alcuni tipi di errori potrebbero non essere significativi in Java, ma esserlo in altri linguaggi, ad es., il C).

• Errori di riferimento ai dati

• Errori di calcolo

• Errori di confronto

• Errori di controllo

• Errori di interfaccia

• Errori di I/O


Errori nel codice (2)Errori di riferimento ai dati:

• Ci si riferisce ad una variabile non inizializzata?

• Nel caso di array o stringhe, ogni indice è compreso nei limiti della dimensione corrispondente?

Ci sono errori di “off by one”? (indici in C...)

• Per i riferimenti attraverso puntatore/riferimento, la corrispondente area di memoria è stata allocata (dangling reference problem)?

• Una variabile (eventualmente riferita tramite puntatore) ha tipo diverso da quello previsto dal programma?

• Esistono variabili con nome simile (pratica pericolosa)?


Errori nel codice (2)Errori di riferimento ai dati:

int i,somma;

for (i=1; i<=100; ++i)

somma = somma+i;

-----------------------------------

int i, v[10];

for (i=1; i<=10; ++i)

v[i] = 0;

-----------------------------------

char *stringa;

scanf("%s", stringa);


Errori nel codice (3)Errori di calcolo:• I calcoli coinvolgono tipi inconsistenti (ad es., stringhe e

interi)?

• Esistono delle inconsistenze nei calcoli misti (ad es., interi ereali)?

• Esistono dei calcoli che coinvolgono tipi compatibili ma di precisione differente?

• In un’assegnazione, il valore sinistro ha rappresentazione meno precisa del valore destro?

• È possibile una condizione di overflow o underflow (ad esempio nei calcoli intermedi, o nelle conversioni)?

• C’è qualche divisione per zero?


Errori nel codice (3)Errori di calcolo:Nel 1996 l' ESA (Agenzia Spaziale Europea) lancia il missile Arianna 5 (10 anni di lavoro, 7 bilioni di

$) con un carico di alcune tonnellate di satelliti. Dopo 39 secondi di volo, a circa 1km di altezza, il sistema di autodistruzione entra in azione e distrugge il missile ed i preziosi satelliti a bordo. Perche?

• Il sistema di assetto inerziale (giroscopi, accelerometri, ecc.) era gestito da un doppio computer (hw ridondante) e, tra le altre cose, monitorava la velocità orizzontale che, una volta acquisita, veniva passata al sitema di guida subendo una conversione da 64 a 16 bit;

• Dopo circa 36 secondi la velocità orizzontale supera il massimo memorizzabile in 16 bit, valore alto, ma ragionevole per un missile così veloce, e nella conversione si verifica un overflow;

• Il controllo passa immediatamente al computer ridondante che interviene istantaneamente e rieffettua i calcoli. Ma il SW è lo stesso (!!!) e si verificalo stesso overflow;

• Il secondo computer restituisce un codice di errore ed effettua uno shutdown (36.7 secondi dopo il lancio)

• Il codice di errore viene interpretato dal sistema di guida come un assetto di voloestremamente bizzarro ed il sistema di guida reagisce immediatamente, imponendo al missile una brusca virata

• A causa dell'accelerazione il motore principale rischia di staccarsi dal missile• Il sistema di autodistruzione interviene prontamente...


Errori nel codice (4)Errori di calcolo (continua):

• Nelle espressioni che contengono vari operatori aritmetici, le assunzioni sull’ordine di valutazione e di precedenza degli operatori sono corrette?

• Il valore di una variabile esce dall’intervallo ragionevole? (ad es., il peso dovrebbe essere positivo, …)

• Ci sono usi sbagliati dell’aritmetica fra interi, in particolare delle divisioni?

• Stiamo prendendo in considerazione adeguatamente la precisione finita dei reali (e degli interi)?


Errori nel codice (4)Errori di calcolo (continua):

-----------------------------------int i,j,k; j=1;k=2;i=(j/k)*2;k=k/i;

-----------------------------------long quota=1000;

.... 10.000 divisioni/moltiplicazioni su quota (simulazione della caduta di un oggetto nell'aria, con attrito, densità dell'aria, velocità, ecc.);

if (quota==0) ....


Errori nel codice (5)Errori di confronto:

• Ci sono confronti fra variabili di diverso tipo?

• Gli operatori di confronto sono usati correttamente?

• Le espressioni booleane sono corrette (uso appropriato di and, or, not)?

• Nelle espressioni che contengono vari operatori booleani, le assunzioni sull’ordine di valutazione e di precedenza degli operatori sono corrette?

• Gli operandi di un’espressione booleana sono booleani?


Errori nel codice (5)Errori di confronto:

-----------------------------------int i,j; j=1;scanf("%d",*i);if (i=j) printf("i e j sono uguali");----------------------------------int voto;scanf("%d",*voto);

/* da tastiera viene inserito 25 */

if (18< voto < 31) printf ("esame superato");else printf ("esame non superato");


Errori nel codice (6)Errori di controllo: (spesso dipendono da errori

nell’algoritmo)• I cicli terminano?

• Le funzioni/procedure terminano?

• È possibile che, a causa delle condizioni di ingresso, un ciclo non venga mai eseguito?

• Le condizioni di uscita dal ciclo sono corrette?

• Ci sono errori di “off by one” (ciclo eseguito una volta in piùo una volta in meno)?

• Esistono delle decisioni non esaustive (ad es., in un’istruzione switch)?


Errori nel codice (6)Errori di controllo:

int i,j;float media=0;i=1;FILE *f;f=fopen("dati.txt",r);while (!feof(f)) {fscanf(f,"%d",*j);media=media+j;++i;}return media/i;


Errori nel codice (7)Errori di interfaccia:

• Il numero e l’ordine dei parametri attuali corrisponde a quello dei parametri formali?

• Le assunzioni sulla conversione di tipo fra parametri attuali e formali sono corrette?

• La modalità di passaggio dei parametri (valore, riferimento) è corretta?

• Un parametro che si pensa essere solo di ingresso viene modificato?

• Le unità di misura dei moduli interagenti sono coerenti (ad es., metri e yard)?


Errori nel codice (8)Errori di I/O:

• La lettura da file avviene rispettando il formato?

• I file vengono aperti con la modalità (lettura/scrittura) giusta?

• Le condizioni di EOF vengono gestite nella maniera giusta?

• Il programma stampa del testo in cui ci sono errori ortografici o sintattici?


Errori nel codice (9)Altri controlli:

• Esistono delle variabili dichiarate ma che non vengono usate, o che vengono usate solamente una volta?

• Ci sono errori di battitura?

• Se il programma è stato compilato con successo, ma il compilatore ha segnalato dei warning, questi sono stati presi adeguatamente in considerazione? !!!!!!!!!!!!!!!!!!!!!!!

• Il programma è sufficientemente robusto? Controlla la validità dell’input?

• Sono presenti tutte le funzionalità previste per il programma?


Qualità del software?

• IEEE:– Il livello con cui un sistema, componente o processo soddisfa

dei requisiti– Il livello con cui un sistema, componente o processo soddisfa

delle esigenze od aspettative di un utente

• PRESSMAN:– Conformità con requisiti funzionali e non funzionali, con espliciti

standard di sviluppo e caratteristiche implicite di un software sviluppato professionalmente


SW quality assurance (SQA):Assicurazione della qualità del sw

• IEEE– un insieme pianificato e strutturato di azioni necessarie a fornire

la confidenza che un prodotto sia conforme ad un insieme direquisiti tecnici

– un insieme di attività pensate per valutare il processo con cui èsviluppato il prodotto software

• Galin– IEEE + conforme a vincoli su:

• manutenzione• tempo• $


Fattori di qualità• Alla base di un qualunque tentativo di produrre sw di

qualità c'è la necessità di avere una ottimadocumentazione dei requisiti (se non è noto cosa occorrefare è difficile farlo bene...)

• In particolare, oltre alla definizione corretta di specifichefunzionali e non, occorre includere tutti gli aspetti di qualitàritenuti essenziali per l'applicazione, quali, ad esempio:

– usabilità– manutenibilità– affidabilità– ...


Fattori di qualità (continua)

• E' nata, quindi, l'esigenza di classificare quali siano gli aspetti diqualità da includere nei requisiti o, più in generale, attribuibiliad un applicativo software (4 componenti)

• La prima, ed estremamente attuale proposta è di McCall (1977) e prevede 11 fattori di qualità. Ulteriori estensioni hannoaumentato e ridenominato i fattori da considerare (lo standard 9126 del 2001 prevede 21 sottocaratteristiche)

• La proposta di McCall divide i fattori di qualità in 3 gruppi– Fattori relativi al funzionamento (Product operation factors)– Fattori relativi alle attività di revisione (Product revision factors)– Fattori relativi alle attività di transizione (Product transition factors)


FUNZIONAMENTOProduct operation factors (5 fattori)

• Correttezza (Correctness)• Affidabilità (Reliability)• Efficienza (Efficiency)• Integrità (Integrity)• Usabilità (Usability)


Correttezza• Tipicamente i requisiti di correttezza sono associati agli

output di un sistema e possono essere classificati secondovarie dimensioni (esemplificate tramite l'esempio di un allarme antincendio):

– scopo dell'output: segnalare sul monitor la presenza di unatemperatura > 70 gradi

– accuratezza: la temperatura mostrata sul monitor deve differire al massimo di 0.5 gradi da quella reale

– completezza : sul monitor deve essere mostrata la temperatura, l'ora, ed il sensore interessato

– vincoli temporali: il ritardo massimo ammissibile è di 5 secondi– standard: la temperatura va mostrata in gradi Celsius

• La correttezza è (potenzialmente) formalizzabile– predicati di ingresso e di uscita– non tutto può essere codificato in tal modo


Affidabilità• Affidabilità è un concetto intuitivo e soggettivo• definizione 9126: capacità di mantenere le prestazioni

stabilite nelle condizioni e nei tempi fissati (il software reagisce bene a variazioni esterne)

• i requisiti di affidabilità possono essere indicati usandovalori limite probabilistici:

– probabilità di perdere i dati <10-9

– sistema attivo il >99% del tempo operativo– errore nel riconoscimento di un evento <10-7

– ...


Efficienza• Tempo di esecuzione / uso di memoria

– Teoria della complessità• limiti asintotici• caso medio• caso peggiore

– Software monitors– Simulazioni (e.g., teoria delle reti di code)

• I requisiti di efficienza sono tipicamente indicati tramitevalori limite sui tempi di risposta e sulla occupazione dellerisorse

– tempo di attesa al bancomat < 10 secondi– memoria centrale richiesta < 128 MB– ...


Integrità (o sicurezza)• La presenza di opportune politiche di sicurezza, tese a proteggere i

dati e l'accesso al sistema da parte di persone/sw non autorizzati• Le specifiche di sicurezza tipicamente prevedono:

- politiche di identificazione ed accesso al sistema- differenti livelli di privilegi- crittografia- ...

• I requisiti di sicurezza possono fare riferimento a– politica di gestione delle password– tecniche di identificazione (e.g., passwd+IP)– tecniche di crittografia– lunghezza della chiave utilizzata (arma da guerra, secondo il DOD! )– probabilità di accesso indesiderato– probabilità/tempo di accesso ai dati


Usabilità• Enfasi sull’utente• Psicologia cognitiva• Fattori fisici/ergonomici• Mentalità dell’utente• Interfacce grafiche/visuali• Le specifiche relative alla usabilità possono fare

riferimento a:– utilizzo di opportune metodologie di progetto– presenza di test di usabilità– rispetto di opportuni standard– semplice rispetto di alcune elementari regole (spesso ignorate)– ...


REVISIONEProduct revision factors (3 fattori)

• Manutenibilità (Maintainability)• Flessibilità (Flexibility)• Provabilità (Testability)


Manutenibilità• Facilità nell’effettuare modifiche correttive, ovvero effettuare

manutenzione:– correttiva (20%): risoluzione di errori– preventiva (10%): rendere piu' semplice la individuazione di errori

tramite miglioramenti del codice (ristrutturazione, pulizia, ecc.)

• è legata alla struttura del programma ed alla suadocumentazione

• Le specifiche relative a questo fattore qualità possono fare riferimento a:

– standard di codifica e documentazione– struttura modulare del programma– indici di complessità– ...

• Non è tra le priorità dell'utente finale.


Flessibilità• Si concentra sulla manutenzione orientata ai cambiamenti:

– adattativa (20%): cambiamenti/aggiunte di specifiche– perfettiva (50%)

• migliorativa: req. non funzionali (spazio, tempo)• evolutiva: req. funzionali secondari

• Ovvero, la facilità con cui è possibile modificare il codiceper adattarlo a nuove richieste

• Oltre alle richieste analoghe a quelle per la manutenibilitàle specifiche possono prevedere la possibilità diconfigurare il software tramite meccanismi utilizzabili dauna utenza non professionale (file di configurazione, opzioni, ecc.)


Provabilità• Denota la facilità con cui è possibile testare il software• Le specifiche relative a questo fattore qualità possono fare riferimento a:

– presenza di file di log– memorizzazione esplicita di risultati intermedi– controlli automatici sulla corretta installazione e funzionamento del

sistema– ...

• Non è tra le priorità dell'utente finale.


Altri fattori qualità/metriche per la revisione

• Lo vedremo in altre lezioni ma sicuramente ha sensomisurare alcuni comportamenti statistici:

– tempo medio per effettuare una modifica (giorni uomo)– tempo medio per risolvere un errore– ….


TRANSIZIONEProduct transition factors (3 fattori)

• Portabilità (Portability)• Riusabilità (Reusability)• Interoperabilità (Interoperability)


Portabilità• Facilità con cui il software può essere trasferito da un

ambiente operativo ad un altro (il software segue l’evoluzione tecnologica e/o la eterogeneità delle piattaforme)

• Le specifiche relative a questo fattore qualità possono fare riferimento a:

– linguaggi di programmazione precisi (e.g., Java)– elenco dei s.o. su cui il sw deve funzionare– strategie di accesso alle risorse della macchina– ...


Riusabilità• Facilità nel poter riutilizzare il codice sviluppato in altri contesti• E' legata alla struttura del programma ed alla sua documentazione

– Libreria di componenti riutilizzabili– Progetto di sw più generale possibile– Documentazione !!!– Tecniche OO

• Implica una maggiore affidabilità !!• Le specifiche relative a questo fattore qualità possono fare riferimento a:

– standard di codifica e documentazione– struttura modulare del programma– evidenziazione di attività di validità generale (controllo di un assegno, login,

ecc.)• fa parte della struttura del PROCESSO produttivo

• Non è tra le priorità dell'utente finale.• La tendenza attuale è quella di standardizzare il modo in cui il sw può

essere riusabile (Java beans, progettazione a componenti, ecc.)


Interoperabilità• Indica la facilità di interazione con altri moduli al fine di svolgere

un compito più complesso (tramite interfacce e protocollipredefiniti)

• e.g., unix– ridirezione dell’input/output – interfaccia : > , <, |– protocollo : ASCII

• favorisce la riusabilità• Le specifiche relative a questo fattore qualità possono fare

riferimento a:– interfacce e protocolli standard per lo scambio di dati (middleware)– funzionalità di import/export tra vari formati– ...


I fattori di qualità secondo McCall (1977)• Funzionamento (5)

– Correttezza (Correctness)– Affidabilità (Reliability)– Efficienza (Efficiency)– Integrità (Integrity)– Usabilità (Usability)

• Revisione (3)– Manutenibilità (Maintainability)– Flessibilità (Flexibility)– Provabilità (Testability)

• Transizione (3)– Portabilità (Portability)– Riusabilità (Reusability)– Interoperabilità (Interoperability)


Fattori di qualità ?• Ai fattori di qualità ideati da McCall si sono aggiunte varie altre

proposte• La sostanza rimane quasi immutata• Principali modifiche:

– metodo di classificazione (e.g., interni/esterni/in uso)– concetto di misura !– maggiore enfasi sull'utente finale

• Nel corso ignoreremo le varie alternative e ci concentreremosulla proposta più recente ISO/IEC 9126 (2001)


external and internal quality

functionality reliability

maturityfault tolerancerecoverability

usability

understandabilitylearnabilityoperability

attractiveness

efficiency

time behaviourresource utilisation

maintainability

analysabilitychangeability

stabilitytestability

portability

adaptabilityinstallabilityco-existencereplaceability

suitabilityaccuracy

interoperabilitysecurity

functionality compliance

reliability compliance

usability compliance

efficiency compliance

maintainability compliance

portability compliance

Caratteristiche (fattori) di qualità secondo lo standard 9126


quality inuse

effectiveness productivity safety satisfaction

Caratteristiche (fattori) di qualità secondo lo standard 9126


E allora?

• Come garantire la presenza dei vari fattori qualità nel processo diproduzione del SW:

Sistema Assicurazione Qualità del Software(Software Quality Assurance System)


Una parentesi economica• Quanto costa la qualità?• Due costi:

– per fare bene le cose– per rimettere a posto le cose sbagliate


Il costo della qualità (ISO)I costi della qualità nel processo produttivo sono i costi che si sostengono per adeguare la qualità del prodotto alla qualità richiesta.

Costo della conformità (COC) (per soddisfare tutte le esigenze espresse edimplicite)

costi di prevenzione: oneri sostenuti per prevenire gli insuccessicosti di accertamento: oneri per controlli e collaudi

Costo della non conformità (CNC) (per insuccessi interni ed esterni)costi per insuccessi interni: oneri connessi ad un prodotto che non soddisfa i

requisiti di qualità prima ancora della sua consegnacosti per insuccessi esterni : oneri connessi ad un prodotto che non soddisfa i

requisiti di qualità dopo la sua consegna (costi di manutenzione e riparazione, costi di garanzia e resi, costi per il richiamo dei prodotti, costi per la responsabilità da prodotto,...)


CNCCOCCNC+COC

Punto di costo minimo

Basso impegno in attività di prevenzione e verifica Alto

cost

o

Costo dellaconformità

Costo dellanon conformità

Il costo della qualità


Standardizzazione• Diversi enti di standardizzazione (e.g., ISO) hanno cercato

di integrare vari approcci alla definizione della qualità, partendo dalla consapevolezza che la qualità è un attributoche varia in funzione del:

– percettore– del contesto di percezione– dello scopo e del costo del prodotto

• ISO/IEC 9126 (Prodotti informatici)• ISO 9000 - ISO 12207 - CMM (SEI) (Processi)


ISO E ALTRE ORGANIZZAZIONIISO E ALTRE ORGANIZZAZIONI

Settori Settorevari elettrotecnico

A livello internazionale ISO IEC

A livello europeo CEN CENELEC

A livello nazionale UNI CEI


SIGLE

lSO International Organization for StandardizationIEC International Electrotechnical CommissionCEN Comitato Europeo di Normazione (sigla sui documenti EN)CENELEC Comitato Europeo di Normazione Elettrotecnica (sigla sui documenti EN HD)UNI Ente Nazionale Italiano di UnificazioneCEI Comitato Elettrotecnico Italiano

Tra gli organismi ISO a livello nazionale non europeo:

ANSI American National Standard Institute, per gli Stati Uniti; JISC Japan Industrial Standards Committee, per il Giappone;SA Standards Australia, per l'Australia; SCC Standard Council of Canada, per il Canada.

I 18 organismi "National Standard Bodies" del CEN rappresentano tutti i paesi europei, con l'aggiunta di7 affiliati di cui 5 paesi limitrofi, più Cipro e Turchia (tra questi rientra l’UNINFO - Ente di normazioneFederato all'UNI per le Tecniche Informatiche e le loro applicazioni - per l'ltalia).


Standard

CMM (SEI 87)

ISO/IEC 12207 (91)

PROCESSO PRODOTTO

ISO/IEC 9126 (91)

ISO/IEC 9126 (2001)

IS0 14598

ISO 8402 (94)ISO 9001 - UNI-EN 29001 (88)

revisionata nel 94revisionata nel 2000: Vision 2000

CMMI (2002) - ISO 25000

Giuseppe Santucci Qualità nella Produzione del Software 01 ...

Documents

Transcript of Giuseppe Santucci Qualità nella Produzione del Software 01 ...