Storia dell'ingegneria del software

Filo personale: dalla portabilità all'interforma e agli ambienti integrati

Nel mio percorso, l'ingresso nell'ingegneria del software è avvenuto prima di tutto attraverso il problema della portabilità: linguaggi portabili, codici intermedi, macroprocessori e strumenti capaci di ridurre la dipendenza da una piattaforma hardware o da un sistema operativo. BCPL, INTCODE, STAGE-2 e JANUS hanno rappresentato per me una prima forma concreta della domanda: come può un programma essere separato dalla macchina su cui viene eseguito?

Negli anni Ottanta, la domanda si è spostata dalla portabilità del programma alla modellazione del processo di progettazione. Da qui sono nati i concetti di macchina astratta, forma intermedia o interforma, nonché l'idea di un ambiente CAD/CAM per lo sviluppo dei programmi. Il sistema INTERFORM è stato il tentativo di materializzare questa visione in un ambiente di sviluppo assistito, nel quale il prodotto software non era più soltanto codice, ma una successione di rappresentazioni, decisioni e trasformazioni controllate.

Il libro Integrating Tools for Software Development, pubblicato da Prentice Hall nel 1992, ha sintetizzato questa direzione: il processo software era visto come un universo composto da oggetti, attività, agenti e strumenti, mentre l'ambiente integrato diventava lo spazio in cui lo sviluppo e l'evoluzione dei programmi potevano essere sostenuti, organizzati e parzialmente automatizzati.

1940–1968 – La preistoria dell'ingegneria del software

La programmazione come mestiere difficile

Nei primi decenni dei calcolatori elettronici, la programmazione era più vicina all'artigianato che all'ingegneria. Il programmatore era spesso allo stesso tempo progettista, codificatore e operatore, mentre il costo dominante dei sistemi di calcolo era ancora l'hardware. Tuttavia, la complessità crebbe rapidamente: apparvero linguaggi assembler, compilatori, librerie di sottoprogrammi, sistemi operativi, time-sharing e applicazioni tecniche o militari che non potevano più essere controllate attraverso l'improvvisazione individuale.

anni Quaranta – La programmazione si svolge a un livello molto vicino alla macchina, attraverso codici numerici, cablaggio o linguaggio assembler embrionale.
anni Cinquanta – Appaiono i primi compilatori, i linguaggi di alto livello e le librerie di programmi; il programma comincia a diventare un artefatto separato dalla macchina.
1957 – FORTRAN mostra che la programmazione scientifica può essere portata a un livello di astrazione accettabile per gli ingegneri.
1958–1960 – ALGOL introduce un modello più rigoroso dei linguaggi di programmazione e influenza la cultura formale della programmazione.
anni Sessanta – Sistemi operativi, compilatori e applicazioni in tempo reale diventano programmi grandi, difficili da testare, documentare e mantenere.
1968 – La lettera di Edsger Dijkstra sull'istruzione goto esprime la necessità di una programmazione più facile da comprendere, verificare e mantenere.

1968–1975 – La nascita del campo: la crisi del software

Le conferenze NATO e la denominazione del problema

La Conferenza NATO di Garmisch, nell'ottobre 1968, ebbe il merito di riunire ricercatori, produttori, utenti e universitari per discutere un problema diventato critico: la difficoltà di produrre software affidabile, manutenibile, consegnato nei tempi previsti e a costi prevedibili. Non fu inventata allora la buona pratica della programmazione, ma venne nominata una nuova disciplina, con aspirazioni ingegneristiche.

1968 – La Conferenza NATO di Garmisch consacra l'espressione software engineering.
1969 – La seconda conferenza NATO, a Roma, continua la discussione su tecniche, metodi e organizzazione della produzione software.
1970 – Winston Royce pubblica l'articolo sullo sviluppo dei grandi sistemi software; il modello sequenziale sarà in seguito associato, talvolta in modo semplificato, al modello “waterfall”.
inizio anni Settanta – Si sviluppano la programmazione strutturata, la verifica dei programmi, la specificazione rigorosa e i primi approcci sistematici al ciclo di vita.
1972 – David Parnas formula criteri per la decomposizione dei sistemi in moduli, mettendo l'accento sull'occultamento delle decisioni di progettazione.
1975 – Fred Brooks pubblica The Mythical Man-Month, criticando le illusioni manageriali dei grandi progetti software.

È in questo periodo che prende forma l'opposizione fondamentale che rimarrà presente in tutta la storia del campo: il software deve essere prodotto con disciplina ingegneristica, ma la sua materia è immateriale, modificabile, dipendente dalle persone, dai linguaggi, dai contesti e da requisiti che cambiano.

1975–1985 – Strutturazione, modularizzazione, metodi formali

Il programma come oggetto di progettazione

Dopo il momento NATO, l'attenzione si sposta verso i mezzi concreti per disciplinare la programmazione: programmazione strutturata, progettazione modulare, specifiche formali, test, documentazione e controllo della configurazione. Il programma non è più visto solo come testo eseguibile, ma come risultato di un processo di progettazione.

la programmazione strutturata riduce l'arbitrarietà del flusso di controllo e persegue l'intelligibilità del programma.
la modularizzazione introduce criteri architetturali per la suddivisione del sistema, non soltanto divisioni basate sul flusso di esecuzione.
le specifiche formali cercano descrizioni precise del comportamento prima del codice.
test e verifica si costituiscono come attività autonome del ciclo di vita.
la gestione dei progetti software cerca di stimare costi, tempi, rischi e produttività.

In questo periodo l'ingegneria del software è ancora fortemente legata ai linguaggi, ai compilatori e ai metodi di programmazione. Tuttavia appare già l'idea centrale: la vera difficoltà non è soltanto scrivere codice, ma controllare le trasformazioni attraverso le quali un requisito diventa un sistema funzionante.

1985–1995 – Ambienti integrati, CASE, processo software

Dal metodo all'ambiente

Negli anni Ottanta e all'inizio degli anni Novanta si afferma l'idea che i metodi non bastano senza strumenti. Appaiono ambienti di sviluppo integrati, strumenti CASE, sistemi di gestione della configurazione, generatori, editor specializzati e tentativi di automazione parziale del ciclo di vita. Parallelamente, l'ingegneria del software sviluppa una propria riflessione sul processo software.

1981 – COCOMO, proposto da Barry Boehm, offre un modello influente per la stima del costo del software.
1981–1987 – Le mie ricerche sulla macchina astratta, l'interforma e i metodi di progettazione software propongono un modello della trasformazione progressiva delle descrizioni del programma.
1985 – Il mio articolo su un sistema CAD/CAM intelligente per lo sviluppo del software sposta l'accento dal modello all'officina software assistita.
1987 – INTERFORM viene presentato come sistema CAD per lo sviluppo dei programmi, con un'architettura stratificata e funzioni di assistenza alla progettazione.
1988 – Il modello a spirale di Boehm pone il rischio e la prototipazione al centro del processo di sviluppo.
fine anni Ottanta – CASE promette l'integrazione di analisi, progettazione, documentazione e generazione di codice, ma spesso rimane al di sotto delle aspettative industriali.
1992 – Integrating Tools for Software Development propone una visione degli ambienti integrati basata su oggetti, attività, agenti e strumenti.

Vista retrospettivamente, questa fase fu forse il momento in cui l'ingegneria del software sognò di più un equivalente dell'officina industriale: uno spazio tecnologico coerente in cui lo sviluppo dei programmi fosse sostenuto da modelli, rappresentazioni intermedie, strumenti cooperanti e una memoria delle decisioni di progettazione.

1990–2000 – Oggetti, componenti, UML, modelli di maturità

Architettura, riuso e standardizzazione

Gli anni Novanta furono segnati dal trionfo dell'orientamento agli oggetti e dalla ricerca di linguaggi comuni di modellazione. C++, Smalltalk, Java, i metodi Booch, OMT e OOSE, poi UML, offrirono un vocabolario comune per classi, oggetti, collaborazioni e architetture. Allo stesso tempo, i modelli di maturità tentarono di trasformare le organizzazioni software in organizzazioni capaci di conoscere e migliorare i propri processi.

1991–1993 – CMM, sviluppato al Software Engineering Institute, introduce l'idea di maturità organizzativa dei processi software.
1994 – Design Patterns fissa un linguaggio di soluzioni ricorrenti nella progettazione orientata agli oggetti.
1995 – Java contribuisce alla diffusione della programmazione orientata agli oggetti e delle applicazioni portabili su infrastrutture distribuite.
1997 – UML diventa standard OMG e cerca di unificare le notazioni e i metodi orientati agli oggetti.
fine anni Novanta – Componenti, middleware e architetture distribuite cambiano la scala dei sistemi software.

Questa fase consolidò il linguaggio architetturale dell'ingegneria del software, ma produsse anche una reazione: i metodi pesanti, la documentazione eccessiva e la modellazione formalizzata in modo troppo rigido furono percepiti da molti team come un freno di fronte al rapido cambiamento dei requisiti.

2001–2010 – Agile, open source, software come servizio

La reazione contro le metodologie pesanti

Il Manifesto Agile del 2001 esprime un cambiamento di accento: individui e interazioni, software funzionante, collaborazione con il cliente e risposta al cambiamento. L'ingegneria del software non scompare, ma cambia il rapporto tra pianificazione e adattamento. Al posto della grande progettazione iniziale si impongono iterazioni brevi, integrazione continua, test automatici, refactoring e feedback rapido.

2001 – Il Manifesto Agile legittima metodi come Scrum, XP e lo sviluppo iterativo centrato sul feedback.
anni 2000 – L'open source diventa una forza importante nella produzione software e cambia il rapporto tra comunità, industria e proprietà intellettuale.
2005–2010 – Il software come servizio, le applicazioni web e le infrastrutture cloud modificano l'idea di consegna: il prodotto software diventa un servizio aggiornato permanentemente.
fine del decennio – L'integrazione continua e le pratiche automatiche di build/test preparano il passaggio a DevOps.

Agile non fu soltanto un metodo, ma anche una critica culturale dell'ingegneria del software burocratizzata. Tuttavia la vittoria di Agile ebbe anche un effetto collaterale: una parte della riflessione ingegneristica sull'architettura, la documentazione e la modellazione venne marginalizzata a favore della velocità e dell'adattamento immediato.

2010–2020 – DevOps, cloud, piattaforme e software continuo

Il software non finisce più

Negli anni 2010, il centro di gravità si sposta dalla costruzione di un prodotto consegnato periodicamente all'operatività continua di un servizio. DevOps, cloud computing, microservizi, container, Kubernetes, infrastruttura come codice e osservabilità cambiano radicalmente l'ingegneria del software. La linea tra sviluppo, test, consegna e operazioni diventa sfumata.

2010 – Continuous Delivery formula le pratiche per consegne rapide, sicure e ripetibili.
2013–2014 – Docker e Kubernetes accelerano la standardizzazione della containerizzazione e dell'orchestrazione delle applicazioni.
anni 2010 – Microservizi e API trasformano il sistema software in una rete di servizi autonomi.
2016 – Le pratiche di Site Reliability Engineering portano la disciplina delle operazioni su larga scala al centro dell'ingegneria del software.
fine del decennio – DevSecOps e la sicurezza della catena di fornitura software diventano temi critici.

In questa fase, l'ingegneria del software diventa sempre meno una disciplina della progettazione di un artefatto e sempre più una disciplina degli ecosistemi: piattaforme, servizi, flussi di consegna, monitoraggio, operazioni e organizzazioni capaci di apprendere continuamente.

2020–presente – IA generativa e trasformazione della professione

Da strumento a collaboratore incerto

I grandi modelli linguistici e gli strumenti di tipo Copilot hanno introdotto una nuova rottura: per la prima volta, la generazione di codice, la spiegazione dei programmi, la scrittura dei test e perfino il refactoring possono essere delegati parzialmente a un sistema conversazionale. Ciò non elimina l'ingegneria del software, ma ne sposta il centro: dalla scrittura diretta del codice alla formulazione dell'intenzione, alla verifica del risultato, all'integrazione, alla governance e al controllo della qualità.

2021 – GitHub Copilot rende popolare l'idea di “AI pair programmer”.
2022–2024 – I modelli conversazionali diventano strumenti quotidiani per generare, spiegare e trasformare codice.
2024–2026 – Appaiono agenti software capaci di proporre modifiche più ampie, creare pull request e partecipare ai flussi di sviluppo.
presente – Crescono l'importanza della verifica umana, dei test automatici, della sicurezza e della capacità di comprendere codice che l'ingegnere non ha scritto direttamente.

Il paradosso del momento è che l'IA sembra ridurre il tempo necessario per scrivere codice, ma aumenta l'importanza delle attività di controllo: validazione, audit, integrazione, test, sicurezza, osservabilità e responsabilità. L'ingegnere del software diventa meno uno scriba del codice e più un supervisore di un processo tecnico-organizzativo in cui il codice può essere prodotto da persone, strumenti o agenti.

L'ingegneria del software è in declino?

Declino della forma classica, non scomparsa della disciplina

Si può parlare di declino solo se per “ingegneria del software” intendiamo la disciplina classica, autonoma, centrata su metodi, cicli di vita, documentazione, progettazione formalizzata e ambienti integrati. Il software non è in declino; al contrario, è diventato l'infrastruttura invisibile della società. In declino è piuttosto la vecchia immagine dell'ingegneria del software come campo separato, con confini chiari, metodi stabili e un processo ideale dalla specifica all'implementazione.

Tre forze hanno contribuito a questa diluizione. La prima è Agile, che ha spesso sostituito il metodo esplicito con l'adattamento continuo. La seconda è DevOps, che ha assorbito lo sviluppo nel flusso permanente delle operazioni. La terza è l'IA generativa, che trasforma il codice da prodotto di un'attività esclusivamente umana in un risultato negoziato tra intenzione, modello, contesto e verifica. Da questo punto di vista, l'ingegneria del software non muore, ma perde la sua forma classica e si redistribuisce in platform engineering, architettura, sicurezza, data engineering, AI engineering e governance.

Se la prima crisi del software fu la crisi della produzione di grandi programmi, la crisi attuale è la crisi del controllo su sistemi software che si modificano continuamente, dipendono da ecosistemi esterni e possono essere generati in parte da modelli statistici. La domanda non è più solo “come scriviamo programmi corretti?”, ma “come conserviamo intelligibilità, responsabilità e controllo in un mondo in cui il software è continuo, distribuito e assistito dall'IA?”.

Sintesi per tappe

Periodo	Caratterizzazione	Punti di riferimento
1940–1968	Preistoria del campo	Compilatori, FORTRAN, ALGOL, sistemi operativi, time-sharing, programmazione strutturata incipiente.
1968–1975	Nascita dell'ingegneria del software	Conferenze NATO, crisi del software, Royce, Dijkstra, Parnas, Brooks.
1975–1985	Disciplinamento della programmazione	Strutturazione, modularizzazione, specifiche formali, verifica, test, stima.
1985–1995	Metodi, ambienti integrati, processo software	CASE, modello a spirale, COCOMO, INTERFORM, ambienti integrati, libro Prentice Hall.
1990–2000	Oggetti e standardizzazione	OOA/OOD, design patterns, UML, componenti, middleware, CMM.
2001–2010	Agile e web	Manifesto Agile, XP, Scrum, open source, integrazione continua, SaaS.
2010–2020	DevOps e cloud	Continuous Delivery, microservizi, container, Kubernetes, SRE, DevSecOps.
2020–presente	IA generativa e ingegneria supervisionata	Copilot, grandi modelli linguistici, agenti software, verifica, sicurezza, governance.

Collegamenti interni

Ingegneria del software
La pagina di sintesi delle mie ricerche nel campo.
Portabilità dei programmi (1974–1979)
La prima direzione attraverso la quale sono entrato nella problematica del software come artefatto trasferibile.
Ordine nel caos. Ingegneria del software e architetture sulla sabbia (1980–1989)
Il decennio della macchina astratta, dell'interforma e del progetto INTERFORM.
Il modello della progettazione software
La macchina astratta e il raffinamento progressivo come modello della progettazione.
Il concetto di interforma
Forme intermedie, faccette e livelli di rappresentazione del prodotto software.
Il progetto INTERFORM
Un ambiente CAD per lo sviluppo dei programmi.
Integrating Tools for Software Development
La sintesi pubblicata da Prentice Hall nel 1992.
Cronologia dell'intelligenza artificiale, 1943–2025
La pagina parallela sull'evoluzione dell'IA, utile soprattutto per la sezione finale sull'IA generativa.

Riferimenti bibliografici orientativi

Peter Naur, Brian Randell (eds.), Software Engineering: Report on a Conference sponsored by the NATO Science Committee, Garmisch, 1968, pubblicato nel 1969.
J. N. Buxton, Brian Randell (eds.), Software Engineering Techniques, rapporto della conferenza NATO di Roma, 1969.
Edsger W. Dijkstra, “Go To Statement Considered Harmful”, Communications of the ACM, 1968.
Winston W. Royce, “Managing the Development of Large Software Systems”, 1970.
David L. Parnas, “On the Criteria To Be Used in Decomposing Systems into Modules”, 1972.
Frederick P. Brooks Jr., The Mythical Man-Month, 1975.
Barry W. Boehm, Software Engineering Economics, 1981; “A Spiral Model of Software Development and Enhancement”, 1988.
Luca Dan Șerbănați, articoli sulla macchina astratta, l'interforma, CAD/CAM e INTERFORM, 1981–1989.
Luca Dan Șerbănați, Integrating Tools for Software Development, Prentice Hall, 1992.
IEEE Computer Society, Guide to the Software Engineering Body of Knowledge (SWEBOK), versioni successive, inclusa la v4.0.
Manifesto for Agile Software Development, 2001.
Rapporti DORA su DevOps e sviluppo software assistito da IA, 2024–2025.

Luca Dan Șerbănați

Professore emerito alla Politehnica di Bucarest

Ricerca, insegnamento, industria e memorie