Qualità del software: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
mNessun oggetto della modifica |
|||
Riga 18:
* Portabilità
==Qualità esterne==
===Correttezza===
Un software è funzionalmente ''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 25 ⟶ 26:
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 36 ⟶ 37:
Solitamente l’affidabilità è definita in termini di [[mtbf]] ('''M'''ean '''T'''ime '''B'''etween '''F'''ailures).
===Correttezza Vs affidabilità===
La correttezza è una qualità assoluta, mentre l’affidabilità è una qualità relativa. <br/>
Se un sistema presenta degli errori
Riga 44 ⟶ 45:
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 54 ⟶ 55:
* 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 67 ⟶ 68:
* modello di simulazione (''simulation'')
===Usabilità===
Un sistema è facile da usare se un essere umano lo reputa tale.<br/>
Riga 75 ⟶ 76:
L’interfaccia utente interviene molto sull’amichevolezza di un’applicazione, ma anche in questo caso è la formazione e la cultura dell’utente a giudicare tale caratteristica.
==Qualità interne==
===Verificabilità===
Un sistema è verificabile se le sua proprietà:
* correttezza
Riga 86 ⟶ 88:
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 infatti la manutenzione riguarda ogni miglioramento del software e andrebbe indicata più precisamente come [[evoluzione del software]].
Riga 112 ⟶ 114:
* 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 122 ⟶ 124:
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 129 ⟶ 131:
E’ 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 ricusabilità si usano di parti di sistema per realizzare un prodotto diverso.
Inizialmente si pensava al riuso del software. Oggi si riusa tutto:
Riga 145 ⟶ 147:
* Standardizzazione del processo di sviluppo
===Portabilità===
Un sistema è portabile se è in grado di funzionare in ambienti diversi.
| |||