Appunti completi corso Ingegneria del Software

Questo è un corso fondamentale come API, perché ci insegna come ingegnerizzare il

software, cioè come organizzare il lavoro e gestire il processo di creazione del software.

Perché ci serve l'ingegneria del software? Se sono un bravissimo programmatore non

basta questo? SEH COME NO! Lo scopo è passare dal programmino inutile fatto da me in

cantina ad un progetto di portata industriale di grande copertura. Non basta un bravo

programmatore per fare GTA V o No Man's Sky per intenderci. L'aspetto fondamentale di

questa materia è la COLLABORATIVITÀ TRA PERSONE e questo spiega la presenza del

progetto di gruppo nel corso. È un assaggio del nostro futuro. Bisogna gestire la

collaborazione, che non è roba da poco. Complessità significa passare da 200 righe di

codice fatte da me a 7 milioni fatte da più persone. Bisogna risolvere questioni riguardanti

l'usabilità, l'efficienza, la dipendenza, la mantenibilità, l'aggiornamento. L'ingegneria del

software massimizza questi aspetti.

Purtroppo c'è sempre un trade-off tra tante cose... Anche se non sembra il software costa,

e tanto, e bisogna bilanciare sforzo e risultato: cercare di ottenere il meglio col minimo

sforzo. Il primo attore fondamentale nella creazione di un software è il CLIENTE. Bisogna

rispettare dei trade-off per non andare in perdita, ma l'obiettivo principale è soddisfare il

cliente. Ma nel software commerciale chi è il cliente? Nel caso di Microsoft Excel, per

esempio, non c'è un qualcuno che ha commissionato la realizzazione di quel programma.

Infatti il software va inizialmente diviso in due categorie: il GENERICO contro il

CUSTOMIZZATO. Il software generico è prodotto da un'azienda per il mercato, ma non ha

un cliente specifico. Ha funzionalità per soddisfare tanti clienti diversi. Nel software

customizzato invece c'è un cliente specifico che chiede un programma con determinati

requisiti. Esiste anche una via di mezzo che è il software CUSTOMIZZABILE, cioè un

software generico che ogni cliente può customizzare per le proprie esigenze. Facendo

degli esempi, un libero professionista che vuole un software per la gestione delle fatture

può andare su internet e cercarsi un software già fatto, e quello è generico. Paga poco per

un servizio generale e non customizzato, e può andare bene così. Ma vediamo il caso

opposto: lo stato deve gestire le tasse. Di certo non usa un software scaricato con

BitTorrent... Ha bisogno di un software customizzato che costerà milioni di euro. Caso

intermedio: il Politecnico deve gestire la contabilità. Prende un software customizzabile,

che costa più del generico ma meno del custom. Il range dei prezzi è comunque molto

ampio, perché si va davvero dai pochi euro dei software generici a centinaia di milioni di

euro per il software ad hoc. La categoria intermedia può costare qualsiasi quantità che sta

nel mezzo.

Il software ha le due principali caratteristiche di essere INTANGIBILE e MALLEABILE. Si

ha la percezione che sia gratuito proprio perché non è qualcosa di materiale, è qualcosa di

astratto, che non si tocca. E questo fa pensare che non costi niente... Ed è malleabile nel

senso che si può modificare nel tempo. I prodotti materiali una volta costruiti non si

modificano più, invece il software si aggiorna continuamente, tanto che le app del telefono

si aggiornano quasi tutti i giorni. Per questo motivo il ciclo di vita del software è

diversissimo da quello dei prodotti materiali. Nei materiali "hardware" il failure rate ha una

certa distribuzione ben nota: la probabilità che un prodotto materiale si rompa è molto alta

quando è appena comprato, perché possono esserci stati errori di produzione e difetti vari,

ed è per questo che esiste la garanzia. Ma col passare del tempo la probabilità di rottura si

abbassa, perché l'oggetto ha dimostrato di essere funzionante come deve, finché poi

l'oggetto diventa molto vecchio e allora la probabilità di rottura aumenta a causa dell'usura.

Nel software invece funziona diversamente: appena messo in commercio hai una

ALTISSIMA probabilità che non funzioni una minchia perché è un covo di bug. Poi la

software house ripara i bug e pubblica gli aggiornamenti, che rendono il programma

utilizzabile. Man mano che si scoprono nuovi bug vengono corretti e il software dovrebbe

idealmente tendere alla perfezione, ovvero alla correzione di tutti i bug. Beh, non è così :) I

software commerciali sono complicatissimi e come detto contengono milioni di righe di

codice e non si può sapere a menadito come interagiscono fra di loro. La correzione di un

bug ne provoca potenzialmente altri cinque per esempio, e questo si ripercuote su ogni

aggiornamento successivo. Il trend prosegue pure negativamente, nel senso che col

tempo la quantità di bug aumenta così tanto che non ha più senso correggerli. A quel

punto il ciclo di vita del software termina e si ricomincia da capo la stesura di una nuova

versione del software. Per questo motivo anche il mantenimento COSTA, e tanto.

La reputazione di una software house è molto importante, perché non rendere contenti i

clienti può distruggere un'intera organizzazione (Hello Games insegna...). Al contrario

avere una certa reputazione tra le organizzazioni permette di avere strette collaborazioni e

pure l'accesso a dati sensibili. Tutto questo poi deve essere incastrato anche in un

contesto legale ben definito. Saper organizzare il lavoro quindi ha lo scopo di ridurre il

rischio.

Il rischio viene studiato con lo STUDIO DI FATTIBILITÀ. Ci sono tanti fattori di rischio che

rendono il costo del software molto alto già in partenza, perché è la prima fase di lavoro:

decidere se il software è fattibile e se ne vale la pena correre il rischio. Dopo questo

possiamo seguire le classiche fasi della creazione del software: la progettazione, il

design, l'implementazione, il testing e la distribuzione.

Siccome il software è diverso in quanto intangibile e malleabile, anche la produzione del

software è diversa da quella dei prodotti tradizionali. Vediamo così una carrellata dei

processi di sviluppo usati a partire dagli anni 60. Il più antico è il più semplice:

PROCESSO A CASCATA o WATERFALL. È il primo processo pensato a livello

industriale, è semplice ed è molto vicino al modo di lavorare degli altri settori. Le fasi del

processo si presentano in successione l'una all'altra. La produzione avviene in modo

sequenziale. Le fasi sono quelle che conosciamo (specifica dei requisiti, design,

implementazione, testing) e vengono eseguite sequenzialmente. Aveva il vantaggio che la

produzione era semplice e diretta, si dividevano nettamente le responsabilità, si poteva

misurare il tempo speso in ogni fase. Ma c'era un problema chiaro: la dipendenza diretta

rende il processo produttivo molto rigido e non è naturale per il software. Durante lo

sviluppo di un software puoi scoprire cose che prima non sapevi (problemi, specifiche non

chiare o simili). Se queste scoperte le fai nel mezzo della produzione cosa fai? Come torni

indietro? È così che si è passati al modello A CASCATA CON FEEDBACK. Ovvero ogni

fase può notificare a quelle precedenti se c'è qualcosa che non va e quindi di riavvolgere

all'indietro la produzione alla fase interessata. Questo approccio ha un altro problema,

ovvero che si perde molto tempo nelle prime due fasi prima di andare avanti, specialmente

se si ha a che fare con un software molto complesso. Diventa tutto molto lento e il

feedback arriva dopo che hai già perso molto tempo. Il nuovo approccio è stato quindi

quello ITERATIVO o a RAFFINAMENTI SUCCESSIVI. È completamente diverso, non è

più sequenziale ma CIRCOLARE o A SPIRALE o INCREMENTALE, continuo e

migliorativo. Non si perdono mesi nella prima fase, si fa una versione semplificata della

prima fase, poi della seconda, della terza e così via. Alla fine si ricomincia da capo

affinando ogni fase e rilasciando tante versioni intermedie. In questo modo se c'è qualcosa

che non va si torna indietro ma perdendo poco tempo. Non parti più a razzo tutto fiero per

poi sbattere la testa, ma prosegui per raffinamenti. È un metodo che minimizza il

RISCHIO, nel senso che non diminuisce il tempo necessario ma quello sprecato.

Però anche questo metodo non è il migliore, perciò ora saltiamo negli anni 2000, quando

sono stati pensati nuovi metodi, i cosiddetti METODI AGILI. Sono una serie di metodi

considerati rivoluzionari perché pongono l'accento sul risultato e non sul processo e per

questo non sono rigidi e formalizzati come i metodi precedenti. Lo scopo quindi è

massimizzare il risultato, non il processo, riducendo l'overhead e i costi aggintivi per il

processo. Questo è avvenuto perché il mondo è cambiato: in quegli anni ormai si passava

ai PC che erano alla portata di tutti, i software erano più generici, cambiavano spesso i

requisiti e tutt cos. Si pianifica di meno e si è più flessibili per le modifiche delle esigenze.

Non si pianifica sul lungo periodo perché non ha senso, le cose cambiano velocemente. Si

coinvolge il più possibile il cliente, lo si consulta sempre e si cerca di rendere tutto il più

semplice possibile. Esistono tanti metodi che appartengono a questa categoria e noi ne

vediamo un paio.

Uno di questi è l'EXTREME PROGRAMMING, in cui si dà estrema attenzione

all'implementazione. Si producono nuove versioni anche più volte al giorno, si consulta il

cliente ogni pochi giorni e ad ogni nuova versione si garantisce che quella versione è a

posto in quello che fa come se fosse la versione finale. Non è uno stub, ma è parte del

lavoro finito. In qualunque momento si ha qualcosa di funzionante. Nel metodo coi cicli ciò

non era vero perché bisognava fare tutte le fasi del ciclo. Nella pratica si chiede che il

cliente sia sempre disponibile per dare un feedback, si rilasciano nuove versioni

continuamente, si programma mettendo il focus sul valore della persona. Inoltre ora si

definiscono prima i casi di test e poi l'implementazione, dato che si usano metodi

automatici per il testing. Il software viene promosso quando passa tutti i test. Qui due

persone lavorano sullo stesso pezzo di codice, sulla stessa tastiera e sullo stesso

schermo. Si è verificato sperimentalmente che con due persone si ha maggiore efficienza

e si hanno meno costi, perché è vero che bisogna pagare due persone, ma queste sono

più veloci ed efficienti nel loro lavoro. Se lavori da solo e più probabile che sbagli

qualcosina, in due invece ci si aiuta a vicenda. Prima c'era anche una

sovraingegnerizzazione delle funzioni, ovvero si programmavano funzioni il più generali

possibili per essere riutilizzate in seguito. L'obiettivo era proprio avere il più codice

riusabile possibile. Ora invece bisogna semplificare. Si tiene la complessità per l'esigenza

specifica. Se in futuro serve qualcosa di specifico, va bene, si riprende il codice vecchio e

lo si integra per le nuove esigenze.

L'altro metodo è lo SCRUM che si compone di tre fasi: INIZIALIZZAZIONE, CICLI DI

SPRINT, CHIUSURA. L'inizializzazione è la normale stesura di requisiti e specifiche.

Seguono gli sprint, che sono cicli che si ripetono con nuovi sprint. La chiusura corrisponde

invece alla chiusura del progetto, il completamento della documentazione richiesta e la

consegna. Lo sprint sostanzialmente è un ciclo di sviluppo di poche settimane, un giro

veloce di lavoro. L'altro elemento importante nello Scrum è il BACKLOG, cioè l'elenco

delle feature mancanti per completare il progetto in ordine di priorità, una lista di

funzionalità da inserire. Nella pratica si definisce inizialmente il backlog, si esegue uno

sprint (assegnato ad un team specifico) che dal backlog seleziona delle funzionalità che

devono essere implementate nello sprint. Il team non ha una struttura gerarchica, si

autogestisce (è composto da poche unità) e organizza tutto il lavoro. Si sceglie un

MASTER che non è il capo del team, ma è quello che ha il ruolo di guardiano e protegge il

team da distrazioni esterne (è l'unico che può interagire con l'esterno durante lo sprint, gli

altri sono isolati nello sviluppo). L'isolamento permette al team di proseguire indisturbato. Il

team non è omogeneo, ma deve essere in grado di saper gestire un po' di tutto ai fini del

programma. La dedizione del team al lavoro è totale e ogni membro deve dare il suo

contributo. Gli elementi del team sono fissati e non possono cambiare durante lo sprint,

ma solo tra uno sprint e l'altro. Insomma è un ambiente movimentato, dove le cose

cambiano rapidamente. Ogni mattina di ogni giorno di sprint il team si riunisce per pochi

minuti, stando in piedi, per discutere delle criticità. Non ha lo scopo di risolvere i problemi

ma di dire quali sono. Ognuno dice cosa ha fatto ieri, cosa farà oggi e quali problemi

intende risolvere nella giornata. In questo modo il team è più unito e sa cosa sta

succedendo.

Lo STUDIO DI FATTIBILITÀ e la SPECIFICA DEI REQUISITI sono le fasi preliminari di un

