Operazione: Personalizzazione dl processo di sviluppo per il progetto
In questo compito si personalizza un processo di sviluppo per adeguarlo alle necessità specifiche del progetto.
Scopo

Lo scopo di questo compito è di:

  • Dimensionare in modo corretto il processo di sviluppo del software in modo da definire le esigenze del progetto.
  • Fornire una guida del processo sufficientemente rilevante da permettere ai membri del progetto di effettuare il proprio lavoro in modo efficiente e con qualità accettabile.
  • Fornire una descrizione del processo accessibile ai membri del progetto.
Relazioni
RuoliPrincipale: Aggiuntivo: Assistenza:
InputObbligatorio: Facoltativo: Esterno:
  • Nessuno
Output
Descrizione principale

Il compito che segue fornisce informazioni sullo sviluppo delle risorse del metodo specifiche per progetto. Vengono eseguite assieme alle fasi di sviluppo del metodo di questo compito:

Quando si utilizza un Caso di sviluppo assieme ad esso viene eseguito un Compito: Sviluppo del caso di sviluppo.

Passi
Analisi del progetto
Scopo:  Comprendere meglio il problema che si sta gestendo, e le risorse disponibili per il progetto.

È fondamentale per il successo del progetto che il processo di produzione sia rilevante per il progetto in gestione, e per suoi requisiti di dimensione e formalità. Un processo troppo elaborato porta ad un aumento della creatività, funzionalità ed efficienza. Un processo che lo sia poco potrà generare un ambiente caotico, che solitamente spinge i membri a prendere decisioni personali che potrebbero portare a risultati inefficienti, inconsistenti e non predicibili.

Definizione dell'ambito dell'impegno della personalizzazione
Scopo:  Definire quali aree del processo coprire nel processo specifico del progetto.

I risultati dell'analisi delle risorse del progetto e delle loro esperienze con progetti di sviluppo software simili, aiutano nell'identificazione dell'ambito dell'impegno di personalizzazione. Un processo specifico del progetto non deve includere tutte le discipline di RUP, e non è neanche necessario coprire tutti i ruoli in esso definiti. Tenere presente che RUP è un framework di processo adattabile ad un'ampia gamma di tipi di progetto, e quindi potrebbe essere troppo da seguire per uno specifico progetto. Le aree che si decide di coprire, dipendono molto dalle figure professionali dei membri del progetto e dalla sua natura. Di seguito si trovano delle considerazioni tipiche da effettuare nella definizione dell'ambito dell'impegno del processo.

  • Le aree in cui i membri del progetto hanno un modo definito di lavorare e dove non è necessario introdurre dei nuovi tool ed un nuovo processo. Ad esempio, se essi hanno esperienze di test, potrebbe essere una buona idea quella di non introdurre la disciplina di test del RUP, per ridurre il numero di nuovi fattori. Ci si può concentrare sull'introduzione di alcune parti di RUP per correggere i problemi nel loro processo esistente.  Consultare Concetto: Implementazione di un processo in un progetto, sezione Processo di miglioramento e tool, per dettagli. 
  • Le aree (discipline) dove il progetto deve introdurre nuovi processi e tool, perché vi sono modi per lavorare esistenti. In alcuni casi non vi sono processi e tool esistenti da utilizzare, e sarà quindi necessario introdurre buona parte del RUP, assieme ai tool di supporto. Consultare Concetto: Implementazione di un processo in un progetto, sezione Modificare tutto, per dettagli. 
  • Problemi in processi esistenti. Concentrarsi sul miglioramento delle aree in cui l'organizzazione ha avuto problemi.
  • Quali tool utilizzare? Se il progetto ha deciso di utilizzare determinati tool, il processo di sviluppo deve solitamente coprire le aree corrispondenti in RUP.
  • Le capacità del progetto da modificare. Nella considerazione dei problemi dell'organizzazione si tende a cercare di risolvere tutto insieme, specialmente se molti di questi problemi si verificano assieme. Questa è solitamente una trappola fatale. Le organizzazioni, alle stregua dei singoli, possono gestire le modifiche in numero limitato. Se la capacità di cambiare è bassa, si deve procedere lentamente, e forse introdurre solo una o due discipline del RUP nel primo progetto.
  • Le area in cui i membri del progetto hanno poche conoscenze. Coprire queste aree con il processo di sviluppo. Accertare che sia facile individuare le informazioni correste in RUP.

