Approccio al miglioramento

L'approccio  al miglioramento continuo, nell'ambito dello sviluppo software, è conosciuto come "Software Process Improvement" (SPI). L'approccio SPI è ricco di modelli di maturità che indirizzano specifiche aree di interesse: i processi (CMMI), il testing (TMMi), le competenze (SWEBOK), l'organizzazione (P-CCMI) ecc.

Questi modelli creano spesso "confusione" in chi ha problemi di sopravivenza e ha poco tempo e risorse per affrontare il tema in maniera strutturata! Si tenta qui di fare un po' di chiarezza e proponendo una soluzione già sperimentata, basata sulle migliori pratiche disponibili (CMMI e Best Practice).

La metodologia proposta è semplice ed efficace, ma richiede coerenza e disciplina, impegno da parte di tutta l'organizzazione: direzione e staff tecnico.

La sua validità è stata sperimentata presso un gruppo di piccole e medie aziende di software italiane che ha adottato l'approccio metodologico in tutti i suoi componenti. La soluzione proposta vede lo sviluppo contemporaneo e sinergico di tre elementi:

• Competenze professionali. Consiste nello sviluppo delle professionalità in azienda tramite la definizione dei ruoli, delle relative responsabilità e delle competenze necessarie - tecniche e professionali -, l'acquisizione di esperienza pratica, la formazione continua e la certificazione (se richiesta).

• Processi maturi. Si tratta di migliorare i processi produttivi e gestionali adottando il modello proposto dal nuovo standard ISO/IEC 29110 Software Engineering for VSE appositamente disegnato per le piccole realtà produttive e arricchendolo delle Best Practice disponibili. Esso accorpa anche il processo di Project Management semplificato per le piccole organizzazioni. Per quanto riguarda l'attività di test e collaudo si fa riferimento all'altro standard recentemente pubblicato sull'argomento: ISO/IEC 29119 Software Testing.

• Strumenti a supporto. Richiede la scelta e l'utilizzo sistematico di metodi e tecniche, metriche e strumenti a supporto che aumentino la produttività e migliorino la qualità. Include la definizione di modelli per la produzione della documentazione di prodotto e di progetto (deliverable).

Modello concettuale

La soluzione proposta è rappresentata graficamente nella figura che segue da un tavolo che regge il software sviluppato.

Figura: Rappresentazione della metodologia proposta

Le tre gambe (competenze, processi, strumenti) reggono il piano orizzontale (l'organizzazione) su cui poggia il prodotto sviluppato. Le gambe del tavolo sono quindi di uguale altezza e di robustezza adeguata per sostenere un piano stabile e reggere la complessità del prodotto.

L'altezza del tavolo rappresenta il livello di maturità dell'organizzazione. La robustezza delle gambe è quindi proporzionale all'altezza del tavolo e al peso del prodotto da sostenere.

Il tutto poggia sul pavimento costituito dall'infrastruttura tecnologica adeguata.

La qualità del prodotto software, in ultima sintesi, e la sua complessità possono essere sviluppate quando l'organizzazione abbia raggiunto un livello di maturità adeguato alla sfida. Livello di maturità raggiunto con competenze, processi e strumenti adeguati, consistenti e sostenibili. L'infrastruttura tecnologica costituisce il linguaggio comune utilizzato per adeguarsi al mercato.

Una prima osservazione riguarda l'aspetto cui buona parte delle aziende focalizza l'attenzione e gli investimenti: esso riguarda solo, o in massima parte, gli aspetti tecnologici, trascurando l'approccio alla qualità che poggia sulle tre gambe. Il risultato non potrà che essere modesto: la tecnologia è solo la base su cui costruire la solidità dell'impresa.

Soluzione proposta

La metodologia proposta è particolarmente adatta alle imprese di piccole e medie dimensioni. Essa prevede:

Ciclo di vita - Il ciclo di vita è di tipo "iterativo - incrementale" che prevede rilasci successivi ciascuno sviluppato in modo iterativo in modo da indirizzare, quando necessario, eventuali indeterminazioni nella definizione dei requisiti.

Approccio - L'approccio adoperato è strutturato e pragmatico: non burocratico ma conciso e severo! Delle metodologie "agili" si è preso il concetto generale del modello "SCRUM" ed alcune sue tecniche redditizie ("time boxing", "test driven development" ecc.).

Processo - Il processo, derivato dall'UP (Unified Process), è aderente alla norma ISO/IEC 29110 Software Engineering for VSE, disegnato per le piccole organizzazioni (fino a 25 persone), anche se l'esperienza suggerisce di poterlo adottare con successo anche in organizzazioni di dimensioni superiori. Il processo include la parte di gestione del progetto di sviluppo (Project Management). L'attività di test e collaudo segue quanto suggerito dal recente standard ISO/IEC 29119 Software Testing e include sia il test statico (ispezioni) sia quello dinamico (testing vero e proprio).

Best Practice - Le migliori pratiche disponibili sono prese in prestito dal modello di maturità CMMI e vengono descritte nell'apposita sezione di questo sito (Best practice del software).

Project Management - La gestione del progetto segue il processo definito dalla norma ISO/IEC 29110 Software Engineering for VSE e include quanto di meglio suggerito dal PMBOK.

Competenze - La soluzione definisce ruoli, responsabilità e competenze partendo dal modello definito nel SWEBOK (Software Engineering Body of Knowledge), opportunamente semplificato per le piccole e medie organizzazioni.

Modelli (template) - La metodologia fornisce i modelli per la produzione dei documenti necessari (piano di progetto, piano della qualità, piano di test, documento dei requisiti, specifiche funzionali e/o casi d'uso, casi di test, rapporti vari (stato del progetto, completamento dei test, disponibilità al collaudo, verbale di collaudo, richiesta di passaggio in esercizio, lista di elementi passati in esercizio, manuale utente e d'installazione ecc.).

Metodi e tecniche - Sono incluse le tecniche più efficaci e semplici (profilo della qualità del software, Kit di ispezione, matrice biunivoca dei requisiti-test, standard di progettazione e di programmazione, tecniche di integrazione e di test ecc.).  

Metriche del software - Le metriche del software proposte servono a misurare i diversi elementi che caratterizzano tale attività: il prodotto, il progetto e il processo. Misurare serve a migliorare: valutare dove siamo (produttività, qualità del prodotto, efficacia del progetto, efficienza del processo), stabilire l'obiettivo (target) e valutare il miglioramento.

Strumenti - L'utilizzo di strumenti è reso semplice dalla selezione di tool, metriche e modelli (template) disponibili e semplificati. Tra gli strumenti selezionati/suggeriti (tool) non possono mancare quelli dedicati alla gestione dei requisiti, delle richieste di intervento, delle anomalie, dei casi di test, della documentazione, della configurazione.

In sintesi, nulla di veramente nuovo; solo pratiche consolidate. L'innovazione consiste nell'aver adattato tali pratiche ad un ambiente reale italiano di medie e piccole dimensioni, provato su di un campione significativo di aziende e aggiornato in base ai risultati.

Guida all'introduzione della metodologia nelle organizzazioni

L'adozione di una metodologia in azienda non è mai semplice né indolore. Specialmente quando il salto qualitativo è di grande significato. Occorre modificare la cultura, l'approccio mentale, il modo di lavorare, prestare più attenzione a nuovi aspetti e tralasciare vecchie abitudini. La resistenza al cambiamento è un tema con cui confrontarsi e gestirla opportunamente.

L'approccio suggerito è quello, già menzionato, dei piccoli passi ma continui. Il livello di dettaglio cui giungere nella descrizione di un processo dipende dal livello culturale dell'ambiente cui è dedicato. La descrizione del processo di sviluppo e dei relativi metodi e delle tecniche utilizzati ha un doppio scopo: costituire una base di consultazione per innalzare il livello culturale dell'organizzazione nel suo complesso, rappresentare un base di partenza (baseline) su cui effettuare i miglioramenti successivi.

La documentazione della metodologia, quando sintetica e aderente alla realtà aziendale, rappresenta un patrimonio di grande valore, un asset da utilizzare nello svolgimento delle attività quotidiane.

Senza giungere a dettagli minuziosi, ciascuna fase è descritta almeno in termini di:

• Criteri di attivazione e di uscita della fase (Entry and Exit Criteria);

• Prodotti di fase realizzati (Deliverable);

• Attività svolte;

• Controlli e verifiche eseguiti;

• Ruoli coinvolti;

• Metodi, tecniche e strumenti adoperati;

• Metriche di prodotto e di processo adoperate;

• Evidenze prodotte (anche ai fini della certificazione ISO 9001).

La descrizione di ciascuna fase si riferisce al "cosa fare" e al "chi lo fa". Il "come fare" è invece demandato al terzo pilastro della metodologia di sviluppo: metodi, tecniche e strumenti.