Riassunto esame Ingegneria del software, Prof. Mongiello Marina, libro consigliato Ingegneria del software, Ian Sommerville

Ingegneria del software: Modulo 1

Processi software

Un processo software è un insieme di attività che porta alla creazione di un prodotto software. Invece, il prodotto software è l’insieme di tutti gli artefatti che permettono l'utilizzo di un programma.

Ciclo di vita

Lo sviluppo di un software include le quattro attività fondamentali dell’ingegneria del software, che descrivono il suo ciclo di vita:

• Specifica: vengono definite le funzionalità del software e fissati i vincoli operativi.
• Sviluppo: deve essere prodotto il software che realizza i requisiti definiti nella specifica.
• Convalida: il software deve essere convalidato per garantire ciò che il cliente richiede.
• Evoluzione: il software deve evolversi per soddisfare le necessità e i cambiamenti dei requisiti.

Durante la vita del sistema è prevista una singola esecuzione di tutte queste fasi, ma i cambiamenti dei requisiti possono causare una loro ripetizione. È importante osservare che non esiste:

• Un processo universale valido per tutti i tipi di software;
• Un approccio giusto o sbagliato, perché ognuno è adatto a differenti tipi di software.

I processi plan-driven sono processi dove tutte le attività sono pianificate in anticipo e il loro avanzamento è misurato rispetto a quanto previsto dal piano. Nei processi agili, la pianificazione è incrementale e continua durante lo sviluppo del software. È quindi più facile modificare il processo per adeguarsi alle modifiche dei requisiti del cliente o del prodotto.

Modelli dei processi software

Un modello di processo software è una rappresentazione semplificata di un processo software. Ogni modello rappresenta un processo da una particolare prospettiva, e quindi fornisce solo delle informazioni parziali sul processo.

Modello a cascata

Il modello a cascata è caratterizzato da una successione di fasi sequenziali, dove ognuna termina con la produzione di documenti formali. Solitamente, comprende le seguenti fasi: analisi e definizione dei requisiti, progettazione del sistema e del software, implementazione e test delle unità, integrazione e test del sistema e operatività e manutenzione. Nel modello a cascata si può passare alla fase successiva solo dopo aver terminato quella precedente. Questo non sempre risulta essere vantaggioso. Infatti, durante la fase finale del ciclo di vita, il software viene messo in funzione ed è qui che si possono rilevare gli errori. In tal caso, il sistema viene modificato, e questo può comportare la ripetizione dei precedenti stadi del processo. Per questo motivo, il modello a cascata è inappropriato quando i requisiti del software cambiano rapidamente. Inoltre, data la troppa rigidità, sono state prodotte due varianti:

• Cascata con prototipazione, in cui si realizza un prototipo usa e getta;
• Cascata con ritorni, che consente al termine di ogni fase di ritornare alle fasi precedenti e apportare modifiche.

Modello incrementale

Lo sviluppo incrementale si basa sull’idea di sviluppare un’implementazione iniziale, esporla agli utenti e perfezionarla attraverso molte versioni. Le attività di specifica, sviluppo e convalida sono intrecciate, con feedback veloci tra le varie attività. Questo approccio può essere plan-driven, agile o una loro combinazione. Rispetto al modello a cascata, è migliore per quei sistemi i cui requisiti è probabile che cambino durante il processo di sviluppo.

Vantaggi e svantaggi

• Il costo di implementazione delle modifiche dei requisiti è ridotto. L’analisi e la documentazione che devono essere ripetute sono minori.
• È più facile ottenere il feedback del cliente perché può fare i suoi commenti durante le dimostrazioni del software e vedere quanto è già stato implementato.
• È possibile consegnare in anticipo al cliente una versione utilizzabile del software, consentendo loro di utilizzare e valutare il software prima di quanto sia possibile con un processo a cascata.

I problemi dello sviluppo incrementale diventano gravi per sistemi grandi, complessi e di lunga durata. Sviluppo incrementale non significa che bisogna consegnare ciascun incremento al cliente. È possibile presentare il sistema al cliente per avere i suoi commenti, senza necessariamente consegnarlo e installarlo nell’ambiente del cliente.

Modello a spirale

Nel modello a spirale il processo ritorna sempre su sé stesso e ogni volta si pianifica la fase successiva. Prevede quattro attività fondamentali:

• Definizione degli obiettivi;
• Analisi dei rischi;
• Sviluppo e validazione;
• Pianificazione.

Esso pone grande attenzione sugli aspetti organizzativi, focalizzandosi sulla pianificazione delle fasi e sull’analisi dei rischi. Inoltre, richiede una forte interazione tra committente e fornitore.

Integrazione e configurazione

Nella maggior parte dei progetti software si è soliti riutilizzare il software. Solitamente, vengono riutilizzati tre tipi di componenti software: sistemi di applicazioni indipendenti, collezioni di oggetti o un pacchetto da integrare tramite framework o servizi web. Le fasi di questo processo sono:

• Specifica dei requisiti;
• Ricerca e valutazione del software: vengono ricercati e valutati i componenti e i sistemi che possono fornire le funzionalità richieste.
• Perfezionamento dei requisiti: i requisiti vengono modificati in funzione dei componenti disponibili. Se le modifiche non sono possibili, l’attività di analisi dei componenti può essere ripetuta per cercare soluzioni alternative.
• Configurazione del sistema delle applicazioni: questo avviene se non è disponibile un sistema pronto all’uso. In tal caso, i singoli componenti possono essere modificati per svilupparne di nuovi.

L’ingegneria del software orientata al riutilizzo ha come vantaggio quello di ridurre la quantità di software da sviluppare, riducendo così i costi e i rischi, e portando anche a consegne più veloci. Ovviamente, ha degli svantaggi come: i compromessi nei requisiti o la perdita del controllo sull’evoluzione del sistema.

Specifica del software

La creazione delle specifiche del software, o ingegneria dei requisiti, è il processo per capire e definire quali servizi sono richiesti dal sistema, e per identificare i vincoli. Si tratta di uno stadio critico, poiché gli errori in questa fase portano a problemi successivi nella progettazione e implementazione del sistema. Le fasi principali dell’ingegneria dei requisiti sono tre:

• Deduzione e analisi dei requisiti: è il processo di deduzione dei requisiti di sistema attraverso l’osservazione di sistemi già esistenti;
• Specifica dei requisiti: è l’attività di tradurre le informazioni raccolte durante la fase di analisi in un documento che definisce un insieme di requisiti (funzionali e non).
• Convalida dei requisiti: quest’attività controlla che i requisiti siano realistici, coerenti e completi.

Progettazione e implementazione del software

Prima di tutto, diamo una definizione di progettazione e implementazione:

• Progettazione: la fase in cui si progetta una struttura software che realizzi le specifiche;
• Implementazione: la fase di traduzione della struttura in un programma eseguibile.

Questo è il processo di conversione delle specifiche in un sistema eseguibile. Il processo di progettazione per i sistemi informativi consta di quattro attività:

• Progettazione dell’architettura: consiste nell’identificazione della struttura complessiva del sistema;
• Progettazione del database: vengono progettate le strutture dei dati del sistema;
• Progettazione dell’interfaccia: viene definita l’interfaccia tra i componenti del sistema;
• Progettazione e scelta dei componenti: vengono ricercati i componenti riutilizzabili e, se non disponibili componenti idonei, ne vengono progettati di nuovi.

La programmazione è un’attività individuale e non c’è un processo generico che viene seguito. Normalmente i programmatori testano il codice che hanno sviluppato e in questo modo mettono in luce difetti che devono essere rimossi dal programma. Questa procedura è chiamata debug.

Sviluppo agile

Tutti i metodi agili hanno alcune caratteristiche comuni:

• I processi di specifica, progettazione e implementazione sono intrecciati.
• Il sistema viene sviluppato in una serie di piccoli incrementi, messi a disposizione dei clienti ogni due o tre settimane.
• Ampio supporto di strumenti utilizzati per supportare il processo di sviluppo.
• I clienti vengono coinvolti nel processo di sviluppo per ottenere un feedback sulle modifiche dei requisiti.
• La documentazione viene ridotta al minimo ricorrendo a comunicazioni informali.

Gli approcci agili considerano la progettazione e l’implementazione attività centrali nel processo software. Esse incorporano altre attività, come la deduzione e la verifica dei requisiti. Inoltre, i metodi agili sono utili in una società di software che sta sviluppando un prodotto di piccole o medie dimensioni; oppure all’interno di un’organizzazione, in cui: c’è un impegno da parte del cliente di essere coinvolto nel processo di sviluppo, ci sono pochi stakeholder e regolamenti esterni.

I principi dei metodi agili

Questi metodi si basano su alcuni principi:

• Coinvolgimento del cliente: il loro coinvolgimento è utile per fornire nuovi requisiti.
• Soddisfazione del cliente e consegna incrementale anticipata del software.
• Semplicità: fare in modo che sia il software che il processo rimanga semplice.
• Fattori umani: le capacità del team di sviluppo devono essere riconosciute e sfruttate. I membri del team devono essere lasciati liberi di sviluppare il software secondo i loro metodi di lavoro.
• Accettazione dei cambiamenti: le richieste di cambiamento vengono considerate positivamente anche se intervengono in fase avanzata. Un team agile è un team in grado di rispondere in modo appropriato ai cambiamenti.

Extreme programming

Il nome fu coniato da Kent Beck perché l’approccio fu sviluppato spingendo le normali pratiche a livelli “estremi”. Prevede quattro attività: pianificazione, progettazione, programmazione e collaudo.

Programmazione a coppie

I programmatori lavorano a coppie verificando reciprocamente il loro lavoro e fornendo il supporto per fare sempre un buon lavoro.

Integrazione continua

Appena un task è concluso, viene integrato nel sistema.

Pianificazione incrementale

I requisiti sono registrati su “story card” che gli sviluppatori suddividono in “task” di sviluppo.

Cliente on-site

Il cliente è un membro del team di sviluppo e ha la responsabilità di consegnare i requisiti del sistema al team per l’implementazione.

Refactoring

Tutti gli sviluppatori effettuano in continuazione il refactoring del codice appena si trovano miglioramenti al codice stesso. Questo rende il codice semplice e mantenibile.

Piccole release

Le release del sistema sono frequenti e aggiungono, in modo incrementale, nuove funzionalità.

Ritmo sostenibile

Non sono considerati accettabili grandi ritardi.

Sviluppo con test iniziali

Viene utilizzato un ambiente automatico di test delle unità per provare una nuova funzionalità, prima che questa sia implementata. Non può essere immediatamente integrata con le pratiche di gestione e le tradizioni di molte aziende. Per questo, le società selezionano le sole pratiche XP più appropriate al loro modo di lavorare.

Refactoring

Il refactoring è il processo di perfezionamento di un programma volto a rallentare il suo deterioramento. Questo significa che occorre modificare un programma per migliorarne la struttura, ridurne la complessità o renderlo più semplice da leggere.

Sviluppo guidato da test

Lo sviluppo guidato da test è un approccio allo sviluppo dei programmi in cui si interlacciano sviluppo e test del codice. Il codice viene sviluppato in modo incrementale, insieme a una serie di test per ogni incremento del codice. Non si potrà procedere allo sviluppo del successivo incremento finché il codice sviluppato non avrà superato tutti i suoi test. Un ambiente di test automatizzati è essenziale per lo sviluppo guidato da test. Questo perché il codice viene sviluppato in piccoli incrementi e quindi i test vengono integrati in un programma distinto che li esegue sul sistema da testare.

Vantaggi

• Copertura del codice: ogni segmento di codice scritto dovrebbe avere almeno un test associato.
• Test di regressione: una serie di test viene sviluppata in modo incrementale mentre il programma viene sviluppato.
• Debugging semplificato: quando un test fallisce, il codice deve essere controllato e modificato.
• Documentazione del sistema. I test stessi sono una forma di documentazione che descrive che cosa dovrebbe fare il codice. La lettura dei test può agevolare la comprensione del codice.

Il test di regressione controlla che le modifiche apportate non introducano nuovi bug nel sistema e che il nuovo codice interagisca secondo le previsioni con il codice esistente.

Gestione agile della progettazione

I manager hanno bisogno di sapere che cosa sta accadendo. La pianificazione informale e il controllo del progetto proposti dai primi seguaci dei metodi agili si sono scontrati con questa esigenza di visibilità da parte dei manager. I team avevano organizzazioni autonome, non producevano documentazione e pianificavano lo sviluppo in cicli molto brevi. Purtroppo, questo non è appropriato per le società più grandi. Per risolvere questo problema, fu sviluppato il metodo agile Scrum. Questo metodo si compone di tre fasi:

• Nella fase iniziale si stabiliscono gli obiettivi generali del progetto e si progetta l'architettura del software.
• Segue una serie di cicli di sprint, in cui ogni ciclo sviluppa un incremento del sistema.
• Nella fase di chiusura si conclude il progetto, completa la documentazione richiesta e si valuta le lezioni apprese dal progetto.

Scrum

Nello Scrum si fa uso dei seguenti termini:

• Team di sviluppo: Un gruppo di sviluppatori software che non dovrebbe avere più di sette persone.
• Incremento di un prodotto potenzialmente rilasciabile: L’incremento del software è consegnato da uno sprint. Questo incremento deve trovarsi in uno stato finito e non deve servire altro lavoro per incorporarlo nel prodotto finale.
• Product backlog: Lista di elementi di cui si deve occupare il team di Scrum.
• Product owner: Individuo o piccolo gruppo, il cui compito è identificare le caratteristiche o i requisiti del prodotto, stabilirne le priorità e rivedere il product backlog. Può essere un cliente, ma anche un product manager.
• Scrum: Una riunione giornaliera del team che esamina l’avanzamento del lavoro e stabilisce le priorità del lavoro da svolgere in quel giorno.
• ScrumMaster: Lo ScrumMaster ha la responsabilità di garantire che il processo Scrum sia seguito e di guidare il team.
• Sprint: Una iterazione dello sviluppo. Gli sprint di solito durano da 2 a 4 settimane.
• Velocità: Stima della quantità di lavoro del product backlog che un team può svolgere in un singolo sprint.

Questa tecnica consente di avere i seguenti benefici:

• Il prodotto è suddiviso in parti gestibili e comprensibili;
• I requisiti instabili non fanno ritardare l’avanzamento del lavoro;
• L’intero team ha una visione su tutto;
• I clienti ricevono in tempo gli incrementi e hanno un feedback su come funziona il prodotto;
• C’è fiducia tra clienti e sviluppatori, perché tutti si aspettano che il progetto avrà successo.

Problemi pratici con i metodi agili

L’uso di un approccio agile per grandi sistemi di lunga durata presenta alcuni problemi:

• L’informalità è incompatibile con l’approccio legale alla definizione dei contratti;
• I metodi agili non sono indicati per la manutenzione del software;
• I metodi agili sono ideati per piccoli team fisicamente vicini.

Ingegneria dei requisiti

I requisiti di un sistema sono la descrizione dei servizi che il sistema deve fornire e dei suoi vincoli operativi. Il processo di ricerca, analisi, documentazione e verifica di questi servizi e vincoli è chiamato ingegneria dei requisiti. Esistono due tipi di requisiti:

• Requisiti dell’utente: dichiarano, attraverso l’uso del linguaggio naturale e di diagrammi, quali servizi il sistema dovrebbe fornire e i vincoli sotto cui deve operare. Quindi risultano essere più generici;
• Requisiti del sistema: sono descrizioni più dettagliate delle funzioni, dei servizi e dei vincoli operativi del sistema software. Essi forniscono informazioni più specifiche sui servizi e sulle funzioni da implementare.

I requisiti andrebbero scritti con diversi livelli di dettaglio, perché tipi diversi di lettori li usano in modo differente. Questo perché, i lettori dei requisiti dell’utente non si occupano del modo in cui il sistema sarà implementato. Invece, i lettori dei requisiti del sistema hanno bisogno di sapere con più precisione che cosa il sistema dovrà fare. Gli stakeholder del sistema includono chiunque sia influenzato dal sistema in qualche maniera e chiunque abbia un interesse verso di esso. Gli stakeholder possono essere utenti finali.