Newsgroup: it.lavoro.informatica
Titolo: Qualità del software in relazione al linguaggio

   Si è parlato più volte dell'argomento.  Alla University of California 
at Davis hanno condotto un'analisi statistica estesa su GitHub.  Le loro 
analisi, metodologie e risultati sono riportati su:
http://macbeth.cs.ucdavis.edu/lang_study.pdf
 
 
   In breve: caratteristiche del linguaggio come la tipizzazione forte o 
debole dei dati (strong/weak typing) e la differenza tra i linguaggi 
funzionali e quelli procedurali portano ad una differenza misurabile di 
qualità del codice prodotto (a vantaggio dei linguaggi funzionali e a 
tipizzazione forte).  Questo vantaggio è però modesto e grandemente 
superato dall'impatto di altri fattori sia tangibili, come la dimensione 
del progetto, della squadra di sviluppatori e delle "commit", sia 
intangibili (umani), come la predilezione personale per un certo stile 
di programmazione/linguaggio.
 
 
   Ciao,
 
 
-- 
Alessandro Selli 
http://alessandro.route-add.net
 
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.

 la predilezione personale per un certo stile di programmazione/linguaggio.
 
beh, non l'avrei mai detto
 
-- 
So I throw the windows wide
And call to you across the sky

 at Davis hanno condotto un'analisi statistica estesa su GitHub. [..]
 
Interessante, sfruttano l'ampio nunero di progetti opnsource in GitHub per condurre un'analisi quantitativa statistica su parametri qualitativi. Nello specifico, usano regressione multipla su un classificatore n-dimensionale basato su proprieta' specifiche dei vari linguaggi. Danno per scontato che "qualita' del codice" sia linearmente dipendente da proprieta' specifiche del linguaggio, prescindendo dall'algoritmo utilizzato nel codice. Studi alternativi utilizzano Rosetta Code per tentare di ovviare all'inconveniente (see 
http://arxiv.org/pdf/1409.0252v2.pdf
). Sicuramente produce risultati interessanti per chi si occupa di marketing, per convincere investitori, o per supportare importantissime guerre di religione tra emeriti entusiasti :-) 
 


 
Il che significa che un linguaggio puo offrire la possibilità di 
progettare al meglio usando alcune tecniche messe a disposizione dal 
linguaggio stesso, ma un cane rimane un cane indipendentemente dal 
linguaggio stesso
 


  Il buon senso esprime approvazione con un cenno della testa.


 tipizzazione forte).
 
Non l'ho ancora letto ma mi piacerebbe capire come misurano
la "qualita' del codice", visto che personalmente non avevo
mai visto alcun tipo di misura quantitativa della "qualita'"
del codice.
 
Ciao,
Marco.
 

 del codice.
 
 
E' un campo di stufi che parte dagli anni 70.
http://scholar.google.it/scholar?hl=en&as_sdt=0,5&q=software+quality+analysis
 
 
Ciao
  Francesco


Puoi leggerti,se sei interessato,questa tesi:
 
http://wpage.unina.it/ptramont/Download/Tesi/LAURENZAGABRIELLA.pdf
 
 
Universita' di Napoli
 


