Domande aperte con risposta di vecchi esami di Ingegneria del software

Modello incrementale vs modello a cascata: Il modello incrementale è più

flessibile, consentendo modifiche durante il processo di sviluppo, mentre

il modello a cascata è rigido e non prevede cambiamenti dopo che una

fase è stata completata. Il modello incrementale permette di ridurre il

rischio di fallimento fornendo feedback continui e correggendo gli errori

durante lo sviluppo. Il modello a cascata, al contrario, concentra il rischio

nelle fasi finali del progetto. Nel modello incrementale, il software è

consegnato in fasi, permettendo di ottenere rapidamente una parte

funzionante del sistema. Nel modello a cascata, il software è consegnato

solo alla fine, dopo che tutte le fasi sono state completate.

12. Caratteristiche generali del modello a V, inclusi vantaggi e

limiti rispetto al modello a cascata classico, e si descriva

l’associazione con lo standard documentale MIL-STD-498.

Il modello a V è una variante del modello a cascata che enfatizza la

verifica e la validazione in ogni fase del ciclo di vita del software. Questo

modello segue un approccio sequenziale simile a quello del modello a

cascata, ma con una struttura a "V" che rappresenta la relazione tra le

fasi di sviluppo e le corrispondenti fasi di test.

Il MIL-STD-498 è uno standard militare statunitense per lo sviluppo e la

documentazione del software, che stabilisce criteri rigorosi per la

gestione del ciclo di vita del software, inclusi i processi di sviluppo,

verifica, validazione e manutenzione. Questo standard richiede una

documentazione completa e dettagliata per ogni fase del ciclo di vita del

software, che include piani di progetto, requisiti, design, test, e manuali

utente.

Il modello a V si allinea strettamente con i requisiti del MIL-STD-498 per

quanto riguarda la verifica e la validazione, poiché entrambe le

metodologie sottolineano l'importanza di test sistematici e di una

rigorosa documentazione a ogni fase. Il MIL-STD-498 richiede che ogni

fase di sviluppo del software sia accompagnata da una documentazione

specifica, che si adatta bene al modello a V, dove ogni fase di test è

chiaramente definita e documentata.

13. Caratteristiche generali e aspetti salienti del modello a V.

Il modello a V è un modello di sviluppo del software che rappresenta una

variante del modello a cascata, con un forte focus sulla verifica e sulla

validazione in ogni fase del processo di sviluppo. La struttura del modello

a V segue una forma a "V", dove la discesa rappresenta la fase di

sviluppo (verifica) e la salita rappresenta la fase di test (validazione).

Fasi del Modello a V

- Analisi dei Requisiti: Raccoglie e definisce i requisiti del sistema. È

fondamentale che i requisiti siano ben compresi e documentati.

- Progettazione del Sistema: Definizione dell'architettura del sistema,

dove si pianificano le interazioni tra i vari componenti del sistema.

- Progettazione Dettagliata: Fase in cui si sviluppa il design dettagliato

dei componenti del sistema, preparandoli per l'implementazione.

- Implementazione: Sviluppo del codice e realizzazione fisica dei moduli

progettati.

Le fasi di verifica e validazione si svolgono parallelamente e sono

strettamente associate alle fasi di sviluppo:

- Test di Unità: Verifica dei singoli moduli sviluppati durante la fase di

implementazione.

- Test di Integrazione: Verifica dell'interazione tra i vari moduli per

garantire che funzionino insieme come previsto.

- Test di Sistema: Verifica che l'intero sistema funzioni correttamente e

soddisfi i requisiti definiti.

- Test di Accettazione: Validazione del sistema da parte dell'utente

finale o del cliente, per assicurarsi che il prodotto soddisfi le

aspettative.

Aspetti salienti:

- Verifica e Validazione in Ogni Fase: A differenza del modello a cascata,

il modello a V pone una forte enfasi sulla verifica e sulla validazione in

ogni fase dello sviluppo, riducendo il rischio di errori che emergono

nelle fasi successive.

- Associazione tra Sviluppo e Test: Ogni fase di sviluppo ha una fase di

test corrispondente, garantendo che ogni componente sia validato non

appena viene sviluppato.

- Documentazione Dettagliata: Come il modello a cascata, il modello a

V richiede una documentazione estesa per ogni fase del processo, il

che aiuta nella gestione del progetto e nella futura manutenzione.

- Rigido ma Efficace per Progetti con Requisiti Stabili: Funziona bene per

progetti in cui i requisiti sono chiari e stabili sin dall'inizio, rendendolo

adatto a settori come quello militare e dell'aeronautica.

14. Si illustrino le caratteristiche generali dei modelli di

sviluppo evolutivi e si dettaglino gli aspetti salienti del modello a

spirale.

Caratteristiche del modello evolutivo:

- Consegnare valore in modo incrementale,

- Adattabilità ai cambiamenti dei requisiti,

- Coinvolgimento degli stakeholder,

- Prototipazione feedback tempestivo,

- Riduzione dei rischi,

- Apprendimento continuo.

I modelli di sviluppo evolutivi sono caratterizzati da un approccio iterativo

e incrementale al ciclo di vita del software. Invece di seguire una

sequenza rigida di fasi come nei modelli prescrittivi, i modelli evolutivi

consentono il continuo miglioramento e adattamento del software

attraverso più iterazioni. Questi modelli sono particolarmente utili in

contesti dove i requisiti non sono completamente definiti all'inizio del

