SC01103936 - INGEGNERIA DEL SOFTWARE 2022-2023
Indice degli argomenti
-
-
-
Questa pagina, in periodico aggiornamento, contiene il calendario delle attività dell'insegnamento Ingegneria del Software, unitamente alle risorse corrispondenti agli argomenti trattati. Gli studenti dovranno fare riferimento a tale pagina per conoscere la sequenza degli argomenti trattati, e i giorni di svolgimento delle attività.
-
Aperto: giovedì, 8 dicembre 2022, 17:00
Questionario intermedio sull’organizzazione e l’efficacia della didattica in presenza
Le chiediamo di esprimere una serie di valutazioni sull'organizzazione e l'efficacia della didattica in presenza.
Le Sue indicazioni saranno un contributo prezioso per il miglioramento di questo insegnamento.
Le risposte a questo questionario sono anonime, e il loro esito resterà al Docente.
Grazie della collaborazione.
-
In questa prima settimana, facciamo conoscenza con l'insegnamento "Ingegneria del Software", i suoi temi principali, il suo calendario di attività, e il suo metodo didattico. Assaggiamo anche il ritmo piuttosto serrato delle lezioni e l'alternanza dei loro temi, tra teoria, pratica, e avvicinamento al progetto didattico.
-
Qui trovate il puntatore alle diapositive oggetto della lezione del 4 ottobre 2022. Come anticipato a voce, la lezione in aula non espone tutte le diapositive, ma solo si concentra sui temi principali, lasciando il resto alla lettura, lo studio, e l'approfondimento autonomo degli studenti.
L'argomento T1 spiega e contestualizza il senso delle principali parole chiave del dominio detto "Ingegneria del Software". Tra esse assume speciale importanza la nozione di "progetto" (cosa lo è, cosa non lo è) e sulla sua comprensione si concentra molto materiale.
Oltre a ciò, l'argomento T1 illustra il metodo didattico adottato in questo insegnamento, che si incentra su una tecnica nota come "apprendimento attivo", cioè sul praticare subito, immediatamente, quanto evocato in aula, stimolando e richiedendo sforzi di auto-apprendimento, per poter affrontare sfide sempre più avanzate, sia sul piano del metodo che delle tecnologie.
-
I contenuti delle due lezioni presentate nella registrazione presentano poche differenze marginali con quanto esposto in aula nelle lezioni T1 di quest'anno. Essi dunque costituiscono un ausilio affidabile all'apprendimento dei temi qui discussi.
-
Prima di accedere a questa pagina, assicuratevi di aver ben compreso quanto riportato al titolo "Svolgimento del progetto didattico" del documento di presentazione dell'insegnamento e le pagine 26-27 delle diapositive di presentazione dell'argomento T1.
-
Con oggi inizia anche la parte 'P' dell'insegnamento IS, a cura del docente Riccardo Cardin, da lungo tempo collaboratore di questo corso. Il materiale di lezione è riportato nel calendario, sopra riferito, insieme a materiale di approfondimento, che siete invitati a utilizzare.
-
-
Nella seconda settimana di lezione completiamo la prima presa di conoscenza con la nozione di ciclo di vita del software, e dei processi che alimentano le transizioni tra gli stati del ciclo di vita. Su quella base, esploriamo i principali modelli organizzativi delle attività di processo comprese nel segmento tra concezione (stadio iniziale) e sviluppo (stadio immediatamente precedente al primo rilascio pubblico), che sono chiamati appunto "modelli di sviluppo".
Nella parte pratica dell'insegnamento, con il docente Cardin, ragioniamo sul ruolo essenziale della progettazione (design) software come premessa, giustificazione, e guida alla codifica e facciamo conoscenza con il formalismo che useremo nel progetto didattico per rappresentare i prodotti dell'analisi dei requisiti e della progettazione.
-
L'argomento T2 illustra come la "vita" del software si dipani tra un momento iniziale, in cui l'attenzione è tutta incentrata sui bisogni che motivano la sua realizzazione, e la sua vita operativa, fino all'eventuale ritiro definitivo, in cui il suo ulteriore utilizzo è deprecato o non più possibile tecnologicamente, attraverso tutte le attività che chiamiamo "sviluppo". Il tema centrale di questo argomento è prendere consapevolezza che le attività che "spingono" il software più avanti nel proprio ciclo di vita sono molte e articolate, al punto da richiedere un sistema strutturato di classificazione e di organizzazione, per stabilire in modo uniforme "chi fa cosa" tra esse. Nella discussione di questo argomento vediamo anche come il segmento di vita più lungo, idealmente e praticamente, per un prodotto software è la manutenzione, dove l'esperienza d'uso mette in rilievo mancanze, difetti e nuove esigenze, e l'evoluzione tecnologica richiede adattamenti o crea opportunità di evoluzione. L'ovvia necessità che la manutenzione non sia una "giungla selvaggia" richiede accorgimenti di concezione, organizzazione, e scrittura del software di cui tratteremo nelle prossime settimane.
-
La parte del ciclo di vita del software più vicina ai temi "vivi" di questo insegnamento è il segmento da "concezione" a sviluppo. Vi sono diversi modi per organizzare le attività che servono per percorrere quel tratto. Questi modi sono teorizzati in "modelli": in questa lezione illustriamo e discutiamo alcuni di essi.
-
Parte della difficoltà di scrivere software è proprio dover comunicare idee e concetti riguardanti il software. Il linguaggio UML ci viene in aiuto, definendo un linguaggio formale attorno alle diverse sfacettature del mondo dell'ingegneria del software.
Introduciamo per primi i diagrammi delle classi.
-
-
La terza settimana di lezione è in larga parte dedicata all'avvio delle attività di progetto didattico (limitatamente ai gruppi del I lotto), con la pubblicazione della composizione dei gruppi, l'esposizione del regolamento di progetto che i gruppi dovranno comprendere e scrupolosamente seguire, e infine la presentazione dei capitolati d'appalto.
La parte pratica dell'insegnamento prosegue con l'approfondimento del formalismo UML.
-
Qui trovate la composizione dei gruppi del I lotto, determinata a valle della corrispondente discussione preliminare svoltasi in aula. L'algoritmo utilizzato ha diviso gli 86 studenti aventi diritto in 13 gruppi, 8 dei quali composti da 7 persone, e i rimanenti 5, da 6: i corrispondenti gruppi sono immediatamente attivi. Questi i loro primi impegni:
- dotarsi di un nome, di un logo, e di un recapito riflettore di posta elettronica;
- cominciare a ragionare sul proprio way of working, secondo le indicazioni del regolamento del progetto didattico.
-
Qui trovate il materiale di presentazione del regolamento del progetto didattico illustrato nella lezione lunedì 17 ottobre 2022, valide per l'intero anno accademico, quindi per il I e il II lotto.
-
Come avrete visto, il calendario delle attività d’aula di questo insegnamento è costellato di eventi intitolati “diario di bordo”. Nella lezione di lunedì scorso, 17 ottobre, sul “regolamento del progetto didattico”, vi ho dato alcune indicazioni iniziali sull’uso che faremo di tali attività. Con questa comunicazione ne integro la presentazione, con informazione più sistematica e completa.
-
In questa lezione approfondiamo una tecnica di analisi delle funzionalità e dei requisiti di un sistema: I casi d'uso. Con questa lezione inizieremo ad utilizzare e sviluppare il progetto "interno" al corso, ossia una versione semplificata di imdb.
-
-
La settimana 4 prevede la prima occorrenza dell'attività "diario di bordo", con la dinamica qui spiegata, e poi due lezioni, una di teoria, incentrata sulle problematiche e le metodiche di gestione di progetto, e l'altra di pratica, con la prima introduzione a un tema centrale nella disciplina IS: la progettazione software (design) guidata da stili architetturali predefiniti con ben definite proprietà.
-
In queste lezione, proveremo ad introdurre il concetto di architettura software e i più comuni pattern architetturali utilizzati oggi giorno: Dal monolite, ai microservizi. Dalle layered architecture alle hexagonal (clean) architecture.
-
Anche questa settimana ha meno impegni d'aula del solito. La lezione di teoria servirà come "apripista" per la "lezione rovesciata" che svolgeremo il 17 novembre, incentrata su metodi e strumenti per lo sviluppo del software. La lezione di pratica proseguirà il percorso di esplorazione della progettazione guidata da "pattern".
In questa settimana anche avviene l'aggiudicazione degli appalti relativamente ai gruppi del I lotto. Un procedimento analogo avverrà più avanti per i gruppi del II lotto.-
Il documento qui pubblicato riporta le decisioni di aggiudicazione degli appalti in risposta alle candidature ricevute. Ove l'aggiudicazione risulti "sospesa", il gruppo candidato dovrà presentare emendamenti che sanino le mancanze segnalate, cui seguirà nuova valutazione.
-
Continuiamo ad analizzare i pattern architetturali, soffermandoci questa volta su una problematica complessa: La risoluzione delle dipendenze in fase di costruzione di un oggetto.
Come di consueto, la lezione prevederà del live coding sul progetto di riferimento, https://github.com/rcardin/swe-imdb
-
In questa settimana l'attenzione delle lezioni di teoria si sposta sulle attività di analisi dei requisiti, in corrispondenza con la formalizzazione dell'aggiudicazione degli appalti ai gruppi del I lotto e il conseguente avvio effettivo del loro progetto.
Le lezioni di pratica invece continuano l'approfondimento sulle tecniche di progettazione software guidata da stili architetturali dotati di buone proprietà.-
La lezione di lunedì 7 novembre si svolgerà come attività "diario di bordo", con le modalità qui descritte e già sperimentate il 24 ottobre scorso. I gruppi sono invitati a prestare attenzione a riferire sui loro passi futuri, per intenzioni da dichiarare e dubbi sui quali chiedere consiglio.
-
Queste due lezioni di teoria illustrano il problema dell'analisi dei requisiti (a cosa serve, cosa fa, come lo fa) e alcune buone prassi di conduzione delle corrispondenti attività. Questi contenuti integrano e completano quanto già avete visto nella lezione di pratica relativa a i casi d'uso per l'analisi e la descrizione delle funzionalità software.
-
In questa lezione introdurremo una famiglia di pattern collegati allo sviluppo di applicazione che richiedono una user interface. Questi pattern vengono chiamati Model-View-* e sono:
- Model-View-Controller
- Model-View-Presenter
- Model-View-ViewModel
-
-
-
Come già anticipato, le lezioni del 15 e 17 novembre si svolgono in modalità rovesciata, cioè con presentazione di contenuti elaborati ed esposti da parte degli studenti e non già del docente, e discussione aperta, con il docente operante come moderatore e l’aula come partecipante attivo.
-
Con questa lezione iniziamo ad analizzare i design pattern presenti nel famoso libro della Gang of Four, Design Pattern. I primi pattern che analizzeremo sono parte di quelli definiti "creazionali":
- Abstract Factory
- Singleton
- Builder
-
-
In questa settimana svolgiamo solo lezioni di teoria, che si ricongiungono con la parte di pratica intorno al tema della progettazione software, nell'accezione di "design".
-
Affrontiamo questo importante argomento in tre lezioni successive, utilizzando un unico blocco di diapositive, che discuteremo in profondità in aula.
-
-
In questa settimana, il calendario delle attività subisce due variazioni:
A) la lezione di martedì 29 novembre non avrà luogo, a causa di un impegno fuori sede del docente;
B) la lezione di giovedì 1 dicembre slitta a mercoledì 30 novembre, alle ore 8:30, in luogo di Ricerca Operativa (quindi alle 8:30), che fa il percorso inverso.
Nella lezione di lunedì 28 novembre riprenderemo l'attività "diario di bordo", dopo la sospensione della settimana scorsa.
Nella lezione di mercoledì 30 novembre invece faremo una sorta di "sosta ai box", tornando al tema dell'analisi dei requisiti, discutendo di come usare i casi d'uso (per individuazione di scenari e attori), e di come da essi derivare requisiti "di lato soluzione", nelle situazioni concrete del progetto didattico. Svolgeremo questa lezione come un "ricevimento collettivo", fatto di domande e risposte, con l'ausilio del proiettore per entrambe.
La lezione di venerdì 2 dicembre, invece, dedicata alla pratica, riprenderà il tema dei design pattern.-
La lezione continua ad analizzare i design pattern presenti nel famoso libro della Gang of Four, Design Pattern. Questa volta è il momento di introdurre alcuni dei pattern definiti "strutturali", perché agiscono sulle relazioni di composizione tra classi:
- Adapter
- Decorator
- Façade
- Proxy
-
-
Le lezioni di questa settimana sono considerevolmente amputate dal ponte dell'Immacolata. Restano pertanto in calendario l'attività "diario di bordo" e la prima di tre lezioni di teoria incentrate sul tema della qualità. Il primo argomento che tratteremo al riguardo sarà "la qualità software".
-
Per la parte di teoria, le lezioni di questa settimana completano il ragionamento sulla qualità, spostando l'attenzione sulla qualità dei processi, ossia del modo di lavorare, e poi iniziano un trittico dedicato alle tecniche di verifica, la cui trattazione concluderà il programma. Il percorso di pratica, invece, continuerà l'illustrazione dei design pattern secondo la categorizzazione della Gang of Four, concentrandosi su quelli comportamentali.Causa impegni fuori sede del docente, l'attività "diario di bordo" di questa settimana vi svolgerà via Zoom.
-
La lezione continua ad analizzare i design pattern presenti nel famoso libro della Gang of Four, Design Pattern. Questa volta è il momento di introdurre alcuni dei pattern definiti "di comportamento", perché forniscono soluzioni progettuali a problematiche funzionali:
- Command
- Iterator
- Observer
- Strategy
- Template Method
-
Questa settimana, resa più breve dall'avvio delle vacanze di Natale, si sviluppa tra lunedì e giovedì, comprimendo l'attività "diario di bordo" di lunedì, e anticipando la trattazione di uno dei due argomenti di teoria che concludono il programma, incentrato sulle tecniche di analisi statica del codice.<br>La parte di pratica, invece, tocca il suo ultimo argomento discutendo importanti principi di programmazione.
-
Terminato l'excursus sui design pattern, introduciamo dei principi di programmazione che dovrebbero permettere la corretta gestione delle dipendenze fra componenti: I principi SOLID.
-
Questa settimana include tutte le attività canoniche, concludendo il percorso di teoria con due lezioni sull'analisi dinamica del codice (aka test), e includendo la prima di due esercitazioni in preparazione alla prova scritta che integra la valutazione dell'esame di questo insegnamento.Proprio in previsione delle sessioni d'esame che ospiteranno le prove scritte, qui anticipiamo anche l'informazione essenziale sulla struttura di quel tipo di prova.
-
-
Prima lezione in preparazione dell'esame scritto. Durante la lezione, discuteremo e proveremo a risolvere insieme alcuni quesiti direttamente presi dagli esami degli anni passati.
-
-
La prova d'esame “scritto” di IS consiste di due blocchi di quiz, uno di profilo teorico l'altro di profilo pratico, e due blocchi di compiti, con la medesima ripartizione.
-
Aperto: venerdì, 15 settembre 2023, 09:30Chiuso: venerdì, 15 settembre 2023, 09:35
In questa sezione si trova il blocco dei quiz di profilo teorico.
I quiz sono a svolgimento individuale, e per questo soggetti a tempi di esecuzione molto rapidi.
Questo blocco di quiz comprende due quesiti, con diverse possibili modalità di risposta, e un punteggio, positivo o negativo, associato a ciascuna. -
Aperto: venerdì, 15 settembre 2023, 09:39Chiuso: venerdì, 15 settembre 2023, 09:54
In questa sezione si trova il blocco dei quiz di profilo pratico.
Anche in questo caso, i quiz sono a svolgimento individuale, e per questo soggetti a tempi di esecuzione molto rapidi. Questo blocco di quiz comprende tre quesiti, con diverse possibili modalità di risposta, e un punteggio, positivo o negativo, associato a ciascuna. -
Aperto: venerdì, 15 settembre 2023, 10:00Data limite: venerdì, 15 settembre 2023, 11:32
In questa sezione si trova la parte teorica della prova che Moodle definisce "compito".
La prova "compito" è intesa come collaborativa, perché la collaborazione, cioè la discussione tra pari, rafforza sia la comprensione del quesito che la concezione della soluzione proposta.
Cionondimeno, la collaborazione è una facoltà, ma non un obbligo.
Il documento base da utilizzare per la risposta è qui fornito in formato sorgente.
La risposta andrà fornita caricando il PDF generato da tale documento, riportando chiaramente, nella sua intestazione, i nominativi dei rispondenti che abbiano collaborato alla risposta.
La correzione avverrà tramite l'inserimento di annotazioni nel documento PDF di consegna. -
Aperto: venerdì, 15 settembre 2023, 11:30Data limite: venerdì, 15 settembre 2023, 13:15
Come la sua analoga per la parte di teoria, questa prova è intesa come collaborativa, sia per la comprensione del quesito che per la concezione della soluzione proposta.
Il documento base da utilizzare per la risposta è qui fornito in formato sorgente.
La risposta andrà fornita caricando il PDF generato da tale documento, riportando chiaramente, nella sua intestazione, i nominativi dei rispondenti. Prestate attenzione a non sovrascrivere i documenti di consegna tra le due prove "Compito".
La correzione avverrà tramite l'inserimento di annotazioni nel documento PDF di consegna.
-