|
Ingegneria
del Software |
Ultimo aggiornamento: 2 agosto
2017 ore 13:35
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 canoni rigorosi di metodo 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 di Ingegneria del Software. L'altra condizione richiede il superamento di una prova scritta individuale, che ciascuno studente potrà sostenere nelle date sopra indicate. Per ogni membro del gruppo valutato 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 "pesa" per complessivi 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
(Versione 2004)
(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 |
1 |
3 ottobre |
T1 |
Vardanega | Introduzione Per approfondire #1: No Silver Bullet. Essence and Accidents of Software Engineering Per approfondire #2: IEEE Code of Ethics |
|
6 ottobre |
T2 |
Vardanega |
Processi software |
§9 |
|
7 ottobre |
T3 |
Vardanega |
Continuazione lezione T3 |
||
2
|
10 ottobre |
T4 |
Vardanega |
Il ciclo di vita del software |
|
13 ottobre |
T5 |
Vardanega |
Gestione di progetto |
§8 | |
14 ottobre | T6 | Vardanega | Amministrazione di progetto Per approfondire #13: Strumenti di collaborazione Flipped classroom [studio autonomo e presentazione in aula di strumenti di: pianificazione, coordinamento, configurazione, versionamento] |
§6-7,10 | |
3 | 17 ottobre | E1 | Cardin | UML Introduzione Diagrammi dei casi d'uso |
|
20 ottobre | T7 | Vardanega | Analisi dei requisiti Per approfondire #14: Struttura commentata del documento di specifica dei requisiti secondo IEEE 830-1998 |
§2 |
|
21 ottobre | T8 | Vardanega | Continuazione lezione T7 | ||
4 |
24 ottobre | E2 | Cardin |
UML Diagrammi delle classi Diagrammi dei package |
|
27 ottobre |
T9 |
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 |
§3 | |
28 ottobre | T10 | Vardanega | Continuazione lezione T9 | ||
5 | 3 novembre | T11 | Vardanega | Documentazione Flipped classroom [studio autonomo e presentazione di possibili strutture dei principali documenti di progetto: - Analisi dei Requisiti - Piano di Qualifica - Norme di Progetto] |
§8 |
4 novembre | P1 |
Vardanega |
Presentazione dei capitolati d'appalto | |
|
6 |
7 novembre |
E3 |
Cardin |
UML Diagrammi di sequenza Diagrammi di attività |
|
7 novembre (13:30-14:30 1C150) |
P2 | Zucchetti | Seminario tecnologico: JavaScript | ||
8 novembre (13:30-14:30 1C150) |
P3 | italianaSoftware | Seminario tecnologico: la
rivoluzione dei microservizi Presentazione Jolie Esempi |
||
9 novembre (13:30-14:30 1C150) |
P4 | RedBabel | Seminario tecnologico: Node.js
e la programmazione asincrona Esempi |
||
11 novembre | P5 | Vardanega | Regole del progetto didattico Regolamento Capitolati Regolamento Organigramma Possibile struttura documenti: - Norme di Progetto - Analisi dei Requisiti - Piano di Qualifica - Piano di Progetto |
||
7 |
14 novembre | E4 | Cardin | Design
pattern strutturali: Decorator, Proxy, Facade, Adapter |
|
14 novembre (13:30-14:30 1C150) |
P6 | RedBabel | Seminario tecnologico: Meteor e Rocket.Chat | ||
15 novembre (13:30-14:30 1C150) |
P7 | Zero12 | Seminario tecnologico: AWS e MongoDB | ||
16 novembre (13:30-14:30 1C150) |
P8 | Zucchetti | Seminario tecnologico: uso avanzato dei Design Pattern | ||
17 novembre | T12 | Vardanega |
§11 | ||
17 novembre (13:30-14:30 1C150) |
P9 | Mivoq | Seminario tecnologico: Git
worklows esempio comandi Git forum collaborativo |
||
18 novembre | T13 | Vardanega | Continuazione lezione T12 | ||
8 |
21 novembre |
E5 | Cardin |
Design pattern
creazionali: |
|
24 novembre | T14 | Vardanega | Qualità di processo Per approfondire #18: Elementi dello standard ISO 9000 Per approfondire #19: Sintesi di ISO IEC 90003:2004 |
||
Questionario valutazione didattica | |||||
9 |
28 novembre |
E6 |
Cardin |
Design
pattern comportamentali: Observer,
Template Method, Command, Strategy, Iterator |
|
30 novembre (13:30-14:30 1C150) |
P10 | Bertazzo | Seminario tecnologico: integrazione continua | ||
10 | 5 dicembre | E7 | Cardin | Esercitazione su preparazione AR | |
11 |
12 dicembre | E8 | Cardin | Design
pattern architetturali: Dependency Injection |
|
14 dicembre | P11 | Mivoq | Seminario tecnologico: Git
worklows (parte 2) |
||
15 dicembre |
T15 | Vardanega |
Verifica e validazione:
introduzione |
§5 | |
16 dicembre | T16 | Vardanega | Verifica e validazione: analisi statica |
||
13 |
9 gennaio | E9 | Cardin | Design pattern architetturali:
MVC, MVP e MVVM |
|
14 |
16 gennaio | E10 | Cardin | Stili architetturali |
|
19 gennaio | T17 |
Vardanega | Verifica e validazione: analisi dinamica Per approfondire #22: Effetti indesiderabili del dynamic binding |
||
20 gennaio | Vardanega | Incontro informativo sugli stage curricolari | |||
|
RR 24 gennaio |
P12 |
Revisione dei Requisiti
(RR) ore 15:00 di mercoledì 11
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.