progetto o sono soggetti a cambiamenti.

Il modello a spirale è uno dei modelli evolutivi più noti, ideato da Barry

Boehm nel 1988. Combina elementi del modello a cascata con l'iteratività

tipica dei modelli evolutivi, ponendo una forte enfasi sulla gestione dei

rischi. Il modello a spirale è un approccio iterativo incrementale allo

sviluppo del software. È detto così per la sua rappresentazione grafica.

Aspetti salienti:

- Cicli iterativi,

- Identificazione dei rischi,

- Prototipazione e valutazione,

- Adattabilità e flessibilità,

- Ciclo di vita a lungo termine.

15. Si illustrino le caratteristiche generali dei modelli agili, con

declinazione specifica alle pratiche XP e le principali differenze

rispetto ai modelli prescrittivi.

I modelli agili di sviluppo software rappresentano un approccio iterativo e

incrementale, focalizzato sulla flessibilità, sul rapido adattamento ai

cambiamenti e sull'interazione continua con gli utenti finali. Questi

modelli sono progettati per rispondere alle esigenze dinamiche dei

progetti, dove i requisiti possono evolvere rapidamente e dove è

essenziale fornire valore al cliente in tempi brevi.

Extreme Programming (XP) è una delle metodologie agili più popolari,

caratterizzata da un insieme di pratiche progettate per migliorare la

qualità del software e la reattività ai cambiamenti dei requisiti.

Principali Pratiche di XP:

- Programmazione a coppie (Pair Programming): Due sviluppatori

lavorano insieme sullo stesso codice, condividendo la tastiera e lo

schermo. Questo approccio migliora la qualità del codice attraverso la

revisione continua e facilita la condivisione della conoscenza.

- Test-Driven Development (TDD): Gli sviluppatori scrivono prima i test

automatici per le funzionalità e poi il codice necessario per superare

questi test. Questo metodo garantisce che il software sia sempre

testato e funzionante.

- Refactoring continuo: Il codice viene continuamente migliorato per

mantenerlo semplice, chiaro e facile da modificare, senza introdurre

nuovi bug.

- Integrazione continua: Il codice sviluppato viene integrato

frequentemente (più volte al giorno) nel sistema principale, con test

automatici che garantiscono che ogni nuova aggiunta non interrompa

il funzionamento esistente.

- Rilasci frequenti: Il software viene rilasciato in versioni funzionanti

molto frequenti, che permettono di raccogliere rapidamente feedback

dal cliente e di apportare le necessarie modifiche.

I modelli agili sono estremamente flessibili, permettono cambiamenti

frequenti nei requisiti anche in fasi avanzate del progetto. Si basano su

una pianificazione incrementale e su un feedback continuo. Mentre i

modelli prescrittivi tendono ad essere rigidi, con un processo sequenziale

e lineare dove i requisiti devono essere ben definiti all'inizio del progetto,

e i cambiamenti sono costosi e difficili da implementare.

Nei modelli agili il cliente è coinvolto attivamente in tutte le fasi, mentre

nei modelli prescrittivi il cliente è coinvolto solo per la raccolta dei

requisiti e nelle fasi di verifica.

Nei modelli agili la documentazione è minima, mentre i modelli

prescrittivi richiedono una documentazione dettagliata per ogni fase del

ciclo di vita del software.

I modelli agili gestiscono il rischio attraverso iterazioni brevi e feedback

continui, mentre nei modelli prescrittivi il rischio tende a concentrarsi

nelle fasi finali del progetto.

16. Caratteristiche generali dei modelli di sviluppo evolutivi.

I modelli di sviluppo evolutivi sono metodologie di sviluppo del software

che enfatizzano un approccio iterativo e incrementale. A differenza dei

modelli prescrittivi, che seguono una sequenza rigida di fasi, i modelli

evolutivi permettono lo sviluppo del software attraverso cicli ripetuti, che

consentono di affinare progressivamente il prodotto in base ai feedback

ricevuti e ai cambiamenti nei requisiti.

Caratteristiche principali:

- Iterazioni e incremento: il processo di sviluppo è suddiviso in cicli o

iterazioni.

- Flessibilità e adattabilità: sono progettati per adattarsi ai cambiamenti

nei requisiti.

- Riduzione del rischio: il rischio è gestito in modo incrementale.

- Feedback continuo.

- Prototipazione.

- Consegna graduale.

Modelli evolutivi sono:

- Modello a spirale: combina lo sviluppo iterativo con la gestione del

rischio.

- Modello a prototipi: si concentra sulla costruzione di prototipi per

chiarire i requisiti e ottenere un feedback iniziale.

- Modelli incrementali: il software è sviluppato e rilasciato in incrementi

successivi, ciascuno dei quali aggiunge funzionalità al prodotto.

17. Si illustrino i pilastri caratterizzanti il framework agile

SCRUM e per ciascuno si descrivano gli intenti e si dettaglino gli

artefatti e gli eventi principalmente coinvolti nella loro

implementazione.

- Trasparenza scopo: fornire una chiara comprensione del processo.

Eventi Scrum: pianificazione dello sprint, per identificare le

funzionalità da sviluppare, un piano per la consegna, un obiettivo di

sprint.

Artefatti Scrum: il product/sprint backlog garantisce trasparenza sui

requisiti. La definition of done/ready garantisce trasparenza su cosa si

intende per software funzionante/funzionalità pronta per essere

elabor