Introduzione alla progettazione del software

Riassunto

Il corso introduce la progettazione e lo sviluppo del software industriale, passando dai programmi piccoli e autonomi a prodotti complessi realizzati con metodi e tecnologie che innalzano il livello di astrazione. Gli agenti di IA possono aumentare la produttività, ma servono competenze di progettazione e programmazione per guidarli e valutare il codice prodotto. Nello sviluppo industriale collaborano committente, esperto di dominio, analista, progettista, programmatore e utente finale, con responsabilità che oggi spesso si sovrappongono. Dopo la distribuzione, il software richiede soprattutto manutenzione ed evoluzione.

Concetti chiave

• Software industriale — Prodotto software reale, progettato e costruito per l'uso in un contesto produttivo e per soddisfare requisiti e prestazioni stabiliti.
• Toy software — Programma di piccole dimensioni, tipico degli esercizi iniziali, destinato a un uso personale o autonomo e non rappresentativo di un'applicazione industriale.
• Model Driven Engineering — Approccio di progettazione basato su modelli, usati come input per la generazione del software.
• UML (Unified Modeling Language) — Linguaggio standard utilizzato per rappresentare modelli concettuali del sistema.
• Design by contract — Tecnica di progettazione per contratto che esplicita le interfacce e gli accordi tra le parti.
• Committente — Soggetto che finanzia il sistema e definisce gli obiettivi e i requisiti di alto livello.
• Esperto di dominio — Persona che conosce il settore applicativo e fornisce le conoscenze necessarie a specificare il comportamento richiesto al software.
• Analista — Tecnico che comprende il problema e lo rappresenta formalmente attraverso modelli concettuali.
• Progettista — Figura che, una volta rappresentato il problema, individua e progetta una soluzione.
• Programmatore — Figura che traduce il progetto in codice, ruolo storicamente distinto da analisi e progettazione.
• Utente finale — Persona che usa il software; può essere diversa dal committente e dall'esperto di dominio.
• Manutenzione del software — Attività svolta dopo la distribuzione per mantenere il sistema e farlo evolvere.

Sviluppo

Dal software didattico al software industriale

Nei corsi introduttivi si scrivono programmi piccoli in Python e C, utili per imparare la programmazione di base ma diversi da un prodotto industriale. Questi programmi didattici, definiti toy software, sono esercizi destinati a un uso personale e stand-alone.

Il passaggio a questo corso consiste nell'affrontare la progettazione di sistemi più grandi, usando metodi e tecnologie, tra cui quelle orientate agli oggetti, che innalzano il livello di astrazione. Il software industriale è progettato e costruito per l'uso in un contesto produttivo reale e deve soddisfare requisiti e prestazioni stabiliti.

La progettazione nell'era dell'IA

Un'obiezione comune sostiene che gli agenti di IA e i modelli linguistici avanzati renderebbero superfluo imparare a programmare. Tuttavia la domanda di sviluppatori e progettisti supera il numero di persone formate dalle università. Gli agenti possono potenziare il lavoro, aumentando la produttività, ma non sostituiscono le competenze essenziali.

Affinché questa collaborazione con gli agenti funzioni, bisogna saper progettare il sistema che si dà in input alla generazione. Il Model Driven Engineering è un approccio in cui modelli progettati con metodo possono guidare la generazione del software e contribuire a ottenere prodotti di qualità migliore. Senza competenze di progettazione, il software generato può contenere errori e richiedere molto tempo per essere corretto.

Anche la programmazione diretta resta necessaria: quando un agente genera molto codice, occorre saper capire come funziona per valutarlo e correggerlo. Come chi lavora nel mondo delle automobili, non tutti svolgono lo stesso compito: l'utente medio guida un'utilitaria senza saperla riparare, mentre chi progetta o prepara un'auto da corsa conosce motore e gomme. La pratica diretta consente di capire e migliorare il sistema.

Committente e contesto applicativo

Il committente è chi finanzia il sistema e decide di investire in tecnologia per automatizzare operazioni, procedure o processi. Può essere un'impresa, un cittadino o una pubblica amministrazione. Fornisce requisiti di alto livello: per esempio, un obiettivo di crescita dei clienti, lasciando al gruppo software il compito di individuare come realizzarlo.

Il software industriale è commissionato in molti settori diversi. SPID è un esempio di sistema commissionato dalla pubblica amministrazione, per cui nascono molti progetti software; altri settori sono la finanza tecnologica, l'industria 4.0, che integra software e componenti robotiche, e l'agricoltura di precisione.

Nell'agricoltura di precisione, un sistema può automatizzare fasi della raccolta e della produzione e monitorare processi come la fermentazione. Nell'esempio della cantina, dati sui gusti dei consumatori possono aiutare a individuare tendenze, mentre sensori e attuatori possono supportare il controllo dei processi di vinificazione. Il software industriale può quindi operare anche nell'agroalimentare e interagire direttamente con hardware fisico.

Il committente investe risorse proprie o pubbliche: per questo i requisiti strategici e l'investimento che li sostiene sono centrali nel progetto.

Esperto di dominio

L'esperto di dominio conosce il settore in cui opererà il sistema e aiuta a trasformare gli obiettivi generali in specifiche utili a chi sviluppa. Nell'esempio della cantina può essere l'enologo, che spiega quali parametri determinano una fermentazione soddisfacente; il gruppo software traduce poi queste indicazioni in procedure, ad esempio per valutare i dati raccolti.

Lo sviluppatore deve confrontarsi spesso con l'esperto di dominio e spiegargli in modo comprensibile che cosa sta costruendo, così che possa valutarne la correttezza rispetto al dominio. Gli agenti di IA possono essere meno affidabili proprio nelle conoscenze specialistiche non documentate online. Per ricavare tali conoscenze serve saper porre domande e far emergere le idee e le informazioni dell'interlocutore, come nella maieutica socratica.

Analista, progettista e programmatore

L'analista comprende il problema e lo formalizza con modelli concettuali; UML è il linguaggio standard per questi modelli. Il progettista individua una soluzione per il problema rappresentato e ne definisce l'impostazione. Nel modello tradizionale, il programmatore traduce il progetto in codice.

La separazione storica di questi ruoli risale ai sistemi dei mainframe IBM negli anni Sessanta, quando le matematiche definivano il problema e il metodo di calcolo, mentre la codifica sulle schede perforate spettava al programmatore. Dagli anni Duemila, i confini tra queste attività si sono attenuati. Con linguaggi di alto livello, IDE e strumenti di generazione, la scrittura del codice può occupare meno tempo; progettare richiede comunque di immaginare come la soluzione sarà realizzata.

Nel lavoro contemporaneo le competenze di analisi, progettazione e programmazione spesso confluiscono in una stessa figura, detta DevOps, che sa occuparsi dello sviluppo e dell'operatività del software. L'ingegnere informatico deve essere in grado di muoversi tra più parti del processo, comprendendo come le scelte progettuali si traducono in implementazione.

Utente finale e qualità del sistema

L'utente finale usa il software e non coincide necessariamente con chi lo commissiona o con chi conosce il dominio. In una banca, per esempio, possono usare il sistema gli impiegati allo sportello e i clienti tramite l'app; il committente e l'esperto di contabilità possono essere persone diverse.

Il progetto deve considerare esigenze differenti: gli obiettivi strategici del committente, le conoscenze dell'esperto di dominio e l'esperienza d'uso degli utenti finali. La qualità del software è complessa anche perché soddisfare queste esigenze richiede tempo e denaro. Un sistema può raggiungere gli obiettivi dell'organizzazione e contenere la conoscenza corretta del dominio, ma avere comunque un'interfaccia poco agevole per gli utenti.

Manutenzione e ciclo di vita

Dopo la distribuzione, il software deve essere mantenuto e fatto evolvere. Nel ciclo di vita, cioè dalla nascita del software fino alla sua dismissione, la produzione iniziale assorbe una parte ridotta del tempo e del budget, mentre la manutenzione ne assorbe di gran lunga la parte maggiore. La maggior parte del software gestito è quindi costituita da sistemi esistenti.

Un esempio è il sistema degli stipendi della Camera dei Deputati, scritto in COBOL e ancora funzionante. Sostituire un sistema consolidato comporta un rischio significativo: non sempre è noto che cosa accadrà durante la migrazione. I sistemi consolidati restano in uso a lungo anche per questo rischio.