Sei sulla pagina 1di 4

Il Processo RUP come metodo Agile e spunti di pianificazione Rosario Turco

Larticolo 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 lUML; con strumenti adeguati a supporto della metodologia UML.

INCEPTION=Avviamento E lavvio 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

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 unopportunit 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, allassertivit, alla pazienza e una continua comunicazione: se consentita! Se lansia 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 nellElaborazione 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.

Lelenco 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. Lobiettivo di prevenire i problemi per sapere pianificare senza gli effetti nebbia che provocano i rischi tecnologici. In questa fase si fa unanalisi 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 linterazione con una GUI o il Web Modello del dominio del problema (analisi di alto livello) 2

Diagrammi dei package, per suddividere le aree di competenza/responsabilit del sw/le dipendenze Diagrammi di deployment generale, per avere unidea 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. Lelaborazione 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 dellElaborazione. I Casi duso vanno classificati in base a: priorit: rischio: alta, media, bassa. 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 allaltra (dimensionamento della P con T fisso). Lo sviluppo deve tener in grande considerazione anche parti di software auto-testate, che facilita le verifiche unitarie 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.

Le iterazioni devono considerare sviluppo/test/refactoring. Il refactoring pu includere anche lintroduzione 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 unattivit siano almeno due), in base a stime passate, a attivit collaterali e di disturbo storicamente presenti nellambiente. 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 settimaneuomo 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 il numero 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 dellambiente e dei ricicli del processo adottato nellazienda. 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.