Riassunto di Ingegneria del Software

AGILE SOFTWARE DEVELOPMENT

L'Agile Software Development rientra nei cosiddetti Modelli Evolutivi, che si

fondano sull'idea centrale di coinvolgere il cliente o l'utente, fornendogli continue

nuove versioni in modo che possa essere partecipe nello sviluppo del progetto.

L'obiettivo è rendere il cliente il più soddisfatto possibile.

Individuals and Interactions: le persone sono più importanti degli

• strumenti.

Working Software: scrivere codice facile e capire da usare.

• Custom Collaboration: partecipazione del cliente.

• Responding to Change: tutti i sistemi cambiano e si evolvono nel tempo.

• Come deve avvenire la Progettazione per tenere conto del Cambiamento? La

Progettazione Agile non avviene in un momento ben definito. Avviene

continuamente, tutte le volte che nel codice si verifica uno dei seguenti

problemi:

Rigidità: il sistema è difficile da cambiare.

◦ Fragilità: le modifiche causano malfunzionamenti.

◦ Immobilità: i sorgenti sono difficili da riutilizzare.

◦ Viscosità: i cambiamenti compatibili con l'architettura sono difficili da

◦ realizzare.

Complessità inutile: il sistema è più complicato del necessario.

◦ Ripetizioni inutili: i sorgenti contengono codice simile.

◦ Opacità: la funzione dei moduli non è facilmente comprensibile.

◦

Lo Sviluppo Agile prevede riprogettazione (rafactoring) e non progettazione. È

necessario codice modulare.

EXTREME PROGRAMMING

Istituisce su una serie di pratiche per lo Sviluppo Agile, volte a enfatizzare la

scrittura di codice di qualità e la rapidità di risposta ai cambiamenti di requisiti.

Pair Programming: due programmi lavorano allo stesso codice.

• Planning Game: la pianificazione avviene continuamente.

• Test-Driven Development: i test vengono realizzati prima del codice.

• Whole-Team: l'utente finale deve essere parte integrante dello sviluppo.

• Continuous Integration: i cambiamenti vengono integrati (non rimandati).

• Refactoring: riscrittura del codice.

• Small Releases: continue consegne delle versioni al cliente.

• Coding Standards: il codice deve seguire regole definite all'inizio.

• Collective Code Ownership: tutti sono responsabili di tutto.

• Symple Design: le soluzioni più semplici sono le migliori.

• System Metaphor: usare metafore per fornire informazioni sul sistema.

• Sustainable Peace: fare pause, non eccedere.

•

RILASCIO DEL SOFTWARE

Con rilascio si intende la generazione di una versione che viene messa a

disposizione degli utenti finali. Tipologie di rilascio:

Pre-Alpha: una versione esemplificativa delle funzionalità del programma.

• Alpha: versione del programma non completa, ma con alcune cose

• funzionanti.

Beta: versione di Test; le versioni Beta dovrebbero avere tutte o quasi tutte

• le funzionalità già implementate.

Versione candidata: una versione che si suppone essere definitiva.

•

VALIDAZIONE DEL CODICE

La validazione del codice è l'insieme di attività che vengono svolte per verificare la

validità del codice.

Test: porzioni di codice dedicate alla verifica di alcune caratteristiche di un

• sistema.

Test unitari: test dedicati alla verifica specifica del funzionamento di un

• componente.

Test automatici: gruppi di test che vengono validati in automatico,

• riducendo di molto il tempo di validazione.

Debugging: attività di rimozione degli errori dal codice.

•

TEST DRIVEN DEVELOPMENT

Il TDD è il processo di Sviluppo del Software che usa i test come strumento di

Pianificazione e Sviluppo.

DEBUGGING

Tecniche di debugging:

Circoscrizione del problema

• Logging

• Gestione delle eccezioni

• Modalità di debugging

• Break point

◦ Step by step

◦ Monitoring delle variabili

◦

REFACTORING

Code Smell più significativi:

Codice duplicato

• Metodi troppo lunghi

• Eccesso di commenti

• Liste di parametri troppo lunghe

• Ambientazione errata (Feature Envy)

• Classi con troppi metodi

• Modifiche divergenti

• Codice inutilizzato

• Classi di dati

• Modifiche a cascata (Shotgun Surgery)

•

IL CICLO BREVE

Di seguito vedremo un esempio di Ciclo di Ingegneria del Software dedicato agli

Sviluppatori dei Prototipi:

Il Ciclo che si basa su poche o una sola funzionalità è rapido. Solitamente

• dura da 1 ora a non più di una giornata.

Il ciclo si basa su una serie di attività che vanno rispettate, perché ognuna

• ha una sua rilevanza nella realizzazione di codice ben fatto e funzionante.

Il Ciclo Breve si compone delle fasi seguenti:

Test Driven Development: definisce i test per la fase di Validazione, e guida

• alla progettazione del codice.

Implementazione: l'Implementazione è rapidissima, e volta unicamente a far

• funzionare i test. I Design Pattern possono essere utilizzati in questa fase

per accelerare lo sviluppo delle funzionalità.

Validazione: verifica del funzionamento e correzione dei Bug.

• Refactoring: le operazioni di Refactoring sono effettuate per ridurre

• l'impatto delle modifiche future.

Documentazione: la documentazione fatta per altri sviluppatori deve essere

• semplice e minimale.

IL CICLO LUNGO

Si abbandona la Modellazione Concettuale e si passa alle Storie Utente, piccole

frasi scritte in linguaggio comune, chiare e semplici che descrivono funzionalità

che il sistema dovrebbe avere.

La definizione degli obiettivi serve a definire che cosa dovrà essere fatto

• durante un certo ciclo di sviluppo.

Gli obiettivi vengono definiti attraverso semplici Storie Utente.

• La Pianificazione Temporale decide la scaletta temporale con cui le Storie

• Utente dovranno essere implementate.

Il Ciclo Breve è utilizzato per l'implementazione. Si effettuano molti Cicli

• Brevi, risolvendo le Storie Utente poco per volta.

Alla fine di ogni Ciclo Breve, si usa SVN per creare una versione di sviluppo.

• Dopo aver implementato tutte le Storie Utente, si effettua un controllo

• completo per verificare che tutte le funzionalità siano state implementate.

Durante il controllo, è possibile sfruttare il Principio delle Dipendenze

• Stabili e delle Astrazioni Stabili per rivedere la struttura dei package prima

di chiudere il ciclo di sviluppo.

Quando il prototipo è pronto, si crea una Versione di Rilascio.

•

VERSIONING

Versioni di Rilascio: corrispondo ai prototipi, messi a disposizione degli

• utenti.

Versioni di Sviluppo: sono versioni utilizzate unicamente dal team di

• sviluppo.