La dimensione del software è il fattore principale per la stima dei costi del progetto

Di gran lunga la maggior parte dei modelli di stima dei costi per lo sviluppo di software, i progetti di miglioramento o manutenzione utilizzano le dimensioni del software come parametro di input principale. La dimensione del software è ampiamente riconosciuta come un importante fattore di costo per lo sforzo e il costo necessari per i progetti software. A differenza di molti oggetti fisici, tuttavia, non esistono standard di misurazione universali per misurare le dimensioni del software. Mentre un pittore che ha bisogno di stimare il costo di dipingere un muro di solito misurerebbe le dimensioni di questo muro in piedi quadrati o metri quadrati come input per la sua stima, la misurazione della dimensione del software è difficile a causa del fatto che non ha una forma fisica reale. tuttavia, esistono numerosi metodi disponibili nel settore che possono essere utilizzati per misurare le dimensioni del software. Per gli estimatori dei costi che non sono tuttavia esperti nel dimensionamento del software, può essere difficile capire i vantaggi e gli svantaggi dei metodi disponibili e quindi potrebbero trovare difficile selezionare il metodo migliore per il loro scopo. In questo blog, viene fornita una panoramica dei metodi più utilizzati per il dimensionamento del software a disposizione dell'industria. Anche i vantaggi e gli svantaggi di questi metodi, nonché le raccomandazioni sui metodi da utilizzare per i tipi di stime dei progetti software. Nella tabella seguente vengono visualizzati i metodi di misurazione delle dimensioni del software trattati in questo blog.

Misura delle dimensioni del softwareAmbito di misurazioneTaglia
SLOCOggetto software fisicoDimensioni tecniche in SLOC
IFPUGRequisiti utente funzionaliDimensione funzionale in FP
NesmaRequisiti utente funzionaliDimensione funzionale in FP
COSMICORequisiti utente funzionaliDimensioni funzionali in CFP
SCATTOParte dei requisiti utente non funzionaliDimensioni non funzionali in punti SNAP
Usa punti casoCasi d'uso, caratteristiche tecniche del progetto, caratteristiche ambientali del progetto"Combinazione sforzo / dimensione" nei punti caso d'uso
Punti funzione velociRequisiti utente funzionali e dimensioni della configurazioneGartner FFP
Punti della storiaElementi del backlog, funzionale e non funzionale"Combinazione sforzo / complessità" nei punti Storia

Stima dei costi del progetto software

Nella stima dei costi del progetto software, il focus è solitamente sulla stima delle ore di lavoro delle persone nel team. La ragione di ciò è che le ore di impegno di solito determinano i costi totali del progetto. Naturalmente ci sono altri costi coinvolti, per esempio. licenze, ambienti di lavoro, infrastruttura, et cetera, ma questi costi non sono determinati dalle dimensioni del software e possono anche essere calcolati in modo più semplice.

UN (semplificato) il modello di stima è visualizzato nella figura seguente.

modello di stima semplificato

Modello di stima semplificato Nesma

La dimensione del software da sviluppare è il principale parametro di input per la stima del progetto. È fondamentale per l'accuratezza della stima che la dimensione sia misurata accuratamente. Anche la selezione di un tasso di produttività realistico è un passaggio molto importante. Questo dovrebbe essere fatto sulla base di dati storici o con l'aiuto di strumenti parametrici professionali basati su dati di settore rilevanti. Di solito è preferibile utilizzare i dati aziendali, poiché questo mostra le effettive capacità dell'organizzazione che possono essere (tanto) meglio o (tanto) peggio della media del settore. Anche le caratteristiche specifiche del progetto possono essere importanti da considerare, per esempio. programma di pressione, dimensione della squadra, vincoli di qualità, et cetera. Perciò, Gli strumenti parametrici sono generalmente molto utili in questa fase della stima di un progetto.

Moltiplicando le dimensioni per la produttività, vengono calcolate le ore di sforzo lordo. Di solito sono necessari alcuni aggiustamenti sulla base di un'analisi dei rischi. Se uno ha bisogno di esserlo 99% sicuro che non ci sarà un superamento dei costi, ad esempio, le ore di sforzo saranno probabilmente regolate per creare una contingenza.

Classificazione dei metodi di misurazione delle dimensioni del software

Esiste un'importante distinzione tra metodi di misurazione delle dimensioni funzionali e altri (metodi di misurazione delle dimensioni non funzionali o metodi ibridi). I metodi di misurazione delle dimensioni funzionali misurano la funzionalità ("Cosa fa il software") che il software offre ai suoi utenti e lo quantifica in qualche modo. Più funzionalità può utilizzare l'utente, questo maggiore è la dimensione del software. Uno dei principali vantaggi di questo tipo di metodi è che la dimensione è indipendente dalla tecnologia utilizzata (per esempio. Giava, .Netto, Oracolo) e metodo di implementazione utilizzato (Culle, sviluppo a cascata, sviluppo agile, eccetera.).

I metodi di misurazione delle dimensioni non funzionali misurano gli artefatti tecnici del software, di solito il codice software che viene costruito. Sono disponibili anche metodi ibridi che misurano gli aspetti funzionali, aspetti tecnici e talvolta anche aspetti ambientali del progetto software per arrivare a una dimensione, per esempio. Usa punti caso. tuttavia, la maggior parte dei metodi misura la dimensione funzionale o la dimensione tecnica del software.

Metodi di misurazione delle dimensioni funzionali: vantaggi e svantaggi

In generale, i principali vantaggi di tutti gli standard ISO / IEC per la misurazione delle dimensioni funzionali sono:

  • La misurazione della taglia viene effettuata in modo obiettivo. Due misuratori certificati dovrebbero avere la stessa dimensione quando misurano gli stessi requisiti funzionali dell'utente;
  • La misura della taglia è ripetibile e verificabile. Se le ipotesi sono state fatte dallo specialista della misurazione, questi dovrebbero essere documentati come parte della misurazione della taglia;
  • La misura della taglia è difendibile. Questo è molto importante in quanto la dimensione funzionale viene spesso utilizzata nei contratti a prezzo unitario tra fornitori e clienti. I contratti relativi al prezzo per punto funzione sono possibili solo quando la dimensione funzionale può essere determinata senza controversia;
  • Alcuni metodi offrono metodi derivati ​​che consentono agli stimatori dei costi di misurare abbastanza accuratamente la dimensione funzionale abbastanza presto nel ciclo di vita del progetto. Ad esempio il Metodo indicativo Nesma può essere utilizzato dopo la fase di analisi dei requisiti e offre un modo rapido per ottenere un'indicazione della dimensione funzionale (+50% / -30% precisione).
  • La dimensione funzionale può essere riconosciuta come "valore" per utenti e clienti del sistema software. Più funzionalità significa più valore e quindi maggiori costi. Questo, ad esempio, rispetto alle dimensioni tecniche come le righe di codice sorgente (slocs) dove non è chiaro se più sloc significano più valore per l'utente e / o per l'azienda.
  • A causa della standardizzazione, il vantaggio più importante è che diventa possibile memorizzare i dati dei progetti completati da utilizzare nelle stime per i nuovi progetti. Proprio come il pittore che ha i dati della sua produttività in ore per piede quadrato per specifici tipi di pareti, le organizzazioni sono in grado di ottenere informazioni sulla loro produttività in termini di ore per punto di funzione. Ciò consente il benchmarking, ad esempio contro il database industriale aperto dell'International Software Benchmarking Standards Group (ISBSG).

Alcuni degli svantaggi dell'utilizzo di metodi di misurazione della dimensione funzionale per il dimensionamento e la stima del software sono:

  • La misurazione della taglia funzionale richiede persone con esperienza per svolgere questa attività. Poiché è un'attività così importante, Si consiglia vivamente di avere solo misuratori certificati che eseguono il dimensionamento e anche in questo caso un processo di revisione adeguato. Esistono alcune iniziative per misurare automaticamente la dimensione funzionale del software, ma fino ad ora queste non sono molto accurate;
  • La misurazione delle taglie funzionali richiede tempo e denaro. Di solito questo è inferiore a 1% del budget del progetto e di gran lunga la maggior parte dei progetti può essere misurata all'interno 1 settimana di durata. Di solito i vantaggi di eseguire una misurazione delle dimensioni funzionali superano il costo molte volte, in quanto consente alle parti interessate di elaborare piani più realistici ed evitare superamenti e possibili umiliazioni;
  • I metodi di misurazione delle dimensioni funzionali misurano i requisiti utente funzionali specificati nella documentazione funzionale. Ci sono alcuni requisiti per questa documentazione affinché i misuratori siano in grado di misurarla. tuttavia, se questi requisiti non sono soddisfatti, il progetto è probabilmente condannato comunque, poiché i programmatori non saranno in grado di codificare e i tester non saranno in grado di testare utilizzando questi documenti. Una misura della taglia funzionale è infatti un potente test statico sui requisiti, in molti casi vengono rilevati gravi difetti e omissioni, consentire un adeguamento precoce delle specifiche e quindi evitare i costi di una successiva individuazione e correzione dei difetti.

La dimensione funzionale dei progetti software può essere utilizzata negli strumenti e nei modelli di stima parametrica più utilizzati, per esempio. QSM SLIM, Galorath SEER, Sistemi di prezzo Trueplanning e COCOMO II.

Prossimo blog

Nel prossimo blog su questo argomento, Darò la mia opinione sui vantaggi e gli svantaggi quando si tratta di stima dei costi del progetto software dei metodi elencati nella tabella.

 

 

Circa l'autore

Harold van Heeringen è un consulente senior per le metriche del software / ingegnere senior dei costi del software per Sogeti Nederland B.V. A parte il suo lavoro per il reparto Sizing, stima & Controllo di Sogeti, è coinvolto in Nesma (membro di bordo), l'International Software Benchmarking Standards Group (ISBSG, attuale presidente) e il Common Software Metrics International Consortium (COSMICO, Consiglio consultivo internazionale, in rappresentanza dei Paesi Bassi).

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

4 Commenti

Lascia un commento
  1. dmbeckett dice:

    Mentre sono d'accordo con tutto quanto affermato, Vorrei affrontare un paio di punti che meritano considerazione. Uno dei fattori che ha l'impatto più drammatico sul costo di un progetto (e qualità) è il programma. La relazione tra costo e pianificazione non è lineare. Semplicemente dichiarato, si acquista un'unità di riduzione del programma a un costo di molte unità di impegno. Di conseguenza, quando si stima è importante esplorare l'impatto dei vari programmi poiché influenzeranno il costo. Nel “Il mitico mese di vita” Brooks ha affermato che la mancanza di una pianificazione sufficiente ha causato più errori del progetto software rispetto a tutte le altre cause combinate. La mia esperienza come estimatore di software serve solo a confermarlo.

    Mentre io sono un sostenitore e praticante o dimensionamento funzionale, ciò che conta quando si stima un progetto software è quanto tempo ci vorrà per consegnarlo, quanto costerà, qual è il miglior profilo di personale, e quanto sarà affidabile il prodotto finale. I requisiti non funzionali hanno un ruolo nel determinarli e non sono tutti costi fissi che possono essere aggiunti a un modello basato sui requisiti funzionali. Per esempio, in un'implementazione ERP una parte significativa del lavoro sarà nella configurazione del prodotto. Non c'è niente di funzionale nella configurazione, ma qualsiasi modello di stima che lo ignori produrrà risultati imprecisi.

    Durante la stima vogliamo prendere in considerazione tutti i fattori di dimensione che avranno un impatto sul costo e sulla pianificazione. Alcuni di questi sono di dimensioni funzionali, altri no.

    I migliori saluti,

    Don Beckett, CFPS

  2. Kalyana Chakravarthy dice:

    Cara squadra,
    Ho alcune domande su Estimation.

    1. Durante lo sviluppo di componenti RICEW, qual è il metodo più adatto per la stima.
    2. durante l'implementazione di Oracle R12 da ; ad esempio moduli finanziari, come stimiamo?
    Ci sono casi di studio?
    Grazie in anticipo !!!
    Saluti
    Kalyana

lascia un commento