La qualità del software. Qualità del software: standard e valutazione

17.07.2019 Windows 8

Poco più di un anno fa, il mio articolo intitolato "Principles of Software Quality Management" è stato pubblicato sulla rivista "Open Systems". La versione online è disponibile qui: http://www.osp.ru/os/2008/06/5344965/. Prima della pubblicazione, la versione originale dell'articolo è stata pesantemente rivista dagli editori, a seguito della quale le sue dimensioni sono state ridotte di 2 volte e anche il testo, incluso il titolo, è stato pesantemente spalato. Ora ho deciso di pubblicare la versione aggiornata dell'autore sul mio blog, facendo lì delle piccole aggiunte. L'articolo non è in formato blog, ma piuttosto per una pubblicazione scientifica o educativa, quindi mi dispiace.

Il tema della qualità del software è spesso menzionato nella letteratura e negli articoli in lingua russa, ma raramente va al di là di lunghi discorsi o conversazioni sui test. Lo scopo di questo articolo è fornire una visione olistica del problema della qualità del software e dei principi di base della gestione della qualità del software. L'articolo fornisce una definizione del concetto di qualità del software, descrive un approccio che semplifica il problema dell'analisi della qualità, fornisce una breve panoramica dei metodi noti per migliorare la qualità.

I. Il concetto di qualità del software

Determinazione della qualità di un prodotto software
Secondo GOST R ISO 9000-2001, la qualità è "il grado in cui le caratteristiche intrinseche (di un prodotto) soddisfano i requisiti". Questa è una definizione generale. Se viene letteralmente trasferito nel campo dello sviluppo del software, potrebbe non essere interpretato completamente correttamente. Il fatto è che lo sviluppo dei requisiti, nel senso che questo termine è inteso per il campo del software, è parte integrante del processo di sviluppo di questo software. La qualità dei requisiti per un prodotto software (PP) influisce direttamente sulla qualità di questo software stesso. In altre parole, se i requisiti per il PCB sono di scarsa qualità, anche il prodotto stesso, sviluppato secondo questi requisiti, sarà di scarsa qualità anche in caso di perfetta conformità.

Se la parola "requisiti" nella definizione di GOST viene sostituita dalle parole "obiettivi del progetto" (qui per progetto si intende il processo di sviluppo di un prodotto software specifico o l'espansione delle funzionalità di un prodotto esistente), allora tutto va a posto. Più avanti nell'articolo indicheremo quanto segue per qualità del PP:

Si noti che questa definizione non affronta i problemi relativi ai costi. Gli obiettivi di un progetto di sviluppo software sono determinati principalmente dagli obiettivi aziendali e dai vincoli esistenti.

Criteri di qualità PCB
La qualità del PP è un concetto complesso e sfaccettato. In generale, la qualità è funzione delle seguenti variabili:

Funzionalità (quanto è utile il software per l'utente);
La qualità dell'interfaccia utente (usabilità, facilità di apprendimento);
Affidabilità (assenza di difetti nel PCB, resistenza ai guasti);
Prestazioni, consumo di risorse, requisiti per l'ambiente esterno;
Qualità del supporto informativo (documentazione);
Manutenibilità (qualità dell'architettura e del codice, qualità interna);
+ eventualmente altri criteri.

Altre opzioni per l'elenco dei criteri di qualità possono essere trovate, ad esempio, in,. La società di sviluppo definisce (dovrebbe definire) i suoi standard di qualità per ogni criterio per ogni progetto software. Quando si valuta la qualità, è necessario essere in grado di quantificare ciascuno dei criteri.

Impatto delle attività del ciclo di vita sulla qualità del PC
Considerare le attività tipiche del ciclo di vita di un progetto software e il loro impatto sui criteri di qualità di cui sopra. Nella tabella sottostante, il simbolo * significa che questo tipo di attività (riga) influenza chiaramente questo criterio di qualità (colonna):

Il punto principale su cui vorrei attirare la vostra attenzione qui è il seguente: la qualità del prodotto finale è influenzata da tutte le fasi e attività del progetto, senza eccezioni, dalla prima all'ultima. Quindi, quanto bene e qualitativamente lavoriamo in ogni fase del progetto (e non solo, ad esempio, durante la fase di test) dipende da quanto risulterà di alta qualità il prodotto che si sta sviluppando. O in altre parole, la qualità del processo di sviluppo determina la qualità del prodotto in fase di sviluppo, ad es. la qualità del prodotto è inseparabile dalla qualità del processo e, per migliorare la qualità del PCB, è necessario migliorare la qualità del processo di sviluppo del PCB.

Concetto generalizzato di difetto
Sarebbe conveniente introdurre e utilizzare un criterio di qualità generalizzato per l'analisi della qualità invece di diversi criteri sparsi. Questo criterio è il concetto generalizzato di difetto:

Pertanto, chiameremo difetto qualsiasi deviazione dallo standard di qualità per uno qualsiasi dei criteri di cui sopra. Ad esempio, la mancanza di funzionalità o l'eccesso di funzionalità è un difetto. Un'interfaccia scomoda è un difetto. Un codice mal progettato o disordinato che avrà un impatto negativo sulla manutenibilità è un difetto. La prestazione inaccettabile è un difetto. Il funzionamento errato del programma ("bug", comportamento errato) è un caso speciale di difetto. Anche un errore di ortografia nella documentazione dell'utente è un difetto.

I difetti possono essere classificati, ad esempio, secondo i seguenti parametri:

Tipo di difetto (determinato dalla fase di sviluppo o dall'attività in cui è stato introdotto);

La criticità del difetto (quanto è critica la sua presenza nel PCB);

Priorità del difetto (quanto è importante risolverlo);

La complessità del difetto (quanto è laborioso ripararlo);

Avendo un indicatore di qualità inversa così generalizzato, diventa più facile valutare e analizzare la qualità del software in fase di sviluppo, nonché la qualità del nostro processo di sviluppo in generale. Possiamo contare il numero dei difetti o la somma dei loro pesi (mediante qualche parametro), possiamo stimare la densità dei difetti per unità di volume del prodotto, analizzare quali fasi del processo sono per noi più problematiche, ecc. Ora la lotta per la qualità non è altro che la lotta con i difetti.

II. Gestione della qualità del prodotto software

Approccio tradizionale alla qualità del software
Introducendo il concetto generalizzato di difetto, è possibile tracciare un grafico che mostra la variazione nel tempo del numero di difetti in un progetto (Fig. 1). Per semplicità, esaminiamo il modello a cascata del ciclo di vita del progetto. Con l'approccio tradizionale alla qualità dei PCB, in cui l'enfasi è posta su test rigorosi, questo grafico potrebbe assomigliare a questo.

Riso. 1. La variazione del numero di difetti in un progetto nel tempo con l'approccio tradizionale alla gestione della qualità e con un ciclo di vita a cascata.

Qui, la linea rossa superiore mostra il numero di difetti introdotti al momento (va chiarito che questa linea è immaginaria, poiché non saremo in grado di calcolare con precisione il numero totale di difetti finché non li troveremo tutti). La linea verde inferiore mostra il numero di difetti trovati e risolti fino a quel momento (qui assumiamo che i difetti vengano corretti quasi immediatamente dopo che sono stati trovati). La differenza tra le linee rosse e verdi in ogni momento mostra il numero di difetti al momento. Siamo molto interessati a quale sarà questa differenza alla fine del progetto. Più è piccolo, migliore è il nostro prodotto. In termini di qualità, il ciclo di vita in questa figura è presentato come una competizione tra i processi di introduzione e correzione dei difetti.

Efficienza nella ricerca dei difetti
Si consideri una delle fasi finalizzate alla ricerca e correzione dei difetti, ad esempio, la fase di test del sistema. Durante questa fase viene riscontrato un certo numero di difetti D trovati, mentre al termine della fase D mancata rimane un certo numero di difetti non trovati (Fig. 2). Il numero totale di difetti che sono passati attraverso la fase sarà pari a D trovato + D mancato.

Riso. 2. Modifica del numero di difetti durante una fase.

Chiamiamo il rapporto tra i difetti riscontrati e il loro numero totale, espresso in percentuale, l'efficienza di ricerca del difetto (EPD%):

EPD% = .

Per ogni fase in cui vengono rilevati e riparati i difetti, a parità di processo maturo, questo valore dovrebbe essere approssimativamente costante. Questo fatto permette di quantificare il livello di qualità (espresso nel numero di difetti non riscontrati) per il progetto in corso e per i progetti pianificati.

L'efficienza della ricerca dei difetti può essere considerata sia per le singole fasi e attività, sia per l'intero ciclo di vita dello sviluppo. Allo stesso tempo, l'efficienza delle singole fasi determina l'efficienza per l'intero ciclo di vita. Ogni fase della ricerca dei difetti può essere considerata come una sorta di filtro che trattiene una certa parte dei difetti, e l'intero ciclo di vita, come un sistema di filtri. Se nelle prime fasi del ciclo di vita ci sono dei filtri scadenti che lasciano passare molti difetti, poi questi difetti si accumulano, e per filtrarli bene, alla fine del ciclo di vita (fase di test) avremo bisogno di un ottimo filtro .

Costo correzione difetti
I difetti non solo tendono ad accumularsi nel tempo, a meno che non venga intrapresa un'azione correttiva precoce. Ma è anche risaputo che più a lungo un difetto risiede in un progetto, più è costoso risolverlo (cioè richiede più tempo), e la dipendenza è spesso esponenziale. Per il modello del ciclo di vita a cascata, questa relazione è ben illustrata dal grafico seguente (Fig. 3).

Riso. 3. Variazione nel tempo del costo di riparazione dei difetti (ciclo di vita a cascata).

Per un modello iterativo del ciclo di vita, l'immagine sarà simile (Figura 4), cambieranno solo le etichette e la scala dell'asse y per diversi tipi di difetti (ad esempio, per requisiti e difetti di progettazione, la scala sarà maggiore rispetto a difetti di codifica).

Riso. 4. Variazione del costo della correzione dei difetti nel tempo (ciclo di vita iterativo).

Un approccio integrato alla gestione della qualità
Quindi, si scopre che basandosi su un solo, anche se molto accurato, test, il problema della qualità non può essere risolto. Se non si adottano misure per combattere i difetti fino alla fase di test, quindi all'inizio del test, nel progetto possono accumularsi così tanti difetti che sarà un compito travolgente ripulirli.

Pertanto, i difetti devono essere ricercati e corretti costantemente, durante l'intero ciclo di vita del progetto, a partire dalle prime fasi, e non solo alla fine della fase di test. In parole povere, alla fine del progetto, nella fase di test, è troppo tardi per cercare i difetti: se ce ne sono molti, nessuna quantità di test aiuterà a trasformare un prodotto di bassa qualità in un prodotto di alta qualità uno.

Il secondo approccio, che può e deve essere applicato in parallelo, è la prevenzione o l'elusione dei difetti,,.

Consideriamo come cambierà il grafico della dipendenza del numero di difetti nel tempo quando verrà applicato un approccio integrato alla gestione della qualità (Fig. 5). L'uso di metodi per trovare i difetti durante l'intero ciclo di vita di un progetto alza la curva dei difetti trovati verso l'alto. E l'applicazione di tecniche di prevenzione dei difetti spinge verso il basso la curva dei difetti di inserzione. Pertanto, il numero di difetti non trovati durante l'intero ciclo di vita diminuisce e, di conseguenza, diminuisce il numero di difetti non trovati alla fine del progetto.

Riso. 5. Variazione del numero di difetti nel progetto nel tempo con un approccio integrato alla gestione della qualità.

Metodi di ricerca dei difetti
I metodi di ricerca dei difetti possono essere classificati secondo i seguenti criteri:

statico e dinamico;
manuale e automatizzato.

Si possono quindi distinguere 4 categorie di metodi:

Analisi manuale degli artefatti:
Controllo statico automatico:
Test automatizzato:
Test manuale:

Ciascuno dei metodi di cui sopra ha i suoi pro e contro. Alcuni tipi di difetti si colgono meglio con alcuni metodi, altri con altri. Pertanto, un'efficace strategia di rilevamento dei difetti consisterà nell'utilizzare una combinazione di diversi metodi diversi. Ogni metodo di ricerca, a seconda di come è implementato e applicato in un contesto specifico, avrà il proprio livello di efficienza percentuale. Nel libro di S. McConnell "Code Perfect", puoi trovare una tabella di valori approssimativi dell'efficienza di trovare difetti per diversi metodi (vedi una copia di questa tabella di seguito). Si noti che in base a questi dati, il test ha un'efficienza di ricerca dei difetti relativamente bassa (25% -40%), e per renderlo elevato è necessario aumentare più volte il costo del processo di test (l'efficienza di beta testing con numero di tester > 1000 è di circa il 75%.

Metodo di ricerca	EPD%	Metodo di ricerca	EPD%
Revisione informale del design (progetto tecnico)	35%	Testare una nuova funzione (componente)	30%
Verifiche di progettazione formale (progetto tecnico)	55%	Test d'integrazione	35%
Revisione informale del codice	25%	Test di regressione	25%
Ispezioni formali del codice	60%	Test del sistema	40%
Modellazione e prototipazione	65%	beta test (<10 тестеров)	35%
Test dell'unità	30%	Beta test (> 1000 tester)	75%

Tecniche di prevenzione dei difetti
Non avremmo bisogno dei metodi di cui sopra per trovare i difetti se potessimo imparare a sviluppare software senza difetti. Questo è difficilmente realizzabile, ma vale la pena provare a ridurre il numero di difetti introdotti. I metodi per prevenire i difetti includono quanto segue:

La prototipazione è la creazione e il test di un modello economico di un sistema in fase di sviluppo al fine di testarne le caratteristiche e identificare ipotesi e decisioni errate che potrebbero portare a gravi difetti (e alterazioni) durante lo sviluppo.

L'uso di standard per tutti i tipi di prodotti realizzati nel corso dello sviluppo del software (requisiti, architettura, codice, documentazione varia, ecc.). Standard rigorosi e universalmente riconosciuti riducono al minimo i possibili malintesi tra le persone quando lavorano con questi prodotti (quando il lettore del prodotto ha letto qualcosa di diverso da ciò che il creatore del prodotto aveva in mente) e, di conseguenza, prevengono la comparsa di difetti associati a questo.

Applicazione di un approccio a componenti (o modulare). L'applicazione competente dell'approccio per componenti nella costruzione di sistemi software ne riduce la complessità e, di conseguenza, restringe lo spazio dei possibili difetti.

L'uso di soluzioni e componenti collaudati già pronti (nostri o acquistati), della cui alta qualità siamo certi. Meno dobbiamo sviluppare nuove soluzioni da soli, meno errori commettiamo.

Refactoring del codice: far sembrare corretto il codice è un buon modo per prevenire futuri difetti di manutenzione, che sono molto lieti di apparire quando si modificano sezioni di codice incomprensibili e mal progettate.

Lo sviluppo preliminare dei casi di test (prima della fase di codifica) consente di comprendere meglio i requisiti del sistema in fase di sviluppo e di progettarlo meglio. Un caso speciale di questo approccio è lo sviluppo guidato dai test, in cui i test unitari vengono sviluppati non dopo, ma prima della codifica.

Analisi regolare delle cause dei difetti più gravi e ricerca di modi per eliminare queste cause. Questo può accadere durante riunioni periodiche del team di sviluppo, oppure può essere fatto per ogni difetto maggiore riscontrato durante il test del sistema o dopo l'implementazione. Il risultato di questa analisi dovrebbe essere modifiche al processo di sviluppo volte ad eliminare le cause dei difetti, o, come minimo, a contribuire all'individuazione tempestiva di tali difetti.

Le tue idee?

Anche il fattore umano merita di essere menzionato qui. Nessun metodo può sostituire la professionalità e l'esperienza di sviluppatori e manager. I veri professionisti esperti, di regola, commettono meno errori e l'utilizzo della loro esperienza fornisce una buona base per lo sviluppo della qualità. Se il team è composto principalmente da giovani sviluppatori inesperti, dovresti considerare la possibilità di condurre corsi di formazione speciali per loro.

Gestione della qualità in un ciclo di vita iterativo
Si consideri, ad esempio, un ciclo di vita iterativo di 5 iterazioni, ciascuna delle quali può essere considerata come un ciclo di vita a cascata piccolo ma completo (Figura 6).

Riso. 6. La variazione del numero di difetti nel progetto nel tempo durante il ciclo di vita iterativo.

Supponiamo che l'efficienza di ricerca dei difetti in ciascuno dei cicli a cascata sia del 50% e che ad ogni iterazione venga introdotto lo stesso numero di difetti. Calcoliamo, utilizzando la formula EPD,%, che sarà uguale all'efficienza di ricerca dei difetti in un ciclo iterativo composto da cinque iterazioni consecutive. Dopo la prima iterazione, questa efficienza sarà del 50%; dopo il 2 - 62,5%; dopo il 3° - 70,8%; dopo il 4 - 76,6%; dopo il 5, l'efficienza di ricerca dei difetti di tutte e 5 le iterazioni sarà pari all'80,6%.

Questo esempio è idealizzato e, nella vita reale, è probabile che l'efficienza della ricerca di difetti a diverse iterazioni sia diversa. Ciò è dovuto all'eterogeneità delle attività a diverse iterazioni. Ma in ogni caso, c'è un chiaro progresso in termini di qualità prima di un semplice ciclo di vita a cascata. La spiegazione di questo effetto è molto semplice: ad ogni iterazione successiva, troviamo difetti non solo dell'iterazione corrente, ma anche i restanti difetti delle iterazioni precedenti. Di conseguenza, l'efficienza complessiva della ricerca dei difetti aumenta.

Pertanto, risulta che il miglioramento della qualità può essere ottenuto non solo introducendo metodi aggiuntivi per il rilevamento precoce dei difetti (come ispezioni, revisioni, ecc.), ma anche passando da una cascata a un ciclo di vita di sviluppo software iterativo. Inoltre, in teoria, più iterazioni, migliore è la qualità. I primi test di iterazione possono essere considerati come l'individuazione di difetti all'inizio del ciclo di vita.

Costo della qualità del software
Può sembrare che l'applicazione di molti metodi diversi per migliorare la qualità del software aumenti il costo dello sviluppo del software. Questo può essere vero a breve termine (fino a quando il processo del loro utilizzo non si è stabilizzato) o con l'uso analfabeta dei metodi. A lungo termine, la complessa applicazione dei metodi di miglioramento della qualità non solo non aumenta il costo di sviluppo, ma può anche renderlo più economico. Vediamo come questo accade.

Innanzitutto, come accennato in precedenza, prima è stato riscontrato il difetto, più economico è risolverlo. Pertanto, l'applicazione efficace di metodi per l'individuazione precoce dei difetti aiuta a ridurre il costo del progetto.

In secondo luogo, i metodi di ricerca dei difetti discussi sopra, oltre all'efficienza, sono caratterizzati anche dal tasso medio di ricerca dei difetti. Secondo i dati statistici, ad esempio da, questo indicatore per i metodi di prova è molte volte peggiore rispetto ai metodi di ricerca precoce dei difetti. Ciò significa che dedicando tempo alla ricerca di difetti nelle prime fasi, risparmiamo più tempo sui prossimi test.

S. McConnell sostiene che "migliorare la qualità del sistema riduce il costo del suo sviluppo", poiché "L'eliminazione dei difetti (nelle fasi successive) è in realtà la fase più costosa e dispendiosa in termini di tempo dello sviluppo del software".

Processo di gestione della qualità
Per la gestione della qualità, non è sufficiente utilizzare semplicemente vari metodi per migliorarla. È necessaria la loro applicazione sistematica consapevole, che diventerebbe parte integrante del processo di sviluppo del software orientato alla qualità.

È necessario monitorare costantemente la qualità del software in sviluppo attraverso metriche di qualità, nonché controllare la qualità dei singoli sottoprocessi che costituiscono un processo di sviluppo integrale.

I metodi che hanno funzionato bene ieri possono essere una perdita di tempo oggi. Ogni progetto può avere le sue specifiche, che richiedono un diverso insieme di metodi di miglioramento della qualità. Se l'efficacia dei metodi non viene costantemente monitorata, nel tempo può deteriorarsi in modo significativo.

La gestione della qualità è anche una ricerca costante di modi per migliorare il processo di sviluppo al fine di ridurre il numero di difetti introdotti e aumentare l'efficienza dei metodi di ricerca dei difetti.

Conclusione
Riassumiamo tutto quanto sopra. La qualità del software è determinata principalmente dal processo di sviluppo di quel software. Solo un processo maturo, stabile e orientato alla qualità è in grado di fornire prodotti software con un livello di qualità prevedibile e controllato. Tale processo dovrebbe essere basato sui principi di base della gestione della qualità del software:

ricerca e correzione costanti dei difetti durante l'intero ciclo di vita dello sviluppo, a partire dalle prime fasi;

applicazione sistematica di metodi per prevenire i difetti;

costante controllo della qualità del software sviluppato e del processo di sviluppo;

miglioramento continuo del processo di sviluppo al fine di migliorare la qualità.

Letteratura

1. Humphrey, Watts S., Una disciplina per l'ingegneria del software, ISBN 0-201-54610-8. Copyright 1995 di Addison-Wesley.
2. McConnell S., Codice perfetto. Master class / Per. dall'inglese –M .: Casa editrice e commerciale "Russian Edition"; SPb.: Pietro, 2005.
3. Humphrey, Watts S., Introduzione al processo software di squadra, ISBN 0-201-47719-X. Copyright 2005 di Addison Wesley Longman, Inc.
4. Humphrey, Watts S., PSP: un processo di auto-miglioramento per gli ingegneri del software, ISBN 0-321-30549-3. Copyright 2005 Pearson Education, Inc.
5. Ambler S., Agile Technologies: Extreme Programming e Unified Development Process. Libreria del programmatore. Per. dall'inglese –SPb.: Pietro, 2005.
6. Kroll P., Kratchen F., Il processo unificato razionale è facile. Una guida pratica a RUP. Per. dall'inglese –M.: KUDITS-OBRAZ, 2004.
7. Torres RJ, una guida pratica alla progettazione e allo sviluppo dell'interfaccia utente. Per dall'inglese. –M.: Casa editrice Williams, 2002.
8. Bobrovsky S., Ingegneria del software. Tecnologie del Pentagono al servizio dei programmatori russi. –SPb.: Pietro, 2003.
9. Hunt E., Thomas D., programmatore pragmatico. Il percorso da apprendista a maestro. Per. dall'inglese –M.: Casa editrice "Lori", 2004.
10. Fowler M., Refactoring: miglioramento del codice esistente. Per. dall'inglese –SPb.: Symbol-Plus, 2005.
11. Beck K., Programmazione estrema. Per. dall'inglese –SPb.: Pietro, 2002.
12. Beck K., Programmazione estrema: sviluppo guidato dai test. Libreria del programmatore. Per. dall'inglese –SPb.: Pietro, 2003.
13.GOST R ISO 9000-2001, http://bib-gost.narod.ru/kazestvo/_gost_r_iso_9000_2001.zip
14. Royce Walker, Gestione dei processi di sviluppo software. Per. dall'inglese –M.: Casa editrice "Lori", 2007.
15. Tian, Jeff, Ingegneria della qualità del software, ISBN 0-471-71345-7. Copyright 2005 della IEEE Computer Society. Metodologia Discipline correlate

Qualità del software- caratteristica del software (software) come grado della sua conformità ai requisiti. Allo stesso tempo, i requisiti possono essere interpretati in modo abbastanza ampio, il che dà origine a una serie di definizioni indipendenti del concetto. La definizione più comunemente utilizzata è la ISO 9001, secondo la quale la qualità è "il grado in cui le caratteristiche intrinseche soddisfano i requisiti".

Qualità del codice sorgente

La qualità del codice può essere determinata da vari criteri. Alcuni di loro sono significativi solo da un punto di vista umano. Ad esempio, il modo in cui viene formattato il testo del programma non è affatto importante per il computer, ma può essere molto importante per la successiva manutenzione. Molti degli standard di codifica esistenti, definendo convenzioni specifiche della lingua e impostando una serie di regole per migliorare la leggibilità del codice, sono progettati per facilitare la futura manutenzione del software, inclusi il debug e gli aggiornamenti. Esistono altri criteri che determinano se il codice è "ben scritto", come la struttura, il grado in cui il codice è suddiviso logicamente in una serie di blocchi gestibili.

Leggibilità del codice
Facilità di supporto, test, debug, correzione di bug, modifica e portabilità
Bassa complessità del codice
Basso utilizzo delle risorse: memoria e tempo della CPU
Gestire correttamente le eccezioni
Pochi avvisi di compilazione e collegamento

Tecniche per migliorare la qualità del codice: refactoring.

Fattori di qualità

Il fattore di qualità del software è un requisito non funzionale per un programma, che di solito non è descritto nel contratto con il cliente, ma, tuttavia, è un requisito desiderabile che aumenta la qualità del programma.

Alcuni dei fattori di qualità:

Comprensibilità Lo scopo del software deve essere chiaro dal programma stesso e dalla documentazione. Completezza Tutte le parti necessarie del programma devono essere presentate e attuate integralmente. brevità Mancanza di informazioni non necessarie e duplicate. Le parti di codice duplicate devono essere convertite in una chiamata di procedura generale. Lo stesso vale per la documentazione. portabilità Facilità di adattamento di un programma a un ambiente diverso: diversa architettura, piattaforma, sistema operativo o sua versione. Coerenza Le stesse convenzioni, formati e convenzioni dovrebbero essere usati in tutto il programma e in tutta la documentazione. Manutenibilità Quanto è difficile modificare un programma per soddisfare nuovi requisiti. Questo requisito indica anche che il programma dovrebbe essere ben documentato, non eccessivamente confuso e avere spazio per una crescita nell'utilizzo delle risorse (memoria, processore). testabilità Se il programma consente l'esecuzione di un test delle prestazioni, se la capacità di misurazione delle prestazioni è supportata. facilità d'uso Semplicità e facilità d'uso del programma. Questo requisito si applica principalmente all'interfaccia utente. affidabilità assenza di guasti e malfunzionamenti nel lavoro dei programmi, nonché facilità di correzione di difetti ed errori: struttura efficienza Con quanta razionalità il programma tratta le risorse (memoria, processore) quando svolge i suoi compiti. sicurezza

Dal punto di vista dell'utente

Oltre a una visione tecnica della qualità del software, esiste anche una valutazione della qualità dal punto di vista dell'utente. Il termine "usabilità" è talvolta usato per questo aspetto della qualità. È piuttosto difficile ottenere un punteggio di usabilità per un determinato prodotto software. Le questioni più importanti che incidono sulla valutazione:

L'interfaccia utente è intuitiva?
Quanto è facile eseguire operazioni semplici e frequenti?
Quanto sono facili le operazioni complesse?
Il programma fornisce messaggi di errore chiari?
Il programma si comporta sempre come previsto?
La documentazione è disponibile e quanto è completa?
L'interfaccia utente è autodescrittiva/autodocumentante?
I ritardi nella risposta del programma sono sempre accettabili?

Guarda anche

Link

Sviluppo software
Notevole cifre
Processi
Concetti
Indicazioni
Modelli sviluppo
Altri modelli
Altro

Fondazione Wikimedia. 2010.

Guarda cos'è "Qualità del software" in altri dizionari:

La capacità di un prodotto software di convalidare la sua specifica, a condizione che la specifica sia focalizzata sulle caratteristiche che l'utente desidera ottenere. Vedi anche: Qualità del software Software finanziario ... ... Vocabolario finanziario

Quando Grace Hopper stava lavorando con un computer Harvard Mark II presso l'Università di Harvard, i suoi colleghi hanno scoperto questa talpa bloccata in un relè e che quindi interferiva con il funzionamento del dispositivo, dopodiché ha notato che stavano "debuggando" il sistema. ... ... Wikipedia

Sviluppo software Sviluppo software Processo Fasi del processo Analisi Progettazione Programmazione Doc... Wikipedia

Lo sviluppo di software (ingegneria del software inglese, sviluppo di software) è un tipo di attività (professione) e un processo volto a creare e mantenere le prestazioni, la qualità e l'affidabilità del software, utilizzando ... Wikipedia

"Software Crisis", un termine usato una volta in informatica per descrivere le implicazioni della rapida crescita della potenza di calcolo dei computer e la complessità dei problemi che possono risolvere. In sostanza, è ... ... Wikipedia

Il nuovo Airbus A 380 utilizza molti software per creare una moderna cabina di pilotaggio nell'aereo. Il metodo dell'ingegneria del software ha permesso la creazione di software aeronautico descritti in milioni di righe... Wikipedia

La capacità del software di funzionare su una varietà di piattaforme hardware o sistemi operativi. Sinonimi: Portabilità del software Vedi anche: Qualità del software Sistemi aperti ... ... Vocabolario finanziario

Caratteristiche di un prodotto software che: consentono di ridurre al minimo gli sforzi degli utenti per preparare i dati iniziali, utilizzare il prodotto software e valutare i risultati ottenuti, e consentono anche di generare emozioni positive ... ... Vocabolario finanziario

Caratteristiche del prodotto software, che consente di ridurre al minimo gli sforzi per apportare modifiche: eliminare gli errori; o per la modifica in base alle mutevoli esigenze degli utenti. Vedi anche: Qualità del software ... ... Vocabolario finanziario

La capacità di un prodotto software di eseguire un insieme di funzioni: definita nella sua descrizione esterna; e soddisfare le esigenze degli utenti specificate o implicite. Sinonimi: Interoperabilità software Vedi anche: Qualità ... ... Vocabolario finanziario

Libri

Code Perfect: una guida pratica allo sviluppo del software, McConnell S .. Per oltre 10 anni, la prima edizione di questo libro è stata considerata una delle migliori guide pratiche nella programmazione. Ora questo libro è stato completamente aggiornato tenendo conto delle tendenze e delle tecnologie attuali ...

Approcci alla qualità del software

Classifichiamo i diversi approcci alla qualità del software utilizzando due dimensioni.

La prima dimensione è orientata al prodotto o al processo. Per migliorare la qualità del tuo software, puoi concentrarti sulla qualità del prodotto stesso, ad esempio rendendolo più user-friendly. Un approccio alternativo consiste nel migliorare il processo di sviluppo, assumendo che migliore è il processo, migliore è la qualità del software.

La seconda dimensione ha a che fare con la conformità o il miglioramento. Conformità significherà conformità a qualsiasi standard. Il miglioramento mira a passare a metodi e migliori pratiche migliori per migliorare la qualità.

ISO 9126 è uno standard di qualità del prodotto che definisce gli attributi e le caratteristiche della qualità, comprese le misurazioni per quantificare queste caratteristiche;

"miglioramento della pratica" ad esempio, miglioramenti nella gestione della configurazione del software, ispezioni, test, ecc.;

ISO 9000 è un insieme di standard che dichiarano i requisiti per i sistemi di qualità. Dal punto di vista dello sviluppo software, le più utili sono le "Linee guida per l'applicazione della ISO 9001 nello sviluppo, nella fornitura e nella manutenzione del software";

i metodi di miglioramento del processo di sviluppo del software offrono un certo livello di scala e requisiti di conformità, in base ai quali è possibile determinare il posto di un'azienda di computer su questa scala. I più famosi e popolari sono due metodi:

il Capability Maturity Model for Software (CMM), proposto dal Software Engineering Institute (SEI);

identificare le opportunità e migliorare il processo di sviluppo del software. ISO / IEC 15504 Miglioramento del processo software e determinazione delle capacità (SPICE).

Due affermazioni critiche sono al centro del raggiungimento della qualità.

La qualità inizia con la soddisfazione delle esigenze degli sviluppatori.
La qualità è dimostrata dalla soddisfazione del cliente.

Gli approcci per raggiungere la qualità sono i seguenti:

la qualità è raggiunta con l'aiuto di sviluppatori qualificati, aderenza accurata ai processi e approcci tecnologici di successo;
la qualità si ottiene comprendendo appieno tutte le azioni e i cambiamenti. Non una singola riga del programma dovrebbe essere aggiunta o modificata senza una piena comprensione di cosa, perché e come viene fatto;
la qualità si ottiene attraverso test approfonditi del programma prima che sia disponibile per l'utente;
il raggiungimento della qualità deve essere pianificato;
raggiungere la qualità è responsabilità di ogni sviluppatore.

Caratteristiche di qualità del software

Attualmente, non esistono criteri generalmente accettati per la qualità del software.

ISO 9000-3 Clausola 6.4.1

La definizione classica di qualità è che il prodotto software sviluppato conferma la sua specifica, mentre la specifica dovrebbe essere focalizzata sulle caratteristiche che il cliente vuole ricevere.

Gli standard moderni chiariscono il concetto di qualità introducendo un insieme di tratti e caratteristiche che influiscono sulla sua capacità di soddisfare le esigenze date degli utenti. Elenchiamo un certo numero di tali caratteristiche [Zhogolev 1996].

Funzionalità (idoneità, accuratezza, interoperabilità, coerenza, sicurezza). La funzionalità è la capacità di un prodotto software di eseguire un insieme di funzioni che soddisfano le esigenze dell'utente specificate o implicite. L'insieme di tali funzioni è definito nella descrizione esterna del prodotto software.

Affidabilità (completezza, stabilità, recuperabilità).

Convenienza (comprensibilità, efficienza nell'apprendimento, ergonomia). La convenienza è le caratteristiche di un prodotto software che riducono al minimo gli sforzi dell'utente per preparare i dati iniziali, utilizzare il prodotto software e valutare i risultati ottenuti, nonché evocare emozioni positive di un utente specifico o previsto.

Efficienza (in termini di tempo e risorse). L'efficienza è il rapporto tra il livello dei servizi forniti da un prodotto software a un utente in determinate condizioni e la quantità di risorse utilizzate.

Manutenibilità (facilità di analisi, variabilità, stabilità, testabilità). La manutenibilità è le caratteristiche di un prodotto software che riducono al minimo lo sforzo di apportare modifiche per correggere i bug e modificarlo per soddisfare le mutevoli esigenze dell'utente.

Portabilità (adattabilità, flessibilità di installazione, coerenza con norme e regolamenti, sostituibilità). La portabilità è la capacità di un prodotto software di essere portato da un ambiente a un altro, in particolare da un'architettura hardware a un'altra.

Bontà (organizzazione razionale, premura). Diamo uno sguardo più da vicino alle due caratteristiche più interessanti.

L'affidabilità è la capacità di un programma di eseguire in modo affidabile determinate funzioni in condizioni specificate per un determinato periodo di tempo con una probabilità piuttosto elevata. Un prodotto software affidabile non esclude la presenza di errori. È importante qui che gli errori nell'applicazione pratica in determinate condizioni compaiano piuttosto raramente. Il grado di affidabilità è caratterizzato dalla probabilità che un prodotto software funzioni senza guasti per un certo periodo di tempo.

Esistono i seguenti approcci per garantire l'affidabilità:

prevenzione degli errori;
auto-rilevazione degli errori;
autocorrezione degli errori;
garantire la resilienza agli errori.

La bontà del programma sta nel fatto che il programma è organizzato ragionevolmente e razionalmente, con un'organizzazione dei flussi di controllo e dei flussi informativi sufficientemente ponderata, non troppo complicata. Il concetto di fattore di qualità è stato introdotto da Pottosin [Pottosin 1997] per valutare i meriti interni dell'attuazione di un programma dal punto di vista tecnico. Pottosin introduce quattro classi di criteri di qualità del programma.

Criteri quantitativi associati a vari metodi di valutazione (metriche) della complessità dei programmi. Indichiamo esempi di caratteristiche numeriche.

Misure di Halstead [Halstead 1981], che include una serie di formule che valutano la lunghezza, il volume, il livello e il contenuto intellettuale dei programmi.

Stima della complessità del grafico di controllo del programma. Un frammento del programma può essere stimato dal numero ciclomatico del suo grafico di controllo, che è uguale a m - n + 2, dove m è il numero di archi, an è il numero di vertici del grafico di controllo. Si ritiene che il numero ciclomatico non debba superare 10.

Valutazione del partizionamento modulare del programma. Tale valutazione dovrebbe consistere di molti criteri. Ad esempio, la complessità di un modulo è stimata dall'aggregato della complessità delle procedure in esso definite e della complessità delle relazioni del modulo con altri moduli per l'importazione e l'esportazione di entità definite.

Criteri genetici relativi all'origine del programma e alla disciplina della sua creazione.

Criteri strutturali relativi alla valutazione dell'organizzazione di gestione nel programma e alla riflessione dell'organizzazione di gestione nel testo del programma.

Criteri pragmatici relativi alla valutazione di quanto bene il testo del programma corrisponda allo scopo del programma. Viene formulato un elenco di eccessi che non dovrebbero essere presenti in programmi di buona qualità, ad esempio ridondanza computazionale.

Valutazione della qualità del processo di sviluppo

Richiedi sia efficienza che flessibilità dallo stesso programma -

è come cercare una moglie affascinante e modesta.

A quanto pare, dovremmo fermarci a una delle due cose.

D. Weinberg

All'inizio di questa sezione, abbiamo notato che esistono due approcci che possono essere utilizzati per valutare la qualità di un prodotto software.

Valutare la qualità del prodotto finale.
Valutare la qualità del processo di sviluppo.

La qualità del prodotto finale può essere valutata mediante test e funzionamento. Il tempo dovrebbe essere assegnato per questo dopo il completamento del lavoro principale sul programma. Ma il secondo approccio dovrebbe diventare parte della strategia a lungo termine dell'azienda.

Modello di maturità dello sviluppo software

Il modello definisce cinque livelli di maturità organizzativa (http://www.sei.cmu.edu/cmm).

Primo livello. A questo livello, il processo di sviluppo è caratterizzato da una pratica assenza di processi gestionali. Il successo di un progetto dipende dagli sforzi individuali, dalle qualità personali e persino dall'eroismo dei partecipanti al progetto.

Livello ripetibile. A questo livello di maturità, l'azienda deve disporre di processi di gestione di base stabiliti per tenere traccia dei costi, della pianificazione del progetto e della funzionalità del progetto. Il livello è caratterizzato dal fatto che la gestione del progetto si basa sull'esperienza accumulata e i successi ottenuti in precedenza verranno ripetuti su applicazioni simili.

Un certo livello. Il processo di sviluppo del software (sia a livello gestionale che ingegneristico) è documentato, standardizzato e integrato in tutta l'organizzazione. Il processo cessa di dipendere dalle qualità individuali dei singoli sviluppatori e non può scivolare a livelli inferiori in situazioni di crisi.

Livello gestito. L'azienda stabilisce indicatori quantitativi dettagliati per il processo di sviluppo e la qualità del prodotto. Sia il processo di sviluppo che i prodotti sono comprensibili e controllabili.

Livello di ottimizzazione. Miglioramento continuo del processo di sviluppo basato sull'analisi dei risultati attuali del processo e sull'applicazione di idee e tecnologie innovative.

Identificazione delle opportunità e miglioramento del processo di sviluppo del software

Questo modello è molto vicino al modello di maturità, ma i livelli di capacità possono essere applicati non solo all'organizzazione nel suo insieme, ma anche ai singoli processi. I modelli di questo tipo vengono spesso definiti continui. Nei modelli continui, un processo può essere a un basso livello di maturità e un altro a un livello elevato. Lo standard definisce sei livelli di maturità del processo.

Livello 0. Il processo non è in esecuzione.

Livello 1. Il processo in corso.

Livello 2. Processo guidato.

Livello 3. Processo stabilito.

Livello 4. Processo prevedibile.

Livello 5. Processo di ottimizzazione.

Durante la valutazione e il miglioramento della qualità dei processi, vengono eseguiti i compiti descritti di seguito [Terekhov, Tunyon 1999].

Confronto del processo di sviluppo del software esistente in una data organizzazione con il modello descritto nello standard. L'analisi dei risultati consente di determinare i punti di forza e di debolezza del processo, i suoi rischi interni.

Una valutazione delle opportunità di miglioramento del processo basata sull'identificazione delle opportunità attuali.

Attuazione tecnica dei compiti stabiliti sulla base degli obiettivi formulati di miglioramento del processo. Dopodiché, l'intero ciclo di lavoro ricomincia.

Sul ruolo del Ministero della Difesa

Si segnala che storicamente i modelli di valutazione della qualità del processo di sviluppo sono stati creati al fine di ottenere ragionevoli procedure di valutazione e il successivo sviluppo di processi tecnologici in quelle organizzazioni che pretendono di ricevere ordini per lo sviluppo di progetti di rilevanza per la difesa. I modelli sono applicabili alle aziende che sviluppano sistemi complessi e in tempo reale. Si tratta di sistemi con lunghi cicli di vita in cui i difetti del software possono essere critici.

Software "abbastanza buono"

Ieri a Seattle dopo che Bill Gates ha menzionato la versione beta

Il nuovo programma di Microsoft ha colpito un terremoto.

Gli utenti attendono con orrore l'annuncio del rilascio della versione finale del prodotto.

Il promotore del software "abbastanza buono" è Edward Yordon [Yordon 2001]. Sottolineiamo che applica questo concetto ai "progetti senza speranza", che sono vincolati da severi vincoli di tempo, budget e risorse umane (vedi sezione 1.6). Nella maggior parte dei progetti senza speranza, il cliente può essere soddisfatto di un sistema che è abbastanza economico, abbastanza potente, ha le capacità necessarie, è abbastanza stabile e sarà pronto abbastanza presto. In effetti, queste caratteristiche possono essere considerate la definizione di software "abbastanza buono".

Si scopre che anche il software "abbastanza buono" è difficile da creare. Ecco alcuni dei motivi che spiegano tutto questo [Yordon 2001].

Spesso si cerca di definire la qualità solo in termini di difetti (errori). Dal punto di vista dell'utente, sono altrettanto importanti aspetti come essere pronti per una certa data.

Si presume che un minor numero di errori equivalga a una migliore qualità, e questa è la qualità che l'utente preferisce. Tuttavia, a volte l'utente è disposto a scendere a compromessi e a fare i conti con alcuni errori in cambio di un lavoro più veloce.

Ignorando fattori come il morale del team di sviluppo e un ambiente di lavoro adeguato.

James Bach sottolinea i seguenti prerequisiti per realizzare un software "abbastanza buono":

strategia utilitaristica - l'arte dell'analisi quantitativa e massimizzare i guadagni netti in situazioni incerte;
strategia evolutiva - considerata non solo in relazione al ciclo di vita del progetto, ma anche a persone, processi e risorse;
le squadre eroiche non sono potenti e brillanti programmatori, ma ordinari abili specialisti capaci di una cooperazione efficace;
infrastrutture dinamiche - l'opposto della burocrazia e del dominio della politica;
processi dinamici - processi che supportano il lavoro in un ambiente evolutivo.

Sfortunatamente, il software "abbastanza buono" raramente è abbastanza buono. Niklaus Wirth nota che questa è "una conseguenza della triste manifestazione dello spirito del nostro tempo, in cui scompare l'orgoglio personale per il proprio lavoro". A suo avviso «non ci si può aspettare un lavoro ben fatto, se non ci si dedica completamente, se non c'è soddisfazione personale, anzi, piacere da esso».

Un'osservazione interessante che alcune aziende cercano di abbassare il livello intellettuale degli utenti dei loro prodotti è stata fatta da molti programmatori. È estremamente vantaggioso per le aziende avere a che fare con persone le cui qualifiche tecniche non consentono di determinare gli aspetti reali (ad esempio, qualità, complessità, valore) di un prodotto software. Nascondendosi dietro la "semplificazione" del lavoro e aumentando la disponibilità dei computer per gli utenti, le aziende sovraccaricano e complicano ripetutamente il software in modo tale che è estremamente difficile per l'utente capire come funziona effettivamente e diventare un professionista.

Standardizzazione delle tecnologie dell'informazione

Uno standard è una definizione generalmente accettata di un componente hardware o software risultante da un accordo. Profilo: un insieme di standard legali e / o fattuali incentrati sull'esecuzione di un compito specifico [Kozlov 1999].

Gli standard possono essere classificati come segue:

dal tipo di requisiti fissati:
definizione dei requisiti per l'impianto;
definizione dei requisiti per il processo;
per scala:
internazionale;
stato;
industria;
imprese;
per grado di legalizzazione:
legalmente accettato;
effettivamente operante.

Il processo di standardizzazione delle tecnologie dell'informazione è supportato da tre gruppi principali di organizzazioni. Organizzazioni internazionali che fanno parte della struttura delle Nazioni Unite. L'Organizzazione internazionale per la standardizzazione (ISO) è un'organizzazione internazionale per la standardizzazione.

Informazioni sull'ISO

Nel 1947, i rappresentanti di 25 paesi decisero di creare un'organizzazione il cui compito principale sarebbe stato quello di coordinare lo sviluppo e unificare gli standard internazionali. La nuova organizzazione è stata denominata International Organization for Standardization (ISO). La discrepanza tra il nome completo e l'abbreviazione è dovuta al fatto che "ISO" è il prefisso greco che significa "uguale".

International Electrotechnical Commission (IEC) è una commissione elettrotecnica internazionale.

Unione internazionale delle telecomunicazioni-telecomunicazioni (ITU-T) - unione internazionale delle telecomunicazioni - telecomunicazioni. Fino al 1993, questa organizzazione era chiamata Comitato consultivo internazionale per il telegrafo e il telefono, un comitato consultivo internazionale sulla telefonia e la telegrafia.

Organizzazioni industriali professionali o amministrative.

Istituto di Ingegneri Elettrici ed Elettronici (IEEE) - Istituto di Ingegneri Elettrici ed Elettronici.

L'Internet Activity Board (IAB) è l'Internet Governance Board.

Consorzi industriali.

Object Management Group (OMG) è un gruppo di gestione degli oggetti.

X/Open è un consorzio organizzato da un gruppo di fornitori di hardware per computer.

La Open Software Foundation (OSF) è una fondazione software open source.

Nel 1987, ISO e IEC hanno unito le loro attività nel campo della standardizzazione delle tecnologie dell'informazione e hanno creato un unico organismo - Joint Technical Committee 1 (JTC1) - un comitato tecnico congiunto 1. Questo comitato è progettato per formare un sistema di standard di base nel campo della tecnologia dell'informazione.

Il problema principale nella gestione della qualità è il fatto che la definizione di qualità è troppo vaga e ambigua. Questo perché il termine qualità è generalmente frainteso. Questa confusione può essere attribuita a diversi motivi...

Proviamo a rispondere alle domande:

Vista popolare sulla qualità
conclusioni

Che cos'è la qualità del software?

Nella nostra prima puntata, cercheremo di definire i termini qualità e qualità del software.

Il primo, la qualità non è un'idea o un concetto isolato, ma piuttosto un concetto multidimensionale e sfaccettato.

Il secondo, per qualsiasi concetto e definizione, ci sono diversi livelli di astrazione, ad esempio, quando si parla di qualità, una parte lo interpreta come un significato troppo ampio e vago, mentre l'altra può riferirsi a una definizione e un significato specifici.

Il terzo, il termine qualità è parte integrante della nostra comunicazione quotidiana, tuttavia, l'uso comune e professionale può essere molto diverso.

Vista popolare sulla qualità

La saggezza convenzionale sulla qualità è che è qualcosa di intangibile e "intangibile" - può essere controversa e dibattuta, può essere criticata e lodata, ma è impossibile pesare e misurare la qualità. Espressioni come "buona qualità" e "cattiva qualità" servono come buoni esempi di come le persone parlano di qualcosa che è vago per loro, qualcosa che non possono caratterizzare e definire chiaramente. Questa visione riflette il fatto che le persone percepiscono e interpretano la qualità in modi diversi. Resta inteso che la qualità non può essere controllata e gestita, e ancor più non può essere misurabile quantitativamente. Questa visione è in netto contrasto con un approccio professionale alla gestione della qualità: la qualità è una quantità chiaramente definita che può essere misurata e controllata, è gestibile e migliorata.

Un'altra credenza popolare è che la qualità sia indissolubilmente legata al lusso, alla prima scelta e al gusto delicato. Un prodotto costoso, accuratamente studiato e tecnicamente più complesso è considerato una garanzia della massima qualità rispetto alle controparti più economiche. Seguendo questa logica, Cadillac è un'auto di qualità, ma Chevrolet non lo è, nonostante l'affidabilità e il numero di guasti; oppure un sistema HI-FI è un sistema di alta qualità, ma non una normale radio. Secondo questo approccio, la qualità è limitata a una certa classe di prodotti costosi con funzionalità complesse e prodotti di classe. In poche parole, è improbabile che un prodotto economico sia classificato come un prodotto di qualità.

Approccio professionale alla qualità

Sfortunatamente, questa visione vaga e vaga non può essere utilizzata per migliorare i processi di sviluppo del software. Pertanto, è necessario fornire una definizione chiara e facile da lavorare. Nel 1979, Crosby definì la qualità come "conformità ai requisiti" e Juran e Gryna nel 1970 definirono la qualità come "idoneità all'uso". Queste due definizioni sono strettamente correlate e concordano molto bene, come vedremo in seguito.

"Conformità ai requisiti" presuppone che i requisiti debbano essere definiti in modo così chiaro da non poter essere compresi e interpretati in modo errato. Successivamente, durante la fase di sviluppo, vengono effettuate misurazioni regolari del prodotto sviluppato per determinare la conformità ai requisiti. Eventuali discrepanze devono essere considerate difetti - mancanza di qualità. Ad esempio, una specifica per un modello radio specifico può richiedere la capacità di ricevere una specifica frequenza di onde radio a più di 30 chilometri dalla sorgente di trasmissione. Se la stazione radio non è in grado di soddisfare questo requisito, non soddisfa i requisiti di qualità e deve essere riconosciuta come non idonea e di scarsa qualità. Sulla base degli stessi principi, se una Cadillac soddisfa tutti i requisiti per un'auto Cadillac, allora è un'auto di qualità. Se una Chevrolet soddisfa tutti i requisiti per un'auto Chevrolet, allora è anche un'auto di qualità. Queste due auto possono essere completamente diverse per stile, velocità ed economia, ma se entrambe vengono misurate con i loro kit standard, allora sono entrambe auto di qualità.

Definizione "Idoneità all'uso" tiene conto dei requisiti e delle aspettative degli utenti finali del prodotto che si aspettano che il prodotto o il servizio fornito sia conveniente per le loro esigenze. Tuttavia, utenti diversi possono utilizzare il prodotto in modi diversi, il che significa che il prodotto dovrebbe avere il maggior numero possibile di usi diversi. Secondo la definizione di Juran, ogni caso d'uso è una caratteristica di qualità e tutti possono essere classificati in categorie come parametri di usabilità.

Queste due definizioni di qualità ("conformità ai requisiti" e "idoneità all'uso") sono essenzialmente le stesse. La differenza è che l'opzione “usabilità” indica il ruolo importante dei requisiti e delle aspettative del cliente. Il ruolo di qualità del cliente non può mai essere sopravvalutato. Dal punto di vista del cliente, la qualità del prodotto che ha acquistato è costituita da molti fattori diversi, quali: prezzo, prestazioni, affidabilità, ecc.

Solo il tuo cliente può parlarti della qualità, perché è l'unica cosa che compra davvero. Il cliente non acquista il prodotto. Compra le tue garanzie che tutte le sue aspettative per il prodotto saranno realizzate.

Guaspari "Lo riconosco quando lo vedo"

conclusioni

Riproviamo a definire la qualità dal punto di vista del cliente o dell'utilizzatore del prodotto.

La qualità è l'idoneità all'uso. Questo prodotto fa ciò di cui ho bisogno, rende il mio lavoro più facile, posso usarlo nel modo che mi si addice.

Ora diamo un'occhiata al punto di vista dello sviluppatore.

La qualità è la conformità ai requisiti specificati e raccolti questo prodotto fa tutto ciò che è specificato nei requisiti.

Il problema è che i requisiti specificati e raccolti di solito sono solo una frazione dei requisiti e delle aspettative effettivi del cliente. Dov'è la corretta definizione di qualità?

La qualità è il rispetto di requisiti reali, espliciti e impliciti. Molto spesso, i requisiti impliciti sono così ovvi per il cliente o l'utente che non presume nemmeno che siano sconosciuti agli sviluppatori. Ad esempio, torniamo alle nostre auto: il cliente può descrivere in dettaglio i requisiti per il design, i parametri del motore, il design degli interni, il colore della carrozzeria, ma non indica da nessuna parte che i pneumatici dovrebbero essere rotondi e il parabrezza dovrebbe essere trasparente.

Il cliente sarà soddisfatto solo quando il prodotto acquistato soddisfa pienamente le sue esigenze reali e di vita, specificate e non.

La qualità del software è il grado in cui il software ha la combinazione di proprietà richiesta.

La qualità del software è un insieme di caratteristiche del software relative alla sua capacità di soddisfare esigenze dichiarate e implicite.

Caratteristiche di qualità del software

Funzionalità(Funzionalità) - è determinata dalla capacità del software di risolvere problemi che corrispondono alle esigenze fisse e previste dell'utente, nelle condizioni date di utilizzo del software. Quelli. questa funzione è responsabile di garantire che il software funzioni correttamente e accuratamente, sia interoperabile, soddisfi gli standard del settore e sia a prova di manomissione.

Affidabilità(Affidabilità) - la capacità del software di eseguire le attività richieste in condizioni specificate per un periodo di tempo specificato o un numero specificato di operazioni. Gli attributi di questa caratteristica sono la completezza e l'integrità dell'intero sistema, la capacità di ripristinare in modo indipendente e corretto i guasti operativi e la tolleranza ai guasti.

La comodità d'uso(Usabilità) - la capacità di comprendere, studiare, utilizzare e rendere il software facilmente appetibile per l'utente.

Efficienza(Efficienza) - la capacità del software di fornire il livello richiesto di prestazioni in conformità con le risorse assegnate, il tempo e le altre condizioni indicate.

Convenienza dell'accompagnamento(Manutenibilità) - la facilità con cui il software può essere analizzato, testato, modificato per correggere i difetti, implementare nuovi requisiti, facilitare l'ulteriore manutenzione e adattarsi all'ambiente indicato.

Portabilità(Portabilità) - caratterizza il software in termini di facilità di portabilità da un ambiente (software/hardware) a un altro.

Modello di qualità del software

Al momento, il più comune e utilizzato modello di qualità del software multilivello presentato in una serie di standard ISO 9126. Evidenziato al livello più alto 6 caratteristiche principali della qualità del software, ciascuno dei quali è determinato da un insieme di attributi che hanno metriche corrispondenti per la valutazione successiva ( vedi fig. 1).

Figura 1 - Modello di qualità del software (ISO 9126-1)

29. Caratteristiche della qualità del software (GOST).

GOST ISO 9126-93

La qualità del software può essere valutata dalle seguenti caratteristiche:

4.1 Funzionalità(Funzionalità) Un insieme di attributi relativi all'essenza di un insieme di funzioni e alle loro proprietà specifiche. Le funzioni sono quelle che soddisfano i bisogni dichiarati o impliciti: Note

1 Questo insieme di attributi caratterizza ciò che il software fa per soddisfare le esigenze, mentre gli altri insiemi descrivono principalmente quando e come viene fatto.

4.2 Affidabilità(Affidabilità) Un insieme di attributi relativi alla capacità del software di mantenere il proprio livello di prestazioni in condizioni specificate per un periodo di tempo specificato. Note 1 Non si verifica alcun deterioramento o invecchiamento del software. I limiti di affidabilità derivano da errori nei requisiti, nella progettazione e nell'implementazione. Gli errori dovuti a questi errori variano a seconda di come viene utilizzato il software e delle versioni del software selezionate in precedenza. NOTA 2 Nella ISO 8402, l'affidabilità è la capacità di un articolo di svolgere una funzione richiesta. In questo Standard Internazionale, la funzionalità è solo una delle caratteristiche della qualità del software. Pertanto, la definizione di affidabilità è stata estesa per “mantenere il suo livello di prestazione” invece di “svolgere la funzione richiesta” (vedi anche 3.4).

4.3 Praticità(Usabilità) Un insieme di attributi relativi allo scopo del lavoro richiesto per l'uso e la valutazione individuale di tale uso da parte di un insieme definito o previsto di utenti. Note 1 Gli "Utenti" possono essere interpretati come la maggior parte degli utenti diretti di software interattivo. La cerchia degli utenti può includere operatori, utenti finali e utenti indiretti sui quali

interessati da questo software o che dipendono dal suo utilizzo. La praticità dovrebbe essere considerata attraverso la varietà di condizioni operative dell'utente che possono influenzare il software, compresa la preparazione per l'uso e la valutazione dei risultati.

NOTA 2 La praticità, definita in questo standard come un insieme specifico di attributi di un prodotto software, differisce dalla definizione ergonomica, che considera altre caratteristiche come l'efficienza e l'inefficienza come parte della praticità.

4.4 Efficienza(Efficienze) Un insieme di attributi relativi alla relazione tra il livello di prestazioni del software e la quantità di risorse utilizzate in condizioni specificate. NOTA Le risorse possono includere altri prodotti software, hardware, materiali (ad es. carta da stampa, floppy disk) ei servizi del personale operativo, di manutenzione o di supporto.

4.5 Manutenzione(Manutenibilità) Un insieme di attributi relativi all'ambito richiesti per eseguire modifiche specifiche (modifiche). NOTA Una modifica può includere correzioni, miglioramenti o adattamenti del software ai cambiamenti nell'ambiente, nei requisiti e nelle condizioni operative.

4.6 Mobilità(Portabilità) Un insieme di attributi relativi alla capacità del software di essere portato da un ambiente a un altro. NOTA L'ambiente può includere un ambiente organizzativo, tecnico o software.