Software Project Management Plan

(First revision- ver. 0.5)

Gruppo Alpha
Andrea Martelli
Emanuele Mottola
Roberto Paolillo
Corso di laurea in Ingegneria Informatica Specialistica
Anno Accademico 2007/2008
Docente: Prof.ssa Marina Mongiello

Tabella delle revisioni

Nome revisione Principali modifiche apportate Data

Initial Draft - ver 0.3 14 aprile 2008

First Revision – ver 0.5 ● aggiunta nuovi strumenti tecnici di 12 maggio 2008
collaborazione (Gliffy, Assembla)
● aggiornamento stato avanzamento lavori

Indice
Software Project Management Plan ....................................................................................................1
Tabella delle revisioni......................................................................................................................1
1. Introduzione ................................................................................................................................2
1.1 Panoramica del progetto .......................................................................................................2
1.2 Consegne...............................................................................................................................2
1.3 Evoluzione del documento ...................................................................................................2
1.4 Materiale di riferimento .......................................................................................................3
1.5 Definizioni e acronimi .........................................................................................................3
2 Organizzazione del Progetto ........................................................................................................4
2.1 Modello di processo..............................................................................................................4
2.2 Struttura organizzativa..........................................................................................................4
2.3 Responsabilità di progetto.....................................................................................................5
3 Processi di gestione ......................................................................................................................6
3.1 Gestione dei rischi ................................................................................................................6
3.2 Monitoraggio e meccanismi di controllo..............................................................................7
4 Processo tecnico............................................................................................................................7
4.1 Metodi, strumenti e tecniche.................................................................................................7
4.2 Infrastruttura di progetto.......................................................................................................9
4.3 Politiche di backup e sicurezza...........................................................................................10
5. Attività, risorse e scheduling ....................................................................................................11
5.1 Attività (Work Packages) ...................................................................................................11
5.2 Dipendenze .........................................................................................................................11
5.3 Stima della durata delle attività .........................................................................................11

Software Project Management Plan – Initial Draft pag. 1 di 18

 5.4 Allocazione delle risorse ...................................................................................................11
5.5 Scheduling .........................................................................................................................12

1. Introduzione
Il presente documento illustra le linee guida seguite dal team di sviluppo per la realizzazione del
tema d’anno del corso di Ingegneria del Software tenuto presso il Politecnico di Bari dalla Prof.ssa
Ing. Marina Mongiello.

E' realizzato secondo le guidelines dello standard IEEE 1058-1998 [6] per la realizzazione dei
SPMP (Software Project Management Plan).

1.1 Panoramica del progetto

L’obiettivo del progetto è la realizzazione di un sistema software per effettuare operazioni di trading
online. Il sistema fornirà un’ampia gamma di funzionalità, quali analisi tecnica, gestione dei conti,
negoziazione e cambio valuta, che interesseranno il mercato borsistico italiano ed internazionale, e
saranno rivolte a diverse categorie di utenti.

Non disponendo di un accesso reale ai sistemi informativi delle Borse prese in considerazione, il
principale scopo del prodotto sarà fornire una simulazione delle operazioni effettuate dagli utenti e
dell’andamento del loro portafoglio titoli, costituendo così una sorta strumento di training per
aspiranti traders.

L’applicazione sarà web-oriented e pertanto sarà sviluppata utilizzando il modello architetturale

client-server. Le risorse hardware e software previste saranno analizzate in seguito.

1.2 Consegne

Il progetto verrà diviso in una serie di macro-attività. L'output di queste è costituito da dei
deliverables, composti essenzialmente da una serie di documenti che verranno consegnati con le
seguenti scadenze:

Nome documento Data di consegna

Piano di Progetto (il presente documento) 15 aprile 2008
Documento d'analisi 12 maggio 2008
Documento di progetto 3 giugno 2008
Release 1.0 (codice + documento di test) 15 luglio 2008

1.3 Evoluzione del documento

Nel corso dell’attuazione del progetto, il presente documento potrebbe subire delle revisioni dovute
al cambiamento di requisiti, dell’organizzazione o a perfezionamenti e decisioni progettuali. Inoltre,
la tracciatura dei progressi nel software di Project Management permette per ogni consegna il
rilascio di un nuovo diagramma GANTT che evidenzi la differenza tra schedulato ed eseguito.

Software Project Management Plan – Initial Draft pag. 2 di 18

Versione Descrizione Scadenza prevista

Bozza Bozza iniziale -

Versione preliminare Sottoposta al processo di controllo dei Fine analisi – 12 maggio 2008
cambiamenti

Versione finale Contiene tutte le modifiche resesi necessarie in Fine progetto – 3 giugno 2008
progettazione

1.4 Materiale di riferimento

[1] SWEBOK Guide 2004 – Software Engineering Body Of Knowledge

[2] Java Advanced How To Program – Deitel & Deitel
[3] Software Engineering II course slides, Prof Brugge, Munich University
[4] Slides del corso di Ingegneria del Software, Prof.ssa M. Mongiello, Politecnico di Bari
[5] Best Practices Software Engineering, http://best-practice-software-engineering.ifs.tuwien.ac.at/
[6] IEEE 1058-1998, Standard for software project management plans
[7] ISO 9126 – Standard for the evaluation of software quality
[8] PMBOK Guide 3rd Edition - Project Management Body of Knowledge

1.5 Definizioni e acronimi

AJAX – Asynchronous Javascript and XML

API – Application Programming Interface
DBMS - Database Management System
CASE – Computer Aided Software Development
CSS – Cascading Style Sheet
DDL – Data Definition Language
DML – Data Manipulation Language
FTP - File Transfer Protocol
GUI – Graphical User Interface
HTML – Hyper Text Markup Language
IDE – Integrated Development Environment
JDK – Java Development Kit
JSP – Java Server Pages
JVM – Java Virtual Machine
SPMP – Software Project Management Plan
SQL – Structured Query Language
SVN – Sub VersioN, collaborative development tool
SWEBOK – Software Engineering Body Of Knowledge
UML – Unified Modeling Language
WBS – Work Breakdown Structure
XML – eXtensible Markup Language

Software Project Management Plan – Initial Draft pag. 3 di 18

2 Organizzazione del Progetto

2.1 Modello di processo

Il progetto è iniziato il 28 marzo 2008 e la sua fine è prevista per il 15 luglio 2008. La metodologia
usata per il progetto del software è quella della modellazione UML e l’intero processo è suddiviso
in varie fasi, ognuna delle quali produce un output sviluppato collaborativamente e della cui
revisione finale ed approvazione è responsabile un singolo componente del team.

Il modello di processo utilizzato è a cascata (waterfall) non rigido, e quindi al termine di ogni fase
è possibile apportare modifiche ai work packages e ai deliverables precedenti. L’utilizzo di questo
modello è dettato principalmente dagli stretti vincoli temporali del progetto, che non consentono di
effettuare una analisi e una progettazione esaustiva che considerino già in fase iniziale un elevato
numero di aspetti.

Figura 1: modello di processo "waterfall" non rigido

2.2 Struttura organizzativa

Per via della dimensione contenuta del team, si è scelto di non assegnare ruoli specifici (analista,
progettista, project manager, ecc.) ai suoi componenti. Tuttavia in alcune fasi è necessaria una
figura di "responsabile" che svolga specifici compiti prendendo alcune decisioni in maniera
autonoma e che coordini il lavoro del team al fine di portare a termine una determinata attività (si
veda il paragrafo successivo).

Dal punto di vista della collaborazione, questa avverrà prevalentemente online, mediante diversi
strumenti che saranno descritti in seguito. Si terranno dei meeting online a cadenza pressoché
quotidiana per mettere al corrente gli altri membri del team di eventuali problemi riscontrati o per
discutere di scelte progettuali.

