Alphatrading - Software Project Management Plan

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

Initial Draft - ver 0.3 First Revision – ver 0.5

Data

14 aprile 2008 ● ●

aggiunta nuovi strumenti tecnici di collaborazione (Gliffy, Assembla) aggiornamento stato avanzamento lavori

12 maggio 2008

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 Piano di Progetto (il presente documento) Documento d'analisi

1.3

Data di consegna 15 aprile 2008 12 maggio 2008

Documento di progetto

3 giugno 2008

Release 1.0 (codice + documento di test)

15 luglio 2008

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

Bozza

Bozza iniziale

Versione preliminare

Versione finale

1.4

Scadenza prevista -

Sottoposta al processo di controllo dei cambiamenti

Fine analisi – 12 maggio 2008

Contiene tutte le modifiche resesi necessarie in progettazione

Fine progetto – 3 giugno 2008

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 instantmessaging (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 sovraassegnazioni 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