Ingegneria del Software

Università degli Studi di Messina

Dipartimento di Scienze Matematiche, Informatiche, Fisiche e della Terra

Ingegneria del software

Un software è un programma con la sua documentazione e può essere generico o generalizzato, è realizzabile mediante linguaggio di programmazione e se il progetto è più complesso mediante modelli di ingegneria del software.

Un software è molto “malleabile” ed è un prodotto “human intensive”, ovvero è un prodotto che richiede un considerevole sforzo in risorse umane perché si concentra soprattutto sulla progettazione e l’implementazione.

Un software, per essere considerato un buon software, deve avere le seguenti caratteristiche:

1. Manutenibilità: deve essere ben strutturato in modo che sia facile da modificare;
2. Affidabilità: deve essere sicuro per chi lo utilizza e per l’ambiente;
3. Efficienza: deve funzionare bene entro un determinato periodo di tempo;
4. Validabilità: deve essere facilmente verificabile;
5. Fruibilità: deve essere disponibile all’uso;
6. Accettazione: deve essere accettabile dal sistema che lo utilizza;
7. Riusabilità: deve essere riutilizzabile;
8. User-Friendly: facilmente utilizzabile dagli utenti.

Il compito dell’ingegneria del software è quello di fare da tramite tra il cliente e il programmatore. L’ingegnere del software, infatti, è colui che raccoglie le richieste dei clienti e le traduce in requisiti del software, organizza lo sviluppo, il rilascio e la manutenzione. Tutto ciò deve essere fatto tenendo in considerazione:

• Budget a disposizione;
• Una deadline fissata;
• I possibili cambiamenti nel corso dello sviluppo.

Per portare a termine i suoi compiti, l’ingegnere del software utilizza: tools (strumenti), tecniche (procedure per raggiungere i risultati) e metodologia (gruppi di tecniche unite dalla stessa filosofia).

L’ingegneria del software richiede la conoscenza sia del dominio software (formale e preciso) sia del dominio del problema (informale, il problema del cliente non è una richiesta precisa a basso livello).

Un ingegnere del software deve quindi avere le seguenti skills:

• Comunicazione;
• Feedback;
• Motivazione;
• Valutazione e analisi (pianificazione, valutazione del rischio, stima della durata dello sviluppo).

Lo sviluppo software prevede 5 fasi:

1. Analisi dei requisiti;
2. Progettazione del software;
3. Costruzione del software;
4. Testing;
5. Manutenzione.

Un software può essere sviluppato secondo diverse metodologie e seguendo diversi modelli.

I modelli sono:

1. Classico o a cascata;
2. A spirale;
3. Agile;
4. Evolutivo (incrementale);
5. Prototipale.

Le metodologie:

1. Scrum;
2. Extreme Programming;
3. RUP (Rational Unified Process);
4. RAD (Rapid Application Development);
5. DevOps.

Il software è differente dagli altri prodotti di tipo ingegneristico, perché, in quanto non tangibile, sembra che sia duttile e sia possibile effettuare modifiche importanti senza conseguenze, ma nella realtà non è così. Infatti, un software è considerato un prodotto “human intensive” cioè un prodotto che richiede un’elevata intensità di lavoro.

Qualità del software

1. Interne se guardano gli sviluppatori;
2. Esterne se riguardano gli utenti;
3. Prodotto se riguardano il prodotto consegnato;
4. Processo se riguardano il software in via di sviluppo.

È importante fare la distinzione tra “prodotto” che è il risultato finito e “artefatto” che è un risultato intermedio nella fase di sviluppo.

Le qualità del software si influenzano tra di loro, quelle interne ovviamente influenzano quelle esterne e quelle di processo influenzano quelle di prodotto.

Principali qualità di un software

1. Correttezza: un programma deve soddisfare i requisiti funzionali specificati. Può essere definita formalmente o informalmente, in relazione alla formalità delle specifiche. Un prodotto può essere corretto o non corretto, non viene individuato un grado di correttezza; È una qualità di prodotto ed esterna.
2. Affidabilità: in modo informale -> è affidabile nella misura in cui l’utente può fare affidamento; In modo formale -> è la probabilità di assenza di errori per un certo periodo di tempo. Se non ci sono errori nelle specifiche, tutti i software corretti sono anche affidabili. È una qualità di prodotto ed esterna.
3. Robustezza: il software si comporta in modo accettabile anche in circostanze non previste. È una qualità di prodotto ed esterna.
4. Prestazioni: uso efficiente delle risorse; può essere valutata con un’analisi della complessità degli algoritmi. È una qualità esterna, sia di prodotto che di processo. È una qualità che implementa la scalabilità.
5. Usabilità: la facilità di utilizzo da parte degli utenti (user-friendly). È una qualità che dipende dagli utenti e perciò molto soggettiva, per questo motivo è difficile da calcolare. È una qualità di prodotto ed esterna.
6. Verificabilità: è la proprietà per cui può essere facilmente verificato che le proprietà di un prodotto siano soddisfatte. È una qualità di prodotto ed interna, ma può anche essere esterna se gli utenti richiedono la verificabilità di determinate caratteristiche, come ad esempio la sicurezza.
7. Manutenibilità: è la proprietà per cui un prodotto può essere facilmente modificato dopo il suo rilascio. Esistono 3 tipologie di manutenibilità:
   • Correttiva: se corregge errori nel software;
   • Adattiva: se effettua modifiche dovute al cambiamento dell’ambiente circostante;
   • Perfettiva: se punta a miglioramenti nel software.

   In particolare, la manutenzione adattiva e quella perfettiva si adattano solitamente prima dell’individuazione dei problemi, perciò si considerano “proattive” (atto a prevenire problemi futuri).

   In conseguenza a questa classificazione della manutenzione, si possono distinguere 2 tipi di manutenibilità:

   • Riparabilità: abilità a correggere i difetti in tempi ragionevoli;
   • Evolvibilità: abilità ad adattarsi ai cambiamenti in tempo ragionevole.
8. Riusabilità: proprietà per cui l’intero software o parti di esso possono essere riutilizzate per creare un altro software con poco lavoro. È una qualità di prodotto ed interna, ma può essere anche di processo.
9. Portabilità: proprietà per cui il software può essere eseguito in ambienti diversi sia a livello hardware che software. È una qualità di prodotto, di processo ed esterna.
10. Comprensibilità: il codice e la documentazione devono essere comprensibili poiché in caso di errori o modifiche deve essere facile copiare i processi applicativi. È una qualità di prodotto ed interna.
11. Interoperabilità: è la qualità per cui il sistema è in grado di cooperare con sistemi già esistenti. È una qualità di prodotto ed interna.
12. Produttività: velocità ed efficienza dello sviluppo. È una qualità di processo ed interna.
13. Tempestività: capacità di consegnare il prodotto in tempo. È una qualità di processo ed interna.
14. Visibilità: la documentazione di tutto lo sviluppo del processo deve essere chiara. È una qualità di processo interna ma anche esterna.

Principi dell’ingegneria del software

Metodi, tecniche, strumenti e metodologie

I principi sono regole importanti e generali da cui vengono ricavate altre. Essi descrivono proprietà desiderabili del processo e del prodotto in termini generali e astratti; i principi vengono poi applicati con metodi e tecniche.

I metodi sono linee guida generali che definiscono approcci rigorosamente sistematici.

Le tecniche sono più specifiche e meccaniche rispetto ai metodi e sono affidabili in maniera più limitata.

La combinazione di metodi e tecniche forma una metodologia, quindi, una metodologia ha lo scopo di promuovere un approccio per la soluzione di un problema mediante i metodi e le tecniche adatte al tipo di problema.

Una metodologia viene applicata utilizzando gli strumenti (tools).

Principi più importanti

I principi dell’ingegneria del software più importanti sono:

1. Rigore e formalità: nonostante lo sviluppo del software sia un’attività di tipo creativo, bisogna usare un approccio sistematico per realizzare un prodotto affidabile e la formalità è il livello più alto di rigore e richiede che il processo sia guidato e valutato in base a leggi matematiche. Esempio: documentazione del processo; analisi matematica della correttezza; test.
2. Separazione degli interessi: cioè affrontare in maniera separata aspetti diversi del problema, con l’approccio “divide et impera”. Con la separazione degli interessi è più facile dividere le responsabilità e parallelizzare il lavoro. Esempio: requisiti del prodotto raggruppati per categorie, fasi del processo distinte.
3. Modularità: suddividere un sistema complesso in moduli più piccoli e più semplici, rendendolo modulare. Questo principio supporta la “separazione degli interessi”, perché quando si lavora su un modulo si possono ignorare gli altri. Si raggiunge la modularità ottimale quando all’interno di un modulo le componenti sono strettamente sommerse tra loro e tra i vari moduli vi è un’interazione minima.
4. Astrazione: l’astrazione è un caso particolare della “separazione degli interessi” e consiste nell’identificare gli aspetti importanti di un sistema tralasciando i dettagli, ciò dà la possibilità di concentrarsi su un modello anziché sul sistema reale.
5. Anticipazione del cambiamento: prevedere i possibili cambiamenti futuri e rendere il sistema capace di evolvere facilmente in questa eventualità.
6. Generalità: quando deve essere risolto un problema si deve cercare di risolvere il problema generale in modo da riutilizzare il componente senza caricare una soluzione specifica per ogni impiego.
7. Incrementalità: il processo aumenta attraverso “passi” dette “incrementi”, l’incrementalità è soprattutto presente negli approcci di tipo agile, ma è presente in quasi tutti i processi.
8. Reflection: abilità di un software di modificarsi a runtime.

