Concetto: Implementazione di un processo in un progetto
Questa pagina di concetto descrive il piano di sviluppo globale per implementare un processo ed i suoi tool di supporto in un progetto di sviluppo di software.
Relazioni
Elementi correlati
Descrizione principale

Introduzione

Queste linee guida descrivono come implementare il processo ed i tool in un progetto di sviluppo di software eseguendo le attività descritte nella disciplina Ambiente. Tratta inoltre della disciplina Gestione del progetto, relativa alla pianificazione del progetto, all'identificazione dei rischi e alla gestione, monitoraggio e valutazione del progetto.   

E' importante comprendere che esistono diversi modi di implementare il processo e i tool, come descritto nella sezione "Approcci all'implementazione del processo e dei tool". La scelta dell'approccio dipende dallo stato corrente del progetto e dall'organizzazione che lo circonda, quindi effettuare una valutazione del progetto e dell'organizzazione circostante (consultare  Prodotto di lavoro: Valutazione dell'organizzazione di sviluppo). 

Queste linee guida descrivono alcuni possibili approcci per implementare un processo in un progetto.   Inoltre, Concetto: Pratiche di ambiente descrive alcune pratiche fondamentali utili per l'implementazione dell'ambiente di un progetto software.  Per ulteriori informazioni sugli aspetti della personalizzazione processo dell'implementazione di un processo, consultare Personalizzazione di RUP.

Linee guida generali sulla pianificazione

Queste linee guida generali riguardano quasi tutti i progetti: 

  • Prima di iniziare il progetto: prima che un progetto abbia effettivamente inizio, le persone che agiscono da tecnici del processo, specialisti e responsabili di progetto devono essere istruiti su RUP (Rational Unified Process). Questo è di importanza cruciale per il successo del progetto. Se i membri del progetto non sanno cosa fare, con tutta probabilità non riusciranno nell'intento.
  • Fase di inizio: durante questa fase in genere si concentra l'attenzione sul come migliorare le proprie modalità di gestione dei requisiti (disciplina Requisiti) e su come gestire il progetto (disciplina Gestione del progetto). 
  • Fase di elaborazione: al termine della fase di elaborazione tutti i processi ed i tool sono pronti. La parte più critica di questa fase spesso è come eseguire la gestione della configurazione e delle modifiche poiché nella fase di costruzione il lavoro viene eseguito dai team di sviluppo che lavorano in parallelo.
  • Fase di costruzione: in questa fase non vengono introdotti nuovi processi o tool. Il punto focale qui è produrre il prodotto, quindi l'ambiente di sviluppo deve essere stabile. Nella fase di costruzione la motivazione è di portare al passo con gli altri le persone nuove al progetto.
  • Fase di transizione: non vengono introdotti nuovi processi o tool. Nella fase di transizione, il punto focale passa dal miglioramento del processo specifico per progetto ai post-mortem del progetto, raccogliendo le esperienze del progetto dal progetto corrente, riassumendole e creando un pacchetto in un formato utilizzabile dai progetti futuri.  Queste esperienze raccolte servono da input per migliorare il processo ed i tool nello sviluppo della successiva evoluzione de prodotto.

Approcci all'implementazione del processo e dei tool

La cerimonia del processo varia di molto nelle diverse organizzazioni di sviluppo. Alcune sono molto mature e dispongono di gruppi dedicati al processo che si occupano della definizione e dei miglioramenti del processo in tutta l'organizzazione. Altri si occupano solo della personalizzazione specifica per il progetto.

L'approccio intrapreso per personalizzare il processo del progetto dipende significativamente dalla cerimonia del processo dell'organizzazione, oltre che da diversi altri fattori.  Ad esempio:

  • La maturità del processo dell'organizzazione di sviluppo.
  • La dimensione del progetto in termini di calendario e numero di risorse di sviluppo.
  • La precedente esposizione dei membri del progetto a processi simili.
  • I requisiti di formalità del progetto.

Per ulteriori informazioni sui fattori che influiscono sull'implementazione del processo consultare Linea guida: Discriminanti del processo.

Quelli che seguono sono gli approcci base all'implementazione del processo e dei tool in un progetto di sviluppo software: 

  • "Modificare tutto". Questo significa che il progetto adotta l'intero RUP ed una serie completa di nuovi tool.  
  • "Migliorare il processo ed i tool". Questo significa che il progetto decide di migliorare alcune aree del processo e dei tool adottando le parti di RUP e supportando i tool.  

Quanto RUP adottare e quanti nuovi tool implementare su uno specifico progetto dipende da diversi fattori.  Questi fattori sono descritti in Linea guida: Discriminanti del processo.  Questi sono dei fattori che in genere vengono rilevati durante una valutazione del progetto e dell'organizzazione circostante. Queste informazioni vengono catturate in  Prodotto di lavoro: Valutazione dell'organizzazione di sviluppo.

