Perchè la qualità SW si dice che sia contestuale ... non è vero per la qualità di qualcosa?

Sembra che l'autore stia cercando di comunicare che la "qualità" di un prodotto software è spesso più legata alle percezioni e alle aspettative degli utenti finali, e non a qualche attributo quantificabile che è possibile applicare ad esso (ad esempio, gli standard di codifica , standard di progettazione, standard di sicurezza, ecc.) o le percezioni dei suoi creatori.

Ad esempio - uno sviluppatore competente indicherà un codice antico che è stato trasformato in una "grande palla di fango", scritto in un linguaggio obsoleto, viola ogni principio del design moderno, è straripante (gioco di parole non previsto) con difetti di sicurezza e backdoor, ed è fragile per gli ingegneri di manutenzione, e ha un'interfaccia utente complicata diabolicamente ostile, e dice "Questo software è terribile!".

Tuttavia, lo stesso bit del software agli occhi degli utenti finali potrebbe fare tutto ciò di cui gli utenti hanno bisogno o che si aspettano che faccia. Questi utenti non "vedranno" l'orrendo codice base sottostante, e gli eventuali difetti che appaiono possono spesso essere modificati in un modo o nell'altro.

Agli occhi degli utenti esperti di tale software (e in particolare delle persone che possiedono i diritti di utilizzo del software e potrebbero averne pagato milioni per il suo sviluppo / manutenzione per molti decenni), se è considerato "abbastanza buono" e " abbastanza stabile "e" fa il lavoro che è destinato a fare ", quindi spesso guadagnerà un grande timbro di gomma nella scatola di qualità.

Questa prospettiva non è unica per il software, anche se è più comunemente presente nel software perché ci sono milioni di aziende nel mondo che fanno ancora affidamento su software costruito decenni fa; e il loro giudizio sulla "qualità" tende ad essere - "Ci fa guadagnare più denaro di quello che ci costa? (e / o ci costerebbe sostituirlo)" e "Conserva la nostra reputazione in buona salute? "

Potresti applicare questo ad altri domini? Forse, ma è molto meno comune con "cose" che sono tangibili, che possono essere raccolte e tenute in mano ed esistono "nel mondo reale" - in particolare dove le cose fisiche / meccaniche tendono a decadere e svanire tempo (ad esempio, le automobili hanno un chilometraggio, le cose meccaniche si logorano, le cose vengono danneggiate da utenti troppo zelanti, ecc. - il software non ne risente!)

Quindi, a parte il fatto che il codice non "decaduta" (tranne che per negligenza da parte di ingegneri del software), i meccanismi interni del software sono così opachi, e gli utenti sono così lontani da loro, che la "qualità" di il codice, insieme ai difetti di sicurezza, i problemi di usabilità e gli oscuri bug / difetti tendono ad essere quasi invisibili all'utente medio.

Nella sezione citata non c'è niente che indica che solo la qualità del software dipende dal contesto. Dato che il libro riguarda la qualità del software, è logico che occorra sui componenti software anziché sui componenti hardware e sulla qualità del software anziché sulla qualità dell'hardware.

Ci sono due aspetti da considerare.

Innanzitutto, considera come misurare la qualità.

Con oggetti fisici, puoi applicare le regole della chimica e della fisica. Puoi realizzare modelli altamente dettagliati ed eseguire simulazioni basate su computer per la progettazione di cose fisiche. Quindi, dopo la produzione, è possibile prelevare campioni ed eseguire test (compresi test distruttivi che soddisfano o superano le caratteristiche desiderate).

Con il software, è possibile scrivere codice di prova e procedure di test manuali per eseguire varie porzioni del software, ma i risultati dei test sono buoni come i casi di test. Esistono diverse misure e metriche relative alla qualità dei processi e dei prodotti, ma nessuna è esatta.

Successivamente, considera ciò che puoi fare con la tua misura della qualità.

Con articoli fisici, puoi caratterizzare i limiti del prodotto. Sapete che il vostro widget può accelerare così velocemente o tenere così tanto peso ad un certo angolo o raggiungere una certa temperatura prima che non funzioni più. È possibile descrivere non solo l'ambiente o gli ambienti in cui è stato testato il componente, ma l'ambiente in cui si è certi che il widget sarà in grado di svolgere il proprio lavoro.

Con il software, l'ambiente ha molte variabili. Non è sempre possibile controllare il sistema operativo, le librerie di terze parti e le versioni del pacchetto software, la velocità del processore, la memoria, la scheda grafica, lo spazio e la velocità del disco, la latenza della rete, il carico dell'utente e così via. È possibile specificare eventuali requisiti o dipendenze, ma gli utenti possono utilizzare il software in modi imprevisti o l'ambiente potrebbe essere degradato o configurato male. Usarlo al di fuori dell'ambiente in cui è stato testato può portare a scoprire problemi con il software. Il tuo software può avere un elevato livello di qualità integrato nel processo, ma la sua distribuzione in ambienti diversi può comportare una differenza nella qualità percepita.

Non penso sia specifico per il software. Ho un'ascia nel garage, e la sua qualità varia molto a seconda che la stia usando per spaccare legna da ardere (qualità ok), come fermacarte (ottima qualità) o per rimuovere neve e ghiaccio dal parabrezza della mia auto (molto bassa qualità, rimuove tanto vetro quanto ghiaccio)