Qualità del software: differenze tra le versioni

Versione delle 15:06, 5 ott 2024

Versione attuale delle 16:12, 8 nov 2024

(Una versione intermedia di un altro utente non mostrate)

Riga 1:

{{F|ingegneria del software|aprile 2011}}

Per '''Qualitàqualità del software''' si intende la misura in cui un prodotto [[software]] soddisfa un certo numero di aspettative rispetto sia al suo funzionamento sia alla sua struttura interna. Gran parte della ricerca nel campo dell'[[ingegneria del software]] è dedicata, direttamente o indirettamente, al tema della qualità. In particolare, si è cercato di stabilire chiaramente cosa si intenda per qualità del software, definendo un insieme di '''parametri di qualità''' significativi; di realizzare tecniche per '''misurare tali parametri''' rispetto a un dato sistema software; di sviluppare tecnologie (per esempio [[linguaggio di programmazione|linguaggi di programmazione]]) e [[metodologia|metodologie]] (per esempio di [[analisi (ingegneria del software)|analisi]] e [[progettazione (ingegneria del software)|progettazione]]) che facilitino la realizzazione di software di qualità.

==Cos'è il software di qualità?==

===Classificazione dei parametri===

Tradizionalmente, i '''parametri''' (o '''fattori''') rispetto a cui si può misurare o definire la qualità del software vengono classificati in due famiglie: '''parametri esterni''' e '''parametri interni'''. I primi si riferiscono alla qualità del software così come è percepita dai suoi utenti, e includono correttezza, [[affidabilità]], [[robustezza (informatica)|robustezza]], [[efficienza (informatica)|efficienza]], [[usabilità]], [[ecocompatibilità]]. I secondi si riferiscono alla qualità del software così come è percepita dagli [[programmatore|sviluppatori]], e includono [[verificabilità]], [[manutenibilità]], [[riparabilità]], [[evolvibilità]], [[riusabilità]], [[portabilità]], [[leggibilità]], [[Modularità (informatica)|modularità]]. Generalmente esiste una correlazione fra questi due aspetti (banalizzando: il software ''mal scritto'' tende anche a ''funzionare male'').

===Parametri di qualità esterni===

====Correttezza====

Un programma o sistema software si dice '''corretto''' se si comporta esattamente secondo quanto previsto dalla sua [[specifica dei requisiti]]. In termini più informali, un sistema è corretto se fa esattamente quello che è stato progettato per fare. Nell'ingegneria del software "classica" ([[anni 1960|anni sessanta]]-[[anni 1970|anni settanta]]), lo sviluppo di software corretto veniva universalmente considerato l'obiettivo ''predominante'', a cui praticamente tutti gli altri parametri di qualità erano finalizzati. Molti moderni [[Modello di sviluppo del software|modelli di sviluppo software]], viceversa, escludono la possibilità di sviluppare rispetto a una ''specifica'' stabilita a priori in modo definitivo e non ambiguo, e quindi, indirettamente, negano alla ''correttezza'' un valore pratico significativo. In ogni caso, la correttezza è una qualità ''assoluta'' (un sistema ''è'' corretto o ''non lo è'') e sostanzialmente impossibile da misurare (verificare); non è possibile ''stabilire con certezza'' che un sistema sia corretto.

Nelle metodologie di sviluppo e progettazione agili, si parla piuttosto di "[[soddisfazione del cliente]]", intendendo con questo che i requisiti iniziali potrebbero essere stati modificati, ma con il consenso e a piena soddisfazione del committente.

Riga 15:

====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à).

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.

Riga 26:

====Robustezza====

{{vedi anche|Robustezza (informatica)}}

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.

====Efficienza====

{{vedi anche|Efficienza (informatica)}}

Un sistema è '''efficiente''' se usa [[memoria]], [[CPU]] e altre 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 utilizzati 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]].

====Usabilità====

Riga 66:

====Manutenibilità====

Facilità di apportare modifiche a sistema realizzato.

In origine si pensava che la manutenzione corrispondesse solo al [[''bug fixing]]'', ma oggi la situazione è più complessa; la manutenzione riguarda infatti ogni miglioramento del software e andrebbe indicata più precisamente come [[evoluzione del software]].

Ormai il {{M|60|ul=%}} dei costi dipende proprio dalla manutenzione.

Per analizzare questi costi occorre suddividere in manutenzione:

* Correttiva

Riga 75:

* Elimina gli errori presenti sin dall'inizio

* Elimina gli errori introdotti da precedenti interventi di manutenzione

* Rappresenta il {{M|20|u=%}} del totale della manutenzione

La manutenzione adattativa (o adattiva):

* Modifiche a seguito di cambiamenti nell'ambiente

* Cambiamenti nell'Hardware, nel Sistema operativo, ecc.

* {{M|20|u=%}} del totale

La manutenzione perfettiva

* Modifiche per migliorare le qualità del software

* Introduzione di nuove funzionalità

* Miglioramento delle funzionalità esistenti

* È la parte più consistente (circa il {{M|60|u=%}} del totale)

L'ultima parte è così consistente soprattutto per il ''[[Sistema legacy|legacy software]]'' che non può essere sostituito a meno di ingenti spese, per cui viene migliorato e adattato.

La manutenibilità dipende da due aspetti

* Riparabilità per indicare ciò che consente di eliminare difetti

Riga 92:

====Riparabilità====

Un sistema è riparabile se la correzione degli errori è poco faticosa.

È una proprietà fondamentale di molti prodotti ingegneristici (automobili, computer, ecc...). Per questi prodotti la tecnica usata è quella di abbassare il prezzo e di favorire la sostituzione piuttosto che la riparazione. Perché ciò possa avvenire si utilizzano delle parti standard che possono essere cambiate con facilità.

Nel software la situazione è diversa.

* Non c'è usura (parti meccaniche);

Riga 128:

È diventato un aspetto fondamentale perché consente di avere vantaggi economici, in quanto si possono ammortizzare i costi trasportando l'applicazione in diversi ambienti.

Nel caso delle applicazioni web è la chiave di volta.

Si usano strumenti e tecniche appositamente pensate per dare luogo ada oggetti portabili.

==Voci correlate==