Versione delle 02:47, 8 feb 2005 modifica Twice25 (discussione \| contributi) Utenti autoverificati 137 728 modifiche provvisorio - cat:software ← Differenza precedente		Versione delle 17:39, 8 feb 2005 modifica annulla Frieda (discussione \| contributi) Utenti autoverificati 41 638 modifiche m - bold Differenza successiva →
Riga 1: ==Caratteristiche== Si distinguono tra: * Qualità ~~ESTERNE~~''esterne'': ~~Percepibili~~percepibili dagli utenti * Qualità ~~INTERNE~~''interne'': ~~Percepibili~~percepibili dagli sviluppatori Lele seconde servono a raggiungere le prime. Qualità esterne: * Correttezza Riga 10 ⟶ 11: * Efficienza e Prestazioni * Facilità d’uso Qualità interne: * Verificabilità Riga 15 ⟶ 17: * Riusabilità * Portabilità * ... ==Correttezza== Un software è funzionalmente '''corretto''' se si comporta come stabilito nei suoi requisiti funzionali (''functional requirements ~~specificatio~~specification''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à. 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~~scritta in un linguaggio naturale e, per questo, ambigua. ==Affidabilità== Misura quanto l’utente può far affidamento sul software. 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. Quindi per il software si hanno: * ~~Aspettative~~aspettative minori * known bugs (falle note) * Known Bugs Solitamente l’affidabilità è definita in termini di [[mtbf]] (~~Mean~~'''M'''ean ~~Time~~'''T'''ime ~~Between~~'''B'''etween ~~Failures~~'''F'''ailures). ==Correttezza vsVs affidabilità== La correttezza è una qualità assoluta, mentre l’affidabilità è una qualità relativa. <br/> Se un sistema presenta degli errori * ~~Non~~non è corretto; * ~~Potrebbe~~potrebbe essere però affidabile Se la specifica cattura tutti i requisiti un sistema corretto è affidabile. Se la specifica ~~NON~~'''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. 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. La robustezza comunque dipende dal contesto e non è assoluta, in particolare dipende da: * chi usa il sistema * ~~Quali~~quali sono le sue capacità di adattamento * ~~Quanto~~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]]. Spesso viene presa in considerazione solo a sistema realizzato, ma può essere molto difficile intervenire a posteriori. Riga 61 ⟶ 62: 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. Esistono diversi modi per misurare queste qualità: * ~~Complessità~~complessità algoritmica * ~~Misure~~misure sul campo delle caratteristiche (''measurement'') * ~~Modello~~modello matematico da analizzare (''analysis'') * ~~Modello~~modello di simulazione (''simulation'') ==Usabilità== Un sistema è facile da usare se un essere umano lo reputa tale.<br/> E’È una qualità soggettiva: * ~~Dipende~~dipende dal contesto * ~~Dipende~~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. ==Verificabilità== Un sistema è verificabile se le sua proprietà: * correttezza * Correttezza * affidabilità * Affidabilità sono facili da verificare. <br/> Per aumentare il grado di verificabilità si fa uso di: * ~~Tecniche~~tecniche di progettazione modulare * ~~Opportuni~~opportuni linguaggi di programmazione * software monitor * Software Monitor In alcuni casi diventa una qualità esterna (''Software safety critical'') ~~==to be continued==~~ [[categoria:software]]

Qualità del software: differenze tra le versioni