Misurazione del software: una panoramica per i CIO

La misurazione del software è importante perché è difficile gestire ciò che non si misura. Il lavoro sul software è lavoro di conoscenza. Si tratta di una delle imprese più costose intraprese dall’umanità, con oltre 50 milioni di persone in tutto il mondo che lavorano in ruoli software ben retribuiti e, per la maggior parte di loro, i loro sforzi non sono misurati. Molte persone non si rendono conto che le dimensioni del software possono essere misurate. La maggior parte delle altre forme di lavoro umano hanno misure standardizzate di dimensioni e produttività. Ma con il lavoro del software, sebbene esistano metriche adeguate, queste vengono utilizzate raramente. I leader del settore, gli educatori, i dirigenti e persino i governi finora si sono mostrati rilassati riguardo a questo fenomeno, ma con la crescente importanza del software per la sopravvivenza aziendale, sono necessarie maggiore trasparenza e misurazioni adeguate del software. L’introduzione della misurazione del software con il dimensionamento COSMIC aiuterà i CIO a gestire in modo più efficace.

La misurazione del software aiuta a rispondere alle domande chiave

Quando si cerca di rispondere alle domande di quanta fatica è necessario per fornire un progetto software o quando sarà finito, la maggior parte delle organizzazioni si affida alle opinioni degli esperti. Queste stime software tendono ad essere non scientifiche e soggette a manipolazione. Ciò di cui hanno bisogno è un mezzo coerente di misurazione del software. Costituiscono una base inadeguata per decisioni gestionali affidabili e spesso possono portare a comportamenti controproducenti. Tuttavia, con stime software valide e standardizzate e metriche software basate sul dimensionamento funzionale standardizzato nei Function Point COSMIC (CFP), i CIO possono migliorare significativamente la visibilità, la gestibilità, la produttività e il rapporto qualità-prezzo del lavoro software nella loro organizzazione. Anche le metriche software basate sulla CFP e le corrispondenti metriche di progetto sono appropriate per il reporting a livello di consiglio. Questa lettura di 15 minuti sarà sufficiente per iniziare questo viaggio verso livelli più elevati di gestione del software.

La misurazione software delle dimensioni conta.

Consideriamo alcune caratteristiche generali peculiari del lavoro del software:

• Il lavoro del software è quasi interamente guidato dallo sforzo umano.
• Ci sono molti fattori che determinano lo sforzo necessario per sviluppare alcuni software. Il fattore più significativo è dimensione funzionale.
• Dimensioni funzionali può essere stimato e in alcuni casi anche misurato prima che inizi la codifica.
• Ci sono dozzine di altri fattori che influenzano lo sforzo necessario per sviluppare software, tra cui: competenza del team, complessità e supporto esecutivo, ma la dimensione è la più significativa.
• Esiste un'elevata variabilità nella produttività tra gli sviluppatori. 10 volte o più tra il meno produttivo e il più produttivo – e lo stesso per i team.
• Il lavoro del software non è scalabile. Esistono diseconomie di scala, causate principalmente dall’elevata percentuale di tempo trascorso a comunicare tra i membri del team. Un linguaggio comune e la conoscenza delle dimensioni di un progetto possono aiutare a contenere questo problema.

Da quando il software è diventato un’industria, il dimensionamento del software è stato oggetto di infiniti dibattiti tra sviluppatori e manager. Dato il numero di persone coinvolte nell’industria del software, è sorprendente che dirigenti e consigli di amministrazione abbiano permesso che ciò accadesse.

Sebbene siano molti i fattori che influenzano il costo e la durata di un progetto software, la dimensione è il fattore più significativo. Se hai analizzato i requisiti e determinato la dimensione funzionale nei CFP, puoi prevedere, con ragionevole certezza, quanto tempo ci vorrà e quanto dovrebbe costare. Queste sono domande vitali a cui i manager responsabili devono rispondere per pianificare in modo efficace. Conoscere le dimensioni funzionali nelle prime fasi del ciclo di vita di un progetto può aiutare a migliorare la qualità delle decisioni prese dai manager e quindi può ridurre il rischio, i costi e la durata del progetto. Sono disponibili parametri di riferimento del settore oppure le organizzazioni possono stabilire i propri parametri di riferimento per la produttività nella CFP, al fine di rispondere alla domanda "quando avremo finito?" domanda.

Misurazione del software e ingegneria del software

Tutte le altre forme di ingegneria adottano misure dimensionali standardizzate (ISO). L’ingegneria del software è l’unica “disciplina” di ingegneria che non è riuscita a farlo. L'ingegneria del software dovrebbe abbracciare la misurazione delle dimensioni standardizzata.

Dimensionamento del software standardizzato

Molte persone pensano che la misurazione delle dimensioni del software possa essere eseguita solo dopo che il lavoro è stato completato. Non è così. Il software può essere misurato prima ancora che la codifica sia iniziata.

La maggior parte delle persone coinvolte nel settore non sono consapevoli del fatto che la misurazione delle dimensioni del software è possibile e facile da eseguire, anche prima che venga avviato qualsiasi lavoro di codifica. La dimensione funzionale può essere determinata semplicemente esaminando le esigenze dell'utente.  

È possibile contare le righe di codice dopo che il software è stato scritto, ma il conteggio delle righe di codice (LOC) ha poco valore tranne quando si considera il lavoro per mantenere ciò che è già stato scritto. Inoltre, considera due sviluppatori che scrivono alcune funzionalità, lo sviluppatore A può scriverlo in sole 4 righe di codice, mentre lo sviluppatore B impiega 40 righe per ottenere la stessa funzionalità. Qual è più grande? Quale è più produttivo? Quale è più soggetto a errori? Ciò ci mostra che non possiamo utilizzare in modo affidabile il LOC come predittore della stima delle dimensioni, dello sforzo o del tempo.

La misurazione del software delle dimensioni funzionali porta a decisioni sul software basate sui dati

Come società ci stiamo muovendo rapidamente verso un processo decisionale basato sui dati. Anche per le decisioni a casa, esaminiamo recensioni e dati tecnici prima di prendere una decisione di acquisto. Affinché questo approccio sia efficace, dobbiamo utilizzare dati validi, coerenti e affidabili. Avendo esaminato per molti anni le misure fondamentali nello spazio software, abbiamo concluso che le metriche basate sulle dimensioni COSMIC sono le più affidabili.

• Dimensioni o ambito (CFP),
• Metriche di produttività (CFP/tempo),
• Metriche di qualità del software (Difetti/CFP) e
• Risorse (risorsa/PCP).

Passare al dimensionamento delle buone pratiche del software

Misurare e stimare il software è stata una sfida sin dagli albori dell’industria del software. Salteremo la lezione di storia e passeremo direttamente allo stato attuale della situazione. La maggior parte dei team software agili stima l’impegno utilizzando indicatori “equivalenti allo sforzo” non scientifici e incoerenti punti della storia O Taglie delle magliette.  Punti della storia E Taglie delle magliette sono ipotesi proxy inaffidabili, non lineari e altamente giocabili per quanto tempo ci vorrà per svolgere una parte del lavoro. Il numero di punti della storia assegnato da uno stimatore o da un team sarà influenzato dalle motivazioni di chi dichiara la dimensione. I “punti della storia” sono spesso l’unico indicatore che viene offerto ai manager per aiutarli a pianificare e gestire il lavoro, quindi questi indicatori vengono abusati e abusati come una sorta di metrica affidabile, quando sono lontani da esso. In alcuni casi il conteggio delle storie viene utilizzato come indicatore di progresso e dimensione. I nostri studi su oltre 250.000 storie utente hanno mostrato una variazione nella dimensione della storia di 2-120 CFP, evidenziando che la dimensione della storia è incoerente e quindi il conteggio delle storie non è affidabile.

La soluzione a questo problema è disponibile ormai da diversi anni: si tratta della misurazione standard ISO delle dimensioni funzionali del software nota come COSMIC Function Point (CFP). Il dimensionamento COSMIC è una metodologia gratuita che rappresenta uno standard internazionale stabile, governato da un'organizzazione senza scopo di lucro  https://www.cosmic-sizing.org/. Lo standard COSMIC è un adattamento del concetto originale di dimensionamento funzionale inventato da Alan Albrecht, membro dell'IBM, nel 1974.

Il COSMIC Function Point (CFP) è un'unità di misura della dimensione funzionale che può essere applicata a QUALSIASI progetto software, lavoro DevOps, manutenzione software o implementazione di pacchetti. Si tratta di una misura di dimensione coerente e universale che può essere utilizzata indipendentemente dai metodi di codifica o dai linguaggi utilizzati. Viene gradualmente riconosciuto come lo standard principale per il dimensionamento e viene insegnato in un numero crescente di corsi di ingegneria informatica in tutto il mondo.

Il dimensionamento COSMIC consente di stimare o misurare la dimensione funzionale (il numero di CFP) all'interno di una porzione di software. Rappresenta una visione delle dimensioni dal punto di vista dell'utente, non da un punto di vista tecnico. (Si noti che un “utente” può essere un altro attore del sistema, quindi questa metodologia può essere utilizzata anche per i sistemi embedded). È indipendente dalla tecnologia o dall'architettura utilizzata per fornire il software e quindi può essere utilizzato in un intero portafoglio di software e attività di manutenzione.  In qualità di CIO puoi misurare tutti i tuoi progetti software e le attività di manutenzione del software. Beneficerai di metriche software valide e coerenti in base alle quali prendere decisioni ben informate.  Puoi anche misurare i progetti passati per fornire parametri di riferimento per la produttività.

Vogliamo sapere quando sarà finito

Questa è una sfida comune affrontata dai CIO. E normalmente è molto difficile rispondere. Ma quando si utilizzano i CFP come metrica di dimensione standard e si monitora l'output dei team di sviluppo in CFP al mese o CFP per sprint, la data di fine diventa prevedibile. Misurare le dimensioni del software è fondamentale per ottenere parametri software validi e rispondere alla domanda cruciale: quanto tempo ci vorrà.

La dimensione della PCP e la sua relazione con l'impegno

La dimensione della CFP sembra essere un eccellente predittore dell’impegno, e quindi dei costi. Studi indipendenti hanno dimostrato che la CFP è un predittore dei costi più coerente rispetto alla stima effettuata da un team in termini di story point (vedere i grafici seguenti). I tassi di produttività variano da team a team, ma ogni singolo team, a parità di tutte le altre condizioni, è probabile che fornisca un numero consistente di CFP per sprint o per mese. Pertanto, puoi determinare rapidamente il costo per CFP.

Adatto per Contratti

Poiché la CFP è una misura coerente e indipendente, può essere utilizzata anche nei contratti software. Invece di essere costretti a stipulare un contratto “tempo e materiali” con un fornitore di sviluppo, i CIO possono richiedere contratti basati sul costo per CFP. Ciò può garantire una maggiore certezza dei costi, anche se non si conoscono ancora tutti i requisiti. È probabile che i contratti software in outsourcing basati sugli story point ti costino 10% in più e richiedano circa 10% in più rispetto a quelli basati su un prezzo fisso fisso per CFP. In tali contratti dovrebbero includere anche obiettivi di produttività (ad esempio CFP/mese) e qualità (limiti su difetti/CFP riscontrati nei test di accettazione, per criticità).

Imparare a misurare le dimensioni

La tecnica di dimensionamento delle funzionalità del software in CFP richiede circa un giorno per apprendere le nozioni di base e circa tre settimane per diventare esperti e certificati. Con l'esperienza, sarai in grado di determinare la dimensione equivalente di un anno di lavoro di sviluppo da parte di uno staff in meno di un giorno di dimensionamento. Se scegli di utilizzare il nostro strumento di dimensionamento automatizzato, ScopeMaster, il dimensionamento CFP può essere eseguito ancora più velocemente e con il minimo sforzo.

Dimensionamento del software standardizzato nella tua organizzazione

Come in tutte le cose, l’uso di pesi e misure standardizzati porta a un mercato più giusto e trasparente. Il dimensionamento standardizzato del software farà lo stesso per il mercato dei servizi software: è solo questione di tempo. Fino ad allora, ci sono vincitori e vinti. I soli Stati Uniti spendono $500 miliardi all’anno in software aziendale. Stimiamo che oltre 30% di questo importo potrebbero essere risparmiati con l’adozione di misure software standardizzate.

Se vuoi sapere perché gli esseri umani fanno quello che fanno, vale sempre la pena seguire la pista del denaro. Ci sono istituzioni multimiliardarie che prosperano grazie a contratti “tempo e materiali” e i cui interessi commerciali saranno minacciati dall’introduzione di dimensionamenti standardizzati. Al giorno d'oggi la maggior parte del lavoro software viene commissionato in base al tempo e ai materiali, con pochi rischi commerciali per il fornitore. Una volta che le organizzazioni acquirenti iniziano a insistere per pagare produzione invece di sforzo per quanto riguarda il lavoro sul software, l’equilibrio del rischio commerciale si sposterà leggermente dal venditore all’acquirente.

Inoltre, molti consulenti, coach agili, fornitori di framework e persino sviluppatori traggono vantaggio dalla mancanza di trasparenza derivante dal non dimensionamento formale del software.

Utilizzando il dimensionamento CFP, gli acquirenti saranno in grado di procurarsi servizi software tra cui sviluppatori, tester, coach agili, architetti e persino consulenti con un costo per CFP. A tempo debito, un’ampia adozione del dimensionamento CFP sarà inevitabile perché coloro che acquistano i servizi software scopriranno che non solo è più trasparente e misurabile, ma che con un dimensionamento adeguato è possibile fornire più software, più velocemente. Alla fine questo porterà alla mercificazione del lavoro del software.

La capacità di realizzare progetti di cambiamento del software più velocemente e meglio della concorrenza sta diventando un fattore determinante per la sopravvivenza aziendale. Utilizzando misurazioni valide, puoi determinare quali team, fornitori e progetti hanno effettivamente successo rispetto a quelli che fingono di esserlo. Ad esempio, se la squadra A consegna 1000 CFP in 12 mesi per $1m di dollari, mentre la squadra B consegna 700 CFP in 20 mesi per $2m, puoi vedere chiaramente chi sta facendo un lavoro migliore. Ciò non è possibile senza il dimensionamento CFP.

Ci sarà resistenza all’adozione di un dimensionamento trasparente del lavoro del software. La trasparenza e la misurabilità possono rappresentare una minaccia per coloro che traggono vantaggio dalla loro assenza. Dovresti aspettarti resistenze da parte dei tuoi fornitori di sviluppo e persino dei tuoi team di sviluppo interni, che attualmente godono di un grado di libertà che deriva dal fatto di non essere misurati.

Sentirai risposte del tipo "non abbiamo il tempo per farlo". Per una tipica storia utente raffinata, saranno necessarie fino a 2 ore di conversazione aggregata da parte dello staff per modellare, analizzare e stimare i punti della storia. Mentre la CFP può essere determinata in pochi minuti.

Un'altra reazione che incontrerai è "abbiamo già molti parametri". In risposta a ciò, dovrai mettere alla prova i tuoi team sulla validità delle “metriche” che attualmente forniscono. Ecco alcuni cosiddetti parametri comunemente utilizzati e i loro difetti rispetto agli equivalenti basati sulla CFP. Questi sono indicatori comunemente usati, possono essere utili ma NON sono metriche valide basate su a sistema metrico.

• Punti della storia – questi sono soggettivi, giocabili, non scientifici e incoerenti all’interno e tra i team. I punti storia sono essenzialmente un proxy per una stima delle ore di impegno. Utilizzare invece la CFP.
• Taglie delle magliette– sono anche indicatori di sforzo soggettivi, giocabili, non scientifici e incoerenti.
• La storia conta – le storie variano in termini di dimensioni assolute, in genere vanno da 2 a 120 CFP, in media 6 CFP, quindi il conteggio delle storie di dimensioni non equivalenti è un indicatore di progresso inaffidabile.
• Velocità agile – citato in storie o story points nel tempo. Vedere Punti della storia, questo dovrebbe essere considerato un indicatore di produttività. Utilizzare invece: CFP per sprint o mese`
• Burndown dello sprint O combustione settimanale– in base ai punti della storia o al conteggio delle storie. Usa invece PCP consegnato.

N.B. Tempo di ciclo, lead time, tasso di correzione dei difetti, complessità del codice, tasso di scoperta dei difetti, E copertura di prova Sono esempi di metriche valide che incoraggiamo.

Utilizzo della CFP come metrica di base per il controllo dei progetti

Oltre a utilizzare la CFP per dimensionare il portafoglio software e i progetti, puoi utilizzare le metriche basate sulla CFP come base per controllare l'avanzamento del progetto:

• produttività (CFP/mese),
• qualità (difetti riscontrati/CFP)*
• pianificazione delle risorse umane come l'assegnazione del lavoro (in CFP) per individuo.
• scopo (CFP), modifica dell’ambito e volatilità dell’ambito

*questo può essere ulteriormente suddiviso in difetti per criticità e difetti per fonte, il tutto per CFP.

Queste sono tutte misure vitali per controllare efficacemente i progetti software. Inizierai rapidamente a vedere quali progetti stanno andando bene e quali hanno bisogno di aiuto.

PCP e Qualità

Diamo uno sguardo alla relazione tra qualità del software e dimensionamento o conoscenza della dimensione (in CFP).

Il processo di dimensionamento aiuta con la qualità

Il processo di dimensionamento ci incoraggia a riflettere profondamente sui requisiti funzionali necessari per offrire una preziosa capacità aziendale. Questo modo di pensare aiuta a eliminare tempestivamente potenziali malintesi. Questi malintesi si manifesterebbero altrimenti come difetti. Quindi il processo di dimensionamento della CFP è, in effetti, “il massimo dei test di spostamento a sinistra”.

La conoscenza delle dimensioni aiuta a migliorare la qualità

Conoscere la dimensione può aiutarci (quando si utilizzano i benchmark) a prevedere il numero di difetti che potremmo aspettarci di trovare in un software. Questa previsione, a sua volta, ci aiuterà a determinare quanti test sono necessari?   Lavorando con difetti per CFP, il nostro apprezzamento per la qualità migliora.

L'analisi automatizzata aiuta anche a migliorare la qualità

Scegliendo di utilizzare ScopeMaster® per analizzare e testare i requisiti, scoprirai immediatamente circa 50% dei problemi relativi ai requisiti latenti che potrai quindi risolvere rapidamente e tempestivamente. Ciò rappresenta circa l'8% di tutti i difetti di un progetto e ancora di più in quelli più grandi.

Gestione della qualità del fornitore con CFP

Quando si utilizza un contratto che insiste su un livello massimo di difetti accettabili per CFP, è possibile incoraggiare i fornitori a garantire la qualità. Qualcosa che sui contratti T&M potrebbero essere meno motivati a fare.

Limitazioni della misurazione delle dimensioni funzionali con CFP

I CFP sono una misura della dimensione funzionale dal punto di vista dell'utente. Misurano i movimenti di dati di un sistema software. Non possono misurare dimensione computazionale di una transazione software, né possono essere utilizzati per misurare “non funzionaleaspetti del lavoro del software, come prestazioni, manutenibilità, usabilità (e altre funzionalità). Questa non è solo una lacuna della PCP ma un fallimento dell’intero settore, nessuno ha ancora ideato misure valide e coerenti di queste due dimensioni (dimensione computazionale, E NFR) del software.

Anche con queste limitazioni, la correlazione tra CFP e lo sforzo compiuto per svolgere il lavoro è eccezionale, il che significa che conoscere la dimensione in CFP fornirà un indicatore molto forte di quanto impegno è necessario e quindi di costi e tempistiche: i due elementi di conoscenza della pianificazione di cui i project manager e i responsabili dello sviluppo hanno bisogno per prendere decisioni valide.

Quando puoi stimare o misurare la taglia

La stima della CFP può essere eseguita in qualsiasi momento del ciclo di vita dello sviluppo del software, anche all'inizio, non appena i requisiti aziendali iniziano ad emergere. Le prime stime possono diventare più precise e accurate man mano che aumenta la conoscenza delle funzionalità dell'utente. Man mano che i requisiti evolvono, la certezza delle stime aumenta e alla fine le stime possono diventare una misurazione accurata. Per eseguire una misurazione accurata, è sufficiente conoscere tutti i movimenti di dati associati a ciascun requisito funzionale (o user story funzionale). Con CFP è possibile dimensionare qualsiasi dato insieme di requisiti, non è necessario conoscere tutti i requisiti in anticipo, né è necessario conoscere il progetto per determinare la dimensione CFP. Al più tardi, dovresti misurare la dimensione CFP di una user story appena prima che venga accettata in uno sprint. Puoi anche stimare o misurare progetti passati per creare dati di riferimento per benchmark interni di produttività.

Gli svantaggi dell’adozione della PCP

Ci sono molte persone nel mondo del software il cui sostentamento trae vantaggio dall’assenza di misurazioni coerenti delle dimensioni. Tra i maggiori beneficiari ci sono quelle organizzazioni che vendono servizi di sviluppo software in base al tempo e ai materiali. Ciò include alcune organizzazioni molto grandi e influenti. Inoltre, molti consulenti, coach agili, fornitori di framework e persino sviluppatori traggono vantaggio dalla mancanza di trasparenza derivante dal non dimensionamento formale del software. Gli errori possono essere nascosti, la produttività è difficile da valutare e questo può soddisfare i loro interessi. D’altro canto, per chiunque sia responsabile dell’acquisto o della gestione del lavoro relativo al software, non vi è alcun aspetto negativo nella misurazione con la CFP. Ci vuole uno sforzo insignificante per eseguire la misurazione. Sia la conoscenza delle dimensioni che l'atto del dimensionamento della CFP possono aiutare a ridurre i problemi di ambito, migliorare la qualità e aumentare la produttività su qualsiasi progetto software.

La CFP è perfetta per Agile e Scaled Agile

I requisiti completi di un progetto software raramente sono noti all'inizio del progetto. Il flusso di lavoro Agile ti consente di gestire questa incertezza iniziale. I progetti agili sono caratterizzati da una consapevolezza in evoluzione dei requisiti. Fortunatamente, la PCP Potere essere misurati con precisione anche prima che tutti i requisiti di un sistema siano noti. Misura semplicemente ciò che sai. Puoi anche potenzialmente stimare ciò che non è ancora noto con certezza. Con l'esperienza puoi anche fare una stima anticipata quando sono note solo le capacità generali o le epiche. Man mano che il progetto avanza, le epiche vengono suddivise in storie utente funzionali e quelle stime iniziali diventano misure più precise della CFP con un margine di errore decrescente. Pensate alla certezza dei requisiti come a uno spettro che va da “sappiamo tutto” a “sappiamo molto poco”. Sebbene sia più semplice dimensionare un progetto se si conoscono tutti i requisiti, è sorprendente quanto si possa sapere fin dall'inizio. In generale, all'inizio non lavoriamo abbastanza duramente per scoprire ciò che è conoscibile.

Nelle organizzazioni con più team software, i senior manager devono conoscere la produttività dei diversi team, al fine di contribuire a migliorare i team con prestazioni inferiori e imparare da quelli altamente produttivi. La CFP risolve il problema della mancanza di dimensionamento coerente tra le squadre. Adottando la CFP in tutti i team, è possibile confrontare i tassi di produttività. I tassi di produttività possono anche essere confrontati tra team interni ed esterni. Ciò aiuta a fornire ai dirigenti del software i dati di cui hanno bisogno per prendere decisioni migliori. Non si dovrebbero mai confrontare le squadre con gli story point.

È giunto il momento di controllare le dimensioni del software

Dopo 70 anni di congetture e approcci non scientifici, è giunto il momento che i CIO responsabili e i leader del software insistano sull’adozione di parametri ingegneristici adeguati per le dimensioni. Introducendo e insistendo sull'adozione della CFP, godrai di una migliore visibilità e prevedibilità della tua attività software. Ci saranno degli oppositori nella tua organizzazione e tra i fornitori, quindi dovrai essere pronto a incoraggiarli a vedere i meriti di una misurazione delle taglie valida. La misurazione delle dimensioni del software è una buona pratica. Ciò porta a una migliore misurabilità e, in definitiva, a una gestione più efficace. A tempo debito sarai in grado di condividere i parametri relativi alla CFP erogata e mantenuta come parte dei parametri a livello di consiglio di amministrazione. I CIO lungimiranti che desiderano essere in grado di migliorare le prestazioni attraverso la misurazione trarranno notevoli vantaggi dall’adozione della CFP.

L'automazione è qui per aiutarti

Il nostro lavoro innovativo presso ScopeMaster fornisce un dimensionamento automatizzato, coerente e valido delle storie degli utenti funzionali o dei requisiti degli utenti funzionali scritti senza sforzo. ScopeMaster stimerà il numero di CFP in una storia utente analizzando il linguaggio della storia. La maggior parte dei progetti agili contiene meno di 500 storie utente. Questi possono essere dimensionati automaticamente entro un'ora utilizzando ScopeMaster. Le storie degli utenti possono quindi essere perfezionate (migliorate in termini di qualità) e la stima diventerà una misurazione, questo in genere richiede un decimo del tempo utilizzando ScopeMaster® che senza.

Prossimi passi.

Se desideri saperne di più su come misurare il tuo portafoglio software, conoscere le metriche software valide e misurare la produttività dello sviluppo per dare maggiore certezza ai tuoi progetti software, ecco alcuni passaggi successivi suggeriti:

1. Incoraggia il tuo team di gestione a scoprire il dimensionamento COSMIC nella CFP, consigliamo il Guida alla misurazione del software
2. Incoraggia il tuo PMO a introdurre il dimensionamento della CFP come metrica nella gestione del portafoglio
3. Chiedi ai tuoi fornitori di riferire sulla CFP erogata per sprint o per mese
4. Chiedi ai tuoi responsabili della qualità di esaminare i rapporti sui difetti rilevati per CFP.
5. Chiedi al tuo team dedicato ai contratti di indagare sui contratti a prezzo fisso per CFP e chiedi ai tuoi fornitori di quotare il costo per CFP.
6. Anticipa le resistenze interne alla tua organizzazione e da parte dei fornitori, sii pronto a contrastarle con la tua esigenza di miglioramenti in termini di trasparenza delle dimensioni, produttività, rapporto qualità-prezzo e misurazione della qualità.

Contatta ScopeMaster per esplorare il nostro strumento di dimensionamento automatizzato e indicazioni sull'adozione della CFP nella tua organizzazione.

A proposito di Colin Hammond

Colin Hammond è un esperto in dimensionamento del software, garanzia dei progetti e analisi automatizzata dei requisiti software. Interviene regolarmente a conferenze su project management, test di software, analisi aziendale e analisi dei costi. Colin è il fondatore e CEO di ScopeMaster che fornisce il pluripremiato strumento di dimensionamento funzionale automatizzato ScopeMaster e servizi professionali su come adottare e utilizzare il dimensionamento funzionale.

Grazie a

Sono molto grato a Kirk Bryde (Agile Coach) e Lonnie Franks (Esperto di Software Project Assurance) per il loro prezioso contributo editoriale a questo articolo.

Riferimenti

McConnell, Steve. “Stima del software, demistificazione dell’arte nera”

Boehm, Barry et al 2000. “Stima dei costi del software con COCOMO II”

Garmus, David e Herron, David. "Analisi dei punti funzione: pratiche di misurazione per progetti software di successo."

Jones, Capperi. “Misurazione applicata al software: garantire produttività e qualità”

Symons, Carlo”Una guida alla misurazione delle dimensioni del software"