Newsgroup: it.lavoro.informatica
Titolo: Danni provocati dal software

Leggiucchiando Embedded Muse sono incappato in una serie di firmware
disasters, e ricollegandomi al thread sulle assicurazioni, vi giro
alcuni link:
http://www.ganssle.com/articles/Firmwaredisasters1.htm
http://www.ganssle.com/articles/Firmwaredisasters2.htm
http://www.ganssle.com/articles/crashburn.htm
http://www.ganssle.com/articles/disaster.htm
Ci trovate fatti avvenuti nel settore aerospaziale (tra cui il Mars
Polar Lander), biomedicale (pacemaker e macchine per irradiare che
hanno finito per uccidere pazienti) e perfino la storia di un cesso
automatizzato che poteva scaraventare per terra l'utente!
Addirittura nel caso di una delle macchine da radioterapia l'errore
stava proprio nella HMI:
Dateline Panama, 2001. Another radiotherapy device, built by a
different company, zapped 28 patients. At least 8 died right after the
overexposures; another 15 either already have or are expected to die
as a result.
To protect the patient physicians put lead blocks around the tumor.
The operator draws the block configuration on the machine’s screen
using a mouse. Developers apparently expected the users to draw each
one individually, though the manual didn’t make that a requirement. 50
years of software engineering has taught us that users will always do
unexpected things. Since the blocks encircled the tumor a number of
doctors drew the entire configuration in one smooth arcing line.
The code printed out a reasonable treatment plan yet in fact delivered
its maximum radiation dose.
Software continues to kill.
The FDA found the usual four horsemen of the software apocalypse at
fault: inadequate testing, poor requirements, no code inspections, and
no use of a defined software process.

Campo insidioso quello della sicurezza... nel senso di safety e non
security!
Non sempre un design 100% funzionante è 100% sicuro... pensa ad
esempio ai frigoriferi: i primi modelli avevano tutti lo sportellone a
scatto, una soluzione sicuramente funzionale:
- la chiusura è ermetica, con risparmio di energia elettrica;
- una molla faceva chiudere automaticamente lo sportello nel caso uno
si dimenticasse.
Bene, quindi 100% funzionante... ma altrettanto sicuro no! Se un
bambino ci mette piede.. beh immagina :(
Ecco allora che si sono inventati i gommini magnetici: stessa
funzionalità, compatibile con l'auto-chiusura, e se un bambino ci si
infila l'unico effetto negativo sarà qualche schiaffone dalla mamma :)
--
www.megadix.it

 Non sempre un design 100% funzionante è 100% sicuro... pensa ad
Perche' si trascura sempre il vero punto debole del SW : l'interazione
con esseri umani.
Il vero punto debole e' l'essere umano, o meglio l'utonto, non la
tecnologia.
C'ya
	Steve

 
Con tutte le lamentele che siamo sottopagati, ci stupiamo anche dei 
conseguenti disastri?! :-D
Scusate, mi è scappata...

 Scusate, mi è scappata...
e con tutti i disastri, ci stupiano anche dei sottopagati?
scusate, è scappata anche a me...
-- 
++ Fino all'anno scorso avevo un solo difetto. Ero presuntuoso.
http://unopuntozero.wordpress.com/
http://www.flickr.com/photos/marko_po/

"STeve" ha scritto

In genere do sempre la colpa di tutto all'utonto, ma nel caso
della sicurezza, una volta tanto non sono d'accordo. Se rileggi
bene il *tuo* ;-) post penso che mi darai ragione, nel senso
che chi trascura il problema dell'interfaccia uomo macchina,
chi si deve far carico del problema, è il programmatore [1],
non l'utonto. Perché, proprio in quanto utonto, e perfino in
quanto utente :-) non ha il dovere di sapere come funziona
internamente un programma.
E' il programma che non dovrebbe permettere, o nel caso
dovrebbe rifiutare input potenzialmente pericolosi, e in subordine
o a dover evitare di compiere azioni pericolose.
[1] in senso lato: il programmatore, il manager, chi ha studiato
l'interfaccia, addirittura chi scrive la manualistica...
Bye, G. 

 
Giusto, è un circolo vizioso... è triste da dire, ma se si è ben pagati, 
si lavora più ad alto livello. Però è una cosa personale! Magari non 
tutti hanno la stessa reazione.


Quoto, ad esempio nel caso della macchina per radioterapia (ammesso che le 
cose siano andate come in quella brevissima descrizione) c'è stata grande 
superficialità da parte di chi ha fatto software e manualistica, non erano 
certo i dottori a doversi immaginare che il macchinario fosse stato 
progettato coi piedi a tal punti!
Ci sono macchinari industriali che spesso finiscono in mano ad operatori 
analfabeti o poco più, se chi scrive il software fa il minimo affidamento su 
di loro è un incosciente. 

 della sicurezza, una volta tanto non sono d'accordo. 
E' esattamente quello che ho detto.
Il "problema" e' l'utenza, non la tecnologia in se'.
E' ovvio che chi ha progettato la macchina non ha tenuto conto del
"problema utenza".
Dicendo che il problema e' dell'utente non intendevo dire che la "colpa"
e' dell'utente ma di chi ha ignorato del tutto tale problema, assumendo
che l'utente fosse un tecnico e che quindi potesse evitare di suo azioni
non appropriate per la macchina.
Specialmente in campo embedded manca ancora una cultura tecnica incline
a considerare il "problema utente".
Spesso scriviamo SW (mi ci metto anche io ) che assume chi usi la
macchina sappia cosa fare e sopratutto, cosa NON fare.
Ma a mia modesta opinione, in informatica in generale, partendo da
Windows, manca una cultura tecnica che permetta di scrivere SW "sicuro"
per persone al di fuori della nostra professione.
C'ya
	STeve


Non credo che c'entri tanto la cultura tecnica.
Per me il problema è che far analisi, progettare e implementare un sw con
una UI sicura fa gonfiare di almeno il doppio il tempo necessario a
rilasciare il sw. 
Più tempo = più costi = maggior costo del sw prodotto, per cui chi deve
decidere quanto tempo impiegare, e volendo puntare al minimo fatturabile,
obbligherà chi sviluppa a costuire UI non buone.
Ciao, Alessandro
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 rilasciare il sw. 
Quello sicuramente e' un altro aspetto del problema.
Non so che tipo di sviluppo fai in genere, ma dimmi, hai mai
letto/studiato testi che trattano specificatamente l'ergonomia e
tecniche di interfacciamento con l'utente ?
Io oggettivamente ho letto qualche anno fa dei testi, prevalentemente
"white paper" del MIT che trattavano il problema.
E sempre oggettivamente ho ritenuto che per applicare alcuni concetti si
dovesse avere a disposizione un Cray solo per l'interfaccia utente :)
Tanta teoria ma difficilmente applicabile, specialmente in campo embedded.
L'unica soluzione "tecnica" sarebbe di avere utenti addestrati, non
tanto tecnologicamente ma piuttosto come "forma mentis" ad interagire
con un sistema, cosa che spesso e' inapplicabile.
Piu' una tecnologia e' sofisticata piu' l'utenza dovrebbe essere addestrata.
Cosa ovviamente impossibile ... quindi il problema utente rimane, sempre
IMHO.
Ciao
	Steve

 obbligherà chi sviluppa a costuire UI non buone.
Il tuo discorso filerebbe se si parlasse di ambienti che non sono
"mission critical". E qui, mi pare evidente, si va pure *ben oltre*,
con il contorno di pesanti responsabilita' che mi pare tu stia
trascurando...
bye G.L.
-- 
"E' assolutamente evidente che l'arte del cinema si ispira
alla vita, mentre la vita si ispira alla TV" - Woody Allen