IT Project Management - Lezione 2 -Ciclo di vita del

IT Project Management
Lezione 2 – Ciclo di vita del progetto
Federica Spiga
A.A. 2010-2011
1
Ciclo di vita del progetto
Il ciclo di vita del progetto definisce le fasi che
collegano l’inizio e la fine del progetto stesso.
Rappresenta un modello prescrittivo che aiuta ad
organizzare le attività del progetto.
Stabilisce l’approccio interno che si intende adottare e
descrive il processo che si vuole seguire
Descrive anche i contenuti del progetto e le attività che
si devono eseguire ed i relativi artefatti (“deliverables”)
2
Ciclo di vita del progetto
Non esiste un modo in assoluto migliore per definire il
ciclo di vita del progetto.
Alcune strutture organizzative hanno adottato delle regole che
consentono di standardizzare tutti i progetti attraverso un solo
ciclo di vita, mentre altre strutture organizzative preferiscono
affidare al gruppo di Project Management la scelta del ciclo di
vita migliore per il progetto assegnato al gruppo.
Le pratiche comunemente adottate nel settore specifico
conducono generalmente all’utilizzo di un ciclo di vita
preferenziale per il settore in questione (es RUP per progetti di
sviluppo software)
3
Ciclo di vita di un progetto: PM approach
4
PMBOK – Project Management Areas & Processes
5
PMBOK – Project Management Areas & Processes
6
Criteri di scelta del processo di sviluppo
La strategia di sviluppo del software stabilisce la modalità con cui si condurrà il
progetto e la realizzazione del prodotto finale. Dipende da:
Caratteristiche del prodotto: requirements chiari e stabili oppure instabili o
confusi, funzionalità, livello di prestazioni, ecc
Tipologia di rilascio: rilascio singolo, rilasci multipli
Grado di coinvolgimento del cliente nel progetto: determina la tipologia e
quantità di review, documentazione formale. Alto coinvolgimento fa aumentare i
costi, ma assicura una maggiore comprensione dei requisiti, basso
coinvolgimento riduce i costi, ma aumenta la probabilità che ci possa essere uno
scollamento dalle aspettative del cliente
Costi/budget di progetto: costi calcolati su requirements vaghi o ben precisi??
E’ un budget fisso oppure c’è una possibilità di negoziare dei cambi di budget?
7
Ciclo di vita del Software – Modello a Cascata (Waterfall)
Requisiti stabili
Adatto quando è richiesto un solo rilascio
Durata del progetto ben definita e non troppo lunga (per avere la
certezza di mantenere i requisiti)
Una fase inizia dopo che la precedente è terminata
Responsabilità precise per ogni documento o artefatto
Ruoli differenti
Comunicazione tramite documenti (chiamato anche Document
Based)
Processo stabilito e formale
Modificare un sistema software in fase di avanzato sviluppo è
troppo costoso: Meglio fare tutti gli sforzi possibili per farlo giusto sin
dal principio!
Si portano anche nel software le tecniche dell’ingegneria
8
Ciclo di vita del Software – Modello a stadi (Staged)
Analisi dei requisiti e
progettazione preliminare
effettuata per l’intero progetto
Progetto scomposto in più
componenti
•I componenti più critici o
prerequisiti vengono
sviluppati subito (1° stadio)
•Gli altri vengono sviluppati
in fasi successive
Adatto quando il prodotto
finale può essere rilasciato in più
step
Struttura dell’intero prodotto è
conosciuta sin dall’inizio
9
Ciclo di vita del Software – Modello prototipale
Due cicli distinti:
Prototipo
prodotto
Ci si concentra nella analisi, design, test del
prototipo al fine di acquisire informazioni sul
prodotto
Quando finisce la fase prototipale si inizia
la fase di realizzazione del prodotto vera e
propria
Adatto anche per investigare su parti
critiche
VANTAGGI :
•Coinvolgere il cliente/utente
•Far emergere funzionalità/servizi non
considerati o poco chiari
•Rilasciare “presto” una versione del
sistema, magari ridotta, che dà fiducia al
cliente sulla riuscita del progetto
•Scrivere meglio le specifiche di qualità
del sistema finito
RISCHI:
•Si potrebbero allungare i tempi di sviluppo e
aumentare la dinamica dei requisiti
• Nel caso di prototipi fatti evolvere nei prodotti
finali, spesso il codice non più utilizzato non
viene cancellato: aumenta il volume e la
complessità strutturale del prodotto
10
Ciclo di vita del Software – Modello iterativo
Rappresenta uno scambio continuo di
feedback tra la fase di sviluppo e le attività
svolte o in corso
Adatto allo sviluppo di appplicazioni OO
Il numero di iterazioni e di fasi non è
previsto a priori, ma dipende dal
raggiungimento degli obiettivi di progetto
Adatto a progetti di grandi dimensioni,
complessi e con requisiti non stabili
VANTAGGI:
•Il prodotto è scomposto in sotto
prodotti ed anche il processo può essere
spezzato di conseguenza
•Si può iniziare a lavorare sulle parti più
critiche, dove serve un rapido feedback
da parte del cliente
•Gli utenti possono incominciare a
testare delle parti rilasciate, mentre le
altre sono ancora in sviluppo
11
Ciclo di vita del Software – Modello iterativo - incrementale
Estensione del modello iterativo
Ciclo di vita come serie di singoli cicli completi di sviluppo (“iterazioni”), che permettono il
rilascio in esercizio di una serie completa di funzioni
Ogni iterazione INCREMENTA le funzionalità del prodotto finora rilasciate
Il modello permetti di rendere disponibili all’utente in esercizio parti di prodotto
autoconsistenti
Adatto a progetti di grandi dimensioni, complessi, con requisiti non stabili e che permetta la
suddivisioni in parti di prodotto autoconsistenti
12
Ciclo di vita del Software – Modello a spirale (Bohem, 1988)
Combina la natura iterativa della prototipazione e
quella sistematica e controllata del modello linearesequenziale
Il software viene sviluppato in versione sempre
più raffinate. Si può partire anche da un prototipo
cartaceo
Il modello prevede 4 (o 6) fasi (dette task regions),
per ognuna delle quali sono definite delle attività
specifiche.
Le attività da svolgere variano secondo la
complessità del progetto
Ciclo di vita come lo sviluppo di una serie di
prototipi, sempre più completi ed evoluti, fino al Le attività vanno svolte a partire dall’inizio del
prodotto finale.
progetto, seguendo la spirale in senso orario
Adatto a progetti con requisiti non stabili e
Ad ogni giro corrisponde un raffinamento:
tecnologie poco conosciute
al primo le specifiche, al secondo un
semplice prototipo, poi prototipi sempre più
completi
Il modello si può applicare anche a progettidi
manutenzione migliorativa-evolutiva
13
Processo di sviluppo – Unified Processes ( es Rational Unified
Process)
Processo industriale per lo sviluppo del software, per ottenere:
•Prodotti di qualità
•Prodotti rispondenti ai requisiti dell’utente
•Controllo forte dei tempi e dei costi di progetto
Racchiude in se le “best practice” del settore
Guidato dai casi d’uso (“Use Case”)
Fondato sull’architettura
Iterativo e incrementale
14
Processo di sviluppo – Rational Unified Process (RUP)
Nel RUP, il ciclo di vita di un processo software viene suddiviso in cicli di sviluppo, a loro volta
scomposti in fasi. Le fasi previste sono:
•Inception
Inception Phase (fase iniziale)
•Elaboration Phase (fase di elaborazione)
•Construction Phase (fase di costruzione)
•Transition Phase (fase di transizione)
Ogni fase ha un certo insieme di obiettivi e si conclude con la realizzazione di un deliverable
(prodotto) di qualche genere. Le fasi sono ulteriormente scomposte in iterazioni, che sono associate a
periodi temporali e hanno deadline precise.
15
Processo di sviluppo – Rational Unified Process (RUP) - Fasi
Inception Phase
L'Inception Phase si può considerare come una particolare elaborazione e precisazione del concetto
generale di analisi di fattibilità.
Visione
Visione approssimativa del progetto
Studio economico
Stime approssimative di costi e tempi
Elaboration Phase
La fase di elaborazione definisce la struttura complessiva del sistema. Questa fase comprende l'analisi
di dominio e un prima fase di progettazione dell'architettura.
Visione raffinata del progetto
Implementazione dell’architettura (la parte più complessa del sistema)
Risoluzione dei rischi maggiori
Identificazione della maggior parte dei requisiti
Stime raffinate di costi e tempi
16
Processo di sviluppo – Rational Unified Process (RUP) - Fasi
Construction Phase
In questa fase viene portato a termine il grosso degli sviluppi. Viene prodotta la prima release del
sistema . Rappresenta la prima disponibilità delle funzionalità del sistema in termini di
implementazione.
Transition Phase
Nella fase di transizione, il sistema passa dall'ambiente dello sviluppo a quello del cliente finale.
Vengono condotte le attività di training degli utenti e il beta testing del sistema a scopo di verifica e
validazione. Si deve in particolare verificare che il prodotto sia conforme alle aspettative descritte
nella fase di Inception. Se questo non è vero si procede a ripetere l'intero ciclo; altrimenti, si
raggiunge la milestone detta "Product Release" e lo sviluppo termina.
Iterazioni
Tipicamente, un progetto gestito usando il RUP viene suddiviso in iterazioni. Questa scomposizione
presenta numerosi vantaggi (in particolare rispetto alla valutazione dell'avanzamento del progetto e
alla gestione dei fattori di rischio) ma implica un overhead specifico. Il RUP definisce una "Project
Management Discipline" (disciplina di gestione dei progetti) a cui il project manager può affidarsi per
amministrare le iterazioni
17
Processo di sviluppo – Rational Unified Process (RUP)
18
Ciclo di vita di un progetto
Processo di
sviluppo
software
19