Qualità del software: differenze tra le versioni

Contenuto cancellato Contenuto aggiunto
Nessun oggetto della modifica
Riga 14:
====Affidabilità====
{{vedi anche|affidabilità}}
Un sistema è tanto più '''affidabile''' quanto più raramente, durante l'uso del sistema, si manifestano malfunzionamenti. Una definizione più specifica, ma non universalmente riconosciuta, è basata sul concetto di [[MTBF]] (''Mean Time Between Failure'', il tempo medio che intercorre fra due fallimenti successivi). In termini invece più vaghi (ma probabilmente più significativi), si può anche dire che l'affidabilità è la misura in cui l'utente può "fidarsi" del software; questa definizione tiene conto, in particolare, del fatto che malfunzionamenti ''gravi'' si considerano solitamente più influenti, nella valutazione dell'affidabilità, di errori minori. In questo senso, il modo in cui si intende il termine affidabilità può variare in funzione del tipo di utente (per esempio della sua capacità di adattarsi) e del tipo di applicazione (per esempio in funzione della sua [[criticità]]).
Misura quanto l’utente può far affidamento sul software.
 
Poiché l'affidabilità è concettualmente misurabile (una volta specificato un particolare modello, per esempio MTBF o una variante pesata in funzione della gravità dei fallimenti), questo parametro viene spesso considerato la controparte "realistica" della correttezza.
È frequente oggi rilasciare software con malfunzionamenti per le prime versioni (''software bacato''). Ciò mostra chiaramente come il software sia ben lontano da altri prodotti ingegneristici perché un’auto, ad esempio, non si rilascia con dei malfunzionamenti, mentre se ciò avviene nel software questi sono accettati con rassegnazione.
 
L'[[industria del software]] moderna, su applicazioni non critiche, tende a considerare tende a considerare economicamente vantaggioso il rilascio di prodotti con un tasso iniziale di malfunzionamenti piuttosto elevato, ma dotati di meccanismi di caricamento periodico di ''[[patch]]'' (per esempio via [[Internet]]) attraverso cui gli errori vengono corretti via via che vengono trovati dall'utenza e segnalati al produttore.
Quindi per il software si hanno:
* aspettative minori
* known [[bug|bugs]] (falle note)
 
Solitamente l’affidabilità è definita in termini di [[mtbf]] ('''M'''ean '''T'''ime '''B'''etween '''F'''ailures).
Tuttavia il mtbf è normalmente associato a malfunzionamenti di natura casuale e mal si adatta al software che è affetto esclusivamente da malfunzionamenti di natura sistematica (errori di progettazione). Risulta quindi estremamente difficile quantificare l'affidabilità del software.
Un approccio comune è quello di sostituire la misura quantitativa con una qualitativa (es: Livello di Integrità del Software).
 
====Correttezza Vs affidabilità====
La correttezza è una qualità assoluta, mentre l’affidabilità è una qualità relativa. <br/>
Se un sistema presenta degli errori
* non è corretto
* potrebbe essere però affidabile
Se la specifica cattura tutti i requisiti un sistema corretto è affidabile.
Se la specifica '''non''' cattura i requisiti un sistema corretto potrebbe non essere affidabile.
 
====Robustezza====
{{vedi anche|robustezza}}
Un sistema è robusto se si comporta in modo ragionevole in situazioni impreviste. Ad esempio quando vengono inseriti dati di input non corretti.
In termini generali, la '''robustezza''' di un sistema è la misura in cui il sistema si comporta in modo ''ragionevole'' in situazioni impreviste, non contemplate dalle specifiche. Situazioni di questo tipo in genere riguardano errori ed eccezioni di varia natura (dati di input scorretti, fallimenti di componenti software o hardware esterni al sistema e interagenti con esso, e così via). Anche in questo caso, l'idea intuitiva della robustezza implica certamente considerazioni di valore sugli effetti dannosi che il sistema o l'utente subiscono se il sistema reagisce in modo "irragionevole" a situazioni impreviste.
La robustezza può essere corretta andando a colmare quelle [[lacune]] dei requisiti che appunto non hanno descritto il comportamento nel caso di situazioni anomale.
La robustezza è difficilmente definibile formalmente. Se si potesse definire il concetto di comportamento ragionevole si potrebbe dire che la ''robustezza'' è uguale alla ''correttezza''. Infatti se un requisito è nelle [[specifiche]] allora fa parte della correttezza, se è fuori allora fa parte della robustezza.
 
La robustezza comunque dipende dal contesto e non è assoluta, in particolare dipende da:
* chi usa il sistema
* quali sono le sue capacità di adattamento
* quanto è critico il buon funzionamento del software
 
====Efficienza e Prestazioni====
Un sistema è efficiente se usa le risorse ([[memoria]], [[CPU]],...) in modo efficiente, ossia senza sprechi.
Si confonde spesso l’''efficienza'' con le ''prestazioni'', ma mentre la prima è una caratteristica interna che si riferisce al peso che un [[software]] ha sulle risorse del computer, la seconda è una caratteristica esterna, basata sui [[requisiti]].
 
Spesso viene presa in considerazione solo a sistema realizzato, ma può essere molto difficile intervenire a posteriori.
 
====Efficienza e Prestazioni====
Lo stesso accade anche per le prestazioni, che a volte possono anche rallentare la [[produttività]], tuttavia esse sono relative perché possono cambiare con l’evoluzione della tecnologia.
{{vedi anche|efficienza}}
Esistono diversi modi per misurare queste qualità:
Un sistema è '''efficiente''' se usa [[memoria]], [[CPU]] e altr risorse in modo proporzionato ai servizi che svolge, ovvero senza sprechi. Il termine '''prestazioni''' ha un significato correlato più specifico; le [[prestazioni]], infatti, sono da considerarsi come uno degli elementi che potrebbe essere specificato dai requisiti (si parla in questo caso di [[requisiti non funzionali]]). Efficienza e prestazioni sono difficilmente predicibili e quindi non raramente vengono prese in considerazione solo a sistema realizzato; tuttavia, gli interventi ''a posteriori'' per migliorare il comportamento del sistema rispetto a questi parametri sono spesso estremamente difficili e costosi. Fra i modelli utilizzato per misurare (o specificare) l'efficienza di un sistema si possono citare quelli basati sulla [[complessità algoritmica]], le misure sul campo, le misure su [[modello matematico|modelli matematici]] o modelli di [[simulazione]].
* complessità algoritmica
* misure sul campo delle caratteristiche (''measurement'')
* modello matematico da analizzare (''analysis'')
* modello di simulazione (''simulation'')
 
====[[Usabilità]]====