dati alterati a causa di un bugs è possibile fare causa?

[WarDuck]

Non era disponibile una versione trial del pacchetto d'aggiornamento? In genere quando si fa un upgrade la prima cosa che si testa è la compatibilità (magari su una piattaforma di test)...

Ad ogni modo, sono in pochi (parlando di utenti comuni) quelli che vedono il software come frutto di un processo ingegneristico.

Esistono metodi formali per specificare e testare il software, so anche dell'esistenza di un sistema che prende in ingresso una specifica formale (matematico/logica) traducendola poi in un algoritmo funzionante e corretto (e per di più ottimizzato).

Ovviamente la complessità iniziale di generare delle specifiche formali viene poi ripagata in fase di sviluppo e testing.

Ogni volta agli occhi di gente inesperta sembra che gli sviluppatori software vendano fumo... e che tutto ciò debba essere gratuito non si sa bene per quale motivo.

[fero86]

Originariamente inviato da cdimauro

Lo è sicuramente. Ma i markettari devono vendere, per cui non mi meravigliano queste sparate.

senti eh: io non ho mai sentito la Microsoft fare sparate simili riguardo al loro sistema operativo e il motivo non é di certo legato alla qualitá. ci sono markettari e markettari.

[PGI-Bis]

Qualche tempo fa avevo letto un articolo che parlava di una software house (forse) australiana (credo... ormai ho una punta di alzheimer...) che aveva sviluppato un programma matematicamente privo di bug.

Causa alla software house. Si può fare - e figuriamoci. Non è detto che si vinca. In primis non ogni limitazione di responsabilità vale per il solo fatto di essere stabilita contrattualmente e questo a prescindere dalla normativa a tutela del consumatore - che in questo non si applica.

La questione importante però è un'altra. Non è che siccome è normale che un programma abbia dei bug ciò significa che ogni bug è normale.

In generale ogni adempimento sottostà al principio secondo cui chi deve adempiere è tenuto a farlo come si deve.

Cosa concretamente significhi "come si deve" dipende dal settore (nel periodo storico).

Se vai da un fabbro a farti fare la testiera del letto non puoi dirgli che sia fatta male perchè pende a destra di 0.001 millimetri ma se una zampa è un metro più alta dell'altra hai i tuoi bei motivi per dirgli che ha fatto una schifezza.

Idem per il software. Se il programma svirgola perchè l'hanno fatto fare a uno stagista, quello ha scambiato le addizioni per sottrazioni e nessuno ha controllato, sfido chiunque a dire che il lavoro possa dirsi ben fatto.

Comunque è sempre meglio affidarsi al parere di un legale piuttosto che a quello di un forum per questioni così delicate.

[fero86]

PGI, il post é interessantissimo, ma quali sono le norme che tutelano il consumatore sotto questi termini? nell'esempio del fabbro a quale norma dovrei fare riferimento nel secondo caso (lavoro fatto veramente male) ?

[PGI-Bis]

Vanno premesse due cose.

1. ho dato Diritto Civile I e II all'epoca di Traiano
2. un'impresa non è un consumatore

Quando al consumatore, ai miei tempi erano gli articoli 1469 (bis, ter e via dicendo) del codice civile ad occuparsene.

Per l'adempimento, codice civile, 1176 e seguenti.

Ma se non ricordo male, la questione consumatore - non consumatore, non riguarda tanto i vizi di ciò che compri quanto tempi e modi di ciò che capita dopo.

In altri termini una cosa fa schifo per per un consumatore nello stesso senso in cui fa schifo per un non consumatore. Quello che cambia è il modo in cui le due parti - il venditore di schifezze e l'acquirente di schifezze - si rapportano. La disciplina normale bilancia il rapporto in un certo modo, quella che riguarda i consumatori considera questi ultimi svantaggiati in partenza e quindi mette il dito sul loro piatto facendoli pesare un po' di più.

Così - sempre se la memoria non mi inganna - alcuni termini si allungano, alcune prove che dovrebbero essere date da chi deve ricevere la prestazione diventano prove a carico di chi deve adempiere e così via.

Ma la schifezza da cui partono i due percorsi, quello normale è quello per il consumatore, è sempre la stessa.

Bisognerebbe comunque guardarsi un manuale aggiornato sulle obbligazioni perchè fidarsi di quel che mi ricordo è un azzardo.

[homero]

ho appena sentito alla televisione che la toyota ha ritirato 400.000 autovetture per un problema software che gestisce l'impianto frenante. che fallisce a basse temperature di esercizio!
quanto si dice la correttezza di una fabbrica...

[gugoXX]

Originariamente inviato da homero

ho appena sentito alla televisione che la toyota ha ritirato 400.000 autovetture per un problema software che gestisce l'impianto frenante. che fallisce a basse temperature di esercizio!
quanto si dice la correttezza di una fabbrica...

Ne ho sentite tante, ho scritto tanti test e ho corretto tanti bachi. Ma un software che fallisce a basse temperature non l'avevo ancora sentita!

[tomminno]

Originariamente inviato da gugoXX

Ne ho sentite tante, ho scritto tanti test e ho corretto tanti bachi. Ma un software che fallisce a basse temperature non l'avevo ancora sentita!

Hai mai lavorato in ambiente embedded?
Se a basse temperature l'hardware fa cilecca il software può fare veramente poco. Metti che alle basse temperature il sensore che rileva un movimento si perde per strada qualche campione oppure che l'errore di misura cresce a dismisura, il software lavora su quello che gli dice il sensore, se gli viene detto qualcosa di sbagliato... Puoi provare a filtrare quanto ti pare, ma se la condizione è persistente l'errore è inevitabile.
Generalmente capita che a basse temperature le prestazioni dell'hardware diminuiscano (cpu più lente, sensori meno affidabili,...) e in sistemi real-time questo può comportare il non rispetto delle specifiche ergo calcoli errati.

Nel caso in questione però i componenti elettronici delle auto più spesso sono della bosch, se la colpa è effettivamente della Toyota più probabilmente è colpa un assemblaggio/posizionamento errato.

[gugoXX]

Originariamente inviato da tomminno

Hai mai lavorato in ambiente embedded?
Se a basse temperature l'hardware fa cilecca il software può fare veramente poco. Metti che alle basse temperature il sensore che rileva un movimento si perde per strada qualche campione oppure che l'errore di misura cresce a dismisura, il software lavora su quello che gli dice il sensore, se gli viene detto qualcosa di sbagliato... Puoi provare a filtrare quanto ti pare, ma se la condizione è persistente l'errore è inevitabile.
Generalmente capita che a basse temperature le prestazioni dell'hardware diminuiscano (cpu più lente, sensori meno affidabili,...) e in sistemi real-time questo può comportare il non rispetto delle specifiche ergo calcoli errati.

Nel caso in questione però i componenti elettronici delle auto più spesso sono della bosch, se la colpa è effettivamente della Toyota più probabilmente è colpa un assemblaggio/posizionamento errato.

???
E' una situazione normalissima. Ho lavorato anche in applicazioni spazio...
Ma in questo e nel mio caso si parla di problema hardware, non software.
Un software e' un sistema logico. Che un baco possa spuntare perche' c'e' una bassa temperatura e' illogico, a meno che la temperatura sia uno dei parametri del software (e quindi sbaglierebbe non per la bassa temperatura, ma per un presunto errore di elaborazione di quello specifico dato. Avrebbe potuto sbagliare analogamente ad alte temperature, o a temperature normali)

[tomminno]

Originariamente inviato da gugoXX

???
E' una situazione normalissima. Ho lavorato anche in applicazioni spazio...
Ma in questo e nel mio caso si parla di problema hardware, non software.
Un software e' un sistema logico. Che un baco possa spuntare perche' c'e' una bassa temperatura e' illogico, a meno che la temperatura sia uno dei parametri del software (e quindi sbaglierebbe non per la bassa temperatura, ma per un presunto errore di elaborazione di quello specifico dato. Avrebbe potuto sbagliare analogamente ad alte temperature, o a temperature normali)

Quindi non hai mai visto un firmware installato su un prototipo dare risultati completamente sbagliati a causa di saldature volanti?
Oppure memorie che cominciano a rispondere al di fuori dei tempi previsti dalle specifiche per cui i dati recuperati dal programma non sono quelli corretti?
Nei test a -40C spesso se ne vedono di cose strane e più spesso sono problemi hardware che causano bug software, dato che generalmente in tali software ci sono vincoli temporali da rispettare, per cui anche il solo fatto di non avere il risultato nei tempi previsti è un errore.
Se devi fare 100 moltiplicazioni al minuto e a -40 in un minuto ne riesci a fare 90 perchè la cpu va più piano cosa puoi fare lato software?
Volendo puoi vederlo anche come bug software che non gestisce correttamente tale situazione.

[gugoXX]

Originariamente inviato da tomminno

Quindi non hai mai visto un firmware installato su un prototipo dare risultati completamente sbagliati a causa di saldature volanti?
Oppure memorie che cominciano a rispondere al di fuori dei tempi previsti dalle specifiche per cui i dati recuperati dal programma non sono quelli corretti?
Nei test a -40C spesso se ne vedono di cose strane e più spesso sono problemi hardware che causano bug software, dato che generalmente in tali software ci sono vincoli temporali da rispettare, per cui anche il solo fatto di non avere il risultato nei tempi previsti è un errore.
Se devi fare 100 moltiplicazioni al minuto e a -40 in un minuto ne riesci a fare 90 perchè la cpu va più piano cosa puoi fare lato software?
Volendo puoi vederlo anche come bug software che non gestisce correttamente tale situazione.

Cerco di spiegarmi.
C'e' la Bosch, che e' molto probabilmente divisa in dipartimenti software e dipartimenti hardware.
La Toyota ha deciso che vuole fare saltare una testa a causa del problema.
Il direttore di quale dipartimento saltera'? Quello software o quello hardware?
Ovvero, e' un problema del software o un problema dell'hardware perche' e' stato pensato, progettato o testato male?

[CozzaAmara]

Originariamente inviato da gugoXX

???
E' una situazione normalissima. Ho lavorato anche in applicazioni spazio...
Ma in questo e nel mio caso si parla di problema hardware, non software.
Un software e' un sistema logico. Che un baco possa spuntare perche' c'e' una bassa temperatura e' illogico, a meno che la temperatura sia uno dei parametri del software (e quindi sbaglierebbe non per la bassa temperatura, ma per un presunto errore di elaborazione di quello specifico dato. Avrebbe potuto sbagliare analogamente ad alte temperature, o a temperature normali)

Infatti in quel caso comunque, credo, l'"errore" stia nell'hardware e non nel software.
Quest'ultimo processa i dati che gli vengono passati, che poi questi siano giusti o sbagliati al software frega nulla.

[fero86]

Originariamente inviato da tomminno

Quindi non hai mai visto un firmware installato su un prototipo dare risultati completamente sbagliati a causa di saldature volanti?

questo ragazzo non capisce eh?

[tomminno]

Originariamente inviato da fero86

questo ragazzo non capisce eh?

Oh grande illuminato spiegami se una alu in determinate circostanze dice che 2+2=5 e il software agisce di conseguenza, il bug è software o hardware?

if (2+2==4)
    blocca ruote;
else
    schiantati nel muro;

[tomminno]

Originariamente inviato da gugoXX

La Toyota ha deciso che vuole fare saltare una testa a causa del problema.
Il direttore di quale dipartimento saltera'? Quello software o quello hardware?

Più probabilmente software visto che l'hardware è stratestato.
Oppure salta il responsabile della progettazione del pianale perchè ha posizionato la centralina sopra la testata del motore.

Ovvero, e' un problema del software o un problema dell'hardware perche' e' stato pensato, progettato o testato male?

Dei 2 scommetteri sul software o meglio sui dati preimpostati nel software, dato che l'hardware a meno di smentite funziona regolarmente su decine di milioni di automobili di marche diverse e della stessa marca.

Cioè software e hardware funzionano perfettamente ma non nelle condizioni a contorno che si verificano nella vettura di produzione e non sul banco test (e sicuramente non si sono verificate in tutti i test su strada che sono stati fatti prima della messa in vendita).

[fero86]

Originariamente inviato da tomminno

Oh grande illuminato spiegami se una alu in determinate circostanze dice che 2+2=5 e il software agisce di conseguenza, il bug è software o hardware?

if (2+2==4)
    blocca ruote;
else
    schiantati nel muro;

suppergiu direi hardware, quindi un caso diverso da quello delle Toyota, nelle quali il problema era software (cosi é stato detto).

[fero86]

Originariamente inviato da tomminno

Più probabilmente software visto che l'hardware è stratestato.

[...]


Dei 2 scommetteri sul software o meglio sui dati preimpostati nel software, dato che l'hardware a meno di smentite funziona regolarmente su decine di milioni di automobili di marche diverse e della stessa marca.

bel tentativo, e in effetti ci hai azzeccato; ma la risposta era molto piu semplice: software, perché é giá stato detto al post #26

[cdimauro]

Originariamente inviato da tomminno

Oh grande illuminato spiegami se una alu in determinate circostanze dice che 2+2=5 e il software agisce di conseguenza, il bug è software o hardware?

if (2+2==4)
    blocca ruote;
else
    schiantati nel muro;

In questo caso senza dubbio il problema è dell'hardware. Se l'hardware sbaglia, è chiaro che l'errore viene propagato anche al software, ma la causa del problema non è certo sua.

Tant'è che per risolvere il tutto non hai bisogno di fixare alcunché nel software, ma soltanto nell'hardware.

[gugoXX]

Originariamente inviato da cdimauro

Tant'è che per risolvere il tutto non hai bisogno di fixare alcunché nel software, ma soltanto nell'hardware.

*

Originariamente inviato da tomminno

Oh grande illuminato spiegami se una alu in determinate circostanze dice che 2+2=5 e il software agisce di conseguenza, il bug è software o hardware?

if (2+2==4)
    blocca ruote;
else
    schiantati nel muro;

A parte che sei decisamente fastidiosio a leggersi,
se una ALU sbaglia, l'errore e' hardware. Hardware e non software.
Limitatamente, circostanzialmente ed esclusivamente hardware.

Il fatto che le ALU in particolare, come tutti i microcircuti in generale, vengano progettati con software scritti tipicamente in VHDL, non fa dello sviluppatore uno sviluppatore di software. Non e' software. Sempre hardware e', sempre hardwarista sara'.

[tomminno]

Originariamente inviato da gugoXX

A parte che sei decisamente fastidiosio a leggersi,

Dato che non era rivolto a te il discorso fastidioso, puoi pure ignorarlo.

se una ALU sbaglia, l'errore e' hardware. Hardware e non software.
Limitatamente, circostanzialmente ed esclusivamente hardware.

E tra i problemi dell'hardware ci può essere anche la bassa temperatura d'esercizio che comporta poi di conseguenza errori nell'esecuzione del software.
Quindi devo capire come fai a dire:

Ma un software che fallisce a basse temperature non l'avevo ancora sentita!

quando un fallimento dell'hardware comporta anche (o può comportare) il fallimento del software.