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"
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.
|