| che cosa prevedono i modelli sequenziali? | i vari passaggi vengono posti in un ordine prestabilito e vengono attraversati uno alla volta uno dopo l’altro.
il più famoso è il modello a cascata
ogni step produce un output chiamato semilavorato che è anche l'input dello step successivo
per questo questi modelli vengono chiamati anche document-based: tra una fase e l’altra si crea infatti un documento che è il mezzo di trasmissione dell’informazione |
| quali sono le varie fasi previste nel modello a cascata? | 1) analisi dei Requisiti
2) Progettazione
3) Codifica
4) Testing
5) consegna del Prodotto |
| quali sono i difetti dei modelli sequenziali? | 1) non prevede una fase di manutenzione e non prevede di tornare indietro in alcun modo
2) congelamento dei sottoprodotti: una volta prodotto un semilavorato esso è fisso e non può essere modificato; questo è particolarmente critico per le stime e specifiche fatte durante le prime fasi, che sono fisiologicamente le più incerte.
3) monoliticità: tutta la pianificazione è orientata ad un singolo rilascio, e l’eventuale manutenzione può essere fatta solo sul codice |
| in che cosa consiste il modello a V? | è una variante del modello a cascata che introduce una più estesa fase di testing
essenzialmente introduce un interfacciamento ciclico con il cliente o con del testi per ogni fase di progettazione |
| in che cosa consistono i modelli iterativi? | consistono nel poter tornare indietro di uno o più passaggi fra i vari step di creazione del prodotto |
| modello a cascata con singola retroazione | modello iterativo che consente di poter tornare ciclicamente indietro di una fase di produzione, ma una volta che il prodotto viene consegnato non è possibile applicargli alcuna modifica o miglioramento |
| modello a fontana | modello di tipo incrementeale.
consente in qualsiasi momento di poter tornare alla fase iniziale consentendo di poter risolvere errori con un margine di operatività più profondo.
dopo la consegna esistono due strade:
- evoluzione
- manutenzione
i tempi di consegna si allungano notevolmente ma il software non è provvisto di errori dovuti al rattoppamento temporaneo |
| che cosa prevedono i modelli incrementali? | come il software iterativo ma fra le varie fasi sono previste fasi di consegna
la manutenzione del software non è quindi più vista come una particolarità ma come una normale fase di evoluzione |
| modello prototipale | lo scopo non è quello di consegnare un prodotto finito ma di ricevere dei feedback
per questo vengono introdotti i prototipi che possono essere:
pubblici: per capire i requisiti del cliente
privati: per esplorare nuovi strumenti o scelte di risoluzione dei problemi
bisogna stare attenti a non consegnare prototipi come prodotti che potrebbe dare problemi di manutenibilità |
| quali sono i difetti dei modelli incrementali? | - Lavoro di planning più complicato per la pianificazione di tutte le iterazioni
- iterazioni troppo lunghe come tempo
- troppe iterazioni (generano overhead)
- Overlapping fra le iterazioni |
| modelli trasformazionali | puntano a controllare tutti i passaggi e i procedimenti in modo formale
partendo da requisiti scritti in linguaggio formale si pensa di poter, tramite dei passi o trasformazioni dimostrabili, di poter generare codice corretto
Questo modello ha un grande difetto ovvero le assunzioni iniziali devono essere studiate molto accuratamente per non produrre errori successivamente |
| metodo a spirale | l'attenzione è posta prevalentemente sui rischi, perciò lo studio di fattibilità viene fatto ogni volta che si inizia una nuova iterazione.
questo aiuta in particolar modo a valutare un lavoro basato su un certo budget |
| variante della spirale win win | è una variante del metodo a spirale
Ad ogni iterazione bisogna dunque trovare con esso un punto di equilibrio win-win in entrambi le parti “vincono” (o hanno l’illusione di aver vinto), così da far convergere tutti su un obiettivo comune. |
| modello COTS | basato sulla riusabilità del codice (ovvero di moduli già presenti sul mercato)
richiede alcune attività diverse oltre alle solite
- Analisi dei requisiti
+ Analisi dei componenti: prima di progettare considero la disponibilità di componenti che implementano una parte o tutte le funzionalità richieste;
+ Modifica dei requisiti: stabilisco se il cliente è disposto ad accettare un cambiamento nei requisiti necessario per utilizzare un componente particolare;
+ Progetto del sistema col riuso di componenti: occorre progettare il sistema per far interagire componenti che non necessariamente sono stati originariamente progettati per interagire;
- Sviluppo e integrazione;
- Verifica del sistema. |
| quali sono i punti fissi delle metodologie agili? | le metodologie agili danno maggiore enfasi alla programmazione rispetto agli altri aspetti, punti focali sono :
- Gli individui e la collaborazione tra individui è più importante di processi e strumenti.
- Il software che funziona è più importante della documentazione ben fatta.
- La collaborazione con il cliente è più importante del contratto.
- Rispondere al cambiamento è più importante che seguire un piano. |
| Kanban | fa parte delle metodologie agile
Nasce con lo scopo di minimizzare il lavoro in corso, concentrandosi per ogni momento su una singola cosa, questo perchè si ha particolare difficoltà nel context switching per gli umani
le varie fasi sono :
- backlog: richieste dal cliente
- da fare: attività da fare in questa iterazione
- in esecuzione
- in testing
- fatto |
| Scrum | ha l'obiettivo del fissare dei requisiti per ogni singola iterazione (che dura 2- 4 settimane)
questo per porre meno stress ai lavoratori per il cambio dei requisiti o obiettivi. |
| Crystal | introduce il concetto di comunicazione osmotica ovvero il codice e la responsabilità di quest'ultimo appartiene al team e non al singolo, quindi la conoscenza deve essere nota a tutti i componenti
- metodologia che funziona con team piccoli |
| eXtreme programming | si fonda sui principi:
- incrementa e poi semplifica (migliorando le proprietà interne del codice)
- sviluppo guidato dal test (test driven development)
le fasi principali sono :
rosso: viene scritto un test di cose non ancora implementate
verde: il test viene fatto passare il più velocemente possibile
verde: refractoring e riorganizzazione del codice |
| quali sono i vantaggi del test driven development | - facilità nel scrivere del codice facilmente testabile (dato che vengono scritti prima i test del codice)
- facilità nella scrittura delle interfacce e nella definizione della loro interazione |
| quali sono i principi dell extreme programming? | - Separazione degli interessi (aspects o concerns): separare tempi, responsabilità e moduli, ovvero tutte le varie viste o le varie dimensioni su cui si deve affrontare il problema.
- Astrazione e modularità: bisogna usare le giuste astrazioni che ci permettono di dominare i problemi complessi (possono essere i diversi linguaggi di programmazione, linguaggi di descrizione o vari altri costrutti).
- Anticipazione del cambiamento (design for change): in fase di progettazione il programmatore deve pensare a come potrebbe cambiare il prodotto, accomodando la possibile aggiunta di requisiti che il cliente magari non aveva neanche pensato; bisogna stare attenti però, perché spesso questo concetto complica arbitrariamente la progettazione e lo sviluppo, rischiando di far perdere molto tempo su cose che al cliente potrebbero non servire: può essere un’idea migliore partire da qualcosa di semplice ed incrementare man mano.
- Generalità: per rendere più semplice la modifica e l’espansione futura è necessario scrivere interfacce molto generali ai sistemi che costruiamo.
- Incrementalità: lo sviluppo avviene incrementalmente, un pezzetto alla volta.
- Rigore e formalità: è importante essere rigidi e specifici sia nella comunicazione che nella descrizione dei requisiti. |
| quali sono i principi aggiuntivi dell'eXtreme programming? | Feedback rapido: bisogna mantenere un costante flusso di feedback; questo viene dato dai test, dai colleghi ma anche dal cliente, che dev’essere continuamente consultato sullo stato dei lavori. Tra le iniziative che favoriscono un veloce ciclo di feedback c’è lo standup meeting, una riunione mattutina fatta in piedi in cui ciascuno descrive in poche parole cosa ha fatto il giorno precedente e cosa intende fare oggi.
Presumere la semplicità: non bisogna complicare senza motivo né il codice, che dev’essere scritto con in mente ciò che serve a breve termine e non in un futuro remoto, né le relazioni tra colleghi, che non devono essere eccessivamente gerarchiche (tutti dovrebbero avere compiti molto simili); in generale si dovrebbe semplificare il più possibile in tutti gli ambiti del progetto.
Accettare il cambiamento: non ci si deve aspettare che il software sia immutabile; al contrario, deve essere dato per scontato il concetto di flessibilità e malleabilità, ovvero che il cliente vorrà fare cambiamenti sia dopo che durante lo sviluppo del prodotto.
Modifica incrementale: ritornando al concetto di baby steps, ogni iterazione di sviluppo dovrebbe essere breve e le funzionalità introdotte piuttosto piccole; questa regola si applica tuttavia a tutti gli ambiti del progetto, tra cui la gestione del team: ovvero non bisognerebbe mai aggiungere più di una persona alla volta al gruppo di lavoro, in quanto aggiungerne di più potrebbe portare a passare più tempo ad istruirle che a sviluppare.
Lavoro di qualità: bisogna ovviamente ottenere un buon prodotto, ma per fare ciò la prospettiva cambia in favore dello sviluppatore, al quale si deve garantire un ambiente di lavoro salutare e un certo benessere; la fidelizzazione dei programmatori è importante perché più si trovano bene e meglio lavorano. |
