Quality gate
• Nei punti chiave del processo di sviluppo del software,
viene integrato un insieme di quality gate per monitorare
la qualità del prodotto intermedio prima che quest’ultimo
possa passare al prossimo passo di sviluppo
• Sono revisioni formali che hanno l’obiettivo di fornire un
mezzo per valutare il processo usato per sviluppare il
software, la conformità del prodotto software alle
esigenze del cliente e alle caratteristiche tecniche attese
Quality gate
• Sono eventi programmati regolarmente e
condotti seguendo una procedura
standard
• Va/non va:
– La revisione non viene tenuta se non si
verificano certi eventi
– Il processo di sviluppo software riprende solo
dopo che tutto il lavoro passato in revisione è
stato completato e approvato dai revisori
Processo per la garanzia della qualità software 1
Il processo SQA comincia facendo una revisione in profondità sul processo di
sviluppo del software
CHECKLIST
1.
La portata del software è definita in maniera chiara?
2.
La terminologia è ben definita?
3.
Le risorse sono ragionevoli? Sono disponibili?
4.
L’analisi dei rischi è stata fatta? E il piano contenimento e/o prevenzione?
5.
I compiti sono stati definiti, programmati e allocati?
6.
Le stime di costo e programmazione sono ragionevoli (si correlano con i
dati storici)?
7.
E’ stato applicato uno standard nella stesura della documentazione?
8.
Come sarà controllato il piano del progetto?
9.
E’ necessario un ambiente per lo sviluppo del software?
10. Come è stata condotta la revisione?
Checklist per i requisiti software
1.
2.
3.
4.
5.
6.
7.
Tutte le funzioni sono state definite, descritte, vincolate in maniera
non ambigua?
Per ogni requisito funzionale è stato introdotto anche un requisito
di performance, e il requisito funzionale è testabile?
Gli input e gli output sono stati tutti definiti in termini di range,
protocolli,.. in modo che il designer del software possa essere
soddisfatto?
E’ stato fatto un piano di test e di integrazione? I criteri di
accettazione dei test sono stati già negoziati con il cliente?
Lo studio di fattibilità è completo?
L’analisi dei rischi è stata iniziata/completata?
Sono stati applicati degli standard alla documentazione?
Checklist per la specifica architetturale
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Ci sono ancora dei requisiti aperti? Se sì, si progetta di chiuderli?
Il partizionamento è completo e documentato?
Tutte le interfacce hardware e software interne ed esterne sono state
definite adeguatamente in termini di protocolli, range ecc..?
Il modello dei dati è stato completamente e accuratamente definito?
I requisiti software di basso livello sono tracciati nei requisiti software di
alto livello in maniera completa ed accurata?
Possono essere soddisfatti i requisiti non funzionali?
Il partizionamento soddisfa i criteri di modularità?
Sono state definite le interfacce fra i moduli?
Il design della struttura dati è consistente con i requisiti dei dati?
Manutenibilità e flessibilità sono attributi di qualità considerati nel design?
Quali attributi di qualità sono applicati?
Gli standard di documentazione sono stati raggiunti?
Sono stati applicati degli standard nella pseudocodifica? Se sì, come sono
stati applicati?
Checklist per la specifica di dettaglio
1.
2.
3.
4.
5.
6.
7.
8.
Sono stati tenuti in considerazione tutti i requisiti?
La specifica dettagliata è consistente con la
precedente?
Lo pseudocodice o i diagrammi sono stati
correttamente trasformati in codice? Hanno soddisfatto
gli standard richiesti?
Sono stati soddisfatti gli standard per la
documentazione?
I commenti soddisfano degli standard?
I tipi di dati e la dichiarazione dei dati è corretta?
I dati sono corretti?
Sono stati tenuti in conto gli attributi di qualità?
Checklist del testing
1. I criteri di accettazione dei test sono stati definiti, negoziati ed accettati? Le
revisioni sono state fatte come richiesto?
2. I piani di test sono stati preparati e revisionati?
3. L’attività di testing è stata presa in considerazione in altre fasi di sviluppo?
4. Gli ambienti di test (strumenti e risorse) sono definiti in maniera adeguata e
disponibili quando necessario?
5. La tracciabilità fra requisiti e test di conferma è stata completata e corretta?
6. Le funzioni principali sono confermate presto nella fase di testing?
7. Sono stati definiti degli standard per condurre i test? I tester sono stati
sottoposti a training?
8. Sono stati definiti test limite e test di stress?
9. Il testing è fatto in maniera completa?
10. La gestione degli errori e delle eccezioni è stata testata?
Checklist per la valutazione della
revisione
1.
2.
3.
4.
5.
6.
7.
8.
9.
Il materiale è completo?
Il materiale è stato distribuito in tempo?
Gli standard applicabili sono disponibili?
I partecipanti erano preparati a contribuire?
La valutazione è iniziata in tempo?
La revisione è stata condotta attraverso protocolli
standard?
E’ stato identificato un certo numero di difetti?
Sono stati riportati gli attributi di qualità?
Si e’ cominciato a tracciare i difetti?
Misura del processo
• L’efficacia di un processo di sviluppo software si misura
indirettamente
– A partire dalle informazioni derivate dal processo si ricava una
famiglia di metriche
– Tali informazioni comprendono
•
•
•
•
•
•
•
La misura degli errori scoperti prima della distribuzione del software
I difetti comunicati dagli utenti finali
I prodotti distribuiti (produttività)
Il lavoro speso
Il tempo impiegato
Il grado di conformità alle scadenze prefissate
…
CMM
Il Capability Maturity Model (CMM) è il più famoso ed utilizzato modello di
valutazione e miglioramento - Software Engineering Istitute (SEI) Pittsburg – USA.
Un processo è caratterizzato da 3 attributi fondamentali:
capability: è l’insieme dei risultati che un processo consente di conseguire;
esprime le potenzialità del processo e permette di effettuare stime attendibili sulla
possibilità di raggiungere i risultati di un progetto, sia per il committente che per il
produttore;
performance: è una misura dei risultati effettivi ottenuti nell’applicazione del
processo;
una valutazione a consuntivo dei risultati che sono stati raggiunti;
maturity: è una misura dell’efficacia del processo e della estensione e
precisione con cui le fasi e le attività dello stesso sono esplicitamente definite,
gestite, misurate e controllate;
è una valutazione del livello di padronanza e controllo del processo da parte
dell’organizzazione, ivi inclusa la capacità dell’organizzazione di migliorarlo,
ottimizzarlo,… o comunque modificarlo in risposta a necessità che si presentano.
CMMI
CMM
CMMI
CMMI
CMMI
CMMI
CMMI
CMMI
Level
Focus
Process Areas
5 Optimizing
Continuous
process
improvement
Organizational Innovation and Deployment
Causal Analysis and Resolution
4 Quantitatively
Managed
Quantitative
management
Organizational Process Performance
Quantitative Project Management
3 Defined
Process
standardization
(SS)
(IPPD)
(IPPD)
2 Managed
1 Performed
Basic
project
management
Requirements Development
Technical Solution
Product Integration
Verification
Validation
Organizational Process Focus
Organizational Process Definition
Organizational Training
Integrated Project Management
Integrated Supplier Management
Risk Management
Decision Analysis and Resolution
Organizational Environment for Integration
Integrated Teaming
Requirements Management
Project Planning
Project Monitoring and Control
Supplier Agreement Management
Measurement and Analysis
Process and Product Quality Assurance
Configuration Management
CMMI
CMMI
CMMI
CMMI
CMMI
CMMI