Processo di sviluppo di un software

Il processo di sviluppo è un insieme di azioni richieste per sviluppare un software e si suddivide in diverse parti:

1. Specificazione: fase in cui vengono definiti i requisiti derivanti dalle richieste dei clienti;
2. Design e implementazione: fase di progettazione del prodotto e quella di realizzazione effettiva;
3. Validazione: fase in cui viene verificata la correttezza del prodotto, quindi la fase in cui vengono fatti i test;
4. Evoluzione: fase in cui si attuano le modifiche al prodotto.

Quando un processo software viene descritto è necessario descriverne non solo le attività svolte ma anche i prodotti (ovvero il file del processo), i ruoli, le responsabilità di chi è coinvolto nel processo e le pre e post condizioni, cioè le condizioni che dovrebbero essere verificate prima e dopo il completamento del processo.

I processi si possono suddividere in:

1. Plan-Driven: in cui tutte le attività del processo sono pianificate a priori e il progresso viene misurato rispetto alle previsioni;
2. Agile: la pianificazione è di tipo incrementale ed è più facile adattarsi a nuovi requisiti del cliente.

La maggior parte dei processi pratici, comunque, include sia elementi di tipo plan-driven, sia elementi di tipo agile.

Inoltre, un processo può seguire diversi modelli:

1. A cascata (waterfall): un modello “plan-driven” in cui le varie fasi vengono eseguite in ordine e i feedback vengono raccolti solo alla fine;
2. Sviluppo incrementale: un modello in cui le varie fasi sono alternate: può essere “plan-driven” o “agile”;
3. Orientato al riutilizzo: è focalizzato sull’integrazione di componenti già esistenti in un nuovo sistema; può essere “plan-driven” o “agile”.

I processi reali prendono spunto da più modelli.

Modello a cascata

Le fasi attraversate da un processo che si basa sul modello a cascata sono:

1. Requirement analysis and definition: in questa fase avviene la specifica dei servizi, dei vincoli e degli obiettivi del prodotto finale;
2. System and software design: in questa fase viene descritta in modo generale l’architettura del prodotto;
3. Implementation and unit testing: in questa fase sono compresi lo sviluppo e quindi l’implementazione del prodotto e test svolti su ogni unità;
4. Integration and system testing: in questa fase le diverse unità sviluppate vengono integrate tra loro e vengono testate nel loro funzionamento totale;
5. Operation and maintenance: fase in cui il prodotto viene installato, utilizzato ed eventualmente modificato per essere adattato a nuovi requisiti.

In questa tipologia di modello è necessario completare una determinata fase prima di passare alla successiva, quindi, dato che la creazione di un software non è un processo propriamente lineare, questo modello porta un po’ di problemi:

• È adatto solo a tipologia di software in cui i requisiti rimangono stabili e non mutano con una certa facilità;
• Può essere utile solo in presenza di progetti di elevata dimensione sviluppati in luoghi diversi per coordinare meglio il lavoro;
• Normalmente viene usato solo in sistemi critici.

Modello di sviluppo incrementale

Le fasi attraversate da questo modello sono:

1. Analisi dei componenti: prevede l’analisi dei requisiti e la ricerca dei componenti adatti a soddisfarli;
2. Raffinamento requisiti: prevede un raffinamento dei requisiti in base ai componenti trovati;
3. Design del sistema con riutilizzo;
4. Sviluppo e integrazione: con l’utilizzo di questo modello si risparmia sui costi e sui tempi ma ovviamente è necessario fare dei componenti sui requisiti.

I componenti che possono essere riutilizzati sono: servizi web, componenti in un package e software stand-alone (può lavorare affine).

Attività di processo

Le reali attività di processo sono sequenze alternate di attività manageriali, tecniche e collaborative.

Le varie fasi di sviluppo sono organizzate in base al modello adottato: se “a cascata”, vengono eseguite in sequenza; se “incrementale”, vengono alternate tra loro.

Analizzia