Il Processo RUP come metodo Agile e spunti di pianificazione

7/16/2019 Il Processo RUP come metodo Agile e spunti di pianificazione

http://slidepdf.com/reader/full/il-processo-rup-come-metodo-agile-e-spunti-di-pianificazione 1/4

1

Il Processo RUP come metodo Agile e spunti di pianificazione

Rosario Turco

L’articolo presuppone una organizzazione che abbia la possibilità di mettere in piedi un processo Rational

Unified Process (RUP) per sviluppare e pianificare un sistema in ambito Object Oriented, evitando situazioni

di team “Object Disoriented”.

E’ chiaro che stiamo parlando di usare una metodologia OO, rappresentabile attraverso l’UML; con

strumenti adeguati a supporto della metodologia UML.

INCEPTION=Avviamento

E’ l’avvio del progetto da parte del Demand e del PM. Sono, quindi, individuati Business case, Portata del

business, Costo, Ricavi, Sicurezza, Architettura generale.

ELABORATION=Elaborazione

I rischi possono essere molteplici ma almeno quattro si presentano sempre:

Rischi di requisito

Rischi tecnologici e di integrazione

Rischi di numero di persone e know-how

Rischi politici



2

Il rischio politico è quello che non ha nessuna possibilità di gestione tecnica, ma è legato a politiche

aziendali, di interessi vari, di norme di legge etc. che qui non staremo ad indagare; ma che possono

costituire una minaccia o un’opportunità per il team chiamato a sviluppare il progetto. Sono minaccia se

influiscono negativamente su Portata dei requisiti, Tempo e Qualità.

Sono da aggiungere anche una serie di rischi psicologici presenti in tutte le fasi:

ansia del cliente

importanza e peso del sistema

prestigio del cliente

scarsa fiducia del fornitore

Tutto questo richiede al team una preparazione allo stress, all’assertività, alla pazienza e una continua

comunicazione: se consentita! Se l’ansia o il peso o il prestigio è troppo sentito o il clima non è corretto si

sfocia nella psicologia del “bastonatore e del branco di lupi” o dei “falchi e le colombe”, che è poco

costruttivo e tende a creare colpe e paure, con effetti deleteri.

In questa fase per ottenere un corretto management del progetto è importante fare:

Gestione dei rischi, Pianificazione e Piano di sviluppo

Per ottenere questo occorre, innanzitutto, descrivere i Requisiti con gli Use Case. Si lavora a raffinamenti

sugli Use Case, cioè nell’Elaborazione si devono individuare tutti gli Use Case ma a livelli di raffinamento

diverso:

alcuni solo abbozzati ma chiari come intento (verranno raffinati nelle Iterazioni della fase di

Costruzione) descritti bene e completamente i più importanti e più rischiosi.

L’elenco degli Use Case permette di iniziare a chiarire due aspetti:

Quanto tempo ci vuole o come suddividere le iterazioni nella fase di Costruzione

Quali sono i più rischiosi che vanno fatti prima

Quante persone sono necessarie e con quali ruoli

In fase di elaborazione occorre chiarire le tecnologie/metodologie che soddisfano il problema che il sistema

deve risolvere, riducendo i rischi tecnologici e di integrazione come mettere insieme varie parti o varie

tecnologie o cosa possa andare storto e come si potrebbe ovviare al problema.

Qui si determina anche il know how necessario.

L’obiettivo è di prevenire i problemi per sapere pianificare senza gli “effetti nebbia” che provocano i rischi

tecnologici.

In questa fase si fa un’analisi che tira fuori non solo gli Use Case a raffinamento diverso, ma a seconda della

necessità (le voci sottolineate sono da considerarsi obbligatorie) o meno anche di:

Glossario di progetto

Diagrammi di Robustezza che chiarisce l’interazione con una GUI o il Web

Modello del dominio del problema (analisi di alto livello)



3

Diagrammi dei package, per suddividere le aree di competenza/responsabilità del sw/le

dipendenze

Diagrammi di deployment generale, per avere un’idea di come il sw si splitta sulle varie macchine

Diagrammi di interazione principali (Sequence)

Activity Diagram se vi è una forte componente di workflow, flusso e processo; tuttavia essi sono

fondamentali per evidenziare responsabilità, cose da automatizzare in un processo manuale, o se

determinate attività se vanno in parallelo o in modalità sequenziale.

Sul Dominio del problema incidono gli Use Case principalmente.

La prima cosa da prevedere è un prototipo degli Use case sia dei diagrammi di robustezza per la GUI e/o

