lo standard internazionale per il ciclo di vita del software

ISO/IEC
12207
Lo standard
internazionale
per
il ciclo di vita
del software
Per quale motivo è nato?
 Il software con il passare del tempo è
diventato parte integrante della vita di
tutti i giorni per milioni di persone.
SW
Procedure, metodi
strumenti, ambienti
per lo sviluppo SW
?
? ?
management e
ingegnerizzazione
Per quale motivo è nato?
C’era la necessità di
“parlare la stessa lingua”
per creare e gestire software
Procedure, metodi
strumenti, ambienti
per lo sviluppo SW
migrazione
Modello
comune
Quando è nato?
 Nel 1989, un comitato tecnico (JTC1)
costituito due anni prima dall’ISO e
dall’IEC, comincia lo sviluppo di uno
standard per il ciclo di vita di un software
 1 Agosto 1995: viene pubblicato lo standard
internazionale ISO/IEC 12207.
 Al progetto hanno partecipato 17 nazioni
(anche l’Italia)
ISO/IEC 12207
 Lo standard copre il ciclo di vita di un
software, dal momento della concretizzazione
delle idee fino al suo ritiro dal mercato.
 L’architettura del software viene costituita
tramite una serie di processi e di relazioni
tra essi.
 La derivazione di un processo da un altro è
basata su due principi fondamentali:
 Modularità
 Responsabilità
Modularità
accoppiamento
coesione
 Ogni processo è un modulo a se stante ed è
dedicato ad una singola funzione.
Responsabilità
 Ogni processo viene eseguito sotto la
supervisione di un gruppo di lavoro.
 Ogni gruppo di lavoro ha determinate
responsabilità.
 Un gruppo di lavoro può supervisionare più
di un processo, ma difficilmente avviene il
viceversa.
(più gruppi di lavoro supervisionano lo
stesso processo)
I processi
 I processi nel ciclo di vita del software
sono raggruppati in tre classi principali:
 Processi primari
 Processi di supporto
 Processi organizzativi
 Oltre alle tre classi di processi
fondamentali, esiste anche un processo
“speciale”, detto processo di tailoring
Suddivisione dei processi
 Ogni processo è suddiviso in diverse
attività, ed ogni attività a sua volta in
vari compiti secondo uno schema gerarchico
Processo
Attività 1
Compito 1
…
Attività 2
Compito n
…
Compito 1
Attività n
…
Compito n
Processi primari (5)
 5 processi base sviluppati dalle parti
principali coinvolte nel ciclo di vita del
software, ovvero:





l’acquirente
il fornitore
lo sviluppatore
l’utente
il manutentore
 Provvedono a gestire le funzioni principali
durante il ciclo di vita.
Processi primari (5)
 Acquisizione (5.1)
 5 attività, suddivise in 23 compiti
 Fornitura (5.2)
 7 attività, suddivise in 24 compiti
 Sviluppo (5.3)
 13 attività, suddivise in 55 compiti
 Esercizio (5.4)
 4 attività, suddivise in 9 compiti
 Manutenzione (5.5)
 6 attività, suddivise in 24 compiti
Acquisizione (5.1)
 Contiene le attività e i compiti
dell’acquirente.
 Il processo comincia con la definizione
della necessità di acquistare un sistema, un
prodotto o un servizio software.
 Il processo continua con la preparazione di
una richiesta di preventivo, la selezione di
un fornitore, il management del processo di
acquisizione e termina con l’accettazione
del sistema proposto.
Acquisizione (5.1)





Definizione delle necessità
Richiesta di un preventivo
Preparazione e aggiornamento del contratto
Monitoraggio delle attività del fornitore
Accettazione del prodotto
Fornitura (5.2)
 Contiene le attività e i compiti del
fornitore del prodotto software.
 Il processo inizia con la contrattazione con
l’acquirente per il prodotto o servizio SW
 Il processo continua con la determinazione
delle procedure e delle risorse necessarie
per gestire il progetto.
 Il processo termina con la consegna del
sistema (prodotto o servizio) all’acquirente
Fornitura (5.2)







Inizializzazione
Preparazione di un preventivo
Contratto
Planning
Esecuzione e controllo
Revisione e valutazione
Consegna e completamento
Le prime due attività sono svolte prima
dell'accordo mentre le ultime 5 dopo l'accordo.
Sviluppo (5.3)
 Contiene le attività e i compiti dello
