|
Corso
di Ingegneria del Software mod. A |
(Ultimo aggiornamento: 12 gennaio 2011 ore 23:50)i>
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.
A circa 2/3 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 (p.es., ECSS-E-40A per il dominio spaziale, sinteticamente raffigurata da figura 3 a pagina 18).
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.
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 altresì consigliati i seguenti testi:
Software Engineering (8th
edition)
Ian Sommerville
Pearson Education | Addison-Wesley
Settimana |
Data |
Lezione |
Docente |
Contenuto |
Tipo |
SWEBOK |
1 |
3 ottobre |
Assenza del docente |
||||
4 ottobre |
1 |
Vardanega |
Premesse al corso |
L |
|
|
6 ottobre |
2 |
Vardanega |
Processi software |
L |
§9 |
|
2 |
10 ottobre |
3 |
Vardanega |
Il
ciclo di vita del software |
L |
§9 |
11 ottobre |
4 |
Vardanega |
Gestione
di progetto |
L |
§8 |
|
13 ottobre | 5 |
Vardanega |
Amministrazione
di progetto (parte 1) |
L |
§6-7 |
|
3 |
17 ottobre | E1 | Cardin |
UML: Introduzione. Diagrammi dei casi d'uso | E |
|
18 ottobre |
6 |
Vardanega |
Amministrazione
di progetto (parte 2) |
L |
||
P0 |
Per approfondire #14: Strumenti
di gestione del ciclo di vita del software
(Ambiente Java, Guida) Per approfondire #15: Strumenti di gestione del ciclo di vita del software [8MB] (Ambiente Microsoft) |
|||||
20 ottobre |
7 |
Vardanega |
Ingegneria
dei requisiti |
L |
§2 | |
4 |
24 ottobre |
8 |
Vardanega |
L |
§11 |
|
25 ottobre |
E2 |
Cardin |
UML: Diagrammi delle classi e
degli oggetti Esercizi: diagrammi casi d'uso;diagrammi delle classi |
E |
||
27 ottobre |
Assenza del docente |
|||||
5 |
31 ottobre |
|||||
1 novembre |
||||||
3 novembre |
||||||
6 |
7 novembre |
E3 | Cardin |
UML:
Diagrammi di sequenza. Diagrammi di attività |
E |
|
8 novembre |
9 |
Vardanega |
Qualità
del processo |
L |
||
10 novembre |
10 | Vardanega |
Progettazione (parte 1) | L |
§3 | |
7 |
14 novembre |
11 | Vardanega |
Progettazione
(parte 2) Per approfondire #19: Fan-in e fan-out Per approfondire #20: Definizioni di architettura software Per approfondire #21: Christopher Alexander sulla teoria dei pattern |
L |
§3 |
15 novembre |
E4 | Cardin | Introduzione
ai design
pattern Esercizi: diagrammi di sequenza |
E | ||
16 novembre | 12 |
Vardanega |
Documentazione | L | §8 | |
17 novembre | 13 |
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 | |
8 |
21 novembre |
E5 | Cardin |
UML: Diagrammi
dei package |
E |
|
P1 |
Cardin |
Esercizi: Studio di fattibilità e analisi dei requisiti | P |
|||
22 novembre |
14 |
Vardanega |
Verifica
e validazione: introduzione Per approfondire #25: Fagan Inspection & Walkthrough Per approfondire #26: Bertrand Meyer sul testing |
L |
§5 | |
23 novembre |
15 |
Vardanega |
Verifica e validazione: analisi statica Per approfondire #27: Effetti indesiderabili del dynamic binding |
L |
||
24 novembre |
P2 |
Vardanega |
Regole del progetto
didattico |
P |
||
9 |
28 novembre (3h) |
P3 |
Vardanega |
Presentazione
dei capitolati d'appalto |
P |
|
29 novembre |
Assenza del docente |
|||||
30 novembre |
||||||
1 dicembre |
||||||
10 |
5 dicembre (3h) |
16 |
Vardanega |
Recupero, ricapitolazione,
esercizi |
L |
|
|
10
gennaio 2012 |
P3 |
Revisione dei Requisiti
(RR) ore 18:00 di martedì 20 dicembre
2011
|
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 1A/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ì 12:00 - 13: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.