Software Project Management Plan 1.0

Transcript

1 Software Project Management Plan maggio 2010 Gruppo CiDeFaRo Progetto di Laboratorio Sistemi e Processi Organizzativi 2010 ALMA MATER STUDIORUM - Universitá di Bologna Facolt di Scienze Matematiche Fisiche e Naturali Corso di Laurea in Scienze di Internet - A.A Autore: Rossi Claudio - Project Manager 1

2 Contents 1 Introduzione Introduzione Progetto: obiettivi e destinatari Artefatti Evoluzione dell'spmp Materiale di Riferimento Denizioni e Acronimi Organizzazione del progetto Modello di Processo Struttura Organizzativa Responsabilitá del progetto Piano di Processo Manageriale Work Breakdown Structure Diagramma di Gantt Gestione del rischio Piani di Processo Tecnico Stima dello sforzo

3 1 Introduzione 1.1 Introduzione Questo documento viene redatto dal Project Manager del gruppo, seguendo - il piú fedelmente possibile - le speciche fornite dal Software Project Management Plan denito all'interno dello standard IEEE Il presente documento rappresenta una bozza della descrizione del progetto e della pianicazione delle attivitá in relazione ai ruoli assunti dai componenti del gruppo, al tempo a disposizione ed allo sforzo preventivato. Essendo una bozza, questo documento, potrá essere soggetto a modiche per aggiornare il committente dei progressi fatti durante il processo di sviluppo. 1.2 Progetto: obiettivi e destinatari Si vuole realizzare un software in grado di gestire il popolare gioco del Fantacalcio (vedi pagina Wikipedia italiano per le informazioni preliminari sul regolamento ed il gioco in generale). Si é deciso di implementare il gioco seguendo le regole del Fantacalcio all'italiana che il Gruppo, ha ritenuto il piú popolare nel nostro paese senza implementare la regola n.5 dei 15 trasferimenti massimi. Inoltre si é deciso di seguire le modalitá di mercato del Magic Cup di Gazzetta.it, cioé ogni Team ha un Budget pressato che puó spendere per l'acquisto di 3 portieri, 8 difensori, 8 centrocampisti e 6 attaccanti. Ognuno di questi giocatori ha un costo pressato dal sistema e ogni Team puó avere in rosa lo stesso giocatore. 1.3 Artefatti Gli artefatti a corredo del progetto saranno consegnati attraverso la pagina Wiki del corso, rispettando le seguenti scadenze: 1. Al 17/5/2010: i PM dovranno consegnare su wiki una bozza iniziale del Piano di Processo. 2. Al 17/5/2010: i TS deniranno eventuali emendamenti ai requisiti, consegnando sul wiki un documento dei requisiti scritto usando uno strumento qualsiasi di gestione dei requisiti. 3. Al 31/5/2010: i Librarian dovranno consegnare sul wiki una bozza della relazione con la parte UML, in modo che possa essere fatta una revisione incrociata. 4. Al 7/6/2010: i QE dovranno consegnare su wiki e per le schede di valutazione dei progetti che saranno stati loro assegnati /01/2010: scadenza ultima per la consegna dell'implementazione del progetto. 1.4 Evoluzione dell'spmp Al presente documento seguiranno versioni aggiornate e ampliate in funzione del processo di progettazione. Sará cosí possibile orire un costante monitoraggio delle attivitá e dello stato del progetto. 1.5 Materiale di Riferimento Nella realizzazione del presente documento si é seguito lo standard IEEE , integrato dalle nozioni apprese a lezione e dal materiale reperibile sul Wiki. 3

4 1.6 Denizioni e Acronimi Fantacalcio: nome del Sistema; Utente: persona che gioca al Fantacalcio e si iscrive ad una Lega; Team: gruppo di Giocatori scelti da ogni Utente per partecipare ad una Lega; Lega: gruppo di Team partecipanti al Fantacalcio; Campionato: campionato di calcio reale (es. Seria A Italiana, Bundesliga Tedesca); Giocatore: persona reale che disputa partite reali nel Campionato e che é associato a qualche Team; Squadra: gruppo di Giocatori che partecipano al Campionato; Giornata: insieme partite disputate lo stesso giorno; Calendario: giornate disputate o da disputare all'interno di una Lega; Formazione: gruppo di Giocatori di un Team che partecipano ad una Giornata del Calendario; Schema di gioco: metodo con cui i Giocatori di ogni Formazione sono schierati; Acquisto Giocatore: operazione eettuata dall'utente nella quale, a seguito di una diminuzione del credito pari al valore del giocatore, viene aggiunto al team dell'utente; Vendita Giocatore: operazione eettuata dall'utente nella quale, a seguito di un aumento del credito pari a metá del valore del giocatore, viene cancellato dal team dell'utente; Credito: mezzo di scambio per l'acquisto e la vendita dei Giocatori; Modulo Formazione: tipologia di schieramento dei giocatori in campo (es , 3-4-3); Budget: somma dei Crediti a disposizione di un Utente per il proprio Team; Titolare: un Giocatore che concorre al punteggio totale di ogni Giornata per il Team (massimo 11 per Team); Sostituto: un Giocatore che subentra al Titolare in caso di assenza di Voto (massimo 7 per Team)(massimo 3 cambi); Voto: punteggio assegnato ad ogni Giocatore per ogni Giornata da un quotidiano sportivo. 4

5 2 Organizzazione del progetto 2.1 Modello di Processo Il modello di processo software seguito nello sviluppo, per quanto possibile, é il RUP (Rational Unied Process). A tal proposito si sottolinea che a causa di problemi, impedimenti e scadenze incombenti si é dato maggior peso alla fase di progettazione rispetto alla stesura del codice. Nonostante una prima release sia in corso d'opera, quindi si potrebbe aermare che il modello di processo seguito sia in realtá un ibrido tra RUP e Waterfall. 2.2 Struttura Organizzativa Come prima attivitá di progetto ogni componente del team di sviluppo ha espresso una preferenza riguardo al ruolo da ricoprire all'interno del processo e, di comune accordo, sono state attribuite le posizioni. Come da specica il Project Manager ha confermato i ruoli sotto elencati. Ruolo Componente Matricola PM - Project Rossi Claudio claudio.rossi14@studio.unibo.it Manager L - Librarian Andrea Cinelli cinelli@cs.unibo.it TS - Tools Matteo Fanciulli matteo.fanciulli@studio.unibo.it Specialist QE - Quality Engineer Alessandro De Troia alessandro.detroia@studio.unibo.it 2.3 Responsabilitá del progetto Analogamente all'assegnazione dei ruoli, l'attribuzione delle responsabilitá del progetto segue le indicazioni fornite dalle speciche. Responsabilitá PM L TS QE Pianicazione Attivitá X Redazione Documenti X X X X Mantenimento Sito X Controllo Qualitá X Controllo Tools di Sviluppo X Redazione Diario di X Gruppo Redazione Diario di Personale X X X X 5

6 3 Piano di Processo Manageriale 3.1 Work Breakdown Structure Ogni attivitá di lavoro all'interno del progetto é stata identicata ed organizzata come rappresentato dal diagramma WBS riportato sotto. (Fig. 1) 6

7 7 Fig. 1 WBS

8 3.2 Diagramma di Gantt Come da specica, in base alle attivitá riportate sul diagramma WBS ed alla tempistica imposta dalle date di consegna, stato redatto il diagramma di Gantt qui di seguito riportato (Fig. 2). 3.3 Gestione del rischio Fig. 2 Gantt Analogamente ad ogni altro progetto, anche i processi software sono soggetti a vari rischi che, in ultima istanza, possono anche portare al fallimento. Per evitare che questo accada, é opportuno approntare un'analisi dei rischi che preveda una stima del livello d'allarme ed una previsione sugli eetti che questi avranno sul processo. Si riporta di seguito una tabella contenete i principali fattori di rischio che possono decretare rallentamenti, intoppi o il non raggiungimento degli scopi di progetto. Rischio Eetto Probabilitá Assenteismo e cattiva organizzazione tra i membri del team. Lavoro discontinuo, nei casi peggiori porta all'arresto dell'intero processo produttivo. 40% Errata comprensione dei requisiti. Sviluppo di un software non conforme alle aspettative del cliente. 25% Lavoro di sviluppo superciale. Bassa qualitá del software. 30% Errata pianicazione di tempistiche e consegne. Ritardo sui tempi di consegna 15% 8

9 Come evidenzia la tabella sopra riportata, uno dei maggiori rischi che si incontra nella realizzazione di un processo software é la cattiva comprensione dei requisiti iniziali che, se non retticata, puó portare alla realizzazione di un progetto diverso dalla consegna adata e perció non conforme alle richieste del cliente. 4 Piani di Processo Tecnico 4.1 Stima dello sforzo COCOMO é un modello matematico creato per stimare alcuni parametri fondamentali come il tempo di consegna ed i mesi-persona necessari per lo sviluppo di un prodotto software. Come prima stima il metodo COCOMO consiglia un calcolo dei Fuction Point che descrivono i requisiti funzionali del sistema che andranno implementati. I FP si dividono in 5 categorie: External Input: informazioni, dati forniti dall'utente (es.nome di le, scelte di menú, campi di input) External Output: informazioni, dati forniti all'utente dell'applicazione (es. report, messaggi d'errore) External Inquiry: sequenze interattive di richieste e risposte External Interface File: interfacce con altri sistemi informativi esterni Internal Logical File: le principali logici gestiti nel sistema Per ogni FP dobbiamo indicare il tipo di categoria e il grado di dicoltá suddiviso tra basso, medio e alto. Il programma di calcolo dello sforzo per ogni FP assocerá un moltiplicatore di sforzo e un numero ttizio di SLOC per poter calcolare lo sforzo totale del progetto. 9

10 Fig 3 Fuction Point Dopodiché il programma stimerá lo sforzo necessario. 10

11 Fig 4 COCOMO Secondo il software il programma sará composto da 5610 SLOC per uno sforzo totale di 19,6 mesipersona da suddividere per 4 componenti del gruppo che in totale sono 5 mesi-persona a testa. Da notare che il programma non tiene conto delle righe auto generate dagli IDE moderni quindi si ritengono queste stime troppo pessimistiche. 11