Panoramica della manutenzione del software

La manutenzione del software è ormai ampiamente accettata come parte di SDLC. Significa tutte le modifiche e gli aggiornamenti effettuati dopo la consegna del prodotto software. Ci sono diversi motivi per cui sono necessarie modifiche, alcune di esse sono brevemente menzionate di seguito:

  • Market Conditions - Le politiche, che cambiano nel tempo, come la tassazione e vincoli di recente introduzione come, come mantenere la contabilità, possono far scattare la necessità di modifiche.

  • Client Requirements - Nel tempo, il cliente potrebbe richiedere nuove caratteristiche o funzioni nel software.

  • Host Modifications - Se l'hardware e / o la piattaforma (come il sistema operativo) dell'host di destinazione cambia, sono necessarie modifiche al software per mantenere l'adattabilità.

  • Organization Changes - Se si verifica un cambiamento a livello aziendale a livello di cliente, come riduzione della forza dell'organizzazione, acquisizione di un'altra azienda, organizzazione che si avventura in nuove attività, potrebbe sorgere la necessità di modificare il software originale.

Tipi di manutenzione

Durante la vita del software, il tipo di manutenzione può variare in base alla sua natura. Potrebbe essere solo un'attività di manutenzione ordinaria come un bug scoperto da qualche utente o potrebbe essere un evento di grandi dimensioni in sé in base alle dimensioni o alla natura della manutenzione. Di seguito sono riportati alcuni tipi di manutenzione in base alle loro caratteristiche:

  • Corrective Maintenance - Ciò include modifiche e aggiornamenti effettuati per correggere o risolvere problemi, che vengono rilevati dall'utente o conclusi da rapporti di errore dell'utente.

  • Adaptive Maintenance - Ciò include modifiche e aggiornamenti applicati per mantenere il prodotto software aggiornato e sintonizzato sul mondo in continua evoluzione della tecnologia e dell'ambiente aziendale.

  • Perfective Maintenance- Ciò include modifiche e aggiornamenti effettuati al fine di mantenere il software utilizzabile per un lungo periodo di tempo. Include nuove funzionalità, nuovi requisiti utente per perfezionare il software e migliorarne l'affidabilità e le prestazioni.

  • Preventive Maintenance- Ciò include modifiche e aggiornamenti per prevenire futuri problemi del software. Ha lo scopo di occuparsi di problemi, che non sono significativi in ​​questo momento, ma che potrebbero causare seri problemi in futuro.

Costo della manutenzione

I rapporti suggeriscono che il costo della manutenzione è elevato. Uno studio sulla stima della manutenzione del software ha rilevato che il costo della manutenzione raggiunge il 67% del costo dell'intero ciclo di processo del software.

In media, il costo della manutenzione del software è superiore al 50% di tutte le fasi SDLC. Ci sono vari fattori che determinano un aumento dei costi di manutenzione, come ad esempio:

Fattori del mondo reale che influenzano i costi di manutenzione

  • L'età standard di qualsiasi software è considerata fino a 10-15 anni.
  • I software più vecchi, che dovevano funzionare su macchine lente con meno memoria e capacità di archiviazione, non possono resistere alla sfida contro i nuovi software migliorati su hardware moderno.
  • Con l'avanzare della tecnologia, diventa costoso mantenere il vecchio software.
  • La maggior parte dei tecnici della manutenzione è alle prime armi e utilizza metodi di prova ed errore per correggere il problema.
  • Spesso, le modifiche apportate possono facilmente danneggiare la struttura originale del software, rendendo difficile qualsiasi modifica successiva.
  • Le modifiche vengono spesso lasciate non documentate, il che potrebbe causare ulteriori conflitti in futuro.

Fattori di fine software che influenzano i costi di manutenzione

  • Struttura del programma software
  • Linguaggio di programmazione
  • Dipendenza dall'ambiente esterno
  • Affidabilità e disponibilità del personale

Attività di manutenzione

