Il forum sulla Qualità di QualitiAmo

[QualitiAmo - Stefania]

[2p71828]

mi è venuto in mente un esempio capitatomi:

faccio un sito web (nel mio caso era un intranet) e utilizzo "apache" come motore del server.
Nella configurazione di apache posso determinare se mi notificherà tutti gli errori o solo quelli fatali, se li notificherà solo una volta o tutte le volte che si ripetono etc. Il bello dei siti web è che, se anche fai degli errori, il sistema, che già di per sè tenta di rimediare, per una combinazione di di file di configurazione dei programmi può sopperire all'errore facendoti sembrare tutto ok. Poi sposti i programmi su una altro server, una di queste configurazioni (ci sono decine e decine di flag all'interno) è diversa e sullo schermo dell'utente iniziano a comparire messaggi di errore, l'impaginazione salta, etc.
Il software è una brutta bestia: mi sono capitati casi in cui per mesi tutto era ok poi sono iniziati dei problemi ricaricando sempre gli stessi dati.

[Paoloruffatti]

Cari Stefania e Paolo,
io parto da un approccio storico: quando uscì nel 1987 la norma 29001-2-3 era il tempo del nucleare, del metalmeccanico e basta (la % di società che davano servizi era inferiore al 10% (ora abbiamo passato abbondantemente l'80%), naturale quindi che la norma parlasse di metalmeccanica (ricordate che allora era possibile certificare addirittura solo la produzione!? (pazzia!) l'80% dei certificati erano 9002 (tutti escludevano la progettazione perchè era troppo complicato (!!).

Da allora il punto 7.6 è rimasto tale e quale.
I casotti sono venuti fuori quando sono uscite macchine con sistemi di controllo elettronici, con sistemi di auto azzeramento ad accensione di macchina, con macchine come i distanziometri laser che funzionano o nono funzionano affatto (è difficile che un laser a gas emetta una lunghezza d'onda diversa!).

I nostri certificatori sono andati in pappa.

Per fortuna gli estensori della norma soppesano parola per parola e ci mettono 4-5 anni per modificarne una. Loro cosa hanno fatto? il punto 7.6 copre tutto il metalmeccanico e la strumentazione classica, ivi compresi i "materiali di riferimento" utilissimi per tarare le macchine per confronto (vedi i laboratori chimici), ma poi per il monitoraggio dei processi e il controllo dei prodotti, se la cavano con l'8.2.3 e 8.2.4 e morta la!

Dice giusto Zancky (l'altro Paolo) che se ci sono sistemi di misura non facilmente classificabili tra le macchine classiche ti devi inventare tu il sistema di misura e il relativo controllo di affidabilità. Pensate che l'AAMS quello che rilascia le licenze per i software che girano sulle slot machines (quelle che mangiano miliardi di euro ai poveri stupidi che affollano le sale giochi e che fanno miliardari i gestori, i quali a loro volta non stanno pagando da anni decine di miliardi di multe) ha definito le regole per il controllo del SW e i test di fatica da fare per assicurare che siano garantite le vincite ogni tot giocate e che i gestori paghino la tassa correttamente; ci sono poi degli enti accreditati per eseguire questi test.

Ma siamo a particolari processi di monitoraggio e misura 8.2.3, come tutti gli esempi che ci ha fatto Zancky con la solita dovizia di particolari.

Per me il 7.6 come reperto archeologico si applica a strumenti del giurassico per le aziende metalmeccaniche in via di estinzione.
cari saluti ad entrambi

[QualitiAmo - Stefania]

Ma qui per monitorare il mio prodotto mi serve un dispositivo che, nel mio caso, sarà un computer con una certa configurazione (con un certo browser all'ultima release, ecc.)

E' la norma, ad esempio, che un sito costruito con IE non funzioni con FF e viceversa, tanto per dirne una. O che ci si dimentichi che i siti devono restare leggibili anche per chi ha quelle porcherie di prime versioni di IE (con opportuni commenti nel codice html). Apriti cielo, poi, se inizi a parlare di CSS!!

Se lavori su una macchina che monta un solo browser, magari non aggiornato, rilascerai un prodotto che sulla macchina del cliente potrebbe non "girare" correttamente. Mantenere una giusta configurazione nel tempo, dunque, è uno dei punti che dobbiamo monitorare nel nostro dispositivo di controllo del prodotto.

Dato che la norma dice:

[2p71828]

sperando che Isolaura non si perda per strada e rimanga ancora più confusa
continuo sulla diatriba.

caro Paolo se ammetti che stai facendo un monitoraggio/misurazione secondo il 8.2.3 applichi una metrica, se applichi una metrica hai una taratura/verifica della stessa (possiamo escludere cose la soddisfazione del cliente, anche se esistono casi in cui i questionari andrebbero controllati)

Prendiamo una cosa semplice semplice, faccio un modulo in excel per una carta X-R e lo vendo. Prima di immetterlo nel mercato devo testarlo. il mio campione di riferimento me lo da l'aiag che nel suo bel manualetto mi dice di immettere una serie di dati e il risultato ottenuto deve coincidere con quello tabulato. Ora i dati del manuale aiag come dicevo sono il mio campione di riferimento e devo verificare che siano ancora validi (può essere uscita una nuova versione del manuale, la copia si è sgualcita etc)
Ora anche se l'attività è molto ma molto più facile che con un anello/tampone/passanonpassa tuttavia dal punto di vista logico è la stessa cosa

sarebbe interessante intervistare i colleghi/fornitori di isolaura e tramite domande capire cosa impiegano per la validazione

[Paoloruffatti]

Vabbè! , mi avete preso per stanchezza!
Scherzi a parte il punto norma 7.6 moderno (oltre a contenere la parte giurassica) dice che quando l'"attrezzo" è un software si deve "confermare" la sua capacità a "soddisfare l'applicazione prevista".

E' il caso dei SW che utilizzano i progettisti di impianti e che sono regalati dai fornitori di apparecchi illuminanti, che eseguono complicati calcoli di illuminotecnica e come output ti danno il codice dell'apparecchio da installare.

Io faccio fare la validazione di questi SW, confrontando l'output di questi SW in un caso specifico, con i calcoli fatti a mano usando le formule che ci insegnano a scuola. Io consiglio di farli in più applicazioni (magari limite: è successo il caso di un Sw che andava bene per i calcoli strutturali di edifici a pianta rettangolare che aveva grossi problemi su edifici a piante diverse: ad esempio traingolari ..... dicono che si è fessurato il palazzo!!)

Concludendo, avete ragione voi a non escludere il 7.6, ma è necessario definire per benino nel manuale e/o in una apposita procedura, come "confermare la capacità di soddisfare l'applicazione prevista", se non altro controllando semplicemente che sia ancora valida la copia sgualcita del manualetto AIAG di Zancky (coperatene una nuova di tanto in tanto...non costerà mica una fortuna, no!?)
Quanto ai sistemi operativi/macchine del cliente/nostri è ovvio che, come nel caso di Isolaura si debba andare ad installare il SW dal cliente e capire se gira sulle loro macchine. .....anche se è un po' tardi, dato che sarebbe bene informarsi al momento dell'offerta su che macchine /sistemi dovranno poi girare le applicazioni che vendono.
Isolaura parla di "validazione", ma comunque il concetto è che dobbiamo essere sicuri che il nostro SW sia così bravo da girare anche su dei cammelli antidiluviani che vivono nelle stalle dei clienti: vi è mai capitato di scoprire che c'è gente che usa dei computer pentium 1 con 256 di Ram , magari con windows 95 e poi si lagnano che sono lenti o che vanno in crash di sistema?
Ciao

[mascalzone79]

Sto leggendo con passione la discussione che è nata sull'argomento, e se posso dire la mia modesta opinione, sono sulla stessa linea di Zancky.
In passato ho collaborato con uno studio che realizzava siti web, e la cosiddetta fase di "validazione" era a carico nostro, ben prima del rilascio del prodotto al cliente. Noi la chiamavamo fase di debugging, perché appunto andavamo a scovare tutte le possibili incompatibilità con software ed hardware del prodotto. Per fare un esempio che può essere chiaro anche ai non addetti, su internet girano software per il commercio elettronico: in questi casi ci si affida a dei server sui quali girano i programmi (apache, ecc.), per cui bisogna verificare la completa compatibilità hw e sw sia lato client sia lato server. Parte del controllo si fa in fase di progettazione, parte del controllo a valle, prima del rilascio, anche perché se non tutto gira a dovere, si rischia di far perdere soldi al cliente finale!
_________________
Insisti e resisti, ottieni e conquisti!!

[QualitiAmo - Stefania]

[2p71828]

sono sempre più convinto che Isolaura dovrebbe intervistare chi le validata il software e investigare sui "mezzi" e dati che adopera, quale simulatore di accessi e di attacchi etc...

[Isolaura]

può sembrare che sia scomparsa, in realtà sto leggendo con attenzione il vostro confronto in merito a questo benedetto 7.6 che ammetto da un paio di giorni mi è diventato molto antipatico .... di sicuro escluderò parzialmente il punto ...oggi stesso mi occuperò, come consigliato da Paolo-zancky, di investigare sulla validazione del software e sulle metodologie ed i mezzi impiegati...in fondo mancano solo tre giorni alla verifica...che sarà mai!!!

[2p71828]

per non ingenerare confusione zancky fa di nome paolo

comunque forza e coraggio hai tutto la fine settimana per rimediare

Se tu fossi Stefano, ti direi che ti penserò mentre nuoto al mare

[Isolaura]

fine settimana a lavorare? anche io ti penserò mentre nuoto al mare, e giusto per non sentirmi in colpa, penserò anche al punto 7.6, questo per non "escluderlo" dai miei pensieri...

buon fine settimana a tutti
Laura

[Isolaura]

Naturalmente ho scherzato, parte del fine settimana l'ho trascorso a lavorare...Ma ne è valsa la pena, giovedì c'è stata la verifica ispettiva....un successone 0 NC, 0 raccomandazioni e molti complimenti....volevo condividerlo con voi che mi avete offerto moltissimi spunti per migliorare il mio sistema.

grazie

[dario]

Great! Brava! Appagata, ora ... al mare!!!!
squalo1

[gibbosky]