|
Corso di Ingegneria del Software
mod. A |
(Ultimo
aggiornamento:
07 gennaio 2010
ore 18:40)
[inserito
esito RR]
Il corso opera in regime di stretta
integrazione con il corso Ingegneria
del
Software
mod.
B, che ha luogo nel trimestre
successivo. Congiuntamente, i due corsi forniscono allo studente
gli
strumenti metodologici per e l'opportunità di condurre 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 gli
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
categorizzate nel testo di riferimento,
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 metà del modulo il docente
emetterà 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 strategico.
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 previsti.
La conduzione del progetto didattico verrà accompagnata da specifiche revisioni formali che seguono la logica adottata come standard nell'ambito dell'industria spaziale europea, come descritta nel documento ECSS-E-40A e sinteticamente raffigurata da figura 3 a pagina 18 dello stesso.
L'intero corso (mod. A+B) "pesa" 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.
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 scritto.
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.
(http://www.swebok.org)
Sono altresì consigliati alcuni utili testi di consultazione:
Software
Engineering (8th edition)
Ian Sommerville
Pearson Education | Addison-Wesley
Settimana |
Data |
Lezione |
Docente |
Contenuto |
Tipo |
SWEBOK |
1 |
1 ottobre |
1 |
Vardanega |
Premesse
al
corso |
L |
|
2 |
6 ottobre |
2 |
Vardanega |
Processi software
(parte
1) |
L |
§9 |
7 ottobre |
Assenza
del
docente |
|
|
|||
8 ottobre |
||||||
3 |
13 ottobre |
3 |
Vardanega |
Processi software (parte 2) |
L |
§9 |
14 ottobre |
4 |
Vardanega |
Seminario |
L |
||
15 ottobre |
5 |
Vardanega |
Il
ciclo di vita del software |
L |
||
Strumenti
di
gestione
del
ciclo
di
vita
del software
(Ambiente Java) Guida |
§10 | |||||
4 |
20 ottobre |
6 |
Vardanega |
Gestione
di progetto |
L |
§7-8 |
21 ottobre |
E1 |
Conte |
UML:
introduzione |
E |
||
22 ottobre |
7 |
Vardanega |
Amministrazione
di progetto (parte 1) |
L |
§7-8 |
|
Strumenti
di
gestione
del
ciclo
di
vita
del software
[8MB] (Microsoft Visual Studio Team System e Microsoft Team Foundation Server) |
§10 | |||||
5 |
27
ottobre |
8 |
Vardanega |
Amministrazione
di
progetto (parte 2) Per approfondire #9: Modello di descrizione di Work Package |
|
§7-8 |
28 ottobre |
E2 |
Conte |
UML:
Diagrammi
dei casi d'uso UML: Diagrammi delle classi e degli oggetti (parte 1) Per sorridere: ingegneria del software? |
E |
||
29 ottobre |
9 |
Vardanega | Lezione di recupero | L |
||
6 |
3 novembre |
10 |
Vardanega |
Ingegneria dei requisiti (parte 1) |
L |
§2 |
4 novembre |
E3 |
Conte |
UML: Diagrammi delle classi e degli
oggetti
(parte 2) |
E |
||
5 novembre |
11 |
Vardanega |
Presentazione
STAGE-IT
2010 Seminario SIAGAS |
|
|
|
7 |
10 novembre |
12 |
Vardanega | Ingegneria
dei
requisiti (parte 2) Per approfondire #10: Struttura commentata del documento di specifica dei requisiti secondo IEEE 830-1998 |
L |
§2 |
11 novembre |
13 |
Vardanega |
L |
§11 |
||
12 novembre |
P1 |
Vardanega |
Regole del
progetto
didattico |
PD |
|
|
8 |
17 novembre |
P2 |
Vardanega |
Presentazione
dei
capitolati
d'appalto |
PD |
|
18 novembre |
E4 |
Conte |
E |
|||
19 novembre |
14 |
Vardanega |
Qualità
del
processo |
L |
§11 |
|
9 |
24 novembre |
15 |
Vardanega |
Progettazione
(parte 1) |
L |
§3-4 |
P3 |
Vardanega | Incontro
con
proponenti (aula 1C/150) ore 14:00 - C02 ore 15:00 - C05 ore 15:45 - C04 |
PD |
|||
25 novembre |
16 |
Vardanega |
Progettazione
(parte
2) Per approfondire #13: Fan-in e fan-out Per approfondire #14: Definizioni di architettura software Per approfondire #15: Christopher Alexander sulla teoria dei pattern |
L |
§3-4 | |
26 novembre |
17 |
Vardanega |
L |
§8 |
||
10 |
1 dicembre |
18 |
Vardanega |
Metodiche
standard di sviluppo industriale |
L |
§8 |
2 dicembre |
19 |
Vardanega |
Verifica
e
validazione: introduzione Per approfondire #18: Fagan Inspection & Walkthrough Per approfondire #19: Bertrand Meyer sul testing |
L |
§5 |
|
3 dicembre |
20 |
Vardanega |
Verifica
e
validazione:
analisi
statica Per approfondire #20: Effetti indesiderabili del dynamic binding |
L |
||
Per approfondire #21:
Stili, scelte e linguaggi
di programmazione Introduzione Rappresentazione dei numeri e trappole sintattiche Il sistema dei tipi Strutture dati e passaggio di parametri |
||||||
|
I
convocazione: 17 dicembre (14:30 - 18:30) aula 2BC/60 II convocazione: 7 gennaio 2010 (14:30 - 18:30) aula 1AD/100 |
P3 |
Revisione dei
Requisiti
(RR) ore 16:00 di
mercoledì 9 dicembre 2009
|
Come indicato in calendario, il modulo consterà di lezioni di tre tipi:
L : Lezione o seminario - docente: T Vardanega
E : Esercitazione - docente: R Conte
P : Progetto didattico - docenti/committenti: T Vardanega e R Conte
Le lezioni indicate in calendario si terranno con l'orario e la collocazione seguenti:
lunedì 9:30 - 11:15 in aula 1C/150
martedì 9:30 - 11:15 in aula 1C/150
mercoledì 9:30 - 11:15 in aula 1C/150
Il ricevimento studenti si tiene per appuntamento in stanza #409 il:
martedì 12:00 - 13:00
giovedì 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 informali 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. Una revisione a scelta tra RPP e RPD è
opzionale, la scelta è libera e a carico del singolo gruppo di
progetto. Tale scelta va specifica nell'offerta.
La partecipazione di un gruppo a una revisione di progetto si svolgerà come segue:
Liste di iscrizione all'esame verranno pubblicate sul sistema SIS nelle due settimane precedenti l'appello corrispondente.