sviluppatore del software
 Il termine sviluppo è riferito sia allo
sviluppo di nuovo software sia a modifiche
di software già esistente.
 Il processo di sviluppo può essere inteso
come:
 sviluppo di un prototipo del sistema
 studio dei requisiti e design di un prodotto
 effettiva produzione di un prodotto
Sviluppo (5.3)









implementazione del processo
analisi dei requisiti del sistema e del sw
design dell’architettura del sistema e sw
design dettagliato del software
codifica e testing del software
integrazione del sistema e del software
test di qualità del sistema e del software
installazione del software
supporto all’accettazione del software
Esercizio (5.4)
 Contiene le attività e i compiti di chi
utilizza il software: l’utente finale.
 Consiste nella conduzione delle operazioni
richieste e operate dagli utenti del
software e nella gestione delle stesse.
 Comprende anche un’iniziale fase di collaudo
per verificare l'uso del prodotto software
operante nell'ambiente per il quale è stato
richiesto.
Esercizio (5.4)




Implementazione del processo
Testing operazionali
Operazioni sul sistema
Supporto all’utente
Manutenzione (5.5)
 Contiene le attività e i compiti del
manutentore del sistema.
 Il processo viene pianificato in modo che la
conduzione delle attività, di gestione delle
modifiche e di analisi del tipo di
manutenzione (adattativa, correttiva o di
emergenza) sia il più possibile semplice e a
costi minimi.
Manutenzione (5.5)
 Lo scopo è quello di modificare il software
già esistente mantenendone l’integrità.
 Per apportare effettivamente le modifiche
al software, viene invocato il processo di
sviluppo (5.3).
 Il processo termina con il ritiro del
sistema.
Manutenzione (5.5)






implementazione del processo
analisi del problema e delle modifiche
implementazione delle modifiche
revisione/accettazione della manutenzione
migrazione
ritiro del software
Processi di supporto (6)
 I Processi di Supporto e di Controllo
supportano gli altri processi del ciclo di
vita del software e contribuiscono al
successo e alla qualità di un progetto
software.
 Un processo di supporto può essere richiesto
da uno dei cinque processi primari o da un
altro processo di supporto.
Processi di supporto (6)
 Documentazione (6.1)
 4 attività, suddivise in 7 compiti
 Gestione della configurazione (6.2)
 6 attività, suddivise in 6 compiti
 Assicurazione di qualità (6.3)
 4 attività, suddivise in 16 compiti
 Verifica (6.4)
 2 attività, suddivise in 13 compiti
Processi di supporto (6)
 Validazione (6.5)
 2 attività, suddivise in 10 compiti
 Revisione congiunta (joint review) (6.6)
 3 attività, suddivise in 8 compiti
 Revisione (audit) (6.7)
 2 attività, suddivise in 8 compiti
 Risoluzione del problema (6.8)
 2 attività, suddivise in 2 compiti
Documentazione (6.1)
 Si occupa della registrazione di tutto ciò
che è stato prodotto nel ciclo di vita del
software: dalle informazioni ai requisiti
del sistema, dagli input agli output del
prodotto.
 I documenti relativi a questo processo
presentano tutte le attività relative alla
pianificazione, alla progettazione, allo
sviluppo, alla manutenzione e alla gestione
totale del processo produttivo.
Documentazione (6.1)




implementazione del processo
progetto e sviluppo della documentazione
produzione della documentazione
manutenzione della documentazione
Gestione della
configurazione (6.2)
 Prevede attività e compiti relativi
all'applicazione di procedure tecniche ed
amministrative per assicurare la
completezza, la consistenza e la correttezza
degli elementi software.
 In questo processo bisognerà identificare,
registrare, analizzare e verificare i
possibili cambiamenti dell'elemento software
specificando approvazioni e rifiuti
(controllo della configurazione).
Gestione della
configurazione (6.2)
 Questo processo fornisce un meccanismo per
identificare, controllare e tracciare le
versioni di ogni elemento del software.
 In molti casi le versioni del software
precedentemente prodotto e ancora in uso
devono subire manutenzione e devono essere
anche controllate in maniera accurata.
Gestione della
configurazione (6.2)






