Limiti Reverse Engineering dei sistemi Legacy
Il Reverse Engineering per i sistemi legacy è stato un argomento “caldo” per molti anni; la migrazione dei database basata sul Reverse Engineering dello schema dati è stata materia di ricerca da ormai 20 anni.
È evidente che quest’approccio punta solo a comprendere il sistema, per di più a partire dal solo aspetto tecnico, ma poi non prevede la sua modifica: al Reverse Engineering deve seguire qualche attività (nel passato era la manutenzione e/o la riscrittura completa del sistema) che migliori effettivamente il suo stato. In sostanza si tratta di un primo passo, propedeutico, ma che talvolta richiede già da solo una spesa così elevata (nel caso di grossi sistemi) da paralizzare le successive attività.
Gli approcci più moderni si occupano anch’essi di comprendere ed analizzare il sistema, ma solo negli aspetti strettamente necessari, mai con un obiettivo così totalizzante come la comprensione di tutti i moduli del sistema, e soprattutto con un’ottica più integrata che tenga conto del contesto (non basta partire dal codice, bisogna considerare anche il business e soprattutto il BPR, per comprendere se effettivamente alcune funzionalità siano ancora necessarie: è inutile spendere risorse per analizzare moduli del sistema che supportano processi che non hanno ragione di essere trasportati nel nuovo sistema realizzato).
Comunque questo non implica che il Reverse Engineering sia un approccio ormai marginale, ma indica che esso da solo non è più sufficiente e soprattutto va integrato, sia in scopi che in termini quantitativi, con gli altri approcci per aggredire il sistema.
