La progettazione del software: arte, scienza, ingegneria?


Una disciplina in costante evoluzione

La progettazione dei sistemi software è una disciplina giovane, con circa 50 anni di storia alle spalle.

Le persone che praticano la progettazione software hanno retrorerra formativi eterogenei, sia come livello che come tipologia di studi effettuati, e forse in misura ancora maggiore in termini di tirocinio e di esperienze lavorative. Non esiste alcun consenso sul tipo di formazione necessario per intraprendere la professione, né (almeno per il momento) una certificazione che abiliti all'esercizio della professione stessa.

Progettare sistemi, oggi, è molto diverso rispetto a dieci anni fa. Le modalità di interazione tra utilizzatore e sistema sono diventate molto più importanti, perché vengono percepite come un aspetto di qualità irrinunciabile. La cura nell'ottimizzazione delle risorse e delle prestazioni si è ridotta, dato che le risorse hardware sono accessibili ad un costo decisamente inferiore. In generale, pur con le debite eccezioni (sistemi real-time e embedded, soprattutto) l'attenzione dei progettisti si sta spostando dagli aspetti più propriamente tecnici a quelli funzionali, e ciò ha impatto sul tipo di conoscenze necessarie per i progettisti.

Le tecniche utilizzate dai progettisti sono in costante evoluzione. Programmazione visuale e basata sugli eventi, sviluppo per assemblaggio di componenti predefinite, orientamento agli oggetti, architetture a strati (layer), utilizzo di design pattern: non è possibile, in questo continuo emergere di nuovi approcci allo sviluppo, potersi affidare unicamente a ciò che si è imparato all'inizio di una carriera lavorativa, permettersi di smettere di imparare. Le tecniche che venivano utilizzate per progettare i sistemi della generazione precedente non sono più sufficienti a affrontare quelli attuali, più complessi e basati su tecnologie diverse.

Un ruolo cruciale

La progettazione del software è anche un’industria, in cui lavorano milioni di persone in tutto il mondo, che ha un impatto sempre crescente su tutti gli altri settori economici, che sta contribuendo in modo decisivo a trasformare le modalità di produzione, di distribuzione e di comunicazione, e influenza in modo rilevante la vita di tutti.

Eppure, se si guarda alle statistiche, si tratta di un'industria profondamente immatura. L'ultima indagine dello Standish Group, basata su un campione di 28.000 progetti e pubblicata da Computer Weekly il 9 luglio 1998, fornisce i seguenti risultati:

A livello internazionale esiste una diffusa consapevolezza sui rischi legati allo sviluppo di sistemi software, e sulla necessità di ottenere miglioramenti significativi nell'efficienza, nell'efficacia e nella qualità della progettazione. Dall'Organizzazione Internazionale per la Standardizzazione (ISO), al Software Engineering Institute (SEI), sponsorizzato dal governo americano

La ricerca di un'identità

la

Art & Craft

La progettazione del software è un arte. Come dicevano i greci, una Téchne. I greci antichi non distinguevano tra arte e tecnica: per loro erano esattamente la stessa cosa. Falegnami, vasai, tintori, pittori, sarti, medici, architetti: tutti tecnici, nel senso che per fare il loro mestiere era (è) necessaria la padronanza di tecniche specifiche. E la tecnologia, nel significato originario, è il discorso – lògos - sulla téchne.

Uno dei più diffusi è quello del programmatore che, in solitaria, dopo avere ascoltato le esigenze del proprio committente - utilizzatore ("utente"), si tuffa direttamente a scrivere il codice che le soddisferà. E' un modo di lavorare sbrigativo e senza troppe pretese, ma può essere efficace, a patto che:

Se però una di queste condizioni viene meno, il metodo sbrigativo non funziona. I problemi, salvo eccezioni, non sono così semplici da poter essere risolti senza un minimo di progettazione preventiva. Chiarire le esigenze (i requisiti) dell'utente richiede capacità di dialogo e di ascolto. E in generale la produzione di software è un'attività collaborativa, che richiede la partecipazione ed il coordinamento di diversi progettisti, non un lavoro isolato.

Ne consegue che, prima di mettersi a scrivere il codice, è opportuno effettuare un'analisi dei requisiti che il sistema dovrà soddisfare, e una progettazione dell'architettura tecnica del sistema. Lo si è scoperto alla fine degli anni '60, quando le esigenze che gli utenti sottoponevano ai progettisti si erano rivelate troppo complesse per trovare soluzione in un unico programma, scritto da un unico programmatore. E proprio dalla fine dei '60 iniziano le riflessioni, le proposte e le discussioni su come dominare la crescente complessità dei sistemi software e delle problematiche relative allo sviluppo delle applicazioni. Si inizia, cioè, a parlare di metodi.


Differenza tra metodo e processo

La complessità della produzione dei sistemi software pone due ordini di problemi distinti. Il primo è di tipo organizzativo - procedurale :

Per risolvere questo problema sono state proposte diverse "metodologie", basate su diverse visioni del ciclo di vita delle applicazioni software. (Il termine "metodologia", che dal punto di vista etimologico significa "ragionamento, discorso sui metodi", viene spesso impropriamente utilizzato in campo informatico per riferirsi al processo, cioè alla sequenza di fasi e attività da compiere per ottenere il risultato voluto).

Vi è poi un secondo problema, che non ha carattere organizzativo bensì "tecnico", cioè relativo ai concreti modi di operare nell'ambito delle attività del processo:

I metodi sono, propriamente, delle tecniche utilizzabili per svolgere una specifica attività nel modo migliore possibile.

Metodi e processi sono indipendenti tra loro. Posso utilizzare un certo metodo (ad esempio, l'Entity-Relationship per la progettazione dei dati) nell'ambito di processi diversi (a cascata, oppure iterativo e incrementale). Viceversa, posso utilizzare metodi diversi per svolgere una certa attività nell'ambito del medesimo processo (ad esempio, per individuare le funzionalità richieste, posso utilizzare un metodo strutturato oppure i casi d'uso).


Metodi di analisi, metodi di disegno

Analisi: lo studio di cosa deve fare il sistema (punto di vista "funzionale")

Disegno: lo studio di come il sistema deve venire implementato, a fronte di  tecnologie specifiche.

In una visione leggermente diversa, e più attenta agli aspetti "contrattuali" del rapporto tra clienti e fornitori, l'analisi è lo studio dei requisiti espressi dal committente, mentre il disegno è la progettazione della soluzione ai requisiti stessi, cioè del sistema.

Nella storia dell'ingegneria del software sono stati proposti metodi (e tecniche) specifici per l'analisi e altri specifici per il disegno; altri ancora con l'ambizione di "coprire" entrambe le attività (com'è tipico dei metodi object oriented).


Metodi strutturati, metodi object oriented

Negli anni settanta e fino circa al 1988 dominavano la scena metodi distinti per la progettazione dei dati e delle funzionalità.

Poi, quasi di colpo, è arrivato l'object oriented (OO). Era successo che, con l'arrivo dei personal computer, la vecchia informatica centralizzata, dei grandi elaboratori e dei terminali a carattere, diventava quasi di colpo obsoleta. E nelle nuove architetture di sistemi distribuiti i metodi (e i linguaggi) basati sulla separazione di dati e processi non funzionavano più bene (e risultavano quindi troppo costosi).

L'object oriented, un approccio che vede i dati e le funzioni in modo integrato, come oggetti che hanno un proprio stato e propri comportamenti, e che possono interagire tra loro, risultava più adeguato per progettare applicazioni basate dul dialogo tra sistemi diversi.

Analisi e disegno object oriented sono oggi "mainstream", l'approccio maggiormente diffuso nel mondo. E se fino a pochi anni fa non si poteva non restare confusi, di fronte agli oltre 50 metodi orientati agli oggetti, la standardizzazione portata da UML sta fornendo un  contributo decisivo per risolvere questo problema.

Tra le tecniche "ante-OO", comunque, alcune conservano intatta la loro validità. L'entity-relationship e la normalizzazione restano insuperate per la progettazione delle basi dati relazionali, e la padronanza di queste tecniche può risultare proficua anche per la definizione di un modello delle classi. E l'approccio strutturato all'analisi delle funzioni, benché i Data Flow Diagram non siano presenti in UML, può essere ancora vantaggiosamente utilizzato per individuare le interazioni di alto livello tra il sistema e il mondo esterno (oltre a presentare molti punti di contatto con l'approccio basato sui casi d'uso).


Bibliografia e rimandi

materiali in rete per alcuni tra i metodi object oriented più diffusi:

confronti tra metodi di analisi e disegno:

bibliografia sui metodi di analisi e disegno object oriented:

bibliografia sui metodi di analisi e disegno strutturati (ante object oriented)