Il processo software

Il processo definisce una cornice per un insieme di aree chiave (KPA Key Process Areas). Le KPA formano la base del controllo gestionale dei progetti software e stabiliscono il contesto in cui si applicano i metodi tecnici, si creano i prodotti intermedi (modelli, documenti, dati, resoconti, formulari e così via), si stabiliscono i punti di controllo (milestone), si garantisce la qualità e si governano in modo opportuno le modifiche .
La maggior parte dei modelli di ciclo di vita del software prevedono una scomposizione del processo di sviluppo in insiemi di attività simili (quando non addirittura identici). La maggior parte delle distinzioni fra diversi cicli di vita verte infatti su altri aspetti, quali:
• l’enfasi relativa che si attribuisce a ciascuna attività.
• l’individuazione degli attori specifici incaricati di ciascuna attività.
• l’ordine in cui le attività si svolgono.

Si istituisce un quadro di riferimento generale del processo, definendo un piccolo numero di attività portanti, comuni a qualsiasi progetto software, quale che sia la sua dimensione e complessità. Una serie di insiemi di compiti consente di adattare le attività portanti alle caratteristiche del progetto software e alle esigenze del team di progetto. Infine le attività ausiliarie (come la garanzia di qualità del software – SQA, la gestione delle configurazioni software e le misurazioni) si sovrappongono al modello di processo. Queste attività sono indipendenti dalle attività portanti e coprono l’intero arco del processo.
Negli ultimi anni si è molto insistito sulla maturità del processo. Il SEI (Software Engineering Institute) ha ideato un modello complessivo, fondato su un insieme di capacità corrispondenti a diversi gradi di maturità di processo di un’azienda. Per determinare il livello di maturità il SEI ricorre a un questionario e a uno schema valutativo a cinque livelli. Il voto finale corrisponde al grado di conformità a un modello di maturità delle capacità (CMM, Capacity Maturity Model), dove sono definite le attività richieste ad ogni livello.
I cinque livelli di maturità sono definiti come segue:
Livello 1: Iniziale. Il processo software è definito di volta in volta e in alcuni casi risulta confuso. Pochi processi sono definiti e la riuscita dipende dall’impegno individuale.
Livello 2: Ripetibile. Presenza di processi basilari di gestione dei progetti, volti a sorvegliare i costi, tempi e funzionalità. La disciplina di processo necessaria ha lo scopo di ripetere il successo di progetti precedenti per applicazioni simili.
Livello 3: Definito. Il processo software, sia per le attività di gestione sia per quelle di realizzazione, è documentato, conforme a uno standard e inserito in un processo software su scala aziendale. Ogni progetto adotta una versione documentata e approvata del processo aziendale per lo sviluppo e la manutenzione del software. Questo livello comprende tutte le caratteristiche definite per il livello 2.
Livello 4: Gestito. Si raccolgono misure dettagliate relative al processo software e alla qualità del prodotto. Sia il processo software sia i prodotti sono valutati quantitativamente e controllati mediante misure dettagliate. Questo livello comprende tutte le caratteristiche definite per il livello 3.
Livello 5: Ottimizzato. Il continuo miglioramento del processo è consentito dalla raccolta di dati quantitativi e dal collaudo di idee e tecnologie innovative. Questo livello comprende tutte le caratteristiche definite per il livello 4.
Il SEI ha associato a ogni livello di maturità alcune aree chiave di processo (KPA). Le KPA descrivono le funzioni (ad esempio pianificazione del progetto software, gestione dei requisiti) che devono essere presenti per garantire un certo livello. Ogni KPA è descritta rispetto alle seguenti caratteristiche.
• Scopi: gli scopi complessivi che la KPA deve raggiungere.
• Impegni: i requisiti (imposti dall’organizzazione) che si devono soddisfare per raggiungere gli scopi che comprovano l’intenzione di adeguarsi a questi ultimi.
• Capacità: tutto ciò che deve essere predisposto (tecnicamente e organizzativamente) per consentire il rispetto degli impegni.
• Attività: i compiti specifici necessari per assolvere la funzione della KPA.
• Metodi di sorveglianza della realizzazione: il metodo in cui verificare la correttezza della applicazione della KPA.
Nel modello di maturità sono definite 18 KPA (ciascuna descritta usando queste caratteristiche), assegnate a diversi livelli di maturità. Eccone l’elenco, ripartito fra i livelli.

