DEVELOPMENT METHODOLOGIES

L’insegnamento ricade tra le attività formative caratterizzanti del percorso di studi e contribuisce alla formazione di figure professionali in grado di progettare, realizzare, rilasciare e far evolvere sistemi software complessi in contesti collaborativi. Fornisce conoscenze sui principali modelli e scuole del ciclo di vita del software (approcci plan-driven, lean/agile, DevOps e prospettive AI-assisted), e sui temi di qualità, architettura e ambienti, integrazione e dati, automazione del delivery e organizzazione dei team. Sviluppa abilità di lavoro iterativo su un prodotto condiviso - specificazione , test e review, integrazione continua, rilascio e osservabilità, decisioni architetturali documentate - e competenze di giudizio metodologico: scegliere, adattare e valutare pratiche e strumenti in funzione del contesto, senza ridurli a un elenco di tecnologie. In questo modo collega e mette a sistema le competenze di programmazione e progettazione già acquisite nel percorso, preparando a ruoli tecnici e di coordinamento in progetti software realistici.

Risultati di apprendimento attesi

1. Conoscenza e comprensione
Lo studente conosce e comprende i principali modelli e scuole del ciclo di vita del software e i relativi vantaggi e limiti; il ruolo e i confini di test, assicurazione della qualità e revisione del codice; i fondamenti di architettura e complessità dei sistemi, ambienti di lavoro, osservabilità e decisioni architetturali; i temi di integrazione tra sistemi, evoluzione dei dati e responsabilità sulla qualità dei dati; le pratiche di automazione di costruzione e rilascio del software, inclusa l’infrastruttura descritta come codice e le strategie di messa in esercizio; i legami tra organizzazione dei team e struttura del sistema; i principali modi di misurare l’efficacia del processo di delivery; le prospettive emergenti di sviluppo assistito dall’intelligenza artificiale e i relativi rischi.
2. Capacità di applicare conoscenza e comprensione
Sa selezionare e adattare pratiche di processo a un contesto progettuale concreto; definire e applicare criteri chiari di accettazione della qualità su un prodotto in evoluzione, cioè stabilire cosa deve essere vero perché un incremento di lavoro sia considerabile completo; condurre cicli di lavoro iterativi con evidenze verificabili, quali test automatici, richieste di integrazione del codice e condizioni di completamento condivise; contribuire a pipeline di integrazione continua e a procedure di rilascio e di ripristino in caso di problemi; redigere specifiche sintetiche e registri delle decisioni architetturali utili a guidare persone o strumenti automatici; usare misure e segnali operativi per ragionare su avanzamento e affidabilità.
3. Capacità di giudizio
Sa confrontare approcci metodologici e tecnologici in presenza di vincoli e di informazione incompleta; distinguere la complessità propria del problema da quella introdotta da scelte tecniche evitabili; valutare quando automatizzare, quando standardizzare e quando mantenere il controllo umano, anche nell’uso di strumenti di intelligenza artificiale; riconoscere i compromessi tra velocità, qualità, rischio e carico di lavoro del team.
4. Abilità comunicative
Sa comunicare decisioni tecniche e di processo in forma chiara a colleghi e a interlocutori non solo tecnici, anche attraverso dimostrazioni di software funzionante, note di architettura, criteri di completamento ed esiti di retrospettive; documentare in modo essenziale ciò che deve restare patrimonio condiviso del gruppo di lavoro.
5. Capacità di apprendimento
Sa aggiornare il proprio modo di lavorare di fronte a nuovi strumenti e paradigmi, collegandoli a principi duraturi; curare la conoscenza del team, dalla raccolta all’organizzazione e al riuso; proseguire lo studio in modo autonomo su fonti primarie e su casi provenienti dal mondo professionale.

Prerequisiti

Sono richieste solide conoscenze di programmazione e la capacità di realizzare e modificare programmi di media complessità in almeno un linguaggio diffuso nello sviluppo software.
È utile, anche se non strettamente indispensabile, aver già incontrato nozioni di base di progettazione del software (modularità, interfacce, uso di librerie o servizi) e di gestione del codice con un sistema di controllo di versione.
Non sono richieste conoscenze pregresse di metodologie agili, DevOps o strumenti specifici di integrazione e rilascio continuo: tali temi sono introdotti e praticati durante l’insegnamento.
Eventuali propedeuticità formali sono quelle previste dal regolamento del corso di studio.

L’insegnamento integra fondamenti teorici e lavoro progettuale iterativo su un prodotto software condiviso. I contenuti sono organizzati nei seguenti ambiti.

1. Giudizio sul metodo e ciclo di vita del software
Modelli e scuole di processo (approcci plan-driven, lean, agile e DevOps); complessità essenziale e accidentale; definizione di completamento e “verità” del prodotto (codice, test, ambienti); avvio del lavoro di team su un prodotto comune.
2. Qualità, verifica e craft del codice
Limiti del testing; portafoglio di tecniche di verifica; sviluppo guidato dai test e specificazione del comportamento; revisione del codice, anche in presenza di strumenti di intelligenza artificiale; leggibilità, igiene della conoscenza di team e criteri di qualità condivisi.
3. Architettura, ambienti e operatività
Modularità e confini di responsabilità; registrazione delle decisioni architetturali; strategia degli ambienti di lavoro; osservabilità e indicatori di servizio; dimostrazioni intermedie di avanzamento.
4. Integrazione e dati
Accoppiamento tra componenti e integrazioni sincrone/asincrone; evoluzione di sistemi esistenti; modellazione e evoluzione degli schemi dati; responsabilità sulla qualità e sulla proprietà dei dati.
5. Costruzione, automazione e rilascio
Sistemi di build e artefatti affidabili; container e infrastruttura descritta come codice; pipeline di integrazione e consegna continua; strategie di messa in esercizio, feature flag e procedure di ripristino.
6. Organizzazione, stima, intelligenza artificiale e misura
Legame tra struttura dei team e architettura del sistema; stime e prioritizzazione in contesti incerti; paradigmi di sviluppo assistito dall’intelligenza artificiale e supervisione umana; metriche di delivery ed efficacia; sintesi finale del metodo di lavoro adottato.

Lungo tutto il percorso gli studenti applicano i temi sopra a incrementi successivi dello stesso prodotto, con momenti periodici di dimostrazione, feedback e ripianificazione.

• F. P. Brooks Jr., “No Silver Bullet — Essence and Accident in Software Engineering”, in Computer, IEEE, 1987 (versione saggio del 1986; reperibile via biblioteche universitarie / ACM Digital Library).
• Manifesto for Agile Software Development, 2001, https://agilemanifesto.org/ (e principi correlati).
• J. Humble, D. Farley, Continuous Delivery, Addison-Wesley, 2010; risorse collegate su https://continuousdelivery.com/
• N. Forsgren, J. Humble, G. Kim, Accelerate: The Science of Lean Software and DevOps, IT Revolution, 2018; quadro metriche anche su https://dora.dev/
• M. Skelton, M. Pais, Team Topologies, IT Revolution, 2019; sito https://teamtopologies.com/
• M. Nygard, “Documenting Architecture Decisions”, 2011, https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions (si veda anche https://adr.github.io/ )
• M. Fowler, “Strangler Fig Application”, https://martinfowler.com/bliki/StranglerFigApplication.html
• M. E. Conway, “How Do Committees Invent?”, Datamation, 1968 (sintesi e contesto: https://en.wikipedia.org/wiki/Conway%27s_law )
• Materiali e casi aggiornati sull’impatto dell’intelligenza artificiale nello sviluppo software e sul ciclo di vita AI-assisted (white paper e report indicati dal docente all’inizio dell’anno accademico; copie o link sulla piattaforma e-learning).
• K. Beck, Test-Driven Development: By Example, Addison-Wesley, 2002.
• K. Beck, Extreme Programming Explained, Addison-Wesley (edizione più recente disponibile).
• G. Kim, J. Humble, P. Debois, J. Willis, The DevOps Handbook, IT Revolution (edizione più recente disponibile).
• E. Evans, Domain-Driven Design, Addison-Wesley, 2003; in alternativa V. Vernon, Domain-Driven Design Distilled, Addison-Wesley, 2016.
• R. C. Martin, Clean Code, Prentice Hall, 2008.
• M. Fowler, Refactoring, Addison-Wesley (edizione più recente disponibile); sito https://refactoring.com/
• Google, Site Reliability Engineering (capitoli su SLO e gestione degli errori), gratuito online: https://sre.google/books/
• Z. Dehghani, principi di Data Mesh, https://martinfowler.com/articles/data-mesh-principles.html
• Ulteriori articoli, post tecnici e casi industriali (Netflix, Zalando, Google SRE, ecc.) saranno segnalati di volta in volta in relazione agli argomenti trattati.

Modalità di verifica dell’apprendimento

La verifica è coerente con un insegnamento basato su lavoro progettuale iterativo e su capacità di giudizio metodologico. Si articola in due componenti obbligatorie, a cui può aggiungersi una componente di partecipazione attiva.

1. Portfolio di progetto (peso indicativo: 60% del voto finale)
Durante il corso gli studenti lavorano, in gruppo, a incrementi successivi di un prodotto software condiviso. La valutazione riguarda non tanto il numero di funzionalità realizzate, quanto la qualità del metodo di lavoro e delle evidenze prodotte, tra cui, in particolare:

• storia del lavoro di team (board, priorità, ripianificazioni dopo le dimostrazioni);
• contributi di codice sottoposti a integrazione, con test e revisioni;
• criteri di completamento adottati e rispettati;
• registri delle decisioni architetturali e specifiche sintetiche;
• automazione di integrazione/rilascio e, ove previsto, storia di messa in esercizio e ripristino;
• dimostrazioni periodiche di software funzionante e sintesi delle retrospettive;
• eventuale uso di strumenti di intelligenza artificiale, dichiarato e spiegabile.

Il portfolio verifica soprattutto la capacità di applicare conoscenze, il giudizio metodologico, la comunicazione tecnica e il lavoro iterativo con evidenze.

2. Prova individuale (peso indicativo: 40% del voto finale)
Prova scritta e/o orale, della durata indicativa di 30–60 minuti, su concetti, confronti tra approcci e casi. Può richiedere di interpretare situazioni simili a quelle affrontate nel progetto (qualità, architettura, integrazione, rilascio, organizzazione, misura, uso consapevole dell’AI).
Verifica conoscenza e comprensione, capacità di giudizio e chiarezza espositiva. Non è una ripetizione mnemonica del portfolio: lo studente deve saper ragionare in autonomia sul materiale del corso.

Regole di composizione del voto
Il voto finale in trentesimi è la media ponderata delle componenti sopra indicate. Per superare l’esame è necessario raggiungere la sufficienza complessiva; il docente può richiedere la sufficienza su entrambe le componenti principali quando il portfolio è di gruppo, al fine di accertare la preparazione individuale.
Nei lavori di gruppo la valutazione può differenziare i contributi individuali sulla base delle evidenze (commit, revisioni, parti discusse in sede di prova).
L’uso di strumenti di intelligenza artificiale è consentito nel lavoro di progetto solo se dichiarato; in sede di verifica lo studente deve saper spiegare scelte, limiti e contenuto di eventuali parti generate automaticamente.
I criteri di dettaglio, le scadenze delle dimostrazioni e i modelli di prova, quando disponibili, sono pubblicati sulla piattaforma e-learning.

scritto

Il/la docente ha il dovere di vigilare affinché siano rispettate le regole di autenticità e originalità delle prove d'esame. Di conseguenza, nei casi in cui vi sia il sospetto di un comportamento irregolare, l'esame può prevedere un ulteriore approfondimento, contestuale alla prova d'esame, che potrà essere realizzato anche in modalità differente rispetto alle modalità sopra riportate.

Graduazione del voto

Il voto finale è espresso in trentesimi ed è la media ponderata di portfolio di progetto (60%) e prova individuale (40%). Di seguito i livelli di prestazione usati per orientare la valutazione di ciascuna componente e del risultato complessivo.

Insufficiente (sotto 18/30)
Conoscenze frammentarie o errate sui temi centrali del corso. Nel portfolio mancano evidenze essenziali (incrementi, test, integrazioni, criteri di completamento, dimostrazioni) oppure il lavoro non è spiegabile dal singolo studente. Nella prova individuale non si riesce a ragionare su casi semplici né a confrontare approcci in modo corretto.

Sufficiente (18–20/30)
Conoscenza di base dei principali contenuti e applicazione corretta ma limitata. Il portfolio mostra un percorso minimo completo, con alcune evidenze di qualità e di processo, anche se irregolari o poco approfondite. La prova individuale risolve domande e casi semplici con argomentazioni essenziali.

Discreto (21–23/30)
Padronanza discreta dei concetti e capacità di applicarli a situazioni tipiche del corso. Il portfolio è coerente: incrementi successive, verifiche e integrazioni presenti, decisioni e criteri di completamento documentati in modo comprensibile. La prova individuale confronta approcci con qualche esempio pertinente e pochi errori rilevanti.

Buono (24–26/30)
Conoscenza sicura e buona capacità di applicazione e di giudizio. Il portfolio evidenzia lavoro iterativo di qualità (test e revisioni efficaci, scelte motivate, automazione o procedure di rilascio/ripristino ove richieste, demo chiare). La prova individuale affronta casi non banali, motiva i trade-off e collega teoria e pratica del progetto.

Ottimo (27–28/30)
Padronanza ampia e uso maturo del metodo. Il portfolio è solido, leggibile e ben argomentato; le evidenze mostrano miglioramento nel tempo e controllo consapevole di qualità, architettura, integrazione e delivery. La prova individuale è precisa, critica e capace di gestire informazione incompleta.

Eccellente (29–30/30)
Padronanza completa e giudizio autonomo di livello elevato. Il portfolio costituisce un esempio di metodo rigoroso ed efficace, con documentazione essenziale ma di alta qualità e contributi individuali chiaramente riconoscibili. La prova individuale è eccellente per completezza, rigore e capacità di sintesi; eventuali parti generate con intelligenza artificiale sono dichiarate e pienamente spiegate. La lode può essere attribuita in presenza di eccellenza su entrambe le componenti.

Criteri trasversali (valgono per entrambe le componenti)

• Correttezza concettuale e completezza rispetto a quanto richiesto.
• Qualità delle evidenze e spiegabilità del proprio contributo.
• Capacità di giudizio sui compromessi (velocità, qualità, rischio, carico di lavoro).
• Chiarezza di comunicazione (scritta, orale o tramite software funzionante).
• Uso dichiarato e consapevole di strumenti di intelligenza artificiale, ove presenti.

Lezioni teoriche e pratiche in aula;
Risorse online (note, slide, video);
Chat e forum;