introduzione
Questa è la terza parte del blog incentrata su una serie di popolari metodi di misurazione delle dimensioni del software e sulla loro utilità per la stima del progetto software. In questa terza parte vengono trattati i metodi di misurazione delle taglie non funzionali. Nel prossimo e ultimo blog su questo argomento blog futuri tratterò i metodi ibridi.
Si consiglia vivamente ai lettori interessati a questo argomento di leggere prima il prima parte e seconda parte di questo blog prima di leggere questa terza parte della serie di blog.
Affinché un particolare metodo di misurazione delle dimensioni del software sia utile per la stima del progetto software, dovrebbero valere le seguenti caratteristiche:
- Il metodo di misurazione delle dimensioni può essere eseguito in un obiettivo (indipendente dalla persona che lo fa), ripetibile, verificabile e quindi difendibile modo;
- La dimensione in sé è utile solo quando dati storici è disponibile di progetti misurati in tale metodo di misurazione delle dimensioni;
- I metodi di misurazione delle dimensioni dovrebbero essere supportati da modelli e/o strumenti parametrici al fine di tener conto con precisione delle caratteristiche specifiche del progetto che influenzano la stima, come per esempio QSM SLIM, SEER per software, TruePlanning o COCOMO II.
Ovviamente, qualsiasi metodo di misurazione delle dimensioni del software che non soddisfa uno o più di questi criteri può comunque essere molto utile per un'organizzazione, a condizione che elaborino una procedura che garantisca la ripetibilità delle misurazioni dimensionali, raccogliere e analizzare dati storici e/o costruire propri modelli di stima sulla base dei dati raccolti. Per questo blog invece, l'attenzione si concentra sull'utilità teorica del metodo di misurazione specifico per scopi di stima del progetto software nel contesto di organizzazioni che non dispongono ancora di un processo di stima parametrica in atto. Per queste organizzazioni, che sono disposti a implementare un metodo di misurazione delle dimensioni per stimare i progetti software, questo blog può servire come linea guida per selezionare un metodo specifico.
Anche se tutto ciò che è scritto in questo blog si basa sull'esperienza personale e sulla documentazione pubblicamente disponibile (referenziato), Ci tengo a sottolinearlo questo blog riflette solo le mie opinioni e convinzioni personali e quindi non pretendo che tutto ciò che è scritto in questo blog sia una verità assoluta. Le mie convinzioni personali non sono necessariamente anche le convinzioni delle organizzazioni a cui sono affiliato: Metri, Nesma e ISBSG.
Incoraggio tutti a inviare commenti e/o feedback su questo blog.
Metodi di misurazione delle dimensioni non funzionali
Mentre i metodi di misurazione della dimensione funzionale misurano solo la dimensione dei requisiti utente funzionali (ciò che il software dovrebbe offrire all'utente), i metodi di misurazione delle dimensioni non funzionali misurano (spesso parte del) requisiti utente non funzionali, che possono essere requisiti utente tecnici e/o requisiti utente di qualità (come dovrebbe funzionare il software). Anche la misura del codice che viene consegnato è considerata una misura dimensionale non funzionale.
La misura di dimensione non funzionale più utilizzata è costituita dalle righe di codice di origine (slocs).
Linee di codice di origine (slocs)
Source Lines of Code fa appello a molte persone e organizzazioni perché una volta che il sistema software è pronto, può essere contato automaticamente dai contatori del codice sorgente. Di frequente, gli strumenti di sviluppo misurano già le righe di codice durante il progetto.
Molte organizzazioni utilizzano la misura slocs come input per i processi di stima dei progetti software. Questo è notevole, poiché il numero di sloc può essere misurato solo dopo il completamento. Ciò significa che utilizzare gli sloc nella stima del software, gli sloc devono essere stimati, non misurato. Solitamente un team di esperti stima insieme il numero di righe di codice sorgente per il nuovo progetto e/o utilizza metodi di analogia rispetto a progetti precedentemente completati per arrivare a una stima della dimensione del software da consegnare.
Anche se questa sembra una buona idea, questo metodo comporta grandi rischi per la stima dello sforzo. Non esiste uno standard ISO (o qualsiasi altro standard) disponibile per righe di codice sorgente. Diversi strumenti di conteggio del codice restituiscono a (a volte completamente) risultato diverso dopo aver contato lo stesso codice. A volte vengono misurate le linee fisiche, ma spesso vengono conteggiate anche le dichiarazioni della fonte. Poiché un'istruzione può essere facilmente scritta su più righe, già questo evidenzia un grosso problema.
Inoltre, il numero di righe di codice sorgente necessarie dipende da fattori come l'ambiente tecnico, complessità e capacità del programmatore. Anche le righe di codice sorgente non rappresentano realmente un valore per gli utenti. È meglio ottenere più righe di codice o meno righe di codice? Più linee possono significare più funzionalità, ma se si pagasse un fornitore in base a un prezzo per 1000 linee di codice sorgente una cosa è certa... il cliente otterrebbe molto codice! I contatori di codice non devono misurare il codice generato dagli strumenti di sviluppo, ma in realtà è impossibile per questi strumenti escludere dalla misurazione il codice generato.
Pertanto, di solito è molto difficile utilizzare gli sloc di un progetto software completato come input per il progetto software successivo. Ricorrere a esperti per stimare il numero totale di righe di codice sorgente per un nuovo progetto e quindi utilizzare dati storici basati su righe di codice sorgente è estremamente rischioso. Valutando in questo modo, esiste già un'ampia percentuale di incertezza nel principale parametro di input della stima.
Così, perché molte organizzazioni stimano i loro progetti in questo modo? Alcune pubblicazioni, per esempio ‘Origini dei difetti software e metodi di rimozione‘ di Capperi Jones, affermare che stimare i progetti in questo modo è una forma di negligenza professionale. Potrebbe funzionare a volte, ma il rischio è enorme e probabilmente non è possibile evitare il fallimento di progetti con enormi sforamenti. In realtà, questa è esattamente la cosa che spesso viene trascurata. Di solito ci sono molte cose che vanno male nei grandi progetti, e alla fine è quasi sempre possibile "incolpare" alcuni problemi operativi che compaiono sempre durante un progetto software... qualche problema tecnico, o un proprietario del prodotto che non è stato coinvolto abbastanza, o l'ambiente OTAP non è stato implementato abbastanza velocemente, oppure il cliente ha cambiato molto le proprie esigenze durante il progetto... e così via. Tuttavia, nella maggior parte dei casi di errori del software, quando si analizza la vera causa, dimostra che il progetto è iniziato con aspettative troppo ottimistiche... il team è troppo piccolo, la durata troppo breve, i costi troppo bassi. Stime degli esperti, e stime che non si basano su standard di settore e dati sull'esperienza di solito iniziano con aspettative ottimistiche. Organizzazioni che comprendono la relazione tra una stima realistica e il risultato del progetto, si concentrerà sull'implementazione di strumenti che consentano loro di stimare il progetto nel modo più accurato possibile, anche non premiare le stime eccessivamente ottimistiche fornite dai fornitori, ad esempio. tuttavia, le organizzazioni devono raggiungere un certo livello di maturità per capirlo e questo livello di maturità è ancora lontano per molte organizzazioni del settore... anche per quelle che si considerano abbastanza mature!
Teoricamente, le righe di codice sorgente non sono affatto utili per la stima del software. Alcune persone riferiscono di progetti di successo stimati in questo modo, ma da un punto di vista teorico questo potrebbe invece essere frutto del caso o della fortuna.
Le caratteristiche per valutare l'utilità di questo metodo per la stima del progetto software sono elencate nella tabella successiva:
| Caratteristica | Si No | Osservazioni |
| Obbiettivo, ripetibile, verificabile e difendibile | No | Gli sloc possono essere misurati solo dopo il completamento del progetto. Per la stima del progetto è possibile utilizzare solo "sblocchi indovinati".. |
| Dati storici disponibili | sì | ISBSG R13: 180 progetti. tuttavia, non è possibile verificare il tipo di SLOC misurato. |
| Supportato da modelli/strumenti | sì | QSM SLIM, SEER per software, TruePlanning, COCOMO II. ISBSG |
Punti SNAP
SNAP è l'acronimo di "Software Non-functional Assessment Process".,” un metodo di misurazione delle dimensioni del software non funzionale. Il dimensionamento dei punti SNAP è pensato per essere un complemento al dimensionamento dei punti funzione, che misura la dimensione funzionale del software. SNAP è un prodotto di Gruppo di utenti del punto di funzione internazionale (IFPUG), ed è dimensionato utilizzando il Manuale delle pratiche di valutazione non funzionale del software, ora in versione 2.2.
SNAP è vagamente connesso all'ISO 9126 e ISO 25010 standard per la qualità del software. Cerca di dimensionare i requisiti non funzionali implementati in un progetto software. Anche se questa sembra una buona idea, il metodo SNAP sembra mancare il suo obiettivo. Non offre uno strumento di misurazione integrale per tutti i requisiti non funzionali e inoltre un certo numero di requisiti non funzionali altamente rilevanti non viene misurato affatto. Una serie di ulteriori osservazioni:
- La maggior parte della documentazione utilizzata nel settore non indica esplicitamente le informazioni necessarie sui requisiti non funzionali che SNAP cerca di misurare. Inoltre, non è chiaro cosa fare quando mancano queste informazioni. Conta comunque qualcosa... o non contare nulla?
- Non tutti gli ISO 9126 o ISO 25010 vengono misurate categorie di requisiti non funzionali. Anche quando i punti SNAP possono essere misurati utilizzando il metodo pubblicato, i requisiti non funzionali che le persone ritengono essere fattori di costo importanti (per esempio. prestazioni o sicurezza, e così via), vengono ignorati;
- Non è chiaro come venga determinata la relazione tra le diverse categorie SNAP e perché ciò sia valido. Perché la complessità dell'interfaccia utente (Punti SNAP = Nr di proprietà aggiunte o configurate …2, 3 o 4 volte il numero di elementi univoci dell'interfaccia utente) essere di dimensioni non funzionali uguali...o maggiori...o inferiori rispetto alle dimensioni non funzionali misurate per i processi batch (4 volte, 6 volte o 10 volte il numero di attributi dei dati). Non sembra esserci alcuna connessione rilevante tra le categorie e il modo in cui vengono misurati i punti SNAP sembra arbitrario;
- Il professor Doctor Abran ha sottolineato che il prova statistica del metodo SNAP non supera i consueti test di validità metodica, poiché sembra che i valori anomali nel set di dati utilizzato per dimostrare la correlazione tra i punti SNAP e lo sforzo non siano stati rimossi;
- Alcuni dei requisiti non funzionali che vengono misurati sono in realtà funzionali e sono misurati anche nei metodi NESMA e/o IFPUG. Questo è strano per un metodo che pretende solo di misurare i requisiti non funzionali.
Nel complesso, sebbene l'IFPUG e molti professionisti stiano sostenendo il metodo SNAP come un metodo valido e valido da utilizzare nella stima, da un punto di vista pratico e da un punto di vista teorico ci sono ancora molte questioni da affrontare prima che questo metodo possa diventare utile quando si tratta di stimare il progetto. Al momento sono disponibili dati storici del progetto misurati in SNAP molto limitati. Nel 2013, l'International Software Benchmarking Standards Group ha pubblicato a Modulo raccolta dati SNAP, ma fino ad ora non sono pervenute candidature di progetti con punti SNAP.
Per adesso, al massimo può essere utilizzato per cercare di comprendere le differenze di prestazioni o produttività tra i progetti completati, ma non è ancora adatto per la stima del progetto.
Le caratteristiche per valutare l'utilità di questo metodo per la stima del progetto software sono elencate nella tabella successiva:
| Caratteristica | Si No | Osservazioni |
| Obbiettivo, ripetibile, verificabile e difendibile | No | Il manuale SNAP dovrebbe garantire misurazioni obiettive, ma poiché non è sicuro di cosa fare quando mancano le informazioni necessarie, è probabile che i misuratori facciano ipotesi diverse con conseguenti dimensioni diverse. |
| Dati storici disponibili | No | ISBSG cattura i progetti nei punti SNAP, ma non è stato ancora inviato alcun dato. Forse ci sono dati disponibili nel gruppo IFPUG SNAP. |
| Supportato da modelli/strumenti | No |
Prossimo blog
Nel prossimo blog su questo argomento, Darò la mia opinione sull'utilità dei principali metodi di misurazione della dimensione ibrida per la stima del progetto software.
Circa l'autore
Harold van Heeringen è consulente senior di benchmarking presso Metri. A parte il suo lavoro per Metri, è 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).