Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D La Corte in Rete
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

Anna Rita Fasolino » 18.Stima dei costi nei progetti Software


Argomenti

  • Produttività Software e determinazione del prezzo;
  • Tecniche di stima dei costi;
  • La modellazione algoritmica dei costi ed il modello COCOMO;
  • La stima della durata dei Progetti;
  • La gestione dei Rischi nei progetti software.

I problemi fondamentali della stima

  1. Quanto vale lo sforzo richiesto per completare una attività? (quanti mesi-uomo?)
  2. Quanto tempo (di calendario) è necessario per completare una attività?
  3. Qual è il costo totale di una attività?

La stima dei costi e la tempistica di un progetto sono in genere eseguite insieme.

I fattori fondamentali dei costi

  • Costi dell’Hardware e del software.
  • Costi per viaggi e formazione.
  • Costi dello sforzo (la voce più rilevante in molti progetti), pari agli stipendi degli ingegneri/programmatori coinvolti.
  • Altri costi da considerare…
    • Costi di rifornimento, riscaldamento, illuminazione
    • Costi di tutto il personale a supporto: amministrazione, tecnici, personale delle pulizie, etc.
    • Costi di rete e telecomunicazioni
    • Costi di biblioteche e altri servizi
    • Costi di previdenza sociale
  • I costi delle risorse “a contorno” di solito valgono almeno quanto i costi legati agli stipendi delle risorse addette direttamente alla produzione.

Costi e Prezzi

Le stime servono a prevedere i costi di sviluppo di un sistema software.

Il prezzo da pagare dovrebbe essere la somma del costo più il profitto

Ma la relazione fra costi di sviluppo e prezzo richiesto al committente non è, in genere, semplice.

Ci possono essere svariate considerazioni di tipo organizzativo, economico, politico ed aziendali che possono influire sul prezzo che verrà richiesto.

Fattori per la determinazione dei prezzi del Software


Produttività di sviluppo Software

Per stimare i costi di sviluppo, può essere necessario conoscere la produttività degli ingegneri.
La produttività è una misura della velocità con cui gli ingegneri producono software e la relativa documentazione.

Un problema: in tali valutazioni della produttività non si tiene conto della qualità di quanto prodotto!
Confrontare la produttività di due team che sviluppano software con diversi requisiti di qualità non è realmente significativo.

Misure di Produttività

Richiedono la misura di qualche attributo del software e si dividono tali misure per lo sforzo richiesto per lo sviluppo.

Size related measures basate su qualche output del processo. (Es. LOC /mese programmatore).

Function-related measures basate su una stima della funzionalità del software rilasciato (es. Function-points/ pm).

Le Linee di Codice

Problema: Che cosa è una linea di codice (LOC)?

  • Il concetto era semplice per linguaggi di vecchia generazione (1 Linea -> 1istruzione->1 Scheda);
  • Non è di immediata traduzione per linguaggi moderni (una istruzione può corrispondere a più linee di codice, o una linea può contenere più istruzioni…);
  • Quali moduli del software vanno conteggiati? E quali no? (il problema dei componenti riusati).

Produttività al variare del linguaggio

Più il linguaggio è di basso livello, più il programmatore può risultare produttivo.

Es. Assembler rispetto a C

  • (es. 700 vs. 300 LOC/mese)
  • Ma il tempo per lo sviluppo in C è complessivamente più breve! Dunque si avrebbe l’assurdo che il programmatore Assembler ha migliore produttività ma consegna dopo!

Più il programmatore è verboso, più risulta produttivo.

I Function Point e l’analisi dei FP

Tecnica proposta da Albrecht [Measuring Application Development Productivity, 1979]
Approccio indipendente dal linguaggio di programmazione per misurare le funzionalità del sistema.
Può essere usata per:

  • Stimare il costo richiesto per programmare, testare il software;
  • Prevedere il numero di errori che si rileveranno durante il testing;
  • Prevedere il numero di componenti o di LOC del sistema.

Cosa sono i Function Point (FP)

I FP sono una misura di funzionalità basata su entità logico-funzionali che l’utente facilmente comprende (es. Input, output,etc.)

  • I FP sono pertanto indipendenti dal linguaggio di programmazione, quindi la produttività può essere confrontata tra diversi linguaggi.

Un FP non è una singola caratteristica ma una combinazione di caratteristiche del sistema;

  • Nati per essere applicati a Sistemi Sw di tipo Business;
  • Misura che può essere effettuata ‘presto’ nel CVS.

Function Point

I FP vengono derivati usando una relazione empirica che si basa su:

  • Misure dirette (espresse in valori interi) del Dominio delle informazioni del software;
  • Valutazione della complessità del software.

Le Misure del Dominio delle Informazioni sono catturate con riferimento al Confine (Boundary) del sistema software.

Boundary