"Modificare tutto" (torna ad Approcci...)

Un progetto può decidere di adottare il RUP completo ed iniziare ad usare una nuova serie di tool per uno o più motivi: 

  • Non sono disponibili né il processo né i tool ed il progetto ha bisogno di tutto (un processo completo e tutti i tool). 
  • Tutte le persone o quasi sono nuove assunzioni e non esiste un metodo di lavoro comunemente accettato.  
  • Il progetto passerà ad una nuova tecnologia per l'organizzazione, il che significa che il processo ed i tool esistenti diverranno obsoleti.  

Se si decide di introdurre nel progetto il RUP completo ed i tool, è importante implementare il processo ed i tool in modo incrementale. Implementando il processo e i tool con una procedura strutturata in fasi, è più facile gestire i rischi e rende le modifiche meno opprimenti per le persone del progetto. Il diagramma riportato di seguito illustra quando vengono sviluppati i prodotti di lavoro dell'ambiente diverso nel ciclo di vita di un progetto.  

 Diagramma descritto nel testo di accompagnamento.

L'evoluzione dei prodotti di lavoro in un progetto dove "tutto è nuovo".

Commenti sul piano:
  • Generale: la disciplina Modellazione del business viene ignorata completamente. 
  • Inizio: focalizzazione sull'introduzione delle discipline Requisiti e Gestione del progetto. Per ridurre il numero di nuovi fattori, non vengono introdotte le parti dei Requisiti relative all'interfaccia utente. Il responsabile di progetto decide quali parti della disciplina Gestione del progetto utilizzare.  
  • Iterazione Elaborazione E-1: Analisi e progettazione e Architettura sono le più importanti nella fase Elaborazione. Test automatizzato e Configurazione e gestione delle modifiche non sono cruciali in questa prima parte del progetto perché il numero dei membri del progetti è relativamente basso. Questo può essere introdotto successivamente nel progetto.  
  • Iterazione Elaborazione E-2: vengono introdotti il processo ed i tool di test per una verifica automatizzata. Viene introdotto Rational RequisitePro per gestire i requisiti che cambiano.
  • Iterazione Elaborazione E-3: nella fase Costruzione, il lavoro verrà eseguito dai team di sviluppo che lavorano in parallelo. Quindi è cruciale disporre della disciplina Configurazione e gestione delle modifiche al termine della fase di elaborazione. Il responsabile dello sviluppo decide come eseguire la disciplina nella disciplina Sviluppo.  
  • Costruzione: non viene introdotto nulla di nuovo. Da una prospettiva dell'ambiente, il punto focale durante la fase Costruzione è portare al passo con gli altri tutte le nuove persone del progetto.
  • Transizione: non è stato introdotto nulla di nuovo. Il processo ed i tool vengono perfezionati, se necessario.

"Miglioramento del processo e dei tool" (torna ad Approcci...)

Le persone di un progetto in un'organizzazione in cui processo e tool sono disponibili, hanno la capacità di sviluppare un sistema. Queste persone hanno un comune metodo di lavoro, che è un processo che può essere documentato più o meno bene.  

L'obiettivo a lungo termine può essere di adottare il RUP completo ed una serie completa di nuovi tool. Tuttavia, l'obiettivo a breve termine è di migliorare in una o più aree del processo e del supporto di tool. Dovrebbe trattarsi di aree con alto potenziale di miglioramento.  

Il diagramma riportato di seguito mostra l'esempio di un progetto che ha deciso di adottare la disciplina Requisiti ed i tool, ad esempio RequisitePro e Rational Rose, per migliorare il modo in cui sono gestiti i requisiti. Il progetto ha deciso anche di introdurre la disciplina Analisi e progettazione.  

Diagramma descritto nel testo di accompagnamento.

L'evoluzione dei prodotti di lavoro Ambiente quando si migliorano Requisiti e Analisi e progettazione.  

E' importante capire che il diagramma precedente è solo un esempio. Le parti del processo su cui si decide di effettuare miglioramenti saranno diverse fra i progetti, a seconda dei problemi e delle esigenze di un particolare progetto. È necessario valutare il progetto e l'organizzazione circostante per individuare le parti del processo che si desidera migliorare o quali tool si desidera introdurre.

Esempio di iterazione Inizio

Quello che segue è un esempio di un'iterazione nella fase di inizio dove viene introdotta la disciplina Requisiti. Ogni voce del grafico di Gantt viene descritta in dettaglio dopo il diagramma.  

Gestione del progetto Piano per successiva iterazione Valutazione ambito e rischio del progetto Pianificazione progetto Gestione iterazione Monitoraggio e controllo del progetto Concepimento nuovo progetto Valutazione ambito e rischio del progetto Requisiti Verifica Ambiente Supporto ambiente durante un'iterazione Preparazione ambiente per progetto Preparazione ambiente per un'iterazione Mentore processo 50% Mentoring RMUC RUPF Formazione Mentore requisiti 50% Fare clic su un argomento per una descrizione dettagliata

