Riassunto processo e sviluppo del software

Riassunto Processo e Sviluppo del Software

Ottobre 2020

1

Indice

1 Introduzione al DevOps 6

1.0.1 Perché usare DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.0.2 Cosa è DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.0.3 DevOps vs Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.0.4 I ruoli nel DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.0.5 Principi DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.1 Build/Test/Relase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.1.1 Continuous delivery pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.2 Deploy/Operate/Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.3 Deployable Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.3.1 Macchine Virtuali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.3.2 Containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.3.3 Bare Metal e server dedicato . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.4 Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Risk Management 13

2.1 Cos’è un rischio? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.1 Unsatisfactory Outcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.2 Qual è la causa di un rischio? . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Classi di rischi e gestione dei rischi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.1 Identificazione del rischio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.2 Analisi dei rischi individuati . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.3 Prioritizzazione dei rischi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.4 Piano di gestione del rischio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.5 Monitoraggio dei rischi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3 Risposte quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Capability Maturity Model Integration 17

3.1 Componenti del modello CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2 Conformità a un’area di processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.1 Conflitto o compatibilità tra CMMI e Agile . . . . . . . . . . . . . . . . . . . 19

3.3 Risposte quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2

4 Requirements Engineering 20

4.1 Requisiti nel ciclo di vita del software . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2 Perché lavorare sul Requirements Engineering è difficile? . . . . . . . . . . . . . . . . 21

4.3 Tipi di requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.3.1 Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.3.2 Categorie dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.3.3 Qualità dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.3.4 Errori in un documento dei requisiti . . . . . . . . . . . . . . . . . . . . . . . 24

4.3.5 Difetti in un documento di requisiti . . . . . . . . . . . . . . . . . . . . . . . . 24

4.4 Il processo di ingegneria dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.4.1 Comprensione del domino ed elicitazione . . . . . . . . . . . . . . . . . . . . . 25

4.4.2 Valutazione e accordo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.4.3 Specifica e documentazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.4.4 Validazione e verifica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.5 Risposte quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5 Comprensione del dominio ed elicitazione dei requisiti 26

5.1 Stakeholder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.1.1 Selezione degli stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.1.2 Identificazione degli stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.1.3 Interazione con lo stakeholder . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.1.4 Analisi degli stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.2 Tecniche di elicitazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.2.1 Atrifact driven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.2.2 Stakeholders driven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6 Valutazione dei requisiti 32

6.1 Gestione dell’incoerenza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6.1.1 Tipi di incoerenza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6.1.2 Gestione delle incongruenze . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.1.3 Gestione dei conflitti: un processo sistematico . . . . . . . . . . . . . . . . . . 34

6.2 Prioritizzazione dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.3 Risposte quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3

7 Documentazione dei requisiti 39

7.1 Documentazione libera in linguaggio naturale senza restrizioni . . . . . . . . . . . . . 40

7.2 Documentazione disciplinata in linguaggio naturale strutturato . . . . . . . . . . . . 40

7.2.1 Regole locali sulla scrittura dei requisiti . . . . . . . . . . . . . . . . . . . . . 40

7.3 Regole globali sull’organizzazione del documento dei requisiti . . . . . . . . . . . . . 42

7.4 Diagrammi - Notazione semi formale . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

7.4.1 Scopo del sistema: diagrammi del contesto, problema e frame . . . . . . . . . 43

7.4.2 Strutture concettuali: diagrammi entità-relazione . . . . . . . . . . . . . . . . 45

7.4.3 Attività e dati: diagrammi SADT . . . . . . . . . . . . . . . . . . . . . . . . . 45

7.4.4 System operations: diagramma dei casi d’uso . . . . . . . . . . . . . . . . . . 47

7.4.5 Scenari di interazione: diagrammi di traccia degli eventi . . . . . . . . . . . . 47

7.4.6 Comportamenti del sistema: diagrammi della macchina a stati . . . . . . . . 48

7.4.7 Stimoli e risposte: diagrammi R-net . . . . . . . . . . . . . . . . . . . . . . . 48

7.4.8 Integrazione di più viste di sistema e la specifica multiview in UML . . . . . 49

7.5 Specifica formale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

7.5.1 Logica come base per la formalizzazione delle dichiarazioni . . . . . . . . . . . 50

7.5.2 Specifiche basate sulla storia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

7.5.3 Specifica basata sullo stato . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7.5.4 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7.6 Risposte quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

8 Requirements Quality Assurance 52

9 Evoluzione dei requisiti 54

