Appunti di Ingegneria del Software

Appunti Software Engineering

Sommario

• Lezione 1 20/09/2021 6
• Introduzione al corso 6
• Legge di Brooks 6
• Lezione 2 23/09/2021 8
• Attività da svolgere nello sviluppo del software 9
• Modelli di Processo 11
• Lezione 3 27/09/21 14
• Analisi dei Requisiti(capitolo 6 del libro) 14
• Elicitazione dei requisiti 16
• Analisi dei Requisiti 18
• Prioritizzazione 19
• Definizione, Prototipizzazione e Revisione 19
• Modello I-P-U 20
• Modello DFD 21
• Modello ERD 21
• Modello UML 22
• Tracciamento dei Requisiti 23
• Prototipazione 24
• Specificazione dei Requisiti 24
• “Sign-off” 24
• Lezione 4 30/09/21 25
• Gestione dei Progetti(capitolo 13) 25
• Planning 25
• Organizing 26
• Monitoring 26
• Adjusting 27
• Tecniche di Project Management 27
• Project Effort Estimation 27
• Estimated Uncertainty 28
• Lezione 5 04/10/21 30
• Efficacia dei modelli algoritmici 30
• Programmer Productivity 30
• Altre Tecniche di Project Management 31
• Work BreakDown Structure (WBS) 31
• Come avviene la suddivisione del progetto? 31
• Project Scheduling 32
• Schedule Presentation 32
• Tecniche di monitoring 33
• Earned Value 33
• Cost Variance 35
• Schedule Variance 35
• Software Pricing 35
• Fattori che determinano la relazione tra costo e prezzo 35
• Strategie di Pricing 35
• Costi nascosti 36
• Pricing to win 36
• Lezione 8 11/10/21 36
• Agile Methodologies 36
• Scrum 37
• Storia di Scrum 37
• Caratteristiche di Scrum 37
• Come funziona Scrum 38
• Ruoli Fondamentali in Scrum 39
• Product Owner 39
• Team di Sviluppo 39
• Scrum Master 39
• Scrum Ceremonies 40
• Sprint Planning Meeting 41
• Daily Scrum Meeting 41
• Sprint Review 41
• Sprint Retrospective 41
• Progettazione 41
• Fase di Pre-Game 42
• Fase di Game 43
• Fase di Closure 43
• Sequential vs Overlapping Dev. 43
• Tracking Sprint Progress 44
• Sprint Burndown chart 44
• Sprint TaskBoard 45
• Lezione 9 12/10/21 45
• Scrum Artefacts 45
• Product Backlog 45
• Sprint Backlog 46
• Increment 47
• Team Velocity 47
• Agile Planning 47
• Stima degli elementi del Product Backlog 48
• Planning Poker 48
• Lezione 10 14/10/21 48
• Forecasting “done” 49
• Comunicazione con il cliente e tra il team 50
• User Stories 50
• Criteri di Accettazione 51
• INVEST 52
• Ciclo di vita di una user Story 52
• User Story VS Tasks 53
• Definition of Done 53
• Lezione 12 19/10/21 55
• Progettazione del Software (capitolo 7 del Libro) 55
• Stili Architetturali/Patterns 56
• Pipes and filters 56
• Event Driven (Real Time) 57
• Client-Server 58
• MVC (Model View Controller) 59
• Layered Style (Stile a Livelli) 59
• Shared Data(DB) - Centric Style 59
• Three-Tier Style 60
• Tattiche Architetturali 60
• Architettura di Riferimento 60
• Progettazione di Dettaglio (SECONDO LIVELLO) 61
• Decomposizione in parti 61
• UML Class Diagram 62
• UML State Diagram 63
• Lezione 13 21/10/21 64
• UML “Sequence Diagram” 64
• Object-Relational Impedance Mismatch 64
• User Interface Design 65
• Flusso delle interazioni 65
• Look and Feel 65
• Other UI Issues 66
• Errori comuni 66
• Caratteristiche di una “buona” progettazione 67
• Consistency (coerenza) 67
• Completeness (completezza) 67
• Complexity (complessità) 67
• Altri segnali di ottima progettazione 68
• Coesione (cohesion) 68
• Accoppiamento (coupling) 69
• Coupling and OOP 70
• Lezione 14 25/10/21 72
• Testing e assicurazione di qualità di un prodotto software 72
• Introduzione 72
• Cosa intendiamo per qualità di un prodotto? 72
• Errore, bug e problema 72
• Severità e Priorità 73
• Testing 73
• Black box testing (o testing funzionale) 74
• Suddivisione in classi di equivalenza 74
• Analisi dei valori limite 74
• White box testing (o testing strutturale) 75
• Grafo del flusso di controllo (o Control Flow Graph) 75
• Copertura delle istruzioni (o statement coverage) 75
• Copertura dei rami (o branch coverage) 75
• Copertura delle condizioni (o condition coverage) 76
• Copertura dei percorsi (o path coverage) 76
• Percorsi linearmente indipendenti 76
• Legge della complessità cinematica di McCabe 77
• Copertura dei percorsi indipendenti 77
• Esempio 77
• Unit code testing 78
• Quando smettere di fare testing? 78
• Inspections and review 79
• Metodi formali 79
• Analisi statica 80
• Lezione 15 28/10/21 81
• Test Driven Development 81
• Introduzione 81
• Conseguenze del Test Driven Development 82
• Refactoring 83
• TDD e Refactoring 83
• Test automation in Java 83
• JUnit 84
• Utilizzo di JUnit 84
• Principali metodi assert 85
• Esempio 85
• Risultati dei test 86
• Time outs 86
• Exceptions 86
• Fixtures 86
• Lezione 16 08/11/21 88
• Sistemi di controllo delle versioni 88
• Storia 88
• Git 89
• VCS Distribuiti (Sistemi di controllo delle versioni distribuiti) 89
• VCS Centralizzati vs. Distribuiti 89
• Concetti fondamentali 89
• Comandi principali 91
• Inizializzazione 92
• Concetti fondamentali (cont.) 92
• Tag 92
• Branch 93
• Head branch 93
• Esempio 93
• Commit di condivisione e remote 96
• Setup di un remote 98
• Esempio con remote 98
• Gestione dei conflitti 99
• Design Patterns 101
• Definizione di design pattern 101
• Classificazione dei pattern 101
• Factory Method - Metodo fabbrica 103
• Abstract factory 104
• Singleton 106
• Pattern strutturali 107
• Adapter (scope Class) 107
• Adapter (scope Object) 109
• Decorator o Wrapper 111
• Proxy 112
• Remote Proxy 113
• Virtual Proxy 114
• Future 114
• Smart Proxy 114
• Protection Proxy 114
• Pattern comportamentali 114
• Command 115
• Iterator o Cursor 116
• Observer o Publish-Subscribe 117
• State 119
• Strategy 120

Lezione 1 20/09/2021

Introduzione al corso

In questo corso tratteremo dell’ingegneria del software, ovvero di tutto quel processo che porta allo sviluppo di un software(analisi dei requisiti, etc…).

Questo modello da seguire nasce a causa della crisi del software. Negli anni 60’ venne osservato un insieme di fenomeni dalla NATO, che andarono a definire questa crisi.

I problemi principali riguardavano:

• I costi di produzione del software, che spesso sforavano di molto le ipotesi iniziali
• I progetti venivano completati in ritardo, oppure non consegnati affatto
• La qualità non era adatta
• Il software realizzato non soddisfaceva i bisogni di chi lo commissionava

Alla conclusione della conferenza si capì la necessità di un approccio metodico per lo sviluppo del software.

Nel 1995, uno studio dimostrò che della totalità dei progetti software delle grandi aziende, solo il 16% era senza problemi. Le maggiori cause erano:

• Mancanza di input da parte del cliente
• Incompletezza dei requisiti e delle specifiche
• Cambiamento dei requisiti e delle specifiche nel corso dello sviluppo

Legge di Brooks

Se avete un progetto software in ritardo e aggiungete persone al progetto, quest’ultimo ritarderà ancora di più. Questo si scontra col pensiero delle aziende che misurano il tempo di sviluppo di un software in Mesi-Uomo.

La legge di Brooks si rivela veritiera perché spesso i compiti da portare a termine nello sviluppo non possono essere divise o essere eseguite in parallelo. Inoltre, il problema della comunicazione tra le persone, soprattutto in grandi team, rallenta ancora di più.

2Il numero di comunicazioni cresce del quadrato rispetto alle persone.[ O(n )].

Il grafo mostra che anche se all’inizio, l’aggiunta di persone ne fa diminuire il tempo, ad un certo punto, l’aggiunta peggiorerà solo le cose.

Lo sviluppo del software non è solo un problema di carattere tecnico(legato al linguaggio, etc..). La comunicazione, ad esempio, è un problema di natura sociale e organizzativa, Essa è un fattore chiave.

Nella maggior parte dei casi, il fallimento non è causato da problemi tecnici, ma da problemi non tecnici.

