ANALISI E MESSA IN OPERA IN AMBITO AZIENDALE...

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



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



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à



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,




– 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:




- 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




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;




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 è




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;




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

http://www.sincert.it/

http://www.cisq.com/




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.

http://www.iqnet-certification.com/

http://www.iqnet-certification.com/

http://www.iaf.nu/

http://www.european-accreditation.org/




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.




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;




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.




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;




- 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.




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




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




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;




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;




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




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.




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




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);




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




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

http://www.sei.cmu.edu/




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

http://www.sei.cmu.edu/cmmi/results.html




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




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



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:




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.




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.




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.





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.




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:


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




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:


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




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.




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.




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.




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.




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




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




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.




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.




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.




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




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.




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




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.




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.




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




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



maturity level 2, 3 e 4 devono raggiungere il livello di capability 3 (entrambe le






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.




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



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.




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




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).




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’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.




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).




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



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




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;




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:




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




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.




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à




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

.




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

.




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.




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.




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.

.




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.




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

.




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




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

.




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:




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



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.




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.




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

-mail

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

.




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.




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




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.




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.




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:




82,35% 5,880%

11,76%

Soddisfatte


Non Soddisfatte

Figura 5 – Stima in % delle Pratiche Specifiche soddisfatte per l’area Gestione dei Requisiti

Progettazione del nuovo sistema procedurale



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




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.




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.




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




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




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.




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à




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




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)




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)




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




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)




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)




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)




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)




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

.




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)




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




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




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)




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)




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




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



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


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



82,35% 5,880%

11,76%

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



100%

0,00%

0,000%

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



100%

0,00%

0,000%

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



APPENDICE A.1

Appendice A.2



APPENDICE A.2

Appendice A.2



Appendice A.3



APPENDICE A.3

Appendice A.3



Appendice B.1



APPENDICE B.1

Appendice B.2



APPENDICE B.2

Appendice B.2



Appendice B.3



APPENDICE B.3

Appendice B.3



Indice delle figure



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



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.


[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.


[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.


[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.

http://www.sei.cmu.edu/cmmi/cmmi.html






http://www.mokabyte.it/2004/11/cmmi.htm


http://www.sei.cmu.edu/ideal/ideal.html

Bibliografia



[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

http://www2.umassd.edu/swpi/dod/mil-std-498/498-std.pdf

http://www.ecss.nl/

ANALISI E MESSA IN OPERA IN AMBITO AZIENDALE...

Documents

Transcript of ANALISI E MESSA IN OPERA IN AMBITO AZIENDALE...