Due mondi per la stima dei progetti software

A prima vista sembra che ci siano due mondi per la stima del progetto software quale, per semplicità, Chiamerò i mondi "Caotico" e "Controllato". Il mondo caotico è caratterizzato dalla maggior parte delle organizzazioni i cui progetti spesso superano i tempi e il budget, o che falliscono completamente. Il mondo controllato ha una popolazione molto più piccola di organizzazioni esemplari i cui progetti sono dichiarati essere consegnati regolarmente nei tempi e nel budget. La domanda interessante è perché le organizzazioni nel mondo caotico non imparano o non possono semplicemente imparare e copiare il comportamento di quelle nel mondo controllato e risparmiare un sacco di soldi.
Questo articolo esplora i due mondi e si propone di spiegare le differenze che sono in parte intrinseche e in parte inevitabili, e in parte a causa di una miscela di cultura, processo e fattori tecnici, molti dei quali possono essere superati con abbastanza sforzo e perseveranza.
Primo, le prove per i due mondi.

Il mondo caotico

Ci sono stati diversi sondaggi, coprendo il risultato di migliaia di progetti software, principalmente negli Stati Uniti e nel Regno Unito e principalmente di progetti nel settore del software applicativo aziendale, nel settore pubblico o privato. A rigor di termini, dovremmo fare riferimento a "progetti di sistema ad alta intensità di software", poiché per molti di questi progetti la consegna del software è solo una parte di un progetto che deve fornire un sistema hardware/software e spesso anche un cambiamento organizzativo. Uso "progetti software" per semplicità. I risultati variano ma indicano che tra 10% – 30% dei progetti software fallisce completamente, cioè. vengono fermati prima di consegnare qualcosa di utile. Un altro grosso modo 50% superamento del tempo e/o del budget di almeno 10%. Questo lascia solo 20% – 40% dei progetti consegnati nei tempi e nel budget.

tuttavia, queste cifre non riflettono il fatto che molti progetti offrono meno funzionalità o valore aziendale di quanto inizialmente previsto. Ulteriore, una percentuale sconosciuta di quei progetti che sono terminati "nei tempi e nel budget" potrebbe essere stata sopravvalutata in primo luogo, quindi avrebbe potuto essere consegnata più velocemente e a un costo inferiore. Abdel-Hamid ha osservato che la legge di Parkinson si applica ai progetti software proprio come qualsiasi altra attività, cioè. il lavoro si dilata per riempire il tempo messo a disposizione per il suo compimento.

Il costo di questi superamenti e fallimenti è enorme. Un'analisi ben documentata di 105 progetti software appaltati completati nei dieci anni fino a 2007 tra clienti del settore pubblico del Regno Unito e fornitori esterni ha avuto un valore totale di 29,5 miliardi di sterline. Di questi, 30% sono stati terminati, 57% media dei superamenti dei costi sperimentati 30.5% (per un totale di 9 miliardi di sterline di sforamenti), mentre 33% subito grossi ritardi. Un punto importante da notare è che tutti questi progetti sono stati intrapresi da fornitori esterni che operano in tutto il mondo e affermano nel loro marketing di essere di "classe mondiale". Ulteriore, il margine di profitto dei fornitori sui contratti era quasi sempre scaduto 10%, che vanno fino a 25%.

Le stesse ragioni di questi fallimenti e superamenti vengono citate ripetutamente, almeno tornando indietro 30 anni come descritto nel libro Crash! Cadono in due gruppi principali.

1. Mancanza di impegno del senior management e coinvolgimento degli utenti, risultando in obiettivi poco chiari, che porta a conflitti tra le parti interessate, e requisiti poco chiari e mutevoli.
2. Cattiva gestione del progetto (per esempio. nella gestione dei progressi e dei cambiamenti), inesperienza del personale, soprattutto quando è coinvolta la nuova tecnologia, e turnover del personale.

Mentre il costo dei guasti e dei sovraccarichi può essere pesantemente appesantito dalle cancellazioni sull'hardware, il costo dell'assunzione di personale aggiuntivo, benefici perduti, eccetera., le cause sono quasi invariabilmente dovute a problemi con la specifica e lo sviluppo del software.

In tutte le varie analisi del motivo per cui i progetti software falliscono o superano il limite, è raro vedere la "scarsa stima" elencata come una delle cause. Questo non è sorprendente per i progetti che falliscono. Una stima scadente sembra una causa improbabile di abbandono di un progetto. Più probabilmente è stato interrotto perché le priorità sono cambiate da quando è iniziato e non fornirà più nulla di utile, oppure è andata avanti così a lungo oltre il budget originario che la direzione decide di ridurre le perdite. Ma se, Dire, 57% di tutti i progetti software superati in media da oltre 30%, ci si deve chiedere "c'è qualcosa di sistematicamente sbagliato nel processo di stima in questi ambienti".?'

