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/Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 dominio 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 Artifact 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 collaborazione 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 chiamato “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 Operations al fine di distribuire codice in produzione più velocemente e in maniera automatizzata e ripetibile.

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

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.

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 quantificando 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.
• Automation expert Poiché una delle basi DevOps è l’automation, questo ruolo è fondamentale. Gli Automation 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 sviluppatori, 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 la8 metodologia DevOps. La necessità di 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 ridurre 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/Release

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, release, master, ecc) possiamo definire quali sono le attività di controllo qualità che devono essere attivate a seguito di ogni cambiamento che può comparire 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 pipeline di distribuzione continua è un’implementazione del paradigma continuo, in cui build, 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