Elementi essenziali del processo
Questa pagina introduce gli elementi essenziali di RUP e alcune linee guida per la personalizzazione del processo in modo da adattarlo alle esigenze specifiche del progetto. Questa è la chiave per il raggiungimento del delicato equilibrio tra la produzione di software di buona qualità e la rapidità nel realizzarlo..
Descrizione principale

Introduzione

La chiave per il raggiungimento del delicato equilibrio tra la produzione di software di buona qualità e la rapidità nel realizzarlo è la comprensione degli elementi essenziali del processo e seguire certe linee guida per personalizzare il processo in modo da adattarlo alle esigenze specifiche del progetto. Ciò dovrebbe essere effettuato utilizzando le procedure ottimali individuate per realizzare progetti di sviluppo software di successo.   

Quanto di seguito riportato descrive i principi essenziali di un processo software valido.

1. Visione:  Sviluppo di una visione

In particolare, lo sviluppo di una visione chiara è la chiave per lo sviluppo di un prodotto che soddisfi le "esigenze effettive dei   portatori di interesse".

In RUP, l'artefatto Visione cattura requisiti ad alto livello e vincoli di progettazione per fornire al lettore la comprensione del sistema da sviluppare. Esso fornisce l'input per il processo di approvazione del progetto ed è quindi strettamente correlato allo scenario business. Trasmette il concetto fondamentale "perché e cosa" relativo al progetto ed è un indicatore rispetto al quale devono essere convalidate tutte le future decisioni.

