Insegnamento di Gestione e Organizzazione dei Progetti · strategici del progetto e/o il program management. Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti

1

1Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti

Lezione 16:P.M.: metodologie di progetto

Prof.ssa R. Folgieriemail: [email protected]

[email protected]

Insegnamento diGestione e Organizzazione

dei ProgettiA.A. 2008/9


La metologia R.U.P.

MO

DE

LLI D

I CO

ND

UZI

ON

E D

I UN

PR

OG

ETT

O • Rational Unified Process (RUP) (estensione dello Unified Process): modello di processo softwareiterativo sviluppato da Rational Software (oggi parte di IBM).

• Il RUP definisce un framework di processi• Framework = struttura di supporto su cui un software

può essere organizzato e progettato. Alla base di un framework c'è sempre una serie di librerie di codiceutilizzabili con uno o più linguaggi di programmazione

• RUP è complesso perché adottabile in diversi contesti• È pensato soprattutto per progetti di grandi

dimensioni.• Rilasciato in formato di guida ipertestuale, nel prodotto

IBM Rational Method Composer (RMC), che permette anche la personalizzazione del processo.

2


Metodologia RUP - contestoRUP nasce da analisi campione di progetti software falliti. Tra i motivi di fallimento identificati :

•Gestione non standard dei requisiti •Comunicazione ambigua e non precisa •Architettura fragile (incapace di sopportare situazioni di particolare criticità) •Incapacità di gestire la complessità•Inconsistenze nei requisiti, nel progetto o nelle implementazioni•Collaudo insufficiente •Valutazione soggettiva dello stato del processo •Incapacità di affrontare il rischio •Propagazione non controllata delle modifiche •Insufficiente automazione

RUP è una collezione di best practices mirate a evitare problemi. E’ un ambiente di gestione dei processi che facilita l'applicazione di tali pratiche.Il processo fu progettato e descritto in termini di un metamodello O.O., espresso in UML

MO

DE

LLI D

I CO

ND

UZI

ON

E D

I UN

PR

OG

ETT

O


Metodologia RUP – concetti fondamentali

Nel RUP, il ciclo di vita di un processo software viene suddiviso in cicli di sviluppo, a loro volta scomposti in fasi:1. Inception Phase ("fase iniziale") 2. Elaboration Phase ("fase di elaborazione") 3. Construction Phase ("fase di costruzione") 4. Transition Phase ("fase di transizione")

Ogni fase prevede un insieme di obiettivi e si conclude con la realizzazione di un deliverable (prodotto).

Le fasi sono ulteriormente scomposte in iterazioni, associate a periodi temporali con deadline definite.

MO

DE

LLI D

I CO

ND

UZI

ON

E D

I UN

PR

OG

ETT

O

3


Metodologia RUP – inception phase• L'Inception Phase coincide, sebbene in modo più ampio, con il

concetto di analisi di fattibilità.• In questa fase il business case deve essere delineato nel

modo più preciso possibile, comprendendo il tipo di mercato al quale il progetto afferisce e identificando ogni elemento importante affinché si ottenga un successo commerciale.

• Fra gli strumenti utilizzati vi sono:• un modello dei casi d'uso,• la pianificazione iniziale del progetto,• la valutazione dei rischi,• una definizione a grana grossa dei requisiti e così via.

• Se il progetto non supera questa milestone, detta "LifecycleObjective Milestone", dovrà essere abbandonato o ridefinito.

MO

DE

LLI D

I CO

ND

UZI

ON

E D

I UN

PR

OG

ETT

O


Metodologia RUP – elaboration phaseQuesta fase definisce la struttura complessiva del sistema. Comprende l'analisi di dominio e un prima fase di progettazione

dell'architettura. L’eleboration phase deve concludersi con il superamento di una

milestone detta "Lifecycle Architecture Milestone“, in base alla quale devono essere soddisfatti i requisiti:

• il modello dei casi d'uso deve essere completo all'80% • si deve aver descritto l'architettura del sistema • l’architettura deve essere '"eseguibile“, cioè dimostrare il

completamento degli use case significativi • occorre aver eseguito una revisione del business case e dei

rischi• la pianificazione del progetto complessivo deve essere delineata

