Qualità del software: differenze tra le versioni

Versione delle 13:01, 13 mar 2006

Versione delle 13:14, 13 mar 2006

Riga 5:

===Classificazione dei parametri===

Tradizionalmente, i '''parametri''' (o '''fattori''') rispetto a cui si può misurare o definire la qualità del software vengono classificateclassificati 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'').

===Parametri di qualità esterni===

===Qualità esterne===

====Correttezza====

{{vedi anche|correttezza}}

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]].

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 '60]]-[[anni 1970|anni '70]]), lo sviluppo di software corretto veniva universalmente considerato l'obiettivo ''predominante'', a cui praticamente tutti gli altri parametri di qualità erano finalizzati. Molti moderni modelli di [[processo 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.

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

Comunque deve essere possibile il confronto con i requisiti per verificare la correttezza.

La specifica deve essere sufficientemente chiara e non ambigua, cosa abbastanza difficile perché sarà scritta in un linguaggio naturale e, per questo, ambigua.

====Affidabilità====

{{vedi anche|affidabilità}}

Misura quanto l’utente può far affidamento sul software.