Il contenuto della visione, insieme a tutti gli artefatti di requisiti correlati, deve rispondere alle seguenti domande, che potrebbero essere divise per separare gli artefatti in maniera più dettagliata, se necessario:

  • Quali sono i termini chiave? (Glossario)
  • Quali problemi si sta cercando di risolvere? (Istruzione del problema)
  • Chi sono i portatori di interesse? Chi sono gli utenti? Quali sono le loro esigenze?
  • Quali sono le funzioni del prodotto?
  • Quali sono i requisiti funzionali? (Casi d'uso)
  • Quali sono i requisiti non funzionali?
  • Quali sono i vincoli di progettazione?

Lo sviluppo di una visione chiara e un insieme comprensibile di requisiti è l'essenza della disciplina disciplina Requisiti e il principio del Bilanciamento delle priorità dei portatori di interesse in conflitto. Ciò implica l'analisi del problema, la comprensione delle esigenze dei portatori di interesse, la definizione del sistema e la gestione delle modifiche dei requisiti.    

2. Piano:  Gestione del piano

"La qualità di un prodotto è buona quanto quella del piano relativo" ( FIS96 ).

Concepimento di un nuovo prodotto, valutazione dell'ambito e dei rischi, controllo del progetto, pianificazione e valutazione di ciascuna iterazione e di ciascuna fase: questi costituiscono "l'essenza" della disciplina Gestione del progetto.

Un Piano di sviluppo software raccoglie le informazioni necessarie per la gestione del progetto. In genere, vengono pianificati i tempi e le risorse necessarie del progetto e si tiene traccia dello stato di avanzamento rispetto alla pianificazione. Il piano coinvolge aree quali:   organizzazione, tempi, budget e risorse. Esso può includere anche piani per la gestione dei requisiti, le gestione della configurazione, la risoluzione di problemi, l'assicurazione di qualità e l'accettazione del prodotto.

In un progetto semplice, molti di questi argomenti possono essere trattati ciascuno mediante una o due frasi. Ad esempio, la pianificazione della gestione della configurazione potrebbe semplicemente specificare: "Al termine di ogni giornata il contenuto della struttura di directory del progetto verrà compresso, copiato su un disco con etichetta e data, contrassegnato con un numero di versione e collocato in un archivio centralizzato."

Il formato degli artefatti di pianificazione non è importante quanto le attività di pianificazione e le considerazioni ad essere relative.  Non è importante l'aspetto dei piani, né quali tool vengono utilizzati per crearli.  Come disse Dwight D. Eisenhower, "Il piano non è niente; la pianificazione è tutto."

3. Rischi:  Riduzione dei rischi e traccia dei problemi correlati

È fondamentale identificare e aggredire gli elementi di rischio più alti nella fase iniziale del progetto e tenerne traccia insieme agli altri problemi correlati.  L' Elenco dei rischi è volto a catturare i rischi percepiti che minacciano il successo del progetto. Esso identifica, in ordine decrescente di priorità, gli eventi che potrebbero portare ad un significativo esito negativo.

Per ciascun rischio dovrebbe esistere un piano per ridurre tale rischio.  Questo serve da punto focale per la pianificazione delle attività del progetto ed è la base su cui vengono organizzate le iterazioni.

4. Scenario business:  Analisi dello scenario business

Lo Scenario business fornisce le informazioni necessarie, dal punto di vista del business, per determinare se vale la pena di investire su un progetto.

Lo scopo principale dello Scenario business è quello di sviluppare un piano economico per la realizzazione della visione del progetto. Una volta sviluppato, lo Scenario business viene utilizzato per eseguire una valutazione accurata del ROI (return on investment) fornito dal progetto. Esso fornisce la giustificazione del progetto e ne stabilisce i vincoli economici. Fornisce informazioni a coloro che prendono decisioni economiche sul valore del progetto e viene utilizzato per stabilire se il progetto deve essere anticipato.

La descrizione non deve entrare negli aspetti specifici del problema, ma deve creare una seria argomentazione che giustifichi la necessità del prodotto. Tuttavia, deve essere breve in modo che sia facile, per tutti i membri del team del progetto, comprenderla e ricordarla. Nei punti cardine critici, lo Scenario del business viene riesaminato per verificare se le stime di costi e ricavi previsti sono ancora accurate e se il progetto deve essere continuato.

5. Architettura:  Progettazione dell'architettura di un componente

In RUP (Rational Unified Process) l'architettura di un sistema software (ad un certo punto) è l'organizzazione o la struttura dei componenti significativi del sistema che interagiscono, mediante interfacce, con componenti composti da componenti più piccoli e interfacce.  Quali sono gli elementi principali? E come si adattano insieme?  Si dispone di una struttura su cui aggiungere il resto del software?

Per parlare di architettura del software, è necessario anzitutto definire una rappresentazione strutturale, ossia un modo di descrivere gli aspetti importanti di un'architettura. Questa descrizione viene raccolta nel Documento dell'architettura software, che presenta l'architettura in più viste.

Ciascuna vista strutturale tratta un certo gruppo di considerazioni specifiche per i portatori di interesse nel processo di sviluppo: utenti, progettisti, responsabili, tecnici, di sistema e così via. Ciò funge da mezzo di comunicazione tra l'architetto software e gli altri membri del progetto riguardo ad importanti decisioni strutturali prese per il progetto.

La definizione di un'architettura candidata, il perfezionamento dell'architettura, l'analisi del comportamento e la progettazione di componenti del sistema è "l'essenza" della disciplina Analisi e progettazione e il principio Innalzamento del livello di astrazione.

6. Prototipo:  Creazione e test del prodotto in modo incrementale

RUP è un approccio iterativo alla creazione, al test, alla valutazione di versioni eseguibili del prodotto allo scopo di eliminare i problemi e risolvere i rischi il più presto possibile.

La creazione e il test di componenti del sistema in modo incrementale è "l'essenza" delle discipline Implementazione  e Test e il principio Dimostrazione del valore in modo iterativo.

7. Valutazione:  Valutazione periodica dei risultati

Una continua comunicazione aperta con dati oggettivi derivati direttamente da attività in corso e la configurazione di prodotti in evoluzione sono importanti in qualunque progetto.   Valutazioni di stato periodiche forniscono un meccanismo per indirizzare, comunicare e risolvere problemi di gestione, problemi tecnici e rischi del progetto.  Oltre ad identificare i problemi, a ciascuno devono essere assegnati una data di scadenza e un responsabile per la risoluzione.   Si consiglia di eseguire una traccia periodica di tali valutazioni e aggiornarle se necessario.

Questa istantanea di progetto rappresenta il centro vitale della gestione. Mentre il periodo può variare, per la funzione di forzatura è necessario catturare la cronologia del progetto per risolvere ed eliminare tutti i blocchi o i colli di bottiglia che limitano l'avanzamento.

La Valutazione dell'iterazione cattura i risultati di un'iterazione, il grado in cui i criteri di valutazione sono stati soddisfatti, le lezioni apprese e le modifiche di processo da implementare.

La valutazione dell'iterazione è un artefatto fondamentale dell'approccio iterativo. A seconda dell'ambito e del rischio del progetto e della natura dell'iterazione, la valutazione dell'iterazione può variare da una semplice relazione di dimostrazione e di risultati ad una completa relazione revisionale di test formale.

La chiave è concentrare l'attenzione sui problemi del processo e sui problemi del prodotto: "più presto si rimane indietro e più bisognerà accelerare i tempi".

8. richieste di modifica:  Gestione e controllo delle modifiche

Appena il primo prototipo viene posto davanti agli utenti (e spesso anche prima), vengono richieste delle modifiche. (Una delle certezze della vita!) Per controllare tali modifiche e gestire efficacemente l'ambito del progetto e le aspettative dei portatori d'interesse, è importante che tutte le modifiche agli artefatti di sviluppo siano proposte mediante Richieste di modifica e che vengano gestite con un processo costante.

Le richieste di modifica vengono utilizzate per documentare e tenere traccia dei difetti, delle richieste di potenziamento e di qualunque altro tipo di richiesta di modifica del prodotto. Il vantaggio delle richieste di modifica è rappresentato dal fatto che esse forniscono una relazione di decisioni e che, grazie al processo di valutazione, assicurano che gli impatti delle potenziali modifiche siano compresi da tutti i membri del team del progetto. Le richieste di modifica sono fondamentali per la gestione dell'ambito del progetto e per la valutazione dell'impatto delle modifiche proposte.

La gestione e il controllo dell'ambito del progetto, quando vengono apportate modifiche durante tutto il ciclo di vita del progetto, mantenendo l'obiettivo di considerare tutte le esigenze dei portatori di interesse: questa è "l'essenza" della disciplina Gestione modifiche e configurazione e del Materiale di supporto: Controllo delle modifiche.

9. Supporto utente:  Distribuzione di prodotto utilizzabile

Lo scopo di un processo è quello di produrre un prodotto utilizzabile.  Tutti gli aspetti del processo devono essere personalizzati tenendo conto di questo obiettivo.   Tipicamente, il prodotto è più di un semplice sofftware.  Dovrebbe almeno essere disponibile una guida per l'utente, realizzata mediante la guida in linea.   È possibile includere anche una guida all'installazione e le note sul rilascio.   A seconda della complessità del prodotto, potrebbe essere necessario anche del materiale per la formazione, l'elenco di materiali e il pacchetto del prodotto. Le attività associate compongono la  disciplina Distribuzione

10. Processo:  Adozione di un processo adatto al progetto

È fondamentale che venga scelto un processo adatto al tipo di prodotto che si sta sviluppando. Anche dopo averlo scelto, non bisogna seguirlo ad occhi chiusi; è necessario usare buon senso ed esperienza per configurare il processo e i tool in modo da soddisfare le esigenze dell'organizzazione e del progetto.

L'adattamento di un processo ad un progetto è una parte importante della disciplina Ambiente.

Per ulteriori informazioni sull'adattamento di RUP al progetto e all'organizzazione, consultare: Concetto: Personalizzazione di RUP.

Conclusione

Gli elementi essenziali sopra riportati forniscono un mezzo per valutare rapidamente un processo e per identificare delle aree i cui è particolarmente vantaggioso apportare dei miglioramenti.   È importante esaminare cosa succederebbe se uno di questi elementi venisse ignorato.  Ad esempio:

  • Nessuna visione? Si può perdere traccia di ciò che si sta svolgendo e degli obiettivi ed essere facilmente deviati.
  • Nessun processo? Senza un processo comune, nel team possono verificarsi dei fraintendimenti su chi fa cosa e quando.
  • Nessun piano? Non sarà possibile tener traccia dello stato di avanzamento.
  • Nessun elenco rischi? Si può concentrare l'attenzione sui problemi sbagliati e ritrovarsi, solo molto tempo dopo, in un problema molto grave non previsto.
  • Nessun scenario business? Si rischia di perdere tempo e denaro sul progetto. Il progetto può essere annullato o fallire.
  • Nessuna architettura? Potrebbe essere impossibile gestire problemi di comunicazione, sincronizzazione e di accesso ai dati quando si verificano; inoltre potrebbero verificarsi problemi relativi alle prestazioni e alla scalabilità.
  • Nessun prodotto (prototipo)? Appena possibile è necessario portare un prodotto al cliente. Accumulare carte non assicura il successo del prodotto e massimizza il rischio di superamento di budget e di tempi e/o di un vero e proprio fallimento
  • Nessuna valutazione? Non tenere la testa nella sabbia. È importante affrontare la realtà. Quanto si è vicini alla scadenza? Agli obiettivi di qualità e di budget? Si sta tenendo adeguatamente traccia di tutti i problemi?
  • Nessuna richiesta di modifica? In quale modo si tiene traccia delle richieste da parte dei portatori d'interesse? In quale modo si assegna ad esse una priorità? E in quale modo si preservano dai problemi quelle aventi bassa priorità?
  • Nessun supporto utente? Cosa succede quando un utente ha una domanda o non riesce a comprendere come utilizzare il prodotto?   Quanto è facile ricevere aiuto?

Questi elementi essenziali forniscono anche un'introduzione a Raggruppamento discipline: Discipline RUP di RUP e ne supportano i Principi chiave.