Come e tecniche per stimare precisamente il costo del software in informatica

Come e tecniche per stimare precisamente il costo del software in informatica

Produttività

In informatica, la valutazione del costo del software dipende dalla produttività dello stesso. Le stime di produttività sono generalmente basate sulla misurazione di determinati attributi del software e poi divise per lo sforzo totale richiesto per lo sviluppo. Le due metriche usate sono di due tipi:

  1. Dimensionali: dipendono dalla dimensione di uno o più output legati ad un’attività. La metrica più comunemente usata è data dalle linee di codice prodotte. Altri parametri che possono essere utilizzati sono il numero di istruzioni di codice oggetto e il numero di pagine di documentazione del sistema.
  2. Funzionali: dipendono dalle funzionalità complessive del codice. La produttività è espressa nei termini dell’ammontare di funzionalità realizzate in un determinato periodo temporale. Le metriche meglio conosciute sono function points e object points.

Come e tecniche per stimare precisamente il costo del software in informatica

Le linee di codice per programmatore-mese (LOC/pm) sono ampiamente usate come metrica per la produttività. Si può calcolare LOC/pm contando il numero totale di linee di codice sorgente, diviso il numero di programmatorimesi richiesti per completare il progetto.
Questo approccio è stato sviluppato quando la maggior parte della programmazione era in FORTRAN, assembly o COBOL e i programmi erano scritti su schede perforate. Il numero di linee di codice era facile da contare: su ogni scheda era presente uno statement, quindi bastava contare il numero di schede totali. Ora, in linguaggi di programmazione come Java o C++ in cui si possono includere macro che espandono il programma a molte linee di codice o al contrario mettere più istruzioni in un’unica linea, viene meno la semplice relazione tra istruzioni e linee di codice.
Confrontare la produttività dei linguaggi di programmazione può non essere corretto in quanto taluni possono essere molto espressivi ma con un’apparente minore produttività. Questa anomalia è dovuta al fatto che tutte le attività di sviluppo del software sono considerate insieme nel calcolo del tempo di sviluppo, ma la metrica LOC si applica solo al processo di programmazione. Pertanto se un linguaggio richiede più linee di un altro per implementare la stessa funzionalità, la stima di produttività è falsata.

Per sopperire a queste anomalie si può stimare qualche attributo del software, per esempio il numero di funzionalità che sono indipendenti dal linguaggio di programmazione. La produttività è espressa in numero di function point implementate per persona-mese. Una function point non è una singola caratteristica ma una combinazione di diverse misurazioni o stime come:

  • input/output esterni;
  • user interaction;
  • interfacce esterne;
  • file usati dal sistema.

Ognuna di queste ha complessità diversa, quindi come si propone nella unadjusted function-point (UFC), ad ogni elemento di un dato tipo viene associato un peso. Il difetto di questa tecnica risiede nel fatto che dipende dalla complessità del sistema e da chi effettua la valutazione.
In alternativa alle function point ci sono gli object point, che possono essere usati con linguaggi di programmazione per database e di scripting, che non correlati all’approccio object-oriented.

Il numero di object point di un programma è la valutazione pesata del:

  • numero di schermate che sono visualizzate;
  • numero di report che sono prodotti;
  • numero di moduli che devono essere sviluppati in linguaggi come Java e C++ a supporto del codice dei linguaggi data-oriented.

Entrambe le tipologie presentano problemi: per esempio se si fanno calcoli solo sulla dimensione si tralascia quella che è la qualità del software come affidabilità e manutenibilità. D’altra parte la produttività del software dipende strettamente dal dominio di applicazione e dalle organizzazioni.

In generale vi è una serie fattori che influenzano la produttività come:

  • la conoscenza del dominio applicazione;
  • il processo di sviluppo utilizzato;
  • la dimensione del progetto(più è grosso più è necessario spendere tempo nella comunicazione sacrificando lo sviluppo);

Tecniche di valutazione

Non c’è un modo semplice ed unico per valutare lo sforzo richiesto per sviluppare un software; a seguire le principali tecniche utilizzate.

  1. Modellazione algoritmica dei costi: un modello è sviluppato utilizzando le informazioni del costo storico che si riferisce ad alcune metriche software (di solito le sue dimensioni) per il costo del progetto.
  2. Expert judgement: sono consultati diversi esperti e ognuno stima il costo del progetto. Successivamente tali stime vengono messe a confronto per raggiungere una stima di comune accordo.
  3. Stima per analogia: l’applicabile quando altri progetti dello stesso dominio di applicazione sono terminati e quindi sono presi come riferimento.
  4. Parkinson’s law: la legge afferma che il lavoro occupa tutto il tempo a disposizione, quindi il costo è determinato dalle risorse disponibili piuttosto che dalla valutazione oggettiva.
  5. Pricing to win: il costo del software stimato coincide con il budget che il cliente ha a disposizione per il progetto, quindi non dipende dalle funzionalità del software.

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: www.vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *