Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D Le Miniguide all'orientamento Gli eBook di Federica La Corte in Rete
 
I corsi di Ingegneria
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

Porfirio Tramontana » 24.Manutenzione del Software


Generalità

La manutenzione del software è il processo di modifica di un prodotto software dopo il suo rilascio in esercizio

  • per eliminare malfunzionamenti;
  • migliorare prestazioni o altri attributi di qualità;
  • adattarlo a modifiche dell’ambiente operativo.

Il termine manutenzione del software (o evoluzione del software) include spesso anche estensioni delle funzionalità originarie per soddisfare nuovi bisogni degli utenti.

70 % del budget software è speso in manutenzione.
75% del personale software svolge attività di manutenzione.

Leggi dell’evoluzione del software

Basate sull’osservazione di un S.O. IBM su 4 cicli di versioni maggiori.
Lehman e Belady, 1976.

  • I° legge: Cambiamento continuo
    • un programma utilizzato in un ambiente del mondo reale deve cambiare, oppure diventa progressivamente meno utile in quell’ambiente.
  • II° legge: Entropia crescente
    • Man mano che un programma cambia, la sua struttura degrada e la dimensione cresce, con il risultato di una complessità crescente;
    • Risorse addizionali sono richieste per preservarne la semantica e semplificarne la struttura.

Classi di manutenzione

  • Manutenzione correttiva
    • Modifiche per correggere difetti.
  • Manutenzione adattativa
    • Modifiche per adattare il software a cambiamenti dell’ambiente operativo (hardware, software di base, interfacce, organizzazione, legislazione, ecc.).
  • Manutenzione perfettiva
    • Estensione dei requisiti funzionali, o migliorie di requisiti non funzionali in risposta a richieste dell’utente.
  • Manutenzione preventiva
    • Modifiche che rendono più semplici le correzioni, gli adattamenti e le migliorie.

Distribuzione dello sforzo di manutenzione


Problemi della manutenzione

In gran parte dipendono dalla mancanza di controllo e disciplina nelle fasi di analisi e progetto del CVS.
Alcuni fattori tecnici:

  • difficoltà nel comprendere un programma scritto da altri;
  • mancanza di documentazione completa/ consistente;
  • software non progettato per modifiche future;
  • difficoltà nel tradurre una richiesta di modifica di funzionamento del sistema in una modifica del software;
  • valutazione dell’impatto di ciascuna modifica sull’intero sistema;
  • la gestione della configurazione del software;
  • la necessità di ritestare il sistema dopo le modifiche.

Modelli di processo per la manutenzione del software

  • Modello di riparazione veloce (Quick-fix model)
    • modifiche al codice in termini di patches (‘pezze’)
    • veloce ed economico sul breve termine
    • degradazione delle struttura
    • documentazione modificata a posteriori
  • Modello di miglioramento iterativo (iterative-enhancement model)
    • valutazione preventiva dell’impatto della modifica
    • decisione se lavorare su componenti esistenti o sviluppare nuove componenti
    • preserva la struttura
    • lento e costoso sul breve termine
    • documentazione modificata in anticipo

Standard IEEE 1219, 1993


Problemi della manutenzione d’urgenza

In molti casi si ricorre comunque alla manutenzione “d’urgenza”…

  • Se un difetto serio deve essere riparato;
  • Se modifiche dell’ambiente causano effetti collaterali imprevisti;
  • Se è necessario l’adeguamento urgente a seguito di un cambiamento delle regole di business.

In questo caso si possono anticipare il più possibile le fasi di implementazione del cambiamento

  • Ma la qualità complessiva del software si ridurrà
    • Potrebbe essere utile un successivo intervento di aggiornamento della documentazione e/o di miglioramento della qualità del software → Reengineering.

Reengineering

La reingegnerizzazione (reengineering) di un sistema software è un’attività nella quale si vuole migliorare la qualità di un software esistente, allo scopo di rendere più semplici gli interventi di manutenzione. Essa può comprendere:

  • Ristrutturazione e riscrittura di parte del software (o anche di tutto), senza modificare l’insieme di funzionalità che esso realizza;
  • Ridocumentazione e aggiornamento della documentazione.

La ridocumentazione, implicando la comprensione del software da reingegnerizzare, è una operazione preliminare necessaria alla ristrutturazione e alla riscrittura del software.

Restructuring vs. Reengineering

Restructuring o refactoring
attività che trasforma il codice esistente in codice equivalente dal punto di vista funzionale, ma migliorato dal punto di vista della sua qualità.
Reengineering
attività di ristrutturazione a livello della riorganizzazione dell’architettura modulare di un sistema; si parte da una certa organizzazione dei moduli del sistema e del relativo flusso dati, e se ne producono altre con migliori caratteristiche di qualità, come ad esempio, la riduzione dell’accoppiamento fra i moduli, il controllo dell’uso di variabili globali e la riorganizzazione di data repository e così via.

Refactoring

Refactoring is the art of improving the design of existing code. Refactoring provides us with ways to recognize problematic code and gives us recipes for improving it.” [William C. Wake].

A change to the system that leaves its behavior unchanged, but enhances some non-functional quality – simplicity, flexibility, understandability, …” [Kent Beck].

The process of changing a software system in such a way that it does not alter the external behavior of the code, yet improves its internal structure” [Fowler].

Esempi di Refactoring

Net Beans Refactoring

Net Beans Refactoring

Eclipse Refactoring

Eclipse Refactoring


Attività del processo di reengineering

  • Source code translation
    • Conversione (eventuale) del codice verso il nuovo linguaggio target.
  • Reverse engineering
    • Comprensione del programma con generazione di documentazione.
  • Program structure improvement
    • Refactoring automatico allo scopo di migliorare la comprensibilità del programma.
  • Program modularisation
    • Refactoring che punta ad aumentare la modularizzazione (e di conseguenza la qualità) del codice.
  • Data reengineering
    • Ristrutturazione dei dati allo scopo di migliorare la qualità dei dati (rendere l’accesso più veloce, eliminare ridondanze e problemi di normalizzazione, etc.).

Reverse Engineering

Il Reverse Engineering (RE) è un insieme di teorie, modelli, metodi, tecniche e tecnologie per:

  • il progetto e l’implementazione di processi di estrazione ed astrazione di informazioni da componenti di un sistema software esistente e la produzione di nuovi componenti ad un livello di astrazione maggiore e consistenti con quelli di partenza;
  • l’aggiunta ai componenti prodotti di conoscenza ed esperienza che non può essere ricostruita direttamente ed automaticamente dai componenti analizzati.

Problemi indecibili nel Reverse Engineering

Non è possibile, a partire dal solo codice, astrarre il progetto dal quale esso è stato prodotto ma non è invece indecidibile il problema di astrarre un progetto coerente con il codice;

Non è possibile, a partire dal solo programma oggetto, astrarre il programma sorgente dal quale esso è stato prodotto ma non è invece indecidibile il problema di astrarre un programma sorgente che generi il dato programma oggetto.

Le decisioni di progetto si perdono nei pozzi neri del software! Per ricostruirle occorre l’aggiunta di conoscenza da parte dell’ingegnere del software (il processo di RE non è automatizzabile completamente).

Scopi del Reverse Engineering

Individuare i componenti del software e le relazioni esistenti tra essi;
Creare rappresentazioni del prodotto ad un più alto livello di astrazione;
Comprendere e descrivere le funzioni svolte dal prodotto stesso e le modalità con cui esse sono state implementate.

Si distinguono fasi di:

  • Estrazione
    • Analisi statica del codice, allo scopo di produrre una documentazione consistente del codice analizzato;
    • Particolarmente utili sono quelli strumenti in grado di estrarre informazioni da un codice sorgente qualsiasi, nota che sia la grammatica del linguaggio di programmazione (ad esempio JavaCC).
  • Astrazione
    • Si esaminano le informazioni estratte e si cercano di astrarre diagrammi ad un più alto livello di astrazione (es.: diagrammi di progetto, architetturali, del dominio dei dati);
    • I processi di astrazione non sono completamente automatizzabili poichè necessitano di conoscenza ed esperienza umana.

Il problema dei Legacy Systems

  • Un sistema legacy (“ereditato”) é spesso vecchio (10 anni o più di vita);
  • É di grandi dimensioni (centinania di migliaia di linee di codice);
  • É scritto in assembler o in un linguaggio di vecchia generazione;
  • É stato probabilmente sviluppato prima che si diffondessero I moderni principi dell’ingegneria del software;
  • La manutenzione é stata svolta in modo da seguire le modifiche nei requisiti, aumentando così l’entropia (il disordine) del sistema;
  • La manutenzione risulta ormai difficile e costosa;
  • Realizza funzionalità cruciali e irrinunciabili per l’organizzazione;
  • Contiene anni di esperienza accumulata nell’ambito del dominio specifico del problema.

Il problema

Un sistema legacy obbliga il management a cercare soluzioni e strategie di manutenzione vincenti!

Svariate alternative disponibili:

  • Eliminazione del sistema e sviluppo di un nuovo sistema;
  • Recupero dei componenti più preziosi del sistema, sostituendo i restanti con prodotti preconfezionati (COTS);
  • Eliminazione dei componenti ormai inutili, del codice obsoleto e dei dati “morti”;
  • Congelamento del sistema as is, e riutilizzo mediante tecniche di wrapping;
  • Manutenzione Ordinaria;
  • Manutenzione Preventiva (re-documentation, restructuring o reengineering);
  • Migrazione …

Come decidere?

Occorre valutare il sistema sia da una prospettiva Economica che Tecnica.
Prospettiva Economica (Business Value):
L’azienda ha realmente bisogno del sistema?

Prospettiva Tecnica:
Qual è la qualità del software applicativo, e del suo ambiente di utilizzo (software che hardware)?

Legacy system categories

  • Low quality, low business value
    • Dovrebbe essere abbandonato;
  • Low-quality, high-business value
    • Realizza funzionali importante ma è costoso mantenerlo. Dovrebbe essere reingegnerizzato in modo da rendere le future (necessarie) operazioni di manutenzione più agevoli ed efficaci (cioè finire nel quarto caso);
  • High-quality, low-business value
    • Si può decidere sia di abbandonarlo (in quanto poco importante), sia di rimpiazzarlo con COTS (se realizza qualcosa di generale, indipendente dal dominio specifico) oppure mantenerlo (dato che i costi di manutenzione saranno limitati);
  • High-quality, high business value
    • Su di esso si eseguono le operazioni di manutenzione
      • In questo modo, però, la qualità diventerà via via più bassa, fino a finire nel secondo caso.

I materiali di supporto della lezione

Ian Sommerville, Ingegneria del Software, 8a ed. Capitolo 21.

  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion