Newsgroup: it.lavoro.informatica
Titolo: Una questione di qualità?

Questi giorni, sentendo in tv un signore che diceva che il gap tra
l'Italia e il resto delle economie forti d'Europa è dovuto in primo luogo
alla povertà culturale del Belpaese, i miei due neuroni si sono messi in
moto, e mi sono fatto delle domande che vi ripropongo .
Quanti di voi hanno occasione di utilizzare strumenti come l'UML o una
qualsiasi strategia di progettazione prima di mettersi a scrivere codice?
In quanti posti è normale una attività seria e non frettolosa di analisi
e progettazione che produca documentazione "ufficiale", leggibile da
gente che in futuro potrebbe iniziare a lavorare sul progetto senza
saperne un accidente?
Quanti dei vostri capoprogetto (o di voi, se lo siete), applicano i Design
Patterns,o una strategia di progettazione/sviluppo di situazioni
ricorrenti che abbia delle basi scientifiche, o si preoccupano di porsi il
problema della scalabilità di quello che stanno scrivendo/disegnando?
Quanti esigono un minimo di commentazione del codice, almeno per le parti
non proprio autoesplicanti?
E infine, quanti di voi possono affermare con tranquillità che il tempo
dedicato al testing di una applicazione sia stato ragionevolmente
sufficiente, e condotto secondo criteri sensati?
Sarebbe molto interessante sapere sia da chi lavora in Italia sia da chi
lavora all'estero se è prassi comune lavorare come viene viene per i
motivi più comuni(ristrettezza dei tempi, cambiamenti delle specifiche in
corso d'opera ecc. ecc.) o se quello che si legge nei libri di ingegneria
del software è applicato da altre persone, oltre a quelle che li scrivono.
Graziassai a grandi e piccini
L.

 non proprio autoesplicanti?
Anche qui non serve a niente imporre una regola fissa.
Ho lavorato per due anni in una grossa azienda di automazione:
Richiedeva 30% di commenti rispetto al codice.
Risultato:
#define PORTA 3400
(... >1000 righe ...)
/*
*
*
*
*
*
*
*
*	questa funzione spedisce un byte alla porta 3949
*
*
*
*
*
*/
int sendByte(int byte)
{
	outByte(byte, PORTA);
}
(avete notato il *gravissimo* errore?)
poi, non contento, vedevi cose del tipo:
	i = o * b + 354;
senza nessuna spiegazione... con quel magic number come un pugno in un
occhio, variabili monolettera *globali*...
Lino

 del software è applicato da altre persone, oltre a quelle che li scrivono.
Una giusta via di mezzo. Nulla è teorico, nella pratica... ;)
-- 
______________________________________
Luc (31, CO, VC++ Programmer)
Editorial Systems Software development
______________________________________

 lavora all'estero se è prassi comune lavorare come viene viene per i
Anche se lavoro in ambito di progettazioni di reti, dico la mia.
Ho lavorato per diversi anni con colleghi inglesi e di loro apprezzavo (a
volte invidiavo) la loro minuziosa pianificazione e circostanziata
precisione nella documentazione. A volte, pero', tutto cio' si trasformava
in ostacoli micidiali nella realizzazione di qualsiasi cosa: due anni per
installare una scheda T/R su una FEP!
Insomma, il contro era che avevano flessibilita' pari a zero per qualsiasi
cosa.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 Richiedeva 30% di commenti rispetto al codice.
[cut]
questa è una solenne idiozia... ma non significa che sia bello trovarsi
a lavorare su librerie di funzioni di mille mila righe senza avere altro
che i nomi delle funzioni stesse per capire cosa si sta facendo...
Il problema che mi ponevo era : formare la gente per imparare a usare
questi strumenti ha senso o è uno spreco di soldi?
Grazie per la risposta :).

 ha scritto nel
messaggio
(...)
Il tuo post è da incorniciare. Non ho mai visto una descrizione così
*esatta* delle situazioni che ho trovato.
Per fare le cose con metodo ci vuole formazione, capacità di
osservazione e senso critico. In anni di lavoro non ho ancora trovato
tutte questo insieme. E poi la sfortuna è che chi commissiona i lavori
non è capace di valutare se gli strumenti sono usati bene o no. Se fai
un lavoro di qualità nessuno lo capisce. Se invece inizi a scrivere
del codice come ti gira in quel momento, riesci a far partire le cose,
e poi guadagni ogni volta che ci rimetti le mani. Ho perso dei lavori
perchè ho avuto la presunzione di far sedere a un tavolo il
committente per valutare le specifiche e fare le cose tenendo presente
il maggior numero di fattori possibili. I lavori sono andati a quelli
che hanno detto subito: "ci penso io" e poi hanno fatto delle
schifezze e continuano a lavorarci sopra (sempre guadagnando) per
metterle a posto e aggiungere dei pezzi ogni volta.
Così è la vita. Non c'è un mercato della qualità. Tu che sei esperto
di queste cose, come la vedi?
Ivan

 corso d'opera ecc. ecc.)
Ritardo e cambiamenti di specifiche ci sono sempre, ma fa parte della 
nostra ( nel senso di noi informatici ) professionalità fornire comunque 
lavori di qualità. Che so, in grave ristrettezza di tempo potresti 
pensare ad una soluzione "la cosa più semplice che funzioni" e poi 
andare di refactoring/building up, ma devono sempre essere scelte 
ponderate, ossia mai "come viene viene".  Il vero problema è che la 
qualità, nel nostro caso, è latente. Il cliente nell'immediato non la 
vede, o comunque non è in grado di apprezzarla.
Ciao
Luca

 Così è la vita. Non c'è un mercato della qualità.
Non ci è mai stato, caro Ivan... non ci è mai stato.
-- 
Pepe
Milano, Italy

 no, hai fatto una cagata...
ironia, chi era costei?

 di queste cose, come la vedi?
Semplice:
 
	nel mercato dell'eccesso il superfluo paga.
