Anna Rita Fasolino » 11.I Processi di Manutenzione del Software

La Manutenzione del software- generalità

Qualsiasi software, dopo il rilascio della prima release, avrà bisogno di essere modificato.
I sistemi software sono, per loro natura, sistemi evolutivi che cambiano durante la loro vita.
Ciò deriva dal fatto che, durante la vita del sistema, le caratteristiche che lo definiscono cambiano, cambiando sia le esigenze di chi usa il software, sia dell’ambiente del mondo reale in cui il sistema opera.
Più i requisiti del sistema sono instabili, o specificano un problema in maniera incompleta ed approssimativa, più il sistema avrà bisogno di cambiare.

L’evoluzione di un software è dunque inevitabile!

Motivazioni per il cambiamento

• Errori possono essere individuati e devono essere corretti;
• Il dominio del software può evolvere;
• Nuovi requisiti possono emergere dopo il rilascio;
• Nuove tecnologie hardware e software possono affermarsi nel frattempo;
• Può essere necessario migliorare la qualità del software (ad esempio l’affidabilità o le performance).

L’importanza dell’evoluzione

Le organizzazioni proprietarie hanno fatto grossi investimenti per I loro sistemi software, che sono risorse critiche!
Per preservare il valore di tali risorse, I sistemi devono necessariamente cambiare ed evolvere.
La manutenzione è un’attività costosa e la maggior parte del budget speso per il software è in genere speso per la sua manutenzione, piuttosto che per il suo sviluppo.

I costi della manutenzione

Un tipico progetto di sviluppo software mediamente dura tra 1 e 2 anni, mentre la durata del periodo di manutenzione può variare tra 5 e 6 anni [1]

• Più della metà dei costi di un progetto software sono spesi per la manutenzione
• Recenti survey riportano la regola dell’ 80-20, ossia 80% di sforzo speso per la manutenzione e 20% per lo sviluppo.

[1] Parikh and Zvegintzov, Tutorial on Software Maintenance, IEEE, 1993.

Evoluzione o Declino?

Fino a che punto si può continuare a far evolvere un sistema software?
Quando si deve decidere di gettare il vecchio sistema e sostituirlo con uno nuovo?

Alcune domande da porsi:

• Il costo di manutenzione è troppo alto?
• L’affidabilità del sistema è inaccettabile?
• Non si riesce più ad adattare il software in tempi accettabili?
• Le prestazioni sono inaccettabili?
• Le funzionalità del sistema sono poco utili?
• Ci sono altri sistemi che fanno lo stesso lavoro meglio, più velocemente ed economicamente?
• Il costo di manutenzione dell’hardware è diventato tale da giustificare la sostituzione con nuovo hardware?

Leggi dell’Evoluzione del software

Ci sono delle regole valide in generale per i sistemi software, che ci permettono di capire cosa sta accadendo ad un sistema in evoluzione?
Una valida indicazione può giungerci dallo studio delle serie storiche di alcuni dati (es. dimensioni, complessità, risorse richieste, facilità di manutenzione).
Se l’evoluzione di tali dati seguisse un andamento ‘invariante’, dalla loro osservazione potremo dedurre cosa sta accadendo al software.

Leggi dell’evoluzione del software (segue)

Proposte da Lehman e Belady [1] a partire dal 1976, in seguito a studi empirici basati inizialmente sull’osservazione dell’evoluzione di 4 versioni successive di un S.O. IBM.

Leggi iniziali

• Modifiche continue
• Complessità crescente
• Evoluzione dei grandi sistemi leggi iniziali
• Stabilità organizzativa
• Conservazione della familiarità

Leggi più recenti

• Crescita continua
• Qualità deteriorata leggi più recenti
• Sistema feedback

[1] Lehman, Belady, Program Evolution: Process of Software Change. London: Academic Press (Cap. 21), 1985.

Le Leggi di Lehman

Modifiche continue

• Un sistema deve necessariamente cambiare, o diventerà progressivamente inutile.

Complessità crescente

• Quando un sistema viene modificato, la sua struttura si deteriora: per evitare ciò bisogna investire sulla manutenzione preventiva.

Evoluzione dei grandi sistemi

• I grandi sistemi hanno una loro dinamica che è caratterizzata da comportamenti e trends regolari che possono essere usati per fare predizioni: in particolare, la dimensione, il tempo fra due release successive, il numero di errori rilevati sono approssimativamente invarianti per ogni release.

Le Leggi di Lehman (segue)

Stabilità organizzativa

• Raggiunto lo stato ’saturo’, non ci possono essere variazioni significative nella produttività dello staff.

Conservazione della familiarità

• Le modifiche incrementali per ogni release sono approssimativamente costanti.

Crescita continua

• Le funzionalità offerte dai sistemi devono crescere continuamente, per la soddisfazione degli utenti.

Qualità deteriorata

• La qualità dei sistemi si deteriora se non si interviene con adattamenti ai nuovi ambienti operativi.

Sistema feedback

• I processi evolutivi incorporano sistemi feedback utili al miglioramento dei prodotti.

Applicabilità delle Leggi di Lehman

Le leggi di Lehman sembrano applicabili a sistemi di grandi dimensioni e personalizzati, sviluppati da vaste organizzazioni.

Non è chiaro come dovrebbero essere modificate per:

• Sistemi ottenuti attraverso wrapping;
• Sistemi che incorporano molti componenti COTS;
• Piccole organizzazioni;
• Sistemi di medie dimensioni.