IEEE fornisce una struttura per le attività del processo di manutenzione sequenziale. Può essere utilizzato in modo iterativo e può essere esteso in modo da includere elementi e processi personalizzati.

Queste attività vanno di pari passo con ciascuna delle seguenti fasi:

  • Identification & Tracing- Comporta attività relative all'individuazione del requisito di modifica o manutenzione. Viene generato dall'utente o il sistema stesso può segnalare tramite log o messaggi di errore. Qui viene classificato anche il tipo di manutenzione.

  • Analysis- La modifica viene analizzata per il suo impatto sul sistema, comprese le implicazioni in materia di sicurezza e protezione. Se il probabile impatto è grave, si cerca una soluzione alternativa. Una serie di modifiche richieste viene quindi concretizzata nelle specifiche dei requisiti. Si analizza il costo di modifica / manutenzione e si conclude la stima.

  • Design- I nuovi moduli, che devono essere sostituiti o modificati, sono progettati in base alle specifiche dei requisiti fissate nella fase precedente. I casi di test vengono creati per la convalida e la verifica.

  • Implementation - I nuovi moduli sono codificati con l'aiuto di un design strutturato creato nella fase di progettazione. Ogni programmatore dovrebbe eseguire test unitari in parallelo.

  • System Testing- Il test di integrazione viene eseguito tra i moduli di nuova creazione. Viene inoltre eseguito il test di integrazione tra i nuovi moduli e il sistema. Infine il sistema viene testato nel suo complesso, seguendo procedure di test regressivo.

  • Acceptance Testing- Dopo aver testato internamente il sistema, viene testato per l'accettazione con l'aiuto degli utenti. Se in questo stato l'utente lamenta alcuni problemi, vengono risolti o annotati per risolverli nella successiva iterazione.

  • Delivery- Dopo il test di accettazione, il sistema viene distribuito in tutta l'organizzazione tramite un piccolo pacchetto di aggiornamento o una nuova installazione del sistema. Il test finale viene eseguito al client dopo la consegna del software.

    Se necessario, viene fornita una struttura di formazione oltre alla copia cartacea del manuale dell'utente.

  • Maintenance management- La gestione della configurazione è una parte essenziale della manutenzione del sistema. È supportato con strumenti di controllo della versione per controllare le versioni, la semi-versione o la gestione delle patch.

Reingegnerizzazione del software

Quando dobbiamo aggiornare il software per mantenerlo al mercato attuale, senza influire sulla sua funzionalità, si parla di reingegnerizzazione del software. Si tratta di un processo completo in cui la progettazione del software viene modificata e i programmi vengono riscritti.

Il software legacy non è in grado di mantenere la sintonizzazione con la tecnologia più recente disponibile sul mercato. Man mano che l'hardware diventa obsoleto, l'aggiornamento del software diventa un mal di testa. Anche se il software invecchia con il tempo, la sua funzionalità non lo fa.

Ad esempio, inizialmente Unix è stato sviluppato in linguaggio assembly. Quando il linguaggio C è nato, Unix è stato riprogettato in C, perché lavorare in linguaggio assembly era difficile.

Oltre a questo, a volte i programmatori notano che poche parti del software richiedono più manutenzione di altre e hanno anche bisogno di una riprogettazione.

Processo di reingegnerizzazione

  • Decidecosa riprogettare. È un intero software o una parte di esso?
  • Perform Reverse Engineering, al fine di ottenere le specifiche del software esistente.
  • Restructure Programse richiesto. Ad esempio, cambiare i programmi orientati alle funzioni in programmi orientati agli oggetti.
  • Re-structure data come richiesto.
  • Apply Forward engineering concetti per ottenere software riprogettato.

Ci sono pochi termini importanti usati nella riprogettazione del software

Reverse Engineering

È un processo per ottenere le specifiche del sistema analizzando e comprendendo a fondo il sistema esistente. Questo processo può essere visto come un modello SDLC inverso, ovvero cerchiamo di ottenere un livello di astrazione più elevato analizzando livelli di astrazione più bassi.