Ma questo non vale solo nell'informatica.
In un'economia non drogata una macchina che fa meno di 20km/l sarebbe
uno spreco, in autostrada si andrebbe a 90km/h e la benzina costerebbe 5
Euro al litro, senza tasse.
In un'informatica non drogata ci sarebbe il Pentium VI ma anche il 286 e
chiascuno avrebbe il suo mercato. Ci sarebbero PC da 1Gb di RAM e pc con
ancora 256Kb.
Quando i nodi verranno al pettine ci sara` bisogno di qualita`, il
mercato ne avra` bisogno. Basta aspettare.
Lino
PS. esperto?

 ironia, chi era costei?
Scusami, purtroppo ho avuto a che fare con gente che queste cose le dice
con grande convinzione e senza ironia... la stessa che quando fai uno user
case diagram ti chiede "ma che fai i disegnini?" e ti prende pure per il
culo... quindi non ho colto ;)
Ciao

del software è applicato da altre persone, oltre a quelle che li scrivono.
Beh, e' una domanda senza risposta. Tempo fa ho letto un libro che si
chiamava "laboratorio di programmazione", e che trattava
esplicitamente di ingegneria del software. Bello, ma applicabile solo
per progetti che richiedessero almeno un anno/uomo. Nessuno mi
pagherebbe una mole del genere di lavoro preliminare per un progetto
valutabile in un paio di mesi, significherebbe aumentare di un buon
30% il costo del progetto e, in ultima analisi, mettersi fuori
mercato.
--
Ciao!
Luca Menegotto

e poi guadagni ogni volta che ci rimetti le mani
centrato perfettamente il punto.
--
Ciao!
Luca Menegotto

 del software è applicato da altre persone, oltre a quelle che li scrivono.
io credo che i motivi siano piu' d'uno, certamente il discorso della
progettazione e' applicabile sia in grandi che in piccole aziende, con la
differenza che nelle piccole aziende le spese spesso ti mangiano vivo, per
cui il dipendente che fa questo lavoro costa un ciulo subito e non hai mai
la certezza che in futuro questa cosa ti servira' ... inoltre spesso si
parte con progetti piccoli che man mano crescono, e no si ha mai il tempo di
rivederli, metterli a posto, riorganizzarli, analizzarli, etc ... oppure il
discorso si riferisce alle commesse presso clienti esterni, dove eliminare i
tempi "morti" dovuti alla progettazione permette di costare meno e offrire
meno tempo di esecuzione del lavoro ...  la domanda allora e' "costare il
giusto e offrire l'ottimo, oppure costare un cazzo e offrire schifezze, in
cambio delle ottime opssibilita' di lavorare?!"
Io sarei per la prima opzione, ma vista l'italia come fai a proporre 40 ore
di progettazione, studio, analisi quando chi hai di fronte ti guarda con uan
faccia che parla da sola e dice "ho bisogno di questa cosa, la compro da te
e non so perche' ma ho l'impressione che mi stai fregando ..."
DAvide
-- 
This e-mail was sent with DaemonZone Webmail
http://www.daemonzone.it

 del software è applicato da altre persone, oltre a quelle che li scrivono.
Dipende dal progetto. L'ingegneria del software riguarda la gestione
di progetti (soprattutto complessi o mediamente complessi) adottando
metodologie e tecniche che permettano di realizzarlo 'come se fosse'
un qualsiasi prodotto industriale.
La scelta dei tool di sviluppo, della metodologia di progettazione,
del o dei linguaggi da usare, dell'architettura, del team, etc. sono
generalmente funzione dei vincoli di progetto: che tradotto significa
costo, tempo di realizzazione e qualità del progetto. Costi e tempi
spesso sono fissati, la qualità invece è l'unica che serve da subito
più al team che al cliente (quest'ultimo la percepisce indirettamente)
soprattutto per far fronte ai cambiamenti di specifiche in corso
d'opera, che sono la regola per chi lavora in questo campo. Infatti un
buon capo progetto deve essere in grado di saper gestire oltre al
prodotto software (nel senso di cui sopra) fissati i vincoli, anche i
rapporti con i clienti, col team, etc.
Saluti
--
Nibble

 PS. esperto?
Si, di questi tempi saper distinguere un byte da un int vuol dire
essere esperti!
PS. Perchè non usi le variabili monolettera globali e i magic number?
Sono così comode quando devi consegnare in fretta... Le usa anche mio
cugino che con il Rational Rose fa dei disegni bellissimi (ma a volte
usa Photo Shop che "è uguale")
Ivan

 saranno più drogati? E fra quanti secoli?
Ahime`, cio` non lo si puo` dire. Pero` il problema nord-sud e` di
portata diversa, io credo.
Per l'informatica il discorso credo sia piu` semplice. Anche ammesso che
ci sono "capi" che non capiscono il software di qualita` (e ne ho
trovati, soprattutto fra commerciali), questi stessi capi pero` poi
capiscono quando il cliente e` soddisfatto.
Se io sono convinto di scrivere cose di qualita` vado in prima linea,
come talvolta ho fatto. Rischio. Anche se loro non hanno previsto del
tempo per fare progettazione la faccio lo stesso ed il tempo che sembro
perdere all'inizio lo guadagno dopo perche` i bachi sono pochi e in
genere facilmente individuabili. Certo, rischio, perche` poi se la
consegna e` dopodomani io da quei diagrammini devo tirar fuori del
codice funzionante in fretta. Molto in fretta.
Ma se giochi bene le tue carte sei a posto.
Fanne uno di questi giochetti e poi anche il "capoccia" piu` retrogado
non ti viene a rompere le scatole se per tutta la mattina il tuo monitor
e` rimasto in stand by perche` stai facendo disegnini sulla carta.
Il circolo virtuoso della qualita` comincia dal basso. 
Lino

 del software è applicato da altre persone, oltre a quelle che li scrivono.
Penso che applicare tutti i suggerimenti, gli standard, suggeriti dai
libri
è impensabile
E' atrettanto vero però che per molte realtà tutto quello che
suggeriscono i
libri di ingegneria del software rimane pura utopia, queste sono
realtà dove
non si pensa che costruire software è come costruire una casa.
Per finire IMHO penso che siamo poveri culturamente rispetto agli
altri paesi,
però non è colpa nostra, sono loro che non sono italiani. :-)
G.M.

 di linee guida (mi riferisco al fantomatico testbook).
