Istruzioni

per il Progetto di Ingegneria del Software

e per la formazione dei gruppi di progetto

Il Corso di Ingegneria del Software prevede un progetto di gruppo obbligatorio per la realizzazione
di un sistema software.

Il progetto prevede la produzione della documentazione di analisi e di progettazione di alto livello
per lintero sistema e la documentazione relativa alla progettazione di basso livello, lo sviluppo del
codice e la documentazione di pianificazione ed esecuzione del testing per almeno uno dei
sottosistemi.

Il sistema software dovr avere una architettura three-tier con un client che implementa il livello
di presentazione, un server che implementa la logica applicativa e un DBMS per la gestione dei
dati. I tre livelli dovranno essere potenzialmente installabili su tre macchine diverse.

I documenti da produrre ai fini del progetto sono i seguenti:

Problem Statement
Requirements Analysis Document
System Design Document
Object Design Document
Test Plan
Test Case Specification
Test Execution Report

I template dei documenti sono disponibili nel libro di testo e sulla pagina web dellautore:
https://wwwbruegge.in.tum.de/lehrstuhl_1/component/content/article/217-OOSE

Il progetto pu essere condotto secondo due modalit:

Progetto di Tipo A: il gruppo formato da 6-8 persone ed coordinato da uno studente del
corso di laurea magistrale.
Progetto di Tipo B: il gruppo formato da 2-4 persone, senza coordinatore del corso di
laurea magistrale.

Ogni gruppo di progetto dovr consegnare al docente del corso la proposta di progetto e le schede
individuali per la partecipazione al progetto. Il docente comunicher laccettazione della proposta
di progetto.

Tutta la documentazione e il codice del progetto dovranno essere disponibili su un repository su
GitHub (si veda il file con le relative istruzioni). Nel caso di progetti di Tipo A, sar il coordinatore
della laurea magistrale a creare il repository e ad aggiungere i collaboratori. Nel caso di progetti di
Tipo B sar uno dei componenti del team a creare il progetto e ad aggiungere i collaboratori. Ai
repository dei progetti devono essere sempre aggiunti anche:
il prof. Andrea De Lucia (username GitHub: andrea-delucia)
il dott. Dario Di Nucci (username GitHub: dardin88)
il dott. Fabio Palomba (username GitHub: fpalomba)

Per riuscire a sostenere lesame a fine corso, ogni gruppo di progetto dovrebbe seguire la
seguente tempistica per le consegne:

1. Proposta di progetto e kick-off meeting: 4-7 ottobre 2016
2. Problem Statement: 14 ottobre 2016
3. Requisiti e casi duso: 21 ottobre 2016
4. Requirements Analysis Document: 4 Novembre 2016
5. System Design Document: 25 novembre 2016
6. Specifica delle interfacce dei moduli del sottosistema da implementare: 16 dicembre 2016
7. Piano di test di sistema e specifica dei casi di test per il sottosistema da implementare: 16
dicembre 2016

La restante documentazione e il codice possono essere consegnati prima della discussione del
progetto.

I documenti e il codice prodotti durante lo svolgimento del progetto dovranno essere inseriti in
una cartella Deliverables del repository di progetto su GitHub.
Lo schema per dare i nomi dei file contenenti i documenti deliverable di progetto il seguente:
TipoDocumento_NomeProgetto. Ad esempio, per il Requirements Analsyis Document (RAD) del
progetto MyProject, si dovr usare come nome RAD_MyProject.

Sulla piattaforma di e-learning, saranno inserite delle scadenze per le consegne dei documenti. Il
nome del file caricato sulla piattaforma dovr seguire lo stesso schema descritto sopra.
Queste scadenze non sono obbligatorie, n i documenti consegnati sono soggetti a valutazione,
ma servono solo a ricevere delle indicazioni su se necessario discutere di eventuali problemi
contenuti nel documento con il docente. Tali pre-valutazioni consentiranno di rivedere il lavoro
man mano che viene svolto, evitando eventualmente di dover rifare il lavoro alla fine, nel caso di
mancata interazione con il docente.
Nel caso in cui non si riesca a rispettare le scadenze sulla piataforma di e-learning non un
problema. Il rispetto delle scadenze serve solo a capire se si sta procedendo nei tempi
preventivati. E in ogni caso possibile contattare il docente per avere una pre-valutazione del
documento.

Infine, GitHub non deve essere considerato solo come un repository per consegnare i deliverable
di progetto al docente, ma come il repository per linterazione del gruppo di progetto. I
semilavorati intermedi che fanno parte dei documenti deliverable di progetto e che sono prodotti
dai singoli componenti dei gruppi di progetto dovranno essere comunque disponibili su GitHub, in
modo da poter verificare la quantit e qualit del lavoro svolto dai singoli partecipanti al progetto
attraverso le funzionalit offerte da GitHub. Evitare di scambiarsi file via e-mail e di delegare il
commit di questi file ad un rappresentante del gruppo di progetto: ciascun partecipante dovr
usare GitHub per i file che crea o che modifica.