logo

Ingegneria del Software mod. A
Corso di Laurea in Informatica
Università di Padova, a.a. 2015/16

Docente: Tullio Vardanega

(Ultimo aggiornamento: 17 febbraio 2016 ore 14:30
[pubblicato esito RR]
[documento collaborativo per la formazione dei gruppi di progetto]

Presentazione del corso

Obiettivi

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 nella prima parte del II semestre.

Congiuntamente, i due moduli forniscono allo studente strumenti metodologici per e l'opportunità di intraprendere con successo un impegnativo progetto didattico di sviluppo software da svolgersi in gruppo, secondo canoni rigorosi di conduzione e di gestione del rapporto cliente-fornitore.

Il modulo A del corso 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 metologiche 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 modulo B.

Il progetto didattico si svolgerà secondo il seguente calendario:

A partire da questa data, gli studenti saranno chiamati a costituirsi in gruppi di progetto, secondo regole fissate dal docente e illustrate con congruo anticipo, al fine di competere per l'aggiudicazione del capitolato di interesse. L'aggiudicazione di un appalto trasforma i gruppi vincitori dell'appalto in fornitori ufficiali, impegnati a consegnare al docente il prodotto proposto entro i tempi e i costi specificati nella corrispondente offerta tecnico-economica.
Lo svolgimento del progetto didattico verrà accompagnato da specifiche revisioni di avanzamento di progetto, secondo la prassi adottata in noti standard internazionali.
Per arrivare alla fine del progetto didattico, ogni gruppo dovrà sostenere e superare tre successive revisioni di avanzamento, l'ultima delle quali includerà il collaudo del prodotto sviluppato. Ogni gruppo fornitore potrà collocare la propria serie di revisioni di avanzamento nelle date di calendario sotto riportate:

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, comprensivo dei due suoi moduli, "pesa" per complessivi 13 CFU, ripartiti come segue:

Propedeuticità obbligatorie strette

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.

Materiale 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:

  1. 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:

Calendario delle lezioni

Settimana

Data

Lezione

Docente

Contenuto

Tipo

SWEBOK

1
 1 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

 8 ottobre
(14:15-16:00)

A.2

Vardanega

Processi software
Per approfondire #3: Origine, formazione ed evoluzione degli standard di processo
Per approfondire #4: Lo standard ISO/IEC 12207:1995
Per approfondire #5: Lo standard ISO/IEC 12207:2008

L

§9

3

 12 ottobre

A.3

Vardanega

L

15 ottobre
A.4
Vardanega

Il ciclo di vita del software
Per approfondire #6: Il modello a spirale
Per approfondire #7: Le schede SEMAT (1, 2)

L

4
19 ottobre

A.E1

Cardin

UML
Introduzione
Diagrammi dei casi d'uso

E


22 ottobre
(1C150
09:30-11:15)

A.5
Vardanega

Gestione di progetto
Per approfondire #8: Rapporto dello Standish Group sul Progetto CHAOS
Per approfondire #9: Barry W. Bohem su 40 anni di modelli di stima dei costi software
Per approfondire #10: Gestione delle persone
Per approfondire #11: Diagrammi Gantt e PERT
Per approfondire #12: Modello di descrizione di Work Package

L
§8
5
26 ottobre A.E2 Cardin
UML
Diagrammi delle classi
Diagrammi dei package
E

29 ottobre

A.6
Vardanega

Continuazione lezione A.5

L

6
2 novembre
A.7
Vardanega
Amministrazione di progetto
Per approfondire #13: Strumenti di collaborazione
Flipped classroom [Vedere diapositiva 21]
L
§6-7,10
5 novembre
(1C150
09:30-11:15)
A.P1
Vardanega
Presentazione dei capitolati d'appalto L

6 novembre
(1C150
13:30-14:30)
A.P2 Red Babel Seminario tecnologico: Node.js (Esempi) E
7
9 novembre
A.E3
Cardin
UML
Diagrammi di sequenza
Diagrammi di attività
E

12 novembre
A.8
Vardanega

Ingegneria dei requisiti
Per approfondire #17: Struttura commentata del documento di specifica dei requisiti secondo IEEE 830-1998

L §2
13 novembre
(1C150
13:30-14:30)
A.P3 Mivoq
Seminario tecnologico: Fiware E
8 18 novembre
(1C150
13:30-14:30)
A.P4 Miriade Seminario tecnologico: Dispositivi BLE (beacon) E
19 novembre
(1C150
13:30-14:30)
A.P5 Zucchetti Seminario tecnologico: JavaScript E
20 novembre
(1C150
13:30-14:30)
A.P6 Cardin Seminario tecnologico: Scala/Akka E
9
23 novembre A.P7 Vardanega Regole del progetto didattico
Regolamento Capitolati
Regolamento Organigramma
Regolamento Documenti: tema della flipped classroom del 7/1/16
L
26 novembre
A.E4
Cardin

Design pattern strutturali: Decorator, Proxy, Facade, Adapter

E

27 novembre
(1C150
13:30-14:30)
A.P8 Zero12 Seminario tecnologico: AWS E
10
30 novembre
A.E5
Cardin
Design pattern creazionali: Singleton, Builder, Abstract Factory
E

4 dicembre
(1C150
13:30-14:30)
A.P9 Bertazzo Seminario tecnologico: Integrazione continua

Questionario valutazione didattica
Avvisi importanti
11
10 dicembre A.9
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
12
14 dicembre
A.E6
Cardin
Design pattern comportamentali: Observer, Template Method, Command, Strategy, Iterator
E

17 dicembre
(13:30-16:15)
A.10 Vardanega

Qualità di prodotto
Qualità di processo

Per approfondire #15:
Elementi dello standard ISO 9000
Per approfondire #16: Sintesi di ISO IEC 90003:2004

L §11
15
7 gennaio
(13:30-16:15)
A.11
Vardanega
Documentazione
Flipped classroom: studiare e presentazione proposte di struttura e contenuto dei documenti mostrati a pagina 17 delle diapositive di questa lezione
L
§8
16
11 gennaio
B.12
Vardanega Continuazione lezione A.10 L
 
12 gennaio
(1C150
9:30-11:15)
B.13 Vardanega Verifica e validazione: introduzione
Per approfondire #24: Fagan Inspection & Walkthrough
Per approfondire #25: Bertrand Meyer sul testing
L §5
14 gennaio
(1C150
9:30-11:15)
B.14
Vardanega Verifica e validazione: analisi statica
Per approfondire #26: Effetti indesiderabili del dynamic binding
L
17 18 gennaio B.15
Vardanega Verifica e validazione: analisi dinamica L
18 gennaio
(1C150
13:30-14:30)
--- Vardanega Incontro informativo sugli stage obbligatori -


16 febbraio 2016
(1C150
09:30-13:30)

B.P10

Revisione dei Requisiti (RR)
Prerequisito per sostenere la revisione sarà l'aver costituito i gruppi di progetto, aver distribuito i ruoli al loro interno, e aver presentato tutta la documentazione d'ingresso richiesta entro il termine tassativo:

ore 15:00 di venerdì 22 gennaio 2016

Regole di partecipazione alle revisioni

Esito RR

Note pratiche

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:

Regole di partecipazione alle revisioni di avanzamento di progetto

Le revisioni di avanzamento progetto si dividono in:

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:

Calendario degli appelli d'esame (congiunto con mod. B)

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.

Valid HTML 4.0
          Transitional