TECN.PROG.SIST.INF. Ciclo di vita del software Roberta Gerboni 1

Transcript

1 Roberta Gerboni 1

2 Perché si parla di Ingegneria del software Queste vignette umoristiche vogliono mettere in evidenza le contraddizioni e i paradossi che spesso emergono fin dalle prime fasi di analisi e poi successivamente proseguono nelle fasi di progettazione, realizzazione e consegna di un software con la grave conseguenza che il programma sviluppato non fa quello che il committente pensava di aver chiesto. 2

3 Ingegneria del software La dimensione dei software in LoC (Line of Code) è notevolmente aumentata negli ultimi 50 anni. Esempio - progetti della NASA: Sonda Mercury (1962) software con 1 milione di LoC Apollo 11 (1969) 11 milioni di LoC Shuttle (1981) 37 milioni di LoC Telescopio Hubble (1990) 80 milioni di LoC All aumentare della dimensione del software aumenta anche la difficoltà nelle varie fasi della sua progettazione, produzione e manutenzione nel tempo. Questo è stato compreso fino dalla realizzazione dei primi programmi, ma con il passare del tempo gli sforzi si sono concentrati sempre più nel fornire delle metodologie di riferimento per gli analisti, i progettisti e i programmatori. 3

4 Ingegneria del software Alcuni dei principali problemi della produzione del software sono: Ritardi dei progetti (dovuti a difficoltà nelle fasi iniziali, specifiche incomplete, cambi di piattaforma) Incomprensioni, già in fase di analisi, per il diverso linguaggio usato da clienti-committenti e fornitori-produttori del software Obsolescenza prematura Incompetenza dei realizzatori nel raggiungere gli obiettivi Cattivo coordinamento tra i realizzatori Malfunzionamenti dovuti a un collaudo non eseguito in modo scrupoloso o addirittura l assenza di un sistema di validazione; (c è da tenere presente anche che il collaudo rivela la presenza di errori, NON la loro assenza) Esaurimento di fondi L'ingegneria del software cerca di porre rimedio a tutto questo, studiando metodologie per controllare il software ed il suo processo di produzione. 4

5 Ingegneria del software L evoluzione nella realizzazione del software Guardando al passato l utilizzo dei computer aumentò durante la seconda guerra mondiale. La straordinaria potenza di calcolo e di automazione di un calcolatore consentiva attività complesse difficilmente eseguibili manualmente in tempi brevi. Infatti i primi utilizzatori sono essenzialmente matematici, fisici, ingegneri che utilizzano il computer per eseguire complessi calcoli. In questa fase: si utilizzano linguaggi di programmazione a basso livello (strumenti semplici); chi sviluppa software è un tecnico che si esprime in modo rigoroso e formalizzato; l'applicazione sviluppata nonhanecessità disopravvivere a lungo.... 5

6 Ingegneria del software... Questa situazione è andata modificandosi e grazie all'avvento dei "programmi gestionali" il computer ha potuto permettere la gestione, non più di soli numeri, ma anche di informazioni che vengono utilizzate in modo strategico per fare delle scelte economiche, gestionali, ecc. Grazie a questo sviluppo aumenta il divario tra chi produce software (programmatore) e chi lo utilizza (utente) in quanto l'utente non ha né il tempo né la voglia di imparare ad utilizzare gli strumenti di programmazione. La complessità delle applicazioni cresce notevolmente ed è per questo che accanto agli elaboratori elettronici di dati (Electronic Data Processing) interni delle aziende, nascono le software house.... 6

7 Ingegneria del software... Si passa così dalla fase iniziale, individuale e creativa (software come arte) ad una fase caratterizzata da piccoli gruppi di esperti (software come artigianato) che producono software professionale. Ed è proprio dopo questo passaggio che aumenta la quantità di software prodotto ed innesca riflessioni su: la produttività dello sviluppo del software come aumentare la qualità finale del prodotto. Si passa così gradualmente alla produzione di software come industria, intendendo un processo di sviluppo che coinvolge molte persone su progetti di grosse dimensioni e che deve essere pianificato ed automatizzato il più possibile. Inoltre si pone anche il problema di certificare la qualità dei prodotti con metodologie standard. Programmi realizzati singolarmente o da piccoli gruppi di tecnici specializzati Programmi realizzati da software house Software realizzato da Aziende produttrici di software (industrie) 7

