Il futuro dell'ingegneria del software
Dalla scuola di Software Engineering della FILS alla formazione dell'ingegnere del software nell'epoca delle piattaforme, di DevOps, del cloud e dell'intelligenza artificiale generativa.
Il testo che segue nasce da una preoccupazione personale, maturata in oltre quattro decenni di contatto con l'ingegneria del software nella ricerca, nell'industria e nell'educazione. Non è una profezia e non è nemmeno un programma curricolare ufficiale, ma un saggio-dialogo: un tentativo di formulare le domande che mi preoccupano e di rispondere ad esse dalla prospettiva delle attuali trasformazioni del campo.
Per circa vent'anni ho avuto l'opportunità di contribuire in modo decisivo alla formazione e all'evoluzione di una scuola di Software Engineering alla FILS, sia a livello di laurea sia a livello di master, nel percorso in inglese e in quello in francese. La domanda che rimane è che cosa si possa conservare di questa scuola in un mondo in cui il software si sviluppa attraverso piattaforme, servizi, ecosistemi, automazione e intelligenza artificiale.
Una vecchia preoccupazione in un mondo nuovo
L'ingegneria del software è entrata nella mia vita professionale prima di diventare, in Romania, una disciplina universitaria riconoscibile. L'ho incontrata dapprima attraverso problemi concreti: la portabilità dei programmi, i compilatori, i codici intermedi, i macroprocessori, e poi attraverso domande più generali sulla progettazione, sulle forme intermedie, sulla macchina astratta, sugli ambienti integrati e sul processo software come oggetto di studio. Nell'industria ho incontrato altri vincoli: scadenze, clienti, contratti, manutenzione, compromessi, tecnologie che cambiano e programmi che devono funzionare anche quando la teoria non offre più tutte le risposte.
Mi occupo da oltre quarantacinque anni di ingegneria del software, nella ricerca, nell'industria e nell'educazione. Ho attraversato più paradigmi: programmazione strutturata, metodi formali, CASE, orientamento agli oggetti, Java, UML, componenti, web, Agile, DevOps, cloud e ora IA generativa. Che cosa sta accadendo al campo? Esiste ancora l'ingegneria del software nel senso in cui la intendevamo noi?
L'ingegneria del software esiste, ma non ha più la forma compatta che aveva quando cercava di staccarsi dalla programmazione artigianale. Si è distribuita in diverse pratiche: architettura software, sviluppo agile, DevOps, platform engineering, sicurezza, cloud, data engineering, AI engineering, governance e operatività continua. Forse scompare la sua immagine classica, ma non scompare il bisogno che l'ha creata: il controllo della complessità software.
Questa è la prima chiarificazione. Il software non scompare. Al contrario, il mondo è sempre più costruito sul software. Ciò che cambia è la forma professionale ed educativa attraverso la quale impariamo a costruirlo, verificarlo, mantenerlo e renderlo responsabile.
Che cosa sta accadendo all'ingegneria del software?
Nella storia del campo ho parlato di una possibile crisi o persino di un declino dell'ingegneria del software classica. Non è forse troppo? Può un campo essere in declino proprio quando il software è dappertutto?
Non è il software a essere in declino. In declino è una certa immagine storica dell'ingegneria del software: la disciplina normativa, relativamente stabile, centrata sui cicli di vita, sulla documentazione, sui metodi prescritti, sulla modellazione separata dall'implementazione e sugli strumenti integrati che avrebbero dovuto guidare razionalmente il processo di sviluppo.
Questa immagine è stata erosa da tre ondate successive. Agile ha ridotto il prestigio delle metodologie pesanti e ha spostato l'accento sul feedback e sull'adattamento. DevOps e il cloud hanno assorbito lo sviluppo in un flusso continuo di consegna e operazione. L'intelligenza artificiale generativa sta ora cambiando lo stesso atto di produrre codice, trasformando il programmatore in formulatore di intenzioni, valutatore, integratore e responsabile del risultato.
La nuova crisi dell'ingegneria del software non è più la crisi dei grandi progetti in ritardo, come negli anni Sessanta. È la crisi dell'intelligibilità e della responsabilità in un mondo in cui i sistemi si modificano permanentemente, dipendono da infrastrutture esterne, sono costruiti su librerie, servizi e API fragili, e una parte del codice può essere generata da modelli statistici che producono soluzioni plausibili, ma non sempre giustificate concettualmente.
L'ingegneria del software non deve quindi essere abbandonata, ma ripensata. Non può più essere soltanto la teoria della produzione di un programma, ma deve diventare la teoria e la pratica responsabile di sistemi software evolutivi, distribuiti, assistiti dall'IA e inseriti in processi sociali reali.
Quale destino hanno gli ex studenti?
I miei ex studenti sono ora al culmine della loro carriera. Molti hanno imparato Software Engineering in una forma che metteva l'accento sulla programmazione orientata agli oggetti, Java, progettazione, architetture, metodologie, applicazioni distribuite e sviluppo web. Quale destino hanno in un mondo dominato da cloud, microservizi, DevOps e IA generativa?
Coloro che hanno imparato soltanto tecnologie rischiano di essere superati, perché le tecnologie cambiano rapidamente. Coloro che hanno imparato a pensare in modo ingegneristico sono avvantaggiati. Hanno esattamente i riflessi richiesti dal momento attuale: comprendere architetture, leggere sistemi grandi, valutare compromessi, gestire la complessità, porre domande sulla qualità, sulla sicurezza, sulla manutenibilità e sul costo del cambiamento.
Per gli ex studenti oggi giunti alla maturità professionale, la sfida non è competere con l'IA nella scrittura rapida del codice. La sfida è diventare coloro che sanno usare l'IA senza abdicare alla comprensione: verificare, integrare, rifiutare, rifattorizzare, decidere e conservare la memoria architetturale del sistema.
Da questo punto di vista, ciò che è stato insegnato alla FILS non è annullato dal cambiamento tecnologico. Java è cambiato, i framework sono cambiati, alcune piattaforme sono scomparse, altre sono diventate dominanti. Ma l'idea che il software abbia un'architettura, che la progettazione preceda e superi il codice, che i sistemi debbano essere mantenuti e che le decisioni tecniche abbiano conseguenze a lungo termine rimane più attuale che mai.
Che cosa bisogna insegnare agli studenti di oggi?
Che cosa deve imparare oggi lo studente di Software Engineering? Possiamo continuare a insegnare gli stessi corsi, cambiando soltanto esempi e linguaggi? Oppure bisogna rifare il nucleo della disciplina?
Il nucleo deve essere conservato, ma riorganizzato. Lo studente non deve essere formato né come semplice coder, né come operatore di strumenti IA, né come teorico staccato dalla pratica. Deve essere formato come ingegnere capace di costruire sistemi software reali in un ambiente tecnologico instabile.
Per questo, l'educazione attuale in Software Engineering dovrebbe combinare cinque strati:
- Fondamenti: algoritmi, strutture dati, linguaggi, sistemi operativi, basi di dati, reti, modelli di calcolo, logica e probabilità.
- Costruzione del software: requisiti, progettazione, architettura, testing, verifica, qualità, manutenzione, refactoring, documentazione e gestione della configurazione.
- Sistemi moderni: web, cloud, microservizi, API, container, osservabilità, sicurezza, infrastruttura come codice e consegna continua.
- IA per il software: uso critico degli LLM per codice, test, documentazione, analisi, migrazione, refactoring e rilevamento delle vulnerabilità.
- Responsabilità professionale: etica, sicurezza, protezione dei dati, impatto sociale, sostenibilità, comunicazione e lavoro di squadra.
Una buona scuola di Software Engineering non deve inseguire ogni moda tecnologica. Deve identificare quelle conoscenze che sopravvivono al cambiamento: astrazione, modularità, separazione delle preoccupazioni, architettura, verifica, qualità, evoluzione, sicurezza e responsabilità.
Su che cosa bisogna porre l'accento?
Se il numero di ore è limitato, su che cosa bisogna porre l'accento? Sulla programmazione? Sull'architettura? Sull'IA? Su DevOps? Sulla matematica? Sui progetti?
L'accento deve essere posto sulla competenza di costruire e comprendere sistemi. La programmazione rimane necessaria, ma non è sufficiente. L'architettura è essenziale, ma non può essere insegnata senza progetti concreti. L'IA deve essere introdotta, ma non come sostituto del pensiero. DevOps deve essere insegnato, ma non come semplice insieme di strumenti. La matematica deve essere preservata, ma orientata verso modellazione, analisi, probabilità, complessità e ragionamento.
Se dovessi ridurre tutto ad alcuni assi, direi che lo studente deve imparare:
- a formulare il problema, non soltanto a riceverne l'enunciato;
- a progettare l'architettura, non soltanto a scrivere classi o funzioni;
- a comprendere il sistema esistente, perché la maggior parte del lavoro reale si svolge su sistemi già costruiti;
- a testare e verificare, incluso il codice generato dall'IA;
- a lavorare in gruppo, con strumenti reali di collaborazione, versionamento e consegna;
- a giudicare criticamente i suggerimenti dell'IA, senza diventarne dipendente;
- a documentare le decisioni importanti, non soltanto il risultato finale;
- ad assumere la responsabilità del sistema, anche dopo la consegna.
L'accento non deve essere sul “conoscere un framework”, ma sul sapere che cosa significa costruire un sistema che possa essere modificato, spiegato, testato, protetto e usato da persone reali.
Bisogna cambiare il nome del campo?
Il nome Software Engineering è ancora adatto? Oppure dovrebbe essere cambiato? Forse non costruiamo più solo software, ma piattaforme, ecosistemi digitali, servizi intelligenti, infrastrutture e sistemi socio-tecnici.
Il nome Software Engineering merita di essere conservato, ma deve essere ampliato semanticamente. Ha una storia, un'identità professionale e un corpo di conoscenze. Cambiare il nome potrebbe creare confusione e rompere la continuità con una tradizione importante.
Tuttavia, all'interno del campo bisogna riconoscere che il software di oggi è raramente un programma isolato. È servizio, infrastruttura, piattaforma, prodotto digitale, ecosistema, componente di un processo organizzativo o elemento di una decisione automatica. Forse il nome generale rimane Software Engineering, ma i sottotitoli del futuro saranno: Digital Systems Engineering, AI-assisted Software Engineering, Platform Engineering, Secure Software Engineering e Software Engineering for Socio-Technical Systems.
Manterrei dunque il nome, ma cambierei il modo di spiegarlo. Software Engineering non deve più essere presentato come ingegneria dei programmi, ma come ingegneria dei sistemi digitali costruiti attraverso il software.
Lo sviluppo di programmi sarà ancora necessario?
Sarà ancora necessario lo sviluppo di programmi? Se l'IA può generare codice, se le piattaforme offrono servizi già pronti, se molte applicazioni si costruiscono mediante configurazione e integrazione, che cosa resta della programmazione?
Sì, lo sviluppo di programmi rimarrà necessario, ma il suo peso cambierà. Si scriverà meno codice banale e più codice di integrazione, coordinamento, adattamento, verifica e controllo. Una parte del codice sarà generata, ma qualcuno deve dire che cosa deve essere generato, comprendere il risultato, testarlo, integrarlo e rispondere del comportamento del sistema.
Inoltre, quanto più il software è critico, tanto meno possiamo accettare l'idea di codice prodotto senza comprensione. Nei sistemi medici, finanziari, industriali, militari, giuridici, educativi o di infrastruttura pubblica, il problema non è generare rapidamente codice, ma avere garanzie, tracciabilità, audit, sicurezza e spiegazioni.
La programmazione non scompare. Scompare gradualmente la programmazione come mestiere isolato dal resto del processo. Rimane la programmazione integrata nella progettazione, nell'architettura, nel testing, nella sicurezza, nell'esercizio e nella governance.
Le frontiere del codice generato dall'IA
Un incontro recente con un giovane americano, laureato in un master di Software Engineering, mi ha offerto un esempio concreto che non avevo preso sufficientemente in considerazione. Gli avevo chiesto, quasi provocatoriamente, se lo sviluppo del software abbia ancora un futuro nelle condizioni in cui l'intelligenza artificiale può generare programmi con efficacia crescente. La sua risposta è stata semplice e, proprio per questo, importante: esistono domini in cui il codice prodotto automaticamente dall'IA non può essere accettato così com'è. Mi ha dato l'esempio del software di pianificazione dei robot sulla Luna.
Non avevo pensato abbastanza a simili applicazioni. Se un programma pianifica le azioni di un robot lunare, non si tratta soltanto di un'applicazione che può essere corretta dopo il rilascio. Un errore può compromettere una missione, distruggere attrezzature irreparabili e rendere inutili anni di lavoro. Probabilmente esistono molti altri domini in cui il codice generato dall'IA non può essere usato direttamente.
L'esempio è molto buono, perché mostra il limite reale dell'entusiasmo per la generazione automatica del codice. Il problema non è se l'IA possa produrre una sequenza di istruzioni che sembra corretta. Il problema è se quel codice possa essere certificato, spiegato, tracciato fino ai requisiti, testato in condizioni estreme, integrato in un'architettura verificata e assunto da un'organizzazione responsabile.
Nei domini critici, il codice generato dall'IA può essere utile come supporto: per esplorare una soluzione, generare test, effettuare verifiche supplementari, produrre documentazione o scoprire casi marginali. Ma non può essere accettato come prodotto finale senza un processo rigoroso di ingegneria, verifica, validazione e certificazione.
Questa è forse la distinzione centrale: nelle applicazioni ordinarie, l'errore può essere corretto tramite un aggiornamento; nelle applicazioni critiche, l'errore può produrre perdite irreversibili. Perciò la frontiera non passa tra “codice scritto dall'uomo” e “codice generato dall'IA”, ma tra codice accettato per plausibilità e codice accettato per tracciabilità, verifica, responsabilità e certificazione.
Oggi questa frontiera è visibile in diversi domini:
- software spaziale e robotica extraterrestre, dove le correzioni sono difficili, costose o impossibili;
- avionica e controllo del volo, dove ogni funzione software deve essere collegata a requisiti, livelli di criticità e prove di verifica;
- automobili autonome e sistemi avanzati di assistenza, dove percezione, decisione e controllo possono influire direttamente sulla vita delle persone;
- trasporto ferroviario e sistemi di segnalamento, dove il software deve prevenire collisioni, comandi conflittuali e stati non sicuri;
- dispositivi medici e sistemi clinici, dove una raccomandazione o un comando errato può influire sulla diagnosi, sul trattamento o sull'intervento sul paziente;
- energia, industria e infrastrutture critiche, dove il controllo dei processi fisici non consente sperimentazioni irresponsabili;
- sicurezza, crittografia e infrastruttura finanziaria, dove un piccolo errore può diventare vulnerabilità sistemica;
- sistemi militari o di intervento, dove il software entra in catene decisionali con conseguenze irreversibili.
È possibile che, man mano che l'IA diventa più potente, l'area del codice che può essere generato automaticamente e accettato con rischi ridotti aumenti. Ma questa evoluzione non elimina l'ingegneria del software. Al contrario, sposta l'accento dalla semplice scrittura del codice verso specificazione, analisi del rischio, verifica formale o semi-formale, generazione di test, tracciabilità, audit, certificazione e governance. La nicchia delle applicazioni in cui il codice generato non può essere accettato direttamente può restringersi, ma non scomparirà finché il software comanda processi fisici, medici, finanziari, giuridici o militari con effetti irreversibili.
Da qui deriva anche una conseguenza educativa. Lo studente di Software Engineering non deve essere formato soltanto come utente competente dell'IA generativa, ma come professionista capace di distinguere tra un codice conveniente e un codice accettabile. In molte applicazioni, la domanda non sarà “può l'IA scrivere il programma?”, ma “possiamo dimostrare che il programma, qualunque sia il modo in cui è stato prodotto, è sicuro, corretto, tracciabile e responsabile?”.
Per quali tipi di progetti serviranno ingegneri del software?
Per quali tipi di progetti serviranno ingegneri del software ben preparati? Non saranno sufficienti le piattaforme no-code, low-code, i servizi cloud e l'IA?
Gli strumenti no-code, low-code e IA possono coprire applicazioni semplici, prototipi, automazioni locali e interfacce standardizzate. Ma quanto più un progetto diventa grande, critico, integrato o durevole, tanto più ritorna il bisogno di una vera ingegneria del software.
Saranno necessari ingegneri del software soprattutto per:
- sistemi critici: sanità, trasporti, energia, difesa, amministrazione, finanza;
- piattaforme digitali: ecosistemi con molti utenti, servizi, API e regole di governance;
- sistemi legacy: modernizzazione, migrazione, refactoring e integrazione con nuove tecnologie;
- prodotti software complessi: applicazioni che evolvono per anni e devono essere mantenute da team successivi;
- sistemi AI-intensive: applicazioni in cui i modelli IA devono essere integrati, monitorati, spiegati e controllati;
- cybersecurity e safety: sistemi in cui errore, vulnerabilità o attacco hanno conseguenze importanti;
- infrastrutture cloud ed edge: sistemi distribuiti, osservabili, scalabili e resilienti;
- digital twins ed ecosistemi digitali: rappresentazioni attive di processi reali, nella sanità, nell'industria, nelle città e nell'amministrazione.
Proprio in questi progetti si vede la differenza tra produrre codice e fare ingegneria.
Bisogna ridurre il numero degli studenti?
Se l'IA assumerà una parte dell'attività di programmazione, bisogna ridurre il numero degli studenti nella specializzazione di Software Engineering?
Non credo che la risposta corretta sia una riduzione meccanica del numero degli studenti. Più importante è il cambiamento del profilo formativo. Se la specializzazione produce soltanto programmatori di routine, avrà un problema. Se produce ingegneri capaci di progettare, integrare, verificare, lavorare con l'IA e rispondere di sistemi complessi, la domanda non scomparirà.
Tuttavia può essere necessaria una selezione più attenta e una differenziazione più chiara dei percorsi. Non tutti gli studenti devono diventare architetti software o ricercatori. Alcuni saranno sviluppatori di applicazioni, altri ingegneri DevOps, specialisti di sicurezza, data engineer, AI engineer, product engineer o integratori di piattaforme. Ma tutti dovrebbero ricevere un nucleo comune di pensiero ingegneristico.
Il rischio non è che vi siano troppi studenti in Software Engineering. Il rischio è che siano preparati per un mestiere che sta cambiando sotto i nostri occhi. La prima domanda non deve essere il numero, ma la rilevanza della formazione.
La scuola di Software Engineering della FILS
Per vent'anni ho avuto l'opportunità di decidere sulla creazione e sull'evoluzione di una scuola di ingegneria del software alla FILS, nei percorsi in inglese e in francese. Per la laurea ho costruito un nucleo di corsi innovativo, unico nel paese, e ho introdotto un master in ingegneria del software destinato ad assicurare agli studenti una preparazione solida nel campo. Che cosa ne sarà di questa scuola?
Una scuola universitaria non sopravvive conservando immutati i corsi. Sopravvive attraverso le persone, i riflessi intellettuali, gli standard professionali e un modo di porre le domande. Se la scuola della FILS ha trasmesso l'idea che il software deve essere progettato, compreso, verificato, mantenuto e assunto, allora ha possibilità di continuare anche quando le tecnologie cambiano.
Ma per continuare deve aggiornarsi. Non basta aggiungere un corso sull'IA o un laboratorio sul cloud. Bisogna ripensare il rapporto tra fondamenti e strumenti. L'IA deve essere introdotta in tutti i corsi, ma con regole chiare: lo studente può usare l'IA, ma deve dimostrare di capire il problema, la soluzione, i test, i limiti e le conseguenze.
L'eredità più importante della scuola FILS non è un certo linguaggio, né un certo framework, né un certo strumento. È la convinzione che il software non si improvvisa. Si progetta, si costruisce, si verifica, si esercisce, si cambia e si trasmette ad altri.
Se questa convinzione rimane viva, la scuola non scompare. Si trasforma.
Un possibile nucleo curricolare
Nella forma attuale, un curriculum di Software Engineering dovrebbe conservare l'equilibrio tra ciò che è stabile e ciò che cambia. Non si può costruire un programma di studi solo su tecnologie effimere, ma non si può nemmeno ignorare l'ambiente reale in cui il laureato lavorerà.
| Livello | Che cosa bisogna conservare | Che cosa bisogna aggiungere o rafforzare | Risultato desiderato |
|---|---|---|---|
| Laurea – fondamenti | Programmazione, algoritmi, strutture dati, basi di dati, sistemi operativi, reti, OOP. | Pensiero critico sul codice generato, testing sistematico, versionamento, lavoro di squadra. | Studente capace di scrivere, leggere e spiegare programmi, non solo di produrli. |
| Laurea – costruzione software | Requisiti, progettazione, architettura, UML o notazioni equivalenti, design patterns, qualità. | Architetture cloud-native, API, microservizi, security by design, osservabilità. | Studente capace di pensare il sistema, non solo le sue componenti. |
| Master – sistemi moderni | Processi software, project management, modelli di maturità, metodi agili, DevOps. | Platform engineering, SRE, DevSecOps, governance, costi cloud, sostenibilità. | Laureato capace di lavorare in organizzazioni software reali e di comprendere il flusso completo. |
| Master – IA e software | Fondamenti di IA, machine learning, sistemi intelligenti, dati e modelli. | AI-assisted software engineering, prompt engineering tecnico, valutazione del codice generato, sicurezza dell'IA. | Ingegnere capace di usare l'IA come strumento, non come autorità. |
| Progetti integratori | Progetti di squadra, documentazione, presentazione, valutazione tecnica. | Progetti con cliente reale, sistemi legacy, integrazione API, dati reali, responsabilità riguardo all'IA. | Laureato che ha incontrato la complessità prima di entrare nell'industria. |
Il nucleo curricolare non deve essere una lista di mode tecnologiche, ma un'architettura educativa: fondamenti solidi, progettazione sistematica, tecnologia attuale, IA integrata criticamente e progetti reali.
Che cosa rimane?
Se dovessi formulare una conclusione personale, che cosa rimane dell'ingegneria del software dopo tutte queste trasformazioni?
Rimane esattamente ciò che ha motivato la nascita del campo: la lotta contro il caos software. Solo che oggi il caos ha un'altra forma. Non è più soltanto il caos del codice spaghetti o dei progetti in ritardo. È il caos delle piattaforme interdipendenti, dei servizi distribuiti, delle dipendenze esterne, del codice generato, delle vulnerabilità, dei requisiti instabili e dei sistemi che continuano a cambiare dopo essere stati consegnati.
In questo mondo, l'ingegneria del software non è meno necessaria, ma più difficile da insegnare e più difficile da riconoscere. Non può più essere presentata come un insieme di ricette. Deve essere insegnata come una cultura professionale della costruzione responsabile.
Forse questa è la risposta più semplice. Il futuro dell'ingegneria del software non dipende dalla conservazione di una terminologia o di un insieme fisso di corsi, ma dalla sopravvivenza di un atteggiamento: non confondere la produzione rapida di codice con la costruzione di un sistema; non confondere il suggerimento dell'IA con la soluzione validata; non confondere la piattaforma con l'architettura; non confondere la velocità con il progresso.
Se questo atteggiamento rimane, allora la scuola di Software Engineering che ho cercato di costruire non finisce con una generazione di corsi o con il ritiro di un professore. Continua in coloro che, giunti alla maturità professionale, sanno ancora chiedere non solo “come facciamo a farlo funzionare?”, ma anche “perché funziona, quanto durerà, chi ne risponde e che cosa succede quando dovrà essere cambiato?”.
Riferimenti bibliografici orientativi
- ACM / IEEE Computer Society, Software Engineering 2014: Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering.
- ACM / IEEE / AAAI, Computer Science Curricula 2023.
- IEEE Computer Society, Guide to the Software Engineering Body of Knowledge, SWEBOK, versione 4.0.
- DORA, Accelerate State of DevOps Report, edizioni recenti su DevOps, platform engineering e impatto dell'IA.
- GitHub / Microsoft Research, studi sull'impatto di GitHub Copilot sulla produttività degli sviluppatori.
- NASA, Software Engineering Requirements, per lo sviluppo e l'assicurazione del software critico nelle missioni spaziali.
- RTCA, DO-178C: Software Considerations in Airborne Systems and Equipment Certification, per il software avionico.
- ISO 26262, Road vehicles — Functional safety, per sistemi elettrici/elettronici e software automobilistico con impatto sulla sicurezza.
- IEC 61508, Functional safety of electrical/electronic/programmable electronic safety-related systems, come standard di base per la sicurezza funzionale.
- FDA, materiali recenti sul software medico e sulle funzioni software basate sull'IA nei dispositivi medici.
- Lavori recenti sull'integrazione dell'IA generativa nell'educazione di Software Engineering e nei progetti capstone.
Torna all'ingegneria del software • Torna alla storia dell'ingegneria del software • Torna alla Ricerca