Beh un momento, il test va fatto fare da una persona che sappia anche
programmare e possibilmente che abbia partecipato alla progettazione e allo
sviluppo del sistema, l'importante è che non sia la stessa che ha scritto il
codice che deve essere testato........
Che poi effettuare i test e compilare la checklist sia una attività
terrificante che nessuno vuole fare è un dato di fatto che nessuno mette in
discussione......

 codice che deve essere testato........
Beh in materia di test non ho una grande esperienza (meno male :-) )
però penso che bisogna sempre distinguere la tipologia di test. Se fai
dei test di unità allora ovviamente il tester è il programmatore che
hai scritto quel codice.
Se parliamo di test di integrazione (dove il sistema vene visto come
una blackbox) secondo me il tester può anche non essere un
programmatore.
Concordi con me?
G.M.


 Il circolo virtuoso della qualita` comincia dal basso.
No, la qualità è una funzione _strategica_. E sul fatto che la qualità costa
gratis, è vero solo nel senso che gli investimenti in qualità si ripagano,
ma gli investimenti sono necessari e qualcuno deve autorizzarli.
Tu non hai budget, ed anche sulla libertà di come allochi il tuo tempo ci
sono limiti.
Perché UML abbia una qualche forma di rientro economico su un progetto, per
esempio, non puoi essere tu l'unico che lo usa, dato che la sua utilità su
progetti di una sola persona è discutibile: serve per documentare progetti
complessi.
Lo scopo della programmazione ad oggetti è soprattutto il riutilizzo del
codice, oltre alla semplice riduzione di complessità ed al fatto che pensare
per categorie concettuali è una caratteristica della psiche umana.
Per poter riutilizzare del codice, devi però avere una visione che supera il
singolo progetto a cui stai lavorando, devi cioè avere una strategia
aziendale in tale senso.
Per esempio è utile che esistano dei meccanismi premianti che incentivano e
misurano la produzione di codice di qualità, e lo sviluppo o il riutilizzo
di componenti software.
Implica che chi è "ai piani alti" sia capace di ragionare per astrazioni,
che abbia una strategia.
Se ti si misura e ti si ricompensa, sulla base di quante ore di
straordinario fai e quante linee di codice scrivi, cosa pensi ne verrà
fuori?
Inizi a capire come mai in Italia non esportiamo e non innoviamo? Qui in
genere ragioniamo "a perdere".
Non riutilizziamo, oltre al codice, nemmeno la conoscenza delle persone.
Da un punto di vista della gestione della conoscenza, i contratti flessibili
ed il precariato partono dal presupposto che la conoscenza sia una proprietà
della direzione aziendale, e che chi lavora sia solo un esecutore,
sostituibile come una parte di ricambio o un pezzo meccanico.
Il precariato affossa rapidamente il vantaggio competitivo basato sulla
conoscenza: o questa semplicemente non viene prodotta, o se si non rimane
comunque in azienda. Se come azienda usi UML come idea di marketing e non
come parte del tuo processo di sviluppo, restano dei disegnini, realizzati
con un simpatico formalismo, che descrivono una situazione ormai distante
dalla realtà presente, belli, carini, da far vedere ad un cliente per fargli
credere di aver scritto tanta bella documentazione e chiedergli più soldi...
Prova a menzionare l'argomento pattern con un dirigente, e segui la sua
mimica facciale.
Se sei sfortunato, alcune smorfie e sguardi fissi nel vuoto di alcuni
esemplari umani meriterebbero una foto ed avvalorano la nostra discendenza
dai primati, ma evidentemente l'evoluzione deve essere a volte andata a
diverse velocità :-)
Come puoi, in un contesto di questo genere pensare di imporre la qualità dal
basso quando la direzione, aziendale o di progetto vuole deliberatamente
navigare nella tua direzione opposta?
Non puoi tu, ultima ruota del carro, cambiare rotta a tutta la nave in un
contesto aziendale, e non è nemmeno onesto nei tuoi confronti chiederti di
farlo.

 farlo.
Fare il software un tanto al chilo conviene tanto al programmatore (che
non ci deve perdere la testa) che al dirigente.
Diciamo allora che e` una simbiosi comoda a tutte e due le parti, "fin
che la barca va..."
Io, personalmente, non faccio cosi`, ma ammetto di essere uno dei pochi.
Lino

 nel mercato dell'eccesso il superfluo paga.
Gli esempi che citi sono validi per l'hardware, facilmente ed oggettivamente
misurabile.
Una differenza sostanziale è invece che nel mercato del SOFTWARE la qualità
non può essere facilmente misurata dal consumatore, che compra in generale a
scatola chiusa dei programmi dei quali osserva solo il funzionamento agli
effetti esterni dopo l'acquisto.
Non ha modo di capire preventivamene se siano stati scritti correttamente e
contengano o meno degli errori, in modo non molto diverso dall'acquisto di
auto usate.
Sarà uno dei motivi per cui i commerciali dell'informatica mi sembra possano
spessissimo essere definiti "venditori di auto usate"? :-)
Dal punto di vista di un economista il mercato delle auto usate si chiama
"lemon market", un mercato in cui vince il prodotto peggiore, al prezzo più
basso, dato che i prodotti di qualità tendono a non venire riconosciuti come
tali dal potenziale acquirente, che anzi li scarta. Lemon sarebbe
traducibile in "bidone", "pacco".
Prova invece a diventare leader di settore nel mercato della cioccolata con
un cattivo prodotto...
Non sono completamente convinto del fatto che il software sia sempre in ogni
caso un mercato del tipo descritto, un lemon market, ma questo ragionamento
spiegherebbe in parte fenomeni come l'ascesa della Microsoft, che non è
certo leader di qualità.

 effetti esterni dopo l'acquisto.
Forse si potrebbe distinguere fra software e software.
In *certi* tipi di software la qualita` non e` facilmente misurabile, ma
in altri eccome! Basta pensare a un compilatore o a una routine di
backup.
Generi un test set abbastanza corposo (ovvio, non totale, ma anche i
chip non possono essere testati su tutti gli input, si decidono dei
vettori di test significativi) e ogni volta che fai una piccola modifica
vedi se hai "rotto" il giocattolo.
Il problema e` che in genere questi software non sono visti dall'utente
finale che vede solo le icone e i messaggini. I menu a tendina e le
barrette di scorrimento.
Li` la qualita` non solo e` un optional ma e` mascherabile, nel senso
che si pensa di aggirarla mettendo qualche feature in piu` e non
correggendo quelle che gia` ci sono.
E` un po' difficile dare un giudizio che non sia un PREgiudizio...
Lino

 correggendo quelle che gia` ci sono.
Che la qualità di una piccola utility sia più facilmente determinabile
rispetto alla qualità di un intero sistema operativo come XP è
indiscutibile.
Ma i soldi per chi scrive piccole utility sono solo briciole, il grosso va
all'unico produttore di sistemi operativi desktop rimasto...    :-(

 dover "pagare pegno" in caso di guai :-)
<imho>
Io credo che, anche qui, il cambiamento debba venire dal basso. Fino a
quando la maggioranza, appena esce il nuovo "pacchetto", lo compra in
massa, quelli che chiedono invece la correzione dei bachi della versione
precedente non verranno ascoltati.
Il problema e` che l'informatica si vede ancora come un bene di
intrattenimento, non di uso.
Di solito non si compra un frigorifero ogni due anni anche se e` uscito
quello con la feature in piu`, mentre e` facile che il geek di turno
cambi processore solo perche` gli permette qualche fps in piu` sui suoi
giochini, ma per altro totalmente non sfruttato.
Fino a quando il mercato hw e sw "tira", paradossalmente, io credo, non
si pensa alla qualita`: si continuera` a dire:
"Vabbe', aggiungo un Giga di RAM e chissenefrega, metto il Pentazillion
a 303 GHertz e l'applicazione gira che e` un piacere..."
Era questo il senso che davo alla frase:
nel mercato dell'eccesso il superfluo paga.
Come dice il proverbio: "fin che la barca va..."
</imho>
Lino