Appunti completi corso Ingegneria del Software

Importanza dell'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à e gestione del software

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.

Tipologie di software

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.

Esempi di utilizzo del software

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.

Caratteristiche del software

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.

Ciclo di vita del software

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.

Reputazione della software house

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.

Studio di fattibilità

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.

Processi di sviluppo del software

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.

Processo iterativo

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.

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 aggiuntivi 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 tutto ciò. 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.

Extreme programming

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 è 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.

Scrum

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.

Studio di fattibilità e specifica dei requisiti

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.

Analisi dei rischi e delle risorse

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.

Problemi comuni nello sviluppo

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 nuovo 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 :).

Situazioni tipiche e problemi tecnici

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.

Importanza dello studio di fattibilità

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.

Specifica dei requisiti

È 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.

Categorie di requisiti

• 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