8 Ingegneria del software Qualche notizia 1967 viene istituito un comitato scientifico della NATO per lo studio e lo sviluppo del software ad una conferenza NATO organizzata a Garmisch (Germania) venne coniato il termine Ingegneria del software proprio per rimarcare l'esigenza che la produzione di software diventasse una disciplina ingegneristica e quindi basata su solide basi teoriche e metodologiche che permettessero la progettazione, produzione e manutenzione di applicazioni che fornissero caratteristiche di qualità mediante l'uso delle risorse. Dal 1972 e fino al 1988 vengono introdotte nuove tecnologie e nascono i sistemi distribuiti; il costo dell'hardware si abbassa considerevolmente e di conseguenza la tecnologia informatica comincia a diffondersi rapidamente. Ancora oggi le aziende pongono l'accento sulla necessità di definire processi di sviluppo del software che consentano di rispettare le scadenze fissate per ridurrei costidi realizzazione. 8

9 Ingegneria del software Lo sviluppo di sistemi software è un attività intellettuale complessa, che coinvolge una pluralità di soggetti diversi tra loro. L ingegneria del software (software engineering) si occupa dello studio delle metodologie relative alla: - Progettazione (studio di un problema e individuazione di una soluzione informatica ) - Produzione: (fasi che portano alla stesura di un programma in un linguaggio di programmazione e al suo funzionamento per l utente finale) - Riusabilità (possibilità di usare parti di software già realizzati per crearne di nuovi) - Manutenzione (attività di modifica e aggiornamento di un software per poter continuare ad usarlo nel tempo) di un prodotto o di un servizio software migliorandone la qualità e rispettando i tempi e i costi preventivati. L'Ingegneria del Software è un insieme di teorie, metodi, strumenti e tecniche appropriate per sviluppare software di qualità in maniera professionale 9

10 Ingegneria del software Il software NON è solo programmi, ma l insieme di tutto ciò che viene prodotto durante il suo sviluppo e la documentazione associata (manuale di configurazione, manuale utente...). La sua produzione, a differenza di ciò che avviene in altri settori, non può essere automatizzata perché è ad alta intensità di lavoro del cervello (brain intensive). Mentre la produzione dell hardware è stata automatizzata e il suo sviluppo è andato incredibilmente veloce guadagnando 6 ordini di grandezza nel rapporto prestazioni/costo in 30 anni, la produzione del software ha richiesto e richiede tempi molto più lunghi. 10

11 Il software da realizzare può essere: Ingegneria del software Generico: Personalizzato: Sviluppato per essere venduto ad una vasta gamma di utenti. Si parla in questo caso di pacchetti software. I numerosi utenti che li acquistano contribuiscono alla maggior spesa della realizzazione del software. Sviluppato per un utente specifico in base alle sue esigenze. Richiede maggiore sforzo per lo sviluppo. e le principali caratteristiche di qualità di un prodotto software sono: Funzionalità Affidabilità Efficienza Usabilità Portabilità Manutenibilità Deve soddisfare i requisiti stabiliti Ci si deve poter fidare del prodotto Software Correttezza Robustezza Verificabilità Sicurezza Non deve sprecare risorse (memoria, tempo,...) Deve avere interfaccia e documentazione appropriate Si deve poter eseguire facilmente su più piattaforme Deve poter evolvere in rapporto alla modifica di requisiti che deve avere 11

12 Ingegneria del software Lo sviluppo del software e la progettazione dell'hardware sono attività profondamente diverse. Il software non si consuma come avviene per l hardware, tuttavia si deve tener presente la frequenza dei malfunzionamenti dovuti a modifiche apportate nel tempo. 12

13 Ingegneria del software Fattori che incidono sul costo della manutenzione del software Stabilità del team I costi di manutenzione si riducono se lo stesso staff si occupa della manutenzione per lungo tempo. Responsabilità contrattuale Sviluppo e manutenzione sono talvolta appaltati ad aziende diverse, cosicchè chi sviluppa non ha interesse a semplificare il lavoro di chi effettuerà la manutenzione. Capacità dello staff Chi si occupa della manutenzione potrebbe non avere lo stesso livello di esperienza e pratica di chi lo ha sviluppato. Età e struttura del programma Gli interventi di modifica e aggiornamento nel tempo tendono a far deteriorare la qualità del software e quindi a rendere più difficili tutti gli interventi di manutenzione necessari. 13

14 Ingegneria del software Manutenzione di un software non significa solo eliminare le anomalie dopo il suo rilascio, ma anche migliorare le prestazioni, adattarlo a mutamenti dell ambiente operativo e/o del dominio applicativo, modificare il prodotto rispetto a nuove esigenze. Le modifiche spesso sono causa di profonde ristrutturazioni del prodotto e si parla quindi di nuova versione (major release), revisione e release (minor release) che viene rilasciata e che può integrare o sostituire quella precedente. per determinare se i requisiti di una specifica sono soddisfatti Il test di regressione serve a garantire che le modifiche apportate non abbiano introdotto nuovi errori 14

15 Ingegneria del software Le modifiche apportate ad un software nel tempo incidono in maniera pesante sui costi di manutenzione. La manutenzione può essere: correttiva: adattativa: per eliminare i malfunzionamenti segnalati per far fronte a cambiamenti del sistema elaborativo, dell ambiente di funzionamento, delle normative... migliorativa: miglioramento di aspetti non funzionali (prestazioni, efficienza, interfaccia...) evolutiva: aggiunta di nuove funzionalità ed eliminazione di quelle inutili 15

16 Ingegneria del software Più della metà dei costi di un progetto software sono spesi per la manutenzione. Molti testi fanno riferimento alla regola dell 80-20, ossia: - l 80% di sforzo è speso per la manutenzione - il 20% per lo sviluppo. In particolare le modifiche incidono sempre di più se vengono fatte nelle fasi successive al rilascio del sotfware, rispetto ad averle eseguite durante le prime fasi di analisi e progettazione. Si può arrivare fino a un costo 100 volte superiore. 16

17 Il ciclo di vita di un software definisce un modello per il software, dalla sua concezione iniziale fino al suo sviluppo completo e collaudo, al suo rilascio, alla sua successiva evoluzione, fino al suo ritiro. Il ciclo di vita consiste delle seguenti fasi: Lo studio e ideazione La progettazione lo produzione o sviluppo Ciclo di vita del software (si studia l area di competenza per conoscere la materia e creare un astrazione del prodotto da realizzare definendo le caratteristiche che deve avere) (si formalizza tramite la stesura di documentazione corredata di disegni e modelli. In questa fase possono essere realizzati dei prototipi) (si scrive il software attinendosi alle specifiche della fase di progettazione; è la realizzazione del prodotto software) il suo rilascio la gestione e manutenzione il ritiro del software (riguarda la consegna e l installazione fatta presso il cliente) (riguarda la correzione degli errori, gli aggiornamenti e il supporto ai clienti) (riguarda la fine del suo uso ed una eventuale sua sostituzione con un nuovo applicativo) 17

18 Ciclo di vita del software La realizzazione di un progetto prevede delle fasi operative di codifica e test e altre di gestione del progetto di analisi, pianificazione e documentazione. Nei seguenti grafici vengono riportate le percentuali di tempo dedicate alle varie fasi operative e di pianificazione e documentazione necessarie per la realizzazione di un progetto software. 45% Suddivisione del tempo dedicato ad un progetto software 5% 10% 20% 20% Pianificazione Analisi e progettazione Programmazione effettiva Documentazione Test e controllo qualità Suddivisione del tempo dedicato ad un progetto software 35% Manutenzione 65% Sviluppo 18

19 Si parla di approccio metodologico ai progetti. Una metodologia è un insieme di metodi, procedure, regole, tecniche e linguaggi e deve rispettare determinate condizioni. Essere: Ciclo di vita del software Documentata cioè esistono documenti che descrivono la metodologia stessa e le procedure di cui si compone Ripetibile si deve poter applicare in diversi casi Basata su tecniche consolidate già provate e accettate Validata cioè usata con successo in un cogruo numero di applicazioni Appropriata cioè idonea al contesto Gli aspetti che una metodologia deve coprire sono: Aspetto funzionale: cosa devono fare le varie componenti diun sistema Aspetto temporale: quando devono essere fatte e come si devono sincronizzare le diverse attività o eventi del sistema Aspetto dei dati: come vanno descritti i dati su cui le varie componenti del sistema devono lavorare 19

20 Ciclo di vita del software Esistono parecchie metodologie di progetto che si sono sviluppate negli anni per venire incontro alle esigenze dei progettisti e dei programmatori. I principali modelli sono: A cascata A prototipazione rapida Incrementale Iterativo A spirale Metodologie agili 20