Tipi di Manutenzione del software

Classificazione degli interventi 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.
• Manutenzione di emergenza: manutenzione correttiva non programmata, necessaria a mantenere il sistema in funzione.

Distribuzione dello sforzo di manutenzione

Fig.2: La distribuzione dello sforzo per classi di manutenzione. Da Lientz, Swanson, Problems in application software maintenance, 1981 Communication of the ACM.

Problemi della manutenzione

In gran parte dipendono dalla mancanza di controllo e disciplina nelle fasi di analisi e progetto del Ciclo di Vita del Software.
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 necessità di ri-testare il sistema dopo le modifiche;
• la gestione della configurazione del software.

Fattori di Costo della manutenzione

Stabilità del team

• I costi di manutenzione si riducono se lo stesso staff si occupa della manutenzione per lungo tempo.

Responsabilità contrattuale

• Sviluppo e manutenzione sono talvolta appaltati ad aziende diverse, cosicchè chi sviluppa non ha interesse a semplificare il lavoro di chi effettuerà la manutenzione.

Capacità dello staff

• Chi si occupa della manutenzione potrebbe non avere lo stesso livello di esperienza e pratica di chi lo ha sviluppato.

Età e struttura del programma

• Gli interventi di manutenzione tendono a far deteriorare la qualità del software e quindi a rendere più difficili tutti gli interventi di manutenzione necessari.

[v. anche G. Visaggio, "Giuseppe Visaggio: Ageing of a data-intensive legacy system: symptoms and remedies. Journal of Software Maintenance 13 (5): 281-308 (2001), Wiley]

Prevedere la manutenzione

Per una più efficace ed efficiente gestione di un sistema in evoluzione, è utile riuscire a:

• prevedere i probabili cambiamenti del sistema, e le parti più esposte ai cambiamenti;
• prevedere le parti più difficili da mantenere;
• prevedere i costi di manutenzione per un dato periodo.

Quali fattori possono essere considerati per fare tali previsioni?

Prevedere i cambiamenti del sistema

Per prevedere i probabili cambiamenti del sistema occorre analizzare le sue dipendenze dall’ambiente esterno:

• Più dipendenze ci sono, più è probabile che le modifiche dell’ambiente innescheranno modifiche nel software
• Elementi da valutare:
  • Numero e complessità delle interfacce del sistema;
  • Numero dei requisiti volatili (basati su requisiti di dominio instabili);
  • Processi aziendali in cui il sistema è usato (maggiore è tale numero, più probabili sono le possibili richieste di cambiamento).

Prevedere la manutenibilità

La manutenibilità può essere definita come la probabilità che, in determinate condizioni d’uso, una attività di manutenzione possa essere condotta entro un prefissato intervallo di tempo, usando definite procedure e risorse.

La manutenibilità può essere valutata da due diverse prospettive (interna ed esterna):

1. Prospettiva interna: analizzando attributi interni del software, come quelli relativi alla sua struttura.
2. Prospettiva esterna: si basa su attributi del processo di manutenzione.

Valutare la manutenibilità in base ad attributi interni del software

Molti studi hanno indagato la relazione fra attributi interni del software e manutenibilità.
Si è riscontrato che lo sforzo di manutenzione si concentrava sempre sui componenti più complessi.
Metriche di complessità usabili per predire:

• Complessità ciclomatica di McCabe
• Volume di Halstead,
• Numero di Linee di Codice (LOC)
• Fan-in, Fan-out
• Altre Metriche per valutare la leggibilità del codice …

Valutare la manutenibilità secondo la prospettiva esterna

Si usano dati sul processo di manutenzione per predire la manutenibilità

• Il numero di richieste di manutenzione correttiva: un loro aumento nel tempo può indicare riduzione della manutenibilità;
• Tempo medio richiesto per l’analisi dell’impatto;
• Tempo medio per implementare una richiesta di modifica;
• Numero di richieste di modifica in attesa.

Altri dati utili:
Numero di problemi non risolti, tempo speso su problemi non risolti, % di modifiche che hanno introdotto nuovi difetti, numero di componenti modificati per implementare una modifica.

Prevedere i costi di manutenzione

Si basa sulla previsione delle richieste di modifica e della manutenibilità del sistema.
Molti metodi di stima dei costi si basano sullo sforzo necessario per comprendere il software e per sviluppare nuovo codice (es. COCOMO2).
Es. Equazione di Lehman e Belady:

M= p+ K ^c-d

M= sforzo di manutenzione, p= sforzo di sviluppo totale, c è la complessità causata dalla mancanza di strutturazione e documentazione, d è il grado di familiarità del team di manutenzione col software.

Il processo di evoluzione del software

Fig.3: Il processo di evoluzione delle Release software.

Implementazione della modifica

Fig.4: Le attività necessarie per l'implementazione di una modifica .

Manutenzione “d’urgenza”

In alcuni casi le richieste di manutenzione devono essere soddisfatte rapidamente:

• Se un difetto serio deve essere riparato;
• Se modifiche dell’ambiente operativo causano effetti collaterali imprevisti sull’operatività del sistema;
• Se è necessario l’adeguamento urgente a seguito di cambiamenti imprevisti (es. Ambiente o mercato).

In questi casi, le fasi di analisi e progetto della modifica potrebbero non essere eseguite, implementando direttamente il cambiamento.