Ingegneria del software si occupa di tutti gli aspetti della produzione del software. Si tratta di un approccio ingegneristico perché è sistematico, standard, e prevede l’utilizzo di modelli, metodi e tools in qualche modo formalizzati. Le attività di produzione non sono solo di scrittura del codice, ma sono anche di natura non tecnica (come la comunicazione accennata in precedenza).

Lezione 2 23/09/2021

Modelli di processo

Per produrre un software sono necessarie diverse attività (tra cui la scrittura, che è solo una piccola parte), come l’analisi e la raccolta dei requisiti. Specialmente in lavori di gruppo, è necessario che ogni attività sia svolta da tutti i componenti allo stesso modo (uniformità).

Al fine di creare questa uniformità, si usano i processi di produzione del software, ovvero si segue un insieme di regole che bisogna seguire per dare uniformità alla produzione appunto del software. Un processo può essere inteso, quindi, come un insieme di regole che gli sviluppatori scelgono di seguire.

Un modello, in generale, è un’astrazione che descrive, in maniera generale, il comportamento e le caratteristiche di qualcosa. Nel nostro caso, è un’astrazione di un processo di produzione del software, in termini di:

• Ruoli. Rispondono alla domanda “chi fa che cosa?”. Si divide il lavoro tra le varie persone, che hanno differenti conoscenze/abilità, svolgendo diverse attività e avendo diverse responsabilità. Il mapping tra ruoli e persone non è necessariamente 1 a 1. Inoltre le persone che ricoprono i ruoli possono cambiare, basti pensare a progetti che durano per anni; le persone che iniziano il progetto potrebbero non essere le stesse che lo terminano.
• Tasks. Sono le unità di lavoro assegnate ai vari ruoli. Un task ha degli input e degli output che possono essere di varia natura: documenti, codice, modelli del sistema che si vuole realizzare. I modelli del sistema sono un’astrazione del software da realizzare, come ad esempio i diagrammi delle classi, dal quale si ricavano classi e metodi (ma non sono l’effettivo codice).

A cosa ci serve un’astrazione, ovvero un modello? Servono innanzitutto per la comunicazione. Se c’è bisogno di organizzazione per la suddivisione di task, ad esempio, avere un diagramma delle classi favorisce la comunicazione. Anche mostrare al cliente un automa a stati finiti serve a capire se si è compreso il problema.

Successivamente, i modelli possono essere usati per verificare alcune proprietà del sistema prima di costruirlo. In fase di progettazione si deve definire come verrà fatto il sistema per assicurarsi di raggiungere certi obiettivi. Serve a prevenire perdite di tempo.(Es. nella produzione di un database, si effettua la normalizzazione, che si effettua nel modello logico, per vedere se il modello del database rispecchia alcune caratteristiche e non presenta problemi).

Le task hanno anche delle entry e delle exit condition. L’inizio di un’attività è molto semplice da inquadrare (es. inizio a scrivere il codice quando ho a disposizione il diagramma delle classi). La fine di un task si definisce in vari modi, anche a seconda del tipo di task (es. fine della scrittura del codice, quando viene testato o quando vengono forniti gli opportuni documenti). Risulta importante che tutti seguano lo stesso criterio.

• Linee Guida. Forniscono delle indicazioni agli sviluppatori su come svolgere delle determinate attività: best practices, goals, priorities, errori comuni, etc...

Normalmente si è portati a utilizzare questo tipo di approccio per lo sviluppo di un software, almeno per programmi piccoli. Non va sicuramente bene per programmi software grandi e che vengono sviluppati da più persone.

Un processo, anche semplice come quello in figura. può essere visto come “un gioco”, con diversi ruoli etc…, nel quale se non si seguono le regole, il “gioco” viene meno. La stessa cosa vale per i modelli di processo, nel quale ci sono regole che definiscono il modo di agire per sviluppare il software.

Attività da svolgere nello sviluppo del software

• Analisi dei requisiti. Si definisce cosa deve fare il sistema e quali sono i vincoli da rispettare (es. il tempo da rispettare nell’esecuzione di una funzione, oppure non deve occupare più di un tot di memoria)
• Design. Definizione della struttura del software. Significa realizzare una serie di modelli, e avviene prima della scrittura effettiva del codice
• Implementazione. scrittura del codice. Non è un’attività meccanica. Richiede comunque decisioni, seppur marginali, che troviamo anche nella parte di design.
• Integrazione e testing
• Rilascio e Manutenzione

Modelli di processo

Modello a cascata

Le attività da svolgere vengono effettuate in maniera strettamente sequenziale

Questo schema mostra che ogni attività viene svolta nella sua interezza prima di passare a quella successiva. Ogni fase prende come input, gli output della fase precedente.

