|
Ingegneria
del Software mod. A |
(Ultimo aggiornamento: 16
febbraio 2015 ore 20:00)
L'insegnamento di Ingegneria del Software si sviluppa su due moduli, mod. A e mod. B, operanti in regime di stretta integrazione, collocati prevalentemente nel I semestre, con completamento nel II semestre.
Congiuntamente, i due moduli intendono fornire allo studente
gli strumenti metodologici per e l'opportunità di intraprendere un
impegnativo progetto software didattico da
svolgersi in gruppo e secondo canoni rigorosi di conduzione e di gestione
del rapporto cliente-fornitore.
Il modulo A del corso si
propone di fornire allo studente strumenti intellettuali per comprendere e
sistematizzare l'insieme di conoscenze comprese nella disciplina detta Software
Engineering. A tal fine, il corso illustra ciascuna delle aree
di conoscenza rilevanti nell'ambito, correlandovi le regole
metologiche che gli studenti dovranno seguire nello svolgimento del
progetto didattico, la cui realizzazione effettiva avverrà prevalentemente
nel modulo B.
Entro il primo terzo del modulo A il docente pubblicherà alcuni capitolati
d'appalto per la realizzazione di specifici prodotti informatici.
A seguito di ciò, gli studenti saranno chiamati a costituire gruppi
di progetto, secondo regole fissate dal docente e rese note con
congruo anticipo, per partecipare alla gara d'appalto relativa al
capitolato che il gruppo avrà scelto in base a criteri di fattibilità e
interesse.
Nel corso del modulo A ogni gruppo dovrà predisporre un'offerta tecnico-economica da presentare al docente in occasione della Revisione dei Requisiti, che segna l'inizio formale delle attività di progetto. L'accettazione dell'offerta comporterà il superamento di tale revisione e l'obbligo da parte del gruppo di fornire il prodotto proposto nei tempi pattuiti.
La conduzione del progetto didattico verrà accompagnata da specifiche revisioni di progresso che seguono la logica adottata in rilevanti standard internazionali.
L'insieme dei due moduli "pesa" per complessivi 13 CFU,
ripartiti nel modo seguente: 6 di lezioni frontali per il modulo A, tutte
collocate nel I semestre; 3 di lezioni frontali per il modulo B, ripartite
a metà tra I e II semestre; 4 dedicati allo svolgimento del progetto,
prevalentemente collocate nel II semestre, che comportano un impegno
individuale di circa 100 ore produttive.
L'accettazione finale da parte del docente del prodotto
software sviluppato nel progetto soddisferà una delle due condizione
necessarie al superamento dell'esame di Ingegneria del Software. L'altra
condizione comporta il superamento di una prova scritta individuale. La
valutazione numerica assegnata in sede di accettazione varrà 60% del voto
complessivo. Il rimanente 40% verrà determinato dalla valutazione della
prova scritta.
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à l'ammissione alla Revisione dei Requisiti e conseguentemente lo svolgimento del progetto che è parte integrante dell'esame di profitto del corso.
Il materiale didattico presentato durante le lezioni sarà progressivamente pubblicato, in formato elettronico, tramite collegamento alla lezione corrispondente.
Il principale testo di riferimento bibliografico di supporto al corso è il seguente:
Guide
to the Software Engineering Body of Knowledge
IEEE Computer Society. Software Engineering Coordinating Committee
(Le aree di conoscenza corrispondenti agli argomenti
trattati a lezione sono riferite nel calendario delle lezioni)
Sono inoltre consigliati i seguenti testi:
Software Engineering
(9th 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 |
Tipo |
SWEBOK |
1 |
2 ottobre |
A.1 |
Vardanega | Premesse al
corso Per approfondire #1: No Silver Bullet. Essence and Accidents of Software Engineering Per approfondire #2: IEEE Code of Ethics |
L |
|
2 |
6 ottobre |
A.2 |
Vardanega |
Processi software |
L |
§9 |
7 ottobre |
A.3 |
Vardanega |
L |
|||
3 |
13 ottobre |
A.4 |
Vardanega |
Il ciclo
di vita del software |
L |
|
14 ottobre |
A.5 |
Vardanega |
Continuazione lezione A.4 |
L |
||
16 ottobre | A.6 |
Vardanega |
Gestione
di progetto |
L |
§8 | |
4 |
20 ottobre | A.E1 | Cardin |
UML Introduzione Diagrammi dei casi d'uso |
E |
|
21 ottobre |
A.7 |
Vardanega |
Continuazione lezione A.6 |
L |
|
|
23 ottobre |
A.8 |
Vardanega |
Amministrazione
di progetto |
L |
§6-7,10 | |
5 |
27 ottobre |
A.E2 |
Cardin |
UML Diagrammi delle classi Diagrammi dei package |
E |
|
30 ottobre | A.P1 |
Vardanega |
Presentazione dei capitolati d'appalto | L |
|
|
6 |
3 novembre | A.P2 | Bertazzo | Seminario sull'integrazione continua Per approfondire #14: Strumenti di gestione del ciclo di vita del software: Ambiente Java Ambiente Microsoft [8MB] |
||
4 novembre |
A.E3 |
Cardin |
UML Diagrammi di sequenza Diagrammi di attività |
E |
|
|
5 novembre (11:30-13:15 |
A.P3 | CoffeeStrap | Seminario tecnologico: node.js (esempi) | |||
6 novembre | A.9 |
Vardanega |
Continuazione lezione A.8 |
L |
||
7 |
10 novembre (4h) |
A.E4 | Cardin |
Introduzione ai design pattern | E |
|
A.10 |
Vardanega |
Qualità
di prodotto |
L | §11 | ||
11 novembre |
A.11 |
Vardanega |
Continuazione lezione A.10 |
L |
|
|
13 novembre |
A.P4 |
MongoDB |
Seminario tecnologico: MongoDB |
|
|
|
8 |
17 novembre |
A.E5 |
Cardin | UML Esercizi |
E |
|
18
novembre
(11:30-13:15 |
A.P5 | Zucchetti | Seminario tecnologico: Javascript | |||
20 novembre |
A.E6 |
Vardanega |
Ingegneria
dei requisiti |
L |
§2 | |
9
|
24 novembre | A.12 |
Vardanega |
Progettazione Per approfondire #18: Fan-in e fan-out Per approfondire #19: Definizioni di architettura software Per approfondire #20: Christopher Alexander sulla teoria dei pattern |
L | §3 |
25 novembre |
A.P6 | Vardanega | Regole
del progetto didattico Regolamento Capitolati Regolamento Organigramma Regolamento Documenti |
L |
||
10 |
1 dicembre | A.13 |
Vardanega |
Documentazione | L |
§8 |
Questionario valutazione didattica | ||||||
11 |
11 dicembre |
A.14 |
Vardanega | Strategie di
produzione Per approfondire #21: Implicazioni del paradigma OOP sul software critico Per approfondire #22: Software dependability Per approfondire #23: Stili, scelte e linguaggi di programmazione Introduzione Rappresentazione dei numeri e trappole sintattiche Il sistema dei tipi Strutture dati e passaggio di parametri |
L |
§4 |
12 |
15 dicembre | B.E7 |
Cardin |
Introduzione
ai design pattern Pattern strutturali: Decorator, Proxy, Facade, Adapter |
E |
|
16 dicembre |
B.15 |
Vardanega | Verifica e
validazione: introduzione Per approfondire #24: Fagan Inspection & Walkthrough Per approfondire #25: Bertrand Meyer sul testing |
L |
§5 |
|
18 dicembre |
B.16 |
Vardanega |
Continuazione lezione B.15 | L |
||
14 |
8 gennaio | B.17 |
Vardanega | Verifica e
validazione: analisi statica Per approfondire #26: Effetti indesiderabili del dynamic binding |
L |
|
15 |
12 gennaio | B.E8 |
Cardin | Introduzione ai design
pattern Pattern creazionali: Singleton, Builder, Abstract Factory |
E |
|
13 gennaio | B.18 |
Vardanega | Verifica e validazione: analisi dinamica | L |
§5 | |
15 gennaio | B.19 | Vardanega | L | |||
16 |
19 gennaio | B.E9 |
Cardin | Introduzione ai design
pattern Pattern comportamentali: Observer, Template Method, Command, Strategy, Iterator |
E |
|
20 gennaio | B.20 | Vardanega | Recupero e ripasso generale | E | ||
22 gennaio | B.E10 |
Cardin | Introduzione ai design
pattern Pattern architetturali: Dependency Injection |
E |
||
|
16 febbraio 2015 14:30-17:30 1C150 |
B.P7 |
Revisione dei Requisiti
(RR) ore 15:00 di venerdì 23 gennaio
2015
|
Come indicato in calendario, il modulo consterà di lezioni di tre tipi:
L : Lezione o seminario - docente: T Vardanega
E : Esercitazione - docente: (R.
Cardin)
P : Progetto didattico - docente/committente: T Vardanega
Le lezioni indicate in calendario si terranno in aula 1C/150 con l'orario indicato sul sito del CCS di Informatica.
Il ricevimento studenti si tiene per appuntamento in stanza #400 il:
lunedì 11:30 - 12:30
mercoledì 09:00 - 11:00
Tutte le revisioni contribuiscono a determinare il voto d'esame di ciascuno studente, che sarà basato sulla media pesata della valutazione conseguita dal proprio gruppo di progetto in ciascuna revisione, con una quota di ponderazione legata al rapporto tra l'impegno medio atteso e l'impegno effettivo documentato dallo studente. Il voto d'esame individuale sarà ulteriormente determinato dalla valutazione di una prova scritta individuale compendiata da un breve colloquio orale.
Le revisioni formali sono bloccanti:
la RR regola l'accesso del gruppo al progetto; la
RA ne sancisce il completamento.
L'ammissione alla RA è condizionata al superamento della RQ.
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 all'esame (del quale sono previsti 5 appelli, calendarizzati a partire dalla metà del II semestre e la fine dell'anno accademico verranno pubblicate sul sistema UniWeb nelle due settimane precedenti l'appello corrispondente.