Ho dato un'occhiata ad alcuni. La maggior parte riportano
i fattori di qualita' come li conoscevo
io (cioe' molto molto lontani dall'essere "quantitativamente
misurabili", che e' poi la critica che ho sempre fatto
a chi si occupava di ingegneria del software anche in ambito
accademico
[Mi e' sempre sembrato un controsenso chiamare "ingegneria" una 
disciplina che si occupa di qualcosa che non e' "quantitativamente
misurabile"]). Con un po' piu' di calma provero'
a dare un'occhiata anche ai modelli che non conosco, magari partendo
dalla tesi segnalata nell'altro post, per vedere se effettivamente
si sono inventati qualcosa di misurabile in modo oggettivo.
 
Ciao,
Marco


Ne ho lette circa 20 pagine.
Sembra ottima per alcuni aspetti (molto
migliore dei generici modelli di Boehm o McCall), meno per altri.
 
Cioe' mi sembra ottima se il codice e' scritto utilizzando il
paradigma Object Oriented, un po' meno in altri casi.
 
E inoltre c'e' una cosa che non ho ben capito: secondo
il modello riportato nella tesi, se avessi un programma
che deve calcolare il doppio del numero che io gli do'
come ingresso, se io scrivo semplicemente una funzione main
che chiama il metodo di una classe che semplicemente restituisce
sempre 14 anche se io in ingresso gli ho passato 2, probabilmente
tutte le metriche sarebbero perfette (complessita'
ciclomatica bassa, rapporto astrazione/instabilita' buono, ecc),
pero' quello mi risponde sempre 14, anche se io gli ho passato
2 o 3 come parametro di cui calcolare il doppio.
 
Quindi sembrerebbe che la misura quantitativa della qualita'
risulterebbe buona anche se il programma non
facesse quello che dovrebbe fare.
 
Comunque ora devo interrompere ma quando ho un po' di tempo continuo la 
lettura.
 
Ciao,
Marco.

 Marco.
 

 Neanche un essere umano potrebbe farlo se non per specifiche ovvie o banali
 
Se e' cosi', allora e' *altrettanto ovvio* che qualsiasi metodo di 
misura della qualita' non serve assolutamente a niente.
 
Ciao,
Marco.

 facesse quello che dovrebbe fare.
 
dipende da come analizzi le metriche, e da quali metriche usi. Questo elaborato ha uno "scope" molto diverso dall'articolo postato dall'OP, che si proponeva di comparare linguaggi. Qui non c'e' una comparazione di linguaggi ma una comparazione di tools per analizzare progetti, principalmente per aiutare il programmatore a limitare il refactoring. Il discorso e' deviato di parecchio :-)
 

 Il discorso e' deviato di parecchio :-)
 
 
Puo' essere, ma la domanda che mi facevo io resta esattamente
uguale: come fanno a misurare in maniera "quantitativa"
la qualita' del software ?
 
 
 
Ciao,
Marco.
 
 


No, perchè un conto e' la qualità del codice, un altra cosa le specifiche
Se occorre misurare la qualità si dà per scontato che il codice segua le 
specifiche altrimenti può essere anche il codice più bello del mondo ma 
a che serve ?
 


chiedo scusa, la "qualita' del codice", visto che di
questo si parlava.
 
Ciao,
Marco.

 la qualita' del software ?
 
ovvio che non potranno mai ottenere una stima assoluta di qualita', ammesso che ne possa esistere una, sola e incondizionata. Semplicemente forniscono un indicatore statistico che ne descrive alcune proprieta' identificate come "metriche di qualita'". That's it. 
 
Quanto possa essere utile non lo so, non lo chiedere a me :-)
 
 


Per sbaglio avevo risposto all'email privata di enoquick, invece che nel 
ng: riposto qui, leggermente modificato:
 
  Scusa, ma il post a cui avevo risposto riportata testualmente la 
seguente frase:
 
  "In breve: caratteristiche del linguaggio come la tipizzazione forte o 
debole dei dati (strong/weak typing) e la differenza tra i linguaggi 
funzionali e quelli procedurali portano ad una differenza misurabile di 
qualità del codice prodotto [...]"
 
  NB: nel post si dice "differenza misurabile di qualita' del codice 
prodotto".
 
  Preciso quindi meglio la mia domanda iniziale, suddividendola
  in due altre domande:
 
  1)qual e' "l'unita' di misura" della grandezza "qualita' del codice 
prodotto" ?
 
  2) Data l'unita' di misura, come si effettua la misura delle grandezza
  in questione ?
 
  Mi piacerebbe capire se esiste per la qualita' del codice
  una risposta dello stesso tipo  che di darebbe per le domande :
 
  "qual e' l'unita' di misura della lunghezza ?"
 
  "E come si effettua la misura di una lunghezza?"
 
  (alle due precedenti domande io rozzamente risponderei cosi':
  l'unita' di misura della lunghezza e' il metro e la misura
  si effettua andando a vedere quante volte un campione di lunghezza
  unitaria entra nella lunghezza da misurare).
 
  Mi piacerebbe capire se per la grandezza "qualita' del codice" si 
possono dare risposte di questo tipo, cosi' come si possono dare per la 
"lunghezza". Se non si possono dare allora semplicemente, riterro' "non 
misurabile" (almeno non "quantitativamente") la grandezza "qualita' del 
codice".
 
Fino ad oggi, personalmente, ho sempre ritenuto effettivamente
"non misurabile quantitativamente" la qualita' del software.
 
Pero' nel post dell'OP pareva che si affermasse il contrario.
 
Effettivamente pero', rileggendo, forse la grandezza da misurare
non e' la qualita' del codice, ma la "differenza tra la qualita' di due
codici diversi" (che comunque e' gia' molto meno che non la
misura della qualita' di un codice).
 
  Le domande pero' non cambiano di molto, si potrebbero
  riformulare come segue
 
  1)qual e' "l'unita' di misura" della grandezza "differenza di qualita' 
di due codici prodotti" ?
 
  2) Data l'unita' di misura, come si effettua la misura delle grandezza
  in questione ?
 
(effettivamente nell'elaborato linkato [che sia una tesi o altro non 
importa] si da un'indicazione di un metodo per effettuare una misura 
quantitativa della qualita'.Ora,  se il metodo vale solo per  il 
paradigma OO allora bisogna specificarlo chiaramente e inoltre
se non tiene conto della correttezza mi pare che sia utile a molto molto
poco, visto che tutte le metriche di qualita' non prescindono mai
dalla correttezza, nemmeno quelle classiche che pure quantitative non
sono [a nessuno verrebbe mai in mente di dire che un codice che
sta alla base di un programma che "non fa quello che deve" sia un
codice "di elevata qualita'"])
 
Ciao,
Marco.
 
 

 Quanto possa essere utile non lo so, non lo chiedere a me :-)
 
E' un discorso molto delicato, in quanto in numerosi ambienti, tra cui quello dove lavoro, questi metodi di misura di qualità e/o quantità di lavoro sono usati soprattutto per stabilire quanto va pagato al fornitore/realizzatore. Nel caso specifico usiamo i punti funzione, e ti assicuro che è un metodo ben lungi dal poter essere definito scientifico. Nel senso che è aperto a mille interpretazioni differenti.
 
 
 


Quando lavoravo in Ericsson una volta mi e' capitato di parlare dei 
function point con un aspirante dirigente.
 
Gia diceva che il metodo che conoscevo io per calcolarli era "troppo 
orientato allo sviluppo", poi immagina che faccia ha fatto quando gli ho 
detto che secondo me i coefficienti che avevano a che fare con le
"competenze" dei tecnici avrebbero assumere valori proporzionali allo
stipendio che prendevano.
 
Ciao,
Marco.
 
 
 


 
Esistono sw che effettuano stime


 Esistono sw che effettuano stime
 
Se sono riproducibili e non soggettive, va benissimo (ma, ad esempio, i 
tre software "stimatori" che vengono citati nella "tesi" [o qualunque 
altra cosa sia] sembrano dare "stime" diverse tra loro sulla 'bonta' di 
uno stesso software, oltre al fatto che sembrano non tener conto della 
correttezza).



 
sono di tipo euristico e comunque dipendono da come sono codificati gli 
algoritmi
Non esiste e forse non esisterà mai un metodo deterministico e certo per 
codificare queste cose,proprio come valutare un tema di italiano
E nel campo del sw le cose sono ancora peggio in quanto gli obiettivi da 
tenere conto sono ben maggiori che in un tema
Due  esempi banali possono essere:
1) piu goto si usano e piu il voto si abbassa di x punti
2) piu funzioni/soubroutine/metodi che superano le 50 righe fanno 
abbassare il voto di y punti
3) idem per quelle che superano le 200 righe,fanno abbassare il voto di 
z punti
Questi esempi hanno come obiettivo la manutenibilità del codice
 
Altro esempio
Piu il linguaggio usato e' di alto livello piu il voto si abbassa di 
x,partendo dall' assembler,C,C++,ecc..
 
Questo obiettivo è l' efficienza del codice
 
Per un elenco degli obiettivi:
http://it.wikipedia.org/wiki/Qualit%C3%A0_del_software
 


 massimo come sistema di misura da utilizzare in ambito industriale.
 
Scusa non capisco dove vuoi andare a parare. Valutare la qualità del 
codice non è dare un giudizio del software tout court. E dove si sarebbe 
mai parlato di giudizi arbitrari?

 stipendio che prendevano.
 
Il metodo dei punti funzione è quantitativo, nel senso che vorrebbe misurare la quantità dello sforzo realizzativo del software. Non vuole valutare la qualità del software.
Pertanto il discorso della competenza ed esperienza dei tecnici non entra in gioco.
Oltretutto la valutazione viene strettamente fatta dal punto di vista dell'utente, il che implica grossi problemi quando ci sono attività tutt'altro che banali ma che per l'utente sono "trasparenti". Tipico caso elaborazioni batch, caricamenti iniziali di database, "semplici" upgrade ed adeguamenti tecnologici, ecc.
Il discorso sulla competenza, ed in generale qualitativo, può però rientrare in specifici accordi contrattuali, magari con l'applicazione di altre metodologie specifiche. 

 Esistono sw che effettuano stime
 
Sarebbe un grave errore affidarsi a scatola chiusa ad un software che fa stime, senza conoscere su quali basi metodologiche le fa.
 
 
 

 nel senso che vorrebbe misurare la quantità dello sforzo realizzativo del software.
 
Diciamo che ho fatto confusione, pero' anche l'affermazione sopra non mi 
sembra del tutto esatta.
 
Per riportare il tutto in ambito piu' corretto direi cosi':
 
- i fuction point misurano la "dimensione del software"
e, come tu giustamente dici, nella misura della "dimensione del 
software" non entra la competenza dei programmatori.
 
 
Pero' poi,
 
- una volta trovata la "dimensione del software" bisogna
trovare il "costo di realizzazione" del software calcolato in 
"mesi/uomo" (effort, indichiamolo con M) "e tempo di consegna" (lead 
time, chiamiamolo T) .
 
Per calcolare questi ultimi due parametri, ci possono
essere vari metodi e la competenza dei
programmatori/analisti/sistemist/ ecc. entra eccome (almeno in alcuni
di tali metodi).
 
Il metodo che conoscevo io era il 
CO.CO.MO
 (o 
CO.CO.MO
 II) (che magari
ora sara' obsoleto, non so), il cui modello intermedio (non il "basic") 
prevedeva che per calcolare i suddetti due parametri, si calcolassero 
prima dei valori "nominali" di M e T (questi valori nominali dipendevano 
dai function point trovati e dal tipo di applicazione,
ma "non" dalla capacita' dei programmatori) e poi li si moltiplicassero
per dei coefficienti correttivi che dipendono "anche" (ma non "solo")
dalle capacita' dei lavoratori.
 
La tabella che c'e' sul mio vecchio
libro di ingegneria del software e che nmi sono andato
a rivedere per l'occasione) e' la stessa che
c'e' qui:
 
http://en.wikipedia.org/wiki/COCOMO#Intermediate_COCOMOs
 
 
 
Se la vedi, tra le altre, ci sono varie voci raggruppate sotto la voce 
piu' generica "personnel attributes".
 
Le voci sono
 
-Analyst capability
-Applications experience
-Software engineer capability
-Virtual machine experience,Programming language experience.
 
E i possibili valori da assegnare a queste voci sono dei numeri 
corrispondenti alle valutazioni
 
Very Low,Low,Nominal,High,Very High,Extra High.
 
(e ovviamente, il "coefficiente" per cui moltiplicare i
gli M e T nominali
e' tanto piu' basso quanto maggiore e' la "capability"
della persona. Giustamente: persona piu' capace => costi e tempi minori).
 
Quando al mio "responsabile" di allora dissi che la valutazione
di questi coefficienti (specialmente la Analyst Capability e
la Software engineer capability) dipendevano dallo stipendio
che queste figure prendevano (e quindi un programmatore/analista
con "Extra High Capability" deve necessariamente corrispondere a
un programmatore/analista con "Extra High Salary"),
indovina che faccia ha fatto.
 
Ciao,
Marco

 di tali metodi).
 
Assolutamente d'accordo. Quantomeno il tempo di realizzazione dovrebbe contare nella valutazione economica. 
Sta di fatto che dove lavoro la valutazione in questione viene fatta solo con i punti funzione.

 quantitativa della qualita'.
 
Invece importa sapere cos'e' il documento che stai leggendo. Fosse altro per avere un'idea approssimativa del contenuto del documento prima di andare a leggerlo per intero. Per esempio, contrariamente ad una tesi di buon livello, e' molto difficile che in un elaborato per un esame -sia pure di buon livello- si dia un'"indicazione di metodo" autorevole, se non altro perche' non e' formalmente revisionato da un "peer" o da una commissione esterna, e' piu' un compito che da' il docente per vedere se lo studente ha capito alcuni concetti base, ed eventualmente serve a valutare l'opinione dello studente maturata nella stesura dell'elaborato. Infatti l'elaborato in questione non da' indicazione di metodo, ma mette a confronto tre software per "valutare" la qualita' del codice, il documento citato dall'OP e' tutt'altro (non in meglio o in peggio, ma perche' i due documenti parlano di due cose completamente diverse).


inzomma. Se c'e' un supersenior che fa finta di lavorare tutto il giorno tutti i giorni (tipo Wally di Scott Adams), e dopo due anni produce un accrocchio, dovresti superpagarlo e dichiarare il suo codice di "alta qualita'"? :-)
 
 

 inzomma. Se c'e' un supersenior che fa finta di lavorare tutto il giorno tutti i giorni (tipo Wally di Scott Adams), e dopo due anni produce un accrocchio, dovresti superpagarlo e dichiarare il suo codice di "alta qualita'"? :-)
 
Teoricamente il supersenior può produrre un certo software in una frazione del tempo del superprincipiante che non sa dove mettere le mani.
Quindi pagheresti di più per avere il risultato in un tempo minore. Ed il tempo è uno dei pochi fattori con una misura universalmente riconosciuta. Oltre al fatto che il tempo è denaro :-)
La misura della qualità invece è del tutto arbitraria, almeno ad oggi. Molti dei cosiddetti "metodi" nascondono l'arbitrarietà dietro complesse e fumose procedure pseudo scientifiche/statistiche.

 frazione del tempo del superprincipiante che non sa dove mettere le mani.
 
Teoricamente. Praticamente puo' non fare una benemerita cippa per anni e mandare a ramengo il lavoro suo e degli altri. Guarda, da un lato son d'accordo con te che la qualita' del codice dipende da chi l'ha scritto, pero' valutare la "qualita'" di una persona e' ben piu' difficile che valutare quanto e' scritto bene del codice, quindi se vuoi giudicare oggettivamente come e' scritto un programma non lo puoi fare valutando chi l'ha scritto senza infilarti in un ginepraio.
 


definire qualita del codice cosi, senza altri parametri, non ha alcun senso
Qualita rispetto a cosa ?
 
qui si possono trovare i classici parametri su cui valutare la bonta di 
un codice
Notare che non tutti possono essere perseguiti se non a scapito di 
qualche altro parametro
 
http://it.wikipedia.org/wiki/Qualit%C3%A0_del_software
 
 
 

 Teoricamente. Praticamente puo' non fare una benemerita cippa per anni e mandare a ramengo il lavoro suo e degli altri. Guarda, da un lato son d'accordo con te che la qualita' del codice dipende da chi l'ha scritto, pero' valutare la "qualita'" di una persona e' ben piu' difficile che valutare quanto e' scritto bene del codice, quindi se vuoi giudicare oggettivamente come e' scritto un programma non lo puoi fare valutando chi l'ha scritto senza infilarti in un ginepraio.
 
Non capisco bene cosa vuoi dire. Che ci sia sempre qualche "pecora nera" è più che ovvio, ma allora vogliamo concluderne che l'esperienza in informatica non conta nulla? Oppure che neppure il tempo di realizzazione conta qualcosa? (inteso come uno dei parametri più facilmente misurabili, dove il senior può vincere).
E non capisco cosa c'entra il discorso sulla valutazione della persona, di cui  non ho proprio scritto. Vuoi forse dire che la qualità del codice aumenta anche in base alla simpatia, laboriosità, ecc. dello sviluppatore? :-)
 
 

 può vincere).
 
Se parliamo di pettinar le bambole hai ragione, se parliamo di progetti seri (a) un junior non fa il lavoro da senior, (b) il risultato non e' linearmente proporzionale al tempo che ci si investe.
 
 

 Se parliamo di pettinar le bambole hai ragione, se parliamo di progetti seri (a) un junior non fa il lavoro da senior, (b) il risultato non e' linearmente proporzionale al tempo che ci si investe.
 
 
Non è questione di linearità, è questione che tutti sono d'accordo nella misura del tempo :-) Unanimità assolutamente inesistente per le misure di qualità (nel software): ognuno c'ha la sua prediletta. 
Quanto al punto a, direi che il junior non può che diventare senior facendo via via lavori/progetti superiori alla sua esperienza. In altri termini, qualcuno di volta in volta gli dà fiducia, promuovendolo ad un livello superiore di responsabilità. Quindi è proprio il contrario, il mondo è pieno di "giovani" (in senso lato) di belle speranze che stanno facendo la loro prima esperienza in un dato ruolo. Alcuni avranno successo, e diventeranno senior, altri no, e si fermeranno a quel livello.
Comunque non so bene che c'entri questo con la misura della qualità del software :-)
 
 
 
 


Il problema e': come misuri in modo quantitativo ciascuno di tali 
parametri ?
 
Cioe' come fai a dire, dato il software A e il software B, A e' usabile 
10, B e' usabile 7 (qualsiasi sia l'unita' di misura dell'usabilita', 
anche se i numeri sono adimensionali va bene) in modo che la misura sia 
ripetibile anche da altri, non solo da te.
 
E poi, come passo successivo, ammesso che A sia usabile 10 e 
ecocompatibile 8 mentre b sia usabile 7 ma ecocompatibile 11, e' di 
migliore qualita' A o B, a parita' di altri parametri ?
 
Ciao,
Marco.
 
 


Ma nemmeno i coefficienti di valutazione dell'"expertize" delle persone 
devono necessariamente essere usati in modo linearmente proporzionale, 
anche se magari alcuni metodi lo fanno (e in ogni caso, molte tecniche 
di soluzione di problemi "non lineari" prevedono una linearizzazione).
 
Ciao,
Marco.

Il 20/11/2014 20:51, askaholik ha scritto:> On Sunday, November 16, 2014 
6:03:38 PM UTC, Marcoxxx wrote:
 >
 >>    1)qual e' "l'unita' di misura" della grandezza "qualita' del codice
 >> prodotto" ?
 >
 > Non esiste un'unita' di misura (universalmente condivisa) della 
qualita' del codice,
 
Se e' per questo non esiste nemmeno un'unica misura della forza (puoi 
usare i newton o i Kgp) o dell'energia (puo' usare i Joule o gli 
elettronvolt), e non esiste nemmeno un unico sistema di unita' di misura,
(esiste il sistema anglosassone, l'MKSA il SI ecc. anche se poi ne 
esiste uno "eletto" che viene riconosciuto da tutti). Non e' importante 
che ne esista una e una sola.
 
E' importante, secondo me, che chi dice di fornire una misura 
quantitativa della "qualita' del codice" dica qual'e' l'unita' di misura 
in cui si misura la grandezza da misurare (fosse anche un numero 
adimensionale).
Se metriche diverse usano unita' di misura diverse non sara' un grosso
problema, basta che ognuna specifichi la propria (e possibilmente 
specifichi anche come si effettua la misura).
 
 >Ciononostante, esistono metriche che misurano (quantitativamente) 
 >delle proprieta' del codice.
 