Al termine di ogni attività prevista dalla WBS i componenti del team si incontreranno per un tempo
non inferiore alle due ore, durante il quale l'assegnatario dell’attività illustrerà il lavoro svolto,
analizzando i progressi, e lo sottoporrà all’approvazione unanime del gruppo. In questa sede
vengono anche assegnate le attività successive. Durante la fase di implementazione le riunioni
potranno avere cadenza settimanale.

Software Project Management Plan – Initial Draft pag. 4 di 18

2.3 Responsabilità di progetto

Al termine di ogni macro-attività si evidenzia l'esigenza di raccogliere e organizzare il materiale

prodotto al fine di produrre il relativo documento. Per coordininare questa attività vengono
individuati dei responsabili con i compiti di:

● organizzare specifiche attività e meeting per la redazione dello scheletro del documento
● effettuare la revisione finale del documento
● strutturarlo in modo coerente e organico, possibilmente seguendo degli standard di
riferimento
● impaginarlo e preparare i file nei corretti formati necessari al rilascio
● consegnare il documento al committente

E' dunque il responsabile principale dei contenuti del documento e della sua corretta
strutturazione.

Per il presente progetto si sono individuati i seguenti responsabili:

Componente Ruolo
Roberto Paolillo Responsabile del documento di Pianificazione
Andrea Martelli Responsabile del documento di Analisi
Emanuele Mottola Responsabile del documento di Progettazione

Vengono inoltre definiti i seguenti ulteriori ruoli di responsabilità:

Componente Ruolo
Emanuele Mottola Responsabile dell'infrastruttura server e backup dei dati
Andrea Martelli Referente per l'analisi del dominio – parte di “mercati e titoli”
Roberto Paolillo Referente per l'analisi del dominio – parte di “analisi tecnica”
Emanuele Mottola Responsabile delle comunicazioni con il committente

Altre figure di responsabilità potranno essere definite in corso d'opera a seconda delle esigenze.

Resta fermo il fatto che ogni attività della WBS sarà assegnata ad uno o più membri del team (con
funzioni di coordinamento e responsabilità specifiche) attraverso il tool di project management,
tenendo conto del calendario didattico e della disponibilità di ore delle risorsa. L'assegnatario
relaziona quotidianamente sui risultati ottenuti e sulle scelte intraprese, in modo che l'intero team
sia sempre a conoscenza dello svolgimento ogni attività.

Software Project Management Plan – Initial Draft pag. 5 di 18

3 Processi di gestione

3.1 Gestione dei rischi

Di seguito sono analizzati i rischi coinvolti nel progetto. Questa sezione potrà essere revisionata in
qualsiasi momento, per tenere in conto l’insorgenza di nuovi rischi o il cambiamento delle strategie
da attuare in risposta a questi.

Rischio: cambiamento degli orari di lezione / disponibilità ore delle risorse diminuite.
Probabilità: alta
Piano di contingenza: re-scheduling delle attività. Se non è possibile (vincoli di programmazione
non rispettati), ridimensionamento del tempo assegnato alle attività non critiche immediatamente
successive.

Rischio: indisponibilità temporanea di un membro del team.

Probabilità: medio-alta
Piano di contingenza: gli altri membri del gruppo, se possibile, si dividono equamente le attività
del membro non disponibile. Se l’attività non è critica e il tempo di indisponibilità non supera i 3
giorni, si rimane in attesa.

Rischio: impossibilità improvvisa di svolgimento di una riunione.

Probabilità: medio-alta
Piano di contingenza: se almeno due membri del gruppo sono disponibili, l’incontro si tiene
comunque e la persona mancante viene messa al corrente appena possibile. Se è richiesta la
presenza del gruppo al completo, la riunione viene spostata nella prima data utile. Se dopo la data
prevista della riunione dovevano essere avviate delle attività critiche, queste vengono avviate
ugualmente: nella riunione seguente affronterà anche questi temi.

Rischio: un membro del team non dispone di un PC funzionante.

Probabilità: molto bassa
Piano di contingenza: se possibile, la persona interessata dedicherà lo stesso tempo ad attività di
analisi, progettazione o ricerca che non richiedano l’uso di un PC. Se ciò non è possibile,
comunicherà al più presto con gli altri membri, che proveranno a svolgere parte del suo lavoro.

Rischio: uno strumento di collaborazione (Google Docs, Google Groups, MSN, SVN, server FTP)
è momentaneamente non funzionante.
Probabilità: bassa
Piano di contingenza: gli eventuali scambi di materiale e/o informazioni possono procedere su
canali alternativi.

Rischio: ottenimento dei dati di borsa impossibile.

Probabilità: medio-bassa
Piano di contingenza: se non possono essere ottenuti in modo abbastanza efficace, verrà costituito
un database “artificiale” e opzionalmente creata una routine per simulare la variazione del valore
dei titoli in modo da simulare la situazione reale.

Rischio: le pagine web o i servizi usati come fonte per l’ottenimento dei dati di borsa sono state
modificate.
Probabilità: media
Piano di contingenza: se il cambiamento è tale da consentire di adeguare le funzioni di ottenimento
dati in tempi brevi o medi, operare di conseguenza. Altrimenti utilizzare, per quanto possibile, i dati

Software Project Management Plan – Initial Draft pag. 6 di 18

storici archiviati nel database locale.

Rischio: ritardo eccessivo nel completamento di un’attività per problemi tecnici o pratici.
Probabilità: media
Piano di contingenza: il team si concentra sulla soluzione delle questioni emergenti. Se non viene
trovata una soluzione, si bypassa il problema apportando le opportune modifiche progettuali,
eventualmente rivedendo alcuni requisiti o introducendo nuove ipotesi semplificative.

Rischio: ritardo nella produzione di un deliverable.

Probabilità: media
Piano di contingenza: il diagramma Gantt prevede un margine di qualche giorno tra produzione del
deliverable e scadenze (consegne), proprio per tenere in conto eventuali ritardi. Se il deliverable non
è stato prodotto entro la data prestabilita, i membri del team lavorano congiuntamente e
intensivamente allo sviluppo della stessa, in modo da non superare la scadenza. Se invece il ritardo
supera quello previsto, i tre membri del team concentrano i loro sforzi nel completamento del
deliverable nel minor tempo possibile, avvertendo il committente del ritardo.

3.2 Monitoraggio e meccanismi di controllo

Il monitoraggio delle attività avverrà principalmente attraverso il software di Project Management.

I meccanismi di controllo sono stati precedentemente già descritti e consistono nei meeting
periodici informativi sullo stato delle attività, occasioni in cui si effettua l'aggiornamento dei dati
percentuali di completamento nel software. Eventuali ulteriori meccanismi e azioni di controllo
possono essere intrapresi dal responsabile del documento della fase in atto, volti a garantire di poter
ottenere gli output documentali delle attività in tempi utili alla sua attività di revisione e
integrazione.

4 Processo tecnico
Di seguito sono analizzate le risorse necessarie alla realizzazione del progetto. Queste si possono
dividere innanzitutto in risorse di tipo hardware e di tipo software, queste ultime poi sono di due
diversi tipi: quelle necessarie al dialogo e sincronizzazione del lavoro tra i componenti del gruppo, e
quelle strettamente legate all'implementazione del progetto.

4.1 Metodi, strumenti e tecniche

Nello sviluppo del progetto si fa ricorso ad un metodo di tipo “collaborativo-paritario”, in quanto

non viene definita una gerarchia tra gli elementi del gruppo e tutti hanno le stesse credenziali sia
nell'accesso ai file che nello sviluppo della documentazione. Per quanto riguarda il tipo di
comunicazione tra i componenti del gruppo questa avviente totalmente mediante la rete internet ed
è affidata a servizi gratuiti di instant-messaging e VoIP.

I componenti del gruppo utilizzano sistemi operativi differenti (Windows/GNU Linux). Dunque è
assai importante nella scelta degli strumenti da utilizzare la caratteristica di essere
multipiattaforma o, meglio ancora, web-based.

Ogni componente del gruppo comunica con gli altri attraverso protocolli e client di instant-
messaging (Pidgin o Windows Live Messenger) sia con sessioni di conversazioni private che di
gruppo. Per le conferenze vocali si utilizza il software Skype, con supporto alle conversazioni
singole o multiple e supporto video. In entrambi i casi i software sono disponibili per divesi sistemi
operativi.

Software Project Management Plan – Initial Draft pag. 7 di 18

Per la redazione dei documenti di progetto si è scelto di utilizzare il servizio online Google Docs,
il quale permette una facile accessibilità ai documenti, creazione, modifica online ed esportazione in
numerosi formati, oltre che a diverse funzioni che facilitano la stesura di testi in maniera
collaborativa e simultanea, tutto attraverso il browser web.

(first revision – ver 0.5) Per la redazione dei diagrammi, oltre a Microsoft Visio, è stato
ampiamente utilizzato il tool online Gliffy che fornisce con una interfaccia dinamica e collaborativa
per la creazione di diagrammi e la condivisione con un gruppo di lavoro. Questo ha facilitato la
discussione e la conseguente diretta modifica dei diagrammi, agevolando le attività di brainstorming
su casi d'uso e classi. Di seguito è riportato un esempio di diagramma “intermedio” realizzato in
Gliffy con l'assegnazione ai componenti del gruppo delle attività di dettagliamento di scenari e
attività dei casi d'uso.

L' archiviazione dei file riguardanti il progetto avviene mediate due sistemi. Per quanto riguarda i
file di documentazione e in generale i file di piccole dimensioni, si è scelto di utilizzare il servizio
Google Groups. Questo consente anche di gestire una mailing list per lo scambio di informazioni al
difuori dei metting in IM e VoIP, utile anche per tenere traccia in modo organizzato di discussioni
che determinano scelte progettuali.
Per quanto concerne i file generici e di dimensioni medio-grandi come gli archivi di backup o la
documentazione di riferimento, la scelta è ricaduta su un server FTP privato.
Per i file sorgente utilizzati durante durante l'implementazione si utilizza un sistema di ”controllo
di versione”. La scelta è ricaduta sulla tecnologia Subversion (SVN) che, in breve, consente di
tenere traccia delle modifiche apportate ai file e permette di lavorare in maniera concorrente su una
“working copy” del progetto, di cui viene periodicamente effettuata la “commit” (verificando che le
modifiche dei diversi utenti non creino conflitti). E' da segnalare che Google Docs, scelto per la
gestione documentale, gestisce anch'esso un sistema di versioning molto simile a SVN.

Per lo sviluppo l'IDE che sarà utilizzato è Netbeans: multilinguaggio, eccellente per la creazione di
software in Java, espandibile tramite numerosi plugin. E' stato scelto rispetto ad Eclipse per via

Software Project Management Plan – Initial Draft pag. 8 di 18

della sua maggiore flessibilità e completezza nella creazione di applicazioni web. Anche nella scelta
dell'IDE, essendo Netbeans scritto in Java e quindi multipiattaforma, non ci si è legati ad un
particolare sistema operativo o a costi di licenza. Netbeans è anche usato per la creazione della
documentazione UML.

Per quanto riguarda DBMS e il web server/container, pur essendo la loro scelta vincolata a
successive scelte architetturali in fase di progetto, si è deciso di rendere disponibili sin da subito
questi servizi, per effettuare applicazioni d'esempio a scopo didattico al fine di familiarizzare con
le architetture web-based.
Il DBMS utilizzato per questi scopi è MySQL, basato sul modello relazionale, opensource e
disponibile per diversi sistemi operativi. Esso dispone di diversi storage engine e di strumenti di
amministrazione locali e remoti per tutte le piattaforme. Come contenitore si è scelto Apache
Tomcat, web container e web server open source che implementa le specifiche JSP e Servlet di Sun
Microsystem. Esso fornisce una delle migliori piattaforme per l'esecuzione di applicazioni web
sviluppate nel linguaggio Java. Essendo anch'esso scritto in java, può essere utilizzato dovunque ci
sia una JVM.

Il servizio FTP è configurato in modo tale che l'utente remoto, una volta autenticatosi, abbia
accesso direttamente a tutte le cartelle della partizione dati, potendo così avere a disposizione tutto
il materiale condiviso.

Tramite il servizio SSH (Secure Shell) è possibile avere una shell remota da qualsiasi sistema
connesso ad internet che, una volta autenticatosi, può amministrare a qualsiasi livello il server. Il
client SSH è disponibile per tutti i sistemi operativi.

(first revision – ver 0.5) Per molti dei servizi sopracitati si è scelto di utilizzare, oltre agli appositi
software installati su Alphaserver, anche uno spazio di lavoro online Assembla, che favorisce una
collaborazione “agile” tra i componenti del team e uno sviluppo più rapido, fornendo strumenti
come wiki, discussioni, alerts, chat, ticketing, Git, Subversion e Trac, tutti molto utili
soprattutto in fase di implementazione. Inoltre l'archiviazione di documenti e sorgenti su questo
spazio web favorisce anche la ridondanza a scopo di backup dei dati.

Infine per il Project Management, viene utilizzato il software Microsoft Project. La scelta è dovuta
al fatto che MS Project è altamente personalizzabile e scalabile a seconda delle necessità. Inoltre il
formato di file prodotto (MPP o XML) rappresenta uno standard de-facto in quest'ambito. Sono
infatti disponibili numerosi applicativi in grado di leggere questi formati, tra cui segnaliamo
OpenProj e GanttProject, entrambi opensource e java-based, scelti come applicazioni di lavoro
alternative multipiattaforma.

4.2 Infrastruttura di progetto

Considerato il numero di servizi richiesti per lo sviluppo del progetto, si è deciso di assemblare e
rendere operativo 24ore/24 un calcolatore utilizzandolo come server dedicato. Detto server è
denominato "Alphaserver" ed è ospitato presso uno dei componenti del gruppo. Utilizzando un
servizio gratuito di "Dynamic DNS", esso è sempre raggiungibile all'indirizzo
alphaserver.selfip.org.

Software Project Management Plan – Initial Draft pag. 9 di 18

 Figura 2: infrastruttura hardware e software
Alphaserver
Configurazione harwdare:
● CPU Amd AthlonXP 2600
● RAM 512 Mb DDR PC-2700
● HD 40Gb per il sistema operativo
● HD 60Gb per i dati
● UPS 500VA

Configurazione software:
● Sist. Operativo: Gentoo GNU/Linux
● Kernel: 2.6.24-r4 Low-Latency
● Tomcat-6.0.16
● MySQL-5.0.54
● ProFTP-1.3.1
● Subversion-1.4.6
● OpenSSH-4.7
● Supporto NFS integrato nel kernel

Pc3 (sistema di backup)

Configurazione hardware:
● CPU Amd X2 6000+
● RAM 2Gb DDR2 PC2-6400
● HD 80Gb per il backup di Alphaserver
● HD 320Gb di cui 100Gb per backup

Configurazione software:
● Sist. Operativo: Gentoo GNU/Linux
● Kernel: 2.6.24-r4 Preemption Low-Latency
● Rdiff-backup-1.0.5
● Nfs-utils-1.1
● Cronbase-0.3.2

Si è scelto di utilizzare GNU/Linux per Alphaserver in quanto questo sistema operativo, opensource
e gratuito, in primo luogo perchè consente una grande flessibilità e scalabilità, nonchè pieno

Software Project Management Plan – Initial Draft pag. 10 di 18

supporto e disponibilità ai software opensource per l'erogazione di tutti servizi necessari. In secondo
luogo GNU/Linux consente di ottenere prestazioni e sicurezza migliori di altri sistemi proprietari.
L'utilizzazione di GNU/Linux anche su Pc3 rende possibile realizzare in maniera completa ed
affidabile, i backup automatici.

La distribuzione Linux scelta per Alphaserver è Gentoo in quanto è l'unica meta-distribuzione che
consente di compilare interamente il sistema utilizzando le opportune ottimizzazioni per
l'architettura specifica, offrendo miglioramenti prestazionali rispetto alle altre distribuzioni
precompilate per l'artchiterrura i386.

4.3 Politiche di backup e sicurezza

Al fine di evitare la perdita di dati dovuta a black-out, si è dotato Alphaserver di un unità UPS in
grado di fornire energia elettrica per circa 30min in assenza di corrente. Questa è connessa tramite
porta seriale ad Alphaserver in modo da comunicare la mancanza di corrente ed attivare uno script
di spegnimento del server trascorsi 25min di blackout. Inoltre si è dotato l'hard disk dei dati di
partizione di tipo Ext3, con filesystem di tipo jounaled, il massimo in caso di racovery dei dati, a
differenza del sistema operativo che è ospitato in un volume logico LVM con partizioni di tipo XFS
per poter ottenere le massime prestazioni possibili dall'hardware.

Alphaserver esporta, mediante la rete LAN e tramite il servizio NFS (Network File System) l'intera
partizione dati e le partizioni in cui risiede il sistema operativo al sistema Pc3 che le inserisce nel
proprio albero delle directory al boot. Con cadenza regolare, mediante script in Bash attivati dal
demone Cron, Pc3 effettua un backup differenziale, tramite il software opensource Rdiff-backup,
dell'intero sistema Alphaserver sull'hard disk da 80Gb dedicato all'operazione, mentre altri 100Gb
sono dedicati in una partizione di un altro hard disk di Pc3 per effettuare degli snapshot dei database
o per ulteriori backup. Il backup differenziale è stato scelto per l'efficienza sia in termini di
velocità, che di spazio occupato, il vincolo che le directory da salvare siano locali è superato tramite
NFS.

Sempre con cadenza giornaliera e tramite script in Bash il sistema Alphaserver crea un archivio,
compresso in formato tar.bz2, dei dati sensibili presenti sulla propira partizione dati,
sovrascrivendolo giornalmente e posizionandolo all'interno dell'hard disk del sistema operativo. Su
entrambi i sistemi Pc3 e Alphaserver gli hard disk sono posizionati su distinti canali EIDE, al fine
di massimizzare le prestazioni.

Dal punto di vista della sicurezza di rete, tutti i servizi forniti da Alphaserver, NFS escluso poichè
relativo alla rete locale, vengono erogati su porte diverse da quelle di default dei vari servizi
evitando parzialmente rischi di attacchi di port-scanning, piuttosto frequenti per server pubblici con
indirizzo IP statico o con associato un nome di dominio (nel nostro caso ottenuto tramite DNS
dinamico). Un firewall e un IDS (Intrusion Detection System) presenti sul router, insieme
all'adozione di altre good-pratices e policies di sicurezza, garantiscono un buon livello di difesa da
attacchi esterni.

Software Project Management Plan – Initial Draft pag. 11 di 18

5. Attività, risorse e scheduling

5.1 Attività (Work Packages)

Il progetto è stato suddiviso in una serie di sottoattività organizzate in una WBS (Working
Breakdown Structure) secondo i principi del Project Management così come descritti nella
Knownledge Area di Scope Management del PMBOK [8].

Durante l'incontro conclusivo della fase di analisi preliminare si è effettuato un brainstorming per
scomporre le attività del progetto in sottofasi, secondo un approccio top/down, dando così vita a una
struttura organizzata gerarchicamente. Il WBS ottenuto e qui di seguito presentato è “orientato alle
attività” ed ha un approccio “funzionale”. Si sono individuate delle macro-attività del tutto simili a
quelle del modello di processo (waterfall) utilizzato e descritto al paragrafo 2.1.

5.2 Dipendenze

Analizzando singolarmente le attività si è valutato tra quali di queste intercorressero dei vincoli di
dipendenza e si è dunque associato a ciascuna una lista di precedenze.
Per via della tipologia di progetto nonché del modello di processo utilizzato, molto spesso è stato
necessario porre le attività in sequenza tra di loro. Tuttavia s'è cercato, nei limiti del possibile, di
parallelizzare alcune attività in modo da permettere una più efficace gestione del tempo e delle
risorse.

5.3 Stima della durata delle attività

Durante un incontro tra i componenti del team in fase di pianificazione, nonché con raffinamenti
successivi attraverso gli strumenti di collaborazione a disposizione, si sono stimate le durate delle
attività individuate basandosi sulle esperienze personali. Per attività che richiedono skill non
ancora acquisite dai parte dei componenti, e che non sono mai state svolte precedentemente, si è
seguita la politica di sovrastimare la loro durata ipotetica, cercando di bilanciare durata di ogni fase
con le scadenze prefissate, attraverso l'ausilio del software di Project Management utilizzato.
Inoltre, le consegne sono state ritardate di qualche giorno rispetto alla data di fine della relativa fase,
garantendo i necessari margini necessari per una corretta gestione del rischio.

5.4 Allocazione delle risorse

Nel tool di Project Management sono stati inseriti i dati relativi alle risorse umane a disposizione (i
componenti del gruppo) e i loro calendari di lavoro, che tengono conto degli impegni didattici e
di altra natura di ciascuno. Con questi dati il software è in grado di tenere traccia e permette di
monitorare i carichi di lavoro assegnati alle varie risorse. Questo permette di evitare sovra-
assegnazioni non immediatamente evidenti e quindi semplifica la pianificazione, migliora qualità
del lavoro e riduce il rischio di sforamento delle durate stimate.

Per via dei (complessi) calendari dei componenti del team, è da notare che spesso la durata delle
attività (espressa in giorni) non coincide con il numero di giorni intercorrenti tra data d'inizio e data
di fine schedulata. Quindi è stato necessario porre attenzione nella definizione della durata prevista
delle attività ricordandosi che la durata espressa in giorni viene dal software moltiplicata per le ore
lavorative giornaliere (fissate a 10) e poi suddivisa secondo i calendari di lavoro.

Software Project Management Plan – Initial Draft pag. 12 di 18

Nelle tabelle successive, a titolo di esempio, sono riportate le allocazioni delle risorse per le fasi
completate al momento della prima consegna del presente documento.

5.5 Scheduling

Attraverso la conoscenza di:

● durata (stimata) delle attività
● calendario di lavoro delle risorse
● vincoli di precedenza tra attività
● scadenze (date di consegna)
il software di Project Management è in grado di fornire le date di inizio e fine di ogni attività e di
segnalare eventuali conflitti di programmazione. Inoltre permette di registrare i progressi,
permettendo di intervenire immediatamente non appena si hanno segnali che evidenziano un ritardo
sulle attività.

La rappresentazione grafica delle attività, dei loro tempi e vincoli è fornita dal seguente diagramma
di Gantt.

Software Project Management Plan – Initial Draft pag. 13 di 18

Software Project Management Plan – Initial Draft pag. 14 di 18
Software Project Management Plan – Initial Draft pag. 15 di 18
Software Project Management Plan – Initial Draft pag. 16 di 18
Software Project Management Plan – Initial Draft pag. 17 di 18
Software Project Management Plan – Initial Draft pag. 18 di 18