I progetti non si eseguono in isolamento, confidano nelle attenzioni delle organizzazioni di supporto. La natura di
quel supporto viene caratterizzata nelle sezioni che seguono. RUP (Rational Unified Process) presuppone che i tipi di
servizi descritti qui saranno disponibili all'esterno del progetto e che in qualsiasi organizzazione esista una pari
capacità di fornirli, ma non prescrive la struttura o l'operatività di queste entità. Le descrizioni che seguono sono
prese da [ROY98] (q.v.).
Il SEPA (Software Engineering Process Authority) facilita lo scambio, da e verso professionisti del progetto, di
informazioni e di guida al processo. Questo ruolo è giustificabile per il responsabile generale dell'organizzazione per
la gestione di una valutazione corrente della maturità del processo dell'organizzazione e per i piani di futuri
miglioramenti del processo. Il SEPA deve aiutare ad avviare e valutare periodicamente i processi del progetto. La
catalizzazione di acquisizione e diffusione di pratiche software si ottiene solo quando il SEPA viene a conoscenza sia
del miglioramento desiderato che del contesto del progetto. La SEPA è un ruolo necessario in qualunque organizzazione.
Si assume la responsabilità e la giustificabilità della definizione del processo e la sua manutenzione (modifica,
miglioramento, inserimento di tecnologie). Il SEPA potrebbe essere un singolo individuo, il responsabile generale, o
anche un team di rappresentanti. Il SEPA deve essere davvero un'autorità, competente e potente, non una posizione del
personale resa impotente da una burocrazia inefficace.
Il PRA (Project Review Authority) è l'entità organizzativa che deve garantire che il progetto software sia conforme a
tutte le politiche, pratiche e standard software delle unità di business e aziendali. Un responsabile di progetto
software deve garantire la soddisfazione dei requisiti di un contratto o di qualche altro standard di conformità del
progetto ed è giustificabile per il PRA. Il PRA rivede la conformità del progetto rispetto agli obblighi contrattuali e
agli obblighi delle politiche aziendali del progetto. Il cliente monitora i requisiti del contratto, i punti cardine
del contratto, i componenti distribuibili del contratto, le revisioni mensili della gestione, l'avanzamento, la
qualità, il costo, la pianificazione ed i rischi. Il PRA rivede i commitment del cliente oltre all'adesione alle
politiche organizzative, ai componenti di distribuzione organizzativi, le prestazioni finanziarie e altri rischi e
adempimenti. Si consiglia di assegnare il ruolo di PRA ad un'unica persona; quella persona può delegare il lavoro di
monitoraggio e di revisione a seconda delle necessità, e le riunioni a cui partecipa il PRA possono richiedere il
supporto di altre persone proveniente dal team dirigenziale dell'organizzazione di sviluppo, in modo da far sembrare
che il PRA sia un team di persone, almeno per la durata della riunione. Si consiglia vivamente, tuttavia, di
lasciare l'autorità finale per le prestazioni ad una persona, che può chiedere supporto quando necessario.
Il SEEA (Software Engineering Environment Authority) è responsabile dell'automazione del processo dell'organizzazione,
della gestione dell'ambiente standard dell'organizzazione, della gestione dei beni riutilizzabili di tutta
l'organizzazione e di insegnare ai progetti ad utilizzare l'ambiente. Il ruoli SEEA è necessario per ottenere un
significativo ritorno di investimento per un comune processo. I tool, le tecniche e la formazione possono essere
ammortizzati efficacemente in più progetti solo se qualcuno dell'organizzazione (il SEEA) è responsabile del supporto e
della gestione di un ambiente standard. In molti casi l'ambiente può essere migliorato, personalizzato o modificato ma
per ottenere l'istituzionalizzazione del processo dell'organizzazione ed un buon ROI sugli investimenti di capitale per
i tool è fondamentale l'esistenza di una soluzione per ciascun progetto predefinita all'80%.
Un'infrastruttura dell'organizzazione fornisce il supporto di risorse umane, la ricerca e lo sviluppo indipendenti dal
progetto, ed altri beni di capitale per la progettazione software. L'infrastruttura per una data linea di software di
business può variare da burocrazia irrilevante a burocrazia altamente radicata. I componenti tipici dell'infrastruttura
organizzativa sono:
-
Amministrazione del progetto: sistema di contabilità temporale; contratti, tariffe, termini e condizioni;
integrazione di sistemi di informazioni aziendali
-
Centri di skill di progettazione software: repository e manutenzione di tool personalizzati, supporto per gare
d'appalto e proposte, ricerca e sviluppo indipendente
-
Sviluppo professionale: formazione interna, assunzione di personale, gestione di database degli skill del
personale, libreria di letteratura e beni, pubblicazioni tecniche.
|