parte Web che del sistema circa le parti critiche degli Use Case. Il prototipo deve chiarire se si è compreso

lo/gli Use Case rischiosi e se si è superato il rischio e quanto tempo reale servirà a realizzare la parte

completa.

L’elaborazione si avverte conclusa quando:

Sono stati individuati tutti i rischi più significativi

si riesce a stimare quanto tempo occorre per un insieme di Use case nella iterazione #1 della fase

di Costruzione, con un errore al massimo di una settimana. Il team è più sicuro, affidabile e preciso.

Costruzione

E’ importante pianificare le iterazioni della fase di Costruzione, già a valle dell’Elaborazione.

I Casi d’uso vanno classificati in base a:

priorità: alta, media, bassa.

rischio: alto, medio, basso

La priorità alta individua gli Use case che conducono alla parte importante del sistema (sistema “core”). A

questo punto si inizia a pianificare/stimare in giorni/uomo gli Use Case a priorità alta e rischio alto.

Le iterazioni devono avere un periodo fisso e devono prevedere: analisi, progettazione, test unitario,

documentazione. Le iterazioni sono fisse (T fisso), si possono invece spostare solo gli Use Case da una

iterazione all ’ altra (dimensionamento della P con T fisso).

Lo sviluppo deve tener in grande considerazione anche parti di software auto-testate, che facilita le verificheunitarie a seguito di modifiche e refactoring, le regressioni.

Le iterazioni sono incrementali perché si aggiungono Use Case/funzionalità in base alle priorità/rischi e

sono iterativi, cioè si fa refactoring per rendere più flessibile il software a fronte di altre aggiunte.

Sono importanti quindi le tre variabili non ortogonali:

P=portata dei requisiti in una iterazione,

Q=qualità (refactoring, software auto testante etc.),

T=tempo di iterazione.



4

Le iterazioni devono considerare sviluppo/test/refactoring. Il refactoring può includere anche l’introduzione

di flessibilità attraverso Design Pattern prima non evidenti.

Una iterazione dovrebbe prendere in seria considerazione anche il Continuos Integration per anticipare

problemi e rischi di sviluppo e i simulatori .

Le stime risentono del fattore di carico del team e/o della coppia di sviluppo (preferibile che su un ’attività

siano almeno due), in base a stime passate, a attività collaterali e di disturbo storicamente presenti

nell’ambiente.

Ad esempio supponendo una durata di iterazione (Di) di 4 settimane o 20 giorni, con 5 persone (Np) e un

fattore di carico 2 (Fc) si ottiene che la velocità di produzione del team che è VP = 5*4*1/2 = 10 settimane-

uomo o VP = 5 * 20 * 1/2 = 50 gg-uomo:

Vp = Di * Np / Fc

Sapendo i gg-uomo totali (Tg) per i 3 gruppi di use case da realizzare e dividendolo per VP si ottiene ilnumero di iterazioni (Ni) necessarie:

Ni = Tg / Vp

Gli sviluppatori dovrebbero essere totalmente concentrati allo sviluppo (Fc = 1 ma in realtà non è così),

mentre gli analisti sono più presi da riunioni di analisi/requisiti in determinati periodi e o di dalle fasi di

Transizione (test, verifica anomalie, analisi per la rimozione errori, verifica del processo etc.).

Dovendo qui pianificare anche per il periodo di Transizione occorrerebbe, a seconda della situazione,

prevedere da un minimo del 20% ad un massimo del 40% del tempo di Costruzione.

Alla pianificazione finale occorre aggiungere la contingency del 10% - 20% (non sovrastimata né

sottostimata). Il valore dipende anche dal conoscenza storica dell’ambiente e dei ricicli del processo

adottato nell’azienda.

A questo punto inizia il raffinamento di quanto presente dalla Elaborazione e diventano importanti i

diagrammi dei package, dei componenti, dei deployment ed i Design Pattern.

Transizione

In questa fase si fanno soprattutto i test interni (di sistema), di integrazione con altri sistemi (in sviluppo).

In realtà i test di sistema vanno progettati prima nella fase di Costruzione (durante ogni iterazione). Gli

analisti a partire dagli Use Case e il loro raffinamento scrivono i test. I test di sistema vanno effettuati ad

ogni fine iterazione di un sistema auto-consistente. Si consiglia di usare strumenti di bug-tracking (open

source o aziendali).

La fase finale della Transizione è il collaudo a cui segue anche la certificazione/prestazionale.

Il Processo RUP come metodo Agile e spunti di pianificazione

Documents

Transcript of Il Processo RUP come metodo Agile e spunti di pianificazione