La produzione di software non è un una attività che si limita alla sola realizzazione di codice.

Il puro coding può andare bene per progetti molto semplici. 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 uno o più ambienti di esecuzione, la collaborazione tra più programmatori, l’interfaccia utente, ecc.

Questo è tanto più vero per chi si occupa professionalmente dello sviluppo di software, e quindi intende non solo produrre software, ma con la migliore qualità possibile, in modo ripetibile, in modo indipendente dalle tecnologie, dai linguaggi e dai programmatori.

Serve un approccio industriale, analogamente a quanto avviene in altre attività produttive, come la realizzazione di automobili o di edifici.

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, come e con quali risorse.

L‘ingegneria del software è quella branca dell’informatica che ha proprio questo obiettivo, e si occupa in generale di metodi, obiettivi e strumenti di sviluppo di software.

Alla fine degli anni 60 era diventato ormai evidente che la dimensione dei software già realizzati allora non poteva più essere gestita tramite produzioni artigianali, dipendenti cioè dal genio o le pratiche di un singolo individuo o team. Era necessario ­superare la metodologia per cui si realizzava il software in base all’esperienza, la capacità ed il genio individuale di singoli progettisti: occorreva arrivare ad una strutturazione del processo di sviluppo, dove la qualità del prodotto finale dipende principalmente da una metodologia di lavoro, da una capacità di dare tempi e modalità certe indipendenti dalla soggettività individuale, e dove il genio individuale poteva essere un valore aggiunto, non strettamente necessario.

Nei primi studi i ricercatori si erano subito resi conto che produrre software non era proprio come produrre strade, edifici o automobili, e loro ingegnerie (meccanica, civile, ecc.) ma occorreva definire un nuovo tipo di ingegneria, che tenesse conto delle caratteristiche intrinseche del software. Tra queste le più importanti sono queste:

• la complessità aumenta enormemente con l’aumento delle righe di codice. Di norma si usa la formula empirica C = K * LOC² (dove K è una costante, LOC il numero di righe di codice). Di norma nell’ingegneria tradizionale, la complessità non necessariamente dipende dalle dimensioni del progetto.
• un software può essere riavviato e funzionare anche dopo un crash, e può essere utilizzabile anche con molti difetti; anche questa è una grande differenza con le ingegnerie tradizionali (un ponte se crolla va ricostruito);
• il software ha un enorme costo di produzione, ma un costo nullo di duplicazione; anche qui c’è una grossa differenza con l’industria tradizionale, dove esistono costi fissi, ma anche costi dipendenti dai volumi;
• una pessima progettazione porta ad un software costoso da mantenere ed evolvere, quindi la progettazione è una chiave fondamentale per il successo di un prodotto;
• il software deve essere adattabile a dati e contesti specifici;
• il software manipola dati ed informazioni, e deve garantire standard di sicurezza sia per le persone che nella gestione dei dati.
• il software deve essere sia estendibile che modificabile.

L’ingegneria del software si pone due obiettivi:

• definire in modo oggettivo la qualità del software. E’ un problema non banale: ci sono molte metriche per misurare la qualità del software: le prestazioni, l’interfaccia utente, il numero di difetti, la modificabilità, la sicurezza, l’estensibilità, l’adattabilità, ecc.
• definire processi di sviluppo efficaci per lo sviluppo. 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à. Vediamo questo tema in dettaglio.

Il ciclo di produzione

L’ingegneria del software definisce, per qualsiasi progetto, di qualsiasi dimensione e per qualsiasi processo, almeno quattro grandi macro attività:

1. Definizione: identifica l’insieme delle attività che vanno a determinare “cosa” deve essere prodotto. Essa produce artefatti che indicano le richieste/bisogni degli utenti, 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. Rilascio: identifica sia le attività di messa in produzione del software, sia la definizione delle procedure e degli ambienti di esecuzione del software stesso (ad esempio server, PC, mobile, embedded, ecc.).

4. Supporto: Identifica tutte le attività di manutenzione del prodotto, evoluzione, modifiche, adattamenti.

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 Agile si adatta a progetti dove la produzione avviene per cicli di sviluppo della durata predefinita, dove cioè si va definire, realizzare e rilasciare un numero ridotto di funzioni per ogni iterazione, per poi aggiungere funzioni ad ogni successivo ciclo, fino ad avere un prodotto abbastanza valido per il rilascio all’utente. Nelle metodologie agile il team di sviluppo diventa multidisciplinare, e viene coinvolto il committente finale in ogni fase di rilascio. Nelle metodologie Agile SCRUM il team rivede il processo di sviluppo ad ogni ciclo perfezionandolo ed adattandolo al contesto. Nell’Extreme Programming (XP) invece ad ogni ciclo non solo si sviluppano nuove funzioni, ma si sistema costantemente il codice già scritto, la responsabilità del codice è sempre collettiva. All’interno dell’Agile si è poi sviluppato l’approccio Pragmatic Programmer, che si basa non sul “fare Agile” ma “essere Agile” ovvero portare estrema flessibilità, agendo sul feedback dei risultati per rivedere e modificare il processo di sviluppo.

Utilizzeremo la metodologia Waterfall per descrivere dettagliatamente le fasi di progettazione sviluppo e rilascio, a fini didattici. Questo ci permetterà poi di capire meglio anche l’Agile.