Newsgroup: it.discussioni.iso9000
Titolo: Certificazione software

Ciao a tutti,
Su che norma mi baso per richiedere ad un fornitore la cerificazione del
software che lui mi produce ?
Lui lo definisce "firmware per microelaboratori"
In pratica è il software che fa funzionare degli apparecchi con funzioni
di analisi (misurano dei livelli di colonne di liquido) e che lui
installa su apparecchi da lui costruiti su specifiche concordate.
Spero di essere stato abbastanza poco chiaro
Grazie a tutti
Gabriele Monciatti

basati sulla certificazione dell'avvenuto collaudo funzionale (con tutte le
condizioni di eventuale guasto o imprevisti (es mancanza di alimentazione e
ripristino alimentazione)).
Esiste la possibilità di aggiornamento dello stesso ?
se si deve avvenire in maniera facile e mantenere la compatibilità con il
passato.

 Spero di essere stato abbastanza poco chiaro
Sei stato talmente poco chiaro che ti abbiamo capito in due (chissà ... poi
se è vero!)


Gabriele Monciatti wrote:

Perche' vuoi avere al certifucazione del Sw che ti viene fornito?
Lo usate voi oppure lo rivendete (magari insieme a altri prodotti o
componenti)?
Saluti cordiali
Paolo Astorri

 componenti)?
Ciao Paolo,
a causa della solita ASL che richiede così, all'impronta, che gli
apparecchi abbiano il software che gli permette di funzionare,
certificato.
Lo rivendiamo (in pratica) perché è parte integrante di certi strumenti
che commercializziamo e che senza di esso sarebbero solo dei pezzi di
ferro.
Ciao grazie anche a Dex e ad Alessandro
Gabriele Monciatti

Gabriele Monciatti wrote:

Caro Gabriele,
Gli apparecchi sono dispsositivi medici? Quale classe?
Se si anche il Sw lo e': quindi ricade nelle prescrizioni delle 93/42
(fascicolo tecnico, RES....).
Se voi producete Disp.Medici il sw diventa una parte di essi e richiede un
fascicolo tecnico.
Attenzione pero' a chi immette in commercio il SW (voi o direttamente il
produttore) come dispositivo medico.
Devo  rileggere la 93/42 (comunque non e' richiesta la certificazione ma la
dichiarazione di conformità, se ben ricordo).
Saluti cordiali.
Paolo Astorri

comunque esiste una norma tecnica per il sw.......
a memoria non la so , ma so che esiste...... ed ha 6 requisiti essenziali
base:
1) usabilità
2) manutenibilità
3) aggiornabilità
4) affidabilità
5) compatibilità
6) trasponibilità
non ne sono sicuro però.........

 wrote in message 917kak$3kje$1...@stargate1.inet.it...



giusto per curiosita', sono in ordine sparso o alcune hanno
"piu'" importanza di altre ?
grazie 
ciauz
Vincenzo 'lo sciamano'   Bologna (ITALIA-ITALY)
Homepage  
http://www.geocities.com/vincesalsero/

 7) Portabilità
Ad occhio, dubito dell'utilità e applicabilità di una tale norma, a meno che
non sia un cumulo di banalità (cosa probabile). Ho un vago ricordo di qualcosa
del genere, nel quale mi sono imbattuto in passato.
In ogni caso si parla di software, e non di firmware, e in un contesto direi
totalmente diverso di quello di uno che acquista una macchina con un computer
"embedded". Certe nozioni come "manutenibilità" e "portabilità" hanno senso
solo a livello del sorgente, o comunque di produzione del software. Quindi
hanno senso nel caso di una commessa nella quali si richieda lo sviluppo di
software per computer. In questi casi possono scattare una serie di requisiti,
compresa la norma ISO9000 specifica per le commesse di produzione software, ma
che anche nel caso delle commesse military e aereospace, (cioè delle più
esigenti in fatto di qualità e affidabilità) si riferiscono fondamentalmente
alle modalità di documentazione dei sorgenti, e delle tecniche di ingegneria
software (come ad esempio la programmazione ad oggetti), tutte cose
"invisibili" a livello di codice eseguibile.
Un firmware è qualcosa di intrinsecamente "non portabile", ad esempio, e non ha
senso parlare di manutenibilità di un codice che è contenuto in una rom e
quindi per definizione non è soggetto ad evoluzioni presso l'utente finale, se
si è nel punto di vista di quest'ultimo. Quanto all'usabilità, nel caso di
software embedded essa coincide con quella della macchina, e quindi ha poco
senso riferirla alla sola componente software (ha senso parlare dell'usabilità
del bilancere di un orologio da polso meccanico?).
In ogni caso, ogni documentazione di portabilità, manutenibilità, affidabilità
di un software richiede la "disclosure" di informazioni che sono generalmente
considerate, nella giurisprudenza internazionale (che ciò ci piaccia o meno)
come segreto industriale protetto addirittura da norme penali. Il "reverse
engineering", ovvero
l'operazione di ricostruire dall'eseguibile la struttura di partenza (sorgenti,
architettura, ecc.) del software è reato penale, quanto la violazione di un
brevetto o lo spionaggio industriale.
Quindi, la certificazione di tali caratteristiche nel caso di acquisto di una
licenza d'uso di un eseguibile cozza contro la natura dei rapporti giuridici
che si instaurano all'atto stesso dell'acquisto appunto di UNA LICENZA D'USO (e
non del software - o meglio ancora, della licenza di particolari forme di
commercializzazione di esso -
che presuppone invece la cessione proprio di quelle informazioni e dei relativi
sorgenti commentati e documentati, ma che è fatta a cifre ben diverse, per
numerosi zeri, da quelle dell'acquisto di una semplice licenza d'uso). Il
problema è che molte persone confondono l'acquisto di software con l'acquisto
di una licenza d'uso (che è invece quello che normalmente si fa: basta leggere
le pappardelle Microsoft all'atto delle installazioni: le famose EULA).
Può avere senso parlare di usabilità di un programma di computer, invece, dato
che, come sappiamo, sono i programmi di computer che noi usiamo in quanto tali
(non si usa "un computer", ma i programmi che vi risiedono...). Ma trovami
citata la famosa IEC in un solo contratto di fornitura di un qualunque
software, anche specialistico, a
cominciare dai sistemi operativi, anche non Microsoft. Se non ricordo male, in
questo caso la norma si riferisce al manuale d'uso (alla sua esistenza, e alla
sua forma). Ma c'è il rischio che essa sia peggiorativa rispetto alle usanze
attuali, dato che è nata nel contesto di forniture industriali, per pochi pezzi
da dare in mano a personale specializzato.
La norma IEC potrà dunque anche essere (o divenire) una norma "de jure", ma non
lo è "de facto". E nel campo delle tecnologie avanzate, sono solo queste ultime
a contare qualcosa, dato che esse si evolvono ad una velocità superiore a
quella del diritto.
Alessandro (alias Lorenzo) Seno





Ciao,


Trattandosi di sw su dispositi medici (se non ho capito male) diventa a sua 
volta dispositivo medico. Penso che il termine certificazione del sw vada 
sostituito con Validazione.


Ovvero una sequenza di prove e test per validare appunto quanto 
fatto.


A proposito sul sito dell'fda c'è una guida, del 97, ma i cui principi 
generali la rendono comunque ancora valida.


 
http://www.fda.gov/cdrh/comp/swareval.html


 


Come (non ricordo chi) è importante sapere la classe del disposito e 
soprattutto sapere se è un active o passive device.


 


 



 soprattutto sapere se è un active o passive device.
Caro Alessandro,
perche' validazione? Il SW puo' essere un Disp. Medico, cioe' un
prodotto. Verrà eventualmente validata la progettazione del SW.
L'importante e' saper la classe: da quello si deducone i requisiti
essenziali di sicurezza applicabili.
Saluti cordiali

 se è un active o passive device.
Dimenticavo..........
Paolo Astorri

 Alessandro (alias Lorenzo) Seno
Probabilmente, e qui attendo lumi da Gabriele, il problema sta negli adempimenti
(dichiarazione conformità e tracciabilità).
Il problema, in ogni caso, non e' peregrino e conosco aziende che hanno preso
soluzioni molto, molto diverse per il software.
Saluti cordiali a tutti.
Paolo Astorri
(questa volta non dimentico la firma)





Ciao Paolo,


Forse faccio un pò di confusione però nella definizione di Validazione la 
nota  2 indica :"la validazione viene normalmente eseguita sul prodotto 
finale in condizioni di utilizzazione definite. Essa può rendersi necessaria in 
fase antecedenti."


 


 


Sw e hw divisi o insieme sono in ogni modo medical device. La classe, 
soprattutto se sono  device attivi, definirà le prove di sicurezza 
elettrica secondo la cei 62-5.


 


Nella mia azienda (che produce medical devise passivi) tutto ciò che è sw e 
fa funzionare / comandare processi e macchine che hanno significativoimpatto 
sulla qualità del prodotto processo sono "Validati" nel senso che, prima 
di renderli "operativi" sono verificati con un protocollo di 
validazione: una prova in field per (cito la norma) confermare il 
soddisfacimento dei particolare requisitiad un determinato impiego. 


 


Alessandro


 (questa volta non dimentico la firma)
Eh sì, una bella gatta da pelare (o la stiamo buttando giù un po' troppo
dura?).
Gabri el Monciatti (e gli altri) dica se sto esagerando, smetto subito!
Alessandro Seno

 (dichiarazione conformità e tracciabilità).
vedi lo sproloquio qui sopra
Ciao a tutti 
Gabriele Monciatti

 risultati attesi, di report di test effettuati.
Ma riferiti al solo firmware o al dispositivo in generale?
Ciao
--
Alessandro Seno

 Ma riferiti al solo firmware o al dispositivo in generale?
Non mi risulta facile discriminare le due cose :-( 
Sono talmente interconnesse che, IMHO, forse è più
pratico/conveniente/efficace andare ad analizzare il buon funzionamento
del firmware deducendolo dalla prestazione complessiva della macchina. 
A presto
Gabriele Monciatti

 Alessandro Seno
NON penso di essere stato chiaro....sigh!
Saluti cordiali
Paolo Astorri

dovrebbe essere la ISO/IEC 9126
ciao a tutti
spazio pipar

 wrote in message
3a37f60a...@news.iol.it...
