Introduzione
Questo principio articola l'importanza di bilanciare le esigenze di business e dello stakeholder spesso
in conflitto, oltre ad equilibrare lo sviluppo personalizzato di contro al riutilizzo delle
risorse, soddisfando tali esigenze.
|
|
Vantaggi
|
-
Allineamento delle applicazioni con le esigenze di business e dell'utente
-
Riduzione dello sviluppo personalizzato
-
Ottimizzazione del valore di business
|
Pattern
|
-
Definire, comprendere ed assegnare una priorità alle esigenze di business e
dell'utente
-
Assegnare le priorità ai progetti ed ai requisiti ed associare le esigenze alle
capacità del software;
-
Capire quale risorsa può essere potenziata;
-
Bilanciare il riutilizzo di risorse con le esigenze dell'utente
|
Anti-pattern
|
-
Documentare in modo approfondito i requisiti precisi all'inizio del progetto,
forzare l'accettazione dei requisiti da parte dello stakeholder
-
Negoziare le modifiche ai requisiti, dove ogni modifica può aumentare il
costo o la durata del progetto,
-
Bloccare i requisiti in anticipo, riducendo quindi la possibilità di
potenziare le risorse esistenti,
-
Eseguire principalmente uno sviluppo personalizzato.
-
Strutturare un sistema solo per soddisfare le esigenze degli stakeholder che si
fanno sentire di più.
|
|
Discussione
Ad esempio, la maggior parte degli stakeholder preferisce disporre di un'applicazione che esegue esattamente quello si
desidera debba svolgere, minimizzando il costo di sviluppo dell'applicazione ed i tempi di realizzazione. Tuttavia
queste priorità sono spesso in conflitto. Un altro esempio è che se si potenzia un'applicazione in
pacchetto, si potrebbe essere in grado di distribuire una soluzione più rapidamente e ad un costo inferiore, ma
scendendo a compromessi con molti requisiti. Se invece si decide di creare un'applicazione da zero, questa potrebbe sì
occuparsi di ogni requisito desiderato, ma il budget e la data di completamento potrebbero entrambi andare oltre i loro
limiti fattibili.
L'utilizzo di un componente può radicalmente ridurre i costi ed i tempi di distribuzione di un determinato insieme di
funzionalità. In molti casi è necessario effettuare un compromesso su alcuni requisiti funzionali o tecnici, ad esempio
il supporto piattaforme, le prestazioni o l'impronta fisica (la dimensione fisica dell'applicazione).
Per essere in una posizione di equilibrio fra le esigenze, è necessario prima gestire i requisiti in modo efficace,
come descritto in Materiale di supporto: gestione dei requisiti. Invece di proiettare i team di
programmazione su ogni elemento dell'elenco di requisiti, è necessario comprendere ed assegnare una priorità alle
esigenze di business e degli stakeholder. Questo significa catturare i processi di business e collegarli ai
progetti e alle capacità software, che consentono di assegnare in modo efficace una priorità ai progetti e ai
requisiti, e di modificare le priorità man mano che aumenta la comprensione dell'applicazione ed evolvono le esigenze
degli stakeholder. Significa anche che è necessario coinvolgere nel progetto il cliente o una sua rappresentanza, per
essere certi di comprendere le sue esigenze.
Allo stesso tempo è necessario incentrare le attività di sviluppo intorno alle esigenze degli stakeholder. Ad
esempio, potenziando lo sviluppo guidato dai casi d'uso e la progettazione incentrata sull'utente, il processo di
sviluppo può accogliere l'evoluzione delle esigenze degli stakeholder nel corso del progetto, come con una
funzione di modifica del business e con una maggiore comprensione delle capacità realmente importanti
per il business e gli utenti finali.
Infine, è necessario capire quali risorse sono disponibili e bilanciare il riutilizzo di risorse con le
esigenze degli stakeholder. Esempi di risorse sono le applicazioni preesistenti, i servizi, i componenti
riutilizzabili ed i pattern. Il riutilizzo delle risorse può, in molti casi, portare alla riduzione dei costi del
progetto. Riutilizzare delle risorse comprovate spesso significa una maggiore qualità nelle nuove applicazioni. Lo
svantaggio è che spesso è necessario giungere ad un compromesso fra il riutilizzo delle risorse e la soddisfazione
completa delle esigenze dell'utente. Il riutilizzo di un componente può abbassare i costi di sviluppo di una funzione
dell'80%, ma quel componente potrebbe risolvere solo il 75% dei requisiti. Quindi un efficace riutilizzo richiede un
costante bilanciamento fra il riutilizzo delle risorse e l'evoluzione delle esigenze degli stakeholder.
|