Secondo il concetto di Boundary, esiste una linea chiusa che definisce il confine del sistema software cui è rivolta la misura.

Con riferimento al confine, sono misurate o valutate le seguenti caratteristiche del programma:

  • External input (EI)
  • External output (EO)
  • External inquiry (EQ)
  • Internal Logical File (ILF)
  • External Interface File (EIF)

External Input (EI)

Un EI rappresenta un tipo di input unico (proveniente dall’esterno dell’applicazione) fornito o da un utente o da un altro sistema, che verrà elaborato dall’applicazione.
Un input è unico se il formato è unico, o la logica con cui viene elaborato è unica.

Questi input tipicamente devono aggiungere, cambiare o cancellare dati in un File Logico Interno (ILF).
I dati possono essere informazioni di controllo o informazioni del dominio applicativo (business information). Se i dati sono informazioni di controllo non devono aggiornare nessun ILF.

External Output (EO)

Un EO è un tipo di dati unico che viene creato nell’applicazione ed è destinato all’utente, o ad altre applicazioni, attraversando il confine dell’applicazione.
Un output è unico se il formato o la logica elaborativa è unica.

Un EO consiste in report, schermate, file, messaggi d’errore…
Un EO può addizionalmente aggiornare un ILF.
Questi reports o files sono creati a partire da uno o più ILF e EIF.

External Inquiry (EQ)

Una interrogazione esterna EQ è definita come una coppia input/output unica, dove un input online produce la generazione di una risposta immediata del software, sotto forma di output online.
Un’interazione è unica se il formato o la logica di elaborazione è unica.

Una EQ ricerca dati o informazioni di controllo (da uno o più ILF e/o EIF) per una risposta immediata.

Internal Logical File (ILF)

Un ILF è un raggruppamento unico di dati logicamente correlati, o di informazioni di controllo, identificabile dall’utente, usato ed aggiornato dall’applicazione.

I dati relativi non attraversano il confine, ma risiedono internamente al confine dell’applicazione e sono gestiti attraverso gli external input (EI).

External Interface File (EIF)

Una EIF è un unico gruppo di dati logicamente correlati, o di informazioni di controllo, identificabile dall’utente, che risiede esternamente all’applicazione ma fornisce dati usati dall’applicazione.

In pratica, i dati relativi attraversano il confine del sistema e risiedono interamente all’esterno del confine dell’applicazione e sono mantenuti da un’altra applicazione.

Un EIF è un ILF di un’altra applicazione.

Calcolo dei Function Point

Esistono diverse teorie, più o meno complesse, per calcolare i FP in funzione del conteggio degli elementi prima descritti.

Il livello di complessità di ciascun elemento individuato per ognuna delle 5 precedenti categorie viene classificato in:

  • Basso (semplice)
  • Medio
  • Alto (complesso)

Ad ognuno dei livelli è associato un peso che varia da 3 (più semplice) a 15 (più complesso).

Matrice dei pesi: un esempio


UFC e FP

Una prima stima dei FP è detta UFC (Unadjusted Function Point Count):

UFC = Σ (number of elements of given type) x (weight)

Lo UFC è poi corretto da un fattore moltiplicativo TFC compreso tra 0.65 e 1.35

DFP = UFC * TFC (Delivered Function Point)

TFC- Fattore di Complessità Totale

Il TFC è calcolato sulla base di 14 Fattori di complessità (FC), valutati su una scala da 0 (ininfluente) a 5 (essenziale):

  1. Il sistema richiede backup e recovery affidabili?
  2. Sono richieste comunicazioni specializzate per trasferire dati da/verso l’applicazione?
  3. Vi sono funzionalità richiedenti elaborazioni distribuite?
  4. Le prestazioni sono un elemento critico?
  5. Il software funzionerà in un ambiente operativo esistente già pesantemente utilizzato?
  6. Il sistema richiede inserimenti online di dati?
  7. L’input online di dati richiede che la transazione relativa sia progettata su più schermate o più operazioni?
  8. Il file principali IFL sono aggiornati online?
  9. I dati di I/O, i file, le interrogazioni sono complesse?
  10. L’elaborazione interna è complessa?
  11. Il codice è progettato/scritto per essere riusabile?
  12. Il progetto comprende anche l’installazione e la conversione?
  13. Il software è stato progettato per essere installato presso diversi utenti?
  14. Il software è stato progettato per facilitare le modifiche e per un semplice uso da parte dell’utente finale?

TFC = 0.65 + 0.01 * Σi=1..14FCi

Schema di calcolo FP


Un esempio di calcolo FP


Vantaggi e svantaggi dei FP

  • Vantaggi:
    • Indipendenti dal linguaggio;
    • Ottime indicazioni per applicazioni di elaborazione dati, che usano linguaggi convenzionali o non procedurali;
    • Basati su quei dati che hanno la maggior probabilità di essere noti all’inizio di un progetto.
  • Svantaggi
    • Soggettività nell’assegnazione dei pesi;
    • Dati sul dominio delle informazioni possono essere difficili da reperire;
    • Nessuna valutazione della complessità dell’algoritmo (a parità di pochi input e output potrebbe essere banale ed estremamente complicato);
    • I FP non hanno un diretto significato fisico.

Utilizzi dei FP

  • Per stimare la dimensione finale del codice:
    • Studi hanno rilevato una correlazione tra FP e numero di LOC, variabile a seconda del linguaggio di programmazione.
    • Es. COBOL: 1 FP -> 100 LOC
      • PL1 : 1FP -> 80 LOC
      • OO lang : 1 FP ->60 LOC
  • Per stimare lo sforzo (in ore/uomo) di sviluppo:
    • Es. se 1 mese/uomo ->12 FP , allora …
  • Per valutare la completezza del testing
    • studi hanno misurato la correlazione fra FP e numero di difetti scoperti durante il testing.

Stime di Produttività

Per sistemi Real-time embedded, 40-160 LOC/P-month.
Programmazione di sistema, 150-400 LOC/P-month.
Applicazioni commerciali, 200-900 LOC/P-month.

La produttività è influenzata da vari fattori (es. Esperienza nel dominio,qualità del processo, dimensione del progetto, supporto tecnologico, ambiente di lavoro).

Problemi delle misure di produttività

Tutte le misure di produttività basate sul rapporto volume/unità di tempo sono difettose perchè considerano solo la quantità e non la qualità di ciò che si produce.
La produttività potrebbe essere ‘aumentata’ a discapito della qualità.

La metrica di produttività più semplice (LOC/pm), usando le LOC, non è un indicatore valido in assoluto ma dipende dai vari fattori indicati precedentemente.
Se si usano I FP, il conteggio di FP dipende da valutazioni soggettive sulla complessità del software.

Tecniche per la stima dello sforzo

Non c’è un modo semplice ed efficace per fare stime accurate nei primi stadi del progetto.

  • Le stime iniziali sono formulate in genere su requisiti definiti solo ad alto livello;
  • Il software può dover funzionare su computer ’sconosciuti’ o usando nuove tecnologie;
  • Il personale assegnato al progetto può essere sconosciuto.

Le tecnologie che cambiano continuamente comportano che le tradizionali tecniche di stima possono non funzionare più correttamente!

Tecniche di Stima tradizionali

  • Pricing to win
  • Expert judgement
  • Algorithmic cost modelling
  • Estimation by analogy
  • Parkinson’s Law

Tecniche per la stima dei costi

Price-to-win estimating
Il costo viene stimato in base a quanto il cliente è disposto a spendere. La stima dipende dal budget del cliente più che dalle funzionalità del software.
Giudizio di esperti
Vengono consultati esperti sulle tecniche di sviluppo e sul dominio. Il costo del progetto viene stimato da ognuno, vengono quindi comparate e discusse le stime finché non viene trovato un accordo.
Legge di Parkinson
“il lavoro si espande per occupare il tempo disponibile” … il costo viene determinato unicamente in base ai vincoli di tempo imposti e alle risorse disponibili.
Stima tramite analogia
Si cerca di stimare il costo trovando delle analogie tra il progetto da realizzare e progetti precedentemente realizzati.
Modellazione algoritmica
Viene sviluppato un modello sulla base di informazioni storiche e del legame empiricamente trovato tra alcune metriche di prodotto e di processo e il costo del software.

Pricing to win

Il progetto costerà quanto il committente ha intenzione di pagare.

  • Vantaggi:
    • Si ottiene il contratto.
  • Svantaggi:
    • La probabilità che il cliente ottenga ciò che richiede è piccola…I costi pagati non garantiscono tutto ciò che sarebbe richiesto.

É usato soprattutto quando non c’è un documento dei requisiti del sistema, ma il committente si fida dell’azienda che fa lo sviluppo, e sa che la cifra offerta rientra nel suo budget.

Approcci di stima Top-down e bottom-up

Le tecniche precedenti possono essere usate sia in modo top-down che bottom-up.

Top-down
Si parte dall’intero sistema e si analizza l’intera funzionalità e come questa sia via via ottenuta attraverso I vari sottosistemi.

Bottom-up
Si parte dal livello dei singoli componenti e si stima lo sforzo di ciascuno di essi. Gli sforzi dei componenti si sommano per ottenere quello globale.

Stima Top-down

Richiede solo la conoscenza delle funzionalità del sistema.

É usabile anche senza alcuna conoscenza dell’architettura del sistema e dei suoi componenti.

Considera anche i costi di integrazione, configuration management e di documentazione.

Può sottostimare i costi legati a problemi tecnici di basso livello di specifici componenti.

Stima Bottom-up

Usabile solo se l’architettura è nota ed I componenti ben identificati.

Può essere un metodo di stima accurato se il sistema è stato progettato in dettaglio.

Può sotto-stimare il costo di attività a livello sistema quali l’integrazione e la documentazione.

Uso dei metodi di stima

Ogni metodo ha I suoi vantaggi e svantaggi, per cui la stima dovrebbe basarsi su differenti metodi.

Se I vari metodi non forniscono risultati comparabili, si deve concludere che non ci sono dati sufficienti per fare una stima valida.

Occorrerà raccogliere ulteriori dati sul prodotto, sul processo o il team.

La tecnica del Pricing to win è talora la sola tecnica applicabile.
Ci si accorda su un costo di progetto in base ad una bozza di proposta e lo sviluppo sarà vincolato da tale costo.
La specifica di dettaglio sarà negoziata successivamente o si userà un approccio di sviluppo evolutivo.

Stima per analogia

  • Si basa sul riuso delle esperienze accumulate in precedenti progetti
    valuta le analogie tra il nuovo progetto e progetti simili svolti in passato.
  • Si applica quando:
    Non esiste, in azienda, una metodologia adottata per la stima dei costi;
    È richiesta una rapida, semplice e ragionevolmente accurata macro stima;
    Esistono informazioni di precedenti progetti ma non un data base storico dettagliato.
  • Requisiti per l’uso:
    Dimensione e scopi del nuovo prodotto simile a quelli del prodotto di riferimento;
    Metodo di lavoro del nuovo progetto simile a quello del progetto di riferimento;
    Disponibilità di informazioni molto dettagliate o di persone che ricordano il lavoro in maniera accurata.

Stima per analogia (segue)

La stima viene eseguita valutando la quantità di lavoro (in mesi/uomo M) e il tempo di sviluppo (in mesi) previsti

  • applicazione di coefficienti moltiplicativi al costo del progetto di riferimento;
  • Modifiers (m) che tengano conto degli scostamenti di determinate caratteristiche (C) da quelle del caso in esame.

Requisiti essenziali nella scelta del progetto di riferimento:

  • Conoscenza di quali caratteristiche sono simili e quali no;
  • Conoscenza della qualità dei dati sullo sforzo e i costi di manodopera disponibili per il progetto di riferimento.

M = Mrif • ∏I mi

Le caratteristiche da considerare sono quelle che fanno riferimento direttamente al software.

Esempio

Caratteristiche del sistema più complesse circa il 15%
Più menù e schermate circa il 10%
Struttura dei file nel data base meno complessa circa il 5%
Più interfacce di sistema circa il 20%
Uso di DBMS meno familiari circa il 20%
Più potenti tool di sviluppo circa il 10%
Team di sviluppo con maggiore esperienza circa il 20%
Testing di accettazione più rigoroso circa il 5%

M = Mrif • 1.15 • 1.10 • 0.95 • 1.20 • 1.20 • 0.90 • 0.80 • 1.05 = 1.31 • Mrif

In teoria nessun limite al numero di modifiers che possono essere usati.
In pratica conviene non usarne più di 15 in generale e più di 10 se ne esiste più di uno con una variazione percentuale maggiore del 30%, altrimenti si perde il concetto stesso di analogia tra sistemi.

Modellazione algoritmica dei costi

Il Costo è stimato come una funzione matematica che tiene conto di attributi del prodotto, del processo e del progetto, stimati da project managers:

Effort = A x SizeB x M

A è una costante dipendente dall’organizzazione;
B tiene conto della non linearità tra lo sforzo e la dimensione (B>1) indica che lo sforzo aumenta più che linearmente con le dimensioni;
M è un moltiplicatore dipendente dal prodotto da realizzare, dal processo scelto e dalla tipologia delle persone coinvolte.

L’attributo di prodotto più usato per la stima è la dimensione del codice (Size- espressa in LOC o FP).
I diversi modelli di stima algoritmica usano valori diversi per A, B ed M. La stima dei fattori che contribuiscono a B e M è soggettiva.

Accuratezza della stima

Per usare tali modelli occorre stimare le dimensioni del software usando una possibile tecnica fra:
Stima per analogia, traduzione dei FP in LOC,o usando giudizio di esperti.

É difficile stimare accuratamente la dimensione quando si è nelle fasi iniziali dello sviluppo. Molti fattori (definiti più avanti) influenzeranno la dimensione finale:

  • Uso di COTS e componenti;
  • Programming language;
  • Distribution of system.

La stima diventa più accurata col procedere del processo, man mano che le informazioni aumentano.

  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion

Fatal error: Call to undefined function federicaDebug() in /usr/local/apache/htdocs/html/footer.php on line 93