Operazione: Personalizzazione del processo di sviluppo per il progetto |
|
 |
In questo compito si personalizza un processo di sviluppo per adeguarlo alle necessità specifiche del progetto. |
Discipline: Ambiente |
|
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
Ruoli | Esecutore primario:
| Esecutori aggiuntivi:
|
Input | Obbligatorio:
| Facoltativo:
|
Output |
|
Utilizzo del processo |
|
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:
|
|
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
Ulteriori informazioni
Concetti |
|
Linee guida |
|
Guida al tool |
|
© Copyright IBM Corp. 1987, 2006. Tutti i diritti riservati.
|
|