21 Ciclo di vita del software Vediamo in dettaglio le diverse fasi che consentono di realizzare un software 1. Studio di fattibilità (cosa) Definizione di che COSA deve essere fatto e non come deve essere fatto! stabilire se lo sviluppo debba essere avviato (COSTI/BENEFICI) quali le alternative possibili e le scelte più ragionevoli; ad esempio si valuta se il prodotto deve essere realizzato oppure comprato stima delle risorse finanziarie e umane necessarie, per ciascuna possibile soluzione redazione di un un Documento di Fattibilità. In pratica ci dobbiamo chiedere: 2. Analisi e specifica dei requisiti siamo in grado di farlo? Ne vale la pena? In caso affermativo, produciamo un Documento. CAPIRE il problema e formularlo correttamente per chi deve risolverlo. Il cliente può essere il mercato. Definizione del problema, tramite interviste con il commitente, di funzioni, vincoli, prestazioni, interfacce e di qualsiasi altra caratteristica che il sistema dovrà soddisfare. redazione di un Documento di Specifica dei Requisiti Software, che sia completo, preciso, consistente, non ambiguo, comprensibile sia al committente che allo sviluppatore da passare alla fase di progettazione. 21

22 Ciclo di vita del software 3. Progettazione (come) Capito il problema nelle fasi precedenti, si cerca di trovare una SOLUZIONE al problema. Si parte dal Documento di Specifica e si cerca di capire COME realizzarlo definizione dell architettura del sistema: definizione macroscopica dei componenti del sistema e delle relazioni tra questi (progetto di alto livello High Level Design HLD ) e, via via, saranno definiti i dettagli definizione della struttura interna di ciascun componente (progetto di dettaglio Low Level Design LLD). definizione della struttura dei dati e delle interfacce utente. redazione di un documento di Specifica di Progetto. 4. Sviluppo e codifica (realizzazione vera e propria) Implementazione dei vari componenti definiti nel Progetto. Vengono tradotti tutti i componenti individuati nel progetto in codice (in realtà non si tratta solo di tradurre maoccore una buone dose di intuizione e creatività) 22

23 Ciclo di vita del software 5. Testing (verifica del corretto funzionamento) Definizione ed esecuzione di casi di prova sia per i singoli componenti (Test delle singole unità) che per l intero sistema con l intento di rilevare malfunzionamenti. Qui possono essere eseguite due metodologie: Black-box testing (se vengono controllate le risposte del sistema immettendo opportuni input e osservando i valori degli output senza conoscere minimamente il codice sorgente o comunque ignorandolo ). White-box testing è un testing strutturale, poichè utilizza la struttura interna del programma per ricavare i dati di test. Si possono formulare criteri di copertura più precisi di quelli formulabili con il Black Box testing e ci possono fornire maggiori indicazioni per il debugger sulla posizione dell errore. 6. Installazione /distribuzione (messa in esercizio, deployment) Insieme di tutte le operazioni necessarie per il rilascio, l installazione sul campo e rendere operativo il sistema realizzato presso il committente. 7. Manutenzione Modifica di un sistema o di un componente software dopo il suo rilascio al fine di eliminare anomalie, migliorare le prestazioni, aggiornarlo. 23

24 Ciclo di vita del software 24

25 Modello a cascata (Definito nel 1970 da Royce) Prevede una sequenza di fasi, ciascuna delle quali produce un ben preciso output che viene utilizzato come input per la fase successiva. Pur essendo stato soggetto a profonde critiche negli ultimi decenni (il modello è degli anni 60 del secolo scorso), rimane il metodo di riferimento universalmente accettato, rispetto al quale tutti gli altri risultano delle varianti piuttosto che delle vere alternative. E un modello per sua natura DOCUMENTALE: fase, documento, fase, documento Al completamento di ogni fase si passa alla successiva. Non prevede nessun ritorno all'indietro, considerato dannoso perché impedisce una buona pianificazione e controllo. 25

26 Vantaggi Modello a cascata Svantaggi modello adeguato quando i requisiti sono ben compresi e non soggetti a modifiche.. la fasi da seguire sono ben definite; È semplice da spiegare e da capire: prima si raccolgono tutti i requisiti, poi si fa l'analisi, poi tutto il design, poi la codifica,.... difficile operare cambiamenti una volta che il processo è in corso.. le fasi avanzano in ordine tipicamente sequenziale. Va bene se NON si prevedono cambiamenti futuri. difficoltà a stimare in modo accurato i costi e le risorse necessarie nella fase iniziale del progetto, quando ancora mancano sufficienti elementi di dettaglio. Il documento che specifica i requisiti non sempre soddisfa le effettive esigenze degli utenti perché spesso gli utenti stessi non sono in grado di conoscere e quindi di descrivere con efficacia tutti i requisiti dell'applicazione 26

