Qualità del software: differenze tra le versioni

Contenuto cancellato Contenuto aggiunto
provvisorio - cat:software
m Correggo dei wikilink.
 
(122 versioni intermedie di 74 utenti non mostrate)
Riga 1:
{{F|ingegneria del software|aprile 2011}}
==Caratteristiche==
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à.
Si distinguono tra:
* Qualità ESTERNE: Percepibili dagli utenti
* Qualità INTERNE: Percepibili dagli sviluppatori
Le seconde servono a raggiungere le prime.
Qualità esterne:
* Correttezza
* Affidabilità
* Robustezza
* Efficienza e Prestazioni
* Facilità d’uso
Qualità interne:
* Verificabilità
* Manutenibilità
* Riusabilità
* Portabilità
* ...
 
==Cos'è il software di qualità?==
==Correttezza==
===Classificazione dei parametri===
Un software è funzionalmente '''corretto''' se si comporta come stabilito nei suoi requisiti funzionali (''functional requirements specificatio''n). 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à.
 
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).
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é si sarà descritta in un linguaggio naturale e, per questo, ambigua.
 
===Parametri di qualità esterni===
==Affidabilità==
====Correttezza====
Misura quanto l’utente può far affidamento sul software.
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.
E’ 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.
 
====Affidabilità====
Quindi per il software si hanno:
{{vedi anche|Affidabilità}}
* Aspettative minori
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à).
* Known Bugs
 
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.
Solitamente l’affidabilità è definita in termini di [[mtbf]] (Mean Time Between Failures).
 
L'[[industria del software]] moderna, su applicazioni non critiche, 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 (informatica)|patch]]'' (per esempio via [[Internet]]) attraverso cui gli errori vengono corretti via via che vengono trovati dall'utenza e segnalati al produttore.
==Correttezza vs affidabilità==
La correttezza è una qualità assoluta, mentre l’affidabilità è una qualità relativa
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.
 
Controesempi di software affidabile (o chiari esempi di software inaffidabile).
==Robustezza==
Il [[Therac-25]] era una strumentazione medica usata agli inizi degli anni ottanta per trattare il cancro. L'unicità dell'apparecchiatura a quel tempo era il software, che monitorava la dose di radiazioni da emettere nel trattamento. Purtroppo un errore nel software causò l'emissione di dosi letali. L'errore si verifica così infrequentemente che morirono diverse persone prima di rendersi conto del problema.
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.
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.
 
====Robustezza====
La robustezza comunque dipende dal contesto e non è assoluta, in particolare dipende da:
{{vedi anche|Robustezza (informatica)}}
* chi usa il sistema
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.
* Quali sono le sue capacità di adattamento
* Quanto è critico il buon funzionamento del software
 
====Efficienza e Prestazioni====
{{vedi anche|Efficienza (informatica)}}
Un sistema è efficiente se usa le risorse ([[memoria]], [[CPU]],...) in modo efficiente, ossia senza sprechi.
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]].
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]].
 
====Usabilità====
Spesso viene presa in considerazione solo a sistema realizzato, ma può essere molto difficile intervenire a posteriori.
{{vedi anche|Usabilità}}
 
Un sistema è facile da usare se un essere umano lo reputa tale.<br />
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.
È una qualità soggettiva:
Esistono diversi modi per misurare queste qualità:
* dipende dal contesto
* Complessità algoritmica
* dipende dall'esperienza
* Misure sul campo delle caratteristiche (measurement)
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.
* Modello matematico da analizzare (analysis)
* Modello di simulazione (simulation)
 
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] {{Webarchive|url=https://web.archive.org/web/20121113142238/http://www.useit.com/papers/heuristic/heuristic_list.html |date=13 novembre 2012 }}, e quanto espresso dallo standard [[ISO]] 9241-10 sugli ''ergonomic requirement'' [http://web.tiscali.it/userware/standardiso9241.htm#parte%2010%20dell%27ISO%209241].
==Usabilità==
 
====Ecocompatibilità====
Un sistema è facile da usare se un essere umano lo reputa tale.
Un sistema è ecocompatibile se tiene in conto nel suo disegno l'impatto del suo esercizio sull'ambiente che lo circonda.
E’ una qualità soggettiva
L'ecocompatibilità equivale all'efficienza del sistema ambiente di cui l'essere umano è parte.
* Dipende dal contesto
* Dipende dall’esperienza
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.
 
====Scalabilità====
==Verificabilità==
{{vedi anche|Scalabilità}}
Un sistema è verificabile se le sua proprietà:
 
* Correttezza
Un sistema è scalabile se può essere adattato a diversi contesti con forti differenze di complessità (per esempio [[database]] molto piccoli o molto grandi) senza che questo richieda la riprogettazione dello stesso sistema. Solitamente, si richiede che le prestazioni di un sistema possano essere aumentate "semplicemente" fornendo al sistema stesso maggiori risorse di calcolo (processori più potenti, maggiori quantità di memoria, sistemi di memoria di massa più capienti o più veloci, e così via).
* Affidabilità
 
sono facili da verificare.
===Parametri di qualità interni===
====Verificabilità====
Un sistema è verificabile se le sue proprietà:
* correttezza
* affidabilità
sono facili da verificare.<br />
Per aumentare il grado di verificabilità si fa uso di:
* Tecnichetecniche di [[progettazione modulare]]
* Opportuniopportuni linguaggi di programmazione
* [[software monitor]]
* Software Monitor
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]].
Ormai il {{M|60|ul=%}} dei costi dipende proprio dalla manutenzione.
Per analizzare questi costi occorre suddividere in manutenzione:
* Correttiva
* Adattativa
* Perfettiva
La manutenzione correttiva
* 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 ''[[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
* Evolvibilità per indicare ciò che consente l'implementazione di nuovi requisiti
 
====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);
* Non esistono componenti standard;
* Il costo non dipende dai pezzi ma solo dalla manodopera necessaria.
La riparabilità si persegue attraverso la modularizzazione.
Non conta tanto il numero, ma piuttosto il come sono organizzati tra loro e al loro interno.
 
====Evolvibilità====
Il software, a differenza di altri prodotti ingegneristici, è teoricamente facilmente modificabile. Tuttavia:
* Non si fanno mai studi di analisi di fattibilità approfonditi
* Non si progettano le modifiche
Peggio ancora, i cambiamenti effettuati non sempre sono documentati per cui le specifiche non vengono aggiornate e ciò rende i cambiamenti futuri difficili da compiere.
È necessario prevedere sin dall'inizio che il software possa 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:
* [[Specifiche]]
* Progetti
* [[Collaudo]]
Indica il livello di maturazione della disciplina.
Vantaggi:
* Diminuzione dei costi
* Aumento della affidabilità
Come fare per rendere i diversi manufatti riusabili?
* Tecniche di progettazione
* Tecniche di specifica
* Metodologie
* Standardizzazione del processo di sviluppo
 
====Portabilità====
Un sistema è portabile se è in grado di funzionare in ambienti diversi.
 
È 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 a oggetti portabili.
 
==Voci correlate==
* [[Ingegneria del software]]
* [[Paradigma di programmazione]]
* [[Sviluppo software]]
* [[Regola del 90-90]]
 
== Altri progetti ==
{{interprogetto|preposizione=sulla}}
 
== Collegamenti esterni ==
* {{Collegamenti esterni}}
 
{{Portale|ingegneria}}
==to be continued==
 
[[categoriaCategoria:Ingegneria del software]]
[[Categoria:Qualità del software| ]]