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

1

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) 2

   

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à: 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 all’altra (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.

3

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 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 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.

4

Sign up to vote on this title
UsefulNot useful