SVILUPPO SOFTWARE-4.docx

**SVILUPPO SOFTWARE** **Rapid Software Development** (Sviluppo rapido del software) è una metodologia progettata per rispondere alle esigenze di un ambiente aziendale in rapida evoluzione, dove le richieste cambiano velocemente e la velocità di consegna del software diventa essenziale. **Punti chi...

**SVILUPPO SOFTWARE** **Rapid Software Development** (Sviluppo rapido del software) è una metodologia progettata per rispondere alle esigenze di un ambiente aziendale in rapida evoluzione, dove le richieste cambiano velocemente e la velocità di consegna del software diventa essenziale. **Punti chiave:** 1. **Strumenti RAD**: Gli strumenti RAD (Rapid Application Development) facilitano la creazione rapida di applicazioni tramite prototipazione rapida, strumenti di modellazione visiva e generatori automatici di codice. Questi strumenti riducono il tempo di sviluppo. 2. **Riutilizzo di sistemi già esistenti**: Invece di costruire il software completamente da zero, si sfruttano componenti già sviluppati, come sistemi commerciali pronti all\'uso (off-the-shelf systems), accelerando così il processo. 3. **Sviluppo Agile**: Lo sviluppo rapido si allinea spesso con la metodologia Agile, che prevede cicli di sviluppo brevi (sprint), feedback continui e iterazioni incrementali. **Contesto aziendale:** Le aziende operanti in ambienti in rapido cambiamento sono disposte a sacrificare temporaneamente la qualità complessiva del software pur di ottenere rapidamente una versione funzionante che fornisca le funzionalità essenziali. L\'idea è di rilasciare una prima versione del software, correggere eventuali problemi successivamente e continuare a migliorarlo con aggiornamenti successivi. **Vantaggi:** - **Time-to-market ridotto**: Le funzionalità essenziali vengono rilasciate in tempi molto più rapidi. - **Maggiore flessibilità**: Il software può essere rapidamente adattato alle nuove esigenze aziendali. **Svantaggi:** - **Qualità inferiore**: La necessità di consegnare velocemente può portare a compromessi sulla qualità del codice o sulla robustezza del software. - **Maggiori costi di manutenzione**: Il software potrebbe necessitare di più correzioni e manutenzioni a lungo termine a causa della rapidità con cui è stato sviluppato. Le **Requirements** (requisiti) nel contesto dello sviluppo rapido del software (RAD) sono difficili da definire e stabilizzare a causa dell\'ambiente in continuo cambiamento. Questo rende impraticabile l\'uso di modelli tradizionali come il **modello a cascata** (waterfall), che prevede una sequenza lineare di fasi (analisi dei requisiti, progettazione, implementazione, ecc.). Invece, si preferisce un approccio **iterativo** che permette una specifica continua e incrementale del sistema. Le caratteristiche dei processi RAD (Rapid Application Development) sono: 1. **Processi paralleli**: Specifica, progettazione e implementazione avvengono contemporaneamente per ridurre i tempi di sviluppo. 2. **Documentazione ridotta**: Si minimizza la documentazione dettagliata, concentrandosi sullo sviluppo rapido del software. 3. **Sviluppo incrementale**: Il sistema è sviluppato e rilasciato in incrementi, con feedback continuo degli utenti per migliorare le versioni successive. 4. **Interfaccia utente interattiva**: L\'interfaccia viene prototipata e migliorata rapidamente grazie al feedback degli utenti. **vantaggi dello sviluppo incrementale:** 1. **Consegna accelerata**: Ogni incremento fornisce le funzionalità prioritarie, accelerando la consegna dei servizi al cliente. 2. **Coinvolgimento degli utenti**: Gli utenti sono coinvolti durante lo sviluppo, aumentando le probabilità che il sistema soddisfi le loro esigenze e il loro impegno verso il progetto. **Problemi dello sviluppo incrementale:** 1. **Problemi di gestione**: Senza documentazione dettagliata, è difficile valutare i progressi e individuare i problemi. 2. **Problemi contrattuali**: Senza una specifica formale, i contratti tradizionali risultano difficili da gestire e devono essere adattati. 3. **Problemi di validazione**: Senza una specifica chiara, diventa difficile capire contro cosa testare il sistema. 4. **Problemi di manutenzione**: Le modifiche continue possono compromettere la struttura del software, rendendo più costosa l\'evoluzione e la manutenzione futura. Lo **sviluppo incrementale** mira a consegnare rapidamente un sistema funzionante, partendo dai requisiti meglio compresi per fornire funzionalità utilizzabili. Il **prototyping usa e getta**, invece, si concentra sulla validazione dei requisiti meno chiari, utilizzando prototipi per ottenere feedback e chiarire le esigenze. Un **prototipo** è una versione preliminare del sistema utilizzata per esplorare design e requisiti. Può essere impiegato per migliorare la raccolta dei requisiti, progettare l\'interfaccia utente o eseguire test. I **prototipi usa e getta** vengono eliminati dopo lo sviluppo, poiché non sono ottimizzati, non sono documentati, hanno una struttura degradata e non rispettano gli standard di qualità. Gli **ambienti RAD** (Rapid Application Development) sono progettati per sviluppare rapidamente applicazioni aziendali che gestiscono grandi quantità di dati, utilizzando strumenti che facilitano la programmazione e la presentazione delle informazioni da un database. Gli strumenti tipici includono: - **Linguaggio di programmazione per database** per gestire e manipolare dati. - **Generatore di interfacce** per creare rapidamente interfacce utente. - **Collegamenti a applicazioni di ufficio** come elaboratori di testi o fogli di calcolo. - **Generatore di report** per creare report sui dati. **Metodi Agile**: I metodi agili sono nati dalla frustrazione per i pesanti processi di progettazione tradizionali. Questi metodi: - Si concentrano più sul codice che sul design. - Si basano su un approccio iterativo allo sviluppo software. - Puntano a consegnare rapidamente software funzionante, che può evolversi per soddisfare nuovi requisiti. Sono particolarmente adatti per sistemi aziendali di piccole o medie dimensioni o per prodotti software per PC. **Principi dei metodi Agile**: 1. **Coinvolgimento del cliente**: Il cliente è strettamente coinvolto in tutto il processo di sviluppo, fornendo e dando priorità ai requisiti, e valutando le iterazioni del sistema. 2. **Consegna incrementale**: Il software viene sviluppato in incrementi, con il cliente che specifica i requisiti per ogni incremento. 3. **Persone, non processi**: Le abilità del team di sviluppo vengono valorizzate, e il team è libero di organizzarsi senza processi rigidi. 4. **Accogliere i cambiamenti**: Si prevede che i requisiti cambino, e il sistema deve essere progettato per adattarsi ai cambiamenti. 5. **Mantenere la semplicità**: Si cerca di mantenere il software e il processo di sviluppo il più semplice possibile, eliminando la complessità. **Problemi dei metodi Agile**: - È difficile mantenere costante l\'interesse del cliente nel processo. - Non tutti i membri del team potrebbero essere adatti al coinvolgimento intenso che caratterizza i metodi agili. - Dare priorità ai cambiamenti può essere complicato quando ci sono molti stakeholder. - Mantenere la semplicità richiede uno sforzo extra. - I contratti possono rappresentare una difficoltà, come in altri approcci di sviluppo iterativo. **Extreme Programming (XP)** è uno dei metodi agili più conosciuti e utilizzati, caratterizzato da un approccio \"estremo\" all\'iterazione nello sviluppo software. La sua filosofia si basa sulla rapida evoluzione e sul coinvolgimento attivo del cliente nel processo di sviluppo. **Caratteristiche di Extreme Programming:** 1. **Iterazioni Veloci**: - Le nuove versioni del software possono essere costruite più volte al giorno. - Incrementi sono consegnati ai clienti ogni due settimane. - Ogni build deve superare tutti i test; solo le build che superano i test vengono accettate. **Pratiche di Extreme Programming:** 1. **Pianificazione Incrementale**: - I requisiti sono registrati su \"Story Cards\" e le storie da includere in una release sono determinate in base al tempo disponibile e alla loro priorità. - Le storie vengono suddivise in \"Tasks\" di sviluppo. 2. **Piccole Rilasci**: - Si sviluppa prima il set minimo di funzionalità utile per fornire valore al business. - Rilasci frequenti incrementano progressivamente le funzionalità. 3. **Design Semplice**: - Si esegue solo la progettazione necessaria a soddisfare i requisiti correnti. 4. **Sviluppo \"Test First\"**: - Si utilizza un framework di test automatizzati per scrivere i test per una nuova funzionalità prima di implementarla. 5. **Refactoring**: - Gli sviluppatori sono incoraggiati a rifattorizzare continuamente il codice non appena vengono trovati miglioramenti. 6. **Programmazione in Coppia**: - Due sviluppatori lavorano insieme, controllando il lavoro dell\'altro e sostenendosi a vicenda per garantire un buon lavoro. 7. **Proprietà Collettiva**: - I team lavorano su tutte le aree del sistema, evitando specializzazioni che portano a \"isole di expertise\". Qualunque sviluppatore può modificare qualsiasi parte del codice. 8. **Integrazione Continua**: - Non appena un task è completato, viene integrato nel sistema. Tutti i test unitari devono passare dopo ogni integrazione. 9. **Pace Sostenibile**: - Non è accettabile un\'elevata quantità di ore straordinarie, poiché ciò riduce la qualità del codice e la produttività a lungo termine. 10. **Cliente In Sede**: - Un rappresentante del cliente deve essere disponibile a tempo pieno per il team di XP. In questo contesto, il cliente è considerato parte del team di sviluppo e porta i requisiti per l\'implementazione. **Scenari di Requisiti:** In XP, i requisiti utente sono espressi come scenari o \"user stories\", che vengono scritte su schede. Queste storie vengono suddivise in compiti di implementazione e sono la base per le stime di programma e costo. Il cliente sceglie le storie da includere nel prossimo rilascio, basandosi su priorità e stime di programma. **Testing e Pair Programming in Extreme Programming (XP)** **Testing in XP**: - **Sviluppo \"Test-First\"**: I test sono scritti prima del codice, chiarendo i requisiti e garantendo che le nuove funzionalità non introducano errori. - **Sviluppo Incrementale dei Test**: I test vengono sviluppati e aggiornati in base a scenari e storie degli utenti, eseguendo tutti i test automaticamente ad ogni nuova release. - **Coinvolgimento degli Utenti**: Gli utenti partecipano attivamente alla validazione dei test, assicurando che rispecchino le loro esigenze. - **Utilizzo di strumenti automatizzati**: Si utilizzano strumenti per eseguire test dei componenti in modo continuo, garantendo un controllo di qualità costante. **Pair Programming**: - Gli sviluppatori lavorano in coppie, favorendo: - **Proprietà Condivisa del Codice**: Promuove un senso di responsabilità comune. - **Condivisione della Conoscenza**: Diffonde le competenze all\'interno del team. - **Revisione Informale**: Ogni riga di codice è esaminata da più persone. - **Facilitazione del Refactoring**: Permette miglioramenti continui del codice. - **Produttività Simile**: La produttività è paragonabile a quella di due programmatori che lavorano separatamente. SOFTWARE RIUSO **Tipologie di Riutilizzo**: 1. **Riutilizzo di Sistemi Applicativi**: - L\'intero sistema applicativo può essere riutilizzato, sia incorporandolo senza modifiche in altri sistemi (riutilizzo di COTS - Commercial Off-The-Shelf), sia sviluppando famiglie di applicazioni. 2. **Riutilizzo di Componenti**: - I componenti di un\'applicazione, che vanno da sotto-sistemi a singoli oggetti, possono essere riutilizzati in vari contesti. 3. **Riutilizzo di Oggetti e Funzioni**: - Componenti software che implementano un singolo oggetto o funzione ben definita possono essere riutilizzati in altre applicazioni. **Panorama della Riutilizzazione**: - Esistono diversi approcci al riutilizzo del software, con possibilità che spaziano da semplici funzioni a sistemi applicativi completi. Questa varietà consente di adottare strategie di riutilizzo che meglio si adattano alle specifiche esigenze dei progetti. **Approcci di Riutilizzo** 1. **Design Patterns**: Astrazioni generici che offrono soluzioni comuni a problemi di progettazione. 2. **Sviluppo Basato su Componenti**: Integrazione di componenti conformi a standard di modelli, facilitando l\'assemblaggio di sistemi. 3. **Framework Applicativi**: Raccolte di classi adattabili e ampliabili per creare applicazioni. 4. **Avvolgimento di Sistemi Legacy**: Creazione di interfacce per accedere e integrare sistemi più vecchi. 5. **Sistemi Orientati ai Servizi**: Sviluppo di sistemi tramite la connessione a servizi esterni condivisi. 6. **Linee di Prodotto Applicative**: Generalizzazione di un\'applicazione attorno a un\'architettura comune, adattabile a vari clienti. 7. **Integrazione COTS**: Uso di sistemi applicativi esistenti già pronti. 8. **Applicazioni Verticali Configurabili**: Sistemi generici configurabili per soddisfare esigenze specifiche. 9. **Librerie di Programmi**: Librerie di classi e funzioni per il riutilizzo di astrazioni comuni. 10. **Generatori di Programmi**: Creazione di sistemi o frammenti basati su regole di applicazione. 11. **Sviluppo Orientato agli Aspetti**: Integrazione di componenti in vari punti durante la compilazione. **Riutilizzo dei Concetti** Il riutilizzo dei concetti implica seguire le decisioni di progettazione fatte dall\'originario sviluppatore del componente. Le principali strategie comprendono: - **Design Patterns**: Utilizzo di modelli di progettazione predefiniti. - **Programmazione Generativa**: Creazione di codice in base a template e regole predefinite. **Modelli di progettazione** \- Un design pattern è un modo per riutilizzare la conoscenza astratta su un problema e sulla sua soluzione. \- Uno schema è una descrizione del problema e dell\'essenza della sua soluzione. \- Dovrebbe essere sufficientemente astratto da poter essere riutilizzato in contesti diversi. \- Spesso i modelli si basano su caratteristiche degli oggetti come l\'ereditarietà e il polimorfismo. **Design Patterns** I **design patterns** sono strumenti per riutilizzare conoscenze astratte riguardanti un problema e la sua soluzione. Ecco una spiegazione dettagliata: - **Definizione**: Un design pattern è una descrizione di un problema comune e dell\'essenza della sua soluzione. È progettato per essere sufficientemente astratto, in modo da poter essere riutilizzato in contesti diversi. - **Caratteristiche**: Spesso si basa su concetti oggettivi come l\'ereditarietà e il polimorfismo, permettendo una maggiore flessibilità nella sua applicazione. **Tipi di Generator di Programmi** I **program generator** consentono di riutilizzare schemi e algoritmi standard, generando automaticamente il codice. Ecco i principali tipi: - **Generatori di Applicazioni**: Per l\'elaborazione dei dati aziendali. - **Generatori di Parser e Analizzatori Lessicali**: Utilizzati nell\'elaborazione del linguaggio. - **Generatori di Codice**: Integrati negli strumenti CASE (Computer-Aided Software Engineering). **Vantaggi del riutilizzo basato su generatori**: - **Costo-efficiente**: Permette di risparmiare tempo e risorse. - **Applicabilità Limitata**: È utile principalmente in un numero ristretto di domini applicativi. - **Facilità d\'uso per gli utenti finali**: Più semplice rispetto agli approcci basati su componenti. **Framework Applicativi** I **framework** sono progettati come sottosistemi composti da una raccolta di classi astratte e concrete, con le interfacce tra di esse. - **Implementazione**: Un sottosistema è implementato aggiungendo componenti per completare parti del design e in stanziando le classi astratte del framework. - **Dimensione**: I framework sono entità di medie dimensioni che possono essere riutilizzate. **Riutilizzo dei Sistemi Applicativi** Il **riutilizzo dei sistemi applicativi** comprende il riutilizzo di interi sistemi, che può avvenire attraverso: - **Configurazione**: Modifica di un sistema per soddisfare esigenze specifiche. - **Integrazione**: Collegamento di due o più sistemi esistenti. Due approcci principali per il riutilizzo dei sistemi applicativi sono: - **Integrazione di Prodotti COTS (Commercial Off-The-Shelf)**: Utilizzo di prodotti già pronti per l\'uso. - **Sviluppo di Linee di Prodotto**: Creazione di famiglie di applicazioni basate su un\'architettura comune. **COTS (Commercial Off-The-Shelf)**: Sistemi pronti all\'uso che offrono un\'API per integrare applicazioni complesse, come sistemi di e-commerce, con il vantaggio di uno sviluppo più rapido e costi inferiori. Tuttavia, presentano problemi di controllo su funzionalità, prestazioni, evoluzione e supporto. **Linee di prodotti software**: Famiglie di applicazioni con funzionalità generiche che possono essere adattate configurando componenti o aggiungendo/modificando parti esistenti. **Sistemi ERP**: Sistemi aziendali generici ampiamente utilizzati nelle grandi aziende per gestire processi comuni, personalizzabili tramite moduli e regole di business. **Sviluppo basato su componenti (CBSE)**: - **Elementi essenziali del CBSE**: - **Componenti indipendenti**: Sono definiti dalle loro interfacce, permettendo loro di funzionare in modo autonomo. - **Standard dei componenti**: Facilitano l\'integrazione tra componenti diversi. - **Middleware**: Fornisce supporto per l\'interoperabilità tra i componenti, aiutando a farli comunicare tra loro. - **Processo di sviluppo orientato al riuso**: L\'intero processo è focalizzato sul riutilizzo dei componenti esistenti per ridurre i tempi e i costi di sviluppo. - **CBSE e principi di progettazione**: - **Componenti indipendenti**: Ogni componente è progettato per essere indipendente, evitando interferenze tra loro. - **Incapsulamento**: Le implementazioni dei componenti sono nascoste, promuovendo il riuso senza la necessità di conoscere i dettagli interni. - **Interfacce ben definite**: La comunicazione tra i componenti avviene solo tramite interfacce chiaramente definite. - **Piattaforme condivise**: L\'uso di piattaforme comuni riduce i costi di sviluppo, poiché è possibile riutilizzare gli stessi componenti in diverse applicazioni. CBSE si basa quindi sul riuso, ma supportato da solide basi ingegneristiche che migliorano l\'efficienza del processo di sviluppo software. - **Componenti**: I componenti forniscono un servizio indipendentemente da dove vengono eseguiti o dal linguaggio di programmazione utilizzato. Un componente è un\'entità eseguibile indipendente, che può essere composto da uno o più oggetti eseguibili. L\'interfaccia del componente è pubblicata e tutte le interazioni avvengono attraverso questa interfaccia. - **Componenti e Oggetti**: - I componenti sono entità che possono essere distribuite (deployable entities). - I componenti non definiscono tipi specifici. - Le implementazioni dei componenti sono opache, ossia non è visibile il loro funzionamento interno. - I componenti sono indipendenti dal linguaggio di programmazione. - I componenti seguono degli standard ben definiti. - **Modelli di componenti**: Un modello di componente è una definizione di standard per l\'implementazione, la documentazione e il rilascio (deploy) dei componenti. Alcuni esempi di modelli di componenti includono: - **EJB** (Enterprise Java Beans): Un modello di componenti usato in Java per lo sviluppo di applicazioni aziendali. - **COM+** (.NET): Un modello di componenti utilizzato nell\'ambiente di sviluppo.NET. - **Corba Component Model**: Un altro modello di componenti utilizzato per l\'interoperabilità tra linguaggi diversi. Il modello di componente specifica come devono essere definite le interfacce e quali elementi devono essere inclusi nella definizione dell\'interfaccia. **Spiegazione**: I componenti sono unità software indipendenti che possono essere eseguite in ambienti diversi senza dipendere dal linguaggio di programmazione. Sono progettati per essere riutilizzati, e interagiscono attraverso interfacce standardizzate, nascondendo i dettagli interni. I modelli di componenti definiscono le regole e gli standard per creare, documentare e distribuire questi componenti, permettendo un\'integrazione efficace in diversi sistemi. - **Il cambiamento del software**: - Il cambiamento del software è inevitabile. Questo può succedere per diversi motivi: - Nuove esigenze emergono quando il software viene utilizzato. - Cambiamenti nell\'ambiente aziendale. - Correzione di errori. - Aggiunta di nuovi computer o attrezzature al sistema. - Miglioramento delle prestazioni o dell\'affidabilità del sistema. Un problema chiave per le organizzazioni è l\'implementazione e la gestione di questi cambiamenti nei loro sistemi software esistenti. - **Modello a spirale dell\'evoluzione**: Questo concetto fa riferimento alla natura ciclica dei cambiamenti nei sistemi software. L\'evoluzione del software non è un processo lineare, ma avviene in cicli in cui vengono affrontati progressivamente nuovi cambiamenti e miglioramenti. - **Dinamiche di evoluzione del programma**: È lo studio dei processi di cambiamento del sistema. Lehman e Belady hanno proposto una serie di \"leggi\" basate su studi empirici importanti. Sebbene queste leggi siano sensate osservazioni generali piuttosto che leggi definitive, sono particolarmente applicabili a sistemi di grandi dimensioni sviluppati da grandi organizzazioni. **Le leggi di Lehman**: 1. **Cambiamento continuo**: Un programma utilizzato in un ambiente reale deve necessariamente cambiare, altrimenti diventerà progressivamente meno utile in quell\'ambiente. 2. **Aumento della complessità**: Man mano che un programma evolve e cambia, la sua struttura tende a diventare più complessa. È necessario investire risorse per preservare e semplificare la struttura. 3. **Evoluzione dei grandi programmi**: L\'evoluzione dei programmi è un processo autoregolante. Attributi come la dimensione del sistema, il tempo tra le versioni e il numero di errori segnalati rimangono approssimativamente invariati per ogni versione del sistema. 4. **Stabilità organizzativa**: Durante la vita di un programma, il tasso di sviluppo rimane approssimativamente costante e indipendente dalle risorse impiegate nello sviluppo del sistema. 5. **Conservazione della familiarità**: Durante la vita di un sistema, il cambiamento incrementale in ogni rilascio rimane approssimativamente costante. 6. **Crescita continua**: La funzionalità offerta dai sistemi deve aumentare continuamente per mantenere la soddisfazione degli utenti. 7. **Declino della qualità**: La qualità dei sistemi sembra declinare a meno che non vengano adattati ai cambiamenti nel loro ambiente operativo. 8. **Sistema di feedback**: I processi di evoluzione del software includono sistemi di feedback multi-agente e multi-loop, e devono essere trattati come tali per ottenere significativi miglioramenti del prodotto. **Manutenzione del software**\ La manutenzione del software consiste nella modifica di un programma dopo che è stato messo in uso, senza però apportare cambiamenti radicali all\'architettura del sistema. I cambiamenti vengono implementati modificando o aggiungendo componenti esistenti. La manutenzione è inevitabile poiché l\'ambiente cambia e le esigenze evolvono. Per mantenere utile un sistema, esso deve essere continuamente aggiornato. **Fattori che influenzano il costo della manutenzione:** - **Stabilità del team**: I costi di manutenzione diminuiscono se lo stesso staff lavora al progetto per un periodo prolungato. - **Responsabilità contrattuale**: Se i sviluppatori originali non sono responsabili della manutenzione, potrebbero non essere incentivati a progettare il software per cambiamenti futuri. - **Competenze del personale**: Spesso chi si occupa di manutenzione è meno esperto e ha conoscenze limitate del dominio. - **Età e struttura del programma**: Con l\'invecchiamento, la struttura dei programmi tende a deteriorarsi, rendendo più difficile la comprensione e la modifica. **Reingegnerizzazione del sistema**\ La reingegnerizzazione di un sistema consiste nel ristrutturare o riscrivere parte o tutto di un sistema legacy senza modificarne le funzionalità. È utile quando solo alcuni sottosistemi di un sistema più ampio necessitano di frequente manutenzione. Questo processo aggiunge sforzi per rendere il sistema più facile da mantenere, ristrutturandolo e fornendo una migliore documentazione. **Vantaggi della reingegnerizzazione:** - **Riduzione del rischio**: Lo sviluppo di nuovo software comporta rischi elevati legati a problemi di sviluppo, personale e specifiche. Reingegnerizzare un sistema esistente riduce questi rischi. - **Riduzione dei costi**: Il costo della reingegnerizzazione è spesso inferiore rispetto allo sviluppo di un nuovo sistema da zero. **Attività del processo di reingegnerizzazione:** 1. **Traduzione del codice sorgente**: Convertire il codice in un nuovo linguaggio di programmazione. 2. **Reverse engineering**: Analizzare il programma per comprenderne la struttura e il funzionamento. 3. **Miglioramento della struttura del programma**: Ristrutturare il programma automaticamente per renderlo più comprensibile. 4. **Modularizzazione del programma**: Riorganizzare la struttura del programma in moduli distinti. 5. **Reingegnerizzazione dei dati**: Pulire e ristrutturare i dati del sistema per migliorarne la gestione. I **sistemi legacy** si riferiscono a software o hardware obsoleto che continua a essere utilizzato all\'interno di un\'organizzazione, nonostante l\'esistenza di tecnologie più moderne e aggiornate **Evoluzione dei sistemi legacy**\ Le organizzazioni che dipendono da sistemi legacy devono scegliere una strategia per evolvere questi sistemi. Le opzioni principali sono: - **Eliminare il sistema** e modificare i processi aziendali in modo che non sia più necessario. - **Continuare la manutenzione del sistema** senza modifiche sostanziali. - **Trasformare il sistema** tramite reingegnerizzazione per migliorare la sua manutenibilità. - **Sostituire il sistema** con uno nuovo. La strategia dipende dalla qualità del sistema e dal suo valore per il business. Le diverse categorie di sistemi legacy sono: 1. **Bassa qualità, basso valore di business**: Questi sistemi dovrebbero essere eliminati poiché non offrono benefici significativi. 2. **Bassa qualità, alto valore di business**: Questi sistemi sono importanti per l\'azienda ma costosi da mantenere. Dovrebbero essere reingegnerizzati o sostituiti, se possibile. 3. **Alta qualità, basso valore di business**: Possono essere sostituiti con prodotti commerciali (COTS), eliminati o mantenuti a seconda delle necessità. 4. **Alta qualità, alto valore di business**: Questi sistemi dovrebbero continuare a essere utilizzati e mantenuti regolarmente.