Livello 2
• Gestione delle configurazioni software.
• Garanzia di qualità del software.
• Gestione dei sottocontratti per il software.
• Controllo e sorveglianza del progetto.
• Pianificazione del progetto.
• Gestione dei requisiti.

Livello 3
• Revisioni.
• Coordinamento dei gruppi.
• Ingegneria del prodotto software.
• Gestione integrata del software.
• Programmi di addestramento.
• Definizione del processo aziendale.
• Obiettivo primario del processo aziendale.

Livello 4
• Gestione della qualità software.
• Gestione quantitativa del processo.

Livello 5
• Gestione del cambiamento nel processo.
• Gestione del cambiamento tecnologico.
• Prevenzione dei difetti.

Ogni KPA è definita come una serie di pratiche chiave che contribuiscono a raggiungere lo scopo. Le pratiche chiave sono politiche, procedure e attività che si devono mettere in pratica prima che una KPA sia pienamente stabilita. Il SEI definisce così gli indicatori chiave: “quelle pratiche o componenti di pratiche chiave che meglio permettono di stabilire se gli scopi di una KPA sono stati raggiunti”. Per sondare l’esistenza o l’assenza di un indicatore chiave si ricorre ad opportune domande.
IL CMM tuttavia è stato abbandonato dal SEI in favore di un nuovo modello, il CMMI (Capacity Maturità Model Integration). Il CMM è stato sviluppato dal 1987 al 1997. Nel 2002 fu rilasciata la versione 1.1 del CMMI, seguita dalla 1.2 nell’agosto 2006. Il CMMI è un framework metodologico integrato di modelli CMM; si propone di integrare i molteplici modelli CMM sviluppati per settore e comparto industriale, al prezzo di una maggiore generalità.
Il CMMI / MOI è un modello che indica ventidue KPA strutturate su cinque livelli, ognuna con i propri obiettivi generici (Generic Goal) e specifici (Specific Goal). Gli obiettivi generici e specifici sono implementati da una sequenza temporale di attività generiche (Generic practice) e specifiche (specific practice), che hanno determinate tipologie di output (tipical work product).
A loro volta, le attività vengono in alcuni casi dettagliate in una sequenza di secondo livello di sub-attività generiche (generic sub-practice) e specifiche (specific sub-practice).
La generica azienda deve classificare i suoi processi secondo le Process Area indicate nel CMMI per condurre un’analisi dei gap fra la situazione attuale e il “to-be” indicato.
Il SEI ha rilasciato la certificazione CMMI ai processi di una ventina di aziende in tutto il mondo. Si tratta di aziende informatiche delle quali sono stati certificati i processi di ingegneria del software. In Italia ha ottenuto la cettificazione CMMI la sola IBM. Al momento non esistono autority indipendenti autorizzate a certificare i processi di altre aziende secondo il CMMI, e la valutazione è effettuata direttamente dal SEI.
L’elenco completo delle KPA di CMMI è il seguente:
CAR – Causal Analysis and Resolution
CM – Configuration Management
DAR – Decision Analysis and Resolution
IPM – Integrated Project Management +IPPD
MA – Measurement and Analysis
OID – Organizational Innovation and Deployment
OPD – Organizational Process Definition +IPPD
OPF – Organizational Process Focus
OPP – Organizational Process Performance
OT – Organizational Training
PI – Product Integration
PMC – Project Monitoring and Control
PP – Project Planning
PPQA – Process and Product Quality Assurance
QPM – Quantitative Project Management
RD – Requirements Development
REQM – Requirements Management
RSKM – Risk Management
SAM – Supplier Agreement Management
TS – Technical Solution
VAL – Validation
VER – Verification