Per ulteriori informazioni sulla definizione dell'ambito dell'impegno di personalizzazione, consultare Linea guida: Personalizzazione di RUP

Per una descrizione dei fattori che influenzano la personalizzazione di un processo di un progetto, consultareLinea guida: Discriminanti del processo.

Le aree di miglioramento identificate non devono necessariamente essere introdotte per la prima volta nello stesso progetto. Ridurre il numero di fattori sconosciuti e controllare le aree dove l'organizzazione dello sviluppo ha sofferto in passato. Si consiglia di implementare RUP in modo iterativo, come descritto in Concetto: Implementazione di un processo in un progetto. Per i progetti piccoli si trova una guida in Esempio: Un piccolo progetto adotta RUP.

Per quanto si potrebbe scoprire la necessità di migliorare diverse discipline, considerare la possibilità di introdurle in modo iterativo durante il corso di diversi progetti, piuttosto che tendere ad un approccio che modifichi tutto contemporaneamente. Un esempio di tale compromesso è quello di introdurre i requisiti con i casi d'uso e posticipare l'introduzione del nuovo processo CM, se progetti procedenti hanno sofferto per una definizione dei requisiti non chiara e/o insufficiente, o se l'utente si è lamentato che il prodotto consegnato non soddisfa le sue necessità.

I compromessi effettuati e gli ambiti risultanti devono essere documentati come parte di un processo in modo da comunicare le decisioni relative agli stakeholder esterni.

Sviluppo dei contenuti specifici per progetto
Scopo:  Creare una maggiore "conoscenza del progetto" nelle aree in cui la copertura nel framework del processo RUP è giudicata insufficiente.

Il framework del metodo RUP è descritto in un modello di processo definito utilizzando un metamodello basato su UML. Questo metamodello si chiama UMA (Unified Method Architecture). Gli elementi di base di UMA sono descritti in  Concetto: Capacità chiave dell'UMA (Unified Method Architecture)

Si potrà estendere il framework di RUP aggiungendoRuoli, Compiti, e/o Prodotti di lavoro, o si potrà aggiungere una Guida  specifica per progetto al framework RUP esistente.  

Come parte di qualsiasi processo specifico del progetto, vi dovranno essere una serie di risorse disponibili personalizzate per fornire un aiuto specifico e materiale di riferimento per la produzione degli artefatti del progetto. Esempi di tali risorse sono:

  • Linee guida comuni sulla produzione di determinati artefatti.
  • Maschere personalizzate da utilizzare in tutto il progetto. Ciò verrà istanziato parzialmente con le informazioni del progetto.
  • Esempi di artefatti relativi alla serie di componenti distribuibili definite per il progetto e la tecnologia scelta.
  • Risorse riutilizzabili, quali pattern del progetto e librerie di codice.

All'avvio del progetto, il Responsabile progetto solitamente collabora con il Tecnico del processo per selezionare la serie di risorse appropriate, e per renderle disponibili ai membri del progetto nell'ambito del processo specifico per progetto. L'esigenza di nuove risorse viene verificata all'inizio di ciascuna iterazione.

Configurazione del processo
Scopo:  Dimensionare il processo sulle esatte esigenze del progetto.

