Queste linee guida descrivono degli elementi da considerare quando si personalizza RUP.
Per una descrizione del processo globale di personalizzazione di RUP, consultare Concetto:
Personalizzazione di RUP.
Per una descrizione delle migliori pratiche generiche correlate alla personalizzazione del processo, consultare Linea guida: Pratiche per la personalizzazione del processo.
Definizione dell'ambito dell'impegno per la personalizzazione
La definizione dell'ambito dell'impegno per la personalizzazione è quando si identifica quello che si desidera
modificare ed in che modo.
Per poter definire l'ambito in maniera efficace, è importante familiarizzare con RUP. Per ulteriori informazioni
consultare Introduzione a RUP.
In che misura personalizzare il processo ed il livello di personalizzazione che si decide di utilizzare sono entrambe
decisioni che dipendono da diversi fattori. Questi fattori sono descritti in Linea
guida: Discriminanti del processo.
Questa sezione esamina le costituenti di un processo che probabilmente verranno modificate, personalizzate, aggiunte o
soppresse come parte di un impegno di personalizzazione RUP.
-
Discipline
Un progetto software raramente ignora completamente una delle discipline, come ad esempio Analisi e progettazione,
Implementazione ecc. ecc. In casi eccezionali alcune discipline, come Requisiti o Distribuzione, potrebbero essere
state seguite da altre organizzazioni. Tuttavia, è più probabile che vengano modificati i flussi di lavoro
specifici all'interno o accanto alle discipline.
-
Prodotti di lavoro
I progetti sono molto diversi dai prodotti di lavoro che devono produrre, aggiornare e distribuire. Ad
un'estremità di un'intervallo, si immagini che un progetto totalmente privo di carte, che gestisce elettronicamente
solo un piccolo numero di prodotti di lavoro, sia supportato da tool come i fogli elettronici, i tool di
progettazione, di programmazione, di verifica, e che distribuisce solo software e documentazione in modo
elettronico su disco, CD o su World-Wide Web. All'altra estremità, ci sono dei progetti che devono produrre e
gestire un insieme molto più vasto di documenti stampati per motivi contrattuali, regolamentari o organizzativi. In
alcuni casi, dei modelli completi possono essere omessi.
-
Attività
Le attività sono soggette a variare per almeno due ragioni. Le attività che utilizzano i prodotti di lavoro come
input e producono o aggiornano i prodotti di lavoro come output sono influenzate dalla modifica dei prodotti di
lavoro; in particolare, se un prodotto di lavoro o un elemento di informazione in un prodotto di lavoro non è più
necessario, i corrispondenti passi potrebbero essere soppressi o essere modificati in modo significativo. Anche le
attività vengono modificate per introdurre tecniche specifiche, metodi e tool che riguardano il dominio specifico
dell'applicazione o la competenza di sviluppo, come i passi di progettazione, linguaggi di programmazione, tool di
generazione automatica di codice, tecniche di misurazione e così via.
Ad un livello più dettagliato, altri elementi del metodo possono essere modificati, aggiunti o soppressi:
-
Ruoli
-
Passi nelle attività
-
Linee guida e guida per le attività
-
Notazioni, come l'utilizzo di sottoinsiemi UML o di stereotipi per risolvere esigenze specifiche di alcuni modelli
o di tutti i modelli
-
Elenchi di controllo per le revisioni
-
Supporto di tool per automatizzare alcune attività
-
Modifiche alla terminologia, ad esempio per adattare il processo al contesto organizzativo
In sintesi, il tecnico del processo deve effettuare una vasta gamma di decisioni quando personalizza RUP. Potrebbe
essere necessario dover regolare RUP per sfruttare determinate pratiche e standard dell'azienda ben assestate, ad
esempio documenti, terminologia, ecc. ecc.
Determinati scenari di personalizzazione sono difficili da implementare e devono essere presi in considerazione molto
attentamente. Per esempio:
-
Modifica all'architettura del processo
Un reimpacchettamento delle attività di ampia gamma in un altro insieme di discipline per corrispondere ad un
processo o ad un'organizzazione esistente può portare a molto impegno con poco guadagno. Spesso è più pratico
stabilire semplicemente una corrispondenza per valutare se tutti sono coperti gli aspetti da RUP. Le discipline non
sono delle fasi eseguite in maniera sequenziale, sono contenitori di attività e vengono eseguite di continuo in
ogni iterazione, spesso contemporaneamente all'interno di una iterazione.
-
Modifiche alla terminologia
Anche se la sostituzione di una parola con un'altra può sembrare una pratica irrilevante nella elaborazione di
parole, alcune modifiche devono essere considerate molto attentamente. Nel dominio della progettazione software, le
organizzazioni spesso utilizzano la stessa parola con significati leggermente diversi o parole diverse che vogliono
dire la stessa cosa. Apportare delle modifiche isolate in RUP può portare ad un processo molto difficile da capire.
Una soluzione è di creare una "tabella di conversione" per la terminologia che converte la terminologia RUP in
quella dell'organizzazione.
Esempi di parole rischiose sono sistema, fase, ruolo, attività, compito, modello e documento.
Se i risultati del processo vengono catturati in un linguaggio diverso dall'inglese, le problematiche terminologiche
sono più complesse quando si devono tradurre le descrizioni di prodotti di lavoro, documenti, report e magari anche
altre parti di RUP nell'altra lingua.
|