Teoria Locale

La carenza di prevedibilità nei tempi e nell’impegno-persona necessario per eseguire un progetto crea il seguente problema:

• Disponibilità delle persone disallineata con il reale fabbisogno in numero e/o in impegno-persona. Se la disponibilità fosse maggiore di quella che servirebbe, si creerebbe uno spreco; se fosse minore, il progetto si fermerebbe per carenza di personale, ciò faciliterebbe ritardi nella consegna e probabile insoddisfazione del committente.

BRD (Business Requirement Definition). Documento standard con cui si descrivono I requisiti che sono oggetto di implementazione del progetto.

Cost drivers. Il costo di base collegato ad ognuna delle caratteristiche delle applicazioni previste dal modello econometrico.

Esperto. Sviluppatore con notevole esperienza nella esecuzione dei progetti dell’impresa. Normalmente in Auriga sono i TAM.

Modello econometrico. Modello per calcolare la previsione:

Ha degli input predefiniti:

1. Le caratteristiche dell’applicazione da modificare ( ade esempio: n.di dati nella base dati; numero di videate; numero di dati da modificare per ogni videata e così via), il modello propone una lista di caratteristiche che guidano la definizione di questo input
2. Il ratings di complessità per ogni caratteristica da modificare. Questo deve essere scelto in una scala che il modello propone.

Ha un cost- river per ognuna delle caratteristiche, spalmato sulle fasi di ogni progetto

Calcola il costo del progetto moltiplicando il cost-drivers per i moltiplicatori relativi al ratings di ogni caratteristica da modificare.

Modifiche di ogni parametro. Entità della modifica di ognuno dei parametri che sono inclusi nel progetto.

Moltiplicatori. Il numero di cost-drivers che deve essere considerato per un dato ratings. Sono definiti per ogni parametro caratteristico e per ogni grado di ratings associato alla stessa caratteristica. Sono rcavati dall’analisi dei dati circa progetti già eseguiti.

Parametri caratteristici delle applicazioni. Sono i parametri che caratterizzano le applicazioni le cui modifiche costituiscono lo scopo di ciascun progetto, quindi, sono le sorgenti di costo dello stesso progetto. Il modello ne propone una lista che è stata ricavata dall’analisi dei progetti già eseguiti.

Previsioni. Valutazione dell’impegno persona necessari in ogni fase del progetto per realizzare quanto descritto nel BRD.

Previsioni euristiche. Previsioni fatte sulla base della esperienza di chi esegue la previsione.

Progetto. Insieme delle modifiche che devono essere realizzate e che sono specificate con il BRD.

Ratings di complessità. Il grado di complessità che determina quanto il cost-drivers deve essere moltiplicato per ricavare il costo della modifica di una delle caratteristiche. Ogni caratteristica da modificare deve avere un ratings scelto tra una lista proposta dal modello econometrico e ricavata dall’analisi dei dati storici circa progetti già eseguiti.

TAM (Technical Account Manager). Analista che conduce il processo standard per la produzione del BRD. È considerato senior se ha più di tre anni di anzianità; junior se ha fino a tre anni di anzianità.

• Le previsioni eseguite con un modello econometrico basato su un set di cost-drivers, ognuno assegnato ad un parametro caratteristico delle applicazioni, che sono aggiustati con moltiplicatori che dipendono dal ratings di complessità assegnati dagli esperti alle modifiche di ogni parametro specifiche del progetto che si deve eseguire sono più affidabili delle previsioni euristiche degli sviluppatori senza il modello econometrico.

• Senza il modello econometrico la previsione è tutta euristica che ogni esperto si è creato nel tempo. Con il modello econometrico l’esperto deve utilizzare l’euristica solo per prevedere il ratings di ognuno di parametri dell’applicazione da modificare che sono esplicitati rigorosamente nel BRD. Pertanto il perimetro di impatto dell’errore di euristica con il modello econometrico è limitato solo alla previsione del ratings.

• Carenza dell’analisi dei dati raccolti nei progetti precedenti da cui deriva che i cost-drivers ed i moltiplicatori non sono affidabili. Di qui deriva che le previsioni fatte con il modello econometrico abbiano errori non tollerabili. Per mitigare questo rischio è opportuno monitorare gli errori di previsioni quando questi non sono stabili e/o non si mantengono entro limiti tollerabili, rifare l’analisi, anche con metodi alternativi, dei dati disponibili per migliorare la elicitazione dei cost-drivers e dei ratings.
• Processi, sottostanti i progetti, non eseguiti conformemente ai modelli su cui sono basati i parametri del modello econometrico. In questo caso il progetto non è prevedibile con nessun mezzo. Per mitigare questo rischio è necessario monitorare la conformità di esecuzione dei processi e, se è il caso, ridefinire i vincoli di gestione delle attività necessari per aumentare la conformità.
• BRD non corretti indicano erroneamente i parametri caratteristici dell’applicazione da modificare, quindi induce in errore il modello econometrico. Per mitigare questo rischio è necessario il controllo statistico circa la correttezza dei BRD e se la sua carenza dovesse essere più alta della tolleranza accettabile è necessario intervenire sullo standard BRD e/o sul potenziamento dei TAM nella produzione del BRD.
• I Cost drivers ed i ratings potrebbero modificarsi nel tempo perché si modificano le competenze degli sviluppatori e/o si modificano le tecnologie utilizzate nello sviluppo e/o si modificano le complessità delle applicazioni, in questo caso incrementano gli errori del modello econometrico. Per moderare questo rischio è necessario il controllo statistico degli errori del modello econometrico e quando questo indica che il modello è instabile o dà risultati che hanno errori intollerabili è necessario ripetere l’apprendimento del modello econometrico rifacendo l’analisi dei progetti su un campione più aggiornato.

• Il modello econometrico attuale è utilizzabile sui progetti che comportano la modifica di software già in esercizio. Sarebbe opportuno estendere il suo scopo ai progetti che producono nuovo software. Oppure determinare un altro modello econometrico per lo sviluppo di software ex-novo basandosi sulla esperienza acquisita con l’attuale modello econometrico.