Introduzione

L’industria dei computer ha conosciuto negli anni un continuo sviluppo con un tasso di crescita esponenziale, così forte da sorprendere persino gli esperti del settore.

Si pensi che la capacità delle memorie raddoppia ogni due anni. Nessuno riesce ad immaginare come sarà tecnicamente possibile produrre il prossimo chip con una integrazione così forte da duplicare la potenza attuale; ma questo avverrà secondo il trend descritto, forse con nuove tecnologie produttive, forse con nuovi metodi di progettazione.

Facendo un confronto, se l’industria automobilistica avesse tenuto lo stesso passo, oggi le auto sarebbero in grado di fare il giro del mondo con un litro di benzina e costerebbero mille lire.

Ma a fronte di questa forte crescita dell’hardware, non c’è stata una crescita corrispondente nella capacità di produrre software e ogni soluzione informatica passa inevitabilmente anche per questa componente. Sistemi informativi che non raggiungono gli obiettivi prefissati, programmi che sforano tutti i preventivi di costo e di tempo, qualità dubbia e clienti insoddisfatti sono scenari frequenti in molti progetti software.

La situazione è così diffusa che nella metà degli anni settanta si è cominciato apertamente a parlare di "crisi del software". Questa crisi ha dei contorni estremamente indefiniti: più che una serie di fatti precisi e quantificabili è un sentimento diffuso, una presa di coscienza che nello sviluppo di un prodotto software si passa da un pieno controllo di ogni aspetto ad un graduale degrado della qualità via via che il programma percorre le varie fasi del proprio ciclo di vita, fino al punto di non ritorno dove tutti i tentativi di risalire la china non fanno altro che peggiorare la situazione.

Da allora sono state fatte varie ricerche per inquadrare una nuova disciplina, l’ingegneria del software, che indichi le regole per una produzione razionale ed economica dei programmi, con metodi che permettano di quantificare a priori i tempi di sviluppo, di avere delle stime affidabili del costo finale, di stabilire precisi requisiti qualitativi del prodotto finale.

L’attività di programmazione dei computer, nei primi anni della sua storia, era vista più come un’arte che come una disciplina scientifica ed ingegneristica, come qualcosa in cui la genialità, l’invenzione erano le qualità ammirate, se non addirittura fondamentali ed indispensabili.

La bravura del programmatore si misurava nella capacità di spremere al massimo ogni potenzialità del computer su cui lavorava; ogni trucco era permesso, addirittura apprezzato, anche a scapito della leggibilità del prodotto finale.

Questa situazione era largamente dovuta alla bassa capacità dei primi computer, ma già alla fine degli anni ‘60, la famosa lettera di Dijkstra contro l’uso del GOTO denunciava questo atteggiamento come dannoso per l’attività di programmazione.

Ricorrere a trucchi di ogni tipo porta a programmi incontrollabili, dove anche chi li ha creati non riesce più a ricostruire la logica di soluzione, persa tra linee di codice "spaghetti-like" strutturate nel solo tentativo di risparmiare tempo macchina e memoria. Praticamente impossibile è poi prendere in mano programmi sviluppati con questi criteri da altre persone.

Messo ordine nei linguaggi con la programmazione strutturata, si è pian piano evidenziato anche un secondo aspetto: la costruzione del software non passa per la sola attività di codifica, ma esiste una serie di fasi da percorrere nel tempo e che si influenzano una con l’altra.

Il tutto è una catena e come le catene reali ha una ben nota caratteristica:

La forza dell’insieme è pari a quella dell’anello più debole, ne basta uno arrugginito che la qualità diventa pessima anche se tutti gli altri sono di primissima scelta.

Un programma il cui codice sia strutturato nel migliore dei modi, testato all’estremo fino ad essere privo di errori, crolla miseramente una volta posto in opera presso l’utente se l’analista non ha sviscerato a fondo i problemi che si dovevano risolvere; o meglio risolve perfettamente un problema che non è quello del cliente, quindi fallisce come progetto nel suo insieme.

Da questo nasce immediatamente la necessità di un manager di produzione, un responsabile che divida i compiti, che coordini tutte le attività e le persone, che sia garante dello svolgimento dell’intero progetto.

Ma gestire la produzione di un programma è per noi ancora qualcosa di poco conosciuto: il software è un prodotto strano, diverso da tutti gli altri, in quanto oggetto puramente logico e non fisico.

Il programmatore costruisce "pezzi" il cui costo è legato solo al tempo speso per scrivere o mantenere le righe di programma, quindi tutti i metodi per ottimizzare la gestione di una produzione negli altri campi non si possono applicare a questo prodotto. Si pensi solo alla gestione degli ordini ai fornitori: il programmatore non ordina materia prima, non può comprare "righe di programma", fare gare per la migliore offerta e non ha laboratori esterni che lavorano per "conto terzi"!

Per il software non esiste una vera e propria fase di produzione materiale, ma solo una lunga e continua progettazione; il prodotto che ne risulta non ha alcun problema di usura, non necessita di pezzi di ricambio, non occorre predisporre alcuna forma di magazzino.

Se queste considerazioni possono essere viste come dei vantaggi, delle semplificazioni rispetto alla gestione della produzione di oggetti materiali, il nostro povero manager si trova in grossa difficoltà quando deve verificare lo stato dei lavori: non siamo ancora capaci di identificare con precisione cosa sia necessario, e a volte neppure che cosa effettivamente debba essere prodotto!

Si pensi al campo dei linguaggi di programmazione, sicuramente una delle cose fondamentali per vedere un programma: ci sono più linguaggi nella comunità informatica che sulla torre di Babele, tanto che il Dipartimento della Difesa degli Stati Uniti d’America ha finanziato lo studio del linguaggio ADA perché un censimento aveva riscontrato che nei vari settori del dipartimento stesso erano stati usati più di 400 linguaggi diversi ed incompatibili tra loro.

Peggio ancora è nelle altre fasi di sviluppo di un programma: cosa deve essere prodotto dalla fase di analisi? E come si distingue una buona analisi da una mediocre? Sappiamo che più sono i pezzi che compongono una macchina, più sono i calcoli da eseguire in fase di progettazione perché tutti i meccanismi siano ben congegnati e duraturi nel tempo; cercando un parallelo, quanti sono i pezzi che compongono un programma?

In una casa le fondamenta reggono le colonne portanti, le quali a loro volta sostengono le travi su cui poggiano i muri divisori, i solai, le pareti esterne ed il tetto. Le interazioni tra le varie parti sono ridotte, e se la struttura di base è buona possiamo sempre sostituire le parti accessorie senza timore di intaccare la costruzione nel suo insieme.

Come interagiscono tra loro le parti di un programma?

C’è un metodo che ci assicura che sostituendo una parte di programma non intacchiamo le altre e la struttura generale continua a reggersi in piedi?

L’unico modo per superare la crisi del software è sviluppare metodi ingegneristici, che ci permettano di gestire questa complessità, di definire il cosa ed il come di ogni punto della costruzione del software, che ci diano degli appigli per valutare la qualità del prodotto in ogni suo momento.

La nostra tesi è che per produrre software di qualità bisogna considerare ogni fase del ciclo di vita e all’interno di queste spersonalizzare al massimo ogni attività.