|
Ingegneria
del Software mod. A |
(Ultimo aggiornamento: 08 gennaio
2014 ore 19:35)
Il corso opera in regime di stretta integrazione con il
corso Ingegneria del Software mod. B,
che ha luogo nel trimestre seguente. 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 relazione 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 dell'Ingegneria
del Software. 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. L'accettazione dell'offerta comporterà il superamento di tale revisione e l'obbligo da parte del gruppo di fornire il prodotto pattuito 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; 3 di
lezioni frontali per il modulo B; 4 dedicati allo svolgimento del
progetto, che dunque comporterà un impegno individuale di circa 100 ore
produttive.
L'accettazione 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 |
1 ottobre |
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 ottobre |
2 |
Vardanega |
Processi software |
L |
§9 |
|
3 ottobre |
3 |
Vardanega |
L |
|||
3 |
14 ottobre |
4 |
Vardanega |
Il
ciclo di vita del software |
L |
|
15 ottobre |
5 |
Vardanega |
Gestione
di progetto |
L |
§8 |
|
16 ottobre | 6 |
Vardanega |
Gestione di progetto (parte
2) |
L |
||
4 |
21 ottobre | E1 | Cardin |
UML Introduzione Diagrammi dei casi d'uso |
E |
|
22 ottobre |
7 |
Vardanega |
Amministrazione
di progetto |
L |
§6-7,10 | |
23 ottobre |
8 |
Vardanega |
Ingegneria
dei requisiti |
L |
§2 | |
5 |
28 ottobre |
E2 |
Cardin |
UML Diagrammi delle classi Esercizi Diagrammi delle classi |
E |
|
31 ottobre | P1 |
Vardanega |
Presentazione dei capitolati d'appalto | L |
|
|
6 |
4 novembre |
E3 |
Cardin |
UML Diagrammi di sequenza Diagrammi di attività Esercizi Diagrammi dei casi d'uso |
E |
|
7 |
11 novembre |
E4 | Cardin |
UML Introduzione ai design pattern Esercizi Diagrammi delle classi Diagrammi di sequenza e di attività |
E |
|
12 novembre |
9 |
Vardanega |
L |
§11 |
||
13 novembre | 10 |
Vardanega |
Qualità
del processo Per approfondire #17: Elementi dello standard ISO 9000 Per approfondire #18: Sintesi di ISO IEC 90003:2004 |
L |
|
|
14 novembre |
11 |
Vardanega |
Continuazione lezioni 9 e 10 | L |
|
|
8 |
Questionario valutazione
didattica |
|||||
18 novembre |
E5 |
Cardin | UML Diagrammi dei package Esercizi Analisi dei requisiti |
E |
|
|
19 novembre |
12 |
Vardanega |
Progettazione |
L |
§3 | |
20 novembre | 13 |
Vardanega |
Documentazione | L | §8 | |
21 novembre (16-17, 1C150) |
P2 |
Zucchetti |
Seminario tecnologico: JavaScript |
|
|
|
9 |
25 novembre (11:30-13:15) |
P3 | Vardanega | Regole
del progetto didattico Regolamento: Capitolati Regolamento: Organigramma Regolamento: Documenti |
L |
|
26 novembre | 14 |
Vardanega |
Strategie di
produzione Per approfondire #22: Implicazioni del paradigma OOP sul software critico Per approfondire #23: Software dependability Per approfondire #24: 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 | |
27 novembre |
15 |
Vardanega | Verifica e
validazione: introduzione Per approfondire #25: Fagan Inspection & Walkthrough Per approfondire #26: Bertrand Meyer sul testing |
L |
§5 | |
27 novembre (16:30-17:30, 2BC60) |
P4 |
FunGoStudios | Seminario tecnologico:
actor pattern con Ruby |
|
|
|
28 novembre (16-17, 1BC45) |
P5 |
CoffeeStrap |
Seminario tecnologico: node.js | |
|
|
29 novembre (16-17, 1C150) |
P6 |
Student
helpers |
Seminario
tecnologico: Scala e Akka (p0,
p1, p2) |
|||
10 |
2 dicembre | E6 |
Bertazzo |
Seminario
sull'integrazione continua |
|
|
3 dicembre |
16 |
Vardanega | Verifica
e validazione: analisi statica Per approfondire #28: Effetti indesiderabili del dynamic binding |
L |
§5 | |
4 dicembre |
17 |
Vardanega |
Recupero e ricapitolazione |
L |
|
|
|
8 gennaio 2013 14:30-18:00 aula 1BC50 |
P3 |
Revisione dei Requisiti
(RR) ore 15:00 di venerdì 20
dicembre 2013
|
Come indicato in calendario, il modulo consterà di lezioni di tre tipi:
L : Lezione o seminario - docente: T Vardanega
E : Esercitazione - docente: (da
definire)
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 tra la fine del mod. B e la sessione di recupero estivo) verranno pubblicate sul sistema UniWeb nelle due settimane precedenti l'appello corrispondente.