Il mondo controllato

Di tanto in tanto intravediamo questo altro mondo quando un'organizzazione pubblica i risultati che mostrano i suoi successi nella stima dei progetti software. L'esemplare che userò è Renault, il produttore di veicoli francese, che ha pubblicato i suoi progressi nella stima di progetti software di successo, più recentemente in 2014.

Una moderna auto familiare media ha all'incirca 50 Centraline elettroniche (ECU), piccoli processori che formano una rete distribuita per monitorare e/o controllare quasi tutte le funzioni, per esempio. motore, luci, aria condizionata, pressioni dei pneumatici, navigazione, informazioni sul conducente, eccetera. Le ECU e il loro software integrato vengono acquistati principalmente da fornitori di componenti con i sensori associati, soggetto alle specifiche emesse da Renault.
Da alcuni anni Renault raccoglie dati sui costi e sulle prestazioni dei suoi fornitori di software ECU. Il processo mediante il quale si contrae per procurarsi le ECU è brevemente:

• Reparti software Renault, specializzati per area funzionale del veicolo (per esempio. propulsore), sviluppare specifiche per software ECU nuovo o migliorato e memorizzarle nello strumento Matlab Simulink;
• Uno strumento sviluppato da Renault calcola quindi automaticamente una dimensione funzionale di ciascuna specifica (o l'aumento delle dimensioni se un miglioramento) utilizzando lo standard ISO COSMICO metodo;
• Le misurazioni passate e le relazioni stabilite statisticamente vengono utilizzate per prevedere lo sforzo necessario al fornitore per sviluppare il software (vedi fig. 1) e la sua dimensione della memoria (Fico. 2);
• Queste informazioni vengono utilizzate dall'ufficio acquisti per negoziare il prezzo dell'ECU. Ulteriore, le informazioni a disposizione di Renault sono ora sufficientemente consolidate da poter essere utilizzate per negoziare le variazioni annuali dei prezzi nello stesso modo in cui i produttori di automobili negoziano periodicamente i prezzi di altri materiali come l'acciaio, vernici ecc., e altri componenti. (Fico. 3);
• Le dimensioni funzionali COSMIC vengono utilizzate anche per monitorare le prestazioni del reparto software interno, dal momento che Renault ha stabilito una relazione specifica-dimensioni/livello di personale per il loro lavoro.

Renault afferma che alla fine di un nuovo sviluppo del software, la differenza tra lo sforzo inizialmente stimato dalla correlazione stabilita e il valore effettivo "deve essere inferiore al 5%" (vedi fig. 4).

Fico. 1 Sforzo vs dimensione COSMIC per il software ECU

Fico. 2 Utilizzo della memoria rispetto alle dimensioni COSMIC

Fico. 3 Trattativa ufficio acquisti

Fico. 4 Controllo della precisione delle stime dei costi

Differenze tra il mondo caotico e quello controllato della stima dei progetti software

Nel seguente, poiché le stime del progetto a vita intera sono richieste qualunque sia l'approccio di gestione del progetto, Userò un modello a cascata delle fasi del progetto per comodità. Le differenze quando si utilizza un modello iterativo o agile verranno menzionate non appena si presentano. Dobbiamo anche assumerlo nei confronti dei mondi Caotico e Controllato, le organizzazioni in entrambi i mondi hanno processi ragionevolmente ripetibili e utilizzano la tecnologia con cui sono ragionevolmente familiari, cioè. ignoreremo gli ambienti in cui l'immaturità dei processi e i rischi associati all'uso di nuove tecnologie lasciano poche possibilità di sviluppare metodi di stima accurati.

Condizioni diverse per la stima. In un senso, è ingiusto fare qualsiasi paragone tra i due mondi in quanto vi sono alcune differenze intrinseche tra loro.

La prima e più ovvia differenza è quella nel mondo caotico, di solito è necessaria una stima del costo dell'intera vita per un progetto di applicazione aziendale all'inizio della sua vita, prima che i requisiti siano noti in dettaglio, al fine di informare l'analisi costi/benefici del software.

In contrasto, i progetti di stima per il completamento nel mondo controllato di Renault non vengono effettuati fino a quando la progettazione del software non è completamente specificata, cioè. non sono realmente stime di tutta la vita. A questo punto, le stime possono essere fatte anche a basso livello di decomposizione (Blocchi Simulink nel caso Renault) prima dell'aggregazione al costo dell'intero ECU.

Chiaramente ci si aspetterebbe che le stime Renault siano molto più accurate di quelle effettuate nelle prime fasi di un tipico progetto di applicazione aziendale. Avendolo detto, è quindi lecito chiedersi perché stime fatte così presto nella vita di un progetto, quando c'è ancora tanta incertezza, vengono accettati come fissi in modo tale che spesso si verificano superamenti. Ulteriore, I costi di manutenzione e supporto continui che contribuiscono al business case spesso si rivelano molto più elevati di quanto previsto in questa fase iniziale.

Differenze culturali. Uno studio sulle pratiche di stima di Jorgensen ci dice molto sulla cultura del mondo caotico. La sua ricerca ha scoperto che la "stima degli esperti" è la strategia dominante per stimare lo sforzo del progetto di sviluppo dell'intera vita. Ha definito la stima degli esperti come "il lavoro svolto da una persona riconosciuta come esperta del compito"., e che una parte significativa del processo di stima si basa su un processo di ragionamento non esplicito e non recuperabile, cioè. 'intuizione''. Sebbene questa ricerca sia stata pubblicata in 2004, Jorgensen mi ha recentemente detto che non conosceva dati pubblicati che alterassero questa opinione secondo cui la stima degli esperti domina ancora la stima dello sforzo del progetto.

In contrasto, la mia osservazione informale è che le organizzazioni nel mondo Controllato che pubblicano dati che indicano un'elevata precisione per le stime dei progetti sono per lo più aziende manifatturiere hi-tech, spesso producendo software safety-critical o mission-critical. Questi progetti richiedono una grande attenzione alla qualità, quindi iniziano con il vantaggio di una "vera" mentalità ingegneristica, basandosi sui dati piuttosto che solo sul giudizio.

Queste differenze culturali influenzano l'accuratezza della stima del progetto. Daniel Kahnman, uno psicologo che ha vinto il 2002 Il premio Nobel per l'economia descrive due modi di pensare umano, intuitivo e razionale. La maggior parte delle volte pensiamo in modo intuitivo; richiede una vera disciplina per pensare in modo razionale. La sua scoperta più importante rilevante per la stima è che il pensiero intuitivo è quasi sempre ottimista e tende a ignorare le statistiche e l'esperienza passata (per esempio. credendo "questa volta lo faremo bene"). Raccomanda che le decisioni predittive finali siano lasciate alle formule, e preferibilmente semplici con poche variabili.

Applicare questa raccomandazione a una stima dei costi del progetto basata sul pensiero intuitivo, per esempio. Per analogia, suggerisce che se l'ambiente ha il track record sopra citato per i progetti del settore pubblico nel Regno Unito, quindi il business case dovrebbe considerare il 30% rischio di fallimento totale, e qualsiasi stima dei costi intuitiva dovrebbe essere automaticamente aumentata di 15% – 20% con un corrispondente aumento dell'incertezza.

Kahneman ha altre raccomandazioni che sono significative per stimare quando mancano dati concreti, per esempio. l'uso di processi come Delphi a banda larga (o "Planning Poker" nel mondo agile), piuttosto che affidarsi all'esperienza di un individuo.

Comprendere i ruoli dei vari attori coinvolti nella stima. La responsabilità di uno stimatore è produrre una cifra dello sforzo del progetto basata sui migliori dati disponibili, con un'appropriata dichiarazione dell'intervallo di incertezza della stima. È tutto.

È compito del manager comprendere le ipotesi dello stimatore, valutare il rischio e l'incertezza, e infine decidere il budget del progetto. Se la mentalità del manager è affidarsi allo stimatore e ignorare il rischio (per esempio. con l'atteggiamento del manager di Dilbert di "dammi solo un numero") il progetto è destinato a mancare il suo budget.

Ulteriore, quando un cliente emette un ITT per procurarsi software da un fornitore esterno, il cliente deve comprendere altri fattori che influenzano il modo in cui un fornitore arriva alle sue stime e ai prezzi di offerta.

I fornitori di sistemi software in outsourcing dipendono da stime affidabili per la loro sopravvivenza - e abbiamo notato sopra che normalmente hanno un buon track record in termini di redditività. Pertanto, normalmente prendono molto sul serio la raccolta di metriche del software e il loro utilizzo per la stima, molto più di quanto non faccia un tipico reparto IT interno o la funzione IT mantenuta di un cliente che gestisce i suoi fornitori IT in outsourcing.

In un fornitore, la stima dei costi basata sulle informazioni sui requisiti contenute nell'ITT del cliente viene convertita dal suo team di vendita in un prezzo vantaggioso. In questo processo, terranno conto di molti fattori ovvi come il budget previsto del cliente, la probabile concorrenza, flusso di cassa futuro, redditività desiderata, eccetera.

Vengono inoltre considerati altri due fattori meno apprezzati ma importanti. Primo, man mano che il progetto avanza, il cliente penserà inevitabilmente a requisiti nuovi o modificati che possono essere addebitati in più rispetto al prezzo dell'offerta. Secondo, il vincitore del progetto di sviluppo iniziale è nella posizione migliore per vincere il lavoro di manutenzione e supporto in corso per tutta la vita del sistema. Entrambe queste attività aggiuntive e continue possono essere molto più redditizie del lavoro di sviluppo iniziale. Di conseguenza, un fornitore può fare un'offerta bassa per lo sviluppo iniziale per assicurarsi una vincita.

purtroppo, quando la prima grande ondata di outsourcing IT del settore pubblico nel Regno Unito è iniziata oltre vent'anni fa, la maggior parte dell'esperienza di metrica software e stima è stata esternalizzata ai fornitori con contratti a lungo termine. Ciò ha portato a una grave "asimmetria informativa" tra i clienti e i loro fornitori ed è quasi certamente una delle principali cause dell'elevato livello di superamento del budget dei progetti IT del settore pubblico del Regno Unito.

Per una casa automobilistica, l'acquisto è una delle sue funzioni più importanti. Nel caso degli appalti IT del settore pubblico del Regno Unito, effettivamente il guardiacaccia ha consegnato la sua esperienza metrica ai bracconieri.

Un'altra causa di superamento dei progetti può derivare dal modo in cui vengono gestite le riserve per imprevisti. Questi dovrebbero essere tenuti da un manager a livello di portafoglio di progetto e rilasciati ai project manager secondo necessità, piuttosto che essere assegnati a singoli progetti all'inizio. Primo, la conoscenza della contingenza inclusa in un preventivo dà conforto al project manager e la legge di Parkinson garantisce che verrà utilizzata. Lo stesso vale per una relazione esternalizzata, dove Kahneman cita "una riserva di bilancio è per gli appaltatori come la carne rossa per i leoni".; lo divorano'.

Tecniche di stima. Molto progetto software preventivo nel mondo controllato, come esemplificato da Renault, tenta di rispondere alla domanda dominante basata sui costi di "quanto è grande".?effettuando stime basate sull'esperienza dei conteggi delle righe di codice sorgente (SLOC). Il noto metodo di stima COCOMO II e la maggior parte degli strumenti di stima disponibili in commercio sono stati calibrati utilizzando le dimensioni SLOC come input. Nonostante i tanti, svantaggi spesso pubblicizzati delle dimensioni SLOC, in genere si afferma che l'accuratezza della stima basata sul giudizio di esperti da progetti dettagliati è accurata all'interno 10% a livello di componente.

Nel mondo caotico, se per le stime è necessario più dell'intuizione o del giudizio di esperti quando esistono solo requisiti di massima, è più comune stimare prima la dimensione dei requisiti utilizzando l'analisi dei punti funzionali (FPA). La dimensione viene quindi convertita in sforzo utilizzando benchmark di produttività derivati ​​da precedenti progetti simili. L'idea originale dell'FPA di Albrecht alla fine degli anni '70 di proporre una misura delle dimensioni di un sistema software basata sui suoi requisiti funzionali era un brillante esempio di pensiero laterale. Ma questo metodo, ora sviluppato e supportato dall'organizzazione IFPUG, mostra la sua età.

Il Metodo COSMICO utilizzato da Renault è stato progettato da un gruppo internazionale di esperti di metriche del software per essere applicabile al business, software in tempo reale e di infrastruttura, basata sui principi fondamentali dell'ingegneria del software. Sono disponibili variazioni del metodo per produrre dimensioni approssimative per misurare i requisiti prima che siano noti in modo sufficientemente dettagliato per una misurazione precisa, e il metodo ha o viene automatizzato con vari mezzi. (La misurazione automatizzata è fondamentale per Renault; il conteggio manuale sarebbe troppo lento per il loro processo di sviluppo.) Il metodo è ideale per misurare i requisiti a qualsiasi livello di aggregazione negli sviluppi agili, per esempio. Diamo un'occhiata più da vicino a queste metriche principali. Iterazioni, rilasci, eccetera., e per i componenti dei sistemi distribuiti.

Un esempio di problema che può essere evitato utilizzando il metodo COSMIC è sorto in un importante fondo pensione europeo che aveva utilizzato il metodo IFPUG FPA per il dimensionamento come base per la stima. La scala FPA offre solo una ristretta gamma di dimensioni per le transazioni; il metodo COSMIC misura su una scala di rapporti senza limite superiore. Un progetto è stato esaminato per scoprire in che modo fosse stato seriamente sottovalutato. Alcune transazioni che hanno ottenuto il punteggio massimo IFPUG di 6 o 7 I FP sono stati rimisurati utilizzando il metodo COSMIC e sono risultati essere finiti 60 FP COSMICI. Le transazioni con size over 40 I FP COSMIC hanno rappresentato quasi 80% del superamento del budget.

Cosa si può fare per colmare il divario di stima dal mondo caotico a quello controllato?

Il consiglio di Jorgensen su come ottenere il meglio dalla stima del giudizio degli esperti è fortemente raccomandato e le osservazioni di Kahneman sulla previsione basata sul giudizio intuitivo devono essere prese in considerazione. Ma se il mondo caotico deve colmare il divario, deve fare di più che affidarsi a stime intuitive. Deve raccogliere dati concreti sulle prestazioni dei progetti completati e sviluppare semplici metodi di stima utilizzando metodi moderni di misurazione dei requisiti. Se si acquista da un fornitore esterno, i clienti devono imparare come i fornitori determinano i loro prezzi di offerta.

Anche con questi passaggi, rimane il problema intrinseco nel mondo caotico che le stime sono spesso richieste e i budget devono essere stabiliti all'inizio della vita di un sistema software prima che i requisiti siano noti in dettaglio. In questa fase una stima deve inevitabilmente avere un range di incertezza molto ampio. Quindi cosa si può fare per mitigare gli effetti di questa sfida?

La risposta è un processo che è stato sviluppato 15 anni fa dal governo dello Stato di Victoria in Australia, ma non è mai stato ampiamente applicato.
In schema semplificato, quando un cliente emette un ITT con una dichiarazione iniziale dei requisiti, ai fornitori viene chiesto di stimare l'eventuale dimensione totale e di offrire un prezzo fisso per unità di dimensione funzionale. Il prezzo di offerta totale è quindi il prodotto di questi due fattori. Quando viene aggiudicato un contratto e man mano che i requisiti si evolvono, il prezzo unitario rimane fisso, ma il prezzo totale varierà in proporzione all'entità del fabbisogno. La dimensione effettiva è monitorata da un Scope Manager indipendente, un "ispettore quantitativo" del software. Il cliente si assume quindi il rischio di variare l'entità dei requisiti; il fornitore si assume il rischio di offrire il giusto prezzo unitario in base alla sua conoscenza delle esigenze del cliente e delle proprie capacità. Con questo processo, le asimmetrie informative e di rischio tra cliente e fornitore sono notevolmente ridotte.

Il processo australiano è stato perfezionato in Finlandia, dove è noto come "Northern Scope". Viene applicato o sperimentato in vari paesi. I fautori del metodo affermano che il superamento dei costi può essere ridotto all'interno 10%.

Ma i maggiori vantaggi rivendicati sono riduzioni molto sostanziali dei costi unitari del software e dei miglioramenti nella velocità di consegna dei progetti software. La capacità di misurare i requisiti gioca qui un ruolo più ampio di quanto si possa immaginare, vale a dire come fattore di controllo della qualità. Se i requisiti non sono sufficientemente precisi da poter essere misurati, il software certamente non può essere costruito e testato in modo affidabile! Si vedrà che sia il processo Renault per la gestione della fornitura di software embedded per le sue centraline sia il processo Northern Scope si basano sul prezzo unitario del software come caratteristica chiave.

In conclusione, gli strumenti sono disponibili per il mondo caotico per colmare in gran parte il divario con il mondo controllato sulla stima del progetto software. Ma non ci sono proiettili d'argento, nessuna risposta rapida e pronta. Una mentalità ingegneristica e la disponibilità a investire nella raccolta e nell'analisi dei dati sulle prestazioni effettive sono essenziali.

Circa l'autore

Charles Symons è fondatore e Past President di Consorzio internazionale per la misurazione del software comune. Puoi contattarlo all'indirizzo cr.symons@btinternet.com. Questo post è apparso in precedenza nel 2015 bollettino invernale del Società per analisi e previsioni dei costi.

Un post sul blog rappresenta l'opinione personale dell'autore
e potrebbe non coincidere necessariamente con le politiche ufficiali di Nesma.