La configurazione di un processo richiede la selezione del contenuto del metodo (prodotti di lavoro, compiti, ruoli e così via) che deve essere inclusa nel processo. Per consigli specifici sugli elementi del metodo da includere in ciascuna disciplina, consultare la guida "decisioni importanti per <nome disciplina>" fornita per ciascuna delle discipline RUP.  La selezione dei giusti contenuti del metodo di un dato progetto non è un'attività semplice. Per essere efficace, il processo deve essere pertinente e correttamente dimensionato su varie misure, come la dimensione del processo (risorse e tempi), formalità, piattaforma tecnologica, dominio per citarne alcune.

Per informazioni su uno schema di classificazione per la documentazione dell'importanza dei prodotti di lavoro del singolo e sul loro eventuale utilizzato, consultare Linea guida: Classificazione dei prodotti di lavoro.

Definizione del modello del ciclo di vita del progetto
Scopo:  Definire il modello del ciclo di vita del progetto.

Una parte importante della personalizzazione di un processo è la decisione del modello del ciclo di vita del progetto da seguire compresa la separazione in fasi ed iterazioni. Per questa parte del lavoro il tecnico del processo dovrà collaborare con il responsabile progetto poiché il ciclo di vita prescelto getta le basi del processo di pianificazione del progetto. A seconda della natura del progetto, vi potrà essere la necessità di regolare il ciclo di vita del RUP in modo da farlo corrispondere meglio alle esigenze specifiche. Ad esempio, lo sviluppo di un campo verde richiede più impegno nella fase di inizio che un progetto di manutenzione. Di conseguenza la descrizione del ciclo di vita deve essere regolata in base alla natura del progetto. Consultare Concetto: Iterazioni per una descrizione dei vari tipi di modelli di ciclo di vita.

Oltre alla selezione del modelli di ciclo di vita generale, è importante decidere come eseguire i flussi di lavoro associati a ciascuna delle discipline contenute nell'impegno di personalizzazione, così come decidere quando, introdurre ciascuna parte del flusso di lavoro delle discipline. La decisione del flusso di lavoro da seguire contempla anche quali attività eseguire ed il loro ordine.  La decisione di quando eseguire ciascuna parte del flusso di lavoro richiede la scelta del punto del ciclo di vita (ad esempio, quale fase) in cui introdurre le attività selezionate. Per informazioni su come personalizzare il flusso di lavoro per ciascuna delle discipline di RUP, consultare le note sull'utilizzo del flusso di lavoro di riferimento fornite per ciascuna di esse.

In questa fase si potrà decidere di specificare alcune informazioni aggiuntive quali i requisiti temporali e di formalità del prodotto di lavoro nei vari punti del ciclo di vita. Ad esempio, in quale fase è creato il prodotto di lavoro e/o aggiornato, e qual'è la formalità richiesta (deve essere rilasciato dal cliente?).

Disponibilità del processo ai membri del progetto
Scopo:  Rendere disponibili i processi specifici del progetto ai suoi membri.

Una volta terminata la parte iniziale della personalizzazione, il processo risultante dovrà essere reso disponibile al team del progetto in forma facilmente accessibile.

Una possibilità è quella via  sito web che si potrà trovare sia su un Server Web della rete di un'organizzazione, o installato sul computer di ciascun membro del progetto. Se essi sono connessi alla rete per la maggior parte del tempo, si consiglia la distribuzione via server Web per evitare sovraccarichi associati ad aggiornamenti al processo.

Manutenzione del processo

Per quanto la maggior parte del lavoro di personalizzazione viene eseguito nei primi giorni del progetto, lo si deve mantenere aggiornato continuamente, mentre i membri del progetto scoprono ostacoli ed altri problemi nel processo.  Con il procedere del processo, si imparano lezioni che vengono utilizzate dai tecnici del processo come feedback per migliorarlo. Le valutazioni effettuate durante il progetto sono importanti input per il miglioramento del processo.

Minime correzioni vengono solitamente gestite dal progetto e gli aggiornamenti al processo specifico vengono effettuati come parte della preparazione dell'ambiente di sviluppo per la successiva iterazione.  Questo tipo di processo porterà spesso all'esecuzione di aggiornamenti al processo specifico del progetto (ad esempio, perfezionamento delle maschere del prodotto di lavoro e delle linee guida).  I problemi più complessi vengono riportati sotto forma d i richiesta di modifica del processo. 

Uno dei benefici primari dello sviluppo iterativo è quello di consentire ai team del progetto di migliorare gradualmente la modalità di sviluppo del software. Si consiglia di includere in ciascun progetto dei micro cicli di costruzione del processo consistenti nelle seguenti fasi:

  • Definizione del processo
  • Effettuare il lavoro del progetto sulla base del processo definito
  • Valutare il proprio lavoro
  • Perfezionare il processo


Proprietà
Ricorrenze multiple
Attivato da evento
In corso
Facoltativo
Pianificato
Ripetibile
Illustrazioni
Considerazioni chiave

A prescindere dal livello di personalizzazione è importante registrarne i risultati (e possibilmente i razionali) dell'impegno.   In aggiunta, se il processo in questione deve essere personalizzato nuovamente (ad esempio il processo viene adattato all'organizzazione e ciò che ne risulta verrà personalizzato per ciascun progetto), sarà importante sviluppare delle linee guida su come personalizzare il processo di sviluppo della personalizzato. Tali decisioni e consigli potranno essere registrati in un documento separato, o come parte integrante del processo di sviluppo.  Per maggiori informazioni sui livelli di personalizzazione, consultare Concetto: Personalizzazione di RUP.

Il Piano di sviluppo software ed organizzazione ha il maggior impatto sul Processo di sviluppo, e vice versa. La personalizzazione del processo deve essere coordinata con lo sviluppo del piano del progetto. Ad esempio, se il progetto decide di utilizzare un insieme di fasi diverse da quelle del Rational Unified Process (RUP), lo si deve registrare nel processo di sviluppo personalizzato.  Inoltre, una volta personalizzato il processo di sviluppo dovrà essere istanziato in un piano del progetto adatto. Per ulteriori informazioni sulla pianificazione del progetto, consultare Compito: Pianificazione delle fasi e delle iterazioni e Compito: Sviluppo del piano di iterazione.


Si consiglia di non personalizzare il processo in un'unica sequenza.  Concentrarsi invece sulla disciplina da applicare successivamente al progetto.  Per maggiori informazioni sull'approccio iterativo all'implementazione del processo, consultareConcetto: Implementazione di un processo in un progetto

Una valutazione dell'organizzazione di sviluppo, se presente, indica su quali aree l'organizzazione di sviluppo deve concentrarsi. È necessario decidere le aree che richiedono migliorie per raggiungere le esigenze del progetto. Questa decisione influenza in modo diretto l'ambito dell'impegno di personalizzazione.

La personalizzazione del processo di un progetto deve essere gestita come un progetto in tutto e per tutto, con piani budget e meccanismi di controllo separati. È necessario definire uno scenario business, basato sull'analisi del ROI (Return on investment, ritorno d'investimento). Lo sviluppo effettivo del plugin beneficerà del fatto di aver seguito il ciclo di vita e le discipline del RUP. Si consiglia di provare le principali idee dietro un plugin sul progetto reale prima di avviare il suo progetto di sviluppo.

Un caso di sviluppo potrà essere utilizzato per documentare le decisioni di personalizzazione (ad esempio, quali parti di RUP sono state personalizzate e perché), ed anche come linee guida per impegni di personalizzazione futuri. In base al livello di personalizzazione eseguito, il caso di sviluppo potrà essere incluso come parte del processo di sviluppo stesso, o potrà essere utilizzato anche solo per pianificare, basare, e documentare l'impegno di personalizzazione. Per maggiori informazioni sui livelli di personalizzazione, consultare Concetto: Personalizzazione di RUP.

Alternativo
Sono possibili diversi livelli di personalizzazione per il RUP.  Per ulteriori informazioni, consultareConcetto: Personalizzazione RUP.
Ulteriori informazioni