Esempio di un'iterazione della fase Inizio

E' valido il flusso di lavoro base descritto per Inizio RUP classico con queste variazioni ed estensioni.

Gestione del progetto

Portare il progetto dal germe iniziale di un'idea ad un punto in cui può essere presa una decisione motivata per continuare o abbandonarlo. I risultati principali sono delle bozze iniziali di Prodotto di lavoro: Scenario businessProdotto di lavoro: Piano di sviluppo di softwareProdotto di lavoro: Elenco dei rischi.

Identificare i rischi del progetto, inclusi quelli associati all'implementazione del nuovo processo e dei tool. Il risultato è il Prodotto di lavoro: Elenco dei rischi.

Pianificare le fasi. Il risultato principale è la sezione intitolata Piano del progetto nel Piano di sviluppo software. Include il Piano delle fasi, in cui sono presenti i principali punti cardine con i relativi criteri di ottenimento, inclusi quelli per la disciplina Ambiente.    
Nota: il Processo di sviluppo personalizzato ha un grosso impatto sul Piano di sviluppo software, e viceversa. Quindi lo sviluppo del piano del progetto e la personalizzazione del processo devono essere coordinati.  

Pianificare l'iterazione in dettaglio, inclusa la disciplina Ambiente e tutte le altre discipline. Il risultato principale è un Prodotto di lavoro: Piano di iterazione, con tutti i dettagli delle attività ed i compiti della disciplina Ambiente, oltre a tutte le altre discipline del processo.

L'utilizzo del processo e dei tool viene stimato come parte della valutazione dell'iterazione. I risultati sono:

Il responsabile del progetto monitora il lavoro della giornata, incluso il processo ed i tool.

Al termine dell'iterazione, i rischi vengono rivalutati, inclusi quelli associati al processo e ai tool. Alcuni rischi vengono mitigati durante l'iterazione e vengono identificati i nuovi rischi. Il risultato primario è un Prodotto di lavoro: Elenco dei rischi.  

Requisiti

Nessuna modifica specifica. 

Test

Vengono definiti alcuni aspetti logistici del Prodotto di lavoro: Strategia di test, che forniscono il ragionamento iniziale per l'assegnazione di risorse all'impegno di test.

Il progettista di test ed un piccolo team di tester verifica che gli elementi chiave dell'approccio di test siano validi per il Prodotto di lavoro: POC (Proof-of-Concept) strutturale e che le selezioni di componenti di terze parti siano stati comprovati come testabili.

Ambiente

Valutare lo stato corrente dell'organizzazione e decidere su quali parti del processo e dei tool si desidera concentrare l'attenzione nelle prime iterazioni. In questo caso il progetto ha deciso, in base alla valutazione, di iniziare ad implementare il processo ed i tool.  
Nota: il Piano di sviluppo software ha un forte impatto sul Processo di sviluppo personalizzato e viceversa. Quindi, la personalizzazione del processo e lo sviluppo del piano del progetto devono essere coordinati.  

I risultati sono:

Preparare il processo ed i tool per la disciplina Requisiti insieme ai tool di supporto, in modo che le persone del progetto possano iniziare ad utilizzarli. (Naturalmente possono essere preparate altre discipline). Consultare Compito: Personalizzazione del processo di sviluppo per il progetto .

Assicurarsi che le persone del progetto sappiano come utilizzare il processo di sviluppo, le linee guida sulla modellazione dei casi d'uso ed i tool. Oltre ai corsi di formazione standard, si consiglia di organizzare un workshop di un giorno in cui i membri del progetto proveranno l'esperienza pratica.  Consultare Compito: Avvio del processo di sviluppo.

I risultati dell'esecuzione dell'attività sono:

L'amministratore del sistema supporta lo sviluppatore durante l'iterazione.  

Formazione

  • Tutti i membri del progetto devono partecipare ad un corso che fornisce una panoramica di RUP per poter avere una visione generale del ciclo di vita del progetto.
  • Le persone che lavorano con la disciplina RUP che è stata "prodotta" devono partecipare ad un corso in cui apprendere i dettagli della disciplina.

Mentoring

Il mentoring è la chiave per un'implementazione di successo del processo.  In generale, sono necessari i seguenti mentori:

  • Mentore processo 50%. Qualcuno che agisce da tecnico del processo per supportare il responsabile di progetto e le altre persone del progetto nell'utilizzo e nella configurazione del processo.
  • Mentore <specifico per disciplina> 50%. Qualcuno che facilita il lavoro specifico per discipline, tenendo workshop, revisionando i risultati e rispondendo a domande specifiche.  
Per ulteriori informazioni sul mentoring, vedere Concetto: Mentoring.