View Full Version : dati alterati a causa di un bugs è possibile fare causa?
Sto lavarando a progetto di aggiornamento software presso un CED basato integralmente su software prodotto da una nota multinazionale.
Nell'evoluzione del software il produttore ha consigliato un upgrade a nuovi sistemi di gestione, invogliando l'azienda a scalare verso le nuove applicazioni.
Hanno acquistato per diverse migliaia di euro i vari pacchetti di aggiornamento, ma ora qui ora li', sembra che i bugs e i problemi di compatibilità siano aumentati rispetto al vecchio sistema invece che risolverli.
E' possibile fare causa alla ditta produttrice per aver rilasciato un software che difatto sta rallentando il lavoro dell'azienda ed è costato parecchi soldi?
insomma è possibile che le aziende che producono software non siano responsabili di quello che producono?
se compro un'auto e questa è difettosa ed a causa del difetto di fabbrica faccio un incidente la casa produttrice mi risarcisce, ma qui chi risarcisce del tempo e dei soldi spesi?
Non entro nello specifico perche' vorrei focalizzare il problema sulle garanzie di efficenza e produttività del software che acquistiamo.
Master_T
08-02-2010, 10:39
Beh, devi vedere cosa ti garantisce la licenza e cosa no... se sulla licenza c'e' scritto che non si prendono responsabilita' per queste cose e voi avete cliccato il classico "I agree", magari senza leggerla... :read:
dubito che tu possa rivalerti ... se nell'eula era espressa chiaramente una limitazione di responsabilità (legata ad es ai danni causati da bachi) e voi l'avete accettata non penso ci sia molto da fare ... potrebbe essere considerata una clausola vessatoria (e quindi per essere valida deve essere sottoscritta espressamente) ma qui mi fermo, perchè i miei ricordi giurisprudenziali sono molto annebbiati :)
ho visto il contratto di licenza ma per capirlo serve un avvocato specializzato,
resta il fatto che se il software fosse come l'automobile dovrebbero riprendersi il pacchetto completo indietro....
è una vergogna!
non credete a quello che dicono le software house o gli "evangelist" anche se sono multinazionali, chiedete un periodo di prova di 30 giorni minimo delle loro soluzioni e prima di comprare leggete attentamente il contratto di licenza...
E' l'unico modo di tutelarsi...
adesso 8000 euro circa di licenza e problemi aumentati...
ci hanno proposto per telefono un contratto di assistenza da 1500 euro anno...
ma siamo sicuri che con questo contratto le cose funzioneranno? io non credo...
CozzaAmara
08-02-2010, 14:11
Di base avresti ragione ma con un'automobile (se difettosa) non è che tu puoi creare una copia di backup della tua vita, con i software invece non c'è alcun problema.
La cosa più semplice da fare in questi casi è ripristinare il vecchio sistema funzionante con i dati che SICURAMENTE avrete backuppato (se andati persi durante l'upgrade) ed infine faculizzare l'azienda produttrice del software che avrà perso un cliente e si sarà fatta pubblicità negativa.
In soldoni: di solito le licenze per il software prevedono sempre che l'azienda che rilascia il prodotto non si assume responsabilità circa la perdita di dati, potrebbe avvenire diversamente con clausole ad hoc ma sicuramente i costi lieviterebbero esponenzialmente per l'acquirente.
yorkeiser
08-02-2010, 14:51
Aggiungo che un software è generalmente un sistema molto più complesso rispetto ad un'automobile, dubito che qualsiasi azienda ti garantirebbe l'assenza di bachi nel proprio sw, a meno che non cerchi volontariamente il suicidio economico.
Aggiungo che un software è generalmente un sistema molto più complesso rispetto ad un'automobile, dubito che qualsiasi azienda ti garantirebbe l'assenza di bachi nel proprio sw, a meno che non cerchi volontariamente il suicidio economico. che sia piu complesso da produrre non credo, ma sicuramente é molto piu complesso da testare, ed é questo il problema.
yorkeiser
08-02-2010, 19:30
che sia piu complesso da produrre non credo, ma sicuramente é molto piu complesso da testare, ed é questo il problema.
Non intendo da produrre, è ovvio che un sistema "tangibile" è più difficile e costoso da produrre, tanto più che si ha bisogno di tutta l'infrastruttura adatta, mentre per un software bastano un pc, un compilatore e al massimo qualche utility.
Intendo la complessità di funzionamento: un software ha svariati input, output e una quantità praticamente infinita di potenziali stati interni che ne governano il funzionamento.
Un'automobile ha meno input (pedali, cambio e sterzo in sostanza) ed ha un comportamento interno molto più lineare: ad esempio il motore, semplificando di molto, succhia benzina e trasmette la rotazione alle ruote, ma non può andare in loop, non può avere incompatibilità con una determinata scheda, non può dividere per zero, non può riempire lo stack, ed in generale non può avere comportamenti non previsti (a meno, ovviamente, di guasti),
Questo non vuol dire ovviamente che un'automobile sia un sistema meno sofisticato, ma è soltanto più semplice (e da qui deriva, giustamente, la maggior difficoltà nel test del sw).
Aggiungo che un software è generalmente un sistema molto più complesso rispetto ad un'automobile, dubito che qualsiasi azienda ti garantirebbe l'assenza di bachi nel proprio sw, a meno che non cerchi volontariamente il suicidio economico.
Ma anche no..
Hai idea della quantità di progetti che ci sono dietro ad un'automobile? A partire dal motore ( senza considerare le innumerevoli parti meccaniche in movimento), passando per il telaio e via dicendo..
Senza contare che le stesse automobili contengono svariati software..
Il problema dei bug è dato principalmente dalle scadenze che le software house devono rispettare, che spesso ti impongono di mettere sul mercato un software non opportunamente testato, ovviamente partendo dal presupposto che i programmatori che ci lavorano non siano degli sprovveduti
tomminno
08-02-2010, 19:59
Non intendo da produrre, è ovvio che un sistema "tangibile" è più difficile e costoso da produrre, tanto più che si ha bisogno di tutta l'infrastruttura adatta, mentre per un software bastano un pc, un compilatore e al massimo qualche utility.
Intendo la complessità di funzionamento: un software ha svariati input, output e una quantità praticamente infinita di potenziali stati interni che ne governano il funzionamento.
Un'automobile ha meno input (pedali, cambio e sterzo in sostanza) ed ha un comportamento interno molto più lineare: ad esempio il motore, semplificando di molto, succhia benzina e trasmette la rotazione alle ruote, ma non può andare in loop, non può avere incompatibilità con una determinata scheda, non può dividere per zero, non può riempire lo stack, ed in generale non può avere comportamenti non previsti (a meno, ovviamente, di guasti),
Questo non vuol dire ovviamente che un'automobile sia un sistema meno sofisticato, ma è soltanto più semplice (e da qui deriva, giustamente, la maggior difficoltà nel test del sw).
Oddio se pensi a quanto possano essere complicate le centraline elettroniche di una automobile...
L'automobile ha anche un software al suo interno, software che analizza costantemente i dati provenineti dagli innumerevoli sensori sparsi per tutta l'auto: ABS,ESB, ammortizzatori elettronici, sonda lambra, anticipo, minimo...
Il tutto deve essere gestito in real time, con temperature di esercizio e condizioni ambientali più disparate e con una potenza di calcolo che non è certo quella di un comune pc.
Le macchine di oggi ti possono piantare in asso senza avere alcun problema meccanico.
wingman87
08-02-2010, 20:05
Diciamo che non si può generalizzare in nessun senso, esistono indubbiamente sistemi software più complessi di un'automobile ma non è la norma
cdimauro
08-02-2010, 20:47
Ma anche no..
Hai idea della quantità di progetti che ci sono dietro ad un'automobile? A partire dal motore ( senza considerare le innumerevoli parti meccaniche in movimento), passando per il telaio e via dicendo..
Senza contare che le stesse automobili contengono svariati software..
Il problema dei bug è dato principalmente dalle scadenze che le software house devono rispettare, che spesso ti impongono di mettere sul mercato un software non opportunamente testato, ovviamente partendo dal presupposto che i programmatori che ci lavorano non siano degli sprovveduti
Anche con tutta la buona volontà e una buona batteria di test, non puoi garantire che il tuo software sarà privo di bug.
Software complessi sono altrettanto complessi da testare. Più aumenta la loro complessità, più è facile che nascondano dei bug, empiricamente parlando.
Oddio se pensi a quanto possano essere complicate le centraline elettroniche di una automobile...
L'automobile ha anche un software al suo interno, software che analizza costantemente i dati provenineti dagli innumerevoli sensori sparsi per tutta l'auto: ABS,ESB, ammortizzatori elettronici, sonda lambra, anticipo, minimo...
Il tutto deve essere gestito in real time, con temperature di esercizio e condizioni ambientali più disparate e con una potenza di calcolo che non è certo quella di un comune pc.
Le macchine di oggi ti possono piantare in asso senza avere alcun problema meccanico.
Sì, ma sempre per problemi... software. :p
Anche con tutta la buona volontà e una buona batteria di test, non puoi garantire che il tuo software sarà privo di bug.
Certamente, ma meno tempo si ha a disposizione per testarlo e peggio è. Sono innumerevoli i casi di software immessi sul mercato pieni di bug in quanto immaturi, solo per rispettare le scadenze.
Anche con tutta la buona volontà e una buona batteria di test, non puoi garantire che il tuo software sarà privo di bug. ciononostante c'é ancora qualcuno che lo fa: http://www2.mandriva.com/
"semplice, sicuro, stabile, veloce, bello, nessun virus, nessun crash, nessuno spreco di tempo, nessuno spyware".
"stabile" e "nessun crash" sono semplicemente false, ma anche "nessun virus" e "nessuno spyware" sono piuttosto scorrette nei confronti dell'utente ignorante: cosa aspettano, che lo programmi io un virus per Mandriva? perché non lo facciamo nel prossimo contest di programmazione? a che contest eravamo arrivati, 16? 17?
per non parlare di tutte le altre che ho citato che sono quantomeno soggettive.
cioé, non so voi ma quelle pesanti affermazioni messe li cosi, in bella vista e a caratteri cubitali sulla loro home, mi lasciano veramente scandalizzato; o sono state scritte da gente veramente ignorante (non i programmatori del team spero) oppure avevano intenzione di prendere per i fondelli un tipico utente che (giustamente) non ne capisce nulla, la qual cosa mi pare molto scorretta.
buh per Mandriva.
cdimauro
09-02-2010, 04:47
Certamente, ma meno tempo si ha a disposizione per testarlo e peggio è. Sono innumerevoli i casi di software immessi sul mercato pieni di bug in quanto immaturi, solo per rispettare le scadenze.
Non lo metto in dubbio.
ciononostante c'é ancora qualcuno che lo fa: http://www2.mandriva.com/
"semplice, sicuro, stabile, veloce, bello, nessun virus, nessun crash, nessuno spreco di tempo, nessuno spyware".
"stabile" e "nessun crash" sono semplicemente false, ma anche "nessun virus" e "nessuno spyware" sono piuttosto scorrette nei confronti dell'utente ignorante: cosa aspettano, che lo programmi io un virus per Mandriva? perché non lo facciamo nel prossimo contest di programmazione? a che contest eravamo arrivati, 16? 17?
per non parlare di tutte le altre che ho citato che sono quantomeno soggettive.
cioé, non so voi ma quelle pesanti affermazioni messe li cosi, in bella vista e a caratteri cubitali sulla loro home, mi lasciano veramente scandalizzato; o sono state scritte da gente veramente ignorante (non i programmatori del team spero) oppure avevano intenzione di prendere per i fondelli un tipico utente che (giustamente) non ne capisce nulla, la qual cosa mi pare molto scorretta.
buh per Mandriva.
Lo è sicuramente. Ma i markettari devono vendere, per cui non mi meravigliano queste sparate. :D
infatti!!
ti dicono che il soft è compatibile con i formati xxx e yyy, supporta standard zzzz e poi invece il formato xxx viene supportato per tutte le funzioni eccetto quella presente nei tuoi documenti (e vieni a sapèrlo soltanto dopo) e lo standard zzzz è solo dalla versione 1.5 mentre in giro c'e' già la 7.0
questo oltre i normali bugs...
quindi è necessario leggere il contratto di licenza prima e chiedere un periodo di prova del software in caso contrario rinunciate senza riserve se non volete pagarne le conseguenze...
8000 mila euro buttati ma il guaio che i problemi sono aumentati!!!
magari fossero stati soltanto soldi buttati!
non so di che software tu stia parlando ma in giro si trova tanta di quella roba open source che e quasi impossibile non trovare qualcosa per ogni esigenza , certo non senza difficolta ma pagando un team di sviluppo si puo estendere un software open source a seconda delle proprie esigenze , e si spende di meno e si ha un software più affidabile ( beh dipende anche da chi lo sviluppa ).
Ma i manager purtroppo non ci arrivano ... preferiscono software a pagamento in cambio di una "certificazione" o assistenza ( sul installazione ovviamente ).
non so di che software tu stia parlando ma in giro si trova tanta di quella roba open source che e quasi impossibile non trovare qualcosa per ogni esigenza , certo non senza difficolta ma pagando un team di sviluppo si puo estendere un software open source a seconda delle proprie esigenze , e si spende di meno e si ha un software più affidabile ( beh dipende anche da chi lo sviluppa ).
Ma i manager purtroppo non ci arrivano ... preferiscono software a pagamento in cambio di una "certificazione" o assistenza ( sul installazione ovviamente ).
con 8000€ che team di sviluppo puoi permetterti?
forse un paio di persone per un paio di settimane, neanche il tempo di spiegargli che modifiche ti servono :)
con 8000€ che team di sviluppo puoi permetterti?
forse un paio di persone per un paio di settimane, neanche il tempo di spiegargli che modifiche ti servono :)
8000€ di software , chi sa quanti € di danno , un bel pò per ripristinare il tutto , il tempo perso di chi ci ha lavorato , e anche lo stress e diservizi verso utenti ed ecco che i conti tornano.
Certo bisogna vedere di che tipo di software stiamo parlando ... certo se ti rivolgi an un azienda molto grande 8000€ te li tolgono solo per pagare "la burocrazia" ( per un paio di giorni ) .
8000€ di software , chi sa quanti € di danno , un bel pò per ripristinare il tutto , il tempo perso di chi ci ha lavorato , e anche lo stress e diservizi verso utenti ed ecco che i conti tornano.
Certo bisogna vedere di che tipo di software stiamo parlando ... certo se ti rivolgi an un azienda molto grande 8000€ te li tolgono solo per pagare "la burocrazia" ( per un paio di giorni ) .
chiaro dipende sempre tutto da costi / necessità!
se puoi tenere il lavoro fermo mezza giornata spenderai tot..
se hai bisogno di uptime al 100% con dati certi e sicuri...le cifre sono decisamente altre.
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.
Lo è sicuramente. Ma i markettari devono vendere, per cui non mi meravigliano queste sparate. :D 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.
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.
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) ?
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.
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...
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
10-02-2010, 09:15
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.
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
10-02-2010, 10:33
???
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.
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
10-02-2010, 12:08
???
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.
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? :asd:
tomminno
10-02-2010, 23:48
questo ragazzo non capisce eh? :asd:
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
10-02-2010, 23:51
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).
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).
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 :asd:
cdimauro
11-02-2010, 05:33
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.
Tant'è che per risolvere il tutto non hai bisogno di fixare alcunché nel software, ma soltanto nell'hardware.
*
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
11-02-2010, 09:49
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.
Dato che non era rivolto a te il discorso fastidioso, puoi pure ignorarlo.
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:
quando un fallimento dell'hardware comporta anche (o può comportare) il fallimento del software.
Non e' un problema del software.
Il software e' stato fatto come si comanda, probabilmente come richiesto e come previsto. e peraltro non si deve cambiare, e non si deve e con tutta probabilita' non si puo' neppure agire a livello sofware per correggere il problema.
Perche' ci si deve ostinare a dire che debba essere un errore software?
Imipicchiamo il progettista meccanico dei freni allora, perche' sono stati i freni comunque a fallire.
Oppure facciamo che dare la colpa al carrozziere. D'altronde se l'auto si e' schiantata e la carrozzeria si e' rotta, la colpa e' anche sua.
Forse che io, progettista software in ambito bancario posso essere additato come imputato per un problema in un sofware che ho fatto perche' la macchina a basse temperature sbaglia a fare le somme, e il mio software ha fatto perdere milioni?
Io? Ma cosa ci posso fare io? Quale responsabilita' mi si vorrebbe mai imputare? :boh:
Insomma, se la frase originaria fosse stata:
ho appena sentito alla televisione che la toyota ha ritirato 400.000 autovetture per un problema HARDWARE che gestisce l'impianto frenante. che fallisce a basse temperature di esercizio!
Nessuno avrebbe avuto niente da ridire. L'hardware ha dato segnali sbagliati al livello superiore, l'hardware e' responsabile, il problema e' hardware.
Quindi devo capire come fai a dire:
quando un fallimento dell'hardware comporta anche (o può comportare) il fallimento del software. tomminno, inizialmente credevo che tu avessi solamente letto male il post #26; leggendo qui invece capisco che c'é un problema di altra natura :asd:
fidati, da come é stato posto il discorso l'hardware di quelle automobili non aveva il minimo problema neanche in condizioni estreme :)
dal momento che é stato detto che il problema era nel software posso immaginare che il software sbagliasse i calcoli quando arrivavano determinati input da qualche termometro; integer overflow?
chinookAT85LSAURO
11-02-2010, 18:47
Di solito nelle condizioni è specificato che non ci si assume la resp, ma è chi lo vende (e di solito fa assistenza) che poi cmq mette tutto apposto senza spese e pratica degli sconti per future implementazioni per scusarsi del danno... Altrimenti si perde un cliente...
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.