27 Modello a prototipazione rapida L idea è quella di sviluppare un prototipo usa-e-getta (throw-away prototype) al fine di acquisire esperienza, prima dello sviluppo vero e proprio. Il prototipo è progettato nelle prime fasi di sviluppo di un sistema per agevolare l interazione con l utente in modo da comprendere le sue richieste e dare una migliore definizione dei requisiti del sistema. Questo modello è sicuramente utile quando: i requisiti software inizialmente sono molto confusi e generici scarsità di risorse sistemi di piccole medie dimensioni 27

28 Modelli incrementale ed evolutivo Combinano alcuni aspetti del modello a cascata applicati iterativamente. Questi modelli, adatti a progetti di dimensioni medio-grandi e complessi, sono accomunati dal prevedere più versioni successive del sistema. Ad ogni istante dopo il primo rilascio esistono più sequenze lineari scalate nel tempo: mentre è operativa la release N del sistema viene sviluppata già la release N+1 del sistema Sviluppo incrementale: ogni versione aggiunge nuove funzionalità/sottosistemi Analisi e progettazione vengono fatte all inizio e sono definitive e quindi anche i requisiti lo sono. Il modello incrementale, anche chiamato "miglioramento del prodotto pianificato perchè: Il primo passo incorpora una parte dei requisiti, Il passo successivo aggiunge un'altra parte dei requisiti, e così via, fino a quando il sistema è completo. 28

29 Modelli incrementale ed evolutivo Sviluppo evolutivo (iterativo): da subito sono presenti tutte le funzionalità /sottosistemi che vengono successivamente raffinate e migliorate. Differisce dal modello incrementale perché i requisiti non sono tutti definiti inizialmente. In questo approccio, i requisiti sono parzialmente definiti in modo grezzo, quindi vengono raffinati in ognuno dei passi successivi. Alcune attività nel processo di sviluppo possono operare in serie o in parallelo. Analisi preliminare serve quindi: Per identificare i requisiti di massima Per definire l architettura di massima Per pianificare i passi di analisi e realizzazione evolutiva 29

30 Modelli incrementale ed evolutivo Vantaggi. Un prodotto intermedio è utilizzabile;. Il sistema è partizionato naturalmente in incrementi;. Le risorse possono essere incrementali.. Possibilità di mettere in esercizio le funzionalità in maniera graduale con più rilasci. ACCETTAZIONE DI VERSIONI PARZIALI, prima di passare al passo successivo dello sviluppo. Svantaggi. Risorse limitate a lungo termine. Per il modello incrementale, a causa di un analisi iniziale definitiva:. I requisiti possono non essere compresi correttamente. Difficilmente tiene conto del cambiamento rapido delle tecnologie e dei requisiti. Per il modello evolutivo. Adatto nei progetti in cui non sia tutto chiaro fin dall inizio. Il monitoraggio e l adattamento ai cambiamenti di tecnologia è facilitato 30

31 Modello a Spirale (proposto nel 1988 da Boehm) Ilprocesso di sviluppo è rappresentato come una spirale. Ogni ciclo nella spirale è una fase del processo. Questo modello può essere considerato un proto-modello, cioè un modello astratto che deve essere specializzato. Si può vedere che include i modelli precedenti. Sono, infatti presenti le fasi del modello a cascata, ma i tempi sono più ristretti e dalla fase di Verifica (testing) si torna a quella di studio di fattibilità, di analisi dei rischi e individuazione dei requisiti per applicare eventuali correzioni. Al termine di ogni giro il risultato può essere un progetto, un prototipo, un sistema funzionante o un prodotto software completo. Non ci sono fasi predefinite. Il management del progetto deve decidere come strutturarlo in fasi. 31

32 Modello a Spirale Vantaggi Svantaggi. Valutazione esplicita dei rischi Adatto allo sviluppo di sistemi complessi di grandi dimensioni Interazione con il cliente ad ogni giro della spirale. La stima dei rischi richiede competenze specifiche Se i rischi non vengono valutati correttamente, potranno sorgere problemi nelle fasi successive 32

33 Metodologie agili (proposte nel 1999 da Kent Beck) L insoddisfazione per l eccessivo overhead richiesto dai sistemi di progettazione ha portato negli anni 90 alla creazione dei metodi agili. L'obiettivo è la piena soddisfazione del cliente. I metodi agili sono più adatti per sistemi aziendali di piccole/medie dimensioni o per prodotti per PC. Molte app sono sviluppate in modo agile. Alcuni dei principi su cui si basano tali metodi: si concentrano sul codice, piuttosto che la progettazione e la documentazione sono basati su un approccio iterativo allo sviluppo software sono pensati per rilasciare software funzionante rapidamente e con una frequenza da due settimane a due mesi, per farlo evolvere rapidamente per soddisfare nuove esigenze committenti/clienti e sviluppatori devono lavorare insieme quotidianamente per tutta la durata del progetto consentono cambiamenti nei requisiti anche in stadi avanzati dello sviluppo attenzione sempre rivolta alla buona progettazione e alla semplicità i progetti sono sviluppati da individui motivati 33

34 Metodologie agili 34

35 Metodologie agili Tramite queste metodologie i team di sviluppo software sono in grado di ridurre sensibilmente il rischio di non rispetto dei tempi e/o di commettere errori di interpretazione dei requisiti, organizzando il proprio lavoro in piccole iterazioni, chiamate sprint, della durata di poche settimane (tipicamente 2-4) che permettono il rilascio del software in modo incrementale. In questo modo i progetti software di dimensione medio-grande possono essere suddivisi in tanti progetti di dimensioni più piccole, aventi ciclo di vita proprio, rilascio in produzione compreso, lavorabili nell ambito di un singolo sprint. L approccio Agile detta linee guida e raccomandazioni che vengono poi implementate da diverse metodologie, come ad esempio: Scrum - Per le attività di gestione del processo di produzione del software suo insieme. nel Extreme Programming (XP) - Per le attività ingegneristiche di sviluppo software. 35

36 Metodologie agili Tra i principali vantaggi offerti dall Agile Programming, vi sono: - una maggiore qualità del software rilasciato, in quanto ogni parte incrementale di prodotto viene testata nell ambito di uno sprint, - una maggiore capacità di adeguamento del team di sviluppo ad eventuali variazioni in corso d opera dei requisiti da parte del committente, cosa molto attuale nei progetti software odierni. Uno dei requisiti chiave per il buon funzionamento dell impiego delle metodologie agili è: la continua interazione tra sviluppatori ed il committente (cliente o Product Owner) al fine di aver sempre una visione chiara ed aggiornata di esigenze, requisiti e sul feedback del lavoro svolto. 36

37 Metodologie agili: SCRUM 37

38 Metodologie agili: SCRUM 38

39 L'organizzazione in Scrum Da un punto di vista organizzativo Scrum prevede un Product Owner che, come committente del lavoro, definisce le richieste (Product Backlog) e le relative priorità con scadenza ad ogni iteratione. Lo Scrum Master è invece responsabile di gestire gli allineamenti giornalieri e ad ogni iteration tiene traccia dello stato di avanzamento dei lavori e della situazione dei Backlog. A inizio di ogni iteration si definisce il lavoro per il mese successivo (Sprint Planning) in base alla priorità evidenziate dal Product Owner e sulle stime di impegno da parte del gruppo di sviluppo. Lo Sprint Planning è diviso in due fasi: Metodologie agili: SCRUM - nella prima vengono identificate le user-story da completare - nella seconda il team definisce la progettazione tecnologica delle funzionalità concordate. Definito l'elenco dei task dell'iterazione (Sprint Backlog) da effettuare per raggiungere gli obiettivi del mese, il team segnala eventuali criticità allo Scrum Master negli allineamenti giornalieri, e ad ogni sprint presenta i risultati ottenuti durante l'iterazione. Lo Sprint Review fornisce un controllo sull'andamento del processo alla conclusione di ogni Sprint esplicitando cosa è andato bene o male. Sulla base delle verifiche fatte possono essere proposti degli adattamenti. Alla conclusione dello Sprint, la squadra presenta l'incremento sul prodotto che potenzialmente potrebbe essere rilasciato. Lo Sprint Retrospective è una riunione che permette allo Scrum Master e al team di identificare azioni correttive o modifiche utili per rendere il successivo sprint più produttivo. Per comprendere la differenza fra i due tipi di "revisione", possiamo dire che lo Sprint Review guarda a "che cosa" la squadra sta costruendo (il prodotto), mentre lo Sprint Retrospective guarda al "come" tutto ciò viene costruito (il processo). 39