Concetto: Contesto organizzativo per RUP (Rational Unified Process)
Questa linea guida descrive le organizzazioni ed i servizi di supporto esterni ad un progetto che sono necessari al suo successo.
Relazioni
Elementi correlati
Descrizione principale

Introduzione

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

SEPA (Software Engineering Process Authority)

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.

PRA (Project Review Authority)

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.

SEEA (Software Engineering Environment Authority)

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

Infrastruttura

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.