Un sistema esistente è stato precedentemente implementato design, di cui non sappiamo nulla. I progettisti quindi eseguono il reverse engineering guardando il codice e provano a ottenere il progetto. Con il design in mano, cercano di concludere le specifiche. Quindi, andando al contrario dal codice alla specifica del sistema.

Ristrutturazione del programma

È un processo per ri-strutturare e ricostruire il software esistente. Si tratta di riorganizzare il codice sorgente, nello stesso linguaggio di programmazione o da un linguaggio di programmazione a un altro. La ristrutturazione può comportare la ristrutturazione del codice sorgente e la ristrutturazione dei dati o entrambe.

La ristrutturazione non influisce sulla funzionalità del software ma migliora l'affidabilità e la manutenibilità. I componenti del programma, che causano errori molto frequentemente, possono essere modificati o aggiornati con la ristrutturazione.

L'affidabilità del software su una piattaforma hardware obsoleta può essere rimossa tramite la ristrutturazione.

Forward Engineering

Il forward engineering è un processo per ottenere il software desiderato dalle specifiche in mano che sono state eliminate mediante reverse engineering. Si presume che in passato fosse già stata eseguita un'ingegneria del software.

Il forward engineering è lo stesso del processo di ingegneria del software con una sola differenza: viene eseguito sempre dopo il reverse engineering.

Riutilizzabilità dei componenti

Un componente è una parte del codice del programma software, che esegue un'attività indipendente nel sistema. Può essere un piccolo modulo o un sottosistema stesso.

Esempio

Le procedure di accesso utilizzate sul web possono essere considerate come componenti, il sistema di stampa nel software può essere visto come un componente del software.

I componenti hanno un'elevata coesione di funzionalità e un tasso di accoppiamento inferiore, ovvero funzionano in modo indipendente e possono svolgere compiti senza dipendere da altri moduli.

In OOP, gli oggetti progettati sono molto specifici per la loro preoccupazione e hanno meno possibilità di essere utilizzati in altri software.

Nella programmazione modulare, i moduli sono codificati per eseguire attività specifiche che possono essere utilizzate attraverso numerosi altri programmi software.

Esiste un verticale completamente nuovo, basato sul riutilizzo di componenti software, noto come Component Based Software Engineering (CBSE).

Il riutilizzo può essere effettuato a vari livelli

  • Application level - Quando un'intera applicazione viene utilizzata come sottosistema di nuovo software.

  • Component level - Dove viene utilizzato il sottosistema di un'applicazione.

  • Modules level - Dove i moduli funzionali vengono riutilizzati.

    I componenti software forniscono interfacce che possono essere utilizzate per stabilire la comunicazione tra diversi componenti.

Processo di riutilizzo

È possibile adottare due tipi di metodo: o mantenendo gli stessi requisiti e regolando i componenti oppure mantenendo gli stessi componenti e modificando i requisiti.

  • Requirement Specification - Vengono specificati i requisiti funzionali e non funzionali a cui un prodotto software deve soddisfare, con l'aiuto del sistema esistente, l'input dell'utente o entrambi.

  • Design- Questa è anche una fase del processo SDLC standard, in cui i requisiti sono definiti in termini di linguaggio software. Viene creata l'architettura di base del sistema nel suo insieme e dei suoi sottosistemi.

  • Specify Components - Studiando la progettazione del software, i progettisti separano l'intero sistema in componenti o sottosistemi più piccoli. Un progetto software completo si trasforma in una raccolta di un enorme set di componenti che lavorano insieme.

  • Search Suitable Components - Il repository dei componenti software viene indirizzato dai progettisti per cercare il componente corrispondente, sulla base della funzionalità e dei requisiti software previsti.

  • Incorporate Components - Tutti i componenti abbinati vengono imballati insieme per modellarli come software completo.