Personalmente, a parte l'elaborato postato da enoquick, non ne ho lette.
 
 >>    2) Data l'unita' di misura, come si effettua la misura delle 
grandezza
 >>    in questione ?
 >
 > valori normalizzati, che dipendono dal tipo di descrittore statistico 
che usi.
 > Qui un overview per capire l'articolo postato dall'OP: 
http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3049417/
 
 
Quando ho un po' di tempo lo leggero'
 
 >> (effettivamente nell'elaborato linkato [che sia una tesi o altro non
 >> importa] si da un'indicazione di un metodo per effettuare una misura
 >> quantitativa della qualita'.
 >
 > Invece importa sapere cos'e' il documento che stai leggendo.
 >Fosse altro per avere un'idea approssimativa del contenuto del 
 >documento prima di andare a leggerlo per intero.
 
 >Per esempio, contrariamente ad una tesi di buon livello, e' molto 
 >difficile che in un elaborato per un esame -
 
 >sia pure di buon livello- si dia un'"indicazione di metodo" autorevole,
 
 >se non altro perche' non e' formalmente revisionato da un "peer" o da 
 >una commissione esterna,
 
Beh', e' revisionato "da me" :-)
 
Se sia autorevole o no non lo so. Di sicuro e' quanto di piu' vicino ad 
un "misura quantitativa" tra tutti quelli che ho letto io, anche se il 
metodo proposto vale solo per alcuni tipi di software (direi solo per 
quelli scritti secondo il paradigma OO)
 
 > e' piu' un compito che da' il docente per vedere se lo studente ha 
 >capito alcuni concetti base,
 
 >ed eventualmente serve a valutare l'opinione dello studente maturata 
 >nella stesura dell'elaborato.
 
 > Infatti l'elaborato in questione non da' indicazione di metodo,
 
 
Scusa, ma la collocazione del software nel piano cartesiano e la sua 
distanza da una retta (o segmento) "ideale" non ti sembra un'indicazione 
di metodo (per altro, visto che si cita la distanza da tale segmento 
"ideale", a me sembra anche un metodo "quantitativo")?
Si parlava di "numero di classi" e di rapporti (ad esempio tra numero
di classi astratte e concrete). Mi sembrano quantita' "misurabili".
E anche il posizionare il codice su un punto del piano 
astrazione/instabilita' e misurare la distanza ddi tale  punto rispetto 
al segmento ideale mi pare una "indicazione di metodo" (che poi sia
un buon metodo o meno e' un altro discorso).
 
 
 >ma mette a confronto tre software per "valutare" la qualita' del >codice,
 
 >il documento citato dall'OP e' tutt'altro (non in meglio o in peggio, 
 >ma perche' i due documenti parlano
 
  >di due cose completamente diverse).
 
Si', fa anche questo (mettere a confronto tre software) e forse tale 
confronto e' anche la parte principale ma almeno la prima meta' 
dell'elaborato non parla di tali tre software, bensi' della qualita'
del software in generale. Anche se poi i tre software "misuratori" 
tengono conto anche di altri fattori, oltre di quello indicato in 
precedenza come "qualita'"; nella prima parte comunque  da' anche 
un'indicazione di metodo. Che poi sia un buon metodo o un cattivo metodo 
e' un'altra questione (per me non e' un buon metodo come minimo perche' 
non tiene conto della correttezza del codice e perche' limitato a 
particolari categorie di software [ad esempio un software scritto in 
assembly probabilmente non e' valutabile con quel metodo], ma comunque 
e' sempre un metodo, tra l'altro "quantitativo", visto che fornisce una 
quantita' "misurabile" [la distanza da un segmento ideale in un piano 
cartesiano]).
 
Ciao,
Marco.


No aspetta e' qui l'equivoco di fondo:
 
Non devi dichiarare il suo software "di qualita'" devi ridurgli lo 
stipendio e ricalcolare i costi del software in base al nuovo valore 
dello stipendio (*). Se il manager non lo fa, allora si dovrebbe 
cacciare il manager.
 
 
Per altro i function point non misurano tanto "la qualita'" quanto "la 
dimensione" del codice [i miei libri di ingegneria del software 
riportavano delle formule per riportare, dati gli FP, un valore di KLOC 
equivalenti da inserire nelle formule per il calcoro del costo]).
 
Cioe' i Function point sono piu' un punto da cui partire per stabilire 
"quanto costa" un software che non per stabilire quale e' la sua qualita'.
 
Ciao,
Marco.
 
(*) detto per inciso, questo e' anche uno dei motivi
secondo cui, per me, gli informatici dovrebbero essere tutti liberi
professionisti: non sai prima cosa questo produrra' per cui la 
retribuzione dell'informatico dovrebbe dipendere anche da cosa questo
ha prodotto di buono, cosi' come, normalmente, un autore di libri 
guadagna di piu' se il libro vende di piu' [idem per gli autori
di canzoni/cantanti, attori, ecc. Se il software e' un prodotto 
dell'editoria, dovrebbero valere modelli di business simili a quelli
degli altri prodotti dell'editoria. Anche i giornalisti se scrivono
articoli del menga, teoricamente dovrebbero avere vita piu' difficile,
anche se in questo caso le sovvenzioni pubbliche all'editoria falsano
non poco la situazione]. Lavorare ad un progetto informatico
dovrebbe essere come lavorare alla realizzazione di un film o di
un disco: se il film o il disco vanno bene, poi chi ci ha lavorato
puo' guadagnare molto. Viceversa si guadagna poco.
 

 Quando ho un po' di tempo lo leggero'
 
In realta' l'avevo gia' letto, cosi' come l'articolo postato dall'op.
 
Quello misura la qualita' sostanzialmente *esclusivamente* in termini
di "numero di bug" => meno bug ci sono migliore e' la qualita'. In altre
prende in considerazione la "correttezza" e non gli altri "indici di 
qualita'".
 
Tra l'altro non misura la correttezza di uno specifico software,
bensi' cerca di valutare se un dato linguaggio di programmazione
(o una categoria di linguaggi) presenta una maggiore predisposizione
ad essere "error-prone" rispetto ad altri.
 
E, se ho capito bene, la misura e' "a posteriori", cioe' andando
a vedere quali progetti su GitHub hanno dato luogo
a dei bug, quanti bug e quali erano i linguaggi di programmazione
usati in quei progetti che hanno dato luogo a dei bug per stimare anche
quali sono i linguaggi piu' error-prone.
 
In questo modo poi si ricostruisce una tabella dalla quale si
ricava che ad esempio i linguaggi procedurali con memoria
non gestita sono quelli che introducono la maggior parte dei bug
relativi alla memoria (l'avrei detto anch'io "a priori" comunque. Quello
che invece non avrei detto e' che, dai risultati che consiederano
tutti gli errori, ovvero sia quelli di memoria che quelli algoritmici, 
di concorrenza, ecc, il Perl sembra essere uno dei linguaggi meno 
error-prone rispetto agli altri. Personalmente avrei detto il contrario).
 
Quindi in realta' l'articolo dell'OP non fa nemmeno una stima della 
"correttezza" del codice di un software ma,al limite, una stima della 
predisposizione  di un linguaggio a produrre bug (stimata "per 
inferenza" [si dice cosi' ?] dal codice esistenze di molti programmi e 
molti linguaggi).
 
Pero' le caratteristiche di qualita' di un singolo software non vengono
trattate.
 
Ciao,
Marco.

 trattate.
 
in realta' si', perche' i bug sono una metrica di qualita' del software. Un programma con memory leaks, che crasha ogni due volte che lo apri, che ti impalla il sistema, che etc etc... lo giudichi di buona qualita'? ;-)
 
 
 

 "ideale", a me sembra anche un metodo "quantitativo")?
[....]
 
qui il discorso sta andando per la tangente :-)
ok, cerca su google linear regression analysis, magari partendo da qui:
http://en.wikipedia.org/wiki/Linear_regression
 
E dovrebbe coprire la risposta ai post che hai scritto, anche per quanto l'approssimazione lineare a sistemi non lineari, che produce residuals bassi solo per approssimazioni locali.

 il perl viene usato molto per progetti di bioinformatica, computazioni che vanno in esecuzione per mesi, quindi si sta bene attenti a farli funzionare ben benino, perche' -ad esempio- se crasha fa perdere mesi di lavoro.
 
Come mai in bioinformatica c'è questa preferenza per il Perl, che non mi sembra un linguaggio particolarmente efficiente (per abbreviare i tempi di elaborazione) ed "amichevole" per lo sviluppatore (per ridurre la probabilità di errori)? 
 

 probabilità di errori)?
 
In realta' il perl ha acquisito popolarita' nelle fasi conclusive dello human genome project, era relativamente facile da usare, le stringhe facilmente gestibili, cross-platform, non aveva bisogno di essere compilato. E soprattutto era facile mettere su uno script per completare tasks piu' o meno complessi, uno script tira l'altro e quelli di Cambridge hanno messo su bioPerl, che ha riscosso un buon successo. Considera che non tutti i progetti perl sono scritti interamente in perl, molte volte vengono usati su wrapper di programmi scritti in C o in fortran, non necessariamente recenti, e sicuramente con un'interfaccia poco user-friendly. Il perl era sicuramente una buona scelta, ed anche adesso viene usato molto, anche se alternative specialmente in python ce ne sono tante. E la storia si ripete, core C e fortran, wrapper e python. Tra 10 anni magari ci si chiedera' perche' python e' diffuso :-)

 In realta' il perl ha acquisito popolarita' nelle fasi conclusive dello human genome project, era relativamente facile da usare, le stringhe facilmente gestibili, cross-platform, non aveva bisogno di essere compilato. E soprattutto era facile mettere su uno script per completare tasks piu' o meno complessi, uno script tira l'altro e quelli di Cambridge hanno messo su bioPerl, che ha riscosso un buon successo. Considera che non tutti i progetti perl sono scritti interamente in perl, molte volte vengono usati su wrapper di programmi scritti in C o in fortran, non necessariamente recenti, e sicuramente con un'interfaccia poco user-friendly. Il perl era sicuramente una buona scelta, ed anche adesso viene usato molto, anche se alternative specialmente in python ce ne sono tante. E la storia si ripete, core C e fortran, wrapper e python. Tra 10 anni magari ci si chiedera' perche' python e' diffuso :-)
 
Ah, ok. Mi sembrava un pò bizzarro che ci si rassegnasse al Perl anche avendo pesanti esigenze di efficienza.
 
 

 che crasha ogni due volte che lo apri, che ti impalla il sistema, che etc etc... lo giudichi di buona qualita'? ;-)
 
A te potra' sembrare strano ma durante il primo anno che ho lavorato a 
tempo pieno (o al massimo il secondo anno, quindi nel periodo 1998-1999) 
una mia collega di allora mi disse che alcuni suoi conoscenti
avevano messo in piedi un server che, dopo che era stato messo in 
esercizio, ha funzionato tranquillamente per 3-4 mesi senza bisogno di 
manutenzione. Da quanto mi ricordo mi diceva che tale server ogni tanto 
veniva anche riavviato e continuava   a funzionare.
 
Poi, dopo 3-4 mesi da quando era in esercizio appunto, dopo un riavvio 
non funzionava piu' una mazza.
 
Dopo qualche giorno di "duro lavoro" passato tra lo sbigottimento 
generale ("ma... non e' possibile, ha sempre funzionato") si sono
accorti che praticamente c'era una variabile (un contatore) non 
inizializzata a zero. Il software era scritto in C e fino a quando
ad ogni riavvio della macchina quella variabile si inizializzava
da sola a zero, tutto funzionava. Quando poi da un certo punto in poi,
ha deciso di non inizializzarsi a zero ma a -72394876 (o qualsiasi altro 
numero diverso da zero) => le cose non funzionavano piu'.
 
Hai voglia di togliere l'ultima patch pensando che fosse colpa di
quella li' (e poi togli la penultima e poi la terzultima e cosi' via...).
 
Se fosse di buona qualita' o meno andrebbe giudicato in base a qualche 
metrica.
 
Ciao,
Marco.
 
 
 
 


Quelli sono bachi molto rognosi
Purtroppo C,e anche C++ perfino nelle istanze di classe, non 
inizializzano le variabili non di classe e non globali,a meno che non lo 
si specifica
Forse su quella macchina è cambiata la versione dell' OS per non 
inizializzare piu questo tipo di variabili oppure è cambiata la sequenza 
di boot e quindi gli è sempre andata bene
Una volta persino in una libreria C++ ho trovato un baco del genere
 
 

 metrica.
 
Quale sarebbe il nesso fra aneddoto e conclusione? Quello è un bug bello 
e buono anche se è rimasto latente per mesi, sta scritto nella seconda 
pagina del K&R che il contenuto delle variabili non inizializzate non è 
determinato. Un analizzatore di stile poteva certamente tirarti fuori la 
metrica che cerchi.

 metrica che cerchi.
 
Considerato che il compilatore C non inizializza nulla, e non ti obbliga a farlo, non si può sapere se questa variabile "libera" faceva parte di una precisa scelta progettuale (non inizializzare nessuna variabile).
Se il C ti dà questa possibilità, inizializzare a tappeto col paraocchi è una fesseria, generalmente parlando.
Sappiamo solo che non inizializzare quella singola variabile causava a volte un malfunzionamento (certo molto grave, visto che il programma non si avviava per niente).
Quindi nel caso specifico una metrica che contasse quante variabili non sono inizializzate sarebbe una metrica che non valuta la qualità del software in questione,  perchè data la scelta del C i progettisti hanno dato per scontato di accollarsi questo rischio specifico (almeno avrebbero dovuto...). 
Valuterà una misura della probabilità di incorrere in un bug tipico come questo, sarà quindi utile per fare una revisione mirata, ma non valuterà la qualità vera e propria.

 Quale sarebbe il nesso fra aneddoto e conclusione?
Il nesso e' nella parte che hai tagliato (non scritta da me)
nel post a cui rispondevo.
 
Ciao,
Marco
 
 

 metrica.
 
e' un'osservazione interessante: utilizzando come metrica i bug trovati la qualita' stimata del software varia nel tempo. E' necessaria quindi una qualche normalizzazione, non ricordo se ne hanno tenuto conto o meno (e purtroppo non ho il tempo di riprendere l'articolo).