Premessa
2
La seconda parte effettua l’analisi del formato e dell’architettura di un sito Web, ossia
l’applicazione della Function Point Analysis in ambienti tecnologici relativamente
grandi.
Introduzione
3
INTRODUZIONE
Chiunque operi nell'ambito del software engineering e che quindi tenti di rendere il
processo di sviluppo e di gestione del software in qualche modo standardizzato, si
trova presto o tardi a dover misurare caratteristiche di prodotto e di processo.
Supponiamo che un'azienda che produce software voglia valutare l'andamento della
qualità (intesa come difettosità) dei propri prodotti software nel passaggio da una
release alla successiva per poter valutare i propri costi di manutenzione. In questo caso
per avere un'indicazione di tale andamento è necessario normalizzare il numero di
difetti riscontrati in una particolare release ed in quella successiva, rispetto alle
dimensioni delle due release, ed esprimere quindi la difettosità in termini di numero di
difetti per unità dimensionale.
Analogamente se la stessa azienda volesse misurare l'andamento della produttività del
gruppo di sviluppo che ha implementato le due successive release potrebbe farlo
misurando il lavoro prodotto (dimensioni) per unità di costo (es. Il mese uomo). In
questo modo è possibile verificare se la produttività (es. linee di codice prodotte per
mese uomo) è stata superiore nella prima o nella successiva release, e ad esempio
tentare di correlare questo fenomeno con la difettosità delle due relative release.
Se le metriche utilizzate per questo tipo di misurazione sono diffuse e/o
standardizzate, le aziende possono misurarsi in termini di qualità dei prodotti forniti o
di produttività anche con altre aziende e sono quindi in grado di valutare la propria
competitività rispetto al mercato.
Anche per chi acquisisce applicazioni software la definizione di misure che possano
contribuire a scegliere i possibili fornitori anche sulla base di valutazioni di qualità e
produttività è altamente auspicabile.
Introduzione
4
Per quanto riguarda la misurazione delle dimensioni del software, questo ruolo è stato
svolto storicamente da misure legate al codice sorgente ed in particolare dalle linee di
codice: queste presentano il vantaggio di essere visibili e quindi facilmente verificabili e
misurabili.
I primi linguaggi macchina richiedevano una tale quantità di tempo per essere usati,
rispetto alle funzioni svolte, che sembrò appropriato misurarne lo sviluppo sulla base
delle linee di codice realizzate. Anche nei linguaggi di terza generazione (Cobol, Fortran
...) lo sforzo inerente la codifica, specialmente in assenza di generatori automatici o
efficienti strumenti Case, rimane significativo.
La riduzione del tempo dedicato alla codifica e la potenzialità dei più recenti linguaggi
(C++, Visual Basic) nella compressione della scrittura di codice fanno prestare
maggiore attenzione a quantificazioni non centrate sulla codifica e sull’ambiente
tecnologico, ma sulle documentazioni legate alle funzioni. La trasformazione
tecnologica che dopo anni di stabilità sta colpendo i linguaggi ha così ravvivato
l’interesse verso un metodo di quantificazione nato verso la metà degli anni settanta,
ideato da Allan Albrecht dell’Ibm.
Per aziende che sviluppano software l'esigenza di "misurare" il software, ed in
particolare il misurarne le dimensioni, è legata (oltre a quanto illustrato in precedenza)
anche alla previsione delle risorse (costi) e dei tempi da investire nel momento in cui si
decide di sviluppare una determinata applicazione.
Le dimensioni sono infatti uno (dei molti) fattori che hanno influenza sui costi di
sviluppo del software. La necessità di poter disporre di una misura (in questo caso
stima) delle dimensioni del software preventivamente è quindi determinante al fine di
prevedere i costi di sviluppo.
È evidente che una misura dimensionale, quale quella delle linee di codice, non si
presta in modo adeguato a questo tipo di utilizzo in quanto, nelle fasi preliminari del
ciclo di vita può, essere solamente stimata e non misurata.
Introduzione
5
Si evidenzia così la necessità di metriche dimensionali che rispetto a quelle tradizionali
siano applicabili durante le prime fasi del ciclo di vita, che siano indipendenti dalla
tecnologia adottata e rispecchino più che la quantità di codice, la quantità di
funzionalità che risulta percepibile anche dall'utilizzatore finale del prodotto software.
La prima metrica a dare risposte efficaci a questo tipo di aspettativa è stata quella dei
Function Points di Albrecht.
La misurazione delle funzioni svolte consente di quantificare anche le attività di analisi,
notevolmente astratte e con consistente lavoro mentale. Inoltre una più tempestiva
attività di quantificazione nelle prime fasi del ciclo di vita consente una migliore stima
in un campo dove gli errori di previsione sono più facili che altrove.
La Precocità della quantificazione basata sui Function Point (FP) consente di definire
tale metrica come preventiva, cioè in grado di precedere lo sviluppo del software,
incidendo sulle caratteristiche del prodotto. Spesso infatti l’evidenziazione della misura
consente una maggiore precisazione dei requisiti da parte del cliente, prima che si passi
agli sviluppi effettivi. In tal senso c’è una certa connessione tra le problematiche dei FP
e quelle dell’usabilità del software: entrambe devono essere definite in modo
preventivo.
Non è necessario che l’utente-cliente conosca le tecniche di conteggio dei Function
Point, ma è importante che ne capisca il funzionamento, il processo di applicazione. Il
conteggio dei FP si offre come un momento di dialogo e confronto tra il fornitore e il
cliente e la metodologia che li utilizza si propone di quantificare il software da un punto
di vista che privilegia la percezione di quest’ultimo. Aiuta in questo il fatto che il cliente
abbia un’idea degli ordini di grandezza delle dimensioni e dei costi unitari, conducendo
ciò a spostare l’analisi (vedi figura) dal costo al problema della dimensione funzionale e
complessità, considerando a parte la realizzazione tecnica e il linguaggio utilizzato.
Introduzione
6
Dimensione funzionale
Costo Produttività e qualità
Al pari di altri beni e servizi, un software viene richiesto o meno a seconda che abbia
un prezzo oggettivamente legato a funzioni riconoscibili, conseguendo al prezzo
estensioni o riduzioni dell’automazione, o variazioni del prezzo stesso.
E’ essenziale, per un corretto conteggio, che il cliente abbia ben chiari, da un punto di
vista logico, i seguenti elementi: gli input, gli output, le interrogazioni, i file e il relativo
costo risultante. Le implicazioni metodologiche sono di competenza del fornitore.
Parafrasando Allan Albrecht: la tecnica non deve essere un ostacolo alla comunicazione
con il cliente, al quale comunque devono essere chiari i sostanziali significati dei dati in
ingresso, uscita, le interrogazioni e gli archivi, a prescindere dal loro formalismo di
rappresentazione.
La metrica dei Function Point è anche una metrica consuntiva. La tecnica di
conteggio, per sua natura, conduce a prestare la massima attenzione ai prodotti
documentali del ciclo di vita del software che precedono la codifica dei programmi e
sottolineano l’importanza del loro aggiornamento, sia nella fase di sviluppo laddove
dovessero verificarsi continue turbolenze dei requisiti, sia nella fase di manutenzione.
L’astrattezza del software rende difficile pervenire alle esatte dimensioni del prodotto.
Si sono formate molte associazioni per la divulgazione e l’esatta applicazione della
tecnica di conteggio dei FP che inizia, in questi anni, ad avere un valore patrimoniale
nel software gestionale, scientifico e real-time. La principale è l’IFPUG (International
Function Point User Group), nata nel 1986 negli USA, che raccoglie oltre 500 iscritti di
32 paesi. Ad esempio in Italia il GUFPI (Gruppo Utenti Function Point Italia)
Introduzione
7
associato all’IFPUG, coinvolge a sua volta circa 50 imprese e associazioni. Nel 1994 in
ambito ISO è anche nata un’attività di definizione dei requisiti dei metodi di misura :
con l’esame delle varie tipologie di software a cui il metodo è applicabile, si perviene a
criteri di orientamento per la valutazione dei metodi di conteggio. Una metrica
patrimoniale è tanto valida quanto più è standard e confrontabile: il vero fine è spostare
l’interesse, anche nel campo industriale del software, dalla dimensione del prodotto
(che deve essere più oggettiva possibile) alla produttività di sviluppo-manutenzione e
quindi al suo costo.
In sintesi i Function Point sono connessi a importanti fattori di qualità: la quantità, la
funzionalità, la prevedibilità, la trasparenza. La quantità è considerabile come un
aspetto stesso della qualità: solo sistemi ad alto livello qualitativo sono in grado di
quantificarsi. La funzionalità assicura completezza e coerenza tra i requisiti richiesti e
automatizzati. La prevedibilità consente migliori stime di effort e di schedulazione
temporale. La trasparenza garantisce il cliente nelle corrispondenze tra funzioni svolte e
costi.
Il Business del Software
8
CAP 1 IL BUSINESS DEL SOFTWARE
In questo capitolo sono discussi alcuni aspetti legati alle regole e alle tecniche per una
gestione efficiente del software, e si forniscono le conoscenze di base per lo studio
della metodologia dei Function Point.
I Function Point sono uno dei meccanismi di controllo elencati in questo capitolo.
1.1 Modello del Software Business
Il progetto, il disegno, la realizzazione, la consegna e il mantenimento di un prodotto
software, sono diventati una realtà critica ed importante del business mondiale. I
principali scopi economici di un azienda che produce software sono: lo sviluppo e la
vendita di un prodotto software.
Il costo di produzione del software è aumentato drasticamente negli ultimi anni,
mentre lo sviluppo del software è diventato una parte importante nella funzione
business di un'organizzazione. Sfortunatamente le tecniche usate per “gestire” il
software non hanno raggiunto i livelli ottenuti in altre unità operative come: finanza e
risorse umane.
Solo negli ultimi anni si sta capendo l'importanza della gestione dei rischi del software e
dei costi della tecnologia investita.
L'abilità di un'organizzazione nel gestire efficacemente ed efficientemente i dati a
disposizione fornisce un vantaggio nella competizione sul mercato, ed aggiunge valore
all’azienda.
Il problema delle aziende è la mancanza standard per stabilire le proprie aspettative
sulla performance del prodotto, sul “Time to Market” e la qualità del prodotto.
Il Business del Software
9
Molte organizzazioni, il cui scopo principale non è la produzione del software, non
hanno una perfetta conoscenza su come poter gestire effettivamente questo ambiente.
A tale scopo è nata l’organizzazione internazionale per lo sviluppo e la gestione dei dati
: IS (Information System). L'organizzazione non è spesso vista come l’unica funzione
business in un'organizzazione, viene considerata una parte di qualcos'altro.
Esistono principi basilari per avere successo nella gestione del software, che possono e
devono essere applicati: gestione interna o in outsourcing. Le aziende decidono di
affidare in outsourcing, cioè dare la gestione del proprio ambiente software a
organizzazioni esterne, perchè sono a conoscenza del fatto che è loro compito fornire
una prospettiva di costo e di gestione per lo sviluppo del proprio ambiente software.
L'industria del software è in costante cambiamento; i progressi in hardware, software e
tecnologie multimediali, inducono le applicazioni ad essere costantemente ripensate,
ridisegnate e riprogettate. I nuovi metodi e tecniche di sviluppo sono in continua
evoluzione; questo perché il business del software è estremamente difficile da gestire.
Le chiavi principali del Software Business sono:
❶ controllo dei costi
❷ miglioramento del Time to Market
❸ visibilità ed integrazione strategica
❹ software di qualità.
Il Business del Software
10
Vediamo in dettaglio :
❶ Controllo dei costi: si guarda l'entità software come un business per raggiungere
profitti, diventando parte del successo e del fascino del outsourcing. La relazione
tra il fornitore di outsourcing e il cliente è costituita da un contratto, attraverso il
quale il fornitore offre un prodotto definendo il prezzo e la performance finale.
❷ Time to Market: intervallo di tempo tra l’inizio della progettazione e l’entrata sul
mercato del prodotto software. Per molto tempo il software è stato sviluppato
velocemente aumentando i costi a lungo termine. Questo approccio è visto
negativamente ed è spesso etichettato come "veloce e pericoloso". Un’industria di
strumenti di supporto automatico chiamato Computed Aided Software
Engineering (CASE) è nata dalla esigenza del mercato di consegne veloci. Il
bisogno di incrementare la performance è una problematica reale e globalmente
competitiva. Il Business ha bisogno di trovare un vantaggio competitivo con
opportuni dati. La sola reale caratteristica di un’organizzazione sono i dati a
disposizione. Il mantenimento dei dati in modo efficiente è essenziale per la
sopravvivenza dell’azienda.
❸ Visibilità ed integrazione strategica: un esempio è il ritorno degli investimenti
tecnologici. Il mercato del software conosce pienamente l'importanza di una
dimostrazione per i propri clienti. Il “IS business” è diventato sempre più visibile al
suo cliente interno. Molti dirigenti hanno richiesto di dimostrare o qualificare il
valore di una unità di denaro spesa. L’incremento del budget associato ad un lungo
tempo di vendita non è una combinazione accettabile. I managers devono
massimizzare il ritorno su ogni unità di denaro spesa in IS.
Il Business del Software
11
1.2 Rischi nella gestione software
La gestione commerciale odierna non è solo intesa come perfomance ma anche come
gestione dei rischi, questi ultimi per essere valutati correttamente devono essere
analizzati nel seguente modo:
1. Individuare i rischi possibili nella gestione del software.
2. Scegliere uno strumento per identificare i rischi.
3. Sviluppare una gestione efficiente per ridurre i rischi.
La chiave del successo nella gestione dei rischi avviene attraverso una combinazione di
strumenti, tecniche e metodi, che possano migliorare il processo.
Esistono un numero di fattori esterni che giocano un ruolo significativo nell'evoluzione
dei rischi come : conflitti di utenti, riferimenti inadeguatamente definiti, o cambiamenti
di committenti commerciali. Tutti elementi che devono risultare totalmente sotto
controllo .
L'organizzazione, per gestire efficacemente i rischi, deve avere una completa visione di
questi. In tal senso molte organizzazioni si rivolgono ad esperti esterni per trovare le
risposte adeguate. Gli esperti esterni hanno il vantaggio di comprendere
oggettivamente la gestione dei rischi ed hanno più esperienza, qrazie alla quale possono
guidare l'organizzazione al successo.
1.2.1 Rischi comuni del software
Il primo passo nella gestione dei rischi del software è identificare i potenziali rischi
attraverso l'analisi del processo software. L'analisi può essere eseguita attraverso un
esame o con un’intervista. Questa consiste in una serie di domande che rivelano la
probabilità di incorrere in certi tipi di rischi. Un semplice esame di analisi dei rischi
può contenere informazioni sui potenziali rischi nelle seguenti cinque categorie:
Il Business del Software
12
1. Risorse effettive
2. Utilizzo del processo
3. Tecnologie applicate
4. Definizioni derivabili
5. Fattori esterni
Usando questo semplice insieme di criteri, le interviste e gli esami conducono ad una
buona gestione del software, includendo la gestione ad alto e medio livello.
L’organizzazione può individuare le principali aree dei rischi potenziali del software
con un piccolo tempo di elaborazione. Usando i dati a disposizione, può essere
stabilito un profilo dei rischi. Questo mostrerà una collezione di rischi ed identificherà
i fattori dei rischi esterni alla compagnia. Una volta identificati, è possibile correggere e
minimizzare i fattori di rischio. Le opportune migliorie possono avere delle priorità in
base alla strategia commerciale dell’organizzazione.
Una semplice strategia commerciale è illustrata nel seguente esempio :
migliorare il tempo di consegna al mercato
diminuire i costi di sviluppo del software
diminuire i costi di manutenzione e produzione
ridurre il gruppo di tecnici
minimizzare applicazioni arretrate
ottimizzare i costi stimati e il programma di lavoro
migliorare i livelli di abilità
Il Business del Software
13
aumentare la soddisfazione del cliente
aumentare l'uso del software commerciale
uso efficiente di esperti e contraenti
ottimizzare lo sviluppo del software verso l'utente finale
ottimizzare l'uso di nuove tecnologie
tutte applicazione outsourced
Ogni fattore è valutato su una scala da uno a cinque in ordine di priorità.
Dopo aver condotto gli esami si hanno due tipi di informazioni:
1. fattori dei potenziali rischi
2. strategie critiche commerciali.
Da queste informazioni un’organizzazione può dare priorità ai rischi. Per esempio,
l'analisi può rivelare che c’è il rischio di arrivare in ritardo sul mercato, oppure di avere
richieste inadeguate e di rispondere in modo non adeguato alle richieste.
L'obbiettivo strategico dell'esame può aver rivelato le strategie necessarie per migliorare
il tempo di consegna, la riduzione dei costi e stabilizzare la produzione del software.
Il Business del Software
14
1.3 Ritorno degli investimenti
Una componente importante del modello business è la misura dell'unità di denaro
investito per lo sviluppo della compagnia, ma esistono altri fattori da considerare: il
ritorno dei costi e la valutazione del software come un bene.
Oggi risulta impossibile quantificare il ritorno degli investimenti per le tecnologie
software. Studi ed analisi sono stati effettuati per mostrare i miglioramenti della
produttività.
Quantificare a breve termine, o limitare l'attenzione solamente su determinati strumenti
o processi di un’organizzazione, implica la possibilità di inconsistenza nella
performance. Molte altre variabili entrano in gioco, ma non sono identificate o
controllate su un ampio range di progetti.
1.3.1 Ritorno dei costi
Molte operazioni Business sono state sviluppate con successo dalla metà degli anni '70
e molte organizzazioni utilizzano il ritorno dei costi come controllo della gestione
Business. In seguito è descritto un semplice modello di ritorno dei costi :
• La compagnia XYZ spende 12 miliardi all'anno in hadware, software e servizi
tecnici.
• Esistono 4 principali unità commerciali che utilizzano questi sistemi e servizi
tecnici.
• I costi assegnati sono calcolati in base all'hardware usato.
• Il pagamento per le risorse software avviene in base al tempo di utilizzo.
• Il risultato, se computato con successo, è un'assegnazione dei costi per l' IS
attraverso le principali unità commerciali.
Il Business del Software
15
Tipicamente i costi di IS diventano una linea guida per ogni unità commerciale
partecipante. Questo crea due forze dinamiche che sono inappropriate per la meta che
si vuole raggiungere.
1. L'unità commerciale può gestire questi costi.
2. L'unità commerciale preclude l'ambiente IS come centro dei profitti non
permettendo la nozione di IS come unica funzione commerciale.
1.3.2 Software come risorsa
Usando l'esempio precedente della compagnia XYZ, si modifica l’assegazione dei costi:
invece di far pagare l'utilizzo delle risorse totali, si faranno pagare tali risorse per il loro
valore commerciale; mentre il software ed i servizi di supporto si faranno pagare in
base alle funzionalità consegnate all'utente.
Si assume di essere capaci di calcolare con successo il numero di "unità" software
prodotte e consegnate all'utente. Il calcolo rivela che nel passato si era in grado di
consegnare 10000 unità (funzionalità di software) al cliente. Questo consegna
coinvolgeva uno staff di 100 di persone e sopportava personale per un costo di 10
miliardi annui. Perciò ogni unità commerciale aveva costo di un milione.
Oggi si stipula con il cliente la vendita di unità software per un costo di un milione
ognuna. Questa formula permette di recuperare i costi e dunque si ha una gestione
positiva che genera profitto.
Il cliente non è in una posizione di gestire le sue spese; però può determinare il ROI
per questo software.
L'organizzazione IS può misurare la perfomance, determinare i profitti e il ritorno degli
investimenti, ovviamente la misura diventa “l'unità" software.
Tutto questo è ciò a cui provvede la metodologia Function Point; dove può essere
usata per misurare il valore delle funzionalità consegnate al cliente.
Ricevi informazioni sui nostri servizi, sulle offerte e non perdere news e consigli su università e lavoro.
