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

2

Il 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