progetto software. Lo studio di fattibilità deve generare un report che spiegherà se il

progetto è fattibile e se può essere intrapreso o meno. Se il progetto passa, si va alla

specifica dei requisiti, in cui vanno specificati esplicitamente (e se necessario

formalmente) i requisiti che dovrà avere il software in lavorazione.

Nello studio di fattibilità bisogna esaminare tutti gli aspetti che potrebbero essere

problematici nello sviluppo, capendo a chi mira il progetto, la sua dimensione, quanto

costerà, quali risorse servono, che rischi ci sono, quali sono gli ostacoli tecnici. Bisogna

identificare il cliente, che a volte non è così scontato e in alcuni casi i clienti sono diversi e

hanno interessi diversi: siamo in grado di soddisfarli tutti? O dobbiamo privilegiare

qualcuno? Quali sono i benefici? Quali sono i costi del progetto in termini di persone:

quante persone devo mettere al lavoro? Per quanto tempo? Ci sono delle scadenze?

Bastano programmatori o servono competenze specifiche? Che risorse software sono

necessarie? Basta un PC portatile o servono software particolari o anche computer

particolari? Qual è l'attitudine del cliente? Per l'uso dei metodi agili esso deve essere

sempre disponibile per una consultazione e non è mica detto che lo sia.

Bisogna anche sapere quali sono i possibili problemi che potrebbero presentarsi quando lo

sviluppo è già partito. Tipico è il CAMBIAMENTO DELLE SPECIFICHE che fa impazzire

tutti. Ma ci sono molti problemi legati allo start-up time, cioè l'avvio del progetto: il lavoro

necessario per far partire il progetto è alto. Ci sono tante persone che vanno organizzate,

magari anche centinaia che si trovano in sedi diverse e ad esse bisogna assegnare

compiti, responsabilità, software da utilizzare ecc... La preparazione può essere costosa in

termini di soldi e tempo, perché potrebbe essere necessario anche l'acquisto di nuovi

hardware o software, oppure i progettisti devono imparare un software o linguaggio muovo

e questo richiede tempo. Lo scopo di questo studio a basso costo è proprio ridurre il

rischio, che invece costerebbe tanto. Il risultato è un documento scritto che spiega perché

si può partire col progetto oppure no, motivando la scelta. La cosa più importante è capire

quali sono i rischi e non perdersene qualcuno per strada. Se si decide di avviare lo

sviluppo e si riscontra un problema che non era stato previsto nello studio di fattibilità, è

colpa tua :)

Per questo ci sono situazioni tipiche che si scoprono a progetto già avviato. Un classico è

la resistenza al cambiamento: sia il cliente che gli sviluppatori tendono a essere

conservatori e a voler fare le cose come le hanno sempre fatte. La richiesta di cambiare

tecnologie di sviluppo può davvero far naufragare un progetto. Un altro possibile problema

è la debolezza tecnica del team: gli sviluppatori potrebbero non avere tutte le competenze

richieste dal progetto. Oppure problemi tecnici dovuti all'integrazione di software

aziendale: ogni software normalmente non funziona da solo, ma integrato con software

dell'azienda che è già stato creato. Bisogna quindi costruire qualcosa di nuovo tenendo

d'occhio quello che c'è già, che è un vincolo e ci richiede di sapere come funziona.

Lo studio di fattibilità sembra una passeggiata perché non consiste in questioni tecniche,

ma in realtà è cruciale per il benessere dell'azienda e viene fatto fare, ovviamente, a gente

che ha molta esperienza in questo campo e sa prevedere i tipici problemi che si

incontrano durante lo sviluppo. E queste persone sono pure pagate tanto.

È ora di passare alla specifica dei requisiti, che noi dovremo fare nel progetto quindi è

parecchio importante. È la parte del processo di sviluppo che si occupa degli obiettivi che

si vogliono realizzare nel mondo reale e dei vincoli imposti dal sistema che andiamo a

creare.

I REQUISITI si dividono in tre categorie:

CONTESTO: lo studio di ciò che ci circonda. Chi sono gli stakeholders, qual è la

– situazione economico/politica del settore, il settore stesso ecc... È ancora vicino allo

studio di fattibilità.

REQUISITI FUNZIONALI: rappresentano la descrizione delle caratteristiche che si

– vogliono avere nel progetto, cioè le funzionalità che il programma dovrà andare a

coprire, quello