Qualità del software: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
m fix link |
Nessun oggetto della modifica |
||
Riga 1:
Per '''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à?==
Qualità esterne:▼
* Correttezza▼
===Classificazione dei parametri===
Tradizionalmente, i '''parametri''' (o '''fattori''') rispetto a cui si può misurare o definire la qualità del software vengono classificate in due famiglie: '''parametri esterni''' e '''parametri interni'''. I primi si riferiscono alla qualità del software così come è percepita dai suoi [[utente finale|utenti]], e includono [[correttezza]], [[affidabilità]], [[robustezza]], [[efficienza]], [[usabilità]]. I secondi si riferiscono alla qualità del software così come è percepita dagli [[programmatore|sviluppatori]], e includono [[verificabilità]], [[manutenibilità]], [[riparabilità]], [[evolvibilità]], [[riusabilità]], [[portabilità]], [[leggibilità]], [[modularità]]. Non raramente esiste una correlazione fra questi due aspetti (banalizzando: il software ''mal scritto'' tende anche a ''funzionare male'').
Un software è ''corretto'' se si comporta come stabilito nei suoi requisiti funzionali (''functional requirements specification''). Ciò presuppone l’esistenza di un [[documento di specifica]] dei [[requisiti]].
Va sottolineato che il termine ''requisiti funzionali'' si abbrevia nella forma ''requisiti'', anche se abbiamo altri tipi di requisiti come quelli di prestazioni e di scalabilità.
Riga 28 ⟶ 15:
La specifica deve essere sufficientemente chiara e non ambigua, cosa abbastanza difficile perché sarà scritta in un linguaggio naturale e, per questo, ambigua.
====Affidabilità====
Misura quanto l’utente può far affidamento sul software.
Riga 49 ⟶ 36:
Se la specifica '''non''' cattura i requisiti un sistema corretto potrebbe non essere affidabile.
====Robustezza====
Un sistema è robusto se si comporta in modo ragionevole in situazioni impreviste. Ad esempio quando vengono inseriti dati di input non corretti.
La robustezza può essere corretta andando a colmare quelle [[lacune]] dei requisiti che appunto non hanno descritto il comportamento nel caso di situazioni anomale.
Riga 59 ⟶ 46:
* 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]].
Riga 72 ⟶ 59:
* modello di simulazione (''simulation'')
====[[Usabilità]]====
Un sistema è facile da usare se un essere umano lo reputa tale.<br/>
Riga 82 ⟶ 69:
Al di fuori di una visione macchinocentrica, va sottolineata l'esistenza di principi condivisi che permettono di valutare il livello di usabilità di un'applicazione, indipendentemente da fattori soggettivi. Valga come riferimento il noto studio di [[Jakob Nielsen]][http://www.useit.com/papers/heuristic/heuristic_list.html], e quanto espresso dallo standard [[ISO]] 9241-10 sugli ergonomic requirements [http://web.tiscali.it/userware/standardiso9241.htm#parte%2010%20dell%27ISO%209241].
===Qualità interne===
====Verificabilità====
Un sistema è verificabile se le sua proprietà:
* correttezza
Riga 94 ⟶ 81:
In alcuni casi diventa una qualità esterna (''Software safety critical'')
====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]].
Riga 120 ⟶ 107:
* Evolvibilità per indicare ciò che consente l’implementazione di nuovi requisiti
====Riparabilità====
Un sistema è riparabile se la correzione degli errori è poco faticosa.
E’ una proprietà fondamentale di molti prodotti ingegneristici (automobili, computer,...). 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à.
Riga 130 ⟶ 117:
Non conta tanto il numero, ma piuttosto il come sono organizzati tra loro e al loro interno.
====Evolvibilità====
Il software, purtroppo, a differenza di altri prodotti ingegneristici è facilmente modificabile:
* Non si fanno mai studi di analisi di fattibilità approfonditi
Riga 137 ⟶ 124:
È necessario prevedere sin dall’inizio che il software può evolvere e progettare tenendo in mente questa evoluzione per sfruttare al meglio i costi sostenuti in passato.
====Riusabilità====
Affine all’evolvibilità. Tuttavia si ha nell’evolvibilità una modifica per realizzare una nuova versione, mentre nella riusabilità si usano parti di sistema per realizzare un prodotto diverso.
Inizialmente si pensava al riuso del software. Oggi si riusa tutto:
Riga 153 ⟶ 140:
* Standardizzazione del processo di sviluppo
====Portabilità====
Un sistema è portabile se è in grado di funzionare in ambienti diversi.
Riga 161 ⟶ 148:
==Voci correlate==
* [[Ingegneria del software]]
* [[Paradigma di programmazione]]
* [[Processo software]]
[[en:Software quality]]
[[zh:软件质量]]
[[categoria:Ingegneria del software]]
| |||