Processo di produzione del software

La produzione di software non è un una attività che si limita alla sola programmazione e poco altro.

Può andare bene per progetti semplici, ma quando si realizza un prodotto molto articolato non è pensabile di lavorare sul progetto in modo artigianale e con semplice buon senso, “buttandosi” sul codice, senza investire tempo e risorse su altri aspetti altrettanto importanti. Questo perché, con l’aumento della complessità delle funzionalità e soprattutto delle righe di codice da scrivere, aumenta anche la complessità di tutte le attività ad esse correlate: la progettazione dell’applicazione in sè, il test degli errori, la gestione dei dati, la definizione di un ambiente di esecuzione, la collaborazione tra programmatori, la condivisione del codice, ecc.

Diventa necessario definire un processo di produzione, cioè un procedimento strutturato per fasi che indicano cosa si dovrà fare in ogni fase, quali sono gli obiettivi, chi se ne occupa, chi ne è responsabile, ecc.

Ingegneria del software

Nell’ingegneria e dell’industria moderna tutte le attività produttive sono regolate da processi predefiniti, e questa standardizzazione garantisce se non la certezza, una buona approssimazione nel definire obiettivi di qualità e tempi di lavorazione, in modo indipendente da chi dovrà svolgerle.

Questo quindi vale anche per i progetti software, per cui esiste una disciplina specifica, l‘ingegneria del software, una branca dell’informatica che si occupa in generale di metodi, obiettivi e strumenti di sviluppo di software.

L’ingegneria del software prende vita a partire dalla fine degli anni 60, in un’epoca in cui era diventato ormai evidente che la dimensione dei software già realizzati allora non poteva più essere gestita tramite produzioni basate sul singolo individuo o team. Era necessario ­superare la metodologia “artigianale” per cui si realizzava il software un po’ in base all’esperienza, la capacità ed il genio individuale di singoli progettisti, per arrivare ad una visione “industriale” del processo di sviluppo, dove le persone contano, ma la qualità del prodotto finale dipende soprattutto da una metodologia di lavoro, dal lavoro di squadra, da una capacità di dare tempi e modalità certe indipendenti dalla soggettività individuale. 

Era diventato evidente altresì che produrre software non era esattamente come produrre strade, edifici o automobili, ma richiedeva una branca dell’ingegneria dedicata, con studi ed approcci dedicati. Il software ha proprie caratteristiche specifiche di cui bisogna tenere conto nella progettazione:

• la complessità aumenta enormemente con l’aumento delle righe di codice: le competenze sul codice sono elevatissime a causa della complessità, e bisogna fare in modo di rendere il software più semplice possibile;
• un software può essere riavviato e funzionare anche dopo un crash, e può essere utilizzabile anche con molti difetti;
• una pessima progettazione può portare ad un software costoso da mantenere ed evolvere, quindi la progettazione è una chiave fondamentale per il successo di un prodotto;
• il software è duplicabile, ma deve essere adattabile a dati ed ambienti specifici al contesto;
• il software manipola dati ed informazioni, e deve garantire standard di sicurezza sia per le persone che nella gestione dei dati.

L’ingegneria del software ha quindi prima di tutto due obiettivi:

• definire i migliori processi di sviluppo.
• definire i criteri e le misure per stabilire in cosa consiste la qualità del software.

Oggi esistono diversi processi di produzione del software, ed il dibattito su come definire le fasi di lavoro e come procedere è più che mai aperto. L’obiettivo finale è infatti è quello di ottenere la maggiore efficacia ed efficienza possibile, anche in base a parametri come la tipologia di progetto, il tipo di industria, i team di sviluppo, e non ultime le tecnologie a disposizione, con l’obiettivo di ottenere software di qualità.

Essa dipende da problematiche organizzative, dallo sviluppo tecnologico ma soprattutto dipende dalle caratteristiche distintive del software. Non esiste ad oggi ancora un modello che va bene per tutto, ma anzi esistono diversi modelli che si adattano meglio o peggio a seconda del tipo di prodotto, contesto e investimento fatto.

Le attività e tipi di processo

L’ingegneria del software definisce, per qualsiasi progetto, di qualsiasi dimensione, almeno tre grandi macro attività quando parliamo di produzione del software:

1. Definizione: identifica l’insieme delle attività che vanno a determinare “cosa” deve essere prodotto. Essa produce artefatti che indicano le specifiche del software, le funzionalità, i vincoli, i contesti di esecuzione. Non è una attività esterna alla produzione di software perchè richiede competenza sia tecnologica sia del prodotto da realizzare.

2. Produzione: Identifica “come” deve essere realizzato il software, e comprende tutte le attività di progettazione e realizzazione del software, compreso lo sviluppo, il test ed il rilascio.

3. Supporto: Identifica tutte le attività di manutenzione del prodotto.

A partire da queste nel corso degli anni, ed in base alle esigenze dei progetti e l’evoluzione delle tecnologie, si sono sviluppate numerose metodologie di progettazione, di cui le due più importanti sono il modello Waterfall ed le metodologie Agile.

Waterfall

In questa tipologia di processo si scompone il progetto in fasi a cascata (analisi, progettazione, sviluppo, test, rilascio), dove ogni fase viene eseguita solo dopo che è terminata la fase precedente. Il modello Waterfall nasce per evitare il problema di progettare software non ben analizzato, di sviluppare software non ben progettato e così via. Presenta una serie di vantaggi che vedremo, primo tra tutti una forte organizzazione dei ruoli e delle responsabilità con gruppi di lavoro monodisciplinari (progettisti, programmatori, tester, ecc.), ma anche degli svantaggi come una grande rigidità di fronte ai cambiamenti.

Di esso ne esistono diverse varianti, come il modello a spirale e il modello a prototipazione rapida, ma fondamentalmente si basa sul principio di replicare in ambito software ciò che avviene nelle altre industrie, come quella dell’automobile, ovvero replicare il modello della “catena di montaggio”.

Metologie Agile

La tipologia Waterfall è una metodologia molto rigida, e male si adatta a progetti dove è necessaria una produzione di funzionalità per cicli di sviluppo, dove cioè si va definire, realizzare e rilasciare un numero ridotto di funzioni in un primo ciclo, per poi rimettere mano al progetto e definire un secondo ciclo con nuove funzioni, con relativa analisi, sviluppo e rilascio, e così via con un terzo ciclo, un quarto e così via. Nelle metodologie agile il team di sviluppo diventa multidisciplinare, la responsabilità diventa collettiva, e viene coinvolto il committente finale in ogni fase di rilascio. Infine, tipicamente nelle metodologie Agile come SCRUM il team rivede il processo di sviluppo ad ogni ciclo. Nell’Extreme programming invece vengono introdotte metodologie che consistono ad ogni ciclo non solo nello sviluppare nuove funzioni, ma nel sistemare costantemente il codice già scritto, automatizzare il test in modo sistematico, e di utilizzare la programmazione in coppia per ridurre al minimo gli errori di programmazione.

Utilizzeremo la metodologia Waterfall per descrivere dettagliatamente le fasi di progettazione sviluppo e rilascio, sia per la sua semplicità, sia perchè nell’Agile sono comunque in buona parte replicate anche se con alcune modifiche che prenderemo in esame quando andremo ad analizzarlo.