9.1 Anticipazione dei cambiamenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

9.2 Gestione della tracciabilità a supporto dell’evoluzione . . . . . . . . . . . . . . . . . . 55

9.3 Tecniche di gestione della tracciabilità . . . . . . . . . . . . . . . . . . . . . . . . . . 56

9.4 Risposte quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

10 Model View Controller 58

10.1 Design Patterns - Controller Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

10.1.1 Page Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

10.1.2 Front Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

10.1.3 Intercepting Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

10.1.4 Application Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4

10.2 Design Patterns - View Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

10.2.1 Template View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

10.2.2 Transformation View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

10.2.3 Two-Step View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

10.3 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

10.4 Risposte quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

11 Object Relational Mapping 65

11.1 Data Source Architectural Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

11.1.1 Table Data Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

11.1.2 Row Data Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

11.1.3 Active Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

11.1.4 Data Mapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

11.2 Object-Relational Behavioral Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . 70

11.2.1 Unit of Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

11.2.2 Identity Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

11.2.3 Lazy Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

11.3 Object-Relational Structural Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . 73

11.3.1 Identity Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

11.4 Risposte quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5

1 Introduzione al DevOps

DevOps è un insieme di processi, metodi e strumenti indirizzati alla comunicazione ed alla collabo-

razione e punta ad aiutare un’organizzazione a sviluppare in modo più rapido ed efficiente prodotti

e servizi software. Quindi uno dei primari obiettivi del DevOps è quello di costituire un ecosistema

di strumenti e processi operativi che permettano di abbattere quello che comunemente viene chia-

mato “Wall of Confusion” e che nei modelli “tradizionali” separa il mondo Development dal mondo

delle Operations. Per permettere l’adozione della metodologia DevOps serve intervenire su fattori

organizzativi ed infrastrutturali quali:

• Utilizzo della metodologia agile per lo sviluppo del software;

• Incremento della frequenza dei rilasci in produzione

• Automazione dei processi di build, test e deploy

• Disponibilità di un’infrastruttura virtualizzata e/o in cloud

1.0.1 Perché usare DevOps

I problemi tipici del non uso di DevOps sono:

• Il team di sviluppo e quello operativo lavorano in completo isolamento

• I membri del team trascorrono gran parte del loro tempo in testare, distribuire e progettare

invece di sviluppare progetto 6

• La distribuzione manuale del codice porta a errori umani in produzione

• I team di codifica e operations hanno le loro tempistiche separate e non sono sincronizzati

causando ulteriori ritardi

1.0.2 Cosa è DevOps

DevOps è una cultura che promuove la collaborazione tra i team Sviluppo (Development) e Ope-

rations al fine di distribuire codice in produzione più velocemente e in maniera automatizzata e

ripetibile. E’ un approccio di sviluppo software che coinvolge:

• Continuous Development: pianifica gli obiettivi dell’applicazione e codificare i requisiti

• Continuous Integration: pianifica i test e crea il prodotto

• Continuous Testing: verifica il prodotto per l’utilizzo effettivo in un ambiente live

• Continuous Deployment: assicura che il prodotto venga distribuito con la massima precisione

• Continuous Monitoring: monitorare l’output del prodotto e individuare le aree problematiche

sul software durante il suo ciclo di sviluppo e in genere sfrutta la virtualizzazione e la containerizza-

zione.

1.0.3 DevOps vs Agile

DevOps è l’estensione dei principi agili dallo sviluppo del software alla distribuzione del software.

Laddove l’evoluzione innescata dal Manifesto Agile ha affrontato modi migliori per creare software,

DevOps applica principi e filosofie simili all’intero del ciclo di vita dello sviluppo del software,

portando lo sviluppo agile fino al rilascio.

Feature DevOps Agile

Processi e pratiche Focus su: CD, CI, CT, CD, CM Focus su: Extreme programming, Scrum, ..

Fonte del feedback Da tool di monitoring Dal cliente

Agilità Nello sviluppo e operations Nello sviluppo

Obiettvo Agilità e automazione Agilità e in parte automazione

1.0.4 I ruoli nel DevOps

La chiave DevOps è una maggiore collaborazione tra developer e operations; per attuare ciò occorre

quindi ripensare i ruoli di sviluppo e operations esistenti e riorientarli attorno alla fornitura di

software continui, dalle idee e dallo sviluppo alla produzione e alla manutenzione.

7

• DevOps Evangelist

Questa figura si occupa di promuovere i vantaggi che DevOps porta, identificando e quantifi-

cando i benefici aziendali derivanti dalla maggiore agilità che tale metodologia offre. In qualità

di “leader del cambiamento", il DevOps Evangelist garantisce il coinvolgimento dei team di

sviluppo e operations, identifica i ruoli chiave per supportare i metodi di implementazione

delle pratiche e garantisce che i professionisti IT siano qualificati e autorizzati a effettuare tali

modifiche.

• Code Release Manager

I release manager lavorano per indirizzare la gestione e il coordinamento del prodotto, dallo

sviluppo alla produzione. In genere lavorano su più dettagli tecnici e problematiche in cui

un project manager tradizionale non sarebbe coinvolto. I release manager supervisionano il

coordinamento, l’integrazione e il flusso di sviluppo, test e implementazione per supportare il

rilascio continuo.

• Automatione expert

Poiché una delle basi DevOps è l’automation, questo ruolo è fondamentale. Gli Automa-

tion Architect analizzano, progettano e implementano strategie per il continuous deployment,

garantendo al contempo un’elevata disponibilità sui sistemi di produzione e di pre-produzione.

• Software Developer/Tester

All’interno di un’organizzazione DevOps il nuovo ruolo di Software Developer/Tester è al centro

del processo e aumenta drasticamente la portata delle relative responsabilità. Gli sviluppatori

in ambito DevOps sono infatti responsabili non solo di trasformare nuovi requisiti in codice, ma

anche di eseguire attività di testing, di distribuzione e monitoraggio continuo. Spesso questo

passaggio include l’esecuzione di più test automatizzati, in modo tale che la qualità del codice

non ne risenta.

• Security Engineer

Le organizzazioni DevOps devono avere dei security engineer che lavorino a fianco degli svi-

luppatori, esprimendo le loro raccomandazioni in fasi iniziali all’interno del processo. Si parla

in questo caso di “security by design”, per dire che la sicurezza dev’essere insita all’interno

dell’applicativo realizzato.

• Quality Assurance / L’Experience Assurance

Essendo la funzione di Quality Assurance (QA) spesso parte del processo di sviluppo del

software, diventa necessario un nuovo tipo di controllo quando le organizzazioni adottano la

8

metodologia DevOps. La necessità dei un tester QA viene quindi sostituita dalla necessità

di esperti XA incaricati di garantire che tutte le nuove funzionalità e caratteristiche vengano

rilasciate tenendo conto dell’esperienza dell’utente finale.

1.0.5 Principi DevOps

Ecco sei principi essenziali quando si adotta DevOps:

1. Azione incentrata sul cliente: Il team DevOps deve prendere azioni incentrate sul cliente, per

questo deve investire costantemente in prodotti e servizi.

2. Responsabilità end-to-end: Il team deve fornire supporto fino alla fine del ciclo di vita. Questo

aumenta il livello di responsabilità e di qualità del prodotto.

3. Miglioramento continuo: La cultura DevOps si concentra sul miglioramento continuo per ri-

durre al minimo gli sprechi. Accelera continuamente il miglioramento del prodotto o dei servizi

offerti.

4. Automatizza tutto: l’automazione è un principio vitale del processo DevOps. Questo non è

solo per lo sviluppo del software, ma anche per l’intero panorama infrastrutturale.

5. Lavora come un unico team: nella cultura DevOps, il ruolo di designer, sviluppatore e tester

è già definito. Tutto quello che si deve fare è lavorare come un team con una collaborazione

completa.

6. Monitorare e testare tutto: è molto importante per il team DevOps disporre di solide procedure

di monitoraggio e test.

1.1 Build/Test/Relase

Lo sviluppo su molteplici branch si collega alle operazioni di verifica che possono essere attivate

automaticamente a seguito dell’evoluzione del codice su ogni branch. Avendo ogni branch una sua

semantica (feature, relase, master, ecc) possiamo definire quali sono le attività di controllo qualità

che devono essere attivate a seguito di ogni cambiamento che può compatire all’interno del sistema

di Version Control. 9

Figura 1: Un branch rappresenta una linea di sviluppo indipendente

1.1.1 Continuous delivery pipeline

Una è un’implementazione del paradigma continuo, in cui build,

pipeline di distribuzione continua

test e distribuzioni automatizzati sono orchestrati come un flusso di lavoro di rilascio. I punti chiave

da rispettare sono:

• Qualità: nessuna consegna di codice difettoso.

• Frequenza: eseguibile ogni volta che serve

• Prevedibilità: esito deterministico

La pipeline si può dividere in di