....e l'affidabilità del software:

http://www.edn.com/blog/1690000169/p...351&rid=350389

un pò tecnico ma interessante, anche i commenti dei lettori

Capoccetta ha scritto:

> ....e l'affidabilità del software:

> [..]

> un pò tecnico ma interessante, anche i commenti dei lettori


Intanto direi che e' interessante proprio perche' e' un po' tecnico :-).

Non ho il tempo di leggere le risposte dei lettori ma
mi vengono in mente alcune considerazioni in ordine sparso:

1 - Quando io scrivo i test case (e' una delle mie maggiori occupazioni
degli ultimi anni), aggiungo *sempre* nell' header o nel footer del
documento

"Program testing can be used to show the presence of bugs, but never to
show their absence!" (Dijkstra)"

Ma tanto non lo capiscono. E non lo capiscono perche' ragionano
"da imprenditori" e non "da tecnici".

"Sono stati fatti i test funzionali ?" Si'.
"Hanno rivelato malfunzionamenti ?" No

"Allora il software e' a posto!".

Ma chiunque non abbia conoscenze informatiche derivanti solo da
smanettamenti vari che la risposta dovrebbe essere "a posto una s**a!!"

Ma se lo vai a dire in azienda... in azienda ovviamente non si dice e se
lo dici tu sei lo s***o ingegnere che pensa di essere ganzo solo lui
perche' e' laureato mentre io sono il programmatore figo che ho imparato
sul campo
e magari ho fatto anche i soldi (magari mettendo su una b.r.) e quindi io
sono piu' esperto informatico di te (io la mia azienda informatica ce
l'ho, tu no: quindi io so cosa e' l'informatica!): io ho fatto un software
che ha passato i test quindi va bene e quindi mi devono pagare!!

2 - Concordo al 100% su

"There simply is no systematic approach to ensuring the quality of an
integrated hardware/software system."

And this is a tragedy."

Anzi, aggiungerei che non c'e' approccio "sistematico" nemmeno per
assicuraere la qualita' del software. O meglio l'approccio sistematico
c'e', solo che e' palesemente mancante di correttezza, sebbene rispetti
tutte le str***te previste dagli standard di qualita' dei processi.

3- "Thirty years ago (...) computer scientists such as Edsger Dijkstra
were making strides in methodology to create formally proven software. But
along came C, UNIX, and the cult of the bemused hobby programmer, and the
entire notion of formal correctness vanished under a smokescreen of
hacking.

So now, after decades invested in metrics-driven verification, formal
verification, and methodology management, we find that our chips don't
work as expected because the software is still being "verified" by feeding
it test cases until the schedule expires. And we find that our cars run
into things for the same reason, and the press of course will blame the
problem on "electronics.""

A me, da ex programmatore C con decennale esperienza dispiace ammetterlo,
ma credo che abbia ragione al 100%, anche se, per quel poco che ne so io,
non e' che anche la progettazione elettronica presenti questi metodi
eccezionali dal punto di vista della verifica formale di correttezza.




4- "The only parties in this little comedy that have an interest in
actually improving the state of the art are the engineers, who won't be
consulted, and the victims, who will be silenced by the lawyers. How much
better for everyone if it were a principle of civil law that when it is
found that damage has been inflicted by a failure, all of the diagnostic
information determined by the vendor and by independent parties must be
placed in the public domain, and may not be used to assess or assign
damages."

Io approverei alla grande, ma no sarebbe "better for everyone". In primo
luogo non sarebbe meglio per gli avvocati e probabilmente non sarebbe
meglio nemmeno per molti imprenditori.

Pero' gli imprenditori (e probabilmente anche gli avvocati) ci fanno
crescere, gli ingegeri no.

" Such a notion might somewhat restrict the income opportunities of
litigators,"

Appunto: non sarebbe quindi "better for everyone"

" but it would unquestionably assist the engineering community in learning
from our mistakes."

Gli imprenditori, gli avvocati (e magari anche "i litigators") ci fanno
crescere. Gli engineers invece no!


Ciao,
Marco

"Marcoxxx" ha scritto nel messaggio news:h871

> "Sono stati fatti i test funzionali ?" Si'.
> "Hanno rivelato malfunzionamenti ?" No
>
> "Allora il software e' a posto!".
>
> Ma chiunque non abbia conoscenze informatiche derivanti solo da
> smanettamenti vari che la risposta dovrebbe essere "a posto una s**a!!"
>

Sempre un passo avanti rispetto a:
"Ma compila senza errori?" Si.
"Allora il sw è a posto!"

> http://www.edn.com/blog/1690000169/p...nid=3351&rid=3....
>
> un pò tecnico ma interessante, anche i commenti dei lettori

WOW, la scoperta dell'acqua calda : "There simply is no systematic
approach to ensuring the quality of an integrated hardware/software
system.", e finalmente.

E comunque, nel caso in questione, credo che bisognerebbe
semplicemente RESISTERE alla tentazione di scrivere troppe righe di
codice tra la pressione del pedale ed il servo della farfalla del
carburatore (o quel che è).

Capoccetta wrote:

> un pò tecnico ma interessante, anche i commenti dei lettori

(non ho letto i commenti, desculpe)

E' interessante questo passaggio:

"How much better for everyone if it were a principle of civil law that
when it is found that damage has been inflicted by a failure, all of
the diagnostic information determined by the vendor and by independent
parties must be placed in the public domain, and may not be used to
assess or assign damages. "

E' interessante perche' corrisponde esattamente a come viene condotta
un'indagine quando si parla di incidenti aeronautici.

On 5 Feb, 10:39, aritopogig...@web.de (Marcoxxx) wrote:

>

>
> "There simply is no systematic approach to ensuring the quality of an
> integrated hardware/software system."
>
> And this is a tragedy."
>
> Anzi, aggiungerei che non c'e' approccio "sistematico" nemmeno per
> assicuraere la qualita' del software. O meglio l'approccio sistematico
> c'e', solo che e' palesemente mancante di correttezza, sebbene rispetti
> tutte le str***te previste dagli standard di qualita' dei processi.

In realtà in alcuni settori molto specifici come credo l'aerospaziale
ho letto che stanno cercando di arrivare al punto di far generare il
software automaticamente da una specie di CAD utilizzabile
direttamente dal progettista, senza intermediazione di programmatori;
tempo fa avevo letto un articolo su una delle riviste di cui ogni
tanto posto i link, ipotizzavano che in seguito la cosa si potesse
estendere ad altri settori dell'embedded meno di punta.
>

>
> A me, da ex programmatore C con decennale esperienza dispiace ammetterlo,
> ma credo che abbia ragione al 100%, anche se, per quel poco che ne so io,
> non e' che anche la progettazione elettronica presenti questi metodi
> eccezionali dal punto di vista della verifica formale di correttezza.

Però per la progettazione elettronica esistono delle prove oggettive:
EMC, sicurezza elettrica (che in realtà a loro volta possono essere
inficiate da problemi del firmware); l'equivalente per il software non
credo esista.

On 5 Feb, 10:39, aritopogig...@web.de (Marcoxxx) wrote:
> "Program testing can be used to show the presence of bugs, but never to
> show their absence!"  (Dijkstra)"

Certo che la frase è specialmente vera fino a quando il software è
scritto con linguaggi rudimentali, dal punto di vista del controllo
formale di correttezza. Confronta C, C++, Java/C#, Python, VB, ecc.
con Haskell od Ada (ma anche parzialmente Pascal, su scala più
ridotta).

Il 05/02/2010 10.39, Marcoxxx ha scritto:
> "Program testing can be used to show the presence of bugs, but never to
> show their absence!" (Dijkstra)"

sembra molto logico, ma non e' del tutto vero: se ogni singola funzione
viene testata al 100%, con tutte le possibili combinazioni di dati in
ingresso, il baco non puo' scappare; se pero' ci si affida ad un test
funzionale complessivo e incompleto..

> "There simply is no systematic approach to ensuring the quality of an
> integrated hardware/software system."
>
> And this is a tragedy."
>
> Anzi, aggiungerei che non c'e' approccio "sistematico" nemmeno per
> assicuraere la qualita' del software. O meglio l'approccio sistematico
> c'e', solo che e' palesemente mancante di correttezza, sebbene rispetti
> tutte le str***te previste dagli standard di qualita' dei processi.

eppure esistono intorno a noi apparecchi safety critical che funzionano
bene, senza farsi notare, senza difetti, senza causare danni o perdita
di vite umane; il software, in particolare, e' costruito sulla base di
normative, che definiscono esattamente i metodi per ottenere software
sicuro; questo in modo indipendente dal linguaggio. [es IEC60730]

> 3- "Thirty years ago (...) computer scientists such as Edsger Dijkstra
> were making strides in methodology to create formally proven software. But
> along came C, UNIX, and the cult of the bemused hobby programmer, and the
> entire notion of formal correctness vanished under a smokescreen of
> hacking.
>
> So now, after decades invested in metrics-driven verification, formal
> verification, and methodology management, we find that our chips don't
> work as expected because the software is still being "verified" by feeding
> it test cases until the schedule expires. And we find that our cars run
> into things for the same reason, and the press of course will blame the
> problem on "electronics.""
>
> A me, da ex programmatore C con decennale esperienza dispiace ammetterlo,
> ma credo che abbia ragione al 100%, anche se, per quel poco che ne so io,
> non e' che anche la progettazione elettronica presenti questi metodi
> eccezionali dal punto di vista della verifica formale di correttezza.

ma se anche fosse, la correttezza formale non garantisce affatto la
correttezza funzionale.

> 4- "The only parties in this little comedy that have an interest in
> actually improving the state of the art are the engineers, who won't be
> consulted, and the victims, who will be silenced by the lawyers. How much
> better for everyone if it were a principle of civil law that when it is
> found that damage has been inflicted by a failure, all of the diagnostic
> information determined by the vendor and by independent parties must be
> placed in the public domain, and may not be used to assess or assign
> damages."

rendere accessibile ai concorrenti tutta quella tecnologia costosa e
vitale ? non avverra' mai.


tornando ad un aspetto del problema, che era formalmente corretto:

"With the software fix, if the throttle is depressed and you step on
the brake, the electronics will say, "The driver wants to stop more
than he wants to go ahead, so we'll cut off the engine,'" Cole said.

cioe' era: freno + acceleratore = acceleratore


infine, questo e' sacrosanto, ma sistematicamente ignorato:

Fault tolerant design focuses on keeping the system running or safe in
spite of failures. These techniques are commonly applied in high value
designs where people’s lives are at stake (like airplanes, space ships,
and automobiles), but there are techniques that can be applied at even
lesser impact consumer level designs. [robertcravotta]


saluti

> sembra molto logico, ma non e' del tutto vero: se ogni singola funzione
> viene testata al 100%, con tutte le possibili combinazioni di dati in
> ingresso, il baco non puo' scappare;  se pero' ci si affida ad un test
> funzionale complessivo e incompleto..

Non è del tutto vero neppure questo : nei sistemi complessi
semplicemente non puoi testare tutto. Le alternative sono inteligenza
artificiale, sistemi ridondanti, sistemi di sicurezza passiva ed
attiva.

> eppure esistono intorno a noi apparecchi safety critical che funzionano
> bene, senza farsi notare, senza difetti, senza causare danni o perdita
> di vite umane; il software, in particolare, e' costruito sulla base di

Io direi che ci sono molti apparecchi dove l'errore è tollerato o
gestito, più o meno accuratamente.

> normative, che definiscono esattamente i metodi per ottenere software
> sicuro;  questo in modo indipendente dal linguaggio.   [es IEC60730]

non conosco la normativa, ma conosco elettronica ed informatica, e
semplicemente non è possible fare sistemi hardware e software
complessi privi di errore.

Certo, se il software deve solo giocare a tetris ne puoi scriverne
uno molto sicuro. Ma se includi nel sistema l'hardware di esecuzione e
quello di interfaccia le cose cambiano, e realizzare un braccio robot
che fa una cosa semplice come giocare a tetris sempre senza sbagliare
la vedo, a oggi, impossibile.

[cut]

On Feb 6, 3:41 pm, lowcost <dies> wrote:
> sembra molto logico, ma non e' del tutto vero: se ogni singola funzione
> viene testata al 100%, con tutte le possibili combinazioni di dati in
> ingresso, il baco non puo' scappare;  se pero' ci si affida ad un test
> funzionale complessivo e incompleto..

E' da poco che lavori vero ? :-)
E' il "sistema" che devi provare. Avere le singole funzioni testate
non copre ogni possibile interazione, anzi, ti da' un falso senso di
sicurezza.
Certo, e' positivo avere questo test fatto ma e' ben lontano
dall'essere sufficiente.
Been there, done that, got the t-shirt.

Si vede che non ci hai ancora sbattuto il naso :-)

> eppure esistono intorno a noi apparecchi safety critical che funzionano
> bene, senza farsi notare, senza difetti, senza causare danni o perdita
> di vite umane;

Non significa che non ci siano bachi.

> normative, che definiscono esattamente i metodi per ottenere software
> sicuro;  questo in modo indipendente dal linguaggio.   [es IEC60730]

Seee buona notte.
Il punto e' che non esistono sistemi di test esaustivi. Anzi, piu'
formalizzi e crei norme, piu' e' facile buttarci dentro "bachi"
trasversali.
Specialmente nel mondo embedded alla fine l'unica garanzia (che e' ben
poca cosa, concordo) e' l'esperienza dello sviluppatore, che negli
anni sbattendoci il grugno, ha imparato cosa fare e cosa NON fare e
perche'.
Ed e' una differenza enorme, vista tante volte.

Mi capita di trovare bachi in codice che gira da DECENNI, in ogni
possibile condizione. Eppure ne trovo ancora.
C'e' sempre quella condizione in piu' ... solo chi ha abbastanza
esperienza sa che il baco e' sempre in agguato e non abbassa MAI la
guardia.
Di sicuro chi ha esperienza non si affida ciecamente ai risultati di
un test, ma anzi ne inventa di nuovi e va oltre le norme e le regole.

> ma se anche fosse, la correttezza formale non garantisce affatto la
> correttezza funzionale.

Vero, ma aiuta e non poco.

> rendere accessibile ai concorrenti tutta quella tecnologia costosa e
> vitale ?     non avverra' mai.

E' ben per quello che i problemi continuano ad esistere.

C'ya
STeve

Il Sat, 06 Feb 2010 22:41:09 +0100, lowcost ha scritto:


>> "Program testing can be used to show the presence of bugs, but never to
>> show their absence!" (Dijkstra)"
>
> sembra molto logico, ma non e' del tutto vero: se ogni singola funzione
> viene testata al 100%, con tutte le possibili combinazioni di dati in
> ingresso, il baco non puo' scappare;

hai idea di cosa hai scritto qui sopra?
praticamente secondo te i test case per la funzione:

void print(String s);

dovrebbero includere tutte le possibili combinazioni di caratteri in s.
ti sembra abbia un senso?


> eppure esistono intorno a noi apparecchi safety critical che funzionano
> bene, senza farsi notare, senza difetti, senza causare danni o perdita
> di vite umane;

senza difetti *conosciuti*.
è fondamentale mantenere il punto di vista critico specie nel software
che ha applicazioni mission critical / safety critical. tant'è che le
procedure di qualità che tu stesso hai citato prevedono delle verifiche
di autocontrollo, cioè ammettono che possano essere sbagliate in modo non
previsto a priori.
la qualità del software va vista come un limite della funzione "sviluppo"
che tende alla qualità totale.

On 6 Feb, 22:41, lowcost <dies> wrote:
> sembra molto logico, ma non e' del tutto vero: se ogni singola funzione
> viene testata al 100%, con tutte le possibili combinazioni di dati in
> ingresso, il baco non puo' scappare;  se pero' ci si affida ad un test
> funzionale complessivo e incompleto..

Sbagliato. Il sistema derivato non può essere più corretto di quel
"sistema" che lo ha progettato, ovvero l'uomo.
E l'uomo non è infallibile... :-) Puoi verificare la perfetta
rispondenza ai requisiti, anche con metodi formali (se li usi, cosa
certamente limitata a certi ambiti). Ma se i requisiti sono sbagliati,
non c'è nulla da fare.
Quando le macchine si autoprogetteranno, allora forse il margine di
errore si ridurrà a zero.

"ispas" <gidesa> ha scritto nel messaggio Quando le macchine si
autoprogetteranno, allora forse il margine di
errore si ridurrà a zero.

"Tutte le macchine al potere, gli uomini a pane e acqua"

"Capoccetta" <er_capoccettaTOGLIMI> ha scritto nel messaggio
news:baef
>
> "ispas" <gidesa> ha scritto nel messaggio Quando le macchine
> si autoprogetteranno, allora forse il margine di
> errore si ridurrà a zero.
>
> "Tutte le macchine al potere, gli uomini a pane e acqua"

A proposito:

http://motori.corriere.it/motori/var...4f02aabe.shtml

On 7 Feb, 14:48, "Capoccetta" <er_capoccettaTOGL> wrote:
> [..]...

Bè, da qualche anno c'è già la Darpa Grand Challenge:
http://en.wikipedia.org/wiki/DARPA_Grand_Challenge

Uno o due anni fa simulava la guida in strade normali (Urban
challenge), con altri veicoli, semafori, ecc., non in una strada
desolata sulla montagna.
Non che quest'ultima sia una prova facile, ma mi impressiona di più
l'altra gara.
Curioso che abbia vinto un progetto in parte della GM, che poi è
fallita. Ma si vede che hanno preferito i Suv 6000 cc come tecnologia
"di punta".... :-)))