Questo tipo di modello consente comunque al programmatore di tornare indietro nel caso in cui vengono rilevati problemi. Nel caso ideale, ogni attività viene svolta solo una volta.

Il problema è che a volte i problemi fanno tornare alla prima fase, creando ritardi nel rilascio e costi aggiuntivi.

Questo tipo di processo è molto intuitivo, ha dei vantaggi dal punto di vista manageriale, consentendo una gestione lineare dell’intero processo. É facilmente intuibile lo stato del processo, conoscendo la fase in cui ci si trova.

Il problema è in termini di flessibilità: quando ci sono cambiamenti nel corso dello sviluppo, risulta complicato soddisfare i cambiamenti.

Il cliente, inoltre, riceve il software solo alla fine; quindi se non sarà soddisfatto, potrebbe essere necessario ricominciare da capo.

Una variante del modello a cascata, che risolve in parte i problemi, è il modello a cascata con feedback ad ogni fase.

Ci sono però dei contesti in cui questo tipo di modello è vantaggioso da utilizzare. Per progetti di grandi dimensioni, è facile per la suddivisione dei compiti. Un altro caso è quando si deve essere estremamente sicuri della qualità del prodotto, per esempio per sistemi di sicurezza, non è accettabile la presenza di bug, o comunque con possibilità minime. Per avere questa sicurezza, va fatta una verifica per ogni fase dello sviluppo, non limitandosi soltanto al testing finale.

In realtà per questo tipo di software, si usa la variante V-MODEL.

Per ogni fase del modello che “costruisce” qualcosa, c’è una fase speculare che va a fare una verifica di quello che è stato costruito. Questo garantisce una perfetta realizzazione.

Modelli iterativi

Il modello a cascata, come intuibile, è utilizzabile solo quando non si vanno a verificare degli errori oppure la probabilità che si verifichino è molto bassa. Questo non accade quasi mai. I modelli iterativi mettono già in conto la possibilità di errori, per cui già preventivamente si sa che ogni fase non verrà fatta una sola volta.

Modello incrementale

In questo tipo di modello si hanno diversi rilasci del software (a pezzi). Questi pezzi potrebbero essere componenti singole (es. sviluppo un IDE e una componente è l’editor, oppure il compilatore). Questo in realtà non è la soluzione più adottata. Viene scelto di rilasciare di volta in volta un insieme crescente di funzionalità.

Il vantaggio sta nella comunicazione con il cliente, che ha sempre qualcosa su cui darci feedback così da far capire cosa va bene e cosa non va. Se spesso i progetti falliscono per colpa di richieste non soddisfatte, i modelli incrementali risolvono questo problema.

Ogni iterazione del ciclo mi permette di aggiungere funzionalità che non c’erano nel ciclo precedente.

Alcuni progetti software non hanno la validazione del sistema (es. un sistema operativo) perchè progettati per evolversi sempre, senza avere una reale conclusione.

Si vedono sempre più progetti che prevedono delle release a scadenza prefissata.

I vantaggi sono che il cliente ha subito il sistema funzionante, anche se solo per alcune funzionalità, ma soprattutto consente di avere feedback ed evita fallimenti del software.

Si dà anche più enfasi ai task più importanti, inserendo nelle prime release le funzionalità più importanti per il cliente.

Spesso modelli incrementali e iterativi vengono definiti come modelli diversi.

In teoria sono indipendenti, ma nella pratica ogni processo incrementale è iterativo e viceversa. Ai fini del corso verranno usati come sinonimi.

Lezione 3 27/09/21

Analisi dei requisiti (capitolo 6 del libro)

L’analisi dei requisiti è una parte del processo di creazione di un software che serve a capire cosa dovrà fare l’applicativo e anche gli eventuali vincoli a cui il programma deve sottostare per soddisfare le esigenze del cliente.

Risulta essere uno dei momenti più importanti, perché eventuali errori hanno ripercussioni su tutto il processo.

È una fase delicata che richiede un’adeguata preparazione, non può essere fatta in maniera approssimata, e richiede tempo per essere effettuata in modo opportuno.

A volte il tempo totale che si va a utilizzare per l’analisi dei requisiti rappresenta una grande fetta del tempo totale del progetto.

La situazione in cui ci si può normalmente trovare è quella in cui l’azienda deve effettuare un preventivo sul costo di realizzazione del software, ma per fare ciò è necessario comunque avere a disposizione i requisiti (se non sappiamo cosa fare è impossibile poter effettuare una stima).

Come si risolve questa situazione di “ricorsione”?

Ci sono 2 modi:

• L’analisi dei requi