implementazione del processo
identificazione della configurazione
controllo della configurazione
documentazione della configurazione
valutazione della configurazione
gestione delle versioni e dei rilasci
Assicurazione di qualità
(6.3)
 Ha lo scopo di prevenire il presentarsi dei
problemi, di individuarli quando si
presentano, di identificarne le cause e di
trovarvi rimedio.
 L'assicurazione della qualità comprende
tutte le attività del management, il quale
determina le politiche per la qualità, gli
obiettivi e le responsabilità, e le
implementa attraverso la pianificazione, il
controllo e il miglioramento della qualità.
Assicurazione di qualità
(6.3)
 L'assicurazione di qualità riguarda sia il
prodotto sia il processo:
 Il prodotto deve essere conforme ai requisiti ed
aderire ai vari piani di progetto e sviluppo al
fine di poter possedere gli specificati attributi
di qualità.
 Il processo, oltre ad essere conforme a quanto
specificato ed aderire alla pianificazione, deve
rispettare gli standard utilizzati per la sua
implementazione.
 Per maggiori informazioni vedi ISO 9001
Assicurazione di qualità
(6.3)




implementazione del processo
assicurazione qualità del prodotto
assicurazione qualità del processo
assicurazione del sistema qualità
Verifica (6.4)
 E’ costituito da attività e compiti atti a
determinare se i requisiti del prodotto,
sistema o servizio software sono completi e
corretti e se essi sono soddisfatti.
 Tale processo deve essere integrato nei
processi primari di sviluppo, fornitura e
manutenzione.
 Consiste nella verifica di processi,
requisiti, design, codifica, integrazione e
documentazione.
Verifica (6.4)
 implementazione del processo
 verifica
Validazione (6.5)
 Serve a determinare se il prodotto finale
offerto soddisfa l'utilizzo per cui è stato
creato.
 La validazione non è un processo da eseguire
al termine della produzione, ma esso può
essere completato nelle prime fasi dello
sviluppo.
 Questo processo solitamente viene invocato
al momento dell’attività di supporto
all’accettazione del software (5.3.13).
Validazione (6.5)
 implementazione del processo
 validazione
Revisione congiunta
(joint review) (6.6)
 In questo processo si procede alla
pianificazione delle revisioni congiunte tra
acquirente e fornitore che avverranno sulla
base di un calendario di incontri fissato
all'inizio del progetto.
 In una joint review, il fornitore presenta
all’acquirente il progresso nelle operazioni
e tutta la documentazione finora prodotta,
per la valutazione e l’approvazione.
Revisione congiunta
(joint review) (6.6)
 implementazione del processo
 revisione della gestione del progetto
 revisione tecnica del progetto
Revisione (audit) (6.7)
 Processo relativo alla determinazione della
verifica della conformità ai requisiti, ai
piani ed ai contratti stabiliti.
 Il processo di revisione dovrà essere
condotto da personale che non ha nessuna
responsabilità diretta sullo sviluppo dei
prodotti, dei servizi o dei sistemi che si
revisionano.
 Le attività della revisione dovranno essere
condotte rispettando i piani e il contratto.
Revisione (audit) (6.7)
 implementazione del processo
 revisione (audit)
Risoluzione del problema
(6.8)
 Scopo di questo processo è fornire
tempestivamente le risorse per assicurare la
risoluzione dei problemi appena essi sono
rilevati.
 Quando si verifica o si rileva un problema
durante le fasi di sviluppo, di
manutenzione, o di altri processi è
necessario documentarlo dettagliatamente,
accertarne l'effettiva esistenza, per poi
risolverlo (anche in diversi modi).
Risoluzione del problema
(6.8)
 Prima però di risolverlo sarà opportuno
valutarne la priorità e l’importanza
rispetto agli altri utilizzando un parametro
di riferimento.
 Questo processo non entra in gioco solamente
quando si evidenzia un problema durante il
ciclo di vita, ma anche quando il processo
non è più conforme ai requisiti richiesti.
Risoluzione del problema
(6.8)
 implementazione del processo
 risoluzione del problema
Processi organizzativi (7)
 I processi organizzativi sono impiegati in
un’organizzazione per stabilire e
implementare una struttura a supporto e per
il continuo miglioramento di:
 processi del ciclo di vita
 struttura organizzativa
 personale
 Supportano qualsiasi altro processo del
ciclo di vita del software.
Processi organizzativi (7)
 Gestione del progetto (7.1)
 5 attività, suddivise in 12 compiti
 Gestione dell’infrastruttura (7.2)
 3 attività, suddivise in 5 compiti
 Miglioramento (7.3)
 3 attività, suddivise in 6 compiti
 Addestramento (7.4)
 3 attività, suddivise in 4 compiti
Gestione del progetto
(7.1)
 Il processo contiene tutte le generiche
attività e compiti, che possono essere
impiegate all'interno del processo di
produzione per gestire i rispettivi
“processi”.
 Il management è responsabile per la gestione
del prodotto, del progetto e dei compiti
applicabili nei processi primari o di
supporto.
Gestione del progetto
(7.1)





Iniziazione e definizione dello scopo
Pianificazione
Esecuzione e controllo
Revisione e valutazione
Chiusura del progetto
Gestione
dell’infrastruttura (7.2)
 Processo che assicura il corretto
svolgimento di tutte le attività di
produzione.
 Serve a stabilire e mantenere
l’infrastruttura sottostante al ciclo di
vita del software.
 L’infrastruttura può includere hardware,
software, strumenti, tecniche, ulteriori
standard e le conoscenze di base per lo
sviluppo, l’esercizio e la manutenzione.
Gestione
dell’infrastruttura (7.2)
 implementazione del processo
 costituzione dell'infrastruttura
 manutenzione dell'infrastruttura
Miglioramento (7.3)
 Definisce le attività necessarie a
migliorare il ciclo di vita di un software.
 Sono di fondamentale importanza esperienze
passate, poiché aiutano l’approccio al
problema.
 Futuri progetti potranno trarre beneficio
dalle operazioni di miglioramento
effettuate.
Miglioramento (7.3)
 Costituzione del processo
 Controllo e valutazione del processo
 Miglioramento del processo
Lo standard su questo punto è molto vago,
consiglia solamente di produrre documentazione
e di rivedere progetti passati per accorgersi
degli errori già commessi.
Addestramento (7.4)
 Tale processo è inerente alla formazione e
addestramento del personale.
 I processi primari dipendono dalle
conoscenze e dalle capacità del personale
sia dell'azienda fornitrice sia di quella
acquirente.
 Il personale deve essere addestrato e
formato costantemente.
Addestramento (7.4)
 implementazione del processo
 sviluppo del materiale di formazione
 formazione
Tailoring:
il processo speciale
 I processi, le attività ed i compiti dello
standard sono stati progettati in modo da
poter essere adattati (tailored) a
specifiche esigenze (ambienti, progetti,
domini applicativi, etc..).
 Il processo di tailoring descrive cosa fare
per “adattare” gli altri processi software.
Tailoring:
il processo speciale
 Il tailoring consiste nella cancellazione di
processi, attività e compiti non applicabili
al caso specifico e nell'aggiunta di
processi, attività o compiti non presenti
nello standard e necessari per il caso
specifico.
 L’aggiunta di processi, attività e compiti
deve essere adeguatamente documentata nel
contratto.
Tailoring:
il processo speciale
 identificazione dell'ambiente di sviluppo
 coinvolgimento delle parti
 individuazione dei processi, delle attività
e dei compiti necessari
 documentazione della decisione di eliminare
o aggiungere processi, attività o compiti
Interazioni tra processi
 Nel prossimo lucido vedremo come i vari
processi del ciclo di vita di un software
(primari, di supporto e organizzativi)
interagiscono tra loro.
Organizzazione
PROGETTO
INFRASTRUTTURA
DOCUMENTAZIONE
MIGLIORAMENTO
gestisce
feedback
Progetto
U
FORMAZIONE
U
tailoring
T:
E:
P:
U:
da il compito
esegue
partecipa
utilizza
esercizio
T
T
acquisizione
P
E
E
JOINT
REVIEW
E
fornitura
manutenzione
U
E
AUDIT
P
V & V
E
sviluppo
E
E
U
QUALITÁ
E
E
RISOLUZ.
PROBLEMI
E
CONTROLLO
GESTIONE