Se il progetto non passa questa milestone, potrebbe ancora essere abbandonato, oppure dovrà essere rivisitato. Al termine di questa fase si ha infatti un rischio più elevato, in cui le modifiche all'impostazione del progetto saranno più difficili e dannose.

MO

DE

LLI D

I CO

ND

UZI

ON

E D

I UN

PR

OG

ETT

O

4


Metodologia RUP – construction phase

• In questa fase viene portato a termine il grosso dello sviluppo.

• Viene prodotta la prima release del sistema.

• La milestone di questa fase si chiama "Initial Operational Capability"

e rappresenta la prima disponibilità delle funzionalità del sistema in

termini di implementazione.

MO

DE

LLI D

I CO

ND

UZI

ON

E D

I UN

PR

OG

ETT

O


Metodologia RUP – transition phase• Nella fase di transizione, il sistema passa dall'ambiente

dello sviluppo (ambiente di produzione e collaudo di sistema) a quello del cliente finale.

• Vengono condotte le attività di training degli utenti e il beta testing (collaudo funzionale o prerilascio) 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 "ProductRelease" e lo sviluppo termina.

MO

DE

LLI D

I CO

ND

UZI

ON

E D

I UN

PR

OG

ETT

O

5


Metodologia RUP – iterazioni• Un progetto gestito con RUP viene suddiviso in iterazioni.• I vantaggi sono molti (in particolare rispetto alla valutazione dell'avanzamento del progetto e alla gestione dei fattori di rischio) ma si ha, di conseguenza, overhead.

• La parola inglese overhead (letteralmente in alto, che sta di sopra) serve per definire le risorse accessorie, richieste in sovrappiù rispetto a quelle strettamente necessarie, per ottenere un determinato scopo in seguito all'introduzione di un metodo o di un processo più evoluto o più generale).

• RUP definisce una "Project Management Discipline" (disciplina di gestione dei progetti) a cui il project managerpuò affidarsi per amministrare le iterazioni.M

OD

ELL

I DI C

ON

DU

ZIO

NE

DI U

N P

RO

GE

TTO


Metodologia RUP – aspetti staticiIl metamodello applicato da RUP per descrivere e controllare un processo si basa su quattro concetti detti "statici", ovvero definiti nello stesso modo per tutti i processi:1.Ruoli. Un ruolo identifica un certo insieme di responsabilitàattribuite a un certo insieme di partecipanti al progetto. (chi?) 2.Artefatti (artifacts). Gli artefatti sono il prodotto delle attività del processo; includono documenti, modelli, componenti software e via dicendo. (cosa?) 3.Workflow. Una sequenza di attività. (quando?) 4.Attività. Le attività sono i compiti specifici portati a termine dai partecipanti del progetto. (come?)

MO

DE

LLI D

I CO

ND

UZI

ON

E D

I UN

PR

OG

ETT

O

6


Metodologia RUP – Link• Sito IBM (in italiano):http://www-142.ibm.com/software/dre/ecatalog/Detail.wss?locale=it_IT&synkey=L271254L87028R67

• White paper: http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf

MO

DE

LLI D

I CO

ND

UZI

ON

E D

I UN

PR

OG

ETT

O


Metodologia RUP – diffusione

Diffusione di RUPRUP è molto diffuso. Tra i motivi principali:

• stesse fonti di UML (Booch, Rumbaugh, Jacobson)

• forza commerciale di IBM-Rational

• più che un processo vero e proprio, fornisce un framework

di processo, cioè un quadro di riferimento generale da cui

creare processi specifici Come conseguenza, RUP può

essere utilizzato (con gli adattamenti opportuni) in qualunque

settore.

MO

DE

LLI D

I CO

ND

UZI

ON

E D

I UN

PR

OG

ETT

O

7


Metodologia RUP – vantaggiVantaggi• molto ben documentato.

• viene fornito sotto forma di sito web, ricco di linee guida,

template di documenti.

• esistono personalizzazioni già realizzate ("plug-in").

• molto utilizzato. E’ popolare anche nel mondo

accademico (almeno negli USA) ed in quello degli

standard. Lo SPEM (Software Process Engineering

Metamodel) dell'OMG (Object Management Group) è, di

fatto, derivato da RUP.MO

DE

LLI D

I CO

ND

UZI

ON

E D

I UN

PR

OG

ETT

O


Metodologia RUP – svantaggi1) RUP è un framework di processo da adattare al particolare contesto organizzativo, non un processo da usare "as is". E' interpretabile in modi molto diversi: anche se RUP nasce come processo iterativo, diverse organizzazioni lo interpretano stiracchiandolo in un approccio a cascata (il vecchio waterfall).In alcune realtà, invece, non viene effettuato alcun adattamento (richiede parecchio lavoro, e una buona competenza). L'utilizzo di RUP "as is" (senza adattamenti) èperò assolutamente sconsigliabile, in quanto si corre il rischiodi utilizzarlo in modo burocratico, inefficace e inefficiente.2) RUP è notevolmente complesso. Per potersi adattare a qualunque esigenza particolare, definisce decine di ruoli, centinaia di task e di documenti, e li descrive in migliaia di pagine.

