Nell’articolo “Ingegneria del software: non è fantascienza” sono stati introdotti i processi per la realizzazione di sistemi software ed i costi associati. Ma scendiamo nel dettaglio. Un processo software è un insieme di attività che porta alla creazione di un prodotto software, ma per l’immensa diversità di processi software esistenti e la non esistenza di un processo ideale, è possibile identificare solo delle attività fondamentali presenti in tutti i processi. Queste attività comuni sono: specifiche del software, progettazione ed implementazione del software, convalida del software, evoluzione del software.

Modelli dei processi software

Un modello di processo software è una rappresentazione astratta di un processo software; ogni modello rappresenta un processo da una particolare prospettiva e quindi fornisce solo delle informazioni parziali. Possono essere usati per spiegare diversi approcci allo sviluppo del software ed i tipici sono:

  • modello a cascata;
  • sviluppo evoluzionistico;
  • Ingegneria del software basata su componenti.

Questi modelli possono essere usati insieme per specificare lo sviluppo di un grande sistema o di sottosistemi diversi. Una variate a tali modelli è lo sviluppo di sistemi formali, dove viene creato un modello formale matematico del sistema, che viene modificato usando trasformazioni matematiche che preservano la sua consistenza fino all’eseguibile finale. Un esempio è il processo Cleanroom, dell’IBM: ogni incremento del software è specificato formalmente e la sua specifica trasformata in implementazione, l’esattezza del software è dimostrata usando un approccio formale, infatti il test del sistema si basa sulla stima della sua attendibilità.

Modello a cascata o ciclo di vita del software

Modello a cascata

Il nome deriva dal susseguirsi di una fase dopo l’altra, queste fasi sono:

  1. Analisi e definizione dei requisiti;
  2. Progettazione del sistema e del software;
  3. Implementazione e test delle unità;
  4. Integrazione e test del sistema;
  5. Operatività e manutenzione.

Il risultato di ogni fase è uno o più documenti approvati (signed off) e una fase non può partire se non è finita quella precedente. Nella pratica, però, le fasi sono sovrapposte e si scambiano informazioni.

A causa dei costi di produzione e approvazione dei documenti, i cicli sono costosi e quindi dopo un determinato numero di cicli vengono congelate alcune fasi ed i problemi vengono accantonati in attesa di una successiva soluzione, ignorati o aggirati. I vantaggi sono che ogni fase produce la documentazione relativa e si allinea ad altri modelli di processi ingegneristici, ma è un modello troppo rigido. Conviene usare tale modello solo se i requisiti sono ben compresi e non variano di molto durante la fase di sviluppo.

È possibile applicare una variante al modello a cascata per renderlo meno restrittivo, cioè l’inserimento del feedback: nel caso in cui si verifica un problema in una attività, è possibile una modifica a monte per poterlo risolvere.

Sviluppo evoluzionistico

Si basa sull’idea di sviluppare un’implementazione iniziale, esporla agli utenti e poi perfezionarla in versioni successive finché non si raggiunge il risultato desiderato. Le attività di specifica, sviluppo e convalida sono intrecciate con feedback veloci. Esistono 2 approcci:

  • Lo sviluppo esplorativo: si lavora con i clienti per esaminare i requisiti e fornire un sistema finale. Si inizia sviluppando le parti chiari del sistema e poi si aggiungono man mano tutte le funzionalità.
  • Prototipo “usa e getta”: una volta capiti i requisiti del cliente attraverso dei prototipi, si passa allo sviluppo completo del software.

Il vantaggio è che le specifiche si sviluppano in modo incrementale, ma il processo non è visibile e i sistemi sono mal strutturati. È ottimo per piccoli o medi sistemi, per grandi sistemi si usa un misto con il modello a cascata: le specifiche chiare vengono sviluppate con il modello a cascata, le altre invece, come l’interfaccia, attraverso il modello di sviluppo esplorativo.

Ingegneria del software basata su componenti (CBSE)

 

Ingegneria del software basata su componenti (CBSE)

Si basa sul riutilizzo di componenti software che sono già dei sistemi (sistemi COTS). Gli stadi sono:

  1. Analisi delle specifiche;
  2. Analisi dei componenti: data una specifica si cercano i componenti per implementarla;
  3. Modifica dei requisiti: si modificano i requisiti per adattarli ai componenti disponibili, se non è possibile si riesegue la fase precedente;
  4. Progettazione del sistema con riutilizzo;
  5. Sviluppo e integrazione: il software che non può essere riutilizzato deve essere scritto ed integrato ai COTS;
  6. Convalida del sistema.

Si riducono i costi e i rischi e si diminuiscono i tempi di consegna, però c’è il rischio di creare un sistema che non soddisfi a pieno i requisiti del cliente.