|
Ingegneria
del Software |
Ultimo aggiornamento: 2 marzo
2018 ore 15:45
L'insegnamento di Ingegneria del Software si sviluppa su due semestri, collocando la maggior parte della didattica d'aula all'interno del I semestre, e la parte prevalente delle attività pratiche nel II semestre.
L'insegnamento si propone di fornire allo studente gli
strumenti metodologici per e l'opportunità di sviluppare con successo un
impegnativo progetto didattico di sviluppo software
da svolgersi in gruppo, secondo metodi professionali di conduzione e di
gestione del rapporto cliente-fornitore.
L'insegnamento si concentra sull'illustrazione di strumenti intellettuali
per comprendere e sistematizzare l'insieme di conoscenze essenziali della
disciplina detta Software Engineering. A tal fine, il corso
illustra ciascuna delle aree di conoscenza
rilevanti nell'ambito, correlandovi le regole metodologiche che gli
studenti dovranno seguire nello svolgimento del progetto didattico, la cui
realizzazione effettiva avverrà, a partire dalla seconda metà di novembre,
per poi proseguire nel II semestre.
Il progetto didattico si svolgerà secondo il seguente calendario:
L'accettazione finale del prodotto sviluppato da ciascun gruppo nel progetto didattico soddisferà una delle due condizioni necessarie al superamento dell'esame. L'altra condizione richiede il superamento di una prova scritta individuale, che ciascuno studente potrà sostenere nelle date sopra indicate. Per ogni studente partecipante, la valutazione numerica del progetto didattico varrà il 60% del voto complessivo individuale, determinato dalla media pesata della valutazione conseguita dal proprio gruppo di progetto in ognuna delle tre revisioni di avanzamento, con una quota di ponderazione legata al rapporto tra l'impegno medio atteso e l'impegno effettivo erogato dallo studente. Il rimanente 40% verrà determinato dalla valutazione della prova scritta individuale.
L'intero svolgimento dell'insegnamento Ingegneria del Software ha un "peso" di 13 CFU, ripartiti come segue:
Programmazione a Oggetti, Basi di Dati.
Note esplicative: Il mancato
soddisfacimento della propedeuticità Programmazione a Oggetti (o
Programmazione 2 del V/O) impedisce tassativamente la partecipazione degli
studenti alla prova scritta individuale di IS, il cui superamento è
obbligatorio per il superamento dell'esame.
Possono però partecipare alle attività di progetto gli studenti che, senza
aver superato l'esame di Programmazione a Oggetti (o Programmazione 2), ne
hanno superato una prova scritta.
Il mancato soddisfacimento di tali propedeuticità non consentirà la partecipazione dello studente al progetto didattico.
Il materiale didattico presentato durante le lezioni sarà progressivamente pubblicato, in formato elettronico, tramite collegamento alla lezione corrispondente.
Il principale riferimento bibliografico di supporto al corso è il seguente:
Guide
to the Software Engineering Body of Knowledge
IEEE Computer Society. Software Engineering Coordinating Committee (V3
2014)
(Le aree di conoscenza corrispondenti agli argomenti
trattati a lezione sono riferite nel calendario delle lezioni)
Sono inoltre consigliati i seguenti testi:
Software Engineering
(10th edition)
Ian Sommerville
Pearson Education | Addison-Wesley
Design Patterns
E. Gamma, R. Helm, R. Johnson, J. Vlissides
Pearson Education | Addison-Wesley
Settimana |
Data |
Lezione |
Docente |
Contenuto |
SWEBOK |
Sommerville |
1 |
2 ottobre |
T1 |
Vardanega | Introduzione Per approfondire #1: No Silver Bullet. Essence and Accidents of Software Engineering Per approfondire #2: IEEE Code of Ethics |
|
|
2 |
9 ottobre |
T2 |
Vardanega |
Continuazione lezione 1 |
|
|
12 ottobre |
T3 |
Vardanega |
Processi software Per approfondire #3: Origine, formazione ed evoluzione degli standard di processo Per approfondire #4: Lo standard ISO/IEC 12207:1995 |
§8 | §2 | |
13 ottobre | T4 | Vardanega |
Continuazione lezione 3 |
|||
3
|
16 ottobre |
T5 |
Vardanega |
Il ciclo di vita del
software |
|
§3 |
19 ottobre |
T6 |
Vardanega |
Gestione di progetto |
§7,12 | §19,20 | |
20 ottobre | T7 | Vardanega | Flipped
classroom sul tema Amministrazione
di progetto Studio autonomo, presentazione e discussione in aula di strumenti di versionamento, configurazione, pianificazione, coordinamento: spunti Per approfondire #12: Strumenti di collaborazione |
§6 | §22 | |
4 | 23 ottobre | E1 | Cardin | UML Introduzione Diagrammi dei casi d'uso |
||
26 ottobre | T8 | Vardanega | Analisi dei requisiti Per approfondire #13: Struttura commentata del documento di specifica dei requisiti secondo IEEE 830-1998 |
§1 |
§4 |
|
27 ottobre | T9 | Vardanega | Continuazione lezione T8 | |||
5 |
30 ottobre | E2 | Cardin |
UML Diagrammi delle classi Diagrammi dei package Per approfondire #14: dal blog di R.Cardin |
|
|
2 novembre |
T10 |
Vardanega |
Progettazione Per approfondire #15: Fan-in e fan-out Per approfondire #16: Definizioni di architettura software Per approfondire #17: Christopher Alexander sulla teoria dei pattern |
§2-3 |
§6-7 |
|
3 novembre | T11 | Vardanega | Continuazione lezione T10 | |||
6 |
6 novembre | E3 | Cardin | UML Diagrammi di sequenza Diagrammi di attività |
||
9 novembre | P1 | Vardanega | Regole del progetto didattico Regolamento Capitolati Regolamento Organigramma |
|||
10 novembre | P2 | Vardanega | Presentazione dei capitolati d'appalto | |||
7 | 13 novembre | E4 | Cardin | Design pattern strutturali: Decorator, Proxy, Facade, Adapter |
||
16 novembre | T12 | Vardanega | Flipped
classroom sul tema documentazione Studio autonomo, presentazione e discussione in aula di soluzioni per la scrittura collaborativa, la verifica, la salvaguardia di documenti di progetto: spunti |
§8 | ||
17 novembre | T13 | Vardanega |
§10 | §21 | ||
8 | 20 novembre (@ 10:30) |
T14 | Vardanega | Continuazione lezione T13 | ||
23 novembre | T15 | Vardanega | Qualità di processo Per approfondire #18: Elementi dello standard ISO 9000 Per approfondire #19: Sintesi di ISO IEC 90003:2004 |
|||
9 | 27 novembre |
E5 | Cardin |
Design pattern
creazionali: |
||
28 novembre (12:30-13:30) |
P3 | IKS | Data analysis con ElasticSearch e Kibana | |||
30 novembre | T16 | Vardanega | Flipped
classroom sul tema Modelli di
sviluppo avanzati Studio autonomo, presentazione e discussione in aula di modelli di sviluppo agile, e di principi SEMAT |
§3 | ||
1 dicembre | T17 | Vardanega | Verifica e validazione:
introduzione Per approfondire #20: Fagan Inspection & Walkthrough Per approfondire #21: Bertrand Meyer sul testing |
§5 | ||
1 dicembre (12:30-13:30 |
P4 | Mivoq | Guida all'uso di CMake | |||
10 |
4 dicembre |
E6 |
Cardin |
Design
pattern comportamentali: Observer, Template Method, Command, Strategy, Iterator |
||
5 dicembre (12:30-13:30) |
P5 | Zucchetti | Pattern, anti-pattern, e robustness diagram | |||
7 dicembre | P6 | Bertazzo | Integrazione continua | |||
Questionario valutazione didattica | ||||||
11 |
11 dicembre | T18 | Vardanega | Verifica e validazione: analisi statica | ||
13 dicembre (12:30-13:30) |
P7 | Zero12 | Google Cloud Platform | |||
14 dicembre |
E7 | Cardin |
Continuazione lezione E6 |
|
||
15 dicembre | T19 | Vardanega | Verifica e validazione: analisi dinamica Per approfondire #22: Effetti indesiderabili del dynamic binding |
§4 |
§8 | |
15 dicembre (16:30-18:00) |
P8 | Vardanega | Incontro con i gruppi del I lotto | |||
12 | 18 dicembre | E8 | Cardin | Design pattern
architetturali: Dependency Injection |
||
15 |
8 gennaio | E9 | Cardin | Design pattern architetturali: MVC, MVP e MVVM |
||
9 gennaio | P9 | RedBabel | Il ciclo di sviluppo di Dapp in Ethereum | |||
11 gennaio | T20 |
Vardanega | Recupero e ripasso Consegna questionari valutazione didattica |
|||
12 gennaio | Vardanega | Incontro
informativo sugli stage curricolari |
||||
|
RR 26 gennaio |
P11 |
Revisione dei Requisiti
(RR) ore 17:00 di martedì 16 gennaio
|
|||
Calendario II semestre |
Le lezioni indicate in calendario si terranno nelle aule e con l'orario indicati sul sito del CCS di Informatica.
Il ricevimento studenti si tiene per appuntamento in stanza #400 il:
martedì 11:30 - 12:30
mercoledì 11:30 - 12:30
Le revisioni formali sono bloccanti:
la RR determina l'accesso del gruppo al progetto
didattico; la RA ne sancisce il completamento.
L'ammissione alla RA è condizionata al sostenimento della RQ,
con esito almeno sufficiente.
Le revisioni di progresso non sono bloccanti, ovvero il gruppo potrà continuare il proprio lavoro di progetto, ma un eventuale esito negativo comporterà una penalità di punteggio commisurata alla gravità dell'insufficienza, da scontare nella valutazione finale.
La partecipazione di un gruppo a una revisione di progetto si svolgerà come segue:
Liste di iscrizione alle prove scritte individuali verranno
pubblicate sul sistema UniWeb
nelle due settimane precedenti l'appello corrispondente.
Per la partecipazione ai compitini che precedono le prove scritte
"ufficiali", gli studenti dovranno rivolgersi al docente.