Reiterative project life cycle per la qualità del software

di A. Autino - Andromeda s.r.l.

 La situazione del mercato del software a livello internazionale si presenta differenziata, per quanto sia sempre arbitrario parlare globalmente di software, senza distinguere almeno tra le sue principali componenti: gestionale, telecomunicazioni, automazione e controllo di processo. Questo articolo non ha la pretesa di analizzare la situazione di mercato in dettaglio, poiché mi sono sufficienti pochi dati generali esemplificativi, per motivare le tesi e le proposte che andrò ad esporre. Partire dal mercato è comunque d’obbligo, poiché nessuno, in particolare di questi tempi di vacche non certo grasse, può permettersi di investire tempo e denaro alla cieca, senza essere certo di acquistare valore, ben superiore all’investimento.

Dopo i disastri seguiti all’esplosione delle bolle speculative della new economy, all’11 settembre ed alla conseguente ulteriore restrizione dei mercati mondiali, e nonostante le tempeste attuali dovute alla globalizzazione ed alla crescente presenza asiatica sui mercati, assistiamo ad una discreta e costante ripresa del mercato ICT USA, seguita da una più modesta ma significativa ripresa del mercato Nord Europeo. L’Italia viene buona ultima, a parecchie lunghezze. Per noi il 2003 sembra essere stato l’anno peggiore, con un deciso calo del mercato (–5%). Il 2004 ha visto perlomeno il ritorno a zero, e per il 2005 i commentatori sperano in un segno positivo, anche se debole.

Il dato più preoccupante, su cui occorre riflettere seriamente, è quello delle esportazioni: il tasso di esportazione del comparto software Italiano è vicino allo 0%. Questo dato deve far riflettere non solo coloro che intendono internazionalizzare la propria presenza sul mercato, ma anche coloro che intendono limitarsi a conservare o estendere la loro presenza sul mercato nazionale. Nel nostro Paese arriva, infatti, software dall’estero (in particolare US) in grande quantità: se la nostra credibilità sul mercato dovesse scendere ulteriormente, tale tendenza potrebbe incrementarsi. Già l’introduzione in Italia di sistemi gestionali come SAP ha ridotto considerevolmente il mercato per i piccoli produttori. La caduta del gestionale nazionale si tira dietro inevitabilmente una caduta di tutto il comparto software, benché alcune branche (es. automazione) seguano dinamiche parzialmente diverse e cicli a se stanti. La caduta di un settore importante dell’ICT è causa di riversamento sul mercato di softwaristi in cerca di consulenze, con conseguente caduta libera delle tariffe dei servizi professionali e comunque del valore dell’ora di sviluppo software o di ingegneria in tutti i settori. Non c’è quindi alcuna possibilità (ammesso e non concesso che qualche settore software fosse meno in crisi), di avere atteggiamenti don’t care, come se la crisi del nostro vicino non ci riguardasse, e potessimo disinteressarcene. Occorre pensare alle sorti del comparto software Italiano, in generale, perché la cosa ci riguarda tutti, e se per ora non riguarda qualcuno, presto arriverà a toccare anche questo qualcuno, se non saremo in grado di invertire la tendenza. In questo malaugurato caso, non solo il nostro comparto di produzione software non sarà in grado di seguire eventuali trend positivi – ammesso che continuino e si consolidino – ma assisteremo al declino della nostra progettazione, pur in presenza di trend positivi del mercato, dei quali non saremo più noi ad approfittare!

Diciamo subito che non è facile invertire la tendenza, perché questa volta non si tratta solo di tirarsi su le maniche, stringere i denti e rifocalizzarsi meglio sulle esigenze degli utenti. Si tratta certamente di fare questo, ma anche, e soprattutto, di prendere coscienza che dobbiamo superare un gap culturale. Che più passa il tempo, più diventa alto e difficile. Il settore software Italiano rappresenta, infatti, un caso molto peculiare, nel panorama planetario.

Diamo un’occhiata a cosa succede nel resto del mondo, poi cercheremo di capire dove siamo noi (maggioranza dei softwaristi Italiani) in relazione a tali processi. In questo, forse (almeno chi è in grado di accorgersene), siamo un po’ aiutati dalla nostra utenza: dalle ultime ricerche di mercato risulta infatti che l’utente Italiano medio-grande di Information Technology assegna la priorità più alta al miglioramento dei processi; in seconda posizione la razionalizzazione dei costi (notare: seconda, e non prima!); e, da ultimo, l’aumento della quota di mercato. Prima lezione di umiltà, quindi, per noi softwaristi, che siamo abituati da trent’anni a crederci i primi della classe, ed in grado sempre e comunque di insegnare (organizzazione, razionalizzazione, ecc…) agli altri. Se la nostra utenza si rende conto di aver bisogno di migliorare e razionalizzare i processi produttivi, per reggere la concorrenza, chi siamo noi (softwaristi) per ritenerci tanto al di sopra? Proprio la genialità e la creatività della nostra ingegneria di progetto – che in passato l’ha portata ai primi posti sulla scena mondiale, non nel campo del software, ma ad esempio nel settore macro-infrastrutturale ed in quello navale – finisce col costituire il nostro handicap più pesante e difficile da superare, mentre il resto del mondo si avvia alla maturità metodologica. E noi non ci rendiamo nemmeno conto che, in tale contesto, non solo non siamo i primi della classe, ma rischiamo di finire buoni ultimi, superati alla grande da squadre più umili (perché partite da posizioni più arretrate), che non hanno la puzza sotto il naso nei confronti delle metodologie. Complice di questo stato di cose è anche un’informazione giornalistica chiusa e provinciale, incapace di estendere il proprio raggio d’indagine almeno a livello europeo, e che nasconde la realtà al grande pubblico Italiano. Così noi continuiamo a vivere nell’illusione che la nostra immagine all’estero sia quella di un popolo geniale e creativo, mentre i manager europei di tutti i settori high tech (e non solo) ci considerano nel migliore dei casi dei pasticcioni furbetti, del tutto indegni di qualsiasi fiducia, soprattutto nella gestione di progetto. I dati che testimoniano questo stato di cose sono sotto gli occhi di tutti, ma non vengono analizzati, o ne viene data una spiegazione diversa. Basterebbe guardare dove vanno i contratti importanti dell’Agenzia Spaziale Europea, e chi sono i main contractor, aldilà del gioco dei ritorni sui diversi paesi aderenti all’agenzia, che comunque deve assegnare qualche commessa a tutti. Complice un giornalismo pietoso o codardo (o ambedue), noi continuiamo a nascondere la testa nella sabbia, ed a dormire sugli allori. Consiglio, a chi non intende svegliarsi, di non proseguire nella lettura di questo articolo.

Secondo il Capability Maturity Model, cui tutto il mondo ormai fa riferimento (mentre in Italia è pressochè sconosciuto), la stragrande maggioranza delle aziende Italiane di software si trova al livello uno: quello in cui l’esito del progetto è lasciato alle capacità ed alla buona volontà dei singoli progettisti, le esperienze positive non sono ripetibili, e si è del tutto incapaci di analizzare le cause di quelle negative. Una piccola minoranza si trova a livello due, quello in cui la qualità è portata come un macigno sulle spalle, raddoppiando i costi di progettazione e producendo una valanga di carta, che già al 70% di sviluppo del progetto è obsoleta, e non servirà più a nulla quando si dovrà fare manutenzione. Questa minoranza è quella abituata ad utilizzare metodologie di qualità, poiché opera nel settore aerospaziale e/o in quello della difesa. Anche qui però non ci si è posti il problema di migliorare l’uso delle metodologie, fino a farne strumenti di maggior efficienza (anziché di rigonfiamento dei costi): potendo godere di un budget dedicato alla qualità, queste organizzazioni hanno piuttosto tollerato la nascita di una sorta di casta burocratica della qualità, che parla un proprio gergo incomprensibile ai più, avulsa dai gruppi di progetto, ed assolutamente incapace di portare un vero contributo alla qualità sostanziale dei prodotti (affidabilità, sicurezza, manutenibilità, ecc…). Ciò è accaduto, ad onor del vero, non solo nel nostro Paese. Gli standard sono cresciuti in modo autoreferenziale, andando sempre più a differenziarsi, anziché razionalizzarsi, semplificare. Anziché puntare all’essenziale della qualità. Tutto questo non ha certamente aumentato l’appeal delle metodologie di qualità, verso progettisti e manager. Al contrario, ha funzionato come un potente dissuasore: perché spendere molti soldi per scrivere carta che poi risulterà del tutto inutile?

Le software house sono tornate (se mai se ne erano distaccate) alla vecchia pratica degli inizi: poche pagine di specifiche, nessun tracciamento dei requisiti di sistema verso quelli utente, nessuna formalizzazione delle procedure di test, nessuna annotazione dei problemi (e quindi anche nessuna capitalizzazione delle soluzioni). Mentre il resto del mondo impara ad andare all’essenziale della qualità – traendo dalle metodologie ciò che veramente ha importanza – noi andiamo in direzione completamente opposta. In questo contesto, neppure i progettisti bravi riescono più a lavorare bene, perché vengono sempre più caricati di scadenze impossibili e pagati sempre meno. Dove tutto questo ci porti (e penso anche all’utenza, in particolare in quei settori in cui affidabilità e sicurezza avrebbero un’importanza primaria), è abbastanza facile intuirlo: ad una situazione in cui i softwaristi Italiani non scriveranno più una riga di software, perché altri lo faranno di gran lunga meglio e, se non a prezzo inferiore, perlomeno a prezzo certo (livello quattro del CMM, quello in cui si è capaci di mantenere le stime).

Sarebbe, ora, assurdo che io avessi tracciato questo quadro a tinte parecchio fosche, senza avere una proposta! La mia è innanzi tutto una proposta di crescita culturale, e di maturità.

Dobbiamo in primo luogo renderci conto che quasi tutto ciò che sappiamo, in fatto di gestione del ciclo di vita e dei processi di progettazione potrebbe essere sbagliato, o, nella migliore delle ipotesi, è certamente obsoleto. Quello che ci sta di fronte è quindi un completo cambio di paradigma. Sono altresì convinto che, identificando gli opportuni percorsi di crescita, e grazie alla nostra genialità e creatività (che pure esistono, altrimenti saremmo già scivolati da tempo fuori dal mercato high-tech!), possiamo raggiungere rapidamente posizioni primarie: perché mai un mercato internazionale che accetta i prodotti Indiani (sia chiaro che personalmente nutro un assoluto rispetto ed ammirazione per le capacità culturali e filosofiche di quel popolo) dovrebbe continuare a rifiutare il software made in Italy, se questo diventasse qualitativamente appetibile? Chi pensa di poter continuare come se niente fosse, è destinato ad uscire anche dal mercato nazionale, senza neanche capire perché, se non quando sarà ormai troppo tardi.

Occorre prendere atto che ormai esistono metodologie essenziali, sfrondate di tutti i fronzoli e gli orpelli cui ci avevano abituati i qualitocrati di qualche anno o decennio fa. Inoltre dobbiamo renderci conto che, per poter passare dal livello due del CMM al livello tre (quello in cui si trasforma la qualità da un macigno in un motorino di efficienza), occorre ricorrere a strumenti informatici, ed in particolare a strumenti basati su database relazionali. Nulla di strano ed incomprensibile, per degli informatici: quasi un uovo di Colombo. Come ci viene in aiuto l’informatica, per migliorare i processi di progettazione? È semplice: ci minimizza il tempo di analisi e gestione delle change in corso d’opera, che sono il vero problema della gestione del ciclo di vita dei progetti. Mi spiego meglio.

Il modello classico del Project Life Cycle (vedi Figura 1), a differenza del precedente modello cosiddetto waterfall, è perlomeno corretto, dal punto di vista teorico. Infatti, tutte le attività di test sono riferite a requisiti definiti in fase di requirements engineering. Invece nel modello waterfall le attività erano tutte in cascata, senza alcun riferimento tra le procedure di test ed i requisiti da testare. Scrivere procedure di test senza riferirle a requisiti, equivale a non scriverle affatto, una pura perdita di tempo: chi, ancora oggi, non formalizza le procedure di test, di fatto si attiene, con trent’anni di ritardo, ad un embrionale modello waterfall, con tutti i guai connessi, di cui il rischio di incompletezza dei test è solo il più macroscopico ed evidente.

Tuttavia, in questi anni d’intensa progettazione, ci si è via via resi conto (ma questa consapevolezza non è ancora molto diffusa), che il modello del Life Cycle, seppur corretto in teoria, non si rivela rispondente alla pratica corrente della progettazione. O meglio, il modello non è di fatto applicabile su tutto il ciclo di vita del progetto, se si gestisce la qualità con strumenti statici (carta, word processor, fogli elettronici di calcolo), poiché le attività di riesame e revisione della documentazione risultano di fatto insostenibili per qualsiasi economia di commessa. Facciamo caso ai circolini rossi, che ho messo sulla figura. Il primo, a valle della definizione dei requisiti di sistema, rappresenta una design review, fatta con il cliente: il cliente legge la nostra documentazione, e ci fa i suoi commenti. Noi procediamo ad un primo riesame della documentazione, e la modifichiamo secondo quanto espresso dal cliente: i documenti sono ancora pochi, il budget di progetto è stato speso forse al 20% o meno, e non siamo ancora in ritardo sulle milestone di consegna/fatturazione. Il gestore di commessa non ha nulla in contrario a che si modifichi la documentazione. Poi procediamo con il disegno architetturale, di dettaglio e lo sviluppo, e cominciamo a testare.

Arriviamo ad un factory test (o shop test) in simulazione, alla presenza del cliente, che ci farà ancora più commenti, visto che adesso può toccare con mano un primo prototipo. Dovremmo modificare la documentazione, e ripercorrere tutto il ciclo. Ma, a questo punto, il 70% del budget è stato speso, e probabilmente siamo già in ritardo, se non già in emergenza! Di modificare la documentazione non se ne parla, perché costerebbe troppo, in termini di tempo: riaprire qualche centinaio di documenti uno per uno, vedere dove impatta la modifica, aggiungere/modificare requisiti e test, riformattare, riemettere i documenti, sono tutte attività che richiedono giorni e giorni di lavoro. Ed il project manager non se la sente di spenderli. Quindi si punta all’apparentemente essenziale: si modifica il sistema, rimandando ad un inesistente poi l’aggiornamento della documentazione. Lo stesso, e sempre peggio, succede durante il commissioning, e poi durante l’accettazione finale, quando il budget è finito da tempo, e l’unica preoccupazione è limitare le perdite. La documentazione è quindi costata molto, alla fine del progetto non è aggiornata, e quindi, quando qualche anno dopo dovremo manutenere o espandere il sistema, dovremo ricorrere a tecniche di reverse engineering.

Lavorare secondo quello che ho definito Reiterative Project Life Cycle, mantenendo costantemente aggiornata la documentazione fino alla fine del progetto ed oltre è, da un punto vista metodologico, molto più maturo, rispetto all’abbandono della documentazione, come un cane, per la strada!

La documentazione, se dinamica, online, ci servirà costantemente, per tutto il progetto ed anche dopo, durante la vita operativa del sistema, come una mappa d’incomparabile utilità, sia per la qualità tecnica del sistema, sia per la miglior gestione delle commesse legate al progetto. Infatti, un sistema di gestione del ciclo di vita ci fornisce anche strumenti per misurare, in ogni momento, esattamente, dove siamo arrivati e quanto ci manca a finire. Integrato con strumenti di gestione di commessa (economia /risorse /schedulazione attività), ci permette di acquisire un controllo totale della commessa, e quindi di diventare presto capaci di fare stime più accurate e di mantenerle (livello quattro del CMM) e di puntare al miglioramento continuo (livello cinque). Per esperienza, mia e di pochi clienti, già dotati di strumenti di gestione del life cycle, è possibile rispettare le scadenze di progetto, produrre una documentazione eccellente, e diminuire i costi di progettazione, rispetto ad un qualsiasi processo non metodologico, e non solo rispetto a metodologie cartacee.

Uno strumento adeguato deve basarsi su database relazionale, e gestire tutti gli aspetti e/o fasi del ciclo di vita: requisiti, disegno architetturale, procedure di test, esecuzione dei test con annotazione dei problemi, archivio dati di ingresso/uscita o delle variabili/database di sistema, documenti, sicurezza dati e profili di accesso/privilegio. Deve essere gestito automaticamente il tracciamento dei requisiti figli verso i padri, dei test verso i requisiti coperti, dei problemi verso i test e verso i requisiti violati, e deve essere prodotta in automatico tutta la documentazione di qualità, già formattata. Non servono ulteriori spiegazioni (a dei softwaristi), per chiarire le quantità enormi di tempo che un tale sistema può fare risparmiare, soprattutto nel valutare l’impatto delle change e nella riemissione dei documenti a valle delle modifiche: il database relazionale ci da’ chiavi di ricerca che ci permettono di estrarre i requisiti ed i test impattati dalle modifiche in pochi secondi, invece di dover rileggere ogni volta tanti documenti. E tutto il resto di conseguenza. Pensate al tempo risparmiato ed all’enorme miglioramento nella gestione dei problemi riscontrati, che non vengono più persi per strada, e con loro la motivazione e la traccia delle modifiche via via apportate. Pensate cosa vuol dire avere un documento di procedura di test prodotto (e riprodotto tutte le volte che serve) automaticamente dal sistema, anziché dover perdere tempo con i word processor, a riformattare manualmente tabelline, font, liste puntate, ecc… Ed a cosa vuol dire avere matrici di tracciabilità prodotte (e riprodotte) in automatico. L’utilità di una matrice di tracciabilità, se affidabile, è evidente, soprattutto per quanto riguarda l’implementazione di modifiche: bene, se la matrice è informatica, e non cartacea, e tutte le modifiche vengono fatte alla fonte, nel database, tutto il resto viene automaticamente, di conseguenza, con enorme risparmio di tempo, e quindi la matrice è sempre aggiornata, cioè affidabile.

Per quanto riguarda l’aspetto education, per chi produce software, due sono le norme ISO che vale la pena di approfondire. La prima è la ISO-12207, che definisce il Project Life Cycle. Le principali differenze fra ISO 9001 e ISO 12207 riguardano soprattutto l’ambito e le modalità di applicazione: mentre la ISO 9001 è applicabile ad organizzazioni di qualsiasi genere, ISO 12207 si applica in particolare ad organizzazioni di produzione e servizi software, concentrandosi sul ciclo di vita del software. ISO 12207 si occupa di tutte le attività del ciclo di vita del software, sia gestionali sia tecniche, ed è utilizzata per acquisire, fornire, sviluppare, utilizzare e mantenere un prodotto software. La seconda è la ISO15504 (la traduzione ISO dell’americano CMM), che copre il percorso successivo: si basa, infatti, sul modello di processi della ISO 12207 per regolamentare in modo più dettagliato le attività di valutazione dei diversi processi e di attribuzione di un "voto" al livello di maturità dimostrato.

Può sembrare strano che si proponga, ad aziende che già guardano con sospetto l’ISO9001, di andare addirittura oltre l’ISO9001: ma credo di aver ben chiarito che si tratta di un andare oltre per raggiungere l’essenziale, e per semplificare, non per complicare ed appesantire ulteriormente. Sono ben consapevole che la mia proposta comporta una riflessione strategica molto profonda, non tanto per quanto riguarda il costo degli investimenti, decisamente modesti, quanto per i rilevanti cambiamenti che causerà in azienda. È perfettamente naturale che le persone – direttori tecnici, amministratori, project manager, sistemisti, quality manager – siano affezionati alla loro pratica quotidiana, e restii a modificarla, per diverse ragioni, anche virtuose. Ma quando le pratiche consolidate non danno più buoni risultati di mercato, o addirittura si oppongono ai cambiamenti necessari, può essere il caso di intervenire energicamente: in molti casi ci si renderà poi conto che la rivoluzione metodologica ci ha portati a sistematizzare metodi in parte già utilizzati, ma che non potevano diventare patrimonio aziendale, proprio perché non opportunamente sistematizzati, né riconosciuti meritevoli di attenzione e generalizzazione.

Segnala questa pagina a qualcuno
Stampa questa pagina