analisi e messa in opera in ambito aziendale...
TRANSCRIPT
Università di Roma
“Sapienza”
Facoltà di Ingegneria
Corso di Laurea in
Ingegneria delle Telecomunicazioni
Laurea Specialistica
ANALISI E MESSA IN OPERA IN AMBITO
AZIENDALE DEL CMMI (CAPABILITY
MATURITY MODEL INTEGRATION): SVILUPPO
E GESTIONE DEI REQUISITI
Relatore Laureanda
CH.MO PROF. Roberto Cusani Palma Polidoro
Anno Accademico 2005 – 2006
Dedico la mia tesi a
Zio Mario e Zio Roberto
Indice
Analisi e messa in opera in ambito aziendale del CMMI: - 2 -
sviluppo e gestione dei requisiti.
INDICE
INDICE ..................................................................................................................... 2
INTRODUZIONE ................................................................................................... 4
1. GESTIONE DELLA QUALITÀ ..................................................................... 5
2. IL CAPABILITY MATURITY MODEL® INTEGRATION ................... 31
2.1 I componenti del modello ............................................................................................ 31
2.1.1 Le aree di processo ............................................................................................................... 32
2.1.2 Obiettivi generici .................................................................................................................. 38
2.1.3 Pratiche generiche ................................................................................................................ 38
2.1.4 Obiettivi specifici .................................................................................................................. 38
2.1.5 Pratiche specifiche ............................................................................................................... 38
2.1.6 Typical Work Product ........................................................................................................... 39
2.1.7 Sottopratiche ......................................................................................................................... 39
2.2 I livelli di capability ..................................................................................................... 39
2.3 I livelli di maturity ....................................................................................................... 43
2.4 Le due rappresentazioni ............................................................................................. 46
2.4.1 La rappresentazione scalare ................................................................................................ 46
2.4.2 La rappresentazione continua .............................................................................................. 48
2.4.3 Differenze tra le due rappresentazioni ................................................................................. 50
2.5 Quadro conclusivo per la registrazione aziendale .................................................... 53
3. L’APPROCCIO AZIENDALE AL CMMI ................................................. 56
4. SVILUPPO DEI REQUISITI ....................................................................... 63
4.1 Descrizione ................................................................................................................... 63
4.2 Assessment ................................................................................................................... 66
4.3 Analisi dei dati raccolti ............................................................................................... 78
5. GESTIONE DEI REQUISITI ....................................................................... 80
5.1 Descrizione ................................................................................................................... 80
5.2 Assessment ................................................................................................................... 81
5.3 Analisi dei dati raccolti ............................................................................................... 87
6. PROGETTAZIONE DEL NUOVO SISTEMA PROCEDURALE .......... 89
6.1 Quadro d’insieme: il nuovo sistema procedurale ..................................................... 89
Indice
Analisi e messa in opera in ambito aziendale del CMMI: - 3 -
sviluppo e gestione dei requisiti.
6.2 Scheda progetto ........................................................................................................... 90
6.3 Procedura: Sviluppo e Gestione dei requisiti ........................................................... 93
6.3.1 Descrizione ........................................................................................................................... 93
6.3.2 Mapping delle pratiche specifiche con la procedura ........................................................... 94
6.4 Procedura: Gestione Offerta ed Ordine di Vendita ............................................... 110
6.4.1 Descrizione ......................................................................................................................... 110
6.4.2 Mapping delle pratiche specifiche con la procedura ......................................................... 111
CONCLUSIONI .................................................................................................. 112
APPENDICE A.1 ................................................................................................. 116
APPENDICE A.2 ................................................................................................. 117
APPENDICE A.3 ................................................................................................. 131
APPENDICE B.1 ................................................................................................. 138
APPENDICE B.2 ................................................................................................. 139
APPENDICE B.3 ................................................................................................. 145
INDICE DELLE FIGURE ................................................................................. 152
BIBLIOGRAFIA ................................................................................................. 153
Introduzione
Analisi e messa in opera in ambito aziendale del CMMI: - 4 -
sviluppo e gestione dei requisiti.
INTRODUZIONE
Ora più che mai, le società sentono l'esigenza di proporre prodotti più performanti e più a buon
mercato. Sebbene lo sviluppo software non sia il motore di business per la maggior parte delle
aziende, il software stesso è diventato uno strumento di distinzione strategica e competitiva per
molti settori. In quanto tale, aziende manufatturiere, istituzioni finanziare, amministrazioni
pubbliche, come i classici produttori software, evidenziano sempre più la loro dipendenza nella
capacità di gestire lo sviluppo di software ad alto livello qualitativo ed in grado di integrarsi con i
loro prodotti o portfolio di servizi.
Attualmente sono presenti vari modelli, standard, metodologie e linee guida che possono
valorizzare il proprio modo di lavorare. Tuttavia, la maggior parte degli approcci disponibili si
concentrano su una specifica area di business e non offrono un approccio sistematico e completo
al problema.
Il CMMI®
(Capability Maturity Model®
Integration) fornisce uno strumento per creare un punto
di integrazione attraverso un modello trascendente dalle discipline. Consiste di un insieme di
best practice, focalizzate a migliorare i processi aziendali per l’acquisizione, lo sviluppo,
l’integrazione e la manutenzione di prodotti o servizi.
Il lavoro di tesi, svolto in azienda con la continua supervisione del Responsabile Qualità, ha
l’obiettivo di descrivere il percorso che ha intrapreso la Chorus S.p.A, per analizzare e mettere in
opera i dettami di un moderno modello di Total Quality Management, allo scopo di
industrializzare e perfezionare la gestione dei propri processi aziendali e di istituzionalizzare il
miglioramento continuo.
Gestione delle qualità
Analisi e messa in opera in ambito aziendale del CMMI: - 5 -
sviluppo e gestione dei requisiti.
1. GESTIONE DELLA QUALITÀ
La gestione della qualità è divenuta un punto chiave per garantire l’efficienza di
tutte le attività svolte da aziende ed organizzazioni. Infatti essa incide direttamente sui
costi aziendali che, secondo alcune stime, possono arrivare al 30% dei ricavi
dell’organizzazione, qualora ci sia un’insufficienza qualitativa nei processi, nei prodotti,
nella gestione delle relazioni fra le unità interne, con i clienti e coi fornitori, nei
meccanismi manageriali, e nella gestione delle risorse umane, tecniche e del patrimonio.
Un aspetto emerso solo negli ultimi anni è la consapevolezza della criticità del fattore
umano: la qualità è fondata sulle persone e sull’organizzazione, e richiede una
rivoluzione manageriale ed organizzativa piuttosto che una profonda trasformazione
tecnologica.
Gli strumenti principali per migliorare in modo sistematico la qualità nei processi
sono i programmi di miglioramento della qualità e la certificazione di qualità, ed i
programmi di accertamento e miglioramento della maturità del ciclo produttivo.
1.1 Il contesto organizzativo
Lo sviluppo di prodotti può avvenire nell’ambito di tre modelli di organizzazione
a volte coesistenti:
– l’organizzazione gerarchica,
– l’organizzazione per processi,
– l’organizzazione mista (gerarchica nella struttura organizzativa e per processi nello
sviluppo del prodotto).
L’organizzazione gerarchica, molto diffusa, ha consentito di raggiungere elevati livelli di
efficienza della singole funzioni introducendo però forti rigidità; appare poco efficace a
rispondere rapidamente ed in modo flessibile alle sollecitazioni di un contesto in continua
evoluzione e fortemente competitivo.
L’organizzazione per processi ha dimostrato di essere la più idonea ad affrontare la
competizione:
– per le caratteristiche di flessibilità,
– per la capacità di perseguire gli obiettivi,
Gestione delle qualità
Analisi e messa in opera in ambito aziendale del CMMI: - 6 -
sviluppo e gestione dei requisiti.
– per l’ottimale utilizzo delle risorse,
– per la semplificazione del confronto con la concorrenza,
– per la semplificazione che introduce nell’integrazione di realtà aziendali diverse.
Ad oggi poche aziende adottano in modo integrale questo tipo di organizzazione, perché
la migrazione dall’organizzazione gerarchica ad una per processi comporta un
cambiamento di ruoli a cui l’ambiente aziendale si adatta con difficoltà.
Più agevole è l’adozione di un’organizzazione mista che, pur recependo numerosi
vantaggi dell’organizzazione per processi, conserva la struttura gerarchica attenuando la
difficoltà di adattamento.
Il contesto industriale evolve continuamente, sia tecnologicamente che strutturalmente,
divenendo più flessibile e più efficiente. Questa situazione richiede un atteggiamento
mentale e metodologie di lavoro orientati al miglioramento continuo, che richiede
appunto un metodo organizzativo adatto, che faccia propri tali orientamenti e ne faciliti
l’attuazione.
Ciò si realizza identificando un sistema di processi, che rappresenti le attività aziendali
(principalmente quelle legate al ciclo di vita dei prodotti), e gestendo le interazioni tra i
processi stessi. Il CMMI focalizza l’attenzione proprio sul concetto di processo.
Un processo è costituito da una serie di step che portano alla soluzione di un
problema. Per essere efficaci, questi step devono essere definiti in modo non ambiguo,
che siano quindi, facilmente comprensibili e semplici da eseguire da chiunque utilizzi il
processo. L'obiettivo è dunque ridurre il lavoro superfluo.
Più precisamente, un processo è definito come un insieme organizzato di attività e
di decisioni, finalizzato alla creazione di output, richiesti da clienti, a partire da input
definiti e che, insieme a controlli e risorse, ne costituiscono gli elementi fondamentali.
Ogni volta che viene intrapreso un nuovo progetto, conviene avere a disposizione una
procedura che guidi il processo di stesura del project plan, e che fornisca esempi da cui
trarre informazioni, invece di procedere alla sua composizione e scrittura ex-novo ogni
volta. I processi devono descrivere gli elementi fondamentali di un’attività, insieme alle
condizioni al contorno e quelle iniziali da rispettare, ma non fornisce indicazioni sulle
modalità di realizzazione, e questo comporta una grande flessibilità, che si può utilizzare
per nuovi esperimenti e modifiche.
La descrizione di un processo deve prevedere:
Gestione delle qualità
Analisi e messa in opera in ambito aziendale del CMMI: - 7 -
sviluppo e gestione dei requisiti.
- Le attività del processo
- Chi le svolge
- Quando (in che condizioni)
- Come (con quali strumenti)
- Gli input e le condizioni di attivazione
- Gli output e le condizioni di completamento
- Le misure e gli indicatori di performance.
Nel nostro caso, un processo è definito ad alto livello e ad esso sono associate delle
procedure, che sono descritte con un livello di dettaglio maggiore.
L'utilizzo di processi permette di adeguare il proprio modo di fare business, fornisce la
possibilità di adattare le proprie risorse e costruisce una direzione per migliorare i propri
prodotti e servizi: i processi costituiscono proprio l'elemento di unione tra persone e
tecnologie. La Figura 1 mostra le tre dimensioni su cui tipicamente si focalizzano le
organizzazioni: persone, procedure e metodi, ed infine tool ed apparecchiature.
Figura 1 - Le tre dimensioni critiche di un'azienda
Da sottolineare il fatto che l’approccio per processi non costituisce l’unica alternativa
valida per una gestione aziendale ottima, ma sta di fatto che ne è elemento portante, se
Persone con
skill, training
e motivazione
PROCESSO
Procedure e metodi
che definiscono le
relazioni tra i task
Tool ed
apparecchiature
Gestione delle qualità
Analisi e messa in opera in ambito aziendale del CMMI: - 8 -
sviluppo e gestione dei requisiti.
supportato da training, da un budget adeguato, da personale con skill opportuni, da giusti
strumenti, e da impegno da parte del management.
1.2 Standard Internazionali (ISO)
In Italia e nell’Unione Europea esistono due tipologie di standard per il controllo
di qualità nei processi di produzione:
Regole tecniche, emesse da uno stato attraverso delle leggi e/o dei regolamenti, in
base a direttive europee; il loro rispetto è obbligatorio (cogente);
Norme tecniche consensuali, elaborate e pubblicate da enti di normazione
riconosciuti, la cui applicazione non è obbligatoria ma volontaria. Esse possono
avere valore:
- Italiano: in tal caso ci si riferisce a norme UNI (Ente Nazionale Italiano di
Unificazione) CEI (Comitato Elettrotecnico Italiano);
- Europeo: sono le norme EN (European Standard);
- Internazionale: le norme sono denominate ISO (International Organization
for Standardization) e IEC (International Electrotechnical Commission).
Il fondamento degli standard per la qualità è costituito dalla famiglia di norme ISO 900X,
emesse a partire dagli anni ’80. Sono norme di tipo consensuale che, nel loro insieme,
forniscono le regole manageriali/organizzative e di processo che le organizzazioni
operanti in qualsiasi settore (produzione o servizi) dovrebbero seguire per rendere
razionali, efficienti, efficaci ed affidabili le attività del loro ciclo produttivo e lavorativo,
e il loro modo di interagire con i clienti.
La famiglia di standard internazionali ISO 900X è la base di riferimento per il processo di
attribuzione di un certificato di qualità alle imprese che vogliano aderire in modo
sistematico alle raccomandazioni e alle prescrizioni degli standard. Tale certificato è
rilasciato da enti indipendenti che non solo assegnano il certificato dopo una fase
preliminare di osservazione dell’azienda, ma verificano anche, con azioni di
monitoraggio, la continuità nel rispetto delle norme.
Gli obiettivi principali delle norme ISO 900X sono due:
Obiettivo tecnico – organizzativo: consiste nel fornire un insieme di regole
concettuali per migliorare e razionalizzare i processi di produzione;
Gestione delle qualità
Analisi e messa in opera in ambito aziendale del CMMI: - 9 -
sviluppo e gestione dei requisiti.
Obiettivo di marketing: consiste nel creare nei clienti una fiducia nei confronti
delle organizzazioni che dimostrano di applicare bene queste regole.
Le norme base della famiglia ISO 900X sono la ISO 9000, la ISO 9001, la ISO 9004, e la
ISO 90003.
La UNI EN ISO 9000: 2000 “Sistemi di gestione per la qualità – Fondamenti e
terminologia”, oltre a contenere i concetti fondamentali su cui si basano i sistemi di
gestione per la qualità, prevede che i processi lavorativi di un’organizzazione vengano
descritti in documenti specifici, che sono:
- Manuale della qualità;
- Piano della Qualità;
- Piano di Progetto;
- Piano di Gestione della Configurazione.
1.2.1 UNI EN ISO 9001: 2000
La UNI EN ISO 9001: 2000 “Sistemi di gestione per la qualità – Requisiti” è la
norma più rilevante tra quelle della famiglia ISO 900X, e si rivolge alla funzione di
assicurazione della qualità.
Un sistema di gestione per la qualità è l’insieme dei controlli, delle attività e delle
risorse che un’organizzazione definisce al fine di ottenere in modo affidabile e ripetibile
prodotti e servizi conformi a specifiche fornite da un cliente, al minor costo possibile e
nei tempi stabiliti.
L’assicurazione della qualità è l’insieme delle attività pianificate e sistematicamente
attuate in un’organizzazione per dimostrare (ai potenziali clienti o al proprio
management) la capacità di fornire un prodotto conforme ai requisiti.
La ISO 9001 definisce i requisiti base di un modello di assicurazione della qualità valido
per tutte le organizzazioni, e può essere utilizzata per uso interno, per scopi contrattuali e
di certificazione.
I requisiti definiti dalla norma ISO 9001 riguardano non solo i principali processi del
ciclo produttivo vero e proprio (i cosiddetti processi primari del ciclo), ma anche i
processi manageriali, organizzativi, di controllo e di supporto a quelli primari, di
marketing e interfaccia con il cliente, secondo il presupposto che un ciclo produttivo è
Gestione delle qualità
Analisi e messa in opera in ambito aziendale del CMMI: - 10 -
sviluppo e gestione dei requisiti.
tanto più affidabile quanto più è controllato e documentato, e le attività svolte sono
consolidate ed istituzionalizzate nell’ambiente lavorativo, e vicine ai requisiti-utente.
I requisiti ISO 9001 sono ad un livello di astrazione piuttosto alto, in quanto pensati per
essere applicabili da qualsiasi organizzazione, indipendentemente dal settore in cui opera.
Perciò, la ISO 9001 non entra nel merito di “come” vanno svolte, dal punto di vista
tecnico, le attività previste dai vari processi lavorativi, ma definisce, per ogni processo
preso in considerazione, quegli accorgimenti di natura manageriale/organizzativa che
hanno maggiore influenza sul risultato finale del processo.
Le aree di processo cui sono rivolti i requisiti ISO 9001 sono poche: erano 20 nella
versione 1994 della norma, ma sono solo 5 nella versione 2000. Esse sono:
- Quality Management System;
- Management Responsibility;
- Resource Management;
- Product Realization;
- Measurement, analysis & improvement.
Questo numero ridotto di processi cui si rivolge la norma è dovuto all’intento di
focalizzare l’attenzione solo su quelli a reale valore aggiunto per una organizzazione, in
particolare su quei processi di cui i potenziali clienti possono avere una diretta
percezione.
Tra gli elementi base della norma si evidenziano in particolare:
“Ritagliabilità” (tailoring), ovvero la possibilità per le organizzazioni di
personalizzare i requisiti di base in funzione di specifici obiettivi;
Gestione delle qualità
Analisi e messa in opera in ambito aziendale del CMMI: - 11 -
sviluppo e gestione dei requisiti.
Maggiore facilità d’uso del modello, in modo da estendere la possibilità di
valutazione del grado di applicazione dei requisiti della norma oltre gli addetti ai
lavori;
Minore enfasi sulla documentazione dei processi;
Introduzione di elementi di valutazione del Sistema per la Gestione della Qualità
legata a risultati di efficacia oltre che di efficienza;
Allargamento delle linee aziendali interessate al Sistema di gestione per la
Qualità, con particolare riferimento a chi gestisce gli aspetti finanziari,
manageriali, amministrativi, commerciali, di relazione con la clientela, l’impatto
sull’ambiente etc;
Specifici punti del modello dedicati alla rilevazione e gestione della
“soddisfazione del cliente”;
Necessità per le organizzazioni di definire obiettivi misurabili di miglioramento,
valutabili dagli auditor;
Importanza data alle risorse umane (e alla formazione) come fattore primario di
miglioramento.
Le organizzazioni possono richiedere (su base volontaria) ad organismi specializzati, di
rilasciare loro (dopo aver compiuto delle verifiche) una certificazione di conformità del
loro Sistema di gestione per la Qualità rispetto ai requisiti ISO 9001.
Con il termine “certificazione” si intende l’atto formale con il quale un organismo
accreditato a livello nazionale od internazionale dichiara che un determinato prodotto,
processo, servizio o sistema qualità è conforme a quanto prescritto da una normativa ad
esso applicabile.
L’accreditamento di un certificatore è definito come il riconoscimento formale, rilasciato
ad un laboratorio di prova o ad un organismo di auditing, della idoneità ad effettuare
determinati tipi di verifiche. Va sottolineato che l’accreditamento è una scelta volontaria.
In Italia la maggior parte degli organismi di certificazione (>150) è accreditata dal
SINCERT (Sistema Nazionale per l’accreditamento degli organismi di CERtificazione),
creato nel 1991 da UNI, CEI, CNR, ENEA, Ministero dell’Industria. Sul sito web del
SINCERT (www.sincert.it) si può verificare se una data Società è in possesso di una
certificazione, la sua estensione, e validità temporale.
In Italia molti organismi che effettuano certificazioni nel settore ISO 9001 sono riuniti
nella federazione CISQ (Certificazione Italiana Sistemi Qualità, www.cisq.com); a livello
Gestione delle qualità
Analisi e messa in opera in ambito aziendale del CMMI: - 12 -
sviluppo e gestione dei requisiti.
europeo l’Ente di riferimento per gli organismi di certificazione è lo IQNET (www.iqnet-
certification.com), che raggruppa enti che operano in 150 nazioni (incluso il CISQ).
Questi organismi aderiscono poi allo IAF (International Accreditation Forum,
www.iaf.nu), ed allo EA (European Accreditation, www.european-accreditation.org).
Il rilascio della certificazione ISO 9001 avviene a seguito di un certo numero di visite
ispettive, nelle quali vengono esaminati gli elementi di valutazione previsti dal metodo di
verifica adottato (ad esempio il metodo CSQ/ITQS per il settore ICT).
In Italia, al 28/2/2006, risultano certificati rispetto alla norma ISO 9001 i Sistemi di
Gestione per la Qualità (SGQ) di oltre 76.400 organizzazioni (Fonte SINCERT), di cui
circa 2800 del settore ICT (Information Communication Technology), in cui operano 25
organismi di certificazione accreditati dal SINCERT.
La UNI EN ISO 9004: 2000 “Sistemi di gestione per la qualità – Linee guida per
il miglioramento delle prestazioni”, fornisce delle linee guida complementari ai requisiti
della ISO 9001 per migliorare l’efficacia e l’efficienza di un sistema di gestione per la
qualità e le prestazioni dell’organizzazione. E’ una norma applicabile ai processi di
un’organizzazione indipendentemente dal tipo e dalla dimensione della stessa, e dai
prodotti forniti (settore in cui opera, compresi i servizi). La ISO 9004 non è però una
norma utilizzabile per ottenere certificazioni.
La norma UNI CEI ISO/IEC 90003: 2005 “Ingegneria del software e di sistema –
Guida per l’applicazione della ISO 9001: 2000 al software per elaboratore” è costruita
come precisazione puntuale ai requisiti della ISO 9001 nel settore dell’ICT (Information
Communication Technology), ma non è una norma utilizzabile come riferimento diretto
per ottenere certificazioni del sistema di gestione per la qualità di una organizzazione che
opera nel settore ICT. Questa norma fornisce indicazioni riguardo ai processi di
acquisizione, fornitura, sviluppo, gestione operativa e manutenzione del software. E’
indipendente dalla tecnologia, dai modelli del ciclo di vita, dai processi di sviluppo, dalla
sequenza delle attività e dalla struttura organizzativa utilizzata da una organizzazione, ed
è utilizzabile per prodotti sviluppati ad hoc, prodotti COTS (Commercial Off The Shelf),
e software inserito in prodotti hardware.
Gestione delle qualità
Analisi e messa in opera in ambito aziendale del CMMI: - 13 -
sviluppo e gestione dei requisiti.
In conclusione, gli standard della serie ISO 900X forniscono una serie di
indicazioni generali su come dovrebbe essere organizzata un’azienda che centra il proprio
successo sulla garanzia di qualità dei beni e servizi offerti ai propri clienti. Essi non
suggeriscono però una pratica per il miglioramento dei processi, ma semplicemente
indicano la soglia di accettazione o di rifiuto della qualità.
1.2.2 UNI CEI ISO/IEC 12207: 2003
La norma definisce uno schema di riferimento comune per i processi relativi al
ciclo di vita del software, utilizzando una ben definita terminologia, che può essere presa
a riferimento dall’industria del software. La norma include i processi, le attività ed i
compiti che devono essere svolti durante l’acquisizione di sistemi software, di prodotti
software a sé stanti, di servizi software e durante la fornitura, lo sviluppo, la gestione
operativa e la manutenzione di prodotti software. Il termine software include la parte
software contenuta nel firmware.
La norma fornisce anche un modello di processo che può essere utilizzato per la
definizione, il controllo ed il miglioramento dei processi relativi al ciclo di vita del
software.
E’ applicabile alle attività di acquisizione di sistemi, prodotti e servizi software, alle
forniture, allo sviluppo, alla gestione operativa ed alla manutenzione dei prodotti
software, alla parte software contenuta nel firmware, sia sviluppata internamente che
esternamente ad una organizzazione. Vengono, inoltre, inclusi quegli aspetti relativi alla
definizione di sistema, necessari per definire il contesto dei prodotti e dei servizi
software.
Questa norma internazionale descrive l’architettura dei processi del ciclo di vita del
software, ma non specifica i dettagli in merito a come sviluppare o eseguire le attività o i
compiti inclusi nel processo; essa inoltre non prescrive uno specifico modello di ciclo di
vita o un metodo di sviluppo del software.
La norma raggruppa le attività che possono essere svolte lungo il ciclo di vita del
software in cinque processi primari, otto processi di supporto e quattro processi
organizzativi.
Gestione delle qualità
Analisi e messa in opera in ambito aziendale del CMMI: - 14 -
sviluppo e gestione dei requisiti.
Ciascun processo del ciclo di vita è diviso in un insieme di attività, e ciascuna attività è a
sua
volta suddivisa in una serie di compiti.
I processi primari del ciclo di vita sono cinque e riguardano i soggetti principali
che sono coinvolti nel ciclo di vita del software. Un soggetto principale è colui che inizia
o svolge lo sviluppo, la gestione operativa o la manutenzione di un prodotto software.
Questi soggetti principali sono gli acquirenti, i fornitori, gli sviluppatori, gli operatori ed i
manutentori dei prodotti software. I processi primari sono:
1) Processo di Acquisizione;
2) Processo di Fornitura;
Gestione delle qualità
Analisi e messa in opera in ambito aziendale del CMMI: - 15 -
sviluppo e gestione dei requisiti.
3) Processo di Sviluppo;
4) Processo di Gestione Operativa;
5) Processo di Manutenzione.
I processi di supporto del ciclo di vita sono otto. Un processo di supporto sostiene
un altro processo come parte integrante con uno scopo differente e contribuisce ad
assicurare il successo e la qualità del progetto software. Un processo di supporto è
utilizzato e svolto, come necessario, da un altro processo. I processi di supporto sono:
1) Processo di Documentazione;
2) Processo di Gestione della Configurazione;
3) Processo di Assicurazione Qualità;
4) Processo di Verifica;
5) Processo di Validazione;
6) Processo del Riesame Congiunto;
7) Processo di Verifica Ispettiva;
8) Processo di Risoluzione dei Problemi.
I processi organizzativi del ciclo di vita sono quattro. Sono applicati da una
organizzazione allo scopo di definire e sviluppare una struttura base costituita da processi
collegati del ciclo di vita e da personale, allo scopo di migliorare continuamente la
struttura stessa ed i processi. Questi processi sono di solito sviluppati fuori dell’ambito di
specifici progetti o contratti; comunque, le esperienze accumulate da tali contratti e
progetti contribuiscono al miglioramento dell’organizzazione. I processi organizzativi
sono:
1) Processo di Gestione;
2) Processo di Infrastruttura;
3) Processo di Miglioramento;
4) Processo di Formazione.
1.2.3 ISO IEC 9126-1: 2000
La norma ISO/IEC 9126 “Software engineering – Product quality” contiene il
modello di riferimento per definire le caratteristiche di qualità del software e le metriche
per la valutazione della qualità che il software possiede.
Gestione delle qualità
Analisi e messa in opera in ambito aziendale del CMMI: - 16 -
sviluppo e gestione dei requisiti.
Si può utilizzare per definire i requisiti qualitativi del software, e per definire le misure
che vanno rilevate per valutare la qualità di un software.
Quanto definito dalla 9126 è applicabile a qualsiasi tipo di software (Custom o COTS).
Non sono previste certificazioni di qualità del prodotto software rispetto a questa norma.
La norma si compone di queste parti:
1) Il modello delle caratteristiche e sottocaratteristiche di qualità del software
(ISO/IEC 9126-1 Software Engineering. Product Quality - Part 1: Quality model,
2001);
2) Le metriche per la misura della qualità esterna (ISO/IEC TR 9126-2, 2003);
3) Le metriche per la misura della qualità interna (ISO/IEC TR 9126-3, 2003);
4) Le metriche per la misura della qualità in uso (ISO/IEC TR 9126-4, 2004).
La parte per noi di maggior interesse è la 9126-1. Essa definisce un modello a quattro
livelli:
Tre “punti di vista” sulla qualità del software (esterno, interno ed in uso) che
qualsiasi progetto di sviluppo deve prendere in considerazione e soddisfare;
I principali attributi (definiti come requisiti qualitativi) che qualificano un
software, secondo i 3 punti di vista;
Per ogni attributo, le sottocaratteristiche (requisiti quantitativi, misurabili) che la
rappresentano, e che dovranno essere misurate per valutare il livello di qualità
effettivamente raggiunto nel software;
Le metriche per effettuare le misure.
Di particolare rilievo sono le sei caratteristiche che rappresentano la qualità esterna ed
interna di un prodotto software:
- Funzionalità: capacità di fornire servizi tali da soddisfare, in determinate
condizioni, requisiti funzionali espliciti o impliciti;
- Affidabilità: capacità di mantenere le prestazioni stabilite nelle condizioni
e nei tempi fissati;
- Usabilità: capacità di essere compreso, appreso, usato con soddisfazione
dal cliente in determinate condizioni d’uso;
- Efficienza: rapporto fra prestazioni e quantità di risorse utiizzate, in
condizioni definite di funzionamento;
- Manutenibilità: capacità di essere modificato con un impegno contenuto;
Gestione delle qualità
Analisi e messa in opera in ambito aziendale del CMMI: - 17 -
sviluppo e gestione dei requisiti.
- Portabilità: facilità con cui un software può essere trasferito da un sistema
operativo ad un altro.
La qualità in uso è rappresentata da 4 caratteristiche, che rappresentano il punto di vista
dell’utente sul software. Rappresenta la capacità del software di supportare specifici
utenti a raggiungere determinati obiettivi, con efficacia, produttività, soddisfazione e
sicurezza personale, in determinati contesti d’uso. Le quattro caratteristiche sono:
- Efficacia, la capacità di supportare un utente nel raggiungere i suoi
obiettivi con accuratezza e completezza in un dato contesto.
- Produttività, la capacità di supportare un utente nello spendere
l’appropriata quantità di risorse in relazione all’efficacia dei risultati da
raggiungere.
- Soddisfazione, la capacità di soddisfare un utente in un dato contesto
d’uso.
- Sicurezza, la capacità di raggiungere accettabili livelli di rischio per le
persone, l’ambiente di utilizzo, le attività dell’utilizzatore, in un dato
contesto d’uso.
Per quanto riguarda l’applicabilità della norma, possiamo dire che il modello 9126 può
essere utilizzato per definire i requisiti di ogni tipo di software, Custom, COTS, incluso il
"firmware". La valutazione della qualità secondo la 9126 è possibile in ogni momento del
ciclo di vita, dall’acquisizione, allo sviluppo (progettazione, codifica), alla manutenzione.
Destinatari sono quindi tutti gli attori del ciclo di vita del software, utenti, sviluppatori,
gestori ed addetti alla manutenzione, manager, auditor, ognuno secondo le proprie
esigenze.
1.3 Altri standard (ECSS, MIL-STD-498, AQAP-160)
ECSS
La standardizzazione è uno strumento importante per ridurre i costi e migliorare la
qualità e comunicazione durante la preparazione e l’esecuzione dei programmi
internazionali. Nel passato le Agenzie Spaziali in Europa ed i loro maggiori contraenti
hanno sviluppato individualmente degli standard, e li hanno applicati ai loro progetti.
Gestione delle qualità
Analisi e messa in opera in ambito aziendale del CMMI: - 18 -
sviluppo e gestione dei requisiti.
L’ECSS (European Cooperation for Space Stadardization) rappresenta un impegno
congiunto dell’ESA (European Space Agency), delle Agenzie Spaziali Nazionali e
dell’industria Europea per sviluppare, mantenere ed applicare degli standard comuni a
tutti i progetti spaziali Europei.
L’obiettivo del Sistema di Standardizzazione ECSS è quello di minimizzare il costo del
ciclo di vita, migliorando allo stesso tempo la qualità, l’integrità funzionale e la
compatibilità di tutti gli elementi di un progetto, applicando standard comuni per
l’hardware, il software, le informazioni e le attività nei progetti.
Gli standard ECSS coprono le seguenti categorie di requisiti per progetti ed applicazioni
spaziali:
Requisiti di gestione del progetto;
Requisiti per attività di progettazione, sviluppo, produzione e verifica, applicate a
sistemi spaziali e alle loro parti costituenti;
Requisiti e metodi di assicurazione della qualità del prodotto;
Requisiti di interfaccia, per informazioni relative a sistemi spaziali ed attività,
trasmessi tra le varie organizzazioni.
Gli Standard ECSS includono specifiche, linee guida, manuali, guide e procedure. In
generale, tutti i documenti emessi dall’ECSS sono denominati standard. Questi standard
devono essere tailorizzabili per progetti differenti e si applicano a tutte le fasi ed attività
dall’inizio alla fine di un progetto, inclusa l’analisi e la dismissione di una missione.
Gli obiettivi generali degli standard ECSS sono:
Ottenere programmi spaziali in Europa che siano ottimizzati dal punto di vista
dei costi;
Promuovere un miglioramento della qualità, sicurezza e protezione
ambientale;
Promuovere una comunicazione chiara e non ambigua tra tutte le parti
interessate;
Organizzare e gestire lo sviluppo di un unico insieme di standard, comuni e
coerenti, per la comunità spaziale Europea, evitando così duplicazioni non
necessarie;
Raggiungere un riconoscimento formale di Standard Europeo (EN), per una
parte selezionata degli standard, dal CEN (European Committee for
Gestione delle qualità
Analisi e messa in opera in ambito aziendale del CMMI: - 19 -
sviluppo e gestione dei requisiti.
Standardization), dal CENELEC (European Committee for Electrotechnical
Standardization), e dall’ETSI (European Telecommunication Standard
Institute), aumentando in questo modo la competitività a livello internazionale
dell’industria spaziale Europea;
Raggiungere un riconoscimento formale di Standard ISO, per una parte
selezionata degli standard, dall’ International Organization for
Standardization.
La policy dell’ECSS è quella di:
Promuovere il miglioramento continuo di tecniche e metodi, ed evitare lavoro
non necessario;
Incorporare sistematicamente nel sistema ECSS l’esperienza proveniente dai
progetti passati e da altre appropriate sorgenti;
Aumentare l’efficienza industriale e la competitività limitando la varietà di
prodotti e processi;
Incorporare, dove possibile, gli standard applicati dai membri partecipanti, e
di non creare duplicati degli standard internazionali.
Infine, gli standard ECSS devono:
Rispondere ad una necessità chiaramente espressa dalla comunità spaziale,
tenendo in dovuto conto lo stato dell’arte;
Essere facili da utilizzare, ed in particolare devono essere completi quanto
basta, concisi, consistenti, accurati e non ambigui;
Essere comprensibili per persone qualificate, e strutturati in modo da
facilitare la tailorizzazione per progetti specifici;
Contenere requisiti di cui beneficia l’intera comunità, e che non diano un
vantaggio esclusivo a nessuna organizzazione individuale;
Essere scritti e strutturati in modo tale da facilitare il trasferimento verso il
CEN, CENELEC, ETSI e ISO.
MIL – STD – 498
Gestione delle qualità
Analisi e messa in opera in ambito aziendale del CMMI: - 20 -
sviluppo e gestione dei requisiti.
Il MIL – STD – 498 è uno standard militare, approvato per l’utilizzo da parte
di tutti i Dipartimenti e tutte le Agenzie del Dipartimento della Difesa degli Stati Uniti
d’America.
Esso scaturisce dalla fusione di due precedenti standard, e definisce una serie di attività e
di documentazione per lo sviluppo di sistemi di difesa e sistemi di informazione
automatizzati. Più precisamente, lo scopo di questo standard è quello di stabilire dei
requisiti uniformi per lo sviluppo e la documentazione software.
Il MIL – STD – 498 può essere applicato in ogni fase del ciclo di vita del sistema; non è
stato creato inoltre per specificare o scoraggiare l’uso di un particolare metodo di
sviluppo del software. Questo standard implementa i processi di sviluppo e di
documentazione della ISO/IEC 12207, e include tutte le attività che riguardano lo
sviluppo del software, dove con “sviluppo del software” qui si intende nuovo sviluppo,
modifica, riuso, reingegnerrizzazione, manutenzione, e tutte le altre attività che
riguardano i prodotti software.
Lo sviluppatore software deve stabilire un processo di sviluppo software consistente con i
requisiti contenuti nel contratto. Il processo deve includere le seguenti attività principali,
che si possono sovrapporre, possono essere applicate iterativamente, possono essere
applicate in modo diverso a differenti elementi del software, e non necessitano di essere
applicati nell’ordine in cui compaiono nella lista. Inoltre il processo di sviluppo del
software deve essere descritto nel Piano di Sviluppo del Software.
Le attività principali sono:
Pianificazione del progetto e monitoraggio;
Stabilire un ambiente di sviluppo software;
Analisi dei requisiti di sistema;
Design del sistema;
Analisi dei requisiti del software;
Design del software;
Implementazione del software e test delle unità;
Integrazione delle unità e test;
Test di qualificazione di CSCI (Computer Software Configuration Item);
Integrazione e test di CSCI/HWCI (Hardware Configuration Item);
Test di qualificazione del sistema;
Gestione delle qualità
Analisi e messa in opera in ambito aziendale del CMMI: - 21 -
sviluppo e gestione dei requisiti.
Preparazione per l’uso del software;
Preparazione per la transizione del software;
Processi integrali:
- Gestione della configurazione software;
- Valutazione del prodotto software;
- Assicurazione di qualità del software;
- Azioni correttive;
- Revisioni tecniche e di gestione;
- Altre attività.
AQAP 160
L’AQAP 160 (Edizione 1) “NATO Integrated Quality Requirements for
Software Throughout the Life Cycle” è una pubblicazione della North Atlantic Treaty
Organization, e contiene i requisiti per un sistema di gestione della qualità del software
attraverso il ciclo di vita. Con “software” si intende anche la porzione software del
firmware.
Questa pubblicazione stabilisce anche una struttura comune per i processi del ciclo di vita
del software, con una terminologia ben definita, che può essere presa come riferimento
dall’industria.
L’AQAP 160 è strutturata in modo tale da poter essere tailorizzata per una determinata
organizzazione, progetto o applicazione all’interno del progetto. Quando tailorizzata,
questa pubblicazione specifica i requisiti per gestire la qualità dei processi del ciclo di
vita del software, e dei risultanti prodotti e servizi.
Essa è stata concepita soprattutto per essere applicata quando si è in presenza di un
contratto tra due parti, ma può essere anche utilizzata internamente ad un’organizzazione
per la fornitura (e relativa acquisizione, sviluppo, produzione, operazione e
manutenzione) del software immerso (embedded) in un sistema e/o un servizio software.
Il modello dell’AQAP 160 Edizione 1 è composto da:
Requisiti correlati al processo: un insieme di requisiti per i processi primari e di
supporto basati sulla ISO/IEC 12207, integrati con quei requisiti della ISO 9001:
2000 non esplicitamente coperti dalla 12207.
Requisiti del sistema di qualità: requisiti organizzativi imposti al fornitore, basati
sulla ISO 9001: 2000, e correlati ai processi primari e di supporto;
Gestione delle qualità
Analisi e messa in opera in ambito aziendale del CMMI: - 22 -
sviluppo e gestione dei requisiti.
Requisiti specifici della NATO, dovuti al fatto che l’acquisizione avviene in un
contesto NATO.
1.4 Modelli di Maturità
Nel paragrafo 1.2 abbiamo visto come gli standard della famiglia ISO 900X non
forniscano una pratica per il miglioramento dei processi, ma indicano semplicemente una
soglia di accettazione o di rifiuto della qualità.
I modelli di maturità costituiscono invece un approccio differente alla gestione
della qualità: essi servono a valutare l’appartenenza di un’azienda o di un’organizzazione
produttiva ad una delle configurazioni previste dal modello stesso, allo scopo di trarne
informazioni utili per avviare processi di miglioramento.
Un modello di maturità è un insieme strutturato di elementi, che descrive le
caratteristiche di processi efficaci (in base all’esperienza delle organizzazioni che hanno
predisposto il modello).
Fornisce:
– Un punto di partenza e degli stati “obiettivo”
– L’esperienza della comunità che lo ha prodotto
– Un linguaggio comune ed una visione condivisa
– Un metodo per determinare le priorità
– Un modo per definire il significato di “miglioramento” per l’organizzazione
Può essere utilizzato per confrontare organizzazioni diverse.
Tra i modelli più articolati, applicabili all’industria del software e dei servizi, abbiamo il
Malcolm Bridge National Quality Award (MBA), ed il Capability Maturity Model
(CMM).
non sono certificazioni ma registrazioni (x tutti i modelli di maturità?)...si chiamano
veramente registrazioni?....scrivere la differenza tra una registrazione e una certificazione
1.4.1 I modelli CMM
Gestione delle qualità
Analisi e messa in opera in ambito aziendale del CMMI: - 23 -
sviluppo e gestione dei requisiti.
CMM sta per Capability Maturity Model, ed è un modello di riferimento
costituito da pratiche (practices) consolidate in una disciplina specifica, utilizzato per
stabilire la capacità di una organizzazione o gruppo di operare in quella disciplina.
Esistono vari CMM, che differiscono per:
- Disciplina (software, sistemi, acquisizione, etc.)
- Struttura
- Come viene definita la Maturity (percorso di miglioramento del processo)
- Come viene definita la Capability (istituzionalizzazione)
“Capability Maturity Model®” e CMM® sono utilizzati dal SEI (Software Engineering
Institute) per denotare una classe particolare di modelli di maturità.
Negli anni ’30, W. Stewhart iniziò a lavorare sul miglioramento dei processi con i
suoi principi di controllo statistico della qualità. Questi principi furono poi raffinati da
altre persone, tra cui un certo Humphrey, che li estesero ed iniziarono ad applicarli al
software. Humphrey scrisse un libro, che fornisce una descrizione dei principi di base su
cui sono basati molti dei CMM.
Il SEI ha preso la premessa su cui si fonda la gestione di un processo, “la qualità
di un sistema o prodotto è altamente influenzata dalla qualità del processo utilizzato per
svilupparlo e mantenerlo”, ed ha definito i CMM che realizzano questa premessa, a cui è
riconosciuta un’importanza particolare a livello internazionale.
I CMM si focalizzano sul miglioramento dei processi in un’organizzazione. Essi
contengono gli elementi essenziali che rendono i processi efficaci per una o più
discipline, e descrivono un percorso evolutivo di miglioramento da processi immaturi
fino a processi maturi, efficaci, qualitativamente migliori.
Dal 1991, sono stati sviluppati dei CMM per una miriade di discipline; alcuni dei
più utilizzati includono modelli per l’ingegneria dei sistemi, ingegneria del software,
acquisizione software, gestione della forza-lavoro e sviluppo, ed infine lo sviluppo
integrato di prodotti e processi (IPPD, Integrated Process and Product Development).
Benchè questi modelli siano stati utili per molte organizzazioni, l’uso di modelli
differenti è risultato problematico, a causa di differenti strutture, formati, termini e modi
di misurare la maturità. Inoltre l’uso in contemporanea di modelli diversi causa
confusione, e diventa complessa e costosa l’integrazione di più di un modello in un unico
programma coordinato di miglioramento.
Gestione delle qualità
Analisi e messa in opera in ambito aziendale del CMMI: - 24 -
sviluppo e gestione dei requisiti.
Il progetto di Integrazione dei CMM (CMMI) è nato proprio per risolvere il
problema dell’uso di tanti CMM diversi, ed è partito da tre modelli CMM, scelti per la
loro diffusione nell’ingegneria del software e dei sistemi, e anche per i loro approcci
differenti al miglioramento dei processi all’interno di un’organizzazione. Questi modelli
sono:
Il Capability Maturity Model for Software (SW-CMM) v2.0 draft C
Il Systems Engineering Capability Model (SECM)
L’Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98
Da qui il team del CMMI ha creato un insieme di modelli integrati, che possono essere
adottati sia da coloro che utilizzano correntemente i modelli sorgente, che da coloro che
sono nuovi al concetto di CMM.
Quindi, il CMMI è il risultato dell’evoluzione del SW-CMM, del SECM, e dell’IPD-
CMM.
1.4.2 Il modello CMMI® e la sua evoluzione
Il modello CMMI (Capability Maturity Model Integration) su cui si basa tutto
questo lavoro di tesi e di stage in ambito aziendale è quello denominato “CMMI for
Development”, perché è il successore designato dei tre modelli CMM (Capability
Maturity Model) da cui è scaturito: il Software CMM, l’IPD-CMM e il SECM, che sono
stati ritirati.
Per applicare ad aree di interesse molteplici la struttura ottenuta dall’evoluzione
dei CMM, le best practice vengono raggruppate in “costellazioni”. Una costellazione è
un insieme di componenti del CMMI che sono progettati per soddisfare le necessità di
una specifica area di interesse. Una costellazione può produrre uno o più modelli CMMI
correlati, insieme ai relativi materiali di training ed appraisal (processo di autovalutazone
obiettiva). Recentemente, l’architettura del CMMI è stata migliorata per permettere il
supporto di costellazioni multiple e la condivisione di best practice tra le costellazioni e i
modelli che le compongono. E sono iniziati i lavori per altre due nuove costellazioni: una
per i servizi (“CMMI for Services”) e l’altra per l’acquisizione (”CMMI for
Acquisition”), e la loro uscita è prevista per il 2007. Tutti i modelli CMMI disponibili
Gestione delle qualità
Analisi e messa in opera in ambito aziendale del CMMI: - 25 -
sviluppo e gestione dei requisiti.
prima del 2006 ora sono considerati parte della costellazione del “CMMI for
Development”.
La costellazione del “CMMI for Development” consiste di due modelli: “CMMI
for Development + IPPD” (Integrated Process and Product Development), e “CMMI for
Development” (senza IPPD).
Il “CMMI for Development” è un modello di riferimento che copre le attività di sviluppo
e manutenzione applicate sia ai prodotti che ai servizi. Organizzazioni appartenenti a
molte categorie, compresa l’aerospaziale, bancaria, hardware, software, difesa,
manufatturiera automobilistica, e telecomunicazioni, utilizza il “CMMI for
Development”. Infatti i modelli della costellazione del “CMMI for Development”
contengono pratiche che coprono la gestione del progetto, la gestione del processo,
l’ingegneria di sistema, l’ingegneria dell’hardware, l’ingegneria del software, ed altri
processi di supporto utilizzati per lo sviluppo e la manutenzione.
Il CMMI ha attraversato un esteso processo di revisione: si è partiti dalla versione
0.2, utilizzata per attività pilota, per poi passare rapidamente alla versione 1.0 e 1.02.
La versione 1.1 del CMMI è stata quella di maggior diffusione ed uso, e noi,
insieme al nostro gruppo di lavoro, abbiamo iniziato l’attività di studio e
implementazione del processo di miglioramento aziendale basandoci proprio su questa
versione, in quanto la versione successiva, la 1.2, è uscita alla fine di agosto 2006, ed è
rappresentata dal “CMMI for Development”. Da notare che le revisioni e le edizioni del
CMMI si fondano sul feedback ottenuto dagli utenti e da tutta la comunità CMMI che lo
utilizza.
Con la versione 1.2 nasce il concetto di costellazione; inoltre, rispetto alla
versione 1.1, sono stati fatti i seguenti cambiamenti:
Sono stati eliminati i concetti di pratica avanzata e di caratteristiche
comuni;
Sono stati aggiunti esempi di hardware;
Tutte le definizioni sono state consolidate nel glossario;
Sono state eliminate le aree di processo IPPD, ora incluse nelle altre aree;
E’ stata eliminato il Supplier Sourcing (acquisizione di prodotti e servizi);
Gestione delle qualità
Analisi e messa in opera in ambito aziendale del CMMI: - 26 -
sviluppo e gestione dei requisiti.
Sono state aggiunte delle spiegazioni su come le aree di processo
supportano le Pratiche Generiche.
Figura 2 – Storia dei CMM
1.4.3 Il CMMI: obiettivi e vantaggi
Il CMMI® (Capability Maturity Model® - Integration) è un valido strumento per
la definizione, la valutazione ed il miglioramento continuativo dei processi e delle
pratiche di ingegneria di sistema (SE - System Engineering), di ingegneria del software
(SWE – Software Engineering) e di sviluppo integrato di prodotti e processi (IPPD –
Integrated Process and Product Development). Il CMMI® consiste in un’insieme di best
practice per l’acquisizione, lo sviluppo, l’integrazione e la manutenzione di prodotti e
servizi. Un prodotto può essere rappresentato da un cellulare, un’automobile, un
pacchetto software, un aeroplano, etc., mentre un servizio da un corso di formazione per
v1.02 (2000)
CMM for Software
v1.1 (1993)
Systems Engineering
CMM v1.1 (1995)
INCOSE SECAM
(1996)
Software CMM
v2, draft C (1997)
EIA 731 SECM
(1998)
Integrated Product
Development CMM
(1997)
CMM for Services
v1.2 (2007)
CMM for Acquisition
v1.2 (2007)
v1.1 (2002)
CMM for
Development
v1.2 (2006)
STORIA DEI CMM
Gestione delle qualità
Analisi e messa in opera in ambito aziendale del CMMI: - 27 -
sviluppo e gestione dei requisiti.
utenti finali, dal supporto tecnico on-demand, dal tutoring sui servizi internet di trading
online, etc.
Il progetto di sviluppo del CMMI® ha visto coinvolte, a livello internazionale, numerose
aziende, organizzazioni ed esperti del settore provenienti dal mondo industriale, dei
servizi e della ricerca. Il progetto è stato diretto dal SEI (Software Engineering Institute,
www.sei.cmu.edu). Il SEI è un istituto federale di ricerca e sviluppo della Carnegie
Mellon University (Pittsburgh, USA). Nato nel 1984, il SEI è sponsorizzato dal DoD (US
Department of Defense) attraverso il OUSD – AT&L (Office of the Under Secretary of
Defence for Acquisition, Technology, and Logistics).
Le relazioni tra lo standard ISO 9001:2000 ed il CMMI® sono oggetto di una
serie di studi ed implementazioni che sottolineano la convergenza e la sinergia dei due
approcci e la possibilità di utilizzare CMMI® come driver per sostenere
l’implementazione della normativa ISO 9001:2000, in particolare il miglioramento
continuativo come richiesto dallo standard ISO 9004.
Il CMMI inoltre:
- E’ coerente con l’approccio Total Quality Management (TQM) perché stimola le
Aziende al miglioramento continuo dei processi;
- Identifica punti di forza e di debolezza dei processi e misura l’efficacia delle
azioni correttive;
- Supporta la valutazione degli investimenti necessari per il miglioramento dei
processi;
- Assiste il conseguimento ed il mantenimento delle certificazioni ISO attraverso
il controllo continuo dei processi;
- Individua 5 livelli di maturity di categorie di processi, e 6 livelli di capability nei
singoli processi.
Il CMMI è nato con lo scopo di realizzare degli obiettivi ben precisi, e cioè:
Aiutare le aziende a definire i propri obiettivi in termini di:
- Tempi
- Costi
- Qualità
Aumentare la prevedibilità nel raggiungimento degli obiettivi
Gestione delle qualità
Analisi e messa in opera in ambito aziendale del CMMI: - 28 -
sviluppo e gestione dei requisiti.
Aumentare la qualità dei prodotti, mediante la riduzione del numero dei difetti
residui
Ridurre tempi e costi dei progetti:
- Diminuendo la necessità di ricorrere alla ri-lavorazione
- Aumentando la produttività dei processi
Gestire e migliorare i prodotti/servizi delle Aziende fornendo a tal fine le linee
guida per l’integrazione dei processi correlati
Identificare stadi evolutivi nel percorso di miglioramento utilizzabili per fornire
uno standard di benchmark tra Aziende.
Sono stati effettuati svariati studi nell’arco degli ultimi dieci anni, per analizzare
dettagliatamente i vantaggi che l’adozione del CMMI da parte di molte aziende ha
comportato. L’ultimo studio disponibile (Performance Results of CMMI-Based Process
Improvement) è stato pubblicato dal SEI (Software Enginnering Institute) ad agosto 2006,
ed è quello a cui faremo riferimento (www.sei.cmu.edu/cmmi/results.html). Esso
presenta l’evidenza quantitativa dei risultati ottenuti da 35 organizzazioni che hanno
deciso di adottare un sistema di miglioramento dei processi basato sul CMMI. Queste
organizzazioni hanno applicato il CMMI a varie discipline dell’ingegneria, tra cui
l’ingegneria del software e l’ingegneria dei sistemi, e infatti i risultati presentati
provengono da industrie appartenenti a settori differenti (telecomunicazioni, finanza,
produzione, difesa). Tutte le organizzazioni a cui ci si riferisce nel report attribuiscono
esplicitamente i loro progressi all’adozione del CMMI. Tra di esse troviamo: Accenture,
General Motors, IBM Application Management Services, JPMorgan, Lockheed Martin
Corporation, Motorola Global Software Group, Raytheon Corporation, Reuters, The
Boeing Company, ed altre.
I risultati di performance sono catalogati e riassunti utilizzando sei parametri: costi, tempi
(schedule), produttività, qualità, soddisfazione del cliente, e ROI (Return On Investment).
Queste categorie includono una grande varietà di misure, ognuna di esse selezionata dalle
organizzazioni che hanno partecipato allo studio, per rilevare e dimostrare i
miglioramenti ottenuti in aree di importanza strategica per i propri specifici obiettivi di
business.
La categoria dei costi comprende misure effettuate sulle variazioni nei costi dei
prodotti finali o intermedi, sulle variazioni nei costi dei processi impiegati per la
Gestione delle qualità
Analisi e messa in opera in ambito aziendale del CMMI: - 29 -
sviluppo e gestione dei requisiti.
produzione, e anche un aumento nella predicibilità dei costi sostenuti, con altre misure di
variazione. Sono state rilevate delle riduzioni nei costi della qualità, costi di rilavorazone,
costi fissi, ed un aumento nell’accuracy di stima del budget.
Per quanto riguarda i tempi (schedule), vengono riportati i miglioramenti nella
previsione dello schedule, nell’accuracy delle stime, e le riduzioni dei tempi necessari a
svolgere il lavoro, dei giorni di scostamento dal piano, e del numero di giorni di ritardo.
La categoria della produttività comprende varie misure basate sulla quantità di
lavoro effettuato in un fissato periodo di tempo, come per esempio il numero di linee di
codice per ora di lavoro, e numero di release all’anno.
Il miglioramento nella qualità del prodotto è misurato frequentemente mediante
le diminuzioni nel numero di difetti. Ancora una volta, le misure specifiche variano
molto, secondo gli obiettivi di business e altre necessità di rilevazione delle
organizzazioni prese in considerazione in questo studio.
La soddisfazione del cliente comprende in genere i cambiamenti basati sulle
rilevazioni dei clienti stessi. Alcune organizzazioni raccolgono , analizzano ed utilizzano
regolarmente misure quantitative sulla soddisfazione del cliente, ma ad oggi sono
disponibili ancora pochi risultati che possano essere espressi come variazione nel tempo.
Il ROI (Return On Investment) può essere espresso in molti modi, e i risultati a
cui si fa riferimento in questa sede sono riportati in forma di rapporto costi-benefici nel
tempo; come per tutte le altre categorie, i costi ed i benefici a cui ci si riferisce variano a
seconda del tipo di organizzazione che ha fornito i dati.
Tutti i risultati sono riassunti dalla seguente tabella, e sono espressi in termini di
cambiamenti su intervalli di tempo variabili:
Categoria di
Performance
Miglioramento
medio
Numero di
Data Points
Miglioramento
minimo
Miglioramento
massimo
COSTI 34% 29 3% 87%
TEMPI (Schedule) 50% 22 2% 95%
PRODUTTIVITA’ 61% 20 11% 329%
QUALITA’ 48% 34 2% 132%
SODDISFAZIONE
DEL CLIENTE
14% 7 -4% 55%
ROI (Return on
Investment)
4.0 : 1 22 1.7 : 1 27.7 : 1
Gestione delle qualità
Analisi e messa in opera in ambito aziendale del CMMI: - 30 -
sviluppo e gestione dei requisiti.
Tabella 1: Riassunto dei risultati di performance del CMMI.
Questi risultati forniscono un’ampia e valida prova della validità del CMMI come
modello base del miglioramento dei processi, anche se essi non rappresentano una
garanzia di successo. Va sottolineato che sono stati rilevati dei miglioramenti in tutte le
sei categorie di performance, e che in genere un’evoluzione positiva per un parametro
costituisce un fattore di miglioramenti degli altri parametri.
La seguente figura mostra la variazione della produttività e della qualità del
software, ottenuta nell’arco di 11 anni dalla Lockheed Martin mediante l’applicazione del
modello CMMI come strumento di miglioramento dei processi aziendali: il risultato è un
aumento notevole della produttività e una diminuzione del tasso di errore.
Figura 3: Performance di produttività e di qualità del software per la Lockheed Martin.
TASSO DI ERRORE
TASSO DI
PRODUTTIVITA’
Il Capability Maturity Model® Integration
Analisi e messa in opera in ambito aziendale del CMMI: - 31 -
sviluppo e gestione dei requisiti.
2. IL CAPABILITY MATURITY MODEL® INTEGRATION
Il CMMI (Capability Maturity Model® Integration) è un modello che fornisce uno
strumento per creare un punto di integrazione trascendente dalle discipline. Come già detto nel
paragrafo Gestione Della Qualità, il CMMI focalizza l’attenzione sul concetto di processo, in
quanto la qualità di un prodotto è determinata principalmente dalla qualità dei processi di
sviluppo, produzione e manutenzione.
Possiamo analizzare nel dettaglio le parole che compongono l’acronimo CMMI:
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.
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. Rappresenta una valutazione del livello di padronanza e controllo del
processo da parte dell'Azienda, ivi inclusa la capacità della stessa di migliorarlo,
ottimizzarlo o comunque modificarlo in risposta a necessità che si presentano.
Model: insieme di descrizioni di processi da adattare alle diverse realtà aziendali,
quindi fornisce modelli che aiutino le aziende nello sviluppo dei propri servizi e
prodotti.
Integration: una struttura predisposta all’integrazione di più discipline, quindi
fornisce un modello integrato rispetto a quelli precedenti (CMM).
2.1 I componenti del modello
Di seguito viene riportata la struttura generale del modello CMMI, illustrandone le
relazioni tra i vari componenti:
Il Capability Maturity Model® Integration
Analisi e messa in opera in ambito aziendale del CMMI: - 32 -
sviluppo e gestione dei requisiti.
Figura 1 - Struttura generale del modello CMMI
Nei successivi sottoparagrafi si analizzeranno in dettaglio i vari componenti del modello
2.1.1 Le aree di processo
L’elemento più importante del modello è l’area di processo, che è definita come un
gruppo di procedure o di attività eseguite collettivamente per il raggiungimento di una serie di
obiettivi predefiniti: ogni area di processo ha degli obiettivi (Goal) che devono essere soddisfatti.
Gli obiettivi delle aree di processo si suddividono in obiettivi specifici ed in obiettivi
generici: per raggiungere tali obiettivi devono essere svolte delle attività, di cui alcune relative
agli obiettivi specifici (pratiche specifiche), altre relative agli obiettivi generici (pratiche
generiche).
Le pratiche generiche in particolare sono un indicatore del livello di istituzionalizzazione
del processo e sono associate ai livelli di capability (vedere paragrafo 2.2).
Il grado di istituzionalizzazione di un processo corrisponde al livello di controllo che
l’organizzazione è in grado di attuare sul processo stesso: individuale, oppure derivante da
standard progettuali o dell’organizzazione, o analizzato statisticamente, etc.
Le pratiche specifiche invece riguardano le attività che devono essere implementate per
una data area di processo e sono specifiche del dominio dell’area di processo.
Il Capability Maturity Model® Integration
Analisi e messa in opera in ambito aziendale del CMMI: - 33 -
sviluppo e gestione dei requisiti.
Di seguito vengono riportate le 22 aree di processo in ordine alfabetico:
Causal Analysis and Resolution (CAR)
Configuration Management (CM)
Decision Analysis and Resolution (DAR)
Integrated Project Management +IPPD (IPM+IPPD)
Measurement and Analysis (MA)
Organizational Innovation and Deployment (OID)
Organizational Process Definition +IPPD (OPD+IPPD)
Organizational Process Focus (OPF)
Organizational Process Performance (OPP)
Organizational Training (OT)
Product Integration (PI)
Project Monitoring and Control (PMC)
Project Planning (PP)
Process and Product Quality Assurance (PPQA)
Quantitative Project Management (QPM)
Requirements Development (RD)
Requirements Management (REQM)
Risk Management (RSKM)
Supplier Agreement Management (SAM)
Technical Solution (TS)
Validation (VAL)
Verification (VER)
Le aree di processo possono essere raggruppate in quattro categorie: Process
Management, Project Management, Engineering e Support.
Process Management
La categoria Process Management contiene le aree di processo riguardanti le attività
inerenti il progetto che hanno lo scopo di definire, pianificare, sviluppare, implementare,
monitorare, controllare, misurare e migliorare i processi.
Il Capability Maturity Model® Integration
Analisi e messa in opera in ambito aziendale del CMMI: - 34 -
sviluppo e gestione dei requisiti.
Le aree di processo della categoria Process Management sono le seguenti:
Categoria Area di Processo Descrizione
Process
Management
Organizational
Process Focus (OPF)
Identificazione, pianificazione, coordinamento e
implementazione del miglioramento.
Organizational
Process Definition
+IPPD (OPD+IPPD)
Sviluppo e mantenimento del set di standard
aziendali di processo e di prodotto.
Organizational
Training (OT)
Identificazione delle necessità di formazione e di
sviluppo/rilascio della formazione.
Organizational
Process Performance
(OPP)
Determinazione degli obiettivi quantitativi per la
qualità e per le performance dei vari processi
implementati dagli obiettivi di business.
Organizational
Innovation and
Deployment (OID)
Selezione ed implementazione di miglioramenti
incrementali ed innovativi, per generare benefici,
gestendo l’inversione in modo quantitativo.
Figura 2 - Aree di processo della categoria Process Management
Project Management
La categoria Project Management contiene le aree di processo riguardanti le attività di
gestione del progetto che hanno lo scopo di pianificare, monitorare e controllare il progetto.
Le aree di processo della categoria Project Management sono quelle della tabella seguente.
Il Capability Maturity Model® Integration
Analisi e messa in opera in ambito aziendale del CMMI: - 35 -
sviluppo e gestione dei requisiti.
Categoria Area di Processo Descrizione
Project
Management
Project Planning
(PP)
Definizione e mantenimento di un piano di progetto,
coinvolgendo gli stakeholder adeguati, ed ottenendo
il commitment per le attività da svolgere.
Project Monitoring
and Control (PMC)
Controllo del progresso rispetto al piano, prendendo
dove necessario azioni correttive e preventive.
Supplier Agreement
Management
(SAM)
Selezione e gestione efficace dei sub-fornitori
definendo un contratto tra le parti che consenta una
pianificazione ed un monitoraggio delle attività e
delle performance del sub-fornitore. Revisioni e test
di accettazione svolti d’accordo ai requisiti
contrattuali.
Integrated Project
Management
+IPPD
(IPM+IPPD)
Definizione e selezione di un processo per ogni
singolo progetto che sia adattato (tailored) dallo
standard dell’organizzazione (vedere Organizational
Process Definition +IPPD). Tale processo, definito
specificatamente per un progetto, garantisce una
visione integrata per quei gruppi di progetti con forte
connotazione di integrazione tra le varie discipline.
Risk Management
(RSKM)
Approccio continuativo alla gestione dei rischi
associati al progetto attraverso una identificazione dei
parametri e delle tassonomie di rischio.
Quantitative Project
Management
(QPM)
Applicazione di tecniche quantitative e statistiche per
gestire la performance e la qualità di prodotto
Figura 3 - Aree di processo della categoria Project Management
Engineering
La categoria Engineering contiene le aree di processo riguardanti le attività di sviluppo e
manutenzione che sono distribuite in discipline tecniche.
Il Capability Maturity Model® Integration
Analisi e messa in opera in ambito aziendale del CMMI: - 36 -
sviluppo e gestione dei requisiti.
Le aree di processo dell’Engineering sono applicate allo sviluppo di qualsiasi prodotto o
servizio nella fase di sviluppo (per esempio prodotti software e hardware, servizi, processi).
Inoltre le aree di processo dell’Engineering forniscono il fondamento tecnico dell’IPPD che è
basato su un approccio con sistemi tecnici robusti, comprendente lo sviluppo nel contesto delle
fasi della vita del prodotto. Le aree di processo della categoria Engineering sono le seguenti:
Categoria Area di Processo Descrizione
Engineering
Requirements
Development (RD)
Identificazione delle necessità del cliente e
traduzione in requisiti di prodotto con una soluzione
concettuale di alto livello per ciascuna disciplina
coinvolta ed evoluzione di una architettura funzionale
preliminare.
Requirements
Management
(REQM)
Gestione dei requisiti con un costante allineamento ai
piani di progetto attraverso una efficace gestione dei
cambi e rintracciabilità dei requisiti dal cliente sino al
prodotto finale.
Technical Solution
(TS)
Sviluppo dei componenti e dati tecnici associati per
la successiva integrazione attraverso la valutazione di
soluzioni alternative (vedere Decision Analysis and
Resolution).
Product Integration
(PI)
Implementazione della migliore strategia per
l’integrazione dei componenti.
Verification (VER) Controllo della conformità con i requisiti specificati
per ciascun prodotto intermedio selezionato.
Validation (VAL)
Controllo della validità del prodotto, dei prodotti
intermedi e dei processi rispetto alla necessità del
cliente.
Figura 4 - Aree di processo della categoria Engineering
Il Capability Maturity Model® Integration
Analisi e messa in opera in ambito aziendale del CMMI: - 37 -
sviluppo e gestione dei requisiti.
Support
La categoria Support contiene le aree di processo riguardanti le attività che supportano lo
sviluppo e la manutenzione del prodotto. Le Aree di processo della categoria Support indirizzano
i processi, usati nel contesto, di eseguire altri processi.
Per esempio l’area di processo Assicurazione Qualità di Processo e di Prodotto (PPQA)
può essere usata con tutte le aree di processo per fornire una valutazione oggettiva dei processi e
dei work product descritti in tutte le aree.
Le aree di processo della categoria Support sono le seguenti:
Categoria Area di Processo Descrizione
Support
Configuration
Management (CM)
Supporto a tutte le aree di processo nel definire e
mantenere l’integrità dei prodotti (prodotti intermedi
acquisiti o sviluppati internamente) e dei tools.
Process and
Product Quality
Assurance (PPQA)
Supporto a tutte le aree di processo per la obiettiva
valutazione dei processi, dei prodotti e dei prodotti
intermedi rispetto agli standard ed alle procedure
applicabili.
Measurement and
Analysis (MA)
Supporto a tutte le aree di processo nel guidare i
progetti e l’organizzazione nell’allineare le necessità
e gli obiettivi di misurazione con l’approccio alla
misurazione, questo al fine di usare i risultati delle
misurazioni per aspetti informativi o prendere
appropriate azioni correttive.
Decision Analysis
and Resolution
(DAR)
Supporto a tutte le aree di processo nello strutturare
un processo di “decision making” per garantire che le
possibili alternative siano confrontabili e per
garantire la più adeguata selezionata.
Causal Analysis
and Resolution
(CAR)
Analisi progettuale delle cause comuni di variazione
inerenti ai processi al fine di rimuoverle e definire la
base conoscitiva per migliorare continuativamente gli
standard processuali dell’organizzazione.
Figura 5 - Aree di processo della categoria Support
Il Capability Maturity Model® Integration
Analisi e messa in opera in ambito aziendale del CMMI: - 38 -
sviluppo e gestione dei requisiti.
Nei seguenti sottoparagrafi si analizzeranno più in dettaglio i vari componenti di un’area
di processo.
2.1.2 Obiettivi generici
Gli obiettivi generici sono chiamati “generici” poiché lo stesso obiettivo deve essere
applicato a tutte le aree di processo. Un obiettivo generico descrive le caratteristiche che devono
essere presenti per istituzionalizzare i processi che implementeranno un’area di processo. Un
obiettivo generico è un componente del modello che è richiesto ed usato nelle valutazioni per
determinare se un’area di processo viene soddisfatta.
2.1.3 Pratiche generiche
Le pratiche generiche, come gli obiettivi generici, sono applicate a tutte le aree di
processo. Una pratica generica è la descrizione di un'attività che è ritenuta importante nel
realizzare l'obiettivo generico ad essa associato.
Per esempio, una pratica generica per l'obiettivo generico “Istituzionalizzare un processo
gestito” è “Provvedere adeguatamente alle risorse per l’esecuzione del processo, per lo sviluppo
dei work product (vedere paragrafo 3.2) e per la fornitura dei servizi del processo”.
2.1.4 Obiettivi specifici
Un obiettivo specifico descrive le caratteristiche uniche che devono essere presenti per
soddisfare l’area di processo. Un obiettivo è un componente del modello che è richiesto ed usato
nelle valutazioni per determinare se un’area di processo viene soddisfatta.
Per esempio, un obiettivo specifico dell’area di processo Gestione della Configurazione
(Configuration Management) è “Stabilire e mantenere l’integrità delle baseline”.
2.1.5 Pratiche specifiche
Una pratica specifica è la descrizione di un’attività che è ritenuta importante nel
realizzare l’obiettivo specifico ad essa associato. Le pratiche specifiche descrivono quindi le
attività che si ritengono indispensabili per il raggiungimento degli obiettivi specifici di un’area di
processo.
Il Capability Maturity Model® Integration
Analisi e messa in opera in ambito aziendale del CMMI: - 39 -
sviluppo e gestione dei requisiti.
Per esempio, una pratica specifica dell’area di processo Monitoraggio e Controllo del
Progetto (Project Monitoring and Control) è “Monitorare i Parametri della Pianificazione del
Progetto”.
2.1.6 Typical Work Product
I Typical Work Product suddividono l’output di una pratica specifica in una lista di
risultati mirati da ottenere. Quest’ultimi sono denominati typical work product perché spesso ci
sono altri work product che sono adatti ed efficaci per la pratica specifica, ma che non sono
elencati. Per esempio, un typical work product per la pratica specifica “Monitorare i Parametri
della Pianificazione del Progetto” nell’area di processo Monitoraggio e Controllo del Progetto è
“Registrazione di deviazioni significative rispetto al piano”.
2.1.7 Sottopratiche
Una sottopratica è una descrizione dettagliata che fornisce le linee guida per
l'interpretazione e per l’implementazione della pratica specifica o generica. Le sottopratiche
possono essere espresse come delle norme da seguire, ma attualmente hanno solo lo scopo di
fornire le idee che possono essere utili per migliorare il processo. Per esempio, un sottopratica
per la pratica specifica “Effettuare Azioni Correttive” nell’area di processo Monitoraggio e
Controllo del progetto è “Determinare e documentare le azioni necessarie e appropriate per
indirizzarsi verso i problemi identificati”.
2.2 I livelli di capability
Nel modello CMMI si usano i livelli per descrivere un percorso di evoluzione
raccomandato per un’organizzazione che voglia migliorare i processi che usa per sviluppare e
mantenere i propri prodotti e servizi.
Il CMMI supporta due percorsi di miglioramento, uno per incrementare i processi
corrispondenti ad una determinata area di processo (o aree di processo) scelta
dall’organizzazione, l’altro è per migliorare un insieme di processi rivolgendosi via via ad aree di
processo successive.
Il Capability Maturity Model® Integration
Analisi e messa in opera in ambito aziendale del CMMI: - 40 -
sviluppo e gestione dei requisiti.
Questi due percorsi, che corrispondono alle due rappresentazioni possibili di questo
modello (che vedremo successivamente in dettaglio nel paragrafo 2.4), sono associati ai due tipi
di livelli possibili. In entrambi i casi il concetto di livello è lo stesso.
Il CMMI fornisce per ciascuna area di processo dei livelli di evoluzione chiamati Livelli
di Capability.
Un livello di capability (Capability Level - CL) consiste in un obiettivo generico e nelle
sue relative pratiche generiche, che possono migliorare i processi dell’organizzazione associati
all’area considerata. Un livello di capability è quindi un insieme di pratiche che descrivono
l’evoluzione graduale delle attività dell’area di processo.
Ciascun livello serve da fondamento per il livello successivo di miglioramento del processo,
pertanto i livelli sono incrementali: il livello più alto include i connotati di quelli più in basso.
Ciascuna area prevede 6 livelli di capability (da 0 a 5) che vengono conseguiti mettendo
in atto attività via via più evolute:
0. Incomplete
1. Performed
2. Managed
3. Defined
4. Quantitatively Managed
5. Optimizing
Ogni processo è valutato secondo il proprio capability level. Un’organizzazione,
probabilmente, avrà aree di processo diverse stimate a differenti livelli di capability. Il risultato
di questa stima può essere riferito con il nome di Capability Profile, come si vede nella figura
seguente.
Il Capability Maturity Model® Integration
Analisi e messa in opera in ambito aziendale del CMMI: - 41 -
sviluppo e gestione dei requisiti.
0
1
2
3
4
5
Area 1 Area 2 Area 3 Area 4
Aree di processo
Liv
elli d
i ca
pab
ilit
y
Figura 6 - Capability Profile
Livello 0: Incomplete
Un processo è incompleto quando non è stato eseguito oppure è stato eseguito solo
parzialmente. Uno o più obiettivi specifici dell’area di processo non sono stati soddisfatti, e non
esistono obiettivi generici per questo livello in quanto non c’è ragione di istituzionalizzare un
processo parzialmente eseguito.
Livello 1: Performed
Perché un’area di processo sia al 1° livello di capability bisogna mettere in pratica le
attività di base richieste per iniziare a lavorare su quella determinata area.
Un processo eseguito è tale quando soddisfa gli obiettivi specifici dell’area di processo.
Questo livello supporta e permette le attività necessarie per produrre i prodotti di lavoro (work
product).
Benché il processo eseguito abbia per risultato dei miglioramenti importanti, questi
potrebbero essere persi nel tempo se non vengono istituzionalizzati. L’istituzionalizzazione
(ovvero la soddisfazione delle pratiche generiche dei livelli di capability dal 2 al 5) aiuta ad
assicurare che i miglioramenti siano mantenuti.
Il Capability Maturity Model® Integration
Analisi e messa in opera in ambito aziendale del CMMI: - 42 -
sviluppo e gestione dei requisiti.
Livello 2: Managed
Un processo gestito è un processo eseguito che ha le infrastrutture di base per essere
supportato. E’ organizzato ed eseguito in accordo ad alcune regole; impiega persone competenti
che abbiano adeguate conoscenze per produrre dei risultati controllati; coinvolge gli stakeholder
più importanti (ovvero i portatori di interessi del progetto); è monitorato, controllato e
revisionato.
Questo livello aiuta ad assicurare che le pratiche esistenti siano mantenute nel tempo.
Livello 3: Defined
Un processo definito è un processo gestito che è stato adattato in accordo con le linee
guida di tailoring dei processi standard dell’organizzazione. Contribuisce ai work product, alle
misure, ed ad altre informazioni di miglioramento.
La differenza principale tra il livello 2 ed il livello 3 è il campo di applicazione degli
standard, le descrizioni del processo e le procedure. Nel livello 2 questi punti possono essere un
po’ diversi in ciascuna istanza specifica del processo. Nel livello 3, invece, queste caratteristiche
sono più rilevanti e vengono tailorizzate dall’insieme dei processi standard dell’azienda per
adattarle ad un particolare progetto od unità organizzativa.
Un’altra differenza è che al livello 3 i processi sono tipicamente descritti più
rigorosamente rispetto al livello 2. Il processo definito infatti afferma chiaramente lo scopo, gli
input, i criteri di entrata, le attività, i ruoli, le misure, gli step di verifica, gli output ed i criteri di
uscita. Il livello 3 quindi gestisce i processi in maniera preventiva usando una comprensione
delle relazioni delle attività di processo, misure dettagliate, suoi work product e suoi servizi.
Livello 4: Quantitatively Managed
In questo caso il processo è un processo definito che è controllato usando tecniche
quantitative o statistiche.
Gli obiettivi quantitativi per la qualità ed il processo sono stabiliti ed usati come criteri di
gestione dei processi stessi. La performance del processo e della qualità è intesa in termini
statistici e viene gestita attraverso tutta la vita del processo.
Livello 5: Optimizing
In questo caso si ha un livello che è quello del livello di capability precedente che è stato
però migliorato sulla base di una comprensione delle più comuni cause di variazione del
Il Capability Maturity Model® Integration
Analisi e messa in opera in ambito aziendale del CMMI: - 43 -
sviluppo e gestione dei requisiti.
processo. Il punto focale a questo livello è un miglioramento continuo del range di esecuzione
del processo attraverso miglioramenti innovativi ed incrementali.
In aggiunta, il fatto che i livelli di capability dal 2 al 5 utilizzino gli stessi termini degli
obiettivi generici dal 2 al 5 è intenzionale, perché ognuno di questi obiettivi, con le relative
pratiche, riflette il significato del livello di capability in termini di obiettivi e pratiche che si
possono implementare.
2.3 I livelli di maturity
I livelli di maturity (Maturity Level - ML) consistono in relative pratiche specifiche e
generiche per un predefinito insieme di aree di processo, che miglioreranno la rappresentazione
totale dell’azienda. Il livello di maturity dell’organizzazione fornisce una strada per prevedere
una rappresentazione di una data disciplina o insieme di discipline.
Ciascun livello matura un importante sottoinsieme di processi preparandolo a muoversi
per il livello successivo. I maturity level sono misurati dal raggiungimento di obiettivi generici e
specifici associati a ciascun predefinito insieme di aree di processo.
Le aree di processo possono anche essere raggruppate nei 5 livelli di maturity, che
vengono conseguiti portando sottoinsiemi crescenti di aree di processo allo stesso livello di
capability.
In questo modo le aziende vengono guidate lungo un percorso ottimale di crescita della
capability, che rivolge l’attenzione dapprima ai processi di management, poi a quelli di
ingegneria, fino a quelli di controllo statistico della progettazione e di miglioramento continuo
dei processi.
Un livello di maturity è una tappa ben definita lungo il percorso evolutivo della maturity
dell’azienda.
I 5 livelli utilizzati per descrivere la strada consigliata per una organizzazione che voglia
migliorare i processi di sviluppo e manutenzione di prodotti e servizi, sono:
1. Initial
2. Managed
3. Defined
4. Quantitatively Managed
Il Capability Maturity Model® Integration
Analisi e messa in opera in ambito aziendale del CMMI: - 44 -
sviluppo e gestione dei requisiti.
5. Optimizing
Da notare che i capability level e i maturity level usano gli stessi termini per definire i
livelli dal 2 al 5, questo perché i due livelli sono complementari. Quelli di maturity sono usati per
caratterizzare il miglioramento dell’organizzazione relativo ad un insieme di aree di processo,
quelli di capability caratterizzano il miglioramento organizzativo relativo ad una singola area di
processo.
Livello 1: Initial
Rappresenta processi con risultati non prevedibili. I processi di produzione sono instabili
e disorganizzati; implicitamente definiti di volta in volta da chi li realizza; il flusso delle attività
è caotico.
Il successo in questo caso è affidato solo alle competenze delle persone che lavorano
nell’azienda e non all’uso comprovato di processi. A questo livello anche se si producono
prodotti e servizi che funzionano, spesso si superano i budget e non si raggiungono pienamente
gli scopi preposti.
Livello 2: Managed
A questo livello i progetti devono assicurare che i processi siano pianificati e gestiti in
accordo a delle regole stabilite. I progetti usano persone competenti che hanno una conoscenza
adeguata per produrre output controllati; coinvolgono gli stakeholder più importanti; sono
monitorati, controllati e revisionati.
Questo livello aiuta ad assicurare che le pratiche siano mantenute nel tempo. I progetti
saranno rappresentati e gestiti in accordo ai piani documentati ed agli impegni stabiliti con gli
stakeholder e revisionati se necessario.
Livello 3: Defined
A questo livello i processi sono ben caratterizzati e compresi, e sono descritti in standard,
procedure, tool e metodi. L’insieme di processi standard, che sono la base del livello di maturity
3, sono stabiliti e migliorati nel tempo.
I progetti stabiliscono i loro processi definiti tailorizzando l’insieme dei processi standard
dell’organizzazione, in accordo alle linea guida del tailoring.
Il Capability Maturity Model® Integration
Analisi e messa in opera in ambito aziendale del CMMI: - 45 -
sviluppo e gestione dei requisiti.
La differenza principale tra il livello 2 ed il livello 3 è il campo di applicazione degli
standard, le descrizioni del processo e le procedure. Nel livello 2 questi punti possono essere un
po’ diversi in ciascuna istanza specifica del processo. Nel livello 3, invece, queste caratteristiche
sono più rilevanti e vengono tailorizzate dall’insieme dei processi standard dell’azienda per
adattarle ad un particolare progetto od unità organizzativa.
Un’altra differenza è che al livello 3 i processi sono tipicamente descritti più
rigorosamente rispetto al livello 2. Il processo definito afferma chiaramente lo scopo, gli input, i
criteri di entrata, le attività, i ruoli, le misure, gli step di verifica, gli output ed i criteri di uscita. Il
livello 3 quindi gestisce i processi in maniera preventiva usando una comprensione delle
relazioni delle attività di processo, misure dettagliate, suoi work product e suoi servizi.
A questo livello l’organizzazione deve inoltre maturare le aree di processo del livello 2.
Livello 4: Quantitatively Managed
In questo caso l’organizzazione ed i progetti stabiliscono gli obiettivi quantitativi per la
rappresentazione della qualità e dei processi e li usano come criteri di gestione. Gli obiettivi sono
basati sulle necessità del cliente, degli utenti, dell’organizzazione e dell’implementazioni del
processo. La rappresentazione del processo e della qualità è intesa nei termini statistici ed è
gestita attraverso la vita dei processi.
La differenza maggiore tra il livello 3 ed il 4 sta nella capacità di prevedere l’esecuzione
dei processi. Al livello 4 l’esecuzione dei processi è controllata attraverso tecniche statistiche e
quantitative ed è prevedibile quantitativamente. Al livello 3, invece, i processi sono solamente
prevedibili qualitativamente.
Livello 5 Optimizing
A questo livello l’azienda migliora continuamente i suoi processi, basati su una
comprensione quantitativa delle più comuni cause di variazione del processo. Questo maturity
level si focalizza su un continuo miglioramento dell’esecuzione del processo attraverso processi
innovativi e miglioramenti tecnologici.
La differenza maggiore tra il livello 4 ed il 5 è il tipo di variazione del processo indicata.
Al livello 4 l’azienda è impegnata a tenere sotto controllo le cause straordinarie di variazione del
processo e a fornire una previsione statistica dei risultati. Al livello 5, invece, l’azienda si occupa
di tenere sotto controllo le cause più comuni di variazione del processo, per migliorarne
l’esecuzione e per raggiungere gli obiettivi di miglioramento.
Il Capability Maturity Model® Integration
Analisi e messa in opera in ambito aziendale del CMMI: - 46 -
sviluppo e gestione dei requisiti.
2.4 Le due rappresentazioni
Ci sono due approcci differenti al processo di miglioramento. Uno focalizzato
sull'Organizzazione, come entità univoca, ed in grado di fornire una road map di passi successivi
rivolti a migliorare la capacità aziendale di capire e controllare il processo. Questo approccio sta
alla base della rappresentazione scalare. L'altro approccio possibile, la rappresentazione
continua, si focalizza sul processo singolo, lasciando all'Organizzazione la possibilità di definire
su quali processi applicare il modello.
L'utilizzo dello standard CMMI ci pone davanti ad una scelta: utilizzare la
rappresentazione continua o scalare.
2.4.1 La rappresentazione scalare
La rappresentazione scalare (staged representation) utilizza i maturity level e fornisce
una road map predefinita stabilita sulla base di un comprovato raggruppamento e ordinamento di
processi. Il termine staged deriva dal modo con cui il modello descrive questa road map, ovvero
come una serie di fasi (stage) che sono appunto i maturity level. Ognuno di questi livelli contiene
un set di aree di processo che indicano dove focalizzarsi per migliorare il processo aziendale.
Ogni area di processo è descritta in termini di pratiche che contribuiscono a raggiungere gli
obiettivi. Le pratiche descrivono l'infrastruttura e le attività che concorrono all'effettiva
implementazione ed istituzionalizzazione delle aree di processo. I progressi sono misurati in
raggiungimento degli obiettivi di ogni area di processo presenti in un particolare maturity level.
Il Capability Maturity Model® Integration
Analisi e messa in opera in ambito aziendale del CMMI: - 47 -
sviluppo e gestione dei requisiti.
Figura 7 - Struttura della rappresentazione scalare
La figura seguente mostra come le aree di processo sono usate nella rappresentazione
scalare, ovvero raggruppate per maturity level.
Figura 8 - Aree di processo nella rappresentazione scalare
All'interno della Tabella seguente sono presentate le aree di processo con il relativo
maturity level.
= Aree di processo selezionate per raggiungere il livello di maturità 3.
Maturity Level 5
Maturity Level 4
Maturity Level 2
Maturity Level 3
REQM PP PMC
SAM MA PPQA
CM
Il Capability Maturity Model® Integration
Analisi e messa in opera in ambito aziendale del CMMI: - 48 -
sviluppo e gestione dei requisiti.
Nome Acronimo Maturity
Level
Configuration Management CM 2
Measurement and Analysis MA 2
Process and Product Quality Assurance PPQA 2
Project Monitoring and Control PMC 2
Project Planning PP 2
Requirements Management REQM 2
Supplier Agreement Management SAM 2
Decision Analysis and Resolution DAR 3
Integrated Project Management +IPPD IPM +IPPD 3
Organizational Process Definition +IPPD OPD +IPPD 3
Organizational Process Focus OPF 3
Organizational Training OT 3
Product Integration PI 3
Requirements Development RD 3
Risk Management RSKM 3
Technical Solution TS 3
Validation VAL 3
Verification VER 3
Organizational Process Performance OPP 4
Quantitative Project Management QPM 4
Causal Analysis and Resolution CAR 5
Organizational Innovation and Deployment OID 5
Figura 9 - Aree di processo per maturity level
2.4.2 La rappresentazione continua
La rappresentazione continua utilizza i capability level e non fornisce una direzione
obbligatoria nella definizione delle modalità con cui affrontare il processo.
Come la rappresentazione scalare, la rappresentazione continua è formata da aree di
processo che contengono delle pratiche che, al contrario della rappresentazione scalare, sono
organizzate in modo da sostenere lo sviluppo di una singola area di processo.
Le pratiche generiche sono raggruppate in capability level. Ogni area di processo è
istituzionalizzata implementando le sue pratiche generiche.
Il Capability Maturity Model® Integration
Analisi e messa in opera in ambito aziendale del CMMI: - 49 -
sviluppo e gestione dei requisiti.
I capability level, quindi, si applicano al raggiungimento del miglioramento del processo
nelle singole aree, e questa rappresentazione si occupa appunto di selezionare una particolare
area di processo per migliorarla e raggiungerne il capability level desiderato.
Figura 10 - Struttura della rappresentazione continua
Il Capability Maturity Model® Integration
Analisi e messa in opera in ambito aziendale del CMMI: - 50 -
sviluppo e gestione dei requisiti.
La figura seguente mostra come le aree di processo sono usate nella rappresentazione
continua.
0
1
2
3
4
5
Area 1 Area 2 Area 3 Area 4
Aree di processo
Liv
elli
di
cap
ab
ilit
y
Figura 11 - Aree di processo nella rappresentazione continua
2.4.3 Differenze tra le due rappresentazioni
La scelta tra le due rappresentazioni è libera, ma è interesse dell’azienda riuscire a capire
quale delle due rappresentazioni conviene maggiormente adottare.
La Tabella seguente riassume le differenze tra la rappresentazione continua e la
rappresentazione scalare.
Il Capability Maturity Model® Integration
Analisi e messa in opera in ambito aziendale del CMMI: - 51 -
sviluppo e gestione dei requisiti.
Rappresentazione Continua Rappresentazione Scalare
L’azienda seleziona le aree di processo e i livelli di capability basati sui propri obiettivi di miglioramento del processo.
L’azienda seleziona le aree di processo basate sui maturity level.
I progessi sono misurati usando i capability level, che:
Misurano
l’istituzionalizzazione
(maturity) di un
particolare processo
nell’azienda.
Vanno da 0 a 5.
I progressi sono misurati usando i maturity level, che:
Misurano
l’istituzionalizzazione
(maturity) di un insieme
di processi nell’azienda.
Vanno da 1 a 5.
I profili dei capability level sono usati per raggiungere e tracciare l’esecuzione del miglioramento dei processi.
I maturity level sono usati per raggiungere e tracciare l’esecuzione del miglioramento dei processi.
L’Equivalent Staging (equivalente scalare) permette ad un’organizzazione di utilizzare l’approccio continuo al miglioramento del processo, per derivare un livello di maturity come parte di un appraisal (autovalutazione).
Non c’è necessità di un meccanismo di equivalenza per tornare all’approccio continuo.
Figura 12 - Comparazione tra rappresentazione continua e scalare
Dopo avere visto, per ogni singola rappresentazione, come sono usate le aree di processo,
possiamo illustrare anche come sono usate le pratiche generiche (Generic Practice - GP) e gli
obiettivi generici (Generic Goal - GG).
Come dimostra la figura seguente, tutti i GG e le GP sono usate nella rappresentazione
continua, ed il capability level che si vuole raggiungere per il miglioramento determinerà quali
GG e GP saranno applicati all’area di processo selezionata. Nella rappresentazione scalare,
invece, come si evince sempre dalla figura, sono usati solo i GG 2 e 3, infatti sono evidenziati
solo questi ultimi e le loro relative GP.
Il Capability Maturity Model® Integration
Analisi e messa in opera in ambito aziendale del CMMI: - 52 -
sviluppo e gestione dei requisiti.
Figura 13 - Pratiche Generiche ed Obiettivi Generici
I GG 4 e 5 e le pratiche relative non sono usati perché non tutti i processi raggiungeranno
lo stato di processo definito. Questo perché soltanto alcuni processi e sottoprocessi diverranno
―Quantitatively Managed‖ e ―Optimizing‖, ovvero quelli individuati dalle aree di processo ai
livelli 4 e 5 di maturity.
Ci sono tre fattori che influenzano la decisione di adottare una rappresentazione piuttosto
che l’altra, e sono: business, cultura e legacy (eredità).
Per il primo fattore (business) si può dire che in un’azienda in cui si ha una conoscenza
matura dei propri obiettivi di business, è probabile che vi sia un tracciamento forte tra processi
aziendali e relativi obiettivi di commercio, in questo caso l’azienda potrebbe scegliere la
rappresentazione continua. Mentre se l’azienda decide di migliorare i propri processi attraverso
l’intera organizzazione, potrebbe servire la rappresentazione scalare, in quanto la aiuterà a
selezionare i processi critici per metterli a fuoco e migliorarli.
GP 1.1 GP 2.1
GP 2.2
GP 2.3
GP 3.1
GP 3.2
GP 2.4
GP 2.5
GP 2.6
GP 2.7
GP 2.8
GP 2.9
GP 2.10
GP 4.1
GP 4.2
GP 5.1
GP 5.2
GG 1 GG 2 GG 3 GG 4 GG 5
GP usate nella rappresentazione scalare
Il Capability Maturity Model® Integration
Analisi e messa in opera in ambito aziendale del CMMI: - 53 -
sviluppo e gestione dei requisiti.
Per quanto riguarda il fattore della cultura aziendale, questa si riferisce al fatto che se
un’azienda ha poca esperienza nel miglioramento dei processi, potrebbe adottare la
rappresentazione scalare, in quanto le fornirebbe il consiglio utile supplementare sull’ordine in
cui i cambiamenti dovrebbero accadere. Di conseguenza l’inverso.
Infine, se un'organizzazione ha esperienza di un altro modello che ha una
rappresentazione scalare, quindi parliamo del fattore legacy, può essere saggio continuare con
questa rappresentazione nell’uso del modello CMMI, in particolare se ha investito le risorse ed i
processi. Lo stesso vale per la rappresentazione continua.
In ogni caso, a prescindere dai tre fattori, la scelta è totalmente libera, anche perchè le due
rappresentazioni sono destinate ad offrire essenzialmente i risultati equivalenti. Di conseguenza,
un'Azienda può trovare utilità in entrambe le rappresentazioni e definire spesso un programma di
miglioramento che usi i principi sia della rappresentazione scalare che continua.
2.5 Quadro conclusivo per la registrazione aziendale
Legando tutto il discorso sui livelli, possiamo dire che il concetto di “maturity” si
riferisce all’intera Azienda, non alla singola area di processo (per la quale è definito il concetto
di “capability”).
Quindi, a questo punto, possiamo riassumere le condizioni richieste per il raggiungimento
della registrazione di maturity aziendale del modello CMMI:
Per raggiungere il livello di maturity 2, tutte le aree di processo assegnate a quel
maturity level devono raggiungere il livello di capability 2 (entrambe le
rappresentazioni) o superiore (solo rappresentazione continua);
Per raggiungere il livello di maturity 3, tutte le aree di processo assegnate ai
maturity level 2 e 3 devono raggiungere il livello di capability 3 (entrambe le
rappresentazioni) o superiore (solo rappresentazione continua);
Per raggiungere il livello di maturity 4, tutte le aree di processo assegnate ai
maturity level 2, 3 e 4 devono raggiungere il livello di capability 3 (entrambe le
rappresentazioni) o superiore (solo rappresentazione continua);
Il Capability Maturity Model® Integration
Analisi e messa in opera in ambito aziendale del CMMI: - 54 -
sviluppo e gestione dei requisiti.
Per raggiungere il livello di maturity 5, tutte le aree di processo assegnate ai
maturity level 2, 3, 4 e 5 devono raggiungere il livello di capability 3 (entrambe le
rappresentazioni) o superiore (solo rappresentazione continua).
Quindi i capability level 4 e 5 non sono obbligatori per il raggiungimento delle
corrispondenti maturity, però alcune aziende potrebbero voler alzare il proprio capability level di
alcune aree di processo, pur non essendo necessario per il raggiungimento della registrazione di
una determinata maturity. Allora quello che si fa è tracciare per le aziende registrate non solo la
maturity raggiunta, ma anche il capability profile (visto nel paragrafo 2.2), che darà la stima
delle aree di processo che si troveranno a differenti e maggiori livelli di capability.
Questo aspetto del modello CMMI però, riguarda solamente le aziende che usano la
rappresentazione continua, in quanto la rappresentazione scalare richiede degli step obbligatori
che portano ad un determinato livello di maturity e non è quindi possibile in questo caso un
livello intermedio, ovvero registrare aree di processo a livelli di capability diversi da quelli
raggiunti per la registrazione. Inoltre, come detto nel paragrafo 2.4.3, i GG di più alto livello (4 e
5), corrispondenti ai relativi capability level (4 e 5), sono usati solo nella rappresentazione
continua, quindi volendo alzare il capability di alcune aree di processo dopo il 3, non sarebbe
neanche possibile per le aziende che usano la rappresentazione scalare.
La figura seguente mostra una sintesi dei profili raggiungibili (Target Profile) per i
maturity level (ML) dal 2 al 5; ciascuna area annerita nelle colonne del capability level (CL)
rappresenta un profilo che è equivalente al livello di maturity.
Il Capability Maturity Model® Integration
Analisi e messa in opera in ambito aziendale del CMMI: - 55 -
sviluppo e gestione dei requisiti.
Nome Acronimo ML CL1 CL2 CL3 CL4 CL5
Requirements Management REQM 2
Target Profile
2
Project Planning PP 2
Project Monitoring and Control PMC 2
Supplier Agreement Management SAM 2
Measurement and Analysis MA 2
Process and Product Quality
Assurance
PPQA 2
Configuration Management CM 2
Requirements Development RD 3
Technical Solution TS 3
Product Integration PI 3
Verification VER 3
Validation VAL 3 Target
Profile 3
Organizational Process Focus OPF 3
Organizational Process
Definition +IPPD
OPD
+IPPD
3
Organizational Training OT 3
Integrated Project Management
+IPPD
IPM
+IPPD
3
Risk Management RSKM 3
Decision Analysis and Resolution DAR 3
Organizational Process
Performance
OPP 4 Target
Profile 4
Quantitative Project Management QPM 4
Organizational Innovation and
Deployment
OID 5 Target
Profile 5
Causal Analysis and Resolution CAR 5
Figura 14 - Target Profile
L’approccio aziendale al CMMI
Analisi e messa in opera in ambito aziendale del CMMI: - 56 -
sviluppo e gestione dei requisiti.
3. L’APPROCCIO AZIENDALE AL CMMI
3.1 Obiettivi aziendali
La CHORUS S.p.A. è un’azienda che opera nel campo dell’ingegneria del software e si
occupa di “Progettazione, sviluppo, installazione e manutenzione di prodotti software e
prestazione dei relativi servizi professionali”. Opera cioè in un contesto industriale che evolve
continuamente, sia tecnologicamente che strutturalmente, divenendo più flessibile e più
efficiente.
Per l’azienda assume particolare importanza il poter assicurare la qualità dei prodotti e
servizi offerti ai propri clienti, attraverso le certificazioni di qualità della serie ISO 9000. D’altra
parte le certificazioni di qualità non suggeriscono nessuna pratica per il miglioramento dei
processi, ma indicano soltanto una soglia di accettazione o di rifiuto della qualità.
Per competere con successo in questo tipo di mercato si deve puntare ad una dinamicità
crescente, ed assumere un atteggiamento mentale e metodologie di lavoro orientati al
miglioramento continuo. Solo in questo modo si potrà veramente emergere e migliorare il
proprio business.
L’adozione, da parte dell’azienda, di un modello di maturità come il CMMI permette di
apprendere progressivamente le pratiche più progredite dell’ingegneria del processo software.
Questa evoluzione si articola sui cinque livelli di maturità già descritti nel precedente capitolo:
Initial, Managed, Defined, Quantitatively Managed, Optimizing.
Sebbene l’azienda possegga una certificazione di qualità ISO 9001, da molti considerata
equivalente al terzo livello di maturità del CMMI, l’analisi effettuata inizialmente la attesta ad un
livello di maturità sensibilmente inferiore. Questo è un’ulteriore dimostrazione del fatto che le
certificazioni di qualità sono spesso fatti formali e laterali, che non rispecchiano le reali pratiche
aziendali e che entrano solo marginalmente nei processi primari.
La CHORUS S.p.A. si è posta l’obiettivo di raggiungere il terzo livello di maturità
indicato dal modello CMMI entro giugno 2007. Per fare ciò ha sviluppato ed avviato un progetto
di implementazione del modello CMMI che coinvolge l’azienda stessa a tutti i livelli, e si avvale
del mentoring della Business Strategy SaS, che è uno dei due SEI partner presenti in Italia.
L’approccio aziendale al CMMI
Analisi e messa in opera in ambito aziendale del CMMI: - 57 -
sviluppo e gestione dei requisiti.
3.2 Organizzazione del gruppo di lavoro
Il gruppo di lavoro a cui l’azienda ha affidato il progetto di implementazione del CMMI è
stato composto da quattro stagisti e da alcuni tutor aziendali.
Il progetto è stato interamente coordinato e supervisionato dal Responsabile della Qualità
dell’azienda, persona con esperienza trentennale nel campo dell’informatica e dei sistemi per la
qualità (è auditor certificato delle norme ISO 9001, BS 7799 e ISO 12207). Inoltre i tutor che
l’azienda ha messo a disposizione del progetto ricoprono incarichi manageriali e hanno ricevuto
un training qualificato sul modello CMMI, seguendo corsi di formazione del SEI.
Dopo una prima fase di studio del modello, ci siamo trovati di fronte alla scelta della
strada da percorrere per giungere all’implementazione del modello CMMI.
Come precedentemente illustrato, esistono due possibili rappresentazioni del modello
CMMI: la continua e la scalare. La scelta è ricaduta sulla rappresentazione continua poiché
permette la massima flessibilità nella scelta delle Aree di Processo su cui concentrare
l’attenzione dell’azienda, al fine di soddisfare i propri obiettivi di business.
In questa fase del progetto di implementazione è stato così deciso di lavorare per la messa
in opera delle best practice soltanto di alcune Aree di Processo. Per ottenere una registrazione
SEI si dovranno comunque prendere in considerazione tutte quelle Aree di Processo previste dal
livello di maturity che si vuole raggiungere.
Sono state ritenute strategiche le seguenti Aree di Processo: Configuration Management
(CM), Measurement and Analysis (MA), Process and Product Quality Assurance (PPQA),
Project Monitoring and Control (PMC), Project Planning (PP), Requirements Development
(RD), Requirements Management (REQM), Risk Management (RSKM), Technical Solution
(TS), Validation (VAL) e Verification (VER).
Per velocizzare il progetto di implementazione del CMMI, è parso opportuno che ognuno
di noi stagisti si occupasse di alcune Aree di Processo in particolare. È stata così effettuata una
suddivisione per affinità di Aree di Processo, come risulta dalla Figura 3.1,di seguito riportata.
Figura 3.1- Suddivisione per affinità delle Aree di Processo selezionate
Project Planning
Project Monitoring
and Control
Requirements
Development
Requirements
Management
Configuration
Management
Process and Product
Quality Assurance
Technical Solution
Verification
Validation
L’approccio aziendale al CMMI
Analisi e messa in opera in ambito aziendale del CMMI: - 58 -
sviluppo e gestione dei requisiti.
Durante ogni fase del progetto di implementazione del CMMI, ognuno di noi stagisti si è
occupato prevalentemente delle Aree di Processo che gli sono state assegnate.
3.3 Fasi del progetto e della sua messa in opera
Il progetto di implementazione CMMI in CHORUS S.p.A. è stato impostato secondo il
modello IDEALSM
ovvero il ciclo di vita per il miglioramento continuativo sviluppato dal
Software Engineering Institute (SEI).
L’esecuzione ciclica di una serie di attività consente l’implementazione di un programma
di miglioramento. Esse sono:
Initiating – Identificazione degli obiettivi di business dell’azienda e sensibilizzazione
dell’alta direzione sui costi e benefici di un programma di miglioramento;
Diagnosing - Valutazione delle pratiche sulla base del modello di riferimento CMMI;
Establishing – Pianificazione del miglioramento;
Acting – Implementazione delle pratiche di miglioramento, attraverso esperienze
pilota (a livello progetto o area);
Learning – Acquisizione del miglioramento come pratica aziendale e validazione
della sua efficacia dal punto di vista dei risultati economici e degli obiettivi di
business.
Il modello IDEAL (vedi Figura 3.2) non è solo una instanziazione del più famoso ciclo
PDCA (Plan-Do-Check-Act), ma include una filosofia di lavoro, ben evidenziata dalla “L”
finale, ovverosia catturare opportunamente l’esperienza in database (quantitativi e qualitativi).
L’approccio aziendale al CMMI
Analisi e messa in opera in ambito aziendale del CMMI: - 59 -
sviluppo e gestione dei requisiti.
Figura 3.2 – Il modello IDEAL: il ciclo del miglioramento continuativo
Di seguito sono riportate nel dettaglio le attività che riguardano ogni fase del modello
IDEAL.
INITIATING – Fase di avviamento
Dopo aver identificato gli obiettivi di business dell’azienda, il gruppo di lavoro ha
compreso gli effettivi vantaggi che deriveranno dall’implementazione del modello CMMI ed ha
ricevuto il sostegno dell’Alta Direzione nel progetto. Sono state valutate le risorse e stimati i
tempi di realizzazione. In questa fase noi stagisti abbiamo acquisito le nozioni base del modello
CMMI, attraverso lo studio e l’analisi del materiale di training ufficiale del SEI.
DIAGNOSING – Fase di valutazione
Durante questa fase è stato effettuato un assessment (valutazione) di alcuni progetti
aziendali a fronte dei requisiti imposti dalle Aree di Processo selezionate per l’implementazione
del CMMI in azienda.
È stato possibile utilizzare le pratiche e le sottopratiche del modello CMMI per costruire
alcune tabelle che sono state le linee guida per la valutazione dei progetti.
I risultati delle attività di assessment vengono riportati in dettaglio nei capitoli 4, 5 e 6 per
le Aree di Processo da me analizzate.
L’approccio aziendale al CMMI
Analisi e messa in opera in ambito aziendale del CMMI: - 60 -
sviluppo e gestione dei requisiti.
L’analisi dei dati raccolti nell’assessment ha portato ad evidenziare i punti di forza e le
aree di debolezza dell’attuale Sistema Procedurale (ovvero l’insieme delle procedure che
regolano i progetti aziendali), tenendo sempre presente l’obiettivo del raggiungimento del terzo
livello di maturità.
Ognuno di noi stagisti, curando le Aree di Processo assegnategli, ha prodotto una serie di
annotazioni circa le integrazioni e le modifiche da effettuare sul Sistema Procedurale per
l’adozione del modello CMMI.
Queste raccomandazioni sono state utilizzate nella fase successiva per la definizione di
un piano di miglioramento.
ESTABLISHING – Fase di definizione
Il rapporto di valutazione risultante dalla fase precedente ha consentito di definire la
priorità degli interventi, e quindi, di pianificare le azioni di miglioramento.
A seguito di alcune riunioni con il Responsabile della Qualità dell’azienda, si è deciso di
intraprendere la strada della progettazione di un nuovo Sistema Procedurale che prendesse
spunto da quello attuale, ma a cui non rimanesse obbligatoriamente legato. Sono state così
identificate nuove procedure e definiti i loro domini di applicazione.
Le nuove procedure affiancheranno il personale dell’azienda nello svolgimento delle
attività lavorative con l’obiettivo di trasferirvi le conoscenze delle best practice del CMMI e
consolidare l’adozione del modello. Questo tipo di apprendimento è chiamato Training on the
Job; oltre ad essere un efficace metodo di formazione per il personale, che è guidato passo passo
in tutte le attività, è anche utile all’azienda poiché abbatte i costi legati alla formazione del
personale.
La progettazione del nuovo Sistema Procedurale è stata affidata a noi stagisti. Nel piano
delle attività di progettazione sono state previste periodiche revisioni del lavoro da parte del
Responsabile della Qualità.
ACTING – Fase di implementazione
In questa fase è avvenuta la progettazione del nuovo Sistema Procedurale. Sono state
formulate e scritte le nuove procedure aziendali che permetteranno di implementare il terzo
livello di maturità del CMMI. Di sicuro è stata una delle fasi più importanti ed innovative del
progetto.
Ognuno di noi stagisti si è interessato alle attività legate alle Aree di Processo
assegnategli e le procedure risultanti sono riportate nel capitolo 7 di questa tesi.
L’approccio aziendale al CMMI
Analisi e messa in opera in ambito aziendale del CMMI: - 61 -
sviluppo e gestione dei requisiti.
Il nostro stage in azienda si è concluso dopo aver prodotto le nuove procedure. Questo
perché i tempi aziendali per l’adozione di un modello come il CMMI sono relativamente lunghi.
Il progetto di implementazione del CMMI andrà comunque avanti e proseguirà secondo l’iter
stabilito. Inizialmente si sceglieranno alcuni progetti pilota in cui adottare il nuovo Sistema
Procedurale ed, in base alle indicazioni raccolte, si effettueranno eventuali revisioni delle
procedure. Dopo aver effettuato – anche più di una volta – il processo di test e rifinitura, e dopo
la definitiva approvazione da parte dell’Alta Direzione dell’azienda, il nuovo Sistema
Procedurale diventerà applicabile per tutti i progetti aziendali.
LEARNING – Fase di apprendimento
Come già detto in precedenza, il modello CMMI aiuta a valutare e dare il giusto peso a
errori e successi sperimentati nel corso delle fasi precedenti e a, eventualmente, rivedere le scelte
organizzative. In questa fase si farà proprio questo.
3.4 Quadro d’insieme: le relazioni tra le Aree di Processo
Nel quadro d’insieme riportato in Figura 3.3 sono riportate le Aree di Processo
selezionate dall’azienda. Esse sono rappresentate dai cerchi colorati e contraddistinte dal loro
acronimo. Le relazioni che intercorrono tra di loro sono messe in evidenza dalle frecce (entranti,
uscenti o bidirezionali).
L’approccio aziendale al CMMI
Analisi e messa in opera in ambito aziendale del CMMI: - 62 -
sviluppo e gestione dei requisiti.
VALVAL
RSKMRSKM
REQMREQM
PMCPMC
TSTS
PPPP
VERVER
RDRD
MACMPPQA MAMACMCMPPQAPPQA
Figura 3.3 - Le relazioni tra le Aree di Processo
Per ricavare tale quadro d’insieme siamo partiti dal ciclo di vita del prodotto attualmente
adottato in CHORUS S.p.A., perciò le relazioni tra le Aree di Processo sono scaturite da questo
particolare contesto lavorativo.
Nel seguito viene riportata una breve descrizione per ognuna delle Aree di Processo presente in
Figura 3.3.
Sviluppo dei Requisiti
Analisi e messa in opera in ambito aziendale del CMMI: - 63 -
sviluppo e gestione dei requisiti.
4. SVILUPPO DEI REQUISITI
Le aree di processo di cui mi sono occupata nei mesi in azienda sono “Sviluppo dei
Requisiti” e “Gestione dei Requisiti”. In questo capitolo vedremo la prima e nel capitolo
successivo la seconda.
Queste due aree sono molto affini tra loro in quanto trattano entrambe i requisiti, ne
curano quindi due fasi diverse.
4.1 Descrizione
Lo scopo di questa area di processo (Requirements Development - RD) è di produrre ed
analizzare i requisiti del cliente, del prodotto e dei componenti del prodotto. Si parla quindi di
una fase che si trova a monte, ovvero all’inizio del progetto, quando bisogna capire cosa vuole il
cliente e quindi tirarne fuori dei requisiti, ovvero sviluppare quelle specifiche che saranno
utilizzate nel corso del progetto per arrivare alla realizzazione del prodotto e dei componenti del
prodotto.
Quindi questa area di processo descrive tre tipi di requisiti:
del cliente
del prodotto
dei componenti di prodotto
Nel corso del progetto, i requisiti del cliente sono ulteriormente raffinati nei requisiti del
prodotto e dei componenti del prodotto, tramite i requisiti derivati, identificati durante le fasi del
ciclo di vita del prodotto. Le decisioni, le successive azioni correttive e le risposte durante ogni
fase di vita, sono analizzate per vederne l’impatto sui requisiti derivati ed assegnati.
Presi insieme, questi requisiti portano verso i fabbisogni degli stakeholder (ovvero gli
individui che sono attivamente coinvolti nel progetto e la cui soddisfazione influenza il successo
del progetto stesso).
Tutti i progetti di sviluppo hanno i requisiti. Nel caso invece di un progetto focalizzato
sulle attività di manutenzione, i requisiti li troviamo nei cambiamenti al prodotto o ai componenti
Sviluppo dei Requisiti
Analisi e messa in opera in ambito aziendale del CMMI: - 64 -
sviluppo e gestione dei requisiti.
del prodotto che sono appunto basati sui cambiamenti all’implementazione, al disegno o ai
requisiti esistenti.
I cambiamenti, se ce ne sono, possono essere documentati nelle richieste di cambiamento
fatte da parte del cliente o degli utenti, o potrebbero venire fuori sottoforma di nuovi requisiti
direttamente durante il processo di sviluppo.
I requisiti sono la base per il disegno di progetto. Lo sviluppo dei suddetti include le
seguenti attività:
Estrapolazione, analisi, validazione e comunicazione delle esigenze degli
stakeholder; aspettative e vincoli del cliente. Quindi tutto ciò che servirà per
ottenere i requisiti che costituiranno una comprensione di che cosa soddisferà gli
stakeholder.
Raccogliere e coordinare questi bisogni.
Sviluppo dei requisiti del ciclo di vita del prodotto.
Istituzionalizzare i requisiti del cliente.
Istituzionalizzare i requisiti iniziali del prodotto e dei componenti del prodotto in
accordo con il cliente.
Questa area di processo include tre obiettivi specifici. Il primo (“Sviluppare i Requisiti
del Cliente”) definisce appunto lo sviluppo dei requisiti del cliente. Sono definite due pratiche
specifiche, la prima deve esplicitare le necessità degli stakeholder, la seconda deve tradurre in
requisiti tale necessità e definire i vincoli per la verifica e la validazione che saranno fatte
successivamente.
Il secondo (“Sviluppare i Requisiti di Prodotto”) definisce lo sviluppo dei requisiti del
prodotto e dei componenti del prodotto, da usare nel disegno di progetto. Sono stabilite tre
pratiche specifiche:
1. stabilire i requisiti sviluppandoli in specifiche tecniche di progettazione,
determinare eventuali requisiti derivati, mantenere le relazioni tra i requisiti
durante i cambiamenti;
Sviluppo dei Requisiti
Analisi e messa in opera in ambito aziendale del CMMI: - 65 -
sviluppo e gestione dei requisiti.
2. allocare i requisiti alle funzioni ed ai componenti di prodotto, assegnare i vincoli e
documentare le relazioni tra i diversi requisiti;
3. identificare le interfacce sia interne che esterne al prodotto, sviluppare quindi i
requisiti per tali interfacce.
Il terzo obiettivo specifico (“Analizzare e Valicare i Requisiti”) si riferisce appunto
all’analisi ed alla validazione, e si definiscono cinque pratiche specifiche:
1. stabilire concetti operativi e scenari di lavoro;
2. stabilire la funzionalità richiesta dal cliente;
3. analizzare i requisiti;
4. analizzare i requisiti per effettuare un bilanciamento tra fabbisogni e vincoli degli
stakeholder;
5. validare i requisiti per accertare che il prodotto risultante funzionerà come
previsto.
Per quanto riguarda la validazione, questa viene fatta per assicurare che i requisiti
funzionino correttamente e rispettino gli scopi per i quali sono stati sviluppati.
Per quanto riguarda invece l’analisi, questa è usata per capire, definire e selezionare i
requisiti a tutti i livelli di sviluppo. Le analisi includono:
Analisi delle esigenze e dei requisiti per ogni fase del ciclo di vita del prodotto,
compresi i fabbisogni degli stakeholder; l’ambiente operativo ed i fattori che
riflettono sul cliente e sulle aspettative e soddisfazione generali dell’utilizzatore
finale.
Sviluppo di un concetto operativo.
Definizione della funzionalità richiesta (la definizione di funzionalità, anche citata
come “analisi funzionale”, non è la stessa dell'analisi strutturata nello sviluppo del
software. La definizione delle funzioni, dei loro raggruppamenti logici e delle loro
associazione con i requisiti, si riferisce ad una “architettura funzionale”).
Come conseguenza dell'analisi dei requisiti e del concetto operativo (compresa la
funzionalità, il supporto, la manutenzione e l’eliminazione), il concetto di produzione o di
manufacturing produce i requisiti derivati, comprese le considerazione seguenti:
Sviluppo dei Requisiti
Analisi e messa in opera in ambito aziendale del CMMI: - 66 -
sviluppo e gestione dei requisiti.
Vincoli di vario tipo;
Limitazioni tecnologiche;
Costi;
Vincoli di programma e di tempo;
Rischi;
Considerazione implicite ma non dichiarate esplicitamente dal cliente o
dall’utilizzatore finale;
Fattori introdotti dalle considerazioni, regolazioni e leggi di business.
Una gerarchia delle entità logiche (funzioni e sottofunzioni, classi e sottoclassi di oggetti)
è stabilita con la ripetizione del concetto operativo d'evoluzione. I requisiti sono raffinati,
derivati e assegnati a queste entità logiche. I requisiti e le entità logiche sono assegnati ai
prodotti, ai componenti del prodotto, alle persone, o ai processi associati.
La partecipazione degli stakeholder in questa area di processo dà loro la visibilità
dell’evoluzione e correttezza dei requisiti.
4.2 Assessment
L’assessment è stata la prima fase del lavoro in azienda e, come scritto nei paragrafi
precedenti, è stata effettuata tramite tabelle, create da noi stagisti, che sono state compilate
mediante colloqui ed interviste ad alcuni Project Manager.
Ogni tabella rappresenta una pratica specifica dell’area di processo. Nelle righe delle
tabelle sono riportati i typical work products e le sottopratiche della pratica specifica
corrispondente.
Le colonne sono formate dai seguenti campi:
1. Stato: indica semplicemente se la sottopratica è soddisfatta (S), non soddisfatta
(NS) o parzialmente soddisfatta (PS);
2. Evidenza oggettiva: indica, nel caso di esito positivo del primo campo, con che
cosa (soprattutto documenti) si è dato prova dell’effettuazione della sottopratica;
3. Note: questo campo contiene informazioni relative al sistema procedurale (PG sta
per procedura Gestionale) attualmente in uso nell’azienda per soddisfare alle
Sviluppo dei Requisiti
Analisi e messa in opera in ambito aziendale del CMMI: - 67 -
sviluppo e gestione dei requisiti.
sottopratiche; per le procedure sono anche indicati nel dettaglio i paragrafi ed il
relativo livello di completezza.
Tramite le interviste abbiamo provveduto a riempire tutte le tabelle di ogni area di
processo che ci è stata assegnata.
I typical work products sono scritti solo a titolo informativo in quanto il CMMI li
prevede, ma i campi non sono stati riempiti perché in realtà sono solo quelli tipici richiesti ma ve
ne potrebbero essere degli altri, quindi non serviva verificarli ma solo seguirli per comprendere
meglio le sottopratiche. Inolte i typical work products sono automaticamente soddisfatti dal
soddisfacimento delle sottopratiche relative.
Per ogni tabella, in alto sulla sinistra, è stato riportato il progetto di riferimento sul quale
ognuno di noi ha effettuato l’assessment.
Di seguito sono riportate tutte le tabelle prodotte per l’area di processo Sviluppo dei
Requisiti.
Sviluppo dei Requisiti
Analisi e messa in opera in ambito aziendale del CMMI: - 68 -
sviluppo e gestione dei requisiti.
Sta
toE
vid
enza
Og
get
tiv
aN
ote
Su
bp
ract
ices
1.
Att
ivar
e e
svil
up
par
e le
nec
essi
tà d
egli
sta
keh
old
er
usa
ndo
met
od
i p
er e
stra
po
lare
esi
gen
ze,
asp
etta
tiv
e,
vin
coli
ed
in
terf
acce
est
ern
e
PS
Dem
o t
ecn
ich
e, r
evis
ion
i
per
iod
ich
e d
i p
roget
to,
qu
esti
on
ari,
in
terv
iste
e s
cen
ari
op
erat
ivi
ott
enu
ti d
all'u
ten
te
fin
ale,
pro
toti
pi
e m
od
elli
,
solu
zio
ni
con
div
ise
dei
pro
ble
mi
(bra
inst
orm
ing),
dis
trib
uzi
on
e
sist
emat
ica
del
le f
un
zio
ni
del
la
qu
alit
à, i
nd
agin
i d
i m
erca
to,
estr
azio
ne
da
fon
ti q
ual
i
do
cum
enti
, st
and
ard
o s
pec
ific
he,
oss
erv
azio
ne
di
pro
do
tti,
am
bie
nti
e d
iagra
mm
i d
i w
ork
flo
w
esis
ten
ti,
casi
d'u
so.
Evi
den
za o
gg
etti
va d
i
rife
rim
ento
: M
OM
ed
e-m
ail
per
arri
var
e al
la v
ersi
on
e d
efin
itiv
a
del
lo S
tate
men
t o
f W
ork
(S
OW
)
del
cli
ente
(co
dic
e d
ocu
men
to:
CS
M-U
GS
-ST
D-S
OW
-00
77-1
.1)
ed a
l P
roje
ct M
an
ag
emen
t P
lan
(PM
P)
del
fo
rnit
ore
(co
dic
e
do
cum
ento
: C
SK
-CH
O-P
FS
ET
-
PM
P-0
00
1-2
.0).
PG
.03
A:
par
agra
fo 4
.3 d
a
rev
isio
nar
e.
Pro
get
to d
i ri
feri
men
to c
om
e es
emp
io:
Tel
esp
azio
Co
smo
Sk
y-M
ED
SP
1.1
Esp
lici
tare
le
Nec
essi
tà
Sviluppo dei Requisiti
Analisi e messa in opera in ambito aziendale del CMMI: - 69 -
sviluppo e gestione dei requisiti.
Sta
toE
vid
enza
Og
get
tiv
aN
ote
1.
Req
uis
iti
del
cli
ente
2.
Vin
coli
del
cli
ente
su
lla
con
du
zio
ne
del
la v
erif
ica
3.
Vin
coli
del
cli
ente
su
lla
con
du
zio
ne
del
la
val
idaz
ion
e
1.
Tra
du
rre
le n
eces
sità
deg
li s
tak
eho
lder
, le
asp
etta
tiv
e, i
vin
coli
e l
e in
terf
acce
nel
do
cum
ento
dei
req
uis
iti
PS
2.
Def
inir
e i
vin
coli
per
la
ver
ific
a e
la v
alid
azio
ne
PS
SP
1.2
Sv
ilu
pp
are
i R
equ
isit
i d
el C
lien
te
PG
.04
A:
par
agra
fo 4
.4 d
a
amp
liar
e.
Ty
pic
al
Wo
rk
Pro
du
cts
Su
bp
ract
ices
Pro
get
to d
i ri
feri
men
to c
om
e es
emp
io:
Tel
esp
azio
Co
smo
Sk
y-M
ED
Il d
ocu
men
to c
he
pro
ced
ura
lizz
a
qu
esta
so
tto
pro
ced
ura
è i
l P
roje
ct
Ma
na
gem
ent
Pla
n (
PM
P).
Evi
den
za o
gg
etti
va d
i
rife
rim
ento
: co
dic
e d
ocu
men
to:
CS
K-C
HO
-PF
SE
T-P
MP
-00
01-
2.0
.
Sviluppo dei Requisiti
Analisi e messa in opera in ambito aziendale del CMMI: - 70 -
sviluppo e gestione dei requisiti.
Sta
toE
vid
enza
Og
get
tiv
aN
ote
1.
Req
uis
iti
der
ivat
i (v
. A
rea
di
Pro
cess
o "
So
luzi
on
e
Tec
nic
a")
2.
Req
uis
iti
di
pro
do
tto
3.
Req
uis
iti
di
com
po
nen
ti d
i p
rod
ott
o
1.
Sv
ilu
pp
are
i re
qu
isit
i in
sp
ecif
ich
e te
cnic
he
di
pro
get
tazi
on
e n
eces
sari
e p
er i
l d
iseg
no
di
pro
get
to d
i
pro
do
tto
e d
ei c
om
po
nen
ti d
i p
rod
ott
o
PS
PG
.04
A:
par
agra
fo 4
.4.1
, p
un
to
3 d
a am
pli
are.
2.
Det
erm
inar
e ev
entu
ali
req
uis
iti
der
ivat
i d
alle
dec
isio
ni
di
pro
get
to
PS
PG
.04
A:
rev
isio
nar
e tu
tta
la
pro
ced
ura
.
3.
Sta
bil
ire
e m
ante
ner
e le
rel
azio
ni
tra
req
uis
iti
du
ran
te i
cam
bia
men
tiP
S
La
tab
ella
ch
e m
anti
ene
qu
este
rela
zio
ni
si t
rov
a n
el S
OW
ed
ind
ica
i ca
mb
iam
enti
dei
req
uis
iti
e d
ov
e si
tro
van
o.
Evi
den
za o
gg
etti
va d
i
rife
rim
ento
: D
ocu
men
t C
ha
ng
e
Rec
ord
del
do
cum
ento
SO
W c
on
cod
ice
CS
M-U
GS
-ST
D-S
OW
-
00
77
-1.1
.
PG
.05
B:
rev
isio
nar
e tu
tta
la
pro
ced
ura
.
SP
2.1
Sta
bil
ire
i R
equ
isit
i d
i P
rod
ott
o e
dei
Co
mp
on
enti
del
Pro
do
tto
Ty
pic
al
Wo
rk
Pro
du
cts
Su
bp
ract
ices
Pro
get
to d
i ri
feri
men
to c
om
e es
emp
io:
Tel
esp
azio
Co
smo
Sk
y-M
ED
Fo
rnir
e il
do
cum
ento
dei
Req
uis
iti,
So
ftw
are
Req
uir
emen
ts D
ocu
men
t (S
RD
).
Evi
den
za o
gg
etti
va d
i
rife
rim
ento
: co
dic
e d
ocu
men
to
CS
M-U
GS
-ST
D-S
RD
-05
99
-2.0
.
Sviluppo dei Requisiti
Analisi e messa in opera in ambito aziendale del CMMI: - 71 -
sviluppo e gestione dei requisiti.
Sta
toE
vid
enza
Og
get
tiv
aN
ote
1.
Tab
elle
di
asse
gn
azio
ne
di
req
uis
ito
2.
Ass
egn
azio
ne
pro
vv
iso
ria
di
req
uis
ito
3.
Vin
coli
di
dis
egn
o d
i p
roget
to
4.
Req
uis
iti
der
ivat
i
5.
Rap
po
rti
fra
i re
qu
isit
i d
eriv
ati
1.
Ass
egn
are
i re
qu
isit
i al
le f
un
zio
ni
PS
2.
Ass
egn
are
i re
qu
isit
i ai
co
mp
on
enti
di
pro
do
tto
PS
3.
Ass
egn
are
i v
inco
li d
i p
roget
to a
i co
mp
on
enti
di
pro
do
tto
PS
Qu
esta
par
te è
des
crit
ta d
al
cap
ito
lo C
om
po
nen
t D
esig
n
Ap
pro
ach
ch
e si
tro
va
nel
do
cum
ento
AD
D.
Evi
den
za o
gg
etti
va d
i
rife
rim
ento
: A
rch
itec
tura
l
Des
ign
Do
cum
ent
(AD
D)
cap
ito
lo 2
. C
od
ice
do
cum
ento
:
CS
M-U
GS
-ST
D-A
DD
-00
60
-1.1
.
4.
Do
cum
enta
re l
e re
lazi
on
i tr
a i
div
ersi
req
uis
iti
asse
gn
ati
PS
Ved
i S
ub
pra
ctic
es 1
& 2
(aggiu
ngen
do
per
ò a
lla
mat
rice
di
trac
ciab
ilit
à la
co
lon
na
dei
req
uis
iti
coll
egat
i).
SP
2.2
All
oca
re i
Req
uis
iti
ad
og
ni
Co
mp
on
ente
di
Pro
do
tto
Ty
pic
al
Wo
rk
Pro
du
cts
Su
bp
ract
ices
Pro
get
to d
i ri
feri
men
to c
om
e es
emp
io:
Tel
esp
azio
Co
smo
Sk
y-M
ED
Fo
rnir
e la
mat
rice
di
trac
ciab
ilit
à
che
si t
rov
a n
el d
ocu
men
to A
DD
(do
c. c
he
dic
e co
me
imp
lem
enta
re
i re
q.)
.
Evi
den
za o
gg
etti
va d
i
rife
rim
ento
: A
rch
itec
tura
l
Des
ign
Do
cum
ent
(AD
D)
cap
ito
lo 6
. C
od
ice
do
cum
ento
:
CS
M-U
GS
-ST
D-A
DD
-00
60
-1.1
.
PG
.04
A:
par
agra
fo 4
.4.1
da
amp
liar
e.
Sviluppo dei Requisiti
Analisi e messa in opera in ambito aziendale del CMMI: - 72 -
sviluppo e gestione dei requisiti.
Sta
toE
vid
enza
Og
get
tiv
aN
ote
Ty
pic
al
Wo
rk
Pro
du
cts
1.
Req
uis
iti
di
Inte
rfac
cia
1.
Iden
tifi
care
le
inte
rfac
ce,
sia
este
rne
che
inte
rne
al
pro
do
tto
(i.
e. t
ra l
e p
arti
zio
ni
o g
li o
gget
ti f
un
zio
nal
i)P
S
2.
Sv
ilu
pp
are
i re
qu
isit
i p
er l
e in
terf
acce
id
enti
fica
teP
S
Su
bp
ract
ices
Pro
get
to d
i ri
feri
men
to c
om
e es
emp
io:
Tel
esp
azio
Co
smo
Sk
y-M
ED
Fo
rnir
e i
do
cum
enti
dei
Req
uis
iti
(AD
D &
SR
S),
in
par
tico
lare
la
par
te E
xte
rnal
In
terf
aces
Des
crip
tor
del
l'AD
D.
Evi
den
za o
gg
etti
va d
i
rife
rim
ento
: A
rch
itec
tura
l
Des
ign
Do
cum
ent
(AD
D)
pa
rag
rafo
4.2
(co
dic
e
do
cum
ento
: C
SM
-UG
S-S
TD
-
AD
D-0
06
0-1
.1);
SR
S (
So
ftw
are
Req
uir
emen
t
Sp
ecif
ica
tio
n)
pa
rag
rafo
3.1
(co
dic
e d
ocu
men
to:
E0
00
XM
R0
-
01
SR
SA
07
).
SP
2.3
Id
enti
fica
re i
Req
uis
iti
di
Inte
rfa
ccia
PG
.04
A:
par
agra
fo 4
.3 d
a
amp
liar
e.
Sviluppo dei Requisiti
Analisi e messa in opera in ambito aziendale del CMMI: - 73 -
sviluppo e gestione dei requisiti.
Sta
toE
vid
en
za
Og
gett
iva
No
te
1.
Co
ncett
i O
pera
tiv
i
2.
Inst
all
azio
ne d
el
pro
do
tto
o d
el
co
mp
on
en
te d
i
pro
do
tto
, m
an
ute
nzio
ne e
co
ncett
i d
i so
stegn
o
3.
Co
ncett
i d
i eli
min
azio
ne (
"dis
po
sal"
)
4.
Casi
d'u
so
5.
Scen
ari
cro
no
logic
i
6.
Nu
ov
i re
qu
isit
i
1.
Sta
bil
ire i
co
ncett
i o
pera
tiv
i e g
li s
cen
ari
ch
e
inclu
do
no
fu
nzio
nali
tà,
pre
stazio
ni,
man
ute
nzio
ne,
sup
po
rto
ed
eli
min
azio
ni,
in
man
iera
ap
pro
pri
ata
PS
Fu
nzio
nali
tà,
pre
stazio
ni
e
man
ute
nzio
ne s
i tr
ov
an
o n
el
Man
uale
Op
era
tiv
o;
sup
po
rto
ed
eli
min
azio
ne s
i tr
ov
an
o n
el
Man
uale
di
Inst
all
azio
ne.
Evid
en
za o
gg
ett
iva
di
rife
rim
ento
: M
an
ua
le O
pera
tiv
o
ca
pit
olo
3 (
co
dic
e d
ocu
men
to:
CS
M-C
HO
-UG
S-A
PP
-MA
N-
01
03
-1.0
).
Ma
nu
ale
di
Inst
all
azio
ne
ca
pit
olo
2.
Co
dic
e d
ocu
men
to:
CS
M-C
HO
-UG
S-P
FS
-IN
S-0
19
5-
1.1
.
2.
Defi
nir
e l
'am
bie
nte
in
cu
i il
pro
do
tto
o i
co
mp
on
en
ti d
i p
rodo
tto
do
vra
nn
o f
un
zio
nare
,
inclu
den
do
lim
iti
e v
inco
li
PS
Ved
ere
qu
ind
i l'am
bie
nte
HW
e
SW
do
ve f
un
zio
nerà
il
pro
do
tto
.
Evid
en
za o
gg
ett
iva
di
rife
rim
ento
: C
on
fig
ura
tio
n
Item
s D
ata
Lis
t ca
pit
olo
3.
Co
dic
e d
ocu
men
to:
CS
M-C
HO
-
UG
S-P
FS
-CD
L-0
23
4-1
.2.
3.
Riv
ed
ere
i c
on
cett
i o
pera
tiv
i e g
li s
cen
ari
per
raff
inare
e s
co
pri
re i
req
uis
iti
PS
Ved
ere
qu
ind
i gli
am
bie
nti
ott
imali
per
i re
qu
isit
i e l
e l
oro
perf
orm
an
ce,
per
po
i ra
ffin
arl
i.
Evid
en
za o
gg
ett
iva
di
rife
rim
ento
: T
ecn
ica
l N
ote
s
(TN
O).
Co
dic
e d
ocu
men
to C
SM
-
CH
O-U
GS
-PF
S-T
NO
-00
50-2
.0.
4.
Sv
ilu
pp
are
un
dett
agli
ato
co
ncett
o o
pera
tiv
o,
co
me
i p
rod
ott
i ed
i c
om
po
nen
ti d
i p
rodo
tto
so
no
sele
zio
nati
, ch
e d
efi
nis
ca l
e i
nte
razio
ni
del
pro
do
tto
,
dell
'ute
nte
fin
ale
, d
ell
'am
bie
nte
, e s
od
dis
fin
o l
e
necess
ità o
pera
tiv
e d
i m
an
ute
nzio
ne,
di
sup
po
rto
e d
i
eli
min
azio
ne
PS
Ved
i S
ub
pra
cti
ce 1
.
Ty
pic
al
Wo
rk
Pro
du
cts
Su
bp
ra
cti
ces
Pro
gett
o d
i ri
feri
mento
co
me e
sem
pio
: T
ele
spazio
Co
smo
Sk
y-M
ED
SP
3.1
Sta
bil
ire i
Co
ncett
i O
pera
tiv
i e g
li S
cen
ari
PG
.04
A:
cap
ito
lo o
para
gra
fo d
a
am
pli
are
o d
a d
efi
nir
e.
.
Sviluppo dei Requisiti
Analisi e messa in opera in ambito aziendale del CMMI: - 74 -
sviluppo e gestione dei requisiti.
Sta
toE
vid
enza
Og
get
tiv
aN
ote
1.
Arc
hit
ettu
ra f
un
zio
nal
e
2.
Dia
gra
mm
i d
i at
tiv
ità
e ca
si d
'uso
3.
An
alis
i o
rien
tata
agli
ogget
ti c
on
ser
viz
i o
met
od
i
iden
tifi
cati
1.
An
aliz
zare
e q
uan
tifi
care
la
fun
zio
nal
ità
rich
iest
a
dal
l'ute
nte
fin
ale
PS
Il d
ocu
men
to c
he
pro
ced
ura
lizz
a
qu
esta
so
tto
pro
ced
ura
è i
l P
MP
.
Evi
den
za o
gg
etti
va d
i
rife
rim
ento
: P
roje
ct
Ma
na
gem
ent
Pla
n (
PM
P)
cap
ito
lo 3
. C
od
ice
do
cum
ento
:
CS
K-C
HO
-PF
SE
T-P
MP
-00
01-
2.0
.
2.
An
aliz
zare
i r
equ
isit
i p
er i
den
tifi
care
le
par
tizi
on
i
logic
he
o f
unzi
on
ali
(so
tto
fun
zio
ni)
PS
3.
Rip
arti
re i
req
uis
iti
in g
rup
pi,
bas
and
osi
su
cri
teri
stab
ilit
i (f
un
zio
nal
ità
sim
ilar
i, p
rest
azio
ni
o c
op
pie
),
per
fac
ilit
are
e fo
cali
zzar
e l'a
nal
isi
dei
req
uis
iti
stes
si
PS
4.
Co
nsi
der
are
l'ord
inam
ento
del
le f
un
zio
ni
tim
e-
crit
ical
, in
izia
lmen
te e
su
cces
siv
amen
te,
du
ran
te l
o
svil
up
po
dei
co
mp
on
enti
di
pro
do
tto
PS
5.
Ass
egn
are
i re
qu
isit
i d
el c
lien
te a
lle
par
tizi
on
i
fun
zio
nal
i, o
gget
ti,
per
son
e, o
ele
men
ti d
i su
pp
ort
o
per
fac
ilit
are
la s
inte
si d
elle
so
luzi
on
i
PS
6.
Ass
egn
are
i re
qu
isit
i fu
nzi
on
ali
e p
rest
azio
nal
i al
le
fun
zio
ni
ed a
lle
sott
ofu
nzi
on
iP
S
SP
3.2
Sta
bil
ire
un
a D
efin
izio
ne
di
Fu
nzi
on
ali
tà R
ich
iest
a
Ty
pic
al
Wo
rk
Pro
du
cts
Su
bp
ract
ices
Pro
get
to d
i ri
feri
men
to c
om
e es
emp
io:
Tel
esp
azio
Co
smo
Sk
y-M
ED
Qu
este
so
tto
pro
ced
ure
so
no
pro
ced
ura
lizz
ate
da
tutt
o i
l
do
cum
ento
AD
D.
Evi
den
za o
gg
etti
va d
i
rife
rim
ento
: A
rch
itec
tura
l
Des
ign
Do
cum
ent
(AD
D).
Co
dic
e d
ocu
men
to:
CS
M-U
GS
-
ST
D-A
DD
-00
60
-1.1
.
Fo
rnir
e q
uin
di
la m
atri
ce d
i
trac
ciab
ilit
à ch
e si
tro
va
nel
do
cum
ento
AD
D.
Evi
den
za o
gg
etti
va d
i
rife
rim
ento
: A
rch
itec
tura
l
Des
ign
Do
cum
ent
(AD
D)
cap
ito
lo 6
. C
od
ice
do
cum
ento
:
CS
M-U
GS
-ST
D-A
DD
-00
60
-1.1
.
PG
.04
A:
cap
ito
lo o
par
agra
fo d
a
amp
liar
e o
da
def
inir
e.
Sviluppo dei Requisiti
Analisi e messa in opera in ambito aziendale del CMMI: - 75 -
sviluppo e gestione dei requisiti.
Sta
toE
vid
en
za
Og
gett
iva
No
te
1.
Rep
ort
dei
dif
ett
i d
ei
req
uis
iti
2.
Pro
po
ste
di
mo
dif
ich
e d
ei
req
uis
iti
per
riso
lvere
i
dif
ett
i
3.
Req
uis
iti
ch
iav
e
4.
Mis
ure
di
pre
sta
zio
ni
tecn
ich
e (
v.
Are
a d
i P
rocesso
"M
isu
razio
ne e
An
ali
si"
)
1.
An
ali
zzare
le e
sig
en
ze d
egli
sta
keh
old
er,
le
asp
ett
ati
ve,
i v
inco
li e
le i
nte
rfacce e
ste
rne p
er
eli
min
are
i c
on
flit
ti e
d o
rgan
izzare
negli
oggett
i
co
rrela
ti
PS
Qu
esta
part
e è
pro
ced
ura
lizzata
dal
do
cu
men
to A
DD
.
Ev
iden
za o
ggett
iva d
i ri
feri
mento
:
Arch
itectu
ra
l D
esig
n D
ocu
men
t
(AD
D)
ca
pit
oli
4-5
. C
od
ice
do
cu
men
to:
CS
M-U
GS
-ST
D-
AD
D-0
06
0-1
.1.
2.
An
ali
zzare
i r
eq
uis
iti
per
dete
rmin
are
se s
od
dis
fan
o
gli
ob
iett
ivi
dei
req
uis
iti
di
liv
ell
o s
up
eri
ore
PS
3.
An
ali
zzare
i r
eq
uis
iti
per
assic
ura
re c
he s
ian
o
co
mp
leti
, fa
ttib
ile,
reali
zzab
ili
e v
eri
ficab
ili
PS
4.
Iden
tifi
care
i r
eq
uis
iti
ch
iav
e,
i q
uali
han
no
un
a
fort
e i
nfl
uen
za s
ul
co
sto
, lo
'sch
ed
ule
', l
a f
un
zio
nali
tà,
il r
isch
io o
le p
resta
zio
ni
PS
Per
iden
tifi
care
i r
eq
uis
iti
ch
iav
e
si
usan
o i
do
cu
men
ti R
MP
&
SO
C.
Evid
en
za
og
gett
iva
di
rif
erim
ento
: S
tate
men
t o
f
Co
mp
lia
nce (
SO
C)
(co
dic
e
do
cu
men
to:
CS
M-C
HO
-UG
S-P
FS
-
SO
C-0
10
5-2
.2);
Ris
k
Ma
na
gem
en
t P
lan
(R
MP
)
(co
dic
e d
ocu
men
to:
CS
K-C
HO
-
PF
SE
T-R
MP
-00
01-1
.0).
5.
Iden
tifi
care
le m
isu
re d
i p
resta
zio
ni
tecn
ich
e,
ch
e
sara
nn
o t
raccia
te d
ura
nte
la f
ase d
i sv
ilu
pp
oP
S
Il d
ocu
men
to c
he p
roced
ura
lizza
qu
esta
so
tto
pro
ced
ura
è i
l P
MP
.
Evid
en
za
og
gett
iva
di
rif
erim
ento
: P
ro
ject
Ma
na
gem
en
t P
lan
(P
MP
).
Co
dic
e d
ocu
men
to:
CS
K-C
HO
-
PF
SE
T-P
MP
-00
01-2
.0.
6.
An
ali
zzare
i c
on
cett
i o
pera
tiv
i e g
li s
cen
ari
per
raff
inare
i f
ab
bis
ogn
i d
el
cli
en
te,
i v
inco
li e
le
inte
rfacce,
e p
er
sco
pri
re i
nu
ov
i re
qu
isit
i
NS
Evid
en
za
og
gett
iva
di
rif
erim
ento
: n
on
tro
vata
per
il
pro
gett
o d
i ri
feri
mento
.
SP
3.3
An
ali
zza
re i
Req
uis
iti
Ty
pic
al
Wo
rk
Pro
du
cts
Su
bp
ra
cti
ces
Pro
gett
o d
i ri
feri
mento
co
me e
sem
pio
: T
ele
sp
azio
Co
sm
o S
ky-M
ED
Il d
ocu
men
to S
OC
pro
ced
ura
lizza
qu
esta
so
tto
pro
ced
ura
. Q
uesto
do
c.
da i
nfo
rmazio
ni
di
co
mp
lian
ce,
e n
on
so
lo,
per
ogn
i
req
.
Evid
en
za
og
gett
iva
di
rif
erim
ento
: S
tate
men
t o
f
Co
mp
lia
nce (
SO
C).
Co
dic
e
do
cu
men
to:
CS
M-C
HO
-UG
S-P
FS
-
SO
C-0
10
5-2
.2.
PG
.04
A:
para
gra
fo 4
.4.1
, p
un
to
3 d
a a
mp
liare
.
Sviluppo dei Requisiti
Analisi e messa in opera in ambito aziendale del CMMI: - 76 -
sviluppo e gestione dei requisiti.
Sta
toE
vid
enza
Og
get
tiv
aN
ote
Ty
pic
al
Wo
rk
Pro
du
cts
1.
Val
uta
zio
ne
dei
ris
chi
rela
tiv
amen
te a
i re
qu
isit
i
1.
Uti
lizz
are
i m
od
elli
pro
va,
le
sim
ula
zio
ni
e i
pro
toti
pi
per
an
aliz
zare
il
bil
anci
amen
to d
ei
fab
bis
ogn
i e
dei
vin
coli
deg
li s
tak
eho
lder
(ad
es.
per
rid
urr
e i
cost
i ed
i r
isch
i)
PS
Qu
esta
pro
ced
ura
la
trov
iam
o n
el
do
cum
ento
del
pia
no
di
ges
tio
ne
del
ris
chio
(R
MP
) e
nel
SE
MP
,
do
cum
ento
per
ges
tire
gli
ap
pro
cci
e le
tec
no
logie
per
sv
ilu
pp
are
il
SW
e p
er c
op
rire
tu
tte
le f
asi
del
cicl
o d
i v
ita
del
SW
.
Evi
den
za o
gg
etti
va d
i
rife
rim
ento
: R
isk
Ma
na
gem
ent
Pla
n (
RM
P)
(co
dic
e d
ocu
men
to:
CS
K-C
HO
-PF
SE
T-R
MP
-00
01-
1.0
); S
oft
wa
re E
ng
inee
rin
g
Ma
na
gem
ent
Pla
n (
SE
MP
)
(co
dic
e d
ocu
men
to:
CS
K-C
HO
-
PF
SE
T-S
EM
P-0
00
1-1
.0).
PG
.04
A:
par
agra
fo 4
.4.1
, p
un
to
3 e
4 d
a am
pli
are.
2.
Eff
ettu
are
un
a v
alu
tazi
on
e d
el r
isch
io s
ui
req
uis
iti
e
sull
'arc
hit
ettu
ra f
un
zio
nal
eP
S
Per
qu
esta
so
tto
pro
ced
ura
ser
ve
il
do
cum
ento
di
Ris
chio
ed
un
do
cum
ento
tec
nic
o.
Evi
den
za o
gg
etti
va d
i
rife
rim
ento
: R
isk
Ma
na
gem
ent
Pla
n (
RM
P)
(co
dic
e d
ocu
men
to:
CS
K-C
HO
-PF
SE
T-R
MP
-00
01-
1.0
); T
ecn
ica
l N
ote
s (T
NO
)
(co
dic
e d
ocu
men
to:
CS
M-C
HO
-
UG
S-P
FS
-TN
O-0
05
0-2
.0).
Inse
rire
nel
la
pro
ced
ura
PG
.04
A u
n
cap
ito
lo s
ul
Ris
k
Man
agem
ent
Pla
n.
3.
Esa
min
are
i co
nce
tti
del
cic
lo d
i v
ita
del
pro
do
tto
per
gli
eff
etti
dei
req
uis
iti
sui
risc
hi
PS
Evi
den
za o
gg
etti
va d
i
rife
rim
ento
: R
isk
Ma
na
gem
ent
Pla
n (
RM
P)
(co
dic
e d
ocu
men
to:
CS
K-C
HO
-PF
SE
T-R
MP
-00
01-
1.0
); P
roje
ct M
an
ag
emen
t P
lan
(PM
P)
(co
dic
e d
ocu
men
to:
CS
K-
CH
O-P
FS
ET
-PM
P-0
00
1-2
.0).
Inse
rire
nel
la
pro
ced
ura
PG
.04
A u
n
cap
ito
lo s
ul
Ris
k
Man
agem
ent
Pla
n e
d
amp
liar
e il
par
agra
fo
4.4
.1.
Su
bp
ract
ices
Pro
get
to d
i ri
feri
men
to c
om
e es
emp
io:
Tel
esp
azio
Co
smo
Sk
y-M
ED
SP
3.4
An
ali
zza
re i
Req
uis
iti
per
Ott
ener
e B
ila
nci
am
ento
Sviluppo dei Requisiti
Analisi e messa in opera in ambito aziendale del CMMI: - 77 -
sviluppo e gestione dei requisiti.
Sta
toE
vid
enza
Og
get
tiv
aN
ote
Ty
pic
al
Wo
rk
Pro
du
cts
1.
An
no
tazi
on
e d
ei m
eto
di
e d
ei r
isu
ltat
i d
i an
alis
i
1.
An
aliz
zare
i r
equ
isit
i p
er d
eter
min
are
il r
isch
io c
he
il p
rodo
tto
ris
ult
ante
no
n f
un
zio
ni
ben
e n
ell'a
mb
ien
te
stab
ilit
o
PS
Per
qu
esta
so
tto
pro
ced
ura
ser
ve
il
do
cum
ento
di
Ris
chio
ed
un
do
cum
ento
tec
nic
o.
Evi
den
za o
gg
etti
va d
i
rife
rim
ento
: R
isk
Ma
na
gem
ent
Pla
n (
RM
P)
(co
dic
e d
ocu
men
to:
CS
K-C
HO
-PF
SE
T-R
MP
-00
01-
1.0
); T
ecn
ica
l N
ote
s (T
NO
)
(co
dic
e d
ocu
men
to:
CS
M-C
HO
-
UG
S-P
FS
-TN
O-0
05
0-2
.0).
PG
.04
A:
par
agra
fo 4
.3 d
a
amp
liar
e.
2.
Esp
lora
re l
'ad
egu
atez
za e
la
com
ple
tezz
a d
ei
req
uis
iti,
co
n l
o s
vil
up
po
di
rap
pre
sen
tazi
on
i d
el
pro
do
tto
(p
roto
tip
i, s
imu
lazi
on
i, m
od
elli
, sc
enar
i ec
c.)
ed o
tten
end
o i
l fe
edb
ack
su
gli
ste
ssi
da
par
te d
ei
Rel
evan
t S
tak
eho
lder
PS
Co
n i
l d
ocu
men
to S
OC
ver
ific
o
l'ad
egu
atez
za e
co
mp
lete
zza
dei
req
uis
iti;
co
n i
l T
NO
ho
la
solu
zio
ne
tecn
ica
dei
ris
ult
ati
ott
enu
ti,
qu
ind
i v
erif
ico
ch
e si
a
tutt
o o
k.
Evi
den
za o
gg
etti
va d
i
rife
rim
ento
: T
ecn
ica
l N
ote
s
(TN
O)
(co
dic
e d
ocu
men
to:
CS
M-
CH
O-U
GS
-PF
S-T
NO
-00
50-2
.0);
Sta
tem
ent
of
Co
mp
lia
nce
(S
OC
)
(co
dic
e d
ocu
men
to:
CS
M-C
HO
-
UG
S-P
FS
-SO
C-0
10
5-2
.2).
3.
Val
uta
re c
om
e il
pro
get
to m
atu
ra n
el c
on
test
o
del
l'am
bie
nte
di
val
idaz
ion
e d
ei r
equ
isit
i p
er
iden
tifi
care
i p
rob
lem
i d
i v
alid
azio
ne
e p
er e
spo
rre
i
bis
ogn
i ed
i r
equ
isit
i d
el c
lien
te n
on
sp
ecif
icat
i
PS
La
sott
op
rati
ca v
ien
e ges
tita
co
n i
l
do
cum
ento
MP
R.
Evi
den
za o
gg
etti
va d
i
rife
rim
ento
: M
on
tly
Pro
gre
ss
Rep
ort
(M
PR
) ca
pit
olo
3.
Co
dic
e d
ocu
men
to:
CS
M-C
HO
-
UG
S-P
FS
-MP
R-0
11
0-1
.0.
Pro
get
to d
i ri
feri
men
to c
om
e es
emp
io:
Tel
esp
azio
Co
smo
Sk
y-M
ED
Su
bp
ract
ices
SP
3.5
Va
lid
are
i R
equ
isit
i
Cap
ito
lo o
par
agra
fo
da
amp
liar
e o
da
inse
rire
nel
la P
G.0
4A
.
Sviluppo dei Requisiti
Analisi e messa in opera in ambito aziendale del CMMI: - 78 -
sviluppo e gestione dei requisiti.
4.3 Analisi dei dati raccolti
L’analisi dei dati raccolti dopo l’assessment è la seconda fase avvenuta in azienda, ed è
stata effettuata alla luce dei dati raccolti durante le interviste fatte per il riempimento delle tabelle
sopra riportate.
Per quanto riguarda l’area di processo Sviluppo dei Requisiti, ci siamo resi conto, con il
Responsabile della Qualità, che il vecchio sistema procedurale dell’azienda non soddisfava a
pieno le sottopratiche del modello CMMI. Infatti le procedure attualmente in uso per lo sviluppo
dei requisiti non focalizzano tutti i punti richiesti dal CMMI.
Le procedure del vecchio sistema procedurale di cui mi hanno dato evidenza i Project
Manager, per questa area di processo, sono:
Procedura “Offerte e riesame del contratto” (PG.03A)
Procedura “Progettazione e realizzazione del software” (PG.04A)
Procedura “Controllo dei documenti e dei dati” (PG.05B)
Queste procedura non analizzano nel dettaglio lo sviluppo dei requisiti ma guidano
l’azienda verso la stesura dei termini per il contratto del progetto, verso la progettazione vera e
propria del prodotto software, e verso il controllo di tutti i dati e documenti raccolti durante il
progetto. Saranno quindi utilizzate per altri aspetti aziendali e solo per alcuni aspetti dello
sviluppo dei requisiti.
A questo punto quello si è pensato di fare è stato, in accordo con il Responsabile della
Qualità, creare una nuova procedura (Procedura CM.07 – Sviluppo e Gestione dei Requisiti) che
si occupasse solamente dello sviluppo e della gestione dei requisiti, motivo per cui questa
procedura riguarderà anche l’altra area di processo di cui mi sono occupata. Quindi ho creato, ex
novo, una procedura che rispettasse punto punto tutte le sottopratiche richieste dal CMMI.
Il fatto che le sottopratiche ed i work product siano parzialmente soddisfatti od esistenti,
come si vede dalle tabelle, non implica che l’area di processo si trovi ad un buon livello di
capability del CMMI, infatti, per questa area si può stimare un livello di capability al livello 0.
Questo perché, come spiegato nel paragrafo 2.2, se le pratiche specifiche non sono del tutto
soddisfatte ci si trova al livello 0 di capability.
La situazione per le 34 pratiche specifiche di questa area di processo è la seguente:
Sviluppo dei Requisiti
Analisi e messa in opera in ambito aziendale del CMMI: - 79 -
sviluppo e gestione dei requisiti.
0%97,06%
2,941%
Soddisfatte
Parzialmente Soddisfatte
Non Soddisfatte
Figura 4 - Stima in % delle Pratiche Specifiche soddisfatte per l’area Sviluppo dei Requisiti
Per quanto riguarda la PG.03A, ci siamo resi conto che, pur non avendo un rapporto uno
ad uno con una determinata area di processo, la procedura utilizza molti dei risultati prodotti
dall’area Sviluppo dei Requisiti, in quanto questa ultima è quella che più affronta l’interazione
con gli stakeholder, sarà quindi, nella fase di implementazione di questa area, redatto il contratto
del progetto. Per questi motivi è stata a me assegnata la stesura della nuova procedura
corrispondente alla PG.03A.
Nel paragrafo 6.4 sarà approfondito il discorso su questa procedura.
Gestione dei Requisiti
Analisi e messa in opera in ambito aziendale del CMMI: - 80 -
sviluppo e gestione dei requisiti.
5. GESTIONE DEI REQUISITI
5.1 Descrizione
Questa area di processo (Requirements Management - REQM) deve controllare i requisiti
dei prodotti e dei componenti del prodotto del progetto, ed identificare eventuali inconsistenze
fra requisiti, piani di progetto e prodotti di lavoro. Controlla la gestione di tutte le specifiche
ricevute o generate dal progetto, comprese sia quelle tecniche che non tecniche. Quindi ci
possiamo trovare in due casi, nel primo può succedere che le specifiche arrivino già del cliente,
in questo caso non occorre sviluppare i requisiti ma serve solo comprenderli con il cliente e
gestirli (si utilizza solo l’area Gestione dei Requisiti). Nel secondo caso, invece, il cliente non
fornisce direttamente i requisiti ma solo le sue necessità ed aspettative, quindi bisogna prima
sviluppare i requisiti e poi in un secondo momento gestirli (si utilizza sia l’area Sviluppo dei
Requisiti che l’area Gestione dei Requisiti).
Allora, come si diceva nelle righe precedenti, questa area di processo gestisce sia requisiti
ricevuti che vengono dal cliente che requisiti sviluppati direttamente dal progetto.
Si definiscono, per l’unico obiettivo specifico (“Gestione dei Requisiti”), cinque pratiche
specifiche:
- ottenere la comprensione dei requisiti con il cliente
- ottenere l’impegno in base ai requisiti
- gestire eventuali cambiamenti
- mantenere la tracciabilità dei requisiti
- identificare le eventuali inconsistenze tra i requisiti ed i lavori del progetto
Nel caso in cui un progetto riceve i requisiti dal cliente, questi sono rivisti insieme dai
cliente e dai fornitori che lavorano al progetto, per risolvere possibili problemi ed impedire
incomprensioni prima che i requisiti siano incorporati nei programmi del progetto.
Una volta raggiunto l'accordo si ottiene l’impegno per il progetto, si controllano i
cambiamenti ai requisiti mentre si evolvono e si identificano tutte le contraddizioni che si
presentano fra i piani, i prodotti di lavoro ed i requisiti.
Gestione dei Requisiti
Analisi e messa in opera in ambito aziendale del CMMI: - 81 -
sviluppo e gestione dei requisiti.
Nel caso in cui, invece, i requisiti non arrivano dal cliente, ma si hanno a disposizione
solo i fabbisogni degli stakeholder, prima della gestione dei requisiti bisogna applicare l’area di
processo Sviluppo dei Requisiti.
Bisogna opportunamente documentare i requisiti, i cambiamenti e le loro spiegazione
razionali e mantenere la tracciabilità bidirezionale fra i requisiti sorgente e tutti i requisiti di
prodotto e componenti di prodotto.
Tutti i progetti di sviluppo hanno i requisiti. Nel caso invece di un progetto focalizzato
sulle attività di manutenzione, i requisiti li troviamo nei cambiamenti al prodotto o ai componenti
del prodotto che sono appunto basati sui cambiamenti all’implementazione, al disegno o ai
requisiti esistenti. I cambiamenti, se ce ne sono, possono essere documentati nelle richieste di
cambiamento fatte da parte del cliente o degli utenti, o potrebbero venire fuori sottoforma di
nuovi requisiti direttamente durante il processo di sviluppo.
5.2 Assessment
Come già spiegato per l’area di processo precedente (paragrafo 4.2), anche in questo caso
sono state prodotte delle tabelle per ogni pratica specifica, che con i Project Manager di alcuni
progetti sono state riempite.
Di seguito sono riportate le tabelle prodotte per l’area di processo Gestione dei Requisiti.
Gestione dei Requisiti
Analisi e messa in opera in ambito aziendale del CMMI: - 82 -
sviluppo e gestione dei requisiti.
Sta
toE
vid
en
za
Og
gett
iva
No
te
1.
Lis
te d
ei
cri
teri
per
dis
tin
gu
ere
i f
orn
ito
ri d
ei
req
uis
iti
ad
att
i
2.
Cri
teri
di
valu
tazio
ne /
accett
azio
ne d
ei
req
uis
iti
3.
Ris
ult
ati
dell
'an
ali
si
in b
ase a
i cri
teri
4.
Insie
me d
i re
qu
isit
i accett
ati
1.
Sta
bil
ire i
cri
teri
per
dis
tin
gu
ere
in
man
iera
ap
pro
pri
ata
le f
on
ti d
i p
rov
en
ien
za d
ei
req
uis
iti
PS
Lis
ta a
ll'in
tern
o d
ell
a P
roced
ura
Gesti
on
ale
PG
4.0
4A
per
gesti
re i
req
uis
iti
in b
ase a
qu
esta
so
tto
pro
ced
ura
, fo
rnir
e q
uin
di
il
Pia
no
di
Qu
ali
tà d
el
Pro
gett
o.
Evid
en
za
og
gett
iva
di
rif
erim
ento
: P
ian
o d
i Q
ua
lità
del
Pro
gett
o (
PQ
P)
rela
tiv
o.
Co
dic
e
do
cu
men
to:
SL
XD
RC
-
PQ
P_
E1
_R
0.
PG
.04
A:
para
gra
fo 4
.2 d
a
am
pli
are
.
2.
Sta
bil
ire d
ei
cri
teri
oggett
ivi
per
la v
alu
tazio
ne e
l'accett
azio
ne d
ei
req
uis
iti,
ch
e s
ian
o a
d e
sem
pio
:
dic
hia
rati
ch
iara
men
te e
co
rrett
am
en
te,
co
mp
leti
,
co
nsis
ten
ti c
on
il
resto
, u
niv
ocam
en
te i
den
tifi
cati
,
imp
lem
en
tab
ili,
veri
ficab
ili
(testa
bil
i),
traccia
bil
i
PS
Lis
ta a
ll'in
tern
o d
ell
a P
roced
ura
Gesti
on
ale
PG
4.0
4A
per
gesti
re i
req
uis
iti
in b
ase a
qu
esta
so
tto
pro
ced
ura
, fo
rnir
e q
uin
di
il
PQ
P.
Evid
en
za
og
gett
iva
di
rif
erim
ento
: P
ian
o d
i Q
ua
lità
del
Pro
gett
o (
PQ
P)
rela
tiv
o.
Co
dic
e
do
cu
men
to:
SL
XD
RC
-
PQ
P_
E1
_R
0.
3.
An
ali
zzare
i r
eq
uis
iti
per
accert
ars
i ch
e i
nco
ntr
ino
i
cri
teri
sta
bil
iti
PS
Ric
hie
ste
di
ch
iari
menti
al
cli
en
te
su
i re
qu
isit
i, q
uin
di
forn
ire
ev
en
tuali
rela
zio
ni
do
cu
men
tati
,
tip
o e
scam
bia
te c
on
il
cli
en
te o
agen
de p
er
gli
in
co
ntr
i
co
n i
l cli
en
te,
ch
e a
ttesti
no
cam
bia
men
ti o
ch
iari
menti
su
i
req
uis
iti.
Evid
en
za
og
gett
iva
di
rif
erim
ento
: e-m
ail
del
06
-12
-05
inv
iata
dall
a S
ele
x c
on
all
egato
il
file
del
do
cu
men
to R
S (
Req
uis
iti
di
Sis
tem
a)
co
n a
llo
cazio
ne C
SC
I
scri
tto
in
man
iera
più
ch
iara
.
4.
Raggiu
ngere
la c
on
div
isio
ne d
ei
req
uis
iti
co
n c
hi
li
forn
isce,
in m
od
o c
he i
part
ecip
an
ti a
l p
rogett
o
po
ssan
o e
ssere
co
inv
olt
i
PS
Inte
rvis
te a
gli
ute
nti
fo
rmali
zzate
att
rav
ers
o l
e r
ela
tiv
e m
inu
te d
i
riu
nio
ne,
qu
ind
i an
ali
zzare
la
do
cu
men
tazio
ne d
efi
nit
iva f
orn
ita
dal
cli
en
te (
Req
uis
iti
di
Sis
tem
a).
Evid
en
za
og
gett
iva
di
rif
erim
ento
: d
ocu
men
to d
ei
Req
uis
iti
di
Sis
tem
a (
RS
) co
n
co
dic
e E
31
5-0
1-0
37
84
RS
.
Cap
ito
lo o
para
gra
fo
da i
nseri
re n
ell
a
PG
.04
A.
SP
1.1
Ott
en
ere l
a C
om
pren
sio
ne d
ei
Req
uis
iti
Ty
pic
al
Wo
rk
Pro
du
cts
Su
bp
ra
cti
ces
Pro
gett
o d
i ri
feri
mento
co
me e
sem
pio
: S
ele
x -
Dis
aste
r R
eco
very
Cap
ito
lo o
para
gra
fo
da a
mp
liare
o d
a
inseri
re n
ell
a P
G.0
4A
.
Gestione dei Requisiti
Analisi e messa in opera in ambito aziendale del CMMI: - 83 -
sviluppo e gestione dei requisiti.
Sta
toE
vid
enza
Og
get
tiv
aN
ote
1.
Val
uta
zio
ne
di
imp
atto
dei
req
uis
iti
2.
Do
cum
enta
zio
ne
del
l'im
peg
no
neg
ozi
ato
per
i
req
uis
iti
nu
ov
i e/
o m
od
ific
ati
1.
Val
uta
re l
'imp
atto
dei
req
uis
iti
(nu
ov
i o
mo
dif
icat
i)
sugli
im
peg
ni
esis
ten
tiP
S
Inco
ntr
i tr
a i
com
po
nen
ti d
el
gru
pp
o d
i p
roget
to,
qu
ind
i
com
un
icaz
ion
i in
tern
e
do
cum
enta
te d
a M
oM
per
val
uta
re
il p
rogra
mm
a d
i la
vo
ro d
ei
par
teci
pat
i al
pro
get
to i
n b
ase
ai
req
uis
iti
(nu
ov
i o
mo
dif
icat
i) e
agli
im
peg
ni
esis
ten
ti.
Evi
den
za o
gg
etti
va d
i
rife
rim
ento
: T
ab
ella
Rie
pil
og
ati
va
Ord
ini.
2.
Neg
ozi
are
e re
gis
trar
e gli
im
peg
ni
PS
Gan
tt c
on
div
iso
da
tutt
i i
par
teci
pat
i al
pro
get
to e
Mo
M c
he
lo d
ocu
men
ti.
Evi
den
za o
gg
etti
va d
i
rife
rim
ento
: P
ian
o d
i S
vil
up
po
Pro
get
to (
PS
P)
man
dat
o a
l
clie
nte
co
n a
lleg
ato
il
Gan
tt.
Ty
pic
al
Wo
rk
Pro
du
cts
Su
bp
ract
ices
Pro
get
to d
i ri
feri
men
to c
om
e es
emp
io:
Sel
ex -
Dis
aste
r R
eco
ver
y
SP
1.2
Ott
ener
e l'
Imp
egn
o i
n b
ase
ai
Req
uis
iti
PG
.04
A e
PG
.05
B:
cap
ito
lo o
par
agra
fo d
a
amp
liar
e o
da
inse
rire
nel
la P
G.0
4A
;
rev
isio
nar
e tu
tta
la
PG
.05
B.
Gestione dei Requisiti
Analisi e messa in opera in ambito aziendale del CMMI: - 84 -
sviluppo e gestione dei requisiti.
Stato
Evid
en
za O
ggettiv
aN
ote
1. S
tatu
s d
ei
requis
iti
2. D
ata
base d
ei
requis
iti
3. D
ata
base d
ell
e d
ecis
ioni
prese i
n m
erit
o a
i requis
iti
1. D
ocum
enta
re i
requis
iti
e l
e m
odif
iche a
d e
ssi
apporta
te e
/o g
enerate
dal
progett
oP
S
Produrre u
n d
ocum
ento
in i
ngle
se
SR
S (
Softw
are R
equir
em
ent
Specif
icati
on), redatt
o c
on i
l
tem
pla
te s
tandard S
ele
x, per a
vere
i requis
iti
più
nel
dett
agli
o.
Fornir
e q
uin
di
e-m
ail
invia
te e
ric
evute
con a
llegate
le v
ersio
ni
draft
fatt
e p
er a
rriv
are a
l
docum
ento
defin
itiv
o.
Evid
enza o
ggett
iva d
i
rif
erim
ento
: e-m
ail
ric
evuta
dall
a
Sele
x i
l gio
rno 0
1-02-06 c
on
all
egato
il
docum
ento
Softw
are
Req
uir
em
en
t S
pecif
icatio
n
(S
RS
) a
cui
son
o s
tate
aggiu
nte
dell
e n
ote
dal
cli
ente
per
mig
liorarlo
.
Codic
e d
ocum
ento
: E
000X
MR
0-
01S
RS
A07.
PG
.04A
e P
G.0
5B
:
paragrafo 4
.4.1
dell
a
PG
.04A
da a
mpli
are;
revis
ionare t
utt
a l
a
PG
.05B
.
2. M
ante
nere u
no s
toric
o d
ell
e m
odif
iche d
ei
requis
iti
con l
a m
oti
vazio
ne d
i ta
li c
am
bia
menti
S
Gio
rnale
di
Config
urazio
ne
(G
DC
) e
Pia
no d
i G
esti
one
Config
urazio
ne (
?).
Evid
enza o
ggett
iva d
i
rif
erim
ento
: docum
ento
del
Pia
no
di
Gestio
ne C
on
fig
urazio
ne
(P
GC
) (
codic
e d
ocum
ento
:
SL
XD
RC
-P
GC
_E
1_R
0);
docum
ento
del
Gio
rn
ale
di
Con
fig
urazio
ne (
GD
C) (
codic
e
docum
ento
: S
LX
DR
C-
GD
C_E
1_R
0).
PG
.08A
:
procedura c
om
ple
ta
(da r
ivedere s
olo
poche c
ose).
3. V
alu
tare l
'im
patt
o d
ell
e m
odif
iche d
ei
requis
iti
dal
punto
di
vis
ta d
ei
rele
vant
sta
kehold
er
PS
Riu
nio
ni
con g
li s
takehold
er
(consegnata
ri)
docum
enta
te d
a
MoM
.
Evid
enza o
ggett
iva d
i
rif
erim
ento
: n
on è
sta
ta
necessaria
per i
l progett
o d
i
rif
erim
ento
, qualo
ra l
o f
osse s
tato
si
sarebbe p
roceduto
a
rip
ianif
icare l
e a
ttiv
ità i
n b
ase
all
'im
patt
o v
alu
tato
.
PG
.05B
:
revis
ionare t
utt
a l
a
procedura.
4. R
endere d
ispo
nib
ili
a t
utt
o i
l progett
o i
dati
sui
requis
iti
e s
ull
e m
odif
iche a
i requis
iti
ste
ssi
S
Gesti
one d
egli
accessi
all
a
docum
enta
zio
ne d
ei
requis
iti,
quin
di
fornir
e i
l P
iano d
i G
esti
one
dell
a C
onfig
urazio
ne (
PG
C) i
n c
ui
si
trovano a
nche g
li a
ccessi
al
CV
S.
Evid
enza o
ggett
iva d
i
rif
erim
ento
: d
ocum
ento
del
Pia
no
di
Gestio
ne C
on
fig
urazio
ne
(P
GC
);
codic
e d
ocum
ento
:
SL
XD
RC
-P
GC
_E
1_R
0.
PG
.08A
:
procedura c
om
ple
ta
(da r
ivedere s
olo
poche c
ose).
Typ
ical
Work
Prod
ucts
Su
bp
ractic
es
Progett
o d
i rif
erim
ento
com
e e
sem
pio
: S
ele
x -
Dis
aste
r R
ecovery
SP
1.3
Gestir
e i
Cam
bia
men
ti
dei
Req
uis
iti
Gestione dei Requisiti
Analisi e messa in opera in ambito aziendale del CMMI: - 85 -
sviluppo e gestione dei requisiti.
Sta
toE
vid
enza
Og
get
tiv
aN
ote
1.
Mat
rice
di
trac
ciab
ilit
à d
ei r
equ
isit
i
2.
Sis
tem
a d
i ri
ntr
acci
abil
ità
dei
req
uis
iti
1.
Man
ten
ere
la t
racc
iab
ilit
à d
ei r
equ
isit
i p
er
assi
cura
re c
he
la f
on
te d
ei r
equ
isit
i d
i li
vel
lo i
nfe
rio
re
(der
ivat
i) s
ia d
ocu
men
tata
PS
Ges
tio
ne
del
la C
on
figu
razi
on
e
del
la d
ocu
men
tazi
on
e d
ei r
equ
isit
i
- A
ggio
rnam
ento
del
Gio
rnal
e d
i
Co
nfi
gu
razi
on
e (G
DC
).
Evi
den
za o
gg
etti
va d
i
rife
rim
ento
: m
atr
ice
di
tra
ccia
bil
ità
(tr
acci
abil
ità
tra
req
uis
iti
di
sist
ema
e re
qu
isit
i
soft
war
e) c
he
si t
rov
a n
el
do
cum
ento
So
ftw
are
Req
uir
emen
t S
pec
ific
ati
on
(SR
S)
pa
rag
rafo
3.1
2.
Co
dic
e d
ocu
men
to:
E0
00
XM
R0
-
01
SR
SA
07
.
2.
Man
ten
ere
la t
racc
iab
ilit
à d
ei r
equ
isit
i d
a u
n
req
uis
ito
ai
suo
i d
eriv
ati
ed a
lle
sue
allo
cazi
on
i d
i
fun
zio
ni,
in
terf
acce
, o
gget
ti,
per
son
e, p
roce
ssi
e
"wo
rk p
rod
uct
"
PS
Do
cum
enta
zio
ne
dei
req
uis
iti
po
sta
sott
o C
on
tro
llo
di
Co
nfi
gu
razi
on
e.
Evi
den
za o
gg
etti
va d
i
rife
rim
ento
: d
ocu
men
ti d
ei
Req
uis
iti
di
Sis
tem
a (
RS
) e
do
cum
ento
So
ftw
are
Req
uir
emen
t S
pec
ific
ati
on
(SR
S).
Co
dic
e d
ocu
men
to:
E0
00
XM
R0
-
01
SR
SA
07
.
3.
Gen
erar
e la
mat
rice
di
trac
ciab
ilit
à d
ei r
equ
isit
iP
SV
edi
Su
bp
ract
ice
1.
SP
1.4
Ma
nte
ner
e u
na
Tra
ccia
bil
ità
Bid
irez
ion
ale
dei
Req
uis
iti
Ty
pic
al
Wo
rk
Pro
du
cts
Su
bp
ract
ices
Pro
get
to d
i ri
feri
men
to c
om
e es
emp
io:
Sel
ex -
Dis
aste
r R
eco
ver
y
PG
.04
A:
par
agra
fo 4
.4.1
da
amp
liar
e.
Gestione dei Requisiti
Analisi e messa in opera in ambito aziendale del CMMI: - 86 -
sviluppo e gestione dei requisiti.
Sta
toE
vid
enza
Og
get
tiv
aN
ote
1.
Do
cum
enta
zio
ne
del
le i
nco
nsi
sten
ze i
ncl
ud
end
o
sorg
enti
, co
nd
izio
ni
e m
oti
vaz
ion
i
2.
Insi
eme
del
le a
zio
ni
corr
etti
ve
1.
Rev
isio
nar
e i
pia
ni
di
pro
get
to,
le a
ttiv
ità
e i
"wo
rk
pro
du
ct"
per
ver
ific
are
la c
on
sist
enza
co
n i
req
uis
iti
e
le m
od
ific
he
fatt
e a
loro
PS
2.
Iden
tifi
care
la
fon
te d
elle
in
con
sist
enze
e l
a
mo
tiv
azio
ne
PS
3.
Iden
tifi
care
le
mo
dif
ich
e ch
e è
nec
essa
rio
eff
ettu
are
sui
pia
ni
e su
i "w
ork
pro
du
ct"
a se
gu
ito
dei
cam
bia
men
ti a
lle
bas
elin
e d
ei r
equ
isit
i
PS
4.
Att
uar
e le
nec
essa
ri a
zio
ni
corr
etti
ve
NS
Evi
den
za o
gg
etti
va d
i
rife
rim
ento
: n
on
è s
tata
tro
vat
a
per
il
pro
get
to d
i ri
feri
men
to.
SP
1.5
Id
enti
fica
re l
e In
con
sist
enze
tra
Pro
ject
Work
e R
equ
isit
i
Pro
get
to d
i ri
feri
men
to c
om
e es
emp
io:
Sel
ex -
Dis
aste
r R
eco
ver
y
Ty
pic
al
Wo
rk
Pro
du
cts
Su
bp
ract
ices
Rev
isio
nar
e p
er c
apir
e se
qual
cosa
è fa
tta
mal
e, q
uin
di
corr
egger
e
l'err
ore
e d
ocu
men
tarl
o n
el
Ver
bal
e d
i R
iesa
me.
Evi
den
za o
gg
etti
va d
i
rife
rim
ento
: V
erb
ale
di
Rie
sam
e
con
co
dic
e S
LX
DR
C-
VR
S_
29
_0
3_
06
.
PG
.05
B:
rev
isio
nar
e tu
tta
la
pro
ced
ura
.
PG
.04
A e
PG
.05
B:
cap
ito
lo o
par
agra
fo d
a
amp
liar
e o
da
inse
rire
nel
la P
G.0
4A
;
rev
isio
nar
e tu
tta
la
PG
.05
B.
Gestione dei Requisiti
Analisi e messa in opera in ambito aziendale del CMMI: - 87 -
sviluppo e gestione dei requisiti.
5.3 Analisi dei dati raccolti
Come per l’area Sviluppo dei Requisiti, anche per l’area Gestione dei Requisiti ci siamo
resi conto, con il Responsabile della Qualità, che il vecchio sistema procedurale dell’azienda non
soddisfava a pieno le sottopratiche del modello CMMI. Infatti le procedure attualmente in uso
per la gestione dei requisiti non focalizzano tutti i punti richiesti dal CMMI.
Le procedure del vecchio sistema procedurale di cui mi hanno dato evidenza i Project
Manager per questa area di processo sono:
Procedura “Progettazione e realizzazione del software” (PG.04A)
Procedura “Controllo dei documenti e dei dati” (PG.05A)
Procedura “Gestione della configurazione” (PG.08A)
Queste procedura non analizzano nel dettaglio la gestione dei requisiti ma guidano
l’azienda verso la progettazione vera e propria del prodotto software, verso il controllo di tutti i
dati e documenti raccolti durante il progetto, e verso la gestione della configurazione. Saranno
quindi utilizzate per altri aspetti aziendali o solo per alcuni aspetti della gestione dei requisiti. Ho
quindi redatto una nuova procedura che si occupasse appunto solamente dello sviluppo e della
gestione dei requisiti, come già anticipato dal paragrafo 4.3.
Lo stesso lavoro fatto per l’area di processo Sviluppo dei Requisiti è stato fatto per l’area
Gestione dei Requisiti, quindi confluiscono entrambe nella stessa procedura (Procedura CM.07 –
Sviluppo e Gestione dei Requisiti).
Il fatto che le sottopratiche ed i work product siano parzialmente soddisfatti od esistenti,
come si vede dalle tabelle, non implica che l’area di processo si trovino ad un buon livello di
capability del CMMI, infatti, per questa area si può stimare un livello di capability al livello 0.
Questo perché, come spiegato nel paragrafo 2.2, se le pratiche specifiche non sono del tutto
soddisfatte ci si trova al livello 0 di capability.
La situazione per le 17 pratiche specifiche di questa area di processo è la seguente:
Gestione dei Requisiti
Analisi e messa in opera in ambito aziendale del CMMI: - 88 -
sviluppo e gestione dei requisiti.
82,35% 5,880%
11,76%
Soddisfatte
Parzialmente Soddisfatte
Non Soddisfatte
Figura 5 – Stima in % delle Pratiche Specifiche soddisfatte per l’area Gestione dei Requisiti
Progettazione del nuovo sistema procedurale
Analisi e messa in opera in ambito aziendale del CMMI: - 89 -
sviluppo e gestione dei requisiti.
6. PROGETTAZIONE DEL NUOVO SISTEMA
PROCEDURALE
Qui ci troviamo nella terza ed ultima fase del nostro lavoro aziendale, ovvero la fase in
cui abbiamo dato vita ad un nuovo sistema procedurale.
Le nuove procedure sono state create sulla base di quelle vecchie, nel caso in cui queste
ultime rispecchiavano in parte le esigenze del CMMI, e da zero, nel caso in cui è stato necessario
un riassetto totale della procedura.
In generale, i primi tre capitoli e l’ultimo sono presenti in tutte le procedure e template.
6.1 Quadro d’insieme: il nuovo sistema procedurale
Le procedure sono state aggiornate sulla base dei dati analizzate dopo la fase
dell’assessment e sulla base del modello CMMI, ottenendo quindi le relazioni con ogni area.
Dopo l’analisi sono state prese le decisioni che hanno portato a creare delle procedure ex-novo, o
a rielaborare semplicemente le esistente o a lasciarle invariate.
Per quanto riguarda entrambe le aree di processo a me assegnate, la conseguenza
dell’analisi effettuata sui dati, è stata quella di creare una nuova procedura che implementasse lo
sviluppo e la gestione dei requisiti. Questo perché, nel vecchio sistema, non c’era nessuna
procedura che rispecchiasse lo sviluppo e la gestione dei requisiti dal punto di vista del CMMI.
Inoltre l’area di processo “Sviluppo dei Requisiti” è quella che più tratta l’interazione con
gli stakeholder, quindi la procedura che si occupa di gestire l’offerta e l’ordine di vendita relativi
ai progetti è messa in relazione appunto con la suddetta area di processo. Alla luce di ciò ho
provveduto alla redazione anche di questa procedura e dei relativi template.
Nella figura seguente sono riportate le aree di processo assegnate a noi stagisti e le
relative procedurali gestionali associate. Dalla figura si evincono anche le sovrapposizioni tra le
procedure, che nascono in quanto più aree avranno pratiche e sottopratiche sviluppate da
procedure di altre aree di processo oppure l’inverso, procedure che svilupperanno punti di aree di
processo non strettamente collegate; questo succede perché le procedure useranno più punti del
modello CMMI per implementare i processi e di conseguenza potranno usare più aree di
processo. Come conseguenza di ciò questa fase è stata realizzata da noi stagisti collaborando tutti
Progettazione del nuovo sistema procedurale
Analisi e messa in opera in ambito aziendale del CMMI: - 90 -
sviluppo e gestione dei requisiti.
insieme, questo per riuscire a capire quali sottopratiche era giusto che fossero sviluppate dalle
procedure assegnate agli altri colleghi piuttosto che a noi stessi e viceversa.
VALVAL
RSK
M
RSK
M
REQ
M
REQ
M
PMCPMC
Procedura
Sviluppo e
Gestione dei
Requisiti
Procedura
Gestione
Offerte e
Ordini di Vendita
Procedura
Pianificazione e
Gestione
Progetti
Procedura
Gestione
Rischi
TSTS
PPPP
VERVER
RDRD
Procedura
Progettazione
Sviluppo e
Implementazione
Procedura
Verifica e Validazione
MAMACMCMProcedura
Metriche
Procedura
Gestione della
ConfigurazionePPQAPPQA
Sistema di
Gestione
per la
Qualità
Figura 6 - Le relazioni tra le Aree di Processo e le Procedure
6.2 Scheda progetto
La scheda progetto è una scheda che è stata create per mappare i processi del ciclo di vita
del software con le aree di processo del modello CMMI, quindi un rapporto uno ad uno tra
processo e pratica specifica.
Progettazione del nuovo sistema procedurale
Analisi e messa in opera in ambito aziendale del CMMI: - 91 -
sviluppo e gestione dei requisiti.
Nell’azienda in cui abbiamo effettuato lo stage si sviluppa software, questo è il motivo
per cui è stato effettuato un mapping tra CMMI e norma 12207.
Questo è il valore aggiunto dei livelli di maturità più alti (dal 3 in poi), appunto un
tailoring sulla situazione aziendale, quindi un ritaglio del CMMI su quella che è la vita
lavorativa dell’azienda nella quale si vuole adottare il modello.
Associare il CMMI al lavoro di tutti i giorni in un’azienda, è una fase molto importante e
che richiede molta cura. Nel nostro caso sono state trovare le relazioni tra pratiche specifiche di
ogni area di processo e processi della norma 12207, in modo da applicare a quella che è la norma
portante dell’azienda, il modello CMMI.
Nella figura seguente, a titolo esplicativo, è riportata solo una parte e solo per una delle
aree di processo a me assegnate, la scheda progetto realizzata dall’azienda, che sarà appunto
portante nel lavoro per questa ultima.
No tailoring. MA tailoring nella 12207.
Si mappa bene con il CMMI:
Da delle linee guida.
Progettazione del nuovo sistema procedurale
Analisi e messa in opera in ambito aziendale del CMMI: - 92 -
sviluppo e gestione dei requisiti.
1.1
1.2
1.1
1.2
3.1
3.2
3.3
3.4
3.5
Avvio
Preparazione della risposta
Contratto
3.3
3.4
2.4
Consegna e completamento
Elicit Needs
Develop the Customer Requirements
Requirements Development
Validate Requirements
Esecuzione e controlli
Establish a Definition of Required
Funcionality
Analyze Requirements
Pratiche Specifiche (CMMI)
Analyze Requirements to Achieve
Balance
Establish Operational Concept and
Scenarios
Analyze Requirements to Achieve
Balance
Obtain an Understanding of Requirements
Attività dei Processi
Processi del Ciclo di
Vita (norma ISO/IEC
12207)
Aree di Processo (CMMI)
5.1
Vendita
(Processo
Primario)
Avvio
Requirements Management
5.2
Fornitura
(Processo
Primario)
Analyze RequirementsRequirements Development
Perform Make, Buy, or Reuse Analyses
Obtain Commitment to Requirements
Riesami e valutazioni
Pianificazione
Figura 7 - Scheda Progetto
Progettazione del nuovo sistema procedurale
Analisi e messa in opera in ambito aziendale del CMMI: - 93 -
sviluppo e gestione dei requisiti.
6.3 Procedura: Sviluppo e Gestione dei requisiti
6.3.1 Descrizione
Questa procedura (Sviluppo e Gestione dei Requisiti – CM.07; riportata nella Appendice
A.1 a pagina 116) è stata scritta seguendo passo passo il manuale CMMI per le aree di processo
“Sviluppo dei Requisiti” e “Gestione dei Requisiti”. I paragrafi del documento redatto sono stati
divisi per pratiche specifiche e per relative sottopratiche. Per ogni punto è stata data una breve
descrizione delle azioni da compiere per soddisfare la sottopratica.
Per alcuni paragrafi è stato dato il riferimento ad altre procedure che si occuperanno di
svilupparli, ed allo stesso modo ci saranno parti nel documento che svilupperanno punti di altre
aree di processo e procedure. Questo succede perché le procedure useranno più punti del modello
CMMI per implementare i processi relativi e di conseguenza potranno usare i risultati di più
punti di aree di processo.
Lo scopo di questa procedura è di produrre, analizzare e gestire i requisiti. Si producono e
si analizzano i requisiti del cliente, del prodotto e dei componenti del prodotto, e si gestiscono
facendo dei controlli ed identificando delle eventuali inconsistenze fra requisiti, piani di progetto
e prodotti di lavoro. Il responsabile del progetto, nominato dal Direttore Tecnico, dovrà applicare
la presente procedura, che fornisce le indicazioni di massima da seguire, le cui istruzioni
operative vengono riportate dettagliatamente nei template a cui si fa riferimento, nella loro
versione corrente.
I template che saranno usati nell’implementazione dalla CM.07 sono due:
Requirements Document (RDoc; Appendice A.2 a pagina 117)
Specifiche Funzionali (SFun; Appendice A.3 a pagina 131)
Il documento RDoc è stato redatto utilizzando alcune parti ben sviluppate ed utili di un
template utilizzato attualmente in azienda per lo sviluppo dei requisiti (SRD - Software
Requirements Document) ed è stato redatto anche e soprattutto seguendo la procedura CM.07.
Quindi la maggior parte dei paragrafi della procedura CM.07 sono stati riportati nell’RDoc sotto
forma di output richiesto. Questo documento definisce i requisiti per lo sviluppo dei progetti.
Il documento SFun è nato invece dall’esigenza di documentare in un altro template le
specifiche funzionali richieste dal modello CMMI nella pratica specifica 3.2 dell’area di
Progettazione del nuovo sistema procedurale
Analisi e messa in opera in ambito aziendale del CMMI: - 94 -
sviluppo e gestione dei requisiti.
processo Sviluppo dei Requisiti. Questo perché le richieste fatte da questa pratica è giusto che
siano affrontate dopo la compilazione del documento RDoc e di conseguenza sulla base di
questo ultimo. La definizione di funzionalità, richiesta da questo documento, anche citata come
“analisi funzionale”, è la descrizione di che cosa il prodotto è inteso a fare. La definizione di
funzionalità può includere le azioni, la sequenza, gli input, gli output, o altre informazioni che
indicano il modo in cui il prodotto sarà usato. Inoltre ad SFun sono stati aggiunti alcuni punti del
modello SRD utilizzato attualmente dall’azienda.
Questi ultimi due documenti saranno gli output prodotti dai Project Manager durante la
fase di sviluppo e gestione dei requisiti per ogni progetto.
Grazie all’implementazione che sarà fatta in azienda seguendo questa procedura,
possiamo dire che il livello di capability per le aree di processo Sviluppo dei Requisiti e
Gestione dei Requisiti sarà portato al livello 2, ovvero al livello di processo gestito. Questo
perché seguendo la procedura il processo avrà le infrastrutture di base per essere supportato; sarà
organizzato ed eseguito in accordo ad alcune regole; impiegherà persone competenti che abbiano
adeguate conoscenze per produrre dei risultati controllati; coinvolgerà gli stakeholder più
importanti (ovvero i portatori di interessi del progetto); e sarà monitorato, controllato e
revisionato. Inoltre le pratiche esistenti saranno mantenute nel tempo.
6.3.2 Mapping delle pratiche specifiche con la procedura
Di seguito sono riportate le tabelle della fase dell’assessment però aggiornate al nuovo
sistema procedurale ed ai nuovi template prodotti.
Per i typical work products i campi sono stati tutti riempiti con la nota “Non Applicabile
– N/A”, infatti il fatto che nelle tabelle seguenti si dia una indicazione di quello che sarà il nuovo
sistema procedura adottato dall’azienda, non ci può far affermare la loro presenza o meno dei
work product, che tra l’altro saranno automaticamente soddisfatti dal soddisfacimento delle
sottopratiche.
Progettazione del nuovo sistema procedurale
Analisi e messa in opera in ambito aziendale del CMMI: - 95 -
sviluppo e gestione dei requisiti.
Pro
ced
ura
Ges
tion
ale
Docu
men
to d
i
Ou
tpu
t
Su
bp
ract
ices
1. A
ttiv
are
e sv
iluppar
e le
nec
essi
tà d
egli
sta
keh
old
er
usa
ndo m
etodi
per
est
rapola
re e
sigen
ze, as
pet
tati
ve,
vin
coli
ed i
nte
rfac
ce e
ster
ne
CM
.07
:
par
agra
fo
4.1
.1.
MO
M (
Min
ute
of
Mee
ting)
Ese
mp
i
· D
imost
razi
oni
di
tecn
olo
gia
· G
ruppi
di
lavo
ro d
i co
ntr
oll
o d
ell'in
terf
acc
ia
· G
ruppi
di
lavo
ro d
i co
ntr
oll
o t
ecnic
o
· R
evis
ioni
di
pro
get
to d
i in
teri
m
· Q
ues
tionari
, in
terv
iste
e s
cenari
oper
ati
vi o
tten
uti
dagli
uti
lizz
ato
ri f
inali
· P
roto
tipi
e m
odel
li
· Sch
iera
men
to d
i fu
nzi
one
di
quali
tà
· In
dagin
i del
mer
cato
· E
stra
zione
dall
e fo
nti
quali
i d
ocu
men
ti, i
cam
pio
ni,
o l
e sp
ecif
iche
· O
sser
vazi
on
e dei
pro
dott
i, d
egli
am
bie
nti
e d
ei
model
li a
ttuali
di
work
flow
· U
sare
i c
asi
· A
nali
si d
el c
aso
di
aff
ari
· In
dagin
i di
soddis
fazi
on
e del
cli
ente
Pro
get
to d
i ri
feri
men
to c
om
e es
empio
: T
eles
paz
io C
osm
o S
ky-M
ED
SP
1.1
Esp
lici
tare
le
Nec
essi
tà
Progettazione del nuovo sistema procedurale
Analisi e messa in opera in ambito aziendale del CMMI: - 96 -
sviluppo e gestione dei requisiti.
Pro
ced
ura
Ges
tion
ale
Docu
men
to d
i
Ou
tpu
t
1. R
equis
iti
del
cli
ente
N/A
N/A
2. V
inco
li d
el c
lien
te s
ull
a co
nduzi
one
del
la v
erif
ica
N/A
N/A
3. V
inco
li d
el c
lien
te s
ull
a co
nduzi
one
del
la
val
idaz
ione
N/A
N/A
1. T
radurr
e le
nec
essi
tà d
egli
sta
keh
old
er, le
aspet
tati
ve,
i v
inco
li e
le
inte
rfac
ce n
el d
ocu
men
to d
ei
requis
iti
2. D
efin
ire
i vin
coli
per
la
ver
ific
a e
la v
alid
azio
ne
SP
1.2
Svil
up
pare
i R
equ
isit
i d
el C
lien
te
CM
.07
:
par
agra
fo
4.1
.2.
PM
P (
Pro
ject
Man
agem
ent
Pla
n)
Typ
ical
Work
Pro
du
cts
Su
bp
ract
ices
Pro
get
to d
i ri
feri
men
to c
om
e es
empio
: T
eles
paz
io C
osm
o S
ky-M
ED
Progettazione del nuovo sistema procedurale
Analisi e messa in opera in ambito aziendale del CMMI: - 97 -
sviluppo e gestione dei requisiti.
Pro
ced
ura
Ges
tion
ale
Docu
men
to d
i
Ou
tpu
t
1. R
equis
iti
der
ivat
i (v
. A
rea
di
Pro
cess
o "
Solu
zione
Tec
nic
a")
N/A
N/A
2. R
equis
iti
di
pro
dott
o
N/A
N/A
3. R
equis
iti
di
com
ponen
ti d
i pro
dott
oN
/AN
/A
1. S
vil
uppar
e i
requis
iti
in s
pec
ific
he
tecn
iche
di
pro
get
tazi
one
nec
essa
rie
per
il
dis
egno d
i pro
get
to d
i
pro
dott
o e
dei
com
ponen
ti d
i pro
dott
o
CM
.07
:
par
agra
fo
4.2
.1.1
.
2. D
eter
min
are
even
tual
i re
quis
iti
der
ivat
i dal
le
dec
isio
ni
di
pro
get
to
CM
.07
:
par
agra
fo
4.2
.1.2
.
3. S
tabil
ire
e m
ante
ner
e le
rel
azio
ni
tra
requis
iti
dura
nte
i c
ambia
men
ti
CM
.07
:
par
agra
fo
4.2
.1.3
.
SP
2.1
Sta
bil
ire
i R
equ
isit
i d
i P
rod
ott
o e
dei
Com
pon
enti
del
Pro
dott
o
Typ
ical
Work
Pro
du
cts
Su
bp
ract
ices
Pro
get
to d
i ri
feri
men
to c
om
e es
empio
: T
eles
paz
io C
osm
o S
ky-M
ED
RD
oc
(Req
uir
emen
ts
Docu
men
t)
Progettazione del nuovo sistema procedurale
Analisi e messa in opera in ambito aziendale del CMMI: - 98 -
sviluppo e gestione dei requisiti.
Pro
ced
ura
Ges
tion
ale
Docu
men
to d
i
Ou
tpu
t
1. T
abel
le d
i as
segnaz
ione
di
requis
ito
N/A
N/A
2. A
sseg
naz
ione
pro
vvis
ori
a di
requis
ito
N/A
N/A
3. V
inco
li d
i dis
egno d
i pro
get
to
N/A
N/A
4. R
equis
iti
der
ivat
i N
/AN
/A
5. R
apport
i fr
a i
requis
iti
der
ivat
iN
/AN
/A
1. A
sseg
nar
e i
requis
iti
alle
funzi
oni
CM
.07
:
par
agra
fo
4.2
.2.1
.
2. A
sseg
nar
e i
requis
iti
ai c
om
ponen
ti d
i pro
dott
o
CM
.07
:
par
agra
fo
4.2
.2.2
.
3. A
sseg
nar
e i
vin
coli
di
pro
get
to a
i co
mponen
ti d
i
pro
dott
o
CM
.07
:
par
agra
fo
4.2
.2.3
.
4. D
ocu
men
tare
le
rela
zioni
tra
i div
ersi
req
uis
iti
asse
gnat
i
CM
.07
:
par
agra
fo
4.2
.2.4
.
SP
2.2
All
oca
re i
Req
uis
iti
ad
ogn
i C
om
pon
ente
di
Pro
dott
o
Typ
ical
Work
Pro
du
cts
Su
bp
ract
ices
Pro
get
to d
i ri
feri
men
to c
om
e es
empio
: T
eles
paz
io C
osm
o S
ky-M
ED
RD
oc
(Req
uir
emen
ts
Docu
men
t)
Progettazione del nuovo sistema procedurale
Analisi e messa in opera in ambito aziendale del CMMI: - 99 -
sviluppo e gestione dei requisiti.
Pro
ced
ura
Ges
tion
ale
Docu
men
to d
i
Ou
tpu
t
Typ
ical
Work
Pro
du
cts
1. R
equis
iti
di
Inte
rfac
cia
N/A
N/A
1. Id
enti
fica
re l
e in
terf
acce
, si
a es
tern
e ch
e in
tern
e al
pro
dott
o (
i.e.
tra
le
par
tizi
oni
o g
li o
gget
ti f
unzi
onal
i)
CM
.07
:
par
agra
fo
4.2
.3.1
.
2. S
vil
uppar
e i
requis
iti
per
le
inte
rfac
ce i
den
tifi
cate
CM
.07
:
par
agra
fo
4.2
.3.2
.
Su
bp
ract
ices
Pro
get
to d
i ri
feri
men
to c
om
e es
empio
: T
eles
paz
io C
osm
o S
ky-M
ED
RD
oc
(Req
uir
emen
ts
Docu
men
t)
SP
2.3
Id
enti
fica
re i
Req
uis
iti
di
Inte
rfacc
ia
Progettazione del nuovo sistema procedurale
Analisi e messa in opera in ambito aziendale del CMMI: - 100 -
sviluppo e gestione dei requisiti.
Pro
ced
ura
Ges
tion
ale
Docu
men
to d
i
Ou
tpu
t
1. C
once
tti
Oper
ativ
iN
/AN
/A
2. In
stal
lazi
one
del
pro
dott
o o
del
com
ponen
te d
i
pro
dott
o, m
anute
nzi
one
e co
nce
tti
di
sost
egno
N/A
N/A
3. C
once
tti
di
elim
inaz
ione
("dis
po
sal"
)N
/AN
/A
4. C
asi
d'u
soN
/AN
/A
5. S
cenar
i cr
onolo
gic
iN
/AN
/A
6. N
uovi
requis
iti
N/A
N/A
1. S
tabil
ire
i co
nce
tti
oper
ativ
i e
gli
sce
nar
i ch
e
incl
udono f
unzi
onal
ità,
pre
staz
ioni,
man
ute
nzi
one,
support
o e
d e
lim
inaz
ioni,
in m
anie
ra a
ppro
pri
ata
CM
.07
:
par
agra
fo
4.3
.1.1
.
2. D
efin
ire
l'am
bie
nte
in c
ui
il p
rodott
o o
i
com
ponen
ti d
i pro
dott
o d
ovra
nno f
unzi
onar
e,
incl
uden
do l
imit
i e
vin
coli
CM
.07
:
par
agra
fo
4.3
.1.2
.
3. R
ived
ere
i co
nce
tti
oper
ativ
i e
gli
sce
nar
i per
raff
inar
e e
scopri
re i
req
uis
iti
CM
.07
:
par
agra
fo
4.3
.1.3
.
4. S
vil
uppar
e un d
etta
gli
ato c
once
tto o
per
ativ
o, co
me
i pro
dott
i ed
i c
om
ponen
ti d
i pro
dott
o s
ono
sele
zionat
i, c
he
def
inis
ca l
e in
tera
zioni
del
pro
dott
o,
del
l'ute
nte
fin
ale,
del
l'am
bie
nte
, e
soddis
fino l
e
nec
essi
tà o
per
ativ
e di
man
ute
nzi
one,
di
support
o e
di
elim
inaz
ione
CM
.07
:
par
agra
fo
4.3
.1.4
.
Typ
ical
Work
Pro
du
cts
Su
bp
ract
ices
Pro
get
to d
i ri
feri
men
to c
om
e es
empio
: T
eles
paz
io C
osm
o S
ky-M
ED
SP
3.1
Sta
bil
ire
i C
on
cett
i O
per
ati
vi
e gli
Sce
nari
RD
oc
(Req
uir
emen
ts
Docu
men
t)
Progettazione del nuovo sistema procedurale
Analisi e messa in opera in ambito aziendale del CMMI: - 101 -
sviluppo e gestione dei requisiti.
Pro
ced
ura
Ges
tion
ale
Docu
men
to d
i
Ou
tpu
t
1. A
rchit
ettu
ra f
unzi
onal
eN
/AN
/A
2. D
iagra
mm
i di
atti
vit
à e
casi
d'u
soN
/AN
/A
3. A
nal
isi
ori
enta
ta a
gli
ogget
ti c
on s
erviz
i o m
etodi
iden
tifi
cati
N/A
N/A
1. A
nal
izza
re e
quan
tifi
care
la
funzi
onal
ità
rich
iest
a
dal
l'ute
nte
fin
ale
CM
.07
:
par
agra
fo
4.3
.2.1
.
2. A
nal
izza
re i
req
uis
iti
per
iden
tifi
care
le
par
tizi
oni
logic
he
o f
unzi
onal
i (s
ott
ofu
nzi
oni)
CM
.07
:
par
agra
fo
4.3
.2.2
.
3. R
ipar
tire
i r
equis
iti
in g
ruppi,
bas
andosi
su c
rite
ri
stab
ilit
i (f
unzi
onal
ità
sim
ilar
i, p
rest
azio
ni
o c
oppie
),
per
fac
ilit
are
e fo
cali
zzar
e l'a
nal
isi
dei
req
uis
iti
stes
si
CM
.07
:
par
agra
fo
4.3
.2.3
.
4. C
onsi
der
are
l'ord
inam
ento
del
le f
unzi
oni
tim
e-
crit
ical
, in
izia
lmen
te e
succ
essi
vam
ente
, dura
nte
lo
svil
uppo d
ei c
om
ponen
ti d
i pro
dott
o
CM
.07
:
par
agra
fo
4.3
.2.4
.
5. A
sseg
nar
e i
requis
iti
del
cli
ente
all
e par
tizi
oni
funzi
onal
i, o
gget
ti, per
sone,
o e
lem
enti
di
support
o
per
fac
ilit
are
la s
inte
si d
elle
solu
zioni
CM
.07
:
par
agra
fo
4.3
.2.5
.
6. A
sseg
nar
e i
requis
iti
funzi
onal
i e
pre
staz
ional
i al
le
funzi
oni
ed a
lle
sott
ofu
nzi
oni
CM
.07
:
par
agra
fo
4.3
.2.6
.
SP
3.2
Sta
bil
ire
un
a D
efin
izio
ne
di
Fu
nzi
on
ali
tà R
ich
iest
a
Typ
ical
Work
Pro
du
cts
Su
bp
ract
ices
Pro
get
to d
i ri
feri
men
to c
om
e es
empio
: T
eles
paz
io C
osm
o S
ky-M
ED
SF
un
(S
pec
ific
he
funzi
onal
i)
Progettazione del nuovo sistema procedurale
Analisi e messa in opera in ambito aziendale del CMMI: - 102 -
sviluppo e gestione dei requisiti.
Proced
ura
Gest
ion
ale
Docu
men
to d
i
Ou
tpu
t
1. R
eport
dei
dif
ett
i dei
requis
iti
N/A
N/A
2. P
ropost
e d
i m
odif
iche d
ei
requis
iti
per
riso
lvere
i
dif
ett
iN
/AN
/A
3. R
equis
iti
chia
ve
N/A
N/A
4. M
isure
di
pre
stazio
ni
tecnic
he (
v. A
rea d
i P
rocess
o
"Mis
ura
zio
ne e
Anali
si")
N/A
N/A
1. A
nali
zzare
le e
sigenze d
egli
sta
kehold
er,
le
asp
ett
ati
ve, i
vin
coli
e l
e i
nte
rfacce e
stern
e p
er
eli
min
are
i c
onfl
itti
ed o
rganiz
zare
negli
oggett
i
corr
ela
ti
CM
.07
:
para
gra
fo
4.3
.3.1
.
2. A
nali
zzare
i r
equis
iti
per
dete
rmin
are
se s
oddis
fano
gli
obie
ttiv
i dei
requis
iti
di
livell
o s
uperi
ore
CM
.07
:
para
gra
fo
4.3
.3.2
.
3. A
nali
zzare
i r
equis
iti
per
ass
icura
re c
he s
iano
com
ple
ti, fa
ttib
ile, re
ali
zzabil
i e v
eri
ficabil
i
CM
.07
:
para
gra
fo
4.3
.3.3
.
4. Id
enti
ficare
i r
equis
iti
chia
ve, i
quali
hanno u
na
fort
e i
nfl
uenza s
ul
cost
o,
lo 'sc
hedule
', l
a f
unzio
nali
tà,
il r
ischio
o l
e p
rest
azio
ni
CM
.07
:
para
gra
fo
4.3
.3.4
.
5. Id
enti
ficare
le m
isure
di
pre
stazio
ni
tecnic
he, che
sara
nno t
raccia
te d
ura
nte
la f
ase
di
svil
uppo
CM
.07
:
para
gra
fo
4.3
.3.5
.
RD
oc
(Requir
em
ents
Docum
ent)
;
docum
enti
rela
tivi
all
'are
a d
i pro
cess
o
MA
(M
easu
rem
ent
and A
naly
sis)
6. A
nali
zzare
i c
oncett
i opera
tivi
e g
li s
cenari
per
raff
inare
i f
abbis
ogni
del
cli
ente
, i
vin
coli
e l
e
inte
rfacce, e p
er
scopri
re i
nuovi
requis
iti
CM
.07
:
para
gra
fo
4.3
.3.6
.
RD
oc
(Requir
em
ents
Docum
ent)
SP
3.3
An
ali
zzare i
Req
uis
iti
Typ
ical
Work
Prod
ucts
Su
bp
racti
ces
Pro
gett
o d
i ri
feri
mento
com
e e
sem
pio
: T
ele
spazio
Cosm
o S
ky-M
ED
RD
oc
(Requir
em
ents
Docum
ent)
Progettazione del nuovo sistema procedurale
Analisi e messa in opera in ambito aziendale del CMMI: - 103 -
sviluppo e gestione dei requisiti.
Pro
ced
ura
Ges
tion
ale
Docu
men
to d
i
Ou
tpu
t
Typ
ical
Work
Pro
du
cts
1. V
aluta
zione
dei
ris
chi
rela
tivam
ente
ai
requis
iti
N/A
N/A
1. U
tili
zzar
e i
model
li p
rova,
le
sim
ula
zioni
e i
pro
toti
pi
per
anal
izza
re i
l bil
anci
amen
to d
ei
fabbis
ogni
e dei
vin
coli
deg
li s
takeh
old
er (
ad e
s. p
er
ridurr
e i
cost
i ed
i r
isch
i)
CM
.07
:
par
agra
fo
4.3
.4.1
.
2. E
ffet
tuar
e una
val
uta
zione
del
ris
chio
sui
requis
iti
e
sull
'arc
hit
ettu
ra f
unzi
onal
e
CM
.07
:
par
agra
fo
4.3
.4.2
.
3. E
sam
inar
e i
conce
tti
del
cic
lo d
i vit
a del
pro
dott
o
per
gli
eff
etti
dei
req
uis
iti
sui
risc
hi
CM
.07
:
par
agra
fo
4.3
.4.3
.
Su
bp
ract
ices
Pro
get
to d
i ri
feri
men
to c
om
e es
empio
: T
eles
paz
io C
osm
o S
ky-M
ED
SP
3.4
An
ali
zzare
i R
equ
isit
i p
er O
tten
ere
Bil
an
ciam
ento
RM
P (
Ris
k
Man
agem
ent
Pla
n)
Progettazione del nuovo sistema procedurale
Analisi e messa in opera in ambito aziendale del CMMI: - 104 -
sviluppo e gestione dei requisiti.
Pro
ced
ura
Ges
tion
ale
Docu
men
to d
i
Ou
tpu
t
Typ
ical
Work
Pro
du
cts
1. A
nnota
zione
dei
met
odi
e dei
ris
ult
ati
di
anal
isi
N/A
N/A
1. A
nal
izza
re i
req
uis
iti
per
det
erm
inar
e il
ris
chio
che
il p
rodott
o r
isult
ante
non f
unzi
oni
ben
e nel
l'am
bie
nte
stab
ilit
o
CM
.07
:
par
agra
fo
4.3
.5.1
.
2. E
splo
rare
l'a
deg
uat
ezza
e l
a co
mple
tezz
a dei
requis
iti,
con l
o s
vil
uppo d
i ra
ppre
senta
zioni
del
pro
dott
o (
pro
toti
pi,
sim
ula
zioni,
model
li, sc
enar
i ec
c.)
ed o
tten
endo i
l fe
edbac
k s
ugli
ste
ssi
da
par
te d
ei
Rel
evan
t S
takeh
old
er
CM
.07
:
par
agra
fo
4.3
.5.2
.
3. V
aluta
re c
om
e il
pro
get
to m
atura
nel
conte
sto
del
l'am
bie
nte
di
val
idaz
ione
dei
req
uis
iti
per
iden
tifi
care
i p
roble
mi
di
val
idaz
ione
e per
esp
orr
e i
bis
ogni
ed i
req
uis
iti
del
cli
ente
non s
pec
ific
ati
CM
.07
:
par
agra
fo
4.3
.5.3
.
SP
3.5
Vali
dare
i R
equ
isit
i
Pro
get
to d
i ri
feri
men
to c
om
e es
empio
: T
eles
paz
io C
osm
o S
ky-M
ED
Su
bp
ract
ices
Tes
t P
lan
, T
est
Des
crip
tion
, T
est
Rep
ort
.
Progettazione del nuovo sistema procedurale
Analisi e messa in opera in ambito aziendale del CMMI: - 105 -
sviluppo e gestione dei requisiti.
Pro
ced
ura
Ges
tion
ale
Docu
men
to d
i
Ou
tpu
t
1. L
iste
dei
cri
teri
per
dis
tinguer
e i
forn
itori
dei
requis
iti
adat
tiN
/AN
/A
2. C
rite
ri d
i val
uta
zione
/ ac
cett
azio
ne
dei
req
uis
iti
N/A
N/A
3. R
isult
ati
del
l'anal
isi
in b
ase
ai c
rite
riN
/AN
/A
4. In
siem
e di
requis
iti
acce
ttat
i N
/AN
/A
1. S
tabil
ire
i cr
iter
i per
dis
tinguer
e in
man
iera
appro
pri
ata
le f
onti
di
pro
ven
ienza
dei
req
uis
iti
CM
.07
:
par
agra
fo
4.4
.1.1
.
2. S
tabil
ire
dei
cri
teri
ogget
tivi
per
la
val
uta
zione
e
l'acc
etta
zione
dei
req
uis
iti,
che
sian
o a
d e
sem
pio
:
dic
hia
rati
chia
ram
ente
e c
orr
etta
men
te, co
mple
ti,
consi
sten
ti c
on i
l re
sto, u
niv
oca
men
te i
den
tifi
cati
,
imple
men
tabil
i, v
erif
icab
ili
(tes
tabil
i), tr
acci
abil
i
CM
.07
:
par
agra
fo
4.4
.1.2
.
3. A
nal
izza
re i
req
uis
iti
per
acc
erta
rsi
che
inco
ntr
ino i
crit
eri
stab
ilit
i
CM
.07
:
par
agra
fo
4.4
.1.3
.
4. R
aggiu
nger
e la
condiv
isio
ne
dei
req
uis
iti
con c
hi
li
forn
isce
, in
modo c
he
i par
teci
pan
ti a
l pro
get
to
poss
ano e
sser
e co
involt
i
CM
.07
:
par
agra
fo
4.4
.1.4
.
MO
M (
Min
ute
of
Mee
ting);
PM
P
(Pro
ject
Man
agem
ent
Pla
n)
SP
1.1
Ott
ener
e la
Com
pre
nsi
on
e d
ei R
equ
isit
i
Typ
ical
Work
Pro
du
cts
Su
bp
ract
ices
Pro
get
to d
i ri
feri
men
to c
om
e es
empio
: S
elex
- D
isas
ter
Rec
over
y
RD
oc
(Req
uir
emen
ts
Docu
men
t)
Progettazione del nuovo sistema procedurale
Analisi e messa in opera in ambito aziendale del CMMI: - 106 -
sviluppo e gestione dei requisiti.
Pro
ced
ura
Ges
tion
ale
Docu
men
to d
i
Ou
tpu
t
1. V
aluta
zione
di
impat
to d
ei r
equis
iti
N/A
N/A
2. D
ocu
men
tazi
one
del
l'im
peg
no n
egozi
ato p
er i
requis
iti
nuovi
e/o m
odif
icat
iN
/AN
/A
1. V
aluta
re l
'impat
to d
ei r
equis
iti
(nuovi
o m
odif
icat
i)
sugli
im
peg
ni
esis
tenti
CM
.07
:
par
agra
fo
4.4
.2.1
.
MO
M (
Min
ute
of
Mee
ting);
PM
P
(Pro
ject
Man
agem
ent
Pla
n).
2. N
egozi
are
e re
gis
trar
e gli
im
peg
ni
CM
.07
:
par
agra
fo
4.4
.2.2
.
PM
P (
Pro
ject
Man
agem
ent
Pla
n).
Typ
ical
Work
Pro
du
cts
Su
bp
ract
ices
Pro
get
to d
i ri
feri
men
to c
om
e es
empio
: S
elex
- D
isas
ter
Rec
over
y
SP
1.2
Ott
ener
e l'
Imp
egn
o i
n b
ase
ai
Req
uis
iti
Progettazione del nuovo sistema procedurale
Analisi e messa in opera in ambito aziendale del CMMI: - 107 -
sviluppo e gestione dei requisiti.
Pro
ced
ura
Ges
tion
ale
Docu
men
to d
i
Ou
tpu
t
1. S
tatu
s dei
req
uis
iti
N/A
N/A
2. D
atab
ase
dei
req
uis
iti
N/A
N/A
3. D
atab
ase
del
le d
ecis
ioni
pre
se i
n m
erit
o a
i re
quis
iti
N/A
N/A
1. D
ocu
men
tare
i r
equis
iti
e le
modif
iche
ad e
ssi
apport
ate
e/o g
ener
ate
dal
pro
get
to
CM
.07
:
par
agra
fo
4.4
.3.1
.
RD
oc
(Req
uir
emen
ts
Docu
men
t)
2. M
ante
ner
e uno s
tori
co d
elle
modif
iche
dei
req
uis
iti
con l
a m
oti
vaz
ione
di
tali
cam
bia
men
ti
CM
.07
:
par
agra
fo
4.4
.3.2
.
PG
C (
Pia
no d
i
Ges
tione
Confi
gura
zione)
3. V
aluta
re l
'impat
to d
elle
modif
iche
dei
req
uis
iti
dal
punto
di
vis
ta d
ei r
elev
ant
stak
ehold
er
CM
.07
:
par
agra
fo
4.4
.3.3
.
MO
M (
Min
ute
of
Mee
ting);
PP
R
(Per
iodic
al P
rogre
ss
Rep
ort
); P
AC
(Pia
no p
er l
e A
zioni
Corr
etti
ve)
.
4. R
ender
e dis
po
nib
ili
a tu
tto i
l pro
get
to i
dat
i su
i
requis
iti
e su
lle
modif
iche
ai r
equis
iti
stes
si
CM
.07
:
par
agra
fo
4.4
.3.4
.
PG
C (
Pia
no d
i
Ges
tione
Confi
gura
zione)
;
GD
C (
Gio
rnal
e di
Confi
gura
zione)
.
Typ
ical
Work
Pro
du
cts
Su
bp
ract
ices
Pro
get
to d
i ri
feri
men
to c
om
e es
empio
: S
elex
- D
isas
ter
Rec
over
y
SP
1.3
Ges
tire
i C
am
bia
men
ti d
ei R
equ
isit
i
Progettazione del nuovo sistema procedurale
Analisi e messa in opera in ambito aziendale del CMMI: - 108 -
sviluppo e gestione dei requisiti.
Pro
ced
ura
Ges
tion
ale
Docu
men
to d
i
Ou
tpu
t
1. M
atri
ce d
i tr
acci
abil
ità
dei
req
uis
iti
N/A
N/A
2. S
iste
ma
di
rintr
acci
abil
ità
dei
req
uis
iti
N/A
N/A
1. M
ante
ner
e la
tra
ccia
bil
ità
dei
req
uis
iti
per
assi
cura
re c
he
la f
onte
dei
req
uis
iti
di
livel
lo i
nfe
riore
(der
ivat
i) s
ia d
ocu
men
tata
CM
.07
:
par
agra
fo
4.4
.4.1
.
2. M
ante
ner
e la
tra
ccia
bil
ità
dei
req
uis
iti
da
un
requis
ito a
i su
oi
der
ivat
i ed
all
e su
e al
loca
zioni
di
funzi
oni,
inte
rfac
ce, ogget
ti, per
sone,
pro
cess
i e
"work
pro
duct
"
CM
.07
:
par
agra
fo
4.4
.4.2
.
3. G
ener
are
la m
atri
ce d
i tr
acci
abil
ità
dei
req
uis
iti
CM
.07
:
par
agra
fo
4.4
.4.3
.
SP
1.4
Man
ten
ere
un
a T
racc
iab
ilit
à B
idir
ezio
nale
dei
Req
uis
iti
Typ
ical
Work
Pro
du
cts
Su
bp
ract
ices
Pro
get
to d
i ri
feri
men
to c
om
e es
empio
: S
elex
- D
isas
ter
Rec
over
y
RD
oc
(Req
uir
emen
ts
Docu
men
t)
Progettazione del nuovo sistema procedurale
Analisi e messa in opera in ambito aziendale del CMMI: - 109 -
sviluppo e gestione dei requisiti.
Pro
ced
ura
Ges
tion
ale
Docu
men
to d
i
Ou
tpu
t
1. D
ocu
men
tazi
one
del
le i
nco
nsi
sten
ze i
ncl
uden
do
sorg
enti
, co
ndiz
ioni
e m
oti
vaz
ioni
N/A
N/A
2. In
siem
e del
le a
zioni
corr
etti
ve
N/A
N/A
1. R
evis
ionar
e i
pia
ni
di
pro
get
to, le
att
ivit
à e
i "w
ork
pro
duct
" per
ver
ific
are
la c
onsi
sten
za c
on i
req
uis
iti
e
le m
odif
iche
fatt
e a
loro
CM
.07
:
par
agra
fo
4.4
.5.1
.
2. Id
enti
fica
re l
a fo
nte
del
le i
nco
nsi
sten
ze e
la
moti
vaz
ione
CM
.07
:
par
agra
fo
4.4
.5.2
.
3. Id
enti
fica
re l
e m
odif
iche
che
è nec
essa
rio e
ffet
tuar
e
sui
pia
ni
e su
i "w
ork
pro
duct
" a
seguit
o d
ei
cam
bia
men
ti a
lle
bas
elin
e dei
req
uis
iti
CM
.07
:
par
agra
fo
4.4
.5.3
.
4. A
ttuar
e le
nec
essa
ri a
zioni
corr
etti
ve
CM
.07
:
par
agra
fo
4.4
.5.4
.
SP
1.5
Id
enti
fica
re l
e In
con
sist
enze
tra
Pro
ject
Work
e R
equ
isit
i
Pro
get
to d
i ri
feri
men
to c
om
e es
empio
: S
elex
- D
isas
ter
Rec
over
y
Typ
ical
Work
Pro
du
cts
Su
bp
ract
ices
PM
P (
Pro
ject
Man
agem
ent
Pla
n)
PA
C (
Pia
no p
er l
e
Azi
oni
Corr
etti
ve)
Progettazione del nuovo sistema procedurale
Analisi e messa in opera in ambito aziendale del CMMI: - 110 -
sviluppo e gestione dei requisiti.
6.4 Procedura: Gestione Offerta ed Ordine di Vendita
6.4.1 Descrizione
Questa procedura (Gestione Offerta ed Ordine di Vendita – CM.03; Appendice B.1 a
pagina 139) è stata redatta sulla base della procedura del vecchio sistema, la PG.03A (Offerte e
Riesame Contratto) e sulla base delle linee guida del CMMI, quindi ho integrato la PG.03A con
le pratiche delle aree di processo del CMMI che trattassero dell’offerta e dell’ordine di vendita.
Questa procedura non ha un rapporto uno ad uno con una determinata area di processo
ma più che altro utilizza i risultati che vengono fuori dalle analisi di determinate aree. E’
associata a Sviluppo dei Requisiti perché è questa ultima quella che più interagisce con gli
stakeholder e che quindi potrà contrattare con loro, ma ne utilizza solo le informazioni prodotte e
non ne implementa nessuna sottopratica.
La presente procedura definisce le modalità operative, i compiti e le responsabilità
dell’attività di riesame ed emissione delle offerte nonché del riesame ed accettazione dei contratti
e degli ordini. Tale procedura deve essere applicata all’elaborazione di tutte le offerte emesse ed
a tutti i contratti ed ordini ricevuti dall’azienda da parte dei clienti, perché è in linea con le
esigenze del CMMI pur non avendo una corrispondente area di processo in particolare. Il
responsabile del progetto, nominato dal Direttore Tecnico, dovrà applicare la presente procedura,
che fornisce le indicazioni di massima da seguire, le cui istruzioni operative vengono riportate
dettagliatamente nei template a cui si fa riferimento, nella loro versione corrente.
I template che saranno usati nell’implementazione dalla CM.03 sono due:
Offerta Economica (OE; Appendice B.2 a pagina 139).
Offerta Tecnica (OT; Appendice B.3 pagina 145)
L’Offerta Commerciale, che viene presentata al cliente, è composta principalmente da
questi due documenti: Offerta Tecnica (che descrive gli aspetti tecnici della fornitura) ed Offerta
Economica (che cura gli aspetti economici legati ai singoli componenti della fornitura).
Questi ultimi due documenti non seguono passo passo una procedura corrispondente ma
astraggono un po’ da questa ultima perché sono stati scritti con l’aiuto del Sales Director, che vi
ha aggiunto dei punti importanti per l’azienda per la preparazione delle offerte per il cliente.
Questo non va fuori dalle esigenze del CMMI, ma anzi ne migliora le performance perché si
Progettazione del nuovo sistema procedurale
Analisi e messa in opera in ambito aziendale del CMMI: - 111 -
sviluppo e gestione dei requisiti.
ritaglia sulla situazione aziendale il modello stesso. Infatti il CMMI dice cosa bisogna fare ma
non come bisogna farlo
Questi due documenti saranno gli output prodotti dai Project Manager durante la fase di
gestione dell’offerta e dell’ordine di vendita per ogni progetto.
6.4.2 Mapping delle pratiche specifiche con la procedura
Per questa procedura non è presente un mapping in quanto, come già detto nel paragrafo
precedente (6.4.1), non vi è un rapporto uno ad uno con le mie aree di processo ma ne utilizza
solo i risultati prodotti.
Conclusioni
Analisi e messa in opera in ambito aziendale del CMMI: - 112 -
sviluppo e gestione dei requisiti.
CONCLUSIONI
In conclusione presento, per le aree di processo a me assegnate, quella che era la
situazione aziendale prima e quella che sarà dopo la creazione del nuovo sistema procedurale.
Prima del nuovo sistema procedurale:
Dall’analisi effettuata sull’assessment la situazione era, per l’area Sviluppo dei Requisiti:
livello di capability 0 del CMMI e percentuale di Pratiche Specifiche soddisfatte dello 0%. Su un
totale di 34 pratiche la situazione era la seguente:
0%97,06%
2,941%
Soddisfatte
Parzialmente Soddisfatte
Non Soddisfatte
Figura 8 – Stima in % delle Pratiche Specifiche soddisfatte per l’area Sviluppo dei Requisiti
prima del nuovo sistema procedurale
Dall’analisi effettuata sull’assessment la situazione era, per l’area Gestione dei Requisiti:
livello di capability 0 del CMMI e percentuale di Pratiche Specifiche soddisfatte dell’11,76%. Su
un totale di 17 pratiche la situazione era la seguente:
Conclusioni
Analisi e messa in opera in ambito aziendale del CMMI: - 113 -
sviluppo e gestione dei requisiti.
82,35% 5,880%
11,76%
Soddisfatte
Parzialmente Soddisfatte
Non Soddisfatte
Figura 9 - Stima delle Pratiche Specifiche soddisfatte per l’area Gestione dei Requisiti prima
del nuovo sistema procedurale
Dopo il nuovo sistema procedurale:
La situazione, per l’area Sviluppo dei Requisiti, dopo l’adozione da parte dell’azienda del
nuovo sistema procedurale, sarà: livello di capability 2 del CMMI e percentuale di Pratiche
Specifiche soddisfatte del 100%.
Conclusioni
Analisi e messa in opera in ambito aziendale del CMMI: - 114 -
sviluppo e gestione dei requisiti.
100%
0,00%
0,000%
Soddisfatte
Parzialmente Soddisfatte
Non Soddisfatte
Figura 10 - Stima delle Pratiche Specifiche soddisfatte per l’area Sviluppo dei Requisiti dopo
l’adozione del nuovo sistema procedurale
La situazione, per l’area Gestione dei Requisiti, dopo l’adozione da parte dell’azienda del
nuovo sistema procedurale, sarà: livello di capability 2 del CMMI e percentuale di Pratiche
Specifiche soddisfatte del 100%.
Conclusioni
Analisi e messa in opera in ambito aziendale del CMMI: - 115 -
sviluppo e gestione dei requisiti.
100%
0,00%
0,000%
Soddisfatte
Parzialmente Soddisfatte
Non Soddisfatte
Figura 11 - Stima delle Pratiche Specifiche soddisfatte per l’area Gestione dei Requisiti dopo
l’adozione del nuovo sistema procedurale
Appendice A.1
Analisi e messa in opera in ambito aziendale del CMMI: - 116 -
sviluppo e gestione dei requisiti.
APPENDICE A.1
Appendice A.2
Analisi e messa in opera in ambito aziendale del CMMI: - 117 -
sviluppo e gestione dei requisiti.
APPENDICE A.2
Appendice A.2
Analisi e messa in opera in ambito aziendale del CMMI: - 118 -
sviluppo e gestione dei requisiti.
Appendice A.2
Analisi e messa in opera in ambito aziendale del CMMI: - 119 -
sviluppo e gestione dei requisiti.
Appendice A.2
Analisi e messa in opera in ambito aziendale del CMMI: - 120 -
sviluppo e gestione dei requisiti.
Appendice A.2
Analisi e messa in opera in ambito aziendale del CMMI: - 121 -
sviluppo e gestione dei requisiti.
Appendice A.2
Analisi e messa in opera in ambito aziendale del CMMI: - 122 -
sviluppo e gestione dei requisiti.
Appendice A.2
Analisi e messa in opera in ambito aziendale del CMMI: - 123 -
sviluppo e gestione dei requisiti.
Appendice A.2
Analisi e messa in opera in ambito aziendale del CMMI: - 124 -
sviluppo e gestione dei requisiti.
Appendice A.2
Analisi e messa in opera in ambito aziendale del CMMI: - 125 -
sviluppo e gestione dei requisiti.
Appendice A.2
Analisi e messa in opera in ambito aziendale del CMMI: - 126 -
sviluppo e gestione dei requisiti.
Appendice A.2
Analisi e messa in opera in ambito aziendale del CMMI: - 127 -
sviluppo e gestione dei requisiti.
Appendice A.2
Analisi e messa in opera in ambito aziendale del CMMI: - 128 -
sviluppo e gestione dei requisiti.
Appendice A.2
Analisi e messa in opera in ambito aziendale del CMMI: - 129 -
sviluppo e gestione dei requisiti.
Appendice A.2
Analisi e messa in opera in ambito aziendale del CMMI: - 130 -
sviluppo e gestione dei requisiti.
Appendice A.3
Analisi e messa in opera in ambito aziendale del CMMI: - 131 -
sviluppo e gestione dei requisiti.
APPENDICE A.3
Appendice A.3
Analisi e messa in opera in ambito aziendale del CMMI: - 132 -
sviluppo e gestione dei requisiti.
Appendice A.3
Analisi e messa in opera in ambito aziendale del CMMI: - 133 -
sviluppo e gestione dei requisiti.
Appendice A.3
Analisi e messa in opera in ambito aziendale del CMMI: - 134 -
sviluppo e gestione dei requisiti.
Appendice A.3
Analisi e messa in opera in ambito aziendale del CMMI: - 135 -
sviluppo e gestione dei requisiti.
Appendice A.3
Analisi e messa in opera in ambito aziendale del CMMI: - 136 -
sviluppo e gestione dei requisiti.
Appendice A.3
Analisi e messa in opera in ambito aziendale del CMMI: - 137 -
sviluppo e gestione dei requisiti.
Appendice B.1
Analisi e messa in opera in ambito aziendale del CMMI: - 138 -
sviluppo e gestione dei requisiti.
APPENDICE B.1
Appendice B.2
Analisi e messa in opera in ambito aziendale del CMMI: - 139 -
sviluppo e gestione dei requisiti.
APPENDICE B.2
Appendice B.2
Analisi e messa in opera in ambito aziendale del CMMI: - 140 -
sviluppo e gestione dei requisiti.
Appendice B.2
Analisi e messa in opera in ambito aziendale del CMMI: - 141 -
sviluppo e gestione dei requisiti.
Appendice B.2
Analisi e messa in opera in ambito aziendale del CMMI: - 142 -
sviluppo e gestione dei requisiti.
Appendice B.2
Analisi e messa in opera in ambito aziendale del CMMI: - 143 -
sviluppo e gestione dei requisiti.
Appendice B.2
Analisi e messa in opera in ambito aziendale del CMMI: - 144 -
sviluppo e gestione dei requisiti.
Appendice B.3
Analisi e messa in opera in ambito aziendale del CMMI: - 145 -
sviluppo e gestione dei requisiti.
APPENDICE B.3
Appendice B.3
Analisi e messa in opera in ambito aziendale del CMMI: - 146 -
sviluppo e gestione dei requisiti.
Appendice B.3
Analisi e messa in opera in ambito aziendale del CMMI: - 147 -
sviluppo e gestione dei requisiti.
Appendice B.3
Analisi e messa in opera in ambito aziendale del CMMI: - 148 -
sviluppo e gestione dei requisiti.
Appendice B.3
Analisi e messa in opera in ambito aziendale del CMMI: - 149 -
sviluppo e gestione dei requisiti.
Appendice B.3
Analisi e messa in opera in ambito aziendale del CMMI: - 150 -
sviluppo e gestione dei requisiti.
Appendice B.3
Analisi e messa in opera in ambito aziendale del CMMI: - 151 -
sviluppo e gestione dei requisiti.
Indice delle figure
Analisi e messa in opera in ambito aziendale del CMMI: - 152 -
sviluppo e gestione dei requisiti.
INDICE DELLE FIGURE
Figura 1 - Struttura generale del modello CMMI .................................................................... 32
Figura 2 - Aree di processo della categoria Process Management ......................................... 34
Figura 3 - Aree di processo della categoria Project Management .......................................... 35
Figura 4 - Aree di processo della categoria Engineering ......................................................... 36
Figura 5 - Aree di processo della categoria Support .................................................................. 37
Figura 6 - Capability Profile ........................................................................................................ 41
Figura 7 - Struttura della rappresentazione scalare ................................................................... 47
Figura 8 - Aree di processo nella rappresentazione scalare ....................................................... 47
Figura 9 - Aree di processo per maturity level ............................................................................ 48
Figura 10 - Struttura della rappresentazione continua .............................................................. 49
Figura 11 - Aree di processo nella rappresentazione continua .................................................. 50
Figura 12 - Comparazione tra rappresentazione continua e scalare ......................................... 51
Figura 13 - Pratiche Generiche ed Obiettivi Generici ................................................................ 52
Figura 14 - Target Profile ............................................................................................................ 55
Figura 15 - Stima in % delle Pratiche Specifiche soddisfatte per l’area Sviluppo dei Requisiti
....................................................................................................................................................... 79
Figura 16 – Stima in % delle Pratiche Specifiche soddisfatte per l’area Gestione dei Requisiti
....................................................................................................................................................... 88
Figura 16 - Le relazioni tra le Aree di Processo e le Procedure ................................................ 90
Figura 17 - Scheda Progetto ........................................................................................................ 92
Figura 19 – Stima in % delle Pratiche Specifiche soddisfatte per l’area Sviluppo dei Requisiti
prima del nuovo sistema procedurale ........................................................................................ 112
Figura 20 - Stima delle Pratiche Specifiche soddisfatte per l’area Gestione dei Requisiti prima
del nuovo sistema procedurale ................................................................................................... 113
Figura 21 - Stima delle Pratiche Specifiche soddisfatte per l’area Sviluppo dei Requisiti dopo
l’adozione del nuovo sistema procedurale ................................................................................. 114
Figura 22 - Stima delle Pratiche Specifiche soddisfatte per l’area Gestione dei Requisiti dopo
l’adozione del nuovo sistema procedurale ................................................................................. 115
Bibliografia
Analisi e messa in opera in ambito aziendale del CMMI: - 153 -
sviluppo e gestione dei requisiti.
BIBLIOGRAFIA
[1] Software Engineering Institute. CMMI Web Site.
http://www.sei.cmu.edu/cmmi/cmmi.html
[2] CMMI Product Team. CMMI®
for Development, Version 1.2. Pittsburgh, PA: Software
Engineering Institute, Carnegie Mellon University, Agosto 2006.
http://www.sei.cmu.edu/publications/documents/06.reports/06tr008.html
[3] CMMI Product Team. CMMISM
for Systems Engineering/Software
Engineering/Integrated Product and Process Development/Supplier Sourcing, Version
1.1 Continuous Representation. Pittsburgh, PA: Software Engineering Institute, Carnegie
Mellon University, Marzo 2002.
http://www.sei.cmu.edu/publications/documents/02.reports/02tr011.html
[4] G. Magnani. Il CMMI®
(Capability Maturity Model Integration) - La valutazione ed il
miglioramento continuativo dei processi di integrazione di sistema.
[5] E. Viola. CMMI – Capability Maturity Model Integration. Roma, 25 maggio 2005.
http://www.isacaroma.it/html/ArchivioEventi-050525.html
[6] V. Tozzetti. Adozione del CMMI. Roma, 25 maggio 2005.
http://www.isacaroma.it/html/ArchivioEventi-050525.html
[7] M. Minzoni. CMMI - Ottimizzare il processo per migliorare il prodotto. MokaByte n. 90,
Novembre 2004.
http://www.mokabyte.it/2004/11/cmmi.htm
[8] D. L. Gibson, D. R. Goldenson, K. Kost. Performance Results of CMMI-Based Process
Improvement. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon
University, Agosto 2006.
http://www.sei.cmu.edu/publications/documents/06.reports/06tr004.html
[9] Software Engineering Institute. The IDEAL Model.
http://www.sei.cmu.edu/ideal/ideal.html
[10] M. Bolognani. Gestione delle società di software. Napoli: Edizioni Scientifiche Italiane,
2003.
Bibliografia
Analisi e messa in opera in ambito aziendale del CMMI: - 154 -
sviluppo e gestione dei requisiti.
[11] International Organization for Standardization. ISO 9000: Quality management systems –
Fundamentals and vocabulary. 2000.
[12] International Organization for Standardization. ISO 9001: Quality management systems –
Requirements. 2000.
[13] International Organization for Standardization. ISO 9004: Quality management systems
— Guidelines for performance improvements. 2000.
[14] International Organization for Standardization and International Electrotechnical
Commission. ISO/IEC 90003: Software engineering – Guidelines for the application of
ISO 9001:2000 to computer software. 2004.
[15] International Organization for Standardization and International Electrotechnical
Commission. ISO/IEC TR 12207 Information Technology – Software Life Cycle
Processes. 2003.
[16] International Organization for Standardization, International Electrotechnical
Commission. ISO/IEC 9126-1: Software engineering – Product quality – Part 1: Quality
model. 2001.
[17] North Atlantic Treaty Organization. AQAP-160 (Edition 1): NATO Integrated Quality
Requirements for Software throughout the Life Cycle. 2001.
[18] Department of Defence of United States of America. MIL-STD-498: Software
Development and Documentation. 1994.
http://www2.umassd.edu/swpi/dod/mil-std-498/498-std.pdf
[19] European Cooperation for Space Standardization. ECSS Web Site. ECSS-P-00A
(“Standardization policy”)
http://www.ecss.nl