MO

DE

LLI D

I CO

ND

UZI

ON

E D

I UN

PR

OG

ETT

O

8


Metodologia RUP - derivazioni

La complessità di RUP, ed il fatto che possa essere interpretato in modo burocratico, ha portato alcuni metodologi a cercare di integrarlo con approcci più agili, in particolare XP e Scrum (avrete infatti notato alcune analogie e punti comuni…).

Le derivazioni di RUP più interessanti sono al momento due:

1. OpenUp/Basic, in ambito Eclipse2. Essential UP, creato e sponsorizzato da Ivar JacobsonM

OD

ELL

I DI C

ON

DU

ZIO

NE

DI U

N P

RO

GE

TTO


Metodoloia RUP - derivazionihttp://www.eclipse.org/epf/openup_component/openup_vision.php

MO

DE

LLI D

I CO

ND

UZI

ON

E D

I UN

PR

OG

ETT

O

9


Metodoloia RUP - derivazionihttp://www.ivarjacobson.com/products.cfm

MO

DE

LLI D

I CO

ND

UZI

ON

E D

I UN

PR

OG

ETT

O


Prince 2La metodologia PRINCE2 (PRoject IN a Controlled Environment) deriva dalla PROMPT, creata dalla Simpact Systems nel 1975 per lo sviluppo software e adottata ufficialmente dal governo inglese. PRINCE e poi PRINCE2 sono diventate lo standard (obbligatorio) di project management nei progetti per enti governativi. Dal 1989 sono un "Open Source" reso disponibile a tutti attraverso lo OGC (Office of Government Commerce), che comprende la Central Computing and Telecommunication Agency. Lo OGC è il possessore dello standard, ma ha delegato gli aspetti di gestione della certificazione alla APM Group, che rilascia tutti i certificati. Chi propone corsi, materiali, approfondimenti e certificazione lo fa sotto l'autorità ispettiva dell' Apm Group. La metodologia è ovviamente molto diffusa in Gran Bretagna, ma anche in Olanda, parte della Germania e Australia. PRINCE2 si è esteso oltre il settore pubblico (solo il 20%) edè molto utilizzato in ambiente IT e telecomunicazioni.

Due siti di riferimento: www.prince2.org.uk www.ampgroup.co.uk M

OD

ELL

I DI C

ON

DU

ZIO

NE

DI U

N P

RO

GE

TTO

10


Prince 2 – concetti baseM

OD

ELL

I DI C

ON

DU

ZIO

NE

DI U

N P

RO

GE

TTO

PRINCE2® è una metodologia process-based, il cui scope si evince bene dalla figura:

Il focus è sul prodotto e sui benefici attesi, con particolare attenzione a mantenere il progetto "market oriented". Non vengono indicati tool di pianificazione da utilizzare, né vi sono orientamenti sulla gestione delle risorse umane, per consentire flessibilità e adattamento a progetti e settori differenti. Non vi sono prescrizioni neanche per gli aspetti strategici del progetto e/o il program management.


Prince 2 - principi

MO

DE

LLI D

I CO

ND

UZI

ON

E D

I UN

PR

OG

ETT

O Sono 4:1 - MBE (Manage By Exception) - il livello di management superiore vede solo gli eventi che esulano da parametri di controllo predefiniti. La metodologia, comunque, riporta molte responsabilità (non delegabili) ai livelli più alti.

2 - Business Case - durante tutto il progetto si è sempre attenti alla sua autorizzazione, pesando continuamente costi e benefici. Si matiene un vero e proprio documento, aggiornato dal PM e revisionato frequentemente dal Project Board.

3 - Default no go - il progetto deve continuamente provare la sua utilità ed èsottoposto ad approvazione di prosecuzione ad ogni stadio.

4 - Product Based Planning - l'unica tecnica obbligatoria è una pianificazione basata sul prodotto, partendo dalla PBS. Il metodo è volutamente molto piùattento al controllo del prodotto (specifiche, collaudi, modifiche, documentazione tecnica) che alle attività per realizzarlo.

11


Prince 2 - schema processi-componentiM

OD

ELL

I DI C

ON

DU

ZIO

NE

DI U

N P

RO

GE

TTO

Al centro dello schema, che rappresenta molta parte della metodologia PRINCE2, vi sono i processi. Intorno troviamo i componenti: per ognuno di essi vengono prescritti uno o più "living documents" da produrre e revisionare durante il progetto. Lo standard suggerisce anche alcuni template.


Prince 2 – componente documentale

MO

DE

LLI D

I CO

ND

UZI

ON

E D

I UN

PR

OG

ETT

O E’ importante tener presente alcuni punti:

Business case - L'attenzione continua al business case (un documento specifico) e alla misura del rapporto costi/benefici è sicuramente il punto centrale del metodo. La responsabilità va al Project Board, ma è il PM che costruisce e aggiorna il documento.

Flessibilità - tutti i processi sono da svolgere nel progetto, ma con livelli di profondità modulabile; l’unica tecnica obbligatoria è il Product Based Planning.

Qualità tecnica - PRINCE2 è la metodologia ideale per la realizzazione di prodotti tecnici (non solo SW), vista la grande attenzione all'aderenza alle specifiche e alla valutazione della qualità.

Attenzione al prodotto tecnico – E’ ritenuto molto importante anche il Configuration Management, cioé la documentazione e l’analisi di ogni richiesta o necessità di modifica del prodotto. Tutti i documenti devono essere archiviati, suddivisi in Specialist o Management Products.

12


Prince 2 - organizzazione del progettoM

OD

ELL

I DI C

ON

DU

ZIO

NE

DI U

N P

RO

GE

TTO

L’ambiente di PRINCE2 è principalmente basato su un ambiente Cliente/Fornitore. Il Project Board (in parte simile allo Steering Committee) presenta il Project Executive, che ha il compito di garantire il SUCCESSO del progetto, cioé di raggiungere i benefici previsti, ma anche il Senior User e Supplier, che condividono il Business Case.Il Senior User è l’owner del Business Case e ne è quindi il suo giudice primario, mentre il Senior Supplier è chi fornisce le risorse per l’operatività del progetto.


Prince 2 – il Project Board

MO

DE

LLI D

I CO

ND

UZI

ON

E D

I UN

PR

OG

ETT

O

Contrariamente allo Steering committee, il Project Board non ha il potere di operare scelte strategiche circa la priorità dei progetti attivi in azienda, ma rappresenta il gruppo di figure del Senior Management delegati sul singolo progetto. Il PB, come lo Steering Committee, ha però il potere di terminare il progetto se il Business Case non risulta più soddisfatto.

Il Project Board può delegare alcune funzioni di Assurance, come la qualità(intesa come qualità tecnica, relativa alle caratteristiche del prodotto) a persone del Project Assurance, che però NON fanno parte del gruppo di progetto e non rispondono al PM.

Alla partenza del progetto, il Corporate Management incarica un Project Executive di nominare un PM e procedere con lui alla pianificazione e all'impostazione di tutta la documentazione che poi sarà utilizzata e aggiornata nella fase esecutiva, di produzione dei deliverable. Si sottintende che Senior User, Executive e lo stesso PM fanno parte della società CLIENTE, cioè chi fruiràdei deliverable, mentre questi saranno fisicamente prodotti dall'organizzazionedalla quale proviene il Senior Supplier.

13


Prince 2 – il Senior SupplierM

OD

ELL

I DI C

ON

DU

ZIO

NE

DI U

N P

RO

GE

TTO

Il ruolo del SS nel Project Board è proprio quello di essere il facilitatore in caso di conflitti sulle risorse operative e produttive, essendone il loro rappresentante e "owner".

Il Supplier è inteso come un macro-fornitore di risorse, team produttivi e Team leaders. Infatti, il Supplier viene sostanzialmente ipotizzato come unico; l'organizzazione cliente coordina il progetto e ne valuta continuamente i costi/benefici (e l'opportunità di continuare a investire!).

Si pensi alla nascita in un ambito governativo del PRINCE2®, concucendol'analogia con un Ministero (l'organizzazione cliente) che coordina l'attività di un main contractor su un progetto, da rifinanziare semestre per semestre e la cui utilità va continuamente dimostrata.


Prince 2 – il ruolo del Project Manager

MO

DE

LLI D

I CO

ND

UZI

ON

E D

I UN

PR

OG

ETT

O Il PM è il controllore del progetto, prepara i piani e i (numerosi) report sul lavoro svolto (eventualmente aiutato dal Project Support, con compiti di staff) e autorizza i vari Work Package, ovvero le unità produttive del processo.

Il PM può fare decision making ma solo all'interno delle "Tolerances" (su tempi e costi) concordate con il Project Board, che resta il decisore su ogni passo del progetto. Quando un evento fa deragliare dal piano concordato il PM produce vari report sullo scenario e genera un Exception Plan, da sottoporre per approvazione al PB.

Per facilitare il controllo, PRINCE2 suggerisce di suddividere la fase di esecuzione in STAGES: la pianificazione dettagliata si fa solo fino allo stage successivo ma, soprattutto, al termine di ogni stage si aggiorna il Business Case, il Project Board valuta i prodotti dello stage e decide se passare al successivo (o terminare il progetto). Anche le "Tolerances" piuttosto che i Contingency Plans si assegnano solo stage per stage.

14


Prince 2 – il PM, considerazioniM

OD

ELL

I DI C

ON

DU

ZIO

NE

DI U

N P

RO

GE

TTO

PM molto coordinatore e poco Manager (responsabilità sono del Project

Executive e/o Project Board).

Il PM PRINCE2® non è il PM forte, assegnatario e gestore delle risorse, che

ha la leadership nel team e che si rapporta e negozia ad ogni livello con tutti

gli stakeholder di progetto. E’ piuttosto un “portavoce“ esecutore del Project

Board. Trattandosi in genere di progetti molto ampi e costosi, il Procurement

Management è nelle mani del Project Board, con il PM garante dei contenuti

tecnici di quanto consegnato dai fornitori.


Prince 2 - certificazioni

MO

DE

LLI D

I CO

ND

UZI

ON

E D

I UN

PR

OG

ETT

O Per un individuo, vi sono due livelli di certificazione: Foundations e Practitioner.

Ottenere la certificazione Foundations è particolarmente veloce: dopo un corso di introduzione di un paio di giornate circa, su materiali molto schematici, si sostiene una prova con 75 domande a scelta multipla. Si ottiene la certificazione se si forniscono almeno 38 risposte esatte. Il 95% dei candidati passa l'esame. Ad oggi, nel mondo, vi sono 100.000 persone certificate Foundations.

Practitioner è basato sullo studio di un libro più approfondito e su un corso di circa 3 giorni, nel quale si applicano tutti i processi, gli strumenti e la documentazione di PRINCE2® a case studies. Di fatto, si percorrono tutti i passi dall’inizio di un progetto alla sua chiusura. L'esame è su casi, a risposta aperta e il tasso di successo è circa il 65%. Si stimano 20.000 persone certificate come Practitioner.

Per ora tutta la documentazione e i gli esami sono in lingua inglese, ma è in corso la traduzione in italiano.

15


Prince 2: riferimenti webM

OD

ELL

I DI C

ON

DU

ZIO

NE

DI U

N P

RO

GE

TTO

http://www.prince2.ch/it/prince2_tm/

Documents

Insegnamento di Gestione e Organizzazione dei Progetti · strategici del progetto e/o il program management. Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti