La stima dei costi e la tempistica di un progetto sono in genere eseguite insieme.
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.
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.
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).
Problema: Che cosa è una linea di codice (LOC)?
Più il linguaggio è di basso livello, più il programmatore può risultare produttivo.
Es. Assembler rispetto a C
Più il programmatore è verboso, più risulta produttivo.
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:
I FP sono una misura di funzionalità basata su entità logico-funzionali che l’utente facilmente comprende (es. Input, output,etc.)
Un FP non è una singola caratteristica ma una combinazione di caratteristiche del sistema;
I FP vengono derivati usando una relazione empirica che si basa su:
Le Misure del Dominio delle Informazioni sono catturate con riferimento al Confine (Boundary) del sistema software.
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:
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.
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.
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.
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).
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.
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:
Ad ognuno dei livelli è associato un peso che varia da 3 (più semplice) a 15 (più complesso).
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)
Il TFC è calcolato sulla base di 14 Fattori di complessità (FC), valutati su una scala da 0 (ininfluente) a 5 (essenziale):
TFC = 0.65 + 0.01 * Σi=1..14FCi
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).
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.
Non c’è un modo semplice ed efficace per fare stime accurate nei primi stadi del progetto.
Le tecnologie che cambiano continuamente comportano che le tradizionali tecniche di stima possono non funzionare più correttamente!
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.
Il progetto costerà quanto il committente ha intenzione di pagare.
É 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.
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.
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.
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.
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.
La stima viene eseguita valutando la quantità di lavoro (in mesi/uomo M) e il tempo di sviluppo (in mesi) previsti
Requisiti essenziali nella scelta del progetto di riferimento:
M = Mrif • ∏I mi
Le caratteristiche da considerare sono quelle che fanno riferimento direttamente al software.
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.
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.
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:
La stima diventa più accurata col procedere del processo, man mano che le informazioni aumentano.
2. Ciclo di Vita e Processi Software
3. Processi per lo sviluppo rapido del software
4. Sviluppo Agile del Software
5. Test Driven Development (TDD)
7. Component Based Software Engineering (CBSE): Generalità
8. Component Based Software Engineering (CBSE): Il processo di svi...
9. Ingegneria del Software orientato ai Servizi
10. Ingegnerizzazione dei Servizi
11. I Processi di Manutenzione del Software
12. Reengineering, Refactoring e Reverse Engineering del Software
13. Verifica e Convalida del Software. Richiami e concetti di base ...
14. Tecniche di Testing Dinamico
15. Testing di Sistemi Object Oriented
16. Automazione del testing e Analisi Mutazionale
17. Tecniche di Analisi Statica del codice e il Debugging
18. Stima dei costi nei progetti Software
19. Il Modello COCOMO per la stima dei costi Software – La gestio...
20. Gestione e Miglioramento dei Processi di Produzione del Softwar...
21. La Valutazione della Qualità dei Processi Software – Il Capa...