Software Quality Management - Guida rapida

Per software di qualità si intende un software che è ragionevolmente privo di bug o difetti, viene consegnato in tempo ed entro il budget specificato, soddisfa i requisiti e / o le aspettative ed è mantenibile. Nel contesto dell'ingegneria del software, la qualità del software riflette entrambifunctional quality così come structural quality.

• Software Functional Quality - Riflette quanto bene soddisfa un determinato progetto, in base ai requisiti o alle specifiche funzionali.

• Software Structural Quality - Si occupa della gestione dei requisiti non funzionali che supportano la consegna dei requisiti funzionali, come robustezza o manutenibilità, e il grado in cui il software è stato prodotto correttamente.

• Software Quality Assurance- Software Quality Assurance (SQA) è un insieme di attività per garantire la qualità nei processi di ingegneria del software che alla fine si traducono in prodotti software di qualità. Le attività stabiliscono e valutano i processi che producono i prodotti. Implica un'azione incentrata sul processo.

• Software Quality Control- Software Quality Control (SQC) è un insieme di attività volte a garantire la qualità dei prodotti software. Queste attività si concentrano sulla determinazione dei difetti nei prodotti effettivamente prodotti. Implica un'azione incentrata sul prodotto.

La sfida della qualità del software

Nell'industria del software, gli sviluppatori non dichiareranno mai che il software è privo di difetti, a differenza di quanto fanno di solito altri produttori di prodotti industriali. Questa differenza è dovuta ai seguenti motivi.

Complessità del prodotto

È il numero di modalità operative consentite dal prodotto. Normalmente, un prodotto industriale consente solo meno di poche migliaia di modalità di funzionamento con diverse combinazioni delle impostazioni della macchina. Tuttavia, i pacchetti software consentono milioni di possibilità operative. Pertanto, garantire correttamente tutte queste possibilità operative è una sfida importante per l'industria del software.

Visibilità del prodotto

Poiché i prodotti industriali sono visibili, la maggior parte dei suoi difetti possono essere rilevati durante il processo di produzione. Anche l'assenza di una parte in un prodotto industriale può essere facilmente rilevata nel prodotto. Tuttavia, i difetti nei prodotti software che sono memorizzati su dischetti o CD sono invisibili.

Sviluppo del prodotto e processo di produzione

In un prodotto industriale, i difetti possono essere rilevati durante le seguenti fasi:

• Product development - In questa fase, i progettisti e il personale addetto all'assicurazione della qualità (QA) verificano e testano il prototipo del prodotto per rilevarne i difetti.

• Product production planning- In questa fase vengono progettati e preparati il ​​processo di produzione e gli strumenti. Questa fase fornisce anche l'opportunità di ispezionare il prodotto per rilevare i difetti che sono passati inosservati durante la fase di sviluppo.

• Manufacturing- In questa fase vengono applicate le procedure di QA per rilevare i guasti dei prodotti stessi. I difetti del prodotto rilevati nel primo periodo di produzione possono essere solitamente corretti da un cambiamento nel design o nei materiali del prodotto o negli strumenti di produzione, in modo da eliminare tali difetti nei prodotti fabbricati in futuro.

Tuttavia, nel caso del software, l'unica fase in cui è possibile rilevare i difetti è la fase di sviluppo. In caso di software, la pianificazione della produzione del prodotto e le fasi di fabbricazione non sono richieste in quanto la produzione delle copie del software e la stampa dei manuali del software sono eseguite automaticamente.

I fattori che influenzano il rilevamento dei difetti nei prodotti software rispetto ad altri prodotti industriali sono mostrati nella tabella seguente.

Caratteristica	Prodotti software	Altri prodotti industriali
Complessità	Milioni di opzioni operative	mille opzioni operative
visibilità del prodotto	Prodotto invisibile Difficile rilevare i difetti alla vista	Prodotto visibile Rilevamento efficace dei difetti alla vista
Natura dello sviluppo e processo di produzione	può difettare i difetti in una sola fase	può rilevare i difetti in tutte le seguenti fasi Sviluppo del prodotto Pianificazione della produzione del prodotto Manufacturing

Queste caratteristiche del software come la complessità e l'invisibilità rendono lo sviluppo della metodologia di garanzia della qualità del software e la sua implementazione di successo una sfida altamente professionale.

I vari fattori che influenzano il software sono definiti fattori software. Possono essere ampiamente suddivisi in due categorie. La prima categoria dei fattori è di quelli che possono essere misurati direttamente come il numero di errori logici, e la seconda categoria club quei fattori che possono essere misurati solo indirettamente. Ad esempio, la manutenibilità, ma ciascuno dei fattori deve essere misurato per verificare il contenuto e il controllo di qualità.

Nel corso degli anni sono stati suggeriti diversi modelli di fattori di qualità del software e la loro categorizzazione. Il modello classico dei fattori di qualità del software, suggerito da McCall, è costituito da 11 fattori (McCall et al., 1977). Allo stesso modo, i modelli composti da 12-15 fattori, sono stati suggeriti da Deutsch e Willis (1988) e da Evans e Marciniak (1987).

Tutti questi modelli non differiscono sostanzialmente dal modello McCall. Il modello a fattori McCall fornisce un metodo pratico e aggiornato per classificare i requisiti del software (Pressman, 2000).

Il modello fattoriale di McCall

Questo modello classifica tutti i requisiti software in 11 fattori di qualità del software. Gli 11 fattori sono raggruppati in tre categorie: funzionamento del prodotto, revisione del prodotto e fattori di transizione del prodotto.

• Product operation factors - Correttezza, affidabilità, efficienza, integrità, usabilità.

• Product revision factors - Manutenibilità, flessibilità, testabilità.

• Product transition factors - Portabilità, riusabilità, interoperabilità.

Fattori di qualità del software di funzionamento del prodotto

Secondo il modello di McCall, la categoria di funzionamento del prodotto include cinque fattori di qualità del software, che trattano i requisiti che influenzano direttamente il funzionamento quotidiano del software. Sono i seguenti:

Correttezza

Questi requisiti riguardano la correttezza dell'output del sistema software. Includono:

• Missione di uscita

• La precisione richiesta dell'output che può essere influenzata negativamente da dati imprecisi o calcoli imprecisi.

• La completezza delle informazioni di output, che possono essere influenzate da dati incompleti.

• L'attualità delle informazioni definita come il tempo che intercorre tra l'evento e la risposta del sistema software.

• La disponibilità delle informazioni.

• Gli standard per la codifica e la documentazione del sistema software.

Affidabilità

I requisiti di affidabilità riguardano il fallimento del servizio. Determinano il tasso di guasto massimo consentito del sistema software e possono fare riferimento all'intero sistema oa una o più delle sue funzioni separate.

Efficienza

Si occupa delle risorse hardware necessarie per eseguire le diverse funzioni del sistema software. Comprende le capacità di elaborazione (espresse in MHz), la capacità di archiviazione (espressa in MB o GB) e la capacità di comunicazione dei dati (espressa in MBPS o GBPS).

Si occupa anche del tempo che intercorre tra la ricarica delle unità portatili del sistema, come le unità del sistema informativo situate in computer portatili o le unità meteorologiche poste all'aperto.

Integrità

Questo fattore si occupa della sicurezza del sistema software, cioè di impedire l'accesso a persone non autorizzate, anche per distinguere tra il gruppo di persone a cui dare il permesso di lettura e quello di scrittura.

Usabilità

I requisiti di usabilità riguardano le risorse del personale necessarie per formare un nuovo dipendente e per far funzionare il sistema software.

Fattori di qualità della revisione del prodotto

Secondo il modello di McCall, tre fattori di qualità del software sono inclusi nella categoria di revisione del prodotto. Questi fattori sono i seguenti:

Manutenibilità

Questo fattore considera gli sforzi che saranno necessari agli utenti e al personale di manutenzione per identificare le ragioni dei guasti del software, correggere i guasti e verificare il successo delle correzioni.

Flessibilità

Questo fattore si occupa delle capacità e degli sforzi necessari per supportare le attività di manutenzione adattiva del software. Questi includono l'adattamento del software corrente a circostanze e clienti aggiuntivi senza modificare il software. I requisiti di questo fattore supportano anche attività di manutenzione perfettiva, come modifiche e aggiunte al software al fine di migliorarne il servizio e adattarlo ai cambiamenti nell'ambiente tecnico o commerciale dell'azienda.

Testabilità

I requisiti di testabilità riguardano il collaudo del sistema software e il suo funzionamento. Include risultati intermedi predefiniti, file di registro e anche la diagnostica automatica eseguita dal sistema software prima dell'avvio del sistema, per scoprire se tutti i componenti del sistema sono funzionanti e per ottenere un rapporto sui guasti rilevati. Un altro tipo di questi requisiti riguarda i controlli diagnostici automatici applicati dai tecnici di manutenzione per rilevare le cause dei guasti del software.

Fattore di qualità del software di transizione del prodotto

Secondo il modello di McCall, tre fattori di qualità del software sono inclusi nella categoria di transizione del prodotto che si occupa dell'adattamento del software ad altri ambienti e della sua interazione con altri sistemi software. Questi fattori sono i seguenti:

Portabilità

I requisiti di portabilità tendono all'adattamento di un sistema software ad altri ambienti costituiti da hardware diverso, diversi sistemi operativi e così via. Il software dovrebbe poter continuare a utilizzare lo stesso software di base in diverse situazioni.

Riusabilità

Questo fattore riguarda l'uso di moduli software originariamente progettati per un progetto in un nuovo progetto software attualmente in fase di sviluppo. Possono anche consentire a progetti futuri di utilizzare un dato modulo o un gruppo di moduli del software attualmente sviluppato. Il riutilizzo del software dovrebbe consentire di risparmiare risorse di sviluppo, abbreviare il periodo di sviluppo e fornire moduli di qualità superiore.

Interoperabilità

I requisiti di interoperabilità si concentrano sulla creazione di interfacce con altri sistemi software o con il firmware di altre apparecchiature. Ad esempio, il firmware dei macchinari di produzione e delle apparecchiature di collaudo si interfaccia con il software di controllo della produzione.

Software Quality Assurance(SQA) è un insieme di attività per garantire la qualità nei processi di ingegneria del software. Assicura che il software sviluppato soddisfi e rispetti le specifiche di qualità definite o standardizzate. SQA è un processo continuo all'interno del ciclo di vita dello sviluppo del software (SDLC) che controlla regolarmente il software sviluppato per garantire che soddisfi le misure di qualità desiderate.

Le pratiche SQA sono implementate nella maggior parte dei tipi di sviluppo software, indipendentemente dal modello di sviluppo software sottostante utilizzato. SQA incorpora e implementa metodologie di test del software per testare il software. Piuttosto che controllare la qualità dopo il completamento, i processi SQA verificano la qualità in ogni fase dello sviluppo, fino al completamento del software. Con SQA, il processo di sviluppo del software passa alla fase successiva solo una volta che la fase corrente / precedente soddisfa gli standard di qualità richiesti. SQA generalmente funziona su uno o più standard di settore che aiutano nella creazione di linee guida sulla qualità del software e strategie di implementazione.

Comprende le seguenti attività:

• Definizione e implementazione del processo
• Auditing
• Training

I processi potrebbero essere -

• Metodologia di sviluppo del software
• Gestione di progetto
• Gestione della configurazione
• Sviluppo / gestione dei requisiti
• Estimation
• Progettazione software
• Test, ecc.

Una volta che i processi sono stati definiti e implementati, Quality Assurance ha le seguenti responsabilità:

• Identifica i punti deboli nei processi
• Correggere questi punti deboli per migliorare continuamente il processo

Componenti del sistema SQA

Un sistema SQA combina sempre un'ampia gamma di componenti SQA. Questi componenti possono essere classificati nelle seguenti sei classi:

Componenti pre-progetto

Ciò garantisce che gli impegni del progetto siano stati chiaramente definiti considerando le risorse richieste, la tempistica e il budget; e i piani di sviluppo e qualità sono stati determinati correttamente.

Componenti della valutazione delle attività del ciclo di vita del progetto

Il ciclo di vita del progetto si compone di due fasi: la fase del ciclo di vita di sviluppo e la fase di funzionamento – manutenzione.

I componenti della fase del ciclo di vita dello sviluppo rilevano gli errori di progettazione e programmazione. I suoi componenti sono suddivisi nelle seguenti sottoclassi: Recensioni, Opinioni di esperti e Test del software.

I componenti SQA utilizzati durante la fase di funzionamento – manutenzione includono componenti di manutenzione specializzati e componenti del ciclo di vita di sviluppo, che vengono applicati principalmente per funzionalità per migliorare le attività di manutenzione.

Componenti di prevenzione e miglioramento degli errori infrastrutturali

L'obiettivo principale di questi componenti, che viene applicato all'intera organizzazione, è eliminare o almeno ridurre il tasso di errori, sulla base dell'esperienza SQA accumulata dall'organizzazione.

Componenti della gestione della qualità del software

Questa classe di componenti si occupa di diversi obiettivi, come il controllo delle attività di sviluppo e manutenzione e l'introduzione di azioni precoci di supporto manageriale che principalmente prevengono o riducono al minimo gli errori di pianificazione e budget ei relativi risultati.

Componenti di standardizzazione, certificazione e valutazione del sistema SQA

Questi componenti implementano standard professionali e manageriali internazionali all'interno dell'organizzazione. Gli obiettivi principali di questa classe sono l'utilizzo delle conoscenze professionali internazionali, il miglioramento del coordinamento dei sistemi di qualità organizzativa con altre organizzazioni e la valutazione dei risultati dei sistemi di qualità secondo una scala comune. I vari standard possono essere classificati in due gruppi principali: standard di gestione della qualità e standard di processo del progetto.

Organizzare per SQA - i componenti umani

La base organizzativa SQA include manager, personale addetto ai test, l'unità SQA e le persone interessate alla qualità del software come i trustee SQA, i membri del comitato SQA e i membri del forum SQA. I loro obiettivi principali sono avviare e supportare l'implementazione dei componenti SQA, rilevare deviazioni dalle procedure e metodologie SQA e suggerire miglioramenti.

Componenti di qualità del software pre-progetto

Questi componenti aiutano a migliorare le fasi preliminari intraprese prima di iniziare un progetto. Include:

• Revisione del contratto
• Piani di sviluppo e qualità

Revisione del contratto

Normalmente, un software viene sviluppato per un contratto negoziato con un cliente o per un ordine interno per sviluppare un firmware da incorporare all'interno di un prodotto hardware. In tutti questi casi, l'unità di sviluppo è impegnata in una specifica funzionale, un budget e un programma concordati. Pertanto, le attività di revisione del contratto devono includere un esame dettagliato della bozza della proposta di progetto e delle bozze del contratto.

Nello specifico, le attività di revisione del contratto includono:

• Chiarimento delle esigenze del cliente

• Revisione della pianificazione del progetto e delle stime dei requisiti di risorse

• Valutazione della capacità del personale professionale di realizzare il progetto proposto

• Valutazione della capacità del cliente di adempiere ai propri obblighi

• Valutazione dei rischi di sviluppo

Piani di sviluppo e qualità

Dopo aver firmato il contratto di sviluppo software con un'organizzazione o un dipartimento interno della stessa organizzazione, viene preparato un piano di sviluppo del progetto e le sue attività integrate di garanzia della qualità. Questi piani includono dettagli aggiuntivi e revisioni necessarie sulla base di piani precedenti che hanno fornito la base per l'attuale proposta e contratto.

Il più delle volte, sono necessari diversi mesi tra la presentazione dell'offerta e la firma del contratto. Durante questo periodo, le risorse come la disponibilità del personale e le capacità professionali possono essere modificate. I piani vengono quindi rivisti per riflettere i cambiamenti avvenuti nel frattempo.

Le principali questioni trattate nel piano di sviluppo del progetto sono:

• Schedules
• Manodopera e risorse hardware richieste
• Valutazioni dei rischi
• Questioni organizzative: membri del team, subappaltatori e partnership
• Metodologia del progetto, strumenti di sviluppo, ecc.
• Piani di riutilizzo del software

Le principali questioni trattate nel piano di qualità del progetto sono:

• Obiettivi di qualità, espressi nei termini misurabili appropriati

• Criteri per l'inizio e la fine di ogni fase del progetto

• Elenchi di revisioni, test e altre attività di verifica e convalida programmate

Le metriche del software possono essere classificate in tre categorie:

• Product metrics - Descrive le caratteristiche del prodotto come dimensioni, complessità, caratteristiche del design, prestazioni e livello di qualità.

• Process metrics - Queste caratteristiche possono essere utilizzate per migliorare le attività di sviluppo e manutenzione del software.

• Project metrics- Queste metriche descrivono le caratteristiche e l'esecuzione del progetto. Gli esempi includono il numero di sviluppatori software, il modello di personale durante il ciclo di vita del software, il costo, la pianificazione e la produttività.

Alcune metriche appartengono a più categorie. Ad esempio, le metriche di qualità in-process di un progetto sono sia metriche di processo che metriche di progetto.

Software quality metricssono un sottoinsieme di metriche software che si concentrano sugli aspetti di qualità del prodotto, processo e progetto. Questi sono più strettamente associati alle metriche di processo e di prodotto che a quelle di progetto.

Le metriche sulla qualità del software possono essere ulteriormente suddivise in tre categorie:

• Metriche di qualità del prodotto
• Metriche di qualità in-process
• Metriche della qualità della manutenzione

Metriche di qualità del prodotto

Queste metriche includono quanto segue:

• Tempo medio per il fallimento
• Densità dei difetti
• Problemi del cliente
• Soddisfazione del cliente

Tempo medio per il fallimento

È il tempo tra i fallimenti. Questa metrica viene utilizzata principalmente con sistemi critici per la sicurezza come i sistemi di controllo del traffico aereo, l'avionica e le armi.

Densità dei difetti

Misura i difetti relativi alla dimensione del software espressa come righe di codice o punto funzione, ecc., Ovvero misura la qualità del codice per unità. Questa metrica viene utilizzata in molti sistemi software commerciali.

Problemi del cliente

Misura i problemi che i clienti incontrano durante l'utilizzo del prodotto. Contiene la prospettiva del cliente rispetto allo spazio problematico del software, che include i problemi non orientati ai difetti insieme ai problemi relativi ai difetti.

La metrica dei problemi viene solitamente espressa in termini di Problems per User-Month (PUM).

PUM = Total Problems that customers reported (true defect and non-defect oriented 
problems) for a time period + Total number of license months of the software during 
the period

Dove,

Number of license-month of the software = Number of install license of the software × 
Number of months in the calculation period

Il PUM viene solitamente calcolato per ogni mese successivo al rilascio del software sul mercato e anche per le medie mensili per anno.

Soddisfazione del cliente

La soddisfazione del cliente viene spesso misurata dai dati dei sondaggi sui clienti attraverso la scala a cinque punti:

• Molto soddisfatto
• Satisfied
• Neutral
• Dissatisfied
• Molto insoddisfatto

La soddisfazione per la qualità complessiva del prodotto e le sue dimensioni specifiche si ottiene solitamente attraverso diversi metodi di indagine sui clienti. Sulla base dei dati su scala a cinque punti, è possibile costruire e utilizzare diverse metriche con lievi variazioni, a seconda dello scopo dell'analisi. Ad esempio:

• Percentuale di clienti completamente soddisfatti
• Percentuale di clienti soddisfatti
• Percentuale di clienti insoddisfatti
• Percentuale di clienti non soddisfatti

Di solito, viene utilizzata questa percentuale di soddisfazione.

Metriche di qualità in-process

Le metriche di qualità in-process si occupano del monitoraggio dell'arrivo dei difetti durante i test formali delle macchine per alcune organizzazioni. Questa metrica include:

• Densità dei difetti durante il test della macchina
• Schema di arrivo dei difetti durante il test della macchina
• Schema di rimozione dei difetti basato sulla fase
• Efficacia di rimozione dei difetti

Densità dei difetti durante il test della macchina

La percentuale di difetti durante il test formale della macchina (test dopo che il codice è stato integrato nella libreria di sistema) è correlata con la percentuale di difetti sul campo. Le percentuali di errore più elevate rilevate durante il test sono un indicatore che il software ha riscontrato una maggiore iniezione di errori durante il processo di sviluppo, a meno che la percentuale di errori di test più elevata sia dovuta a uno straordinario sforzo di test.

Questa semplice metrica dei difetti per KLOC o punto funzione è un buon indicatore di qualità, mentre il software è ancora in fase di test. È particolarmente utile monitorare le versioni successive di un prodotto nella stessa organizzazione di sviluppo.

Schema di arrivo dei difetti durante il test della macchina

La densità complessiva dei difetti durante il test fornirà solo il riepilogo dei difetti. Il modello di arrivo dei difetti fornisce maggiori informazioni sui diversi livelli di qualità sul campo. Include quanto segue:

• Gli arrivi di difetti o difetti segnalati durante la fase di test per intervallo di tempo (ad esempio, settimana). Qui non saranno tutti difetti validi.

• Il modello di arrivi di difetti validi quando viene eseguita la determinazione del problema sui problemi segnalati. Questo è il vero modello di difetto.

• Il modello degli straordinari arretrati di difetti. Questa metrica è necessaria perché le organizzazioni di sviluppo non possono indagare e risolvere immediatamente tutti i problemi segnalati. Questa è una dichiarazione del carico di lavoro e una dichiarazione di qualità. Se il backlog di difetti è elevato alla fine del ciclo di sviluppo e molte correzioni devono ancora essere integrate nel sistema, la stabilità del sistema (quindi la sua qualità) ne risentirà. È necessario ripetere il test (test di regressione) per garantire il raggiungimento dei livelli di qualità del prodotto mirati.

Schema di rimozione dei difetti basato sulla fase

Questa è un'estensione della metrica della densità dei difetti durante il test. Oltre al test, tiene traccia dei difetti in tutte le fasi del ciclo di sviluppo, comprese le revisioni del progetto, le ispezioni del codice e le verifiche formali prima del test.

Poiché una grande percentuale di difetti di programmazione è correlata a problemi di progettazione, l'esecuzione di revisioni formali o verifiche funzionali per migliorare la capacità di rimozione dei difetti del processo sul front-end riduce gli errori nel software. Il modello di rimozione dei difetti basata sulla fase riflette la capacità complessiva di rimozione dei difetti del processo di sviluppo.

Per quanto riguarda le metriche per le fasi di progettazione e codifica, oltre ai tassi di difetto, molte organizzazioni di sviluppo utilizzano metriche come la copertura dell'ispezione e lo sforzo di ispezione per la gestione della qualità in-process.

Efficacia di rimozione dei difetti

Può essere definito come segue:

$$DRE = \frac{Defect \: removed \: during \: a \: development\:phase }{Defects\: latent \: in \: the\: product} \times 100\%$$

Questa metrica può essere calcolata per l'intero processo di sviluppo, per il front-end prima dell'integrazione del codice e per ogni fase. È chiamatoearly defect removal se utilizzato per il front-end e phase effectivenessper fasi specifiche. Maggiore è il valore della metrica, più efficace è il processo di sviluppo e minori sono i difetti passati alla fase successiva o al campo. Questa metrica è un concetto chiave del modello di rimozione dei difetti per lo sviluppo del software.

Metriche della qualità della manutenzione

Sebbene non si possa fare molto per alterare la qualità del prodotto durante questa fase, di seguito sono riportate le correzioni che possono essere effettuate per eliminare i difetti il ​​prima possibile con un'eccellente qualità di correzione.

• Correzione del backlog e dell'indice di gestione del backlog
• Correggi i tempi di risposta e fissa la reattività
• Percentuale di correzioni delinquenti
• Qualità della correzione

Correzione del backlog e dell'indice di gestione del backlog

La correzione degli arretrati è correlata al tasso di arrivi di difetti e alla velocità con cui si rendono disponibili le soluzioni per i problemi segnalati. È un semplice conteggio dei problemi segnalati che rimangono alla fine di ogni mese o ogni settimana. Usandolo nel formato di un grafico di tendenza, questa metrica può fornire informazioni significative per la gestione del processo di manutenzione.

Backlog Management Index (BMI) viene utilizzato per gestire il backlog di problemi aperti e irrisolti.

$$BMI = \frac{Number \: of \: problems \: closed \: during \:the \:month }{Number \: of \: problems \: arrived \: during \:the \:month} \times 100\%$$

Se il BMI è maggiore di 100, significa che il backlog è ridotto. Se il BMI è inferiore a 100, il backlog è aumentato.

Correggi i tempi di risposta e fissa la reattività

La metrica del tempo di risposta della correzione viene solitamente calcolata come il tempo medio di tutti i problemi dall'apertura alla chiusura. Il breve tempo di risposta fisso porta alla soddisfazione del cliente.

Gli elementi importanti della reattività della correzione sono le aspettative del cliente, il tempo concordato per la correzione e la capacità di soddisfare il proprio impegno nei confronti del cliente.

Percentuale di correzioni delinquenti

Viene calcolato come segue:

$Percent \:Delinquent\: Fixes =$

$\frac{Number \: of \: fixes \: that\: exceeded \: the \:response \:time\:criteria\:by\:ceverity\:level}{Number \: of \: fixes \: delivered \: in \:a \:specified \:time} \times 100\%$

Qualità della correzione

La qualità delle correzioni o il numero di correzioni difettose è un'altra metrica di qualità importante per la fase di manutenzione. Una correzione è difettosa se non ha risolto il problema segnalato o se ha risolto il problema originale ma ha inserito un nuovo difetto. Per il software mission-critical, le correzioni difettose sono dannose per la soddisfazione del cliente. La metrica della percentuale di correzioni difettose è la percentuale di tutte le correzioni in un intervallo di tempo difettoso.

Una correzione difettosa può essere registrata in due modi: registrarla nel mese in cui è stata rilevata o registrarla nel mese in cui è stata consegnata. Il primo è una misura del cliente; la seconda è una misura di processo. La differenza tra le due date è il periodo di latenza della correzione difettosa.

Di solito, maggiore è la latenza, maggiori saranno i clienti che ne risentiranno. Se il numero di difetti è elevato, il valore piccolo della metrica percentuale mostrerà un'immagine ottimistica. L'obiettivo di qualità per il processo di manutenzione, ovviamente, è zero correzioni difettose senza delinquenza.

La misurazione è l'azione di misurare qualcosa. È l'assegnazione di un numero a una caratteristica di un oggetto o di un evento, che può essere confrontato con altri oggetti o eventi.

Formalmente può essere definito come il processo mediante il quale numeri o simboli vengono assegnati agli attributi di entità nel mondo reale, in modo tale da descriverli secondo regole chiaramente definite.

Misurazione nella vita quotidiana

La misurazione non viene utilizzata solo da tecnici professionisti, ma anche da tutti noi nella vita di tutti i giorni. In un negozio, il prezzo funge da misura del valore di un articolo. Allo stesso modo, le misurazioni dell'altezza e delle dimensioni assicureranno se il tessuto si adatta correttamente o meno. Pertanto, la misurazione ci aiuterà a confrontare un articolo con un altro.

La misurazione prende le informazioni sugli attributi delle entità. Un'entità è un oggetto come una persona o un evento come un viaggio nel mondo reale. Un attributo è una caratteristica o una proprietà di un'entità come l'altezza di una persona, il costo di un viaggio, ecc. Nel mondo reale, anche se stiamo pensando di misurare le cose, in realtà stiamo misurando gli attributi di quelle cose.

Gli attributi sono per lo più definiti da numeri o simboli. Ad esempio, il prezzo può essere specificato in numero di rupie o dollari, la taglia dell'abbigliamento può essere specificata in termini di piccola, media, grande.

La precisione di una misurazione dipende dallo strumento di misurazione e dalla definizione della misurazione. Dopo aver ottenuto le misurazioni, dobbiamo analizzarle e dobbiamo trarre conclusioni sulle entità.

La misurazione è una quantificazione diretta mentre il calcolo è indiretto in cui combiniamo diverse misurazioni utilizzando alcune formule.

Misurazione in ingegneria del software

L'ingegneria del software implica la gestione, la determinazione dei costi, la pianificazione, la modellazione, l'analisi, la specifica, la progettazione, l'implementazione, il test e la manutenzione dei prodotti software. Quindi, la misurazione gioca un ruolo significativo nell'ingegneria del software. Sarà necessario un approccio rigoroso per misurare gli attributi di un prodotto software.

Per la maggior parte dei progetti di sviluppo,

• Non riusciamo a fissare obiettivi misurabili per i nostri prodotti software
• Non riusciamo a comprendere e quantificare il costo dei componenti dei progetti software
• Non quantificiamo né prevediamo la qualità dei prodotti che produciamo

Pertanto, per controllare i prodotti software, è necessaria la misurazione degli attributi. Ogni azione di misurazione deve essere motivata da un obiettivo o esigenza particolare che sia chiaramente definito e facilmente comprensibile. Gli obiettivi di misurazione devono essere specifici, provati su ciò che devono sapere manager, sviluppatori e utenti. La misurazione è necessaria per valutare lo stato del progetto, del prodotto, dei processi e delle risorse.

Nell'ingegneria del software, la misurazione è essenziale per le seguenti tre attività di base:

• Per capire cosa sta succedendo durante lo sviluppo e la manutenzione
• Per controllare cosa sta succedendo nel progetto
• Per migliorare processi e obiettivi

La teoria rappresentazionale della misurazione

La misurazione ci dice le regole che gettano le basi per lo sviluppo e il ragionamento su tutti i tipi di misurazione. È la mappatura dal mondo empirico al mondo relazionale formale. Di conseguenza, una misura è il numero o il simbolo assegnato a un'entità da questa mappatura per caratterizzare un'entità.

Relazioni empiriche

Nel mondo reale, comprendiamo le cose confrontandole, non assegnandole numeri.

Ad esempio, per confrontare l'altezza, utilizziamo i termini "più alto di", più alto di ". Quindi, questi "più alti di", più alti di "sono relazioni empiriche per l'altezza.

Possiamo definire più di una relazione empirica sullo stesso insieme.

Ad esempio, X è più alto di Y. X, Y sono molto più alti di Z.

Le relazioni empiriche possono essere unarie, binarie, ternarie, ecc.

X è alto, Y non è alto sono relazioni unarie.

X è più alto di Y è una relazione binaria.

Le relazioni empiriche nel mondo reale possono essere mappate in un mondo matematico formale. Per lo più queste relazioni riflettono le preferenze personali.

Alcune delle tecniche di mappatura o valutazione utilizzate per mappare queste relazioni empiriche con il mondo matematico sono le seguenti:

Scala Likert

Qui, agli utenti verrà fornita una dichiarazione sulla quale devono essere d'accordo o in disaccordo.

For example - Questo software funziona bene.

Completamente d'accordo	Essere d'accordo	Nè d'accordo né in disaccordo	Disaccordo	Fortemente disgustato

Classifica forzata

Ordina le alternative fornite da 1 (migliore) a n (peggiore).

Ad esempio: classificare i seguenti 5 moduli software in base alle loro prestazioni.

Nome del modulo	Rango
Modulo A
Modulo B
Modulo C
Modulo D
Modulo E

Scala di frequenza verbale

For example - Quanto spesso questo programma fallisce?

Sempre	Spesso	A volte	Raramente	Mai

Scala ordinale

Qui, agli utenti verrà fornito un elenco di alternative e dovranno selezionarne una.

For example - Quanto spesso questo programma fallisce?

• Hourly
• Daily
• Weekly
• Monthly
• Diverse volte all'anno
• Una o due volte all'anno
• Never

Scala comparativa

Qui l'utente deve fornire un numero confrontando le diverse opzioni.

Very superiorAbout the sameVery inferior

12345678910

Scala numerica

Qui l'utente deve dare un numero in base alla sua importanza.

UnimportantImportant

12345678910

Le regole della mappatura

Per eseguire la mappatura, dobbiamo specificare il dominio, l'intervallo e le regole per eseguire la mappatura.

For example - Dominio - Mondo reale

• Range - Mondo matematico come numeri interi, numero reale, ecc.

• Rules - Per misurare l'altezza, scarpe da indossare o meno

Allo stesso modo, in caso di misurazione software, la lista di controllo della dichiarazione da includere nelle righe di codice da specificare.

La condizione rappresentativa della misurazione

La condizione rappresentativa afferma che una mappatura di misurazione (M) devono mappare le entità in numeri e le relazioni empiriche in relazioni numeriche in modo tale che le relazioni empiriche preservino e siano preservate dalle relazioni numeriche.

Ad esempio: la relazione empirica "più alto di" è mappata alla relazione numerica ">". X is taller than Y, if and only if M(X) > M(Y)

Poiché possono esserci molte relazioni su un dato insieme, anche la condizione rappresentazionale ha implicazioni per ciascuna di queste relazioni.

Per la relazione unaria "è alto", potremmo avere la relazione numerica

X > 50

La condizione rappresentativa lo richiede per qualsiasi misura M,

X is tall if and only if M(X) > 50

Fasi chiave della misurazione formale

Le fasi chiave della misurazione possono essere riassunte come segue:

I modelli sono utili per interpretare il comportamento degli elementi numerici delle entità del mondo reale e misurarli. Per aiutare il processo di misurazione, il modello della mappatura dovrebbe anche essere integrato con un modello del dominio della mappatura. Un modello dovrebbe anche specificare in che modo queste entità sono correlate agli attributi e come si relazionano le caratteristiche.

La misurazione è di due tipi:

• Misurazione diretta
• Misurazione indiretta

Misurazione diretta

Queste sono le misurazioni che possono essere misurate senza il coinvolgimento di altre entità o attributi.

Le seguenti misure dirette sono comunemente utilizzate nell'ingegneria del software.

• Lunghezza del codice sorgente di LOC
• Durata dello scopo del test in base al tempo trascorso
• Numero di difetti rilevati durante il processo di test contando i difetti
• Il tempo che un programmatore dedica a un programma

Misurazione indiretta

Queste sono misurazioni che possono essere misurate in termini di qualsiasi altra entità o attributo.

Le seguenti misure indirette sono comunemente utilizzate nell'ingegneria del software.

$$\small Programmer\:Productivity = \frac{LOC \: produced }{Person \:months \:of \:effort}$$

$\small Module\:Defect\:Density = \frac{Number \:of\:defects}{Module \:size}$

$$\small Defect\:Detection\:Efficiency = \frac{Number \:of\:defects\:detected}{Total \:number \:of\:defects}$$

$\small Requirement\:Stability = \frac{Number \:of\:initial\:requirements}{Total \:number \:of\:requirements}$

$\small Test\:Effectiveness\:Ratio = \frac{Number \:of\:items\:covered}{Total \:number \:of \:items}$

$\small System\:spoilage = \frac{Effort \:spent\:for\:fixing\:faults}{Total \:project \:effort}$

Misurazione per la previsione

Per allocare le risorse appropriate al progetto, dobbiamo prevedere lo sforzo, il tempo e il costo per lo sviluppo del progetto. La misurazione per la previsione richiede sempre un modello matematico che colleghi gli attributi da prevedere a qualche altro attributo che possiamo misurare ora. Quindi, un sistema di previsione è costituito da un modello matematico insieme a una serie di procedure di previsione per determinare i parametri sconosciuti e interpretare i risultati.

Le scale di misurazione sono le mappature utilizzate per rappresentare il sistema di relazioni empiriche. È principalmente di 5 tipi:

• Scala nominale
• Scala ordinale
• Scala degli intervalli
• Scala del rapporto
• Scala assoluta

Scala nominale

Posiziona gli elementi in uno schema di classificazione. Le lezioni non verranno ordinate. Ogni entità dovrebbe essere collocata in una particolare classe o categoria in base al valore dell'attributo.

Ha due caratteristiche principali:

• Il sistema di relazioni empiriche consiste solo di classi differenti; non esiste la nozione di ordinamento tra le classi.

• Qualsiasi numerazione distinta o rappresentazione simbolica delle classi è una misura accettabile, ma non esiste alcuna nozione di grandezza associata ai numeri o ai simboli.

Scala ordinale

Posiziona gli elementi in uno schema di classificazione ordinato. Ha le seguenti caratteristiche:

• Il sistema di relazioni empiriche è costituito da classi ordinate rispetto all'attributo.

• Qualsiasi mappatura che preserva l'ordine è accettabile.

• I numeri rappresentano solo la classifica. Quindi, addizione, sottrazione e altre operazioni aritmetiche non hanno significato.

Scala degli intervalli

Questa scala acquisisce le informazioni sulla dimensione degli intervalli che separano la classificazione. Quindi, è più potente della scala nominale e della scala ordinale.

Ha le seguenti caratteristiche:

• Conserva l'ordine come la scala ordinale.

• Conserva le differenze ma non il rapporto.

• L'addizione e la sottrazione possono essere eseguite su questa scala ma non la moltiplicazione o la divisione.

Se un attributo è misurabile su una scala di intervalli, e M e M’ sono mappature che soddisfano la condizione di rappresentazione, quindi possiamo sempre trovare due numeri a e b tale che,

M = aM '+ b

Scala del rapporto

Questa è la scala di misurazione più utile. Qui esiste una relazione empirica per catturare i rapporti. Ha le seguenti caratteristiche:

• È una mappatura delle misurazioni che preserva l'ordine, la dimensione degli intervalli tra le entità e il rapporto tra le entità.

• C'è un elemento zero, che rappresenta la totale mancanza degli attributi.

• La mappatura delle misurazioni deve iniziare da zero e aumentare a intervalli uguali, noti come unità.

• Possono essere applicate tutte le operazioni aritmetiche.

Qui, la mappatura sarà della forma

M = aM’

Dove ‘a’ è uno scalare positivo.

Scala assoluta

Su questa scala, ci sarà solo una possibile misura per un attributo. Quindi, l'unica trasformazione possibile sarà la trasformazione dell'identità.

Ha le seguenti caratteristiche:

• La misurazione viene effettuata contando il numero di elementi nell'insieme di entità.

• L'attributo assume sempre la forma "numero di occorrenze di x nell'entità".

• Esiste una sola mappatura delle misurazioni possibile, ovvero il conteggio effettivo.

• Tutte le operazioni aritmetiche possono essere eseguite sul conteggio risultante.

Le indagini empiriche implicano l'indagine scientifica di qualsiasi strumento, tecnica o metodo. Questa indagine contiene principalmente i seguenti 4 principi.

• Scegliere una tecnica di indagine
• Affermare l'ipotesi
• Mantenere il controllo sulla variabile
• Rendere significativa l'indagine

Scegliere una tecnica di indagine

I componenti chiave dell'indagine empirica nell'ingegneria del software sono:

• Survey
• Argomento di studio
• Esperimento formale

Sondaggio

Il sondaggio è lo studio retrospettivo di una situazione per documentare relazioni e risultati. Viene sempre eseguito dopo che si è verificato un evento. Ad esempio, nell'ingegneria del software, è possibile eseguire sondaggi per determinare come gli utenti hanno reagito a un particolare metodo, strumento o tecnica per determinare tendenze o relazioni.

In questo caso, non abbiamo alcun controllo sulla situazione in questione. Possiamo registrare una situazione e confrontarla con una simile.

Argomento di studio

È una tecnica di ricerca in cui si identificano i fattori chiave che possono influenzare il risultato di un'attività e quindi si documenta l'attività: input, vincoli, risorse e output.

Esperimento formale

È un'indagine rigorosa e controllata di un'attività, in cui i fattori chiave vengono identificati e manipolati per documentare i loro effetti sul risultato.

Un particolare metodo di indagine può essere scelto secondo le seguenti linee guida:

• Se l'attività è già avvenuta, possiamo eseguire sondaggi o case study. Se deve ancora verificarsi, è possibile scegliere il caso di studio o l'esperimento formale.

• Se abbiamo un alto livello di controllo sulle variabili che possono influenzare il risultato, allora possiamo usare un esperimento. Se non abbiamo alcun controllo sulla variabile, il caso di studio sarà una tecnica preferita.

• Se la replica non è possibile a livelli più alti, non è possibile sperimentare.

• Se il costo della replica è basso, possiamo considerare un esperimento.

Affermare l'ipotesi

Per stimolare la decisione di una particolare tecnica di indagine, l'obiettivo della ricerca dovrebbe essere espresso come un'ipotesi che vogliamo testare. L'ipotesi è la teoria provvisoria o la supposizione che il programmatore pensa spieghi il comportamento che vuole esplorare.

Mantenere il controllo sulle variabili

Dopo aver affermato l'ipotesi, dobbiamo decidere le diverse variabili che influenzano la sua verità e quanto controllo abbiamo su di essa. Ciò è essenziale perché il discriminatore chiave tra l'esperimento e gli studi di casi è il grado di controllo sulla variabile che influenza il comportamento.

Una variabile di stato che è il fattore che può caratterizzare il progetto e può anche influenzare i risultati della valutazione viene utilizzata per distinguere la situazione di controllo da quella sperimentale nell'esperimento formale. Se non possiamo differenziare il controllo dall'esperimento, la tecnica del caso di studio sarà quella preferita.

Ad esempio, se vogliamo determinare se un cambiamento nel linguaggio di programmazione può influire sulla produttività del progetto, il linguaggio sarà una variabile di stato. Supponiamo di utilizzare attualmente FORTRAN che vogliamo sostituire con Ada. Quindi FORTRAN sarà il linguaggio di controllo e Ada sarà quello sperimentale.

Rendere significativa l'indagine

I risultati di un esperimento sono generalmente più generalizzabili dello studio di un caso o del sondaggio. I risultati del caso di studio o del sondaggio possono normalmente essere applicabili solo a una particolare organizzazione. I seguenti punti dimostrano l'efficacia di queste tecniche per rispondere a una serie di domande.

Teorie conformi e saggezza convenzionale

Casi di studio o sondaggi possono essere utilizzati per conformare l'efficacia e l'utilità della saggezza convenzionale e di molti altri standard, metodi o strumenti in una singola organizzazione. Tuttavia, un esperimento formale può indagare le situazioni in cui le affermazioni sono generalmente vere.

Esplorare le relazioni

La relazione tra i vari attributi delle risorse e dei prodotti software può essere suggerita da un caso di studio o da un'indagine.

Ad esempio, un'indagine sui progetti completati può rivelare che un software scritto in una particolare lingua ha meno difetti di un software scritto in altre lingue.

Comprendere e verificare queste relazioni è essenziale per il successo di qualsiasi progetto futuro. Ciascuna di queste relazioni può essere espressa come un'ipotesi e un esperimento formale può essere progettato per verificare il grado di tenuta delle relazioni. Di solito, il valore di un particolare attributo viene osservato mantenendo costanti o sotto controllo altri attributi.

Valutazione dell'accuratezza dei modelli

I modelli vengono solitamente utilizzati per prevedere il risultato di un'attività o per guidare l'uso di un metodo o strumento. Presenta un problema particolarmente difficile quando si progetta un esperimento o un caso di studio, perché le loro previsioni spesso influenzano il risultato. I project manager spesso trasformano le previsioni in obiettivi da completare. Questo effetto è comune quando vengono utilizzati i modelli di costo e di pianificazione.

Alcuni modelli come i modelli di affidabilità non influenzano il risultato, poiché l'affidabilità misurata come tempo medio al guasto non può essere valutata finché il software non è pronto per l'uso sul campo.

Validazione delle misure

Esistono molte misure software per acquisire il valore di un attributo. Pertanto, è necessario condurre uno studio per verificare se una data misura riflette i cambiamenti nell'attributo che dovrebbe acquisire. La convalida viene eseguita correlando una misura con un'altra. Per convalidare dovrebbe essere utilizzata una seconda misura che sia anche una misura diretta e valida del fattore di influenza. Tali misure non sono sempre disponibili o facili da misurare. Inoltre, le misure utilizzate devono essere conformi alle nozioni umane del fattore misurato.

Il framework per la misurazione del software si basa su tre principi:

• Classificazione delle entità da esaminare
• Determinazione degli obiettivi di misurazione rilevanti
• Identificare il livello di maturità raggiunto dall'organizzazione

Classificazione delle entità da esaminare

Nell'ingegneria del software esistono principalmente tre classi di entità. Sono -

• Processes
• Products
• Resources

Tutte queste entità hanno entità interne ed esterne.

• Internal attributessono quelli che possono essere misurati puramente in termini di processo, prodotto o risorse stesse. Ad esempio: dimensioni, complessità, dipendenza tra i moduli.

• External attributessono quelli misurabili solo rispetto al suo rapporto con l'ambiente. Ad esempio: il numero totale di errori riscontrati da un utente, il tempo necessario per cercare nel database e recuperare le informazioni.

I diversi attributi che possono essere misurati per ciascuna delle entità sono i seguenti:

Processi

I processi sono raccolte di attività relative al software. Di seguito sono riportati alcuni degli attributi interni che possono essere misurati direttamente per un processo:

• La durata del processo o una delle sue attività

• Lo sforzo associato al processo o a una delle sue attività

• Il numero di incidenti di un tipo specifico verificatisi durante il processo o una delle sue attività

I diversi attributi esterni di un processo sono costo, controllabilità, efficacia, qualità e stabilità.

Prodotti

I prodotti non sono solo gli elementi che la direzione si impegna a fornire, ma anche qualsiasi artefatto o documento prodotto durante il ciclo di vita del software.

I diversi attributi interni del prodotto sono dimensione, impegno, costo, specifica, lunghezza, funzionalità, modularità, riutilizzo, ridondanza e correttezza sintattica. Tra queste dimensioni, impegno e costo sono relativamente facili da misurare rispetto agli altri.

I diversi attributi del prodotto esterno sono usabilità, integrità, efficienza, testabilità, riusabilità, portabilità e interoperabilità. Questi attributi descrivono non solo il codice ma anche gli altri documenti che supportano lo sforzo di sviluppo.

Risorse

Queste sono entità richieste da un'attività di processo. Può essere qualsiasi input per la produzione del software. Include personale, materiali, strumenti e metodi.

I diversi attributi interni delle risorse sono età, prezzo, dimensione, velocità, dimensione della memoria, temperatura, ecc. I diversi attributi esterni sono produttività, esperienza, qualità, usabilità, affidabilità, comfort ecc.

Determinazione degli obiettivi di misurazione pertinenti

Una particolare misurazione sarà utile solo se aiuta a comprendere il processo o uno dei suoi prodotti risultanti. Il miglioramento del processo o dei prodotti può essere eseguito solo quando il progetto ha obiettivi chiaramente definiti per processi e prodotti. Una chiara comprensione degli obiettivi può essere utilizzata per generare metriche suggerite per un dato progetto nel contesto di un quadro di maturità del processo.

Il paradigma Obiettivo-Domanda-Metrica (GQM)

L'approccio GQM fornisce una struttura che comprende i seguenti tre passaggi:

• Elenco degli obiettivi principali del progetto di sviluppo o manutenzione

• Derivare le domande da ogni obiettivo a cui è necessario rispondere per determinare se gli obiettivi vengono raggiunti

• Decidi cosa misurare per poter rispondere adeguatamente alle domande

Per utilizzare il paradigma GQM, per prima cosa esprimiamo gli obiettivi generali dell'organizzazione. Quindi, generiamo le domande in modo tale che le risposte siano note in modo da poter determinare se gli obiettivi vengono raggiunti. Successivamente, analizza ogni domanda in termini di quale misura abbiamo bisogno per rispondere a ciascuna domanda.

Gli obiettivi tipici sono espressi in termini di produttività, qualità, rischio, soddisfazione del cliente, ecc. Gli obiettivi e le domande devono essere costruiti in termini di pubblico.

Per aiutare a generare obiettivi, domande e metriche, Basili & Rombach ha fornito una serie di modelli.

• Purpose - (caratterizzare, valutare, prevedere, motivare, ecc.) (Processo, prodotto, modello, metrica, ecc.) Al fine di comprendere, valutare, gestire, ingegnerizzare, apprendere, migliorare, ecc. Example: Caratterizzare il prodotto per apprenderlo.

• Perspective - Esaminare il (costo, efficacia, correttezza, difetti, modifiche, misure del prodotto, ecc.) Dal punto di vista dello sviluppatore, manager, cliente, ecc. Example: Esaminare i difetti dal punto di vista del cliente.

• Environment - L'ambiente è costituito da quanto segue: fattori di processo, fattori persone, fattori problema, metodi, strumenti, vincoli, ecc. Example: I clienti di questo software sono coloro che non hanno alcuna conoscenza degli strumenti.

Misurazione e miglioramento dei processi

Normalmente la misurazione è utile per:

• Comprensione del processo e dei prodotti
• Stabilire una linea di base
• Accesso e previsione del risultato

A seconda del livello di maturità del processo fornito da SEI, il tipo di misurazione e il programma di misurazione saranno diversi. Di seguito sono riportati i diversi programmi di misurazione che possono essere applicati a ciascun livello di maturità.

Level 1: Ad hoc

A questo livello, gli input sono mal definiti, mentre gli output sono attesi. Il passaggio dall'ingresso all'uscita è indefinito e incontrollato. Per questo livello di maturità del processo, sono necessarie misurazioni di base per fornire un punto di partenza per la misurazione.

Level 2: Repeatable

A questo livello, gli input e gli output del processo, i vincoli e le risorse sono identificabili. Un processo ripetibile può essere descritto dal diagramma seguente.

Le misure di input possono essere le dimensioni e la volatilità dei requisiti. L'output può essere misurato in termini di dimensioni del sistema, risorse in termini di impegno del personale e vincoli in termini di costi e tempi.

Level 3: Defined

A questo livello vengono definite le attività intermedie e i loro input e output sono conosciuti e compresi. Un semplice esempio del processo definito è descritto nella figura seguente.

L'input e l'output delle attività intermedie possono essere esaminati, misurati e valutati.

Level 4: Managed

A questo livello, il feedback delle prime attività del progetto può essere utilizzato per stabilire le priorità per le attività correnti e successivamente per le attività del progetto. Possiamo misurare l'efficacia delle attività di processo. La misurazione riflette le caratteristiche del processo complessivo e dell'interazione tra e tra le principali attività.

Level 5: Optimizing

A questo livello, le misure delle attività vengono utilizzate per migliorare il processo rimuovendo e aggiungendo attività di processo e modificando dinamicamente la struttura del processo in risposta al feedback delle misurazioni. Pertanto, il cambiamento del processo può influenzare l'organizzazione e il progetto, nonché il processo. Il processo fungerà da sensori e monitor e possiamo modificare il processo in modo significativo in risposta ai segnali di allarme.

A un determinato livello di maturità, possiamo raccogliere le misurazioni per quel livello e per tutti i livelli inferiori.

Identificazione del livello di maturità

La maturità del processo suggerisce di misurare solo ciò che è visibile. Pertanto, la combinazione della maturità del processo con GQM fornirà le misure più utili.

• A level 1, è probabile che il progetto abbia requisiti mal definiti. A questo livello, la misurazione delle caratteristiche dei requisiti è difficile.

• A level 2, i requisiti sono ben definiti e possono essere raccolte informazioni aggiuntive come il tipo di ciascun requisito e il numero di modifiche a ciascun tipo.

• A level 3, le attività intermedie sono definite con criteri di ingresso e uscita per ciascuna attività

L'obiettivo e l'analisi della domanda saranno gli stessi, ma la metrica varierà con la maturità. Più maturo è il processo, più ricche saranno le misurazioni. Il paradigma GQM, di concerto con la maturità del processo, è stato utilizzato come base per diversi strumenti che assistono i manager nella progettazione di programmi di misurazione.

GQM aiuta a capire la necessità di misurare l'attributo e la maturità del processo suggerisce se siamo in grado di misurarlo in modo significativo. Insieme forniscono un contesto per la misurazione.

La convalida della misurazione del sistema software prevede due passaggi:

• Validazione dei sistemi di misura
• Convalida dei sistemi di previsione

Convalida dei sistemi di misurazione

Misure o sistemi di misurazione vengono utilizzati per valutare un'entità esistente caratterizzando numericamente uno o più dei suoi attributi. Una misura è valida se caratterizza accuratamente l'attributo che afferma di misurare.

La convalida di un sistema di misurazione del software è il processo per garantire che la misura sia una caratterizzazione numerica appropriata dell'attributo rivendicato mostrando che la condizione di rappresentazione è soddisfatta.

Per convalidare un sistema di misurazione, abbiamo bisogno sia di un modello formale che descriva le entità sia di una mappatura numerica che preservi l'attributo che stiamo misurando. Ad esempio, se ci sono due programmi P1 e P2 e vogliamo concatenare quei programmi, allora ci aspettiamo che qualsiasi misuram di lunghezza per soddisfarlo,

m (P1 + P2) = m (P1) + m (P2)

Se un programma P1 ha più lunghezza del programma P2, quindi qualsiasi misura m dovrebbe anche soddisfare,

m (P1)> m (P2)

La lunghezza del programma può essere misurata contando le righe di codice. Se questo conteggio soddisfa le relazioni di cui sopra, possiamo dire che le righe di codice sono una misura valida della lunghezza.

Il requisito formale per la convalida di una misura implica la dimostrazione che caratterizza l'attributo dichiarato nel senso della teoria della misurazione. La convalida può essere utilizzata per assicurarsi che i misuratori siano definiti correttamente e siano coerenti con il comportamento del mondo reale dell'entità.

Convalida dei sistemi di previsione

I sistemi di previsione vengono utilizzati per prevedere alcuni attributi di un'entità futura che coinvolge un modello matematico con procedure di previsione associate.

La convalida dei sistemi di previsione in un determinato ambiente è il processo per stabilire l'accuratezza del sistema di previsione con mezzi empirici, ovvero confrontando le prestazioni del modello con i dati noti in un determinato ambiente. Si tratta di sperimentazione e verifica di ipotesi.

Il grado di accuratezza accettabile per la convalida dipende dal fatto che il sistema di previsione sia deterministico o stocastico, nonché dalla persona che esegue la valutazione. Alcuni sistemi di previsione stocastici sono più stocastici di altri.

Esempi di sistemi di previsione stocastici sono sistemi come la stima dei costi del software, la stima dello sforzo, la stima del programma, ecc. Quindi, per convalidare formalmente un sistema di previsione, dobbiamo decidere quanto sia stocastico, quindi confrontare le prestazioni del sistema di previsione con i dati noti.

La metrica del software è uno standard di misura che contiene molte attività che implicano un certo grado di misurazione. Può essere classificato in tre categorie: metriche di prodotto, metriche di processo e metriche di progetto.

• Product metrics descrivere le caratteristiche del prodotto come dimensioni, complessità, caratteristiche del design, prestazioni e livello di qualità.

• Process metricspuò essere utilizzato per migliorare lo sviluppo e la manutenzione del software. Gli esempi includono l'efficacia della rimozione dei difetti durante lo sviluppo, il modello di test di arrivo dei difetti e il tempo di risposta del processo di correzione.

• Project metricsdescrivere le caratteristiche e l'esecuzione del progetto. Gli esempi includono il numero di sviluppatori software, il modello di personale durante il ciclo di vita del software, il costo, la pianificazione e la produttività.

Alcune metriche appartengono a più categorie. Ad esempio, le metriche di qualità in-process di un progetto sono sia metriche di processo che metriche di progetto.

Ambito delle metriche del software

Le metriche del software contengono molte attività che includono quanto segue:

• Stima dei costi e degli sforzi
• Misure e modello di produttività
• Raccolta dati
• Modelli e misure di quantità
• Modelli di affidabilità
• Modelli di performance e valutazione
• Metriche strutturali e di complessità
• Capacità - valutazione della maturità
• Gestione per metriche
• Valutazione di metodi e strumenti

La misurazione del software è una raccolta diversificata di queste attività che vanno dai modelli che prevedono i costi del progetto software in una fase specifica alle misurazioni della struttura del programma.

Stima dei costi e degli sforzi

Lo sforzo è espresso in funzione di una o più variabili come la dimensione del programma, la capacità degli sviluppatori e il livello di riutilizzo. Sono stati proposti modelli di stima dei costi e degli sforzi per prevedere il costo del progetto durante le prime fasi del ciclo di vita del software. I diversi modelli proposti sono:

• Il modello COCOMO di Boehm
• Il modello sottile di Putnam
• Modello di punti funzione di Albrecht

Modello e misure di produttività

La produttività può essere considerata in funzione del valore e del costo. Ciascuno può essere scomposto in diverse dimensioni misurabili, funzionalità, tempo, denaro, ecc. Diversi possibili componenti di un modello di produttività possono essere espressi nel diagramma seguente.

Raccolta dati

La qualità di qualsiasi programma di misurazione dipende chiaramente da un'attenta raccolta dei dati. I dati raccolti possono essere distillati in semplici tabelle e grafici in modo che i manager possano comprendere l'avanzamento e il problema dello sviluppo. La raccolta dei dati è essenziale anche per l'indagine scientifica su relazioni e tendenze.

Modelli e misure di qualità

Sono stati sviluppati modelli di qualità per la misurazione della qualità del prodotto senza i quali la produttività non ha senso. Questi modelli di qualità possono essere combinati con il modello di produttività per misurare la produttività corretta. Questi modelli sono solitamente costruiti in modo simile ad un albero. I rami superiori contengono importanti fattori di qualità di alto livello come l'affidabilità e l'usabilità.

La nozione di approccio divide et impera è stata implementata come approccio standard per misurare la qualità del software.

Modelli di affidabilità

La maggior parte dei modelli di qualità include l'affidabilità come fattore componente, tuttavia, la necessità di prevedere e misurare l'affidabilità ha portato a una specializzazione separata nella modellazione e previsione dell'affidabilità. Il problema di base nella teoria dell'affidabilità è prevedere quando un sistema alla fine fallirà.

Valutazione e modelli delle prestazioni

Comprende caratteristiche prestazionali del sistema osservabili esternamente come tempi di risposta e tassi di completamento e il funzionamento interno del sistema come l'efficienza degli algoritmi. È un altro aspetto della qualità.

Metriche strutturali e di complessità

Qui misuriamo gli attributi strutturali delle rappresentazioni del software, che sono disponibili prima dell'esecuzione. Quindi proviamo a stabilire teorie empiricamente predittive per supportare l'assicurazione della qualità, il controllo di qualità e la previsione della qualità.

Valutazione della maturità delle capacità

Questo modello può valutare molti diversi attributi di sviluppo, compreso l'uso di strumenti, pratiche standard e altro. Si basa sulle pratiche chiave che ogni buon appaltatore dovrebbe utilizzare.

Gestione per metriche

Per la gestione del progetto software, la misurazione ha un ruolo fondamentale. Per verificare se il progetto è in linea, utenti e sviluppatori possono fare affidamento sul grafico e sul grafico basati su misurazioni. Il set standard di misurazioni e metodi di reporting sono particolarmente importanti quando il software è incorporato in un prodotto in cui i clienti non sono generalmente esperti nella terminologia del software.

Valutazione di metodi e strumenti

Ciò dipende dal disegno sperimentale, dalla corretta identificazione dei fattori che possono influenzare il risultato e dalla misurazione appropriata degli attributi dei fattori.

La metrica del software è uno standard di misura che contiene molte attività, il che implica un certo grado di misurazione. Il successo nella misurazione del software risiede nella qualità dei dati raccolti e analizzati.

Cosa sono i dati validi?

I dati raccolti possono essere considerati un buon dato, se possono produrre le risposte alle seguenti domande:

• Are they correct? - Un dato può essere considerato corretto, se è stato raccolto secondo le regole esatte della definizione della metrica.

• Are they accurate? - La precisione si riferisce alla differenza tra i dati e il valore effettivo.

• Are they appropriately precise? - La precisione si occupa del numero di cifre decimali necessarie per esprimere i dati.

• Are they consistent? - I dati possono essere considerati coerenti, se non mostrano una grande differenza da un dispositivo di misurazione all'altro.

• Are they associated with a particular activity or time period? - Se i dati sono associati a una particolare attività o periodo di tempo, devono essere chiaramente specificati nei dati.

• Can they be replicated?- Normalmente, le indagini come i sondaggi, i casi di studio e gli esperimenti vengono spesso ripetuti in circostanze diverse. Quindi, i dati dovrebbero anche essere replicabili facilmente.

Come definire i dati?

I dati raccolti a scopo di misurazione sono di due tipi:

• Raw data- Risultati di dati grezzi dalla misurazione iniziale di processi, prodotti o risorse. Ad esempio: scheda attività settimanale dei dipendenti di un'organizzazione.

• Refined data - Risultati di dati raffinati dall'estrazione di elementi di dati essenziali dai dati grezzi per derivare valori per attributi.

I dati possono essere definiti in base ai seguenti punti:

• Location
• Timing
• Symptoms
• Risultato finale
• Mechanism
• Cause
• Severity
• Cost

Come raccogliere i dati?

La raccolta dei dati richiede l'osservazione e la comunicazione umana. I responsabili, gli analisti di sistema, i programmatori, i tester e gli utenti devono registrare i dati delle righe nei moduli. Per raccogliere dati accurati e completi, è importante:

• Mantieni le procedure semplici

• Evita registrazioni non necessarie

• Formare i dipendenti sulla necessità di registrare i dati e sulle procedure da utilizzare

• Fornire i risultati dell'acquisizione e dell'analisi dei dati ai fornitori originali prontamente e in una forma utile che li assisterà nel loro lavoro

• Convalida tutti i dati raccolti presso un punto di raccolta centrale

La pianificazione della raccolta dei dati prevede diversi passaggi:

• Decidi quali prodotti misurare in base all'analisi GQM

• Assicurati che il prodotto sia sotto il controllo della configurazione

• Decidere esattamente quali attributi misurare e come derivare le misure indirette

• Una volta che il set di metriche è chiaro e il set di componenti da misurare è stato identificato, elaborare uno schema per identificare ciascuna attività coinvolta nel processo di misurazione

• Stabilire una procedura per la gestione dei moduli, l'analisi dei dati e la comunicazione dei risultati

La pianificazione della raccolta dei dati deve iniziare quando inizia la pianificazione del progetto. L'effettiva raccolta dei dati avviene durante molte fasi di sviluppo.

For example - Alcuni dati relativi al personale del progetto possono essere raccolti all'inizio del progetto, mentre altri dati raccolti come lo sforzo inizia all'avvio del progetto e continua attraverso il funzionamento e la manutenzione.

Come archiviare ed estrarre dati

Nell'ingegneria del software, i dati devono essere archiviati in un database e impostati utilizzando un Database Management System (DBMS). Un esempio di struttura del database è mostrato nella figura seguente. Questo database memorizzerà i dettagli di diversi dipendenti che lavorano in diversi reparti di un'organizzazione.

Nel diagramma sopra, ogni casella è una tabella nel database e la freccia indica la mappatura molti-a-uno da una tabella all'altra. Le mappature definiscono i vincoli che preservano la coerenza logica dei dati.

Una volta che il database è stato progettato e popolato con i dati, possiamo fare uso dei linguaggi di manipolazione dei dati per estrarre i dati per l'analisi.

Dopo aver raccolto i dati rilevanti, dobbiamo analizzarli in modo appropriato. Ci sono tre elementi principali da considerare per la scelta della tecnica di analisi.

• La natura dei dati
• Lo scopo dell'esperimento
• Considerazioni sul design

La natura dei dati

Per analizzare i dati, dobbiamo anche guardare alla popolazione più ampia rappresentata dai dati e alla distribuzione di tali dati.

Campionamento, popolazione e distribuzione dei dati

Il campionamento è il processo di selezione di un set di dati da una vasta popolazione. Le statistiche campione descrivono e riassumono le misure ottenute da un gruppo di soggetti sperimentali.

I parametri della popolazione rappresentano i valori che si otterrebbero misurando tutti i soggetti possibili.

La popolazione o il campione possono essere descritti dalle misure della tendenza centrale come media, mediana e modalità e dalle misure di dispersione come la varianza e la deviazione standard. Molti set di dati sono distribuiti normalmente come mostrato nel grafico seguente.

Come mostrato sopra, i dati saranno distribuiti uniformemente sulla media. quali sono le caratteristiche significative di una distribuzione normale.

Esistono anche altre distribuzioni in cui i dati sono distorti in modo che ci siano più punti dati su un lato della media che sull'altro. Ad esempio: se la maggior parte dei dati è presente sul lato sinistro della media, allora possiamo dire che la distribuzione è inclinata a sinistra.

Lo scopo dell'esperimento

Normalmente, gli esperimenti vengono condotti -

• Per confermare una teoria
• Per esplorare una relazione

Per raggiungere ciascuno di questi, l'obiettivo dovrebbe essere espresso formalmente in termini di ipotesi e l'analisi deve affrontare direttamente l'ipotesi.

Per confermare una teoria

L'indagine deve essere progettata per esplorare la verità di una teoria. La teoria di solito afferma che l'uso di un determinato metodo, strumento o tecnica ha un effetto particolare sui soggetti, rendendolo migliore in un modo che in un altro.

Ci sono due casi di dati da considerare: normal data e non-normal data.

Se i dati provengono da una distribuzione normale e ci sono due gruppi da confrontare, il test t di Student può essere utilizzato per l'analisi. Se sono presenti più di due gruppi da confrontare, è possibile utilizzare un'analisi generale della varianza denominata F-statistica.

Se i dati non sono normali, è possibile analizzarli utilizzando il test di Kruskal-Wallis classificandoli.

Per esplorare una relazione

Le indagini sono progettate per determinare la relazione tra i punti dati che descrivono una o più variabili.

Esistono tre tecniche per rispondere alle domande su una relazione: box plot, grafici a dispersione e analisi di correlazione.

• UN box plot può rappresentare il riepilogo dell'intervallo di un insieme di dati.

• UN scatter plot rappresenta la relazione tra due variabili.

• Correlation analysis utilizza metodi statistici per confermare se esiste una vera relazione tra due attributi.

  • Per valori normalmente distribuiti, utilizzare Pearson Correlation Coefficient per verificare se le due variabili sono o meno fortemente correlate.

  • Per i dati non normali, classificare i dati e utilizzare il Spearman Rank Correlation Coefficientcome misura di associazione. Un'altra misura per i dati non normali è ilKendall robust correlation coefficient, che indaga la relazione tra coppie di punti dati e può identificare una correlazione parziale.

Se la classifica contiene un numero elevato di valori pari, a chi-squared testsu una tabella di contingenza può essere utilizzato per testare l'associazione tra le variabili. Allo stesso modo,linear regression può essere utilizzato per generare un'equazione per descrivere la relazione tra le variabili.

Per più di due variabili, multivariate regression può essere utilizzata.

considerazioni sul design

Il disegno dell'indagine deve essere considerato nella scelta delle tecniche di analisi. Allo stesso tempo, la complessità dell'analisi può influenzare il design scelto. Più gruppi utilizzano le statistiche F anziché il test T di Student con due gruppi.

Per progetti fattoriali complessi con più di due fattori, è necessario un test di associazione e significato più sofisticato.

Le tecniche statistiche possono essere utilizzate per tenere conto dell'effetto di un insieme di variabili su altri o per compensare i tempi o gli effetti di apprendimento.

Gli attributi interni del prodotto descrivono i prodotti software in un modo che dipende solo dal prodotto stesso. La ragione principale per misurare gli attributi interni del prodotto è che aiuterà a monitorare e controllare i prodotti durante lo sviluppo.

Misurazione degli attributi interni del prodotto

I principali attributi interni del prodotto includono size e structure. Le dimensioni possono essere misurate staticamente senza doverle eseguire. La dimensione del prodotto ci dice lo sforzo necessario per crearlo. Allo stesso modo, la struttura del prodotto gioca un ruolo importante nella progettazione della manutenzione del prodotto.

Misurare le dimensioni

La dimensione del software può essere descritta con tre attributi:

• Length - È la dimensione fisica del prodotto.

• Functionality - Descrive le funzioni fornite dal prodotto all'utente.

• Complexity - La complessità è di diversi tipi, come.

  • Problem complexity - Misura la complessità del problema sottostante.

  • Algorithmic complexity - Misura la complessità dell'algoritmo implementato per risolvere il problema

  • Structural complexity - Misura la struttura del software utilizzato per implementare l'algoritmo.

  • Cognitive complexity - Misura lo sforzo richiesto per comprendere il software.

La misurazione di questi tre attributi può essere descritta come segue:

Lunghezza

Esistono tre prodotti di sviluppo la cui misurazione delle dimensioni è utile per prevedere lo sforzo necessario per la previsione. Sono specifiche, design e codice.

Specifiche e design

Questi documenti di solito combinano testo, grafici e simboli e diagrammi matematici speciali. La misurazione delle specifiche può essere utilizzata per prevedere la lunghezza del progetto, che a sua volta è un indicatore della lunghezza del codice.

I diagrammi nei documenti hanno una sintassi uniforme come digrafi etichettati, diagrammi di flusso di dati o schemi Z. Poiché i documenti di specifica e progettazione sono costituiti da testi e diagrammi, la sua lunghezza può essere misurata in termini di una coppia di numeri che rappresentano la lunghezza del testo e la lunghezza del diagramma.

Per queste misurazioni, gli oggetti atomici devono essere definiti per diversi tipi di diagrammi e simboli.

Gli oggetti atomici per i diagrammi di flusso di dati sono processi, entità esterne, archivi di dati e flussi di dati. Le entità atomiche per le specifiche algebriche sono ordinamenti, funzioni, operazioni e assiomi. Le entità atomiche per gli schemi Z sono le varie linee che compaiono nella specifica.

Codice

Il codice può essere prodotto in diversi modi come il linguaggio procedurale, l'orientamento agli oggetti e la programmazione visiva. La misura tradizionale più comunemente usata della lunghezza del programma del codice sorgente è le linee di codice (LOC).

La lunghezza totale,

LOC = NCLOC + CLOC

cioè

LOC = Non-commented LOC + Commented LOC

Oltre alla riga di codice, per misurare la lunghezza possono essere utilizzate anche altre alternative come la dimensione e la complessità suggerite da Maurice Halsted.

La scienza del software di Halstead ha tentato di catturare diversi attributi di un programma. Ha proposto tre attributi interni del programma come lunghezza, vocabolario e volume che riflettono diversi punti di vista delle dimensioni.

Ha iniziato definendo un programma Pcome raccolta di token, classificati da operatori o operandi. Le metriche di base per questi token erano,

• μ₁ = Numero di operatori univoci

• μ₂ = Numero di operandi univoci

• N₁ = Occorrenze totali di operatori

• N₂ = Numero di operatori univoci

La lunghezza P può essere definito come

$$N = N_{1}+ N_{2}$$

Il vocabolario di P è

$$\mu =\mu _{1}+\mu _{2}$$

Il volume del programma = Numero di confronti mentali necessari per scrivere un programma di lunghezza N, è

$$V = N\times {log_{2}} \mu$$

Il livello di programma di un programma P di volume V è,

$$L = \frac{V^\ast}{V}$$

Dove, $V^\ast$ è il volume potenziale, ovvero il volume dell'implementazione di dimensioni minime di P

L'inverso del livello è la difficoltà -

$$D = 1\diagup L$$

Secondo la teoria di Halstead, possiamo calcolare una stima L come

$${L}' = 1\diagup D = \frac{2}{\mu_{1}} \times \frac{\mu_{2}}{N_{2}}$$

Allo stesso modo, la durata stimata del programma è, $\mu_{1}\times log_{2}\mu_{1}+\mu_{2}\times log_{2}\mu_{2}$

Lo sforzo richiesto per generare P è dato da,

$$E = V\diagup L = \frac{\mu_{1}N_{2}Nlog_{2}\mu}{2\mu_{2}}$$

Dove l'unità di misura E sono le discriminazioni mentali elementari necessarie per capire P

Le altre alternative per misurare la lunghezza sono:

• In termini di numero di byte di memoria del computer necessari per il testo del programma

• In termini di numero di caratteri nel testo del programma

Lo sviluppo orientato agli oggetti suggerisce nuovi modi per misurare la lunghezza. Pfleeger et al. ha scoperto che un conteggio di oggetti e metodi portava a stime di produttività più accurate rispetto a quelle che utilizzavano righe di codice.

Funzionalità

La quantità di funzionalità insita in un prodotto fornisce la misura della dimensione del prodotto. Esistono tanti metodi diversi per misurare la funzionalità dei prodotti software. Discuteremo uno di questi metodi, il metodo Function Point di Albrecht, nel prossimo capitolo.

Le metriche dei punti funzione forniscono un metodo standardizzato per misurare le varie funzioni di un'applicazione software. Misura la funzionalità dal punto di vista dell'utente, cioè sulla base di ciò che l'utente richiede e riceve in cambio. L'analisi dei punti funzionali è un metodo standard per misurare lo sviluppo del software dal punto di vista dell'utente.

La misura Function Point originariamente concepita da Albrecht ha ricevuto una maggiore popolarità con la creazione dell'International Function Point Users Group (IFPUG) nel 1986. Nel 2002, IFPUG Function Points è diventato uno standard ISO internazionale - ISO / IEC 20926.

Cos'è un Function Point?

FP (Function Point)è la metrica di tipo funzionale più diffusa adatta per quantificare un'applicazione software. Si basa su cinque "funzioni" logiche identificabili dagli utenti, suddivise in due tipi di funzioni dati e tre tipi di funzioni transazionali. Per una data applicazione software, ciascuno di questi elementi viene quantificato e ponderato, contando i suoi elementi caratteristici, come riferimenti a file o campi logici.

I numeri risultanti (FP non regolato) vengono raggruppati in set di funzioni aggiunte, modificate o eliminate e combinati con il fattore di regolazione del valore (VAF) per ottenere il numero finale di FP. Per ogni tipo di conteggio viene utilizzata una formula finale distinta: applicazione, progetto di sviluppo o progetto di miglioramento.

Applicazione del metodo del punto funzione di Albrecht

Vediamo ora come applicare il metodo Function Point di Albrecht. La sua procedura è la seguente:

Determina il numero di componenti (EI, EO, EQ, ILF ed ELF)

• EI- Il numero di ingressi esterni. Si tratta di processi elementari in cui i dati derivati ​​passano attraverso il confine dall'esterno all'interno. In un sistema di database bibliotecario di esempio, immettere il numero di tessera della biblioteca di un utente esistente.

• EO- Il numero di uscite esterne. Si tratta di processi elementari in cui i dati derivati ​​passano attraverso il confine dall'interno all'esterno. In un sistema di database di una biblioteca di esempio, visualizzare un elenco di libri ritirati a un utente.

• EQ- Il numero di query esterne. Si tratta di processi elementari con componenti sia di input che di output che risultano nel recupero dei dati da uno o più file logici interni e file di interfaccia esterna. In un sistema di database di biblioteche di esempio, determinare quali libri sono attualmente ritirati da un utente.

• ILF- Il numero di file di registro interni. Si tratta di gruppi identificabili dall'utente di dati correlati logicamente che risiedono interamente all'interno dei confini delle applicazioni che vengono mantenuti tramite input esterni. In un sistema di database di una biblioteca di esempio, il file dei libri nella biblioteca.

• ELF- Il numero di file di registro esterni. Si tratta di gruppi identificabili dall'utente di dati correlati logicamente che vengono utilizzati solo a scopo di riferimento e che risiedono interamente al di fuori del sistema. In un sistema di database della libreria di esempio, il file che contiene le transazioni nel sistema di fatturazione della libreria.

Calcola il conteggio dei punti funzione non regolato (UFC)

• Valuta ogni componente come low, average, o high.

• Per le transazioni (EI, EO, and EQ), la valutazione si basa su FTR e DET.

  • FTR - Il numero di file aggiornati o referenziati.

  • DET - Il numero di campi riconoscibili dall'utente.

  • Sulla base della seguente tabella, un file EI che fa riferimento a 2 file e 10 elementi di dati sarebbero classificati come average.

FTR	DET
	1-5	6-15	>15
0-1	Basso	Basso	Media
2-3	Basso	Media	Alto
>3	Media	Alto	Alto

• Per i file (ILF and ELF), la valutazione si basa su RET e DET.

  • RET - Il numero di elementi di dati riconoscibili dall'utente in un file ILF o ELF.

  • DET - Il numero di campi riconoscibili dall'utente.

  • Sulla base della seguente tabella, un file ILF che contiene 10 elementi di dati e 5 campi sarebbero classificati come high.

RET	DET
	1-5	6-15	>15
1	Basso	Basso	Media
2-5	Basso	Media	Alto
>5	Media	Alto	Alto

• Converti le valutazioni in UFCs.

Valutazione	Valori
	EO	EQ	EI	ILF	ELF
Low	4	3	3	7	5
Average	5	4	4	10	7
High	6	5	6	15	10

Calcola il conteggio dei punti funzione finale (FPC)

• Calcola il fattore di regolazione del valore (VAF) basato su 14 caratteristiche generali del sistema (GSC).

Caratteristica generale del sistema		Breve descrizione
GSC 1	Comunicazione dei dati	Quante strutture di comunicazione ci sono per facilitare il trasferimento o lo scambio di informazioni con l'applicazione o il sistema?
GSC 2	Elaborazione dati distribuita	Come vengono gestiti i dati distribuiti e le funzioni di elaborazione?
GSC 3	Prestazione	Il tempo di risposta o la velocità effettiva erano richiesti dall'utente?
GSC 4	Configurazione molto usata	Quanto è utilizzata l'attuale piattaforma hardware su cui verrà eseguita l'applicazione?
GSC 5	Tasso di transazione	Con quale frequenza vengono eseguite le transazioni giornaliere, settimanali, mensili, ecc.?
GSC 6	Inserimento dati in linea	Quale percentuale delle informazioni viene inserita online?
GSC 7	Efficienza dell'utente finale	L'applicazione è stata progettata per l'efficienza dell'utente finale?
GSC 8	Aggiornamento in linea	Quanti ILF vengono aggiornati tramite transazione online?
GSC 9	Elaborazione complessa	L'applicazione dispone di un'ampia elaborazione logica o matematica?
GSC 10	Riusabilità	L'applicazione è stata sviluppata per soddisfare le esigenze di uno o più utenti?
GSC 11	Facilità di installazione	Quanto sono difficili la conversione e l'installazione?
SGC 12	Facilità operativa	Quanto sono efficaci e / o automatizzate le procedure di avvio, backup e ripristino?
SGC 13	Più siti	L'applicazione è stata progettata, sviluppata e supportata specificamente per essere installata in più siti per più organizzazioni?
SGC 14	Facilitare il cambiamento	L'applicazione è stata progettata, sviluppata e supportata specificamente per facilitare il cambiamento?

• Pesa ciascuno GSC su una scala da 0 a 5 in base al fatto che non abbia influenza su un'influenza forte.

• Calcola il file FPC come segue -

  FPC = UFC * (0.65+ (somma (GSC) * .01))

Complessità

La complessità è una componente separata della dimensione. È di due tipi:

• Complexity of a problem - È la quantità di risorse necessarie per una soluzione ottimale al problema.

• Complexity of a solution- Sono le risorse necessarie per implementare una particolare soluzione. Ha due aspetti. Sono i seguenti:

  • Time complexity - La risorsa è l'ora del computer.

  • Space complexity - La risorsa è la memoria del computer.

Misurare la complessità

Un aspetto della complessità è l'efficienza. Misura qualsiasi prodotto software che può essere modellato come algoritmo.

Ad esempio: se un algoritmo per risolvere tutte le istanze di un particolare problema richiede f(n) calcoli, quindi f(n) è asintoticamente ottimale, se per ogni altro algoritmo di complessità g che risolve il problema f è O(g). Quindi, la complessità del problema dato è grande -O dell'algoritmo asintoticamente ottimale per la soluzione del problema.

La misurazione delle proprietà strutturali di un software è importante per stimare lo sforzo di sviluppo e per la manutenzione del prodotto. La struttura dei requisiti, della progettazione e del codice aiuta a comprendere la difficoltà che sorge nella conversione di un prodotto in un altro, nel test di un prodotto o nel prevedere gli attributi del software esterno dalle prime misure interne del prodotto.

Tipi di misure strutturali

La struttura del software ha tre parti. Sono -

• Control-flow structure - È la sequenza in cui le istruzioni vengono eseguite in un programma.

• Data-flow structure - È il comportamento dei dati mentre interagisce con il programma.

• Data structure - È l'organizzazione degli elementi di dati sotto forma di elenchi, code, stack o altre strutture ben definite insieme all'algoritmo per crearli, modificarli o eliminarli.

Misurazione della struttura del flusso di controllo

Le misure del flusso di controllo sono solitamente modellate con un grafo diretto, dove ogni nodo o punto corrisponde alle istruzioni del programma e ogni arco o bordo diretto indica il flusso di controllo da un'istruzione all'altra. Questi grafici sono chiamati grafico del flusso di controllo o grafico diretto.

Se ‘m’ è una misura strutturale definita in termini di modello del diagramma di flusso e se programma A è strutturalmente più complesso del programma B, quindi la misura m(A) dovrebbe essere maggiore di m(B).

Misurazione della struttura del flusso di dati

Il flusso di dati o il flusso di informazioni può essere inter-modulare (flusso di informazioni all'interno dei moduli) o intra-modulare (flusso di informazioni tra i singoli moduli e il resto del sistema).

A seconda del modo in cui i dati si muovono attraverso il sistema, possono essere classificati come segue:

• Local direct flow - Se un modulo richiama un secondo modulo e gli passa informazioni o il modulo invocato restituisce un risultato al chiamante.

• Local indirect flow - Se il modulo richiamato restituisce informazioni che vengono successivamente passate a un secondo modulo richiamato.

• Global flow - Se le informazioni fluiscono da un modulo all'altro attraverso una struttura dati globale.

La complessità del flusso di informazioni può essere espressa secondo Henry e Kafura come,

Information flow complexity (M) = length (M) × fan-in (M) × (fan-out (M))²

Dove,

• Fan-in (M) - Il numero di flussi locali che terminano in M ​​+ il numero di strutture dati da cui le informazioni vengono recuperate da M.

• Fan–out (M) - Il numero di flussi locali che provengono da M + il numero di strutture dati che vengono aggiornate da M.

Misurazione della struttura dei dati

La struttura dei dati può essere entrambe le cose local e global.

Locally, verrà misurata la quantità di struttura in ogni elemento di dati. Un approccio basato sulla teoria dei grafici può essere utilizzato per analizzare e misurare le proprietà delle singole strutture di dati. In questo modo semplici tipi di dati come numeri interi, caratteri e booleani sono visti come numeri primi e vengono prese in considerazione le varie operazioni che ci consentono di costruire strutture di dati più complesse. Le misure della struttura dati possono quindi essere definite gerarchicamente in termini di valori per i numeri primi e valori associati alle varie operazioni.

Globally, verrà misurato un conteggio del numero totale di variabili definite dall'utente.

Diversi istituti di standard nazionali e internazionali, organizzazioni professionali e orientate al settore sono stati coinvolti nello sviluppo degli standard SQA.

I seguenti istituti e organizzazioni sono i principali sviluppatori di standard SQA e di ingegneria del software:

• Computer Society IEEE (Institute of Electrical and Electronics Engineers)
• ISO (Organizzazione internazionale per la standardizzazione)
• DOD (Dipartimento della Difesa degli Stati Uniti)
• ANSI (American National Standards Institute)
• IEC (International Electro Technical Commission)
• EIA (Electronic Industries Association)

Queste organizzazioni forniscono standard internazionali aggiornati alla qualità delle attività professionali e gestionali svolte nelle organizzazioni di sviluppo e manutenzione del software.

Forniscono inoltre la certificazione SQA attraverso audit di qualità professionale indipendenti. Questi audit esterni valutano i risultati nello sviluppo dei sistemi SQA e la loro implementazione. La certificazione, che viene rilasciata dopo gli audit periodici, sarà valida solo fino all'audit successivo, e quindi dovrà essere rinnovata. Attualmente, il servizio di certificazione ISO 9000 è il più importante fornitore di certificazione SQA in Europa e in altri paesi.

Forniscono inoltre gli strumenti per l'autovalutazione del sistema SQA di un'organizzazione e del suo funzionamento. Il Capacity Maturity Model (CMM) sviluppato dal Software Engineering Institute (SEI), Carnegie Mellon University e ISO / IEC Std 15504 sono gli esempi di questo approccio.

Standard SQA

Gli standard di garanzia della qualità del software possono essere classificati in due classi principali:

• Standard di gestione della garanzia della qualità del software, comprese metodologie di certificazione e valutazione (standard di gestione della qualità)

• Standard del processo di sviluppo del progetto software (standard del processo del progetto)

Standard di gestione della qualità

Questi si concentrano sul sistema SQA dell'organizzazione, sull'infrastruttura e sui requisiti, lasciando all'organizzazione la scelta dei metodi e degli strumenti. Con gli standard di gestione della qualità, le organizzazioni possono garantire costantemente che i propri prodotti software raggiungano un livello di qualità accettabile.

Example - ISO 9000-3 e il Capability Maturity Model (CMM)

Standard di processo del progetto

Questi si concentrano sulle metodologie per l'implementazione dei progetti di sviluppo e manutenzione del software. Questi standard includono quanto segue:

• I passi da compiere
• Requisiti della documentazione di progettazione
• Contenuti dei documenti di progettazione
• Revisioni del progetto e problemi di revisione
• Test del software da eseguire
• Argomenti di prova

Naturalmente, a causa delle loro caratteristiche, molti standard SQA di questa classe possono fungere da standard di ingegneria del software e viceversa.

Le caratteristiche di queste due classi di standard sono riassunte nella tabella seguente.

Caratteristiche	Standard di gestione della qualità	Standard di processo del progetto
L'unità di destinazione	Gestione dello sviluppo del software, della manutenzione e delle unità SQA specifiche	Un team di progetto di sviluppo e manutenzione del software
L'obiettivo principale	Organizzazione di sistemi, infrastrutture e requisiti SQA	Metodologie per la realizzazione di progetti di sviluppo e manutenzione del software
L'obiettivo dello standard	"Cosa" da ottenere	"Come" eseguire
L'obiettivo dello standard	Garanzia della qualità del software del fornitore e valutazione della sua capacità di elaborazione del software	Garanzia della qualità del software del fornitore e valutazione della sua capacità di elaborazione del software Garanzia della qualità di un progetto software specifico.
Esempi	CMM ISO 9000-3 SEI	ISO / IEC 12207 IEEEStd 1012-1998

Certificazione ISO 9001

L'ISO (International Organization for Standardization) è una federazione mondiale di organismi nazionali di normalizzazione. I comitati tecnici ISO preparano gli standard internazionali. ISO collabora strettamente con la Commissione elettrotecnica internazionale (IEC) su tutte le questioni di standardizzazione elettrotecnica.

Gli Standard Internazionali sono redatti in conformità con le regole date nelle Direttive ISO / IEC, Parte 2. La bozza degli Standard Internazionali adottata dai comitati tecnici è distribuita agli organi membri per la votazione. La ISO 9001 è stata preparata dal Comitato tecnico ISO / TC 176, Gestione della qualità e garanzia della qualità, Sottocomitato SC 2, Sistemi di qualità.

Approccio al processo

La presente norma internazionale promuove l'adozione di un approccio per processi durante lo sviluppo, l'implementazione e il miglioramento dell'efficacia di un sistema di gestione della qualità, per aumentare la soddisfazione del cliente soddisfacendo i requisiti del cliente. Affinché un'organizzazione funzioni in modo efficace, deve determinare e gestire numerose attività collegate. Un'attività o un insieme di attività che utilizzano risorse e gestite in modo da consentire la trasformazione di input in output possono essere considerati come un processo.

Spesso l'output di un processo forma direttamente l'input del successivo. L'applicazione di un sistema di processi all'interno di un'organizzazione, insieme all'identificazione e alle interazioni di questi processi, e alla loro gestione per produrre il risultato desiderato, può essere definita come il“process approach”.

Un vantaggio dell'approccio per processi è il controllo continuo che fornisce sul collegamento tra i singoli processi all'interno del sistema di processi, nonché sulla loro combinazione e interazione. Quando viene utilizzato all'interno di un sistema di gestione della qualità, tale approccio sottolinea l'importanza di quanto segue:

• Comprensione e soddisfazione dei requisiti
• Necessità di considerare i processi in termini di valore aggiunto
• Ottenere i risultati delle prestazioni e dell'efficacia del processo
• Miglioramento continuo dei processi basato su misurazioni oggettive

ISO 9001 - Applicazione al software: l'iniziativa TickIT

TickIT è stato lanciato alla fine degli anni '80 dall'industria del software del Regno Unito in collaborazione con il Dipartimento del commercio e dell'industria del Regno Unito per promuovere lo sviluppo di una metodologia per adattare la ISO 9001 alle caratteristiche dell'industria del software nota come iniziativa TickIT.

TickIT è inoltre specializzato nella tecnologia dell'informazione (IT). Copre l'intera gamma di servizi di sviluppo e manutenzione di software commerciale. TickIT, ora gestito e mantenuto dal DISC Department di BSI (British Standards Institute), è accreditato per la certificazione delle organizzazioni IT nel Regno Unito e in Svezia.

Le sue attività includono:

• Pubblicazione della Guida TickIT, che supporta gli sforzi dell'industria del software per diffondere la certificazione ISO 9001. La guida corrente (edizione 5.0, TickIT, 2001), che include riferimenti a ISO / IEC 12207 e ISO / IEC 15504, è distribuita a tutti i clienti di TickIT.

• Esecuzione di valutazioni basate su audit dei sistemi di qualità del software e consulenza alle organizzazioni sul miglioramento dei processi di sviluppo e manutenzione del software oltre alla loro gestione.

• Condurre audit di certificazione ISO 9000.

Gli auditor di TickIT che conducono valutazioni basate su audit e audit di certificazione sono registrati presso l'International Register of Certificated Auditors (IRCA). Gli auditor IRCA registrati devono, tra le altre cose, avere esperienza nella gestione e nello sviluppo di software; devono anche completare con successo un corso per auditor.

I lead auditor registrati devono avere una comprovata esperienza nella conduzione e direzione degli audit TickIT.

Una valutazione del processo software è un esame disciplinato dei processi software utilizzati da un'organizzazione, sulla base di un modello di processo. La valutazione include l'identificazione e la caratterizzazione delle pratiche correnti, l'identificazione delle aree di punti di forza e di debolezza e la capacità delle pratiche correnti di controllare o evitare cause significative di scarsa qualità (software), costi e pianificazione.

Una valutazione (o audit) del software può essere di tre tipi.

• UN self-assessment (first-party assessment) viene eseguita internamente dal personale di un'organizzazione.

• UN second-party assessment viene eseguita da un team di valutazione esterno o l'organizzazione viene valutata da un cliente.

• UN third-party assessment viene eseguita da una parte esterna o (ad esempio, un fornitore valutato da una terza parte per verificare la sua capacità di stipulare contratti con un cliente).

Le valutazioni del processo software vengono eseguite in un ambiente aperto e collaborativo. Servono all'organizzazione per migliorare i propri processi software ei risultati sono riservati all'organizzazione. L'organizzazione da valutare deve avere membri nel team di valutazione.

Valutazione della maturità del processo software

L'ambito di una valutazione del processo software può coprire tutti i processi nell'organizzazione, un sottoinsieme selezionato dei processi software o un progetto specifico. La maggior parte degli approcci di valutazione del processo basati su standard sono invariabilmente basati sul concetto di maturità del processo.

Quando l'obiettivo della valutazione è l'organizzazione, i risultati di una valutazione del processo possono differire, anche su applicazioni successive dello stesso metodo. Ci sono due ragioni per i diversi risultati. Loro sono,

• L'organizzazione oggetto di indagine deve essere determinata. Per una grande azienda, sono possibili diverse definizioni di organizzazione e pertanto l'effettivo ambito di valutazione può differire nelle valutazioni successive.

• Anche in quella che sembra essere la stessa organizzazione, il campione di progetti selezionati per rappresentare l'organizzazione può influenzare la portata e il risultato.

Quando l'unità di valutazione target è a livello di progetto, la valutazione dovrebbe includere tutti i fattori significativi che contribuiscono al successo o al fallimento del progetto. Non dovrebbe essere limitato dalle dimensioni stabilite di un dato modello di maturità del processo. Qui vengono valutati il ​​grado di implementazione e la loro efficacia come comprovato dai dati del progetto.

La maturità del processo diventa rilevante quando un'organizzazione intende intraprendere una strategia di miglioramento globale a lungo termine. Le valutazioni del progetto software dovrebbero essere valutazioni indipendenti per essere oggettive.

Ciclo di valutazione del processo software

Secondo Paulk e colleghi (1995), l'approccio di valutazione basato su CMM utilizza un ciclo in sei fasi. Sono -

• Seleziona un team: i membri del team devono essere professionisti esperti in ingegneria e gestione del software.

• I rappresentanti del sito da valutare compilano il questionario standard di maturità del processo.

• Il team di valutazione esegue un'analisi delle risposte al questionario e identifica le aree che richiedono un'ulteriore esplorazione in base alle aree chiave del processo CMM.

• Il team di valutazione effettua una visita in loco per acquisire una comprensione del processo software seguito dal sito.

• Il team di valutazione produce un elenco di risultati che identifica i punti di forza e di debolezza del processo software dell'organizzazione.

• Il team di valutazione prepara un'analisi del profilo dell'Area di processo chiave (KPA) e presenta i risultati al pubblico appropriato.

Ad esempio, il team di valutazione deve essere guidato da un Lead Assessor SEI autorizzato. La squadra deve essere composta da quattro a dieci membri della squadra. Almeno un membro del team deve provenire dall'organizzazione da valutare e tutti i membri del team devono completare il corso SEI Introduzione al CMM (o il suo equivalente) e il corso di formazione del team CBA IPI della SEI. I membri del team devono anche soddisfare alcune linee guida per la selezione.

Per quanto riguarda la raccolta dei dati, l'IPI CBA si basa su quattro metodi:

• Il questionario standard sulla maturità
• Colloqui individuali e di gruppo
• Revisioni dei documenti
• Feedback dalla revisione della bozza dei risultati con i partecipanti alla valutazione

SCAMPI

Lo Standard CMMI Assessment Method for Process Improvement (SCAMPI) è stato sviluppato per soddisfare i requisiti del modello CMMI (Software Engineering Institute, 2000). Si basa anche sull'IPI CBA. Sia l'IPI CBA che lo SCAMPI consistono in tre fasi:

• Piano e preparazione
• Condurre la valutazione in loco
• Segnala i risultati

Le attività per la fase di pianificazione e preparazione includono:

• Identificare l'ambito della valutazione
• Sviluppa il piano di valutazione
• Preparare e formare il team di valutazione
• Fai una breve valutazione dei partecipanti
• Amministrare il questionario di valutazione CMMI
• Esamina le risposte al questionario
• Condurre una revisione iniziale del documento

Le attività per la fase di valutazione in loco includono:

• Conduci una riunione di apertura
• Conduci interviste
• Consolida le informazioni
• Preparare la presentazione della bozza dei risultati
• Presentare la bozza dei risultati
• Consolidare, valutare e preparare i risultati finali

Le attività della fase di rendicontazione dei risultati includono:

• Presentare i risultati finali
• Conduci una sessione esecutiva
• Concludi la valutazione

La definizione IEEE per la garanzia della qualità del software è la seguente:

"Un modello pianificato e sistematico di tutte le azioni necessarie per fornire un'adeguata sicurezza che un articolo o un prodotto sia conforme ai requisiti tecnici stabiliti. Un insieme di attività progettate per valutare il processo mediante il quale i prodotti vengono sviluppati o fabbricati."

Obiettivi delle attività SQA

Gli obiettivi delle attività SQA sono i seguenti:

Nello sviluppo software (orientato al processo)

• Assicurare un livello accettabile di fiducia che il software sarà conforme ai requisiti tecnici funzionali.

• Assicurare un livello accettabile di fiducia che il software sarà conforme alla pianificazione gestionale e ai requisiti di budget.

• Avvio e gestione di attività per il miglioramento e una maggiore efficienza dello sviluppo software e delle attività SQA.

In Manutenzione software (orientata al prodotto)

• Assicurando con un livello accettabile di fiducia che le attività di manutenzione del software saranno conformi ai requisiti tecnici funzionali.

• Assicurando con un livello accettabile di fiducia che le attività di manutenzione del software saranno conformi alla pianificazione manageriale e ai requisiti di budget.

• Avvio e gestione di attività per migliorare e aumentare l'efficienza della manutenzione del software e delle attività SQA. Ciò comporta il miglioramento delle prospettive di raggiungimento dei requisiti funzionali e gestionali riducendo i costi.

Organizzazione per la garanzia della qualità

Il quadro organizzativo di garanzia della qualità che opera all'interno della struttura organizzativa include i seguenti partecipanti:

Manager

• Dirigenti apicali, in particolare il dirigente direttamente responsabile della garanzia della qualità del software

• Responsabili reparto sviluppo software e manutenzione

• Responsabili del reparto di test del software

• Project manager e team leader di progetti di sviluppo e manutenzione

• Leader dei team di test del software

Tester

• Membri dei team di test del software

Professionisti SQA e professionisti interessati -

• Fiduciari SQA
• Membri del comitato SQA
• Membri del forum SQA
• Membri del team dell'unità SQA

Solo i manager e i dipendenti del reparto di test del software sono occupati a tempo pieno nello svolgimento delle attività SQA. Gli altri dedicano parte del loro tempo a questioni di qualità, sia durante l'adempimento delle loro funzioni manageriali o compiti professionali, sia come volontari in altri, il più delle volte un comitato SQA, un forum SQA o come amministratori SQA.

Fondamentalmente, esiste una struttura di gestione a tre livelli nelle organizzazioni di sviluppo software:

• Top management
• Direzione del reparto
• Gestione di progetto

Responsabilità del top management nella qualità del software

Di seguito sono riportate le responsabilità del top management nel garantire la qualità del software:

• Garantire la qualità dei prodotti software e dei servizi di manutenzione software dell'azienda

• Comunicare l'importanza della qualità del prodotto e del servizio oltre alla soddisfazione del cliente ai dipendenti a tutti i livelli

• Assicurare un funzionamento soddisfacente e la piena conformità ai requisiti del cliente

• Garantire che gli obiettivi di qualità siano stabiliti per il sistema SQA dell'organizzazione e che i suoi obiettivi siano raggiunti

• Avviare la pianificazione e supervisionare l'implementazione delle modifiche necessarie per adattare il sistema SQA ai principali cambiamenti interni ed esterni relativi alla clientela, alla concorrenza e alla tecnologia dell'organizzazione

• Intervenire direttamente per supportare la risoluzione delle situazioni di crisi e ridurre al minimo i danni

• Garantire la disponibilità delle risorse richieste dai sistemi SQA

I seguenti passaggi possono essere adottati dal top management per adempiere alle proprie responsabilità:

• Stabilire e aggiornare la politica di qualità del software dell'organizzazione.

• Assegnare uno dei dirigenti, come il Vicepresidente per SQA, a occuparsi delle questioni di qualità del software

• Conduzione di revisioni periodiche da parte della direzione delle prestazioni rispetto ai problemi di qualità del software

Politica sulla qualità del software

La politica di qualità del software dell'organizzazione dovrebbe comunicare i seguenti requisiti:

• Conformità allo scopo e agli obiettivi dell'organizzazione

• Impegno nei concetti generali di garanzia della qualità del software

• Impegno per gli standard di qualità adottati dall'organizzazione

• Impegno ad allocare risorse adeguate per la garanzia della qualità del software

• Impegno per il miglioramento continuo della qualità e della produttività dell'organizzazione

Il responsabile esecutivo della qualità del software

Le responsabilità del dirigente responsabile delle questioni relative alla qualità del software possono essere classificate come:

• Responsabilità per la preparazione di un programma e budget annuale delle attività SQA

• Responsabilità per la preparazione dei piani di sviluppo del sistema SQA

• Controllo generale dell'attuazione del programma annuale delle attività regolari SQA e dei progetti di sviluppo SQA pianificati

• Presentazione e difesa delle questioni SQA alla direzione esecutiva

Responsabilità per la preparazione del programma annuale delle attività SQA

Ciò richiede al dirigente di:

• Stabilire gli obiettivi SQA del sistema per il prossimo anno

• Rivedere le proposte preparate dall'unità SQA per il programma di attività annuale e verificare il potenziale della proposta per raggiungere gli obiettivi fissati per il sistema SQA

• Determinare se il programma delle attività è adeguato alle caratteristiche e alla portata dei servizi dei subappaltatori e degli acquisti di software pianificati per l'anno successivo

• Determinare l'adeguatezza della forza lavoro e delle altre risorse pianificate per l'attuazione del programma SQA

• Approvare la versione finale del programma e del budget annuale delle attività SQA

Responsabilità per la preparazione dei piani di sviluppo del sistema SQA

Questi piani devono essere adattabili ai cambiamenti tecnologici, alle richieste dei clienti e alla concorrenza. Le responsabilità includono:

• Revisione delle tendenze che si prevede influenzeranno la qualità del software dell'organizzazione nel prossimo futuro

• Rivedere le proposte per gli adattamenti SQA come la preparazione di nuove procedure appropriate ai nuovi strumenti e standard SQA

• Preparazione di programmi di formazione per team di sviluppo software veterani e membri del team appena reclutati

• Sviluppo di metriche sulla qualità del software appropriate per valutare i nuovi strumenti e standard, nonché il successo dei programmi di formazione

• Approvazione della versione finale dei progetti di sviluppo SQA pianificati, compresi i loro programmi e budget

Controllo generale dell'attuazione del programma SQA annuale

Il dirigente preposto è responsabile di:

• Supervisione generale del programma annuale delle attività

• Revisione dell'avanzamento dei progetti di adattamento SQA

• Supervisione generale delle azioni intraprese per realizzare i risultati di qualità dettati dagli obiettivi dei team (sulla base di report periodici)

• Revisione della conformità con le procedure e gli standard SQA sulla base di audit interni di qualità

• Follow-up generale della conformità ai programmi e ai budget dei progetti di sviluppo software

• Follow-up generale della fornitura di servizi di manutenzione della qualità ai clienti esterni e interni

Presentazione e difesa delle questioni SQA alla direzione esecutiva

Per promuovere la qualità e risolvere le difficoltà del sistema SQA richiede:

• Presentazione per l'approvazione finale della proposta di programma annuale di attività e budget

• Presentazione per l'approvazione finale dei progetti di adattamento SQA pianificati insieme ai budget corrispondenti

• Avvio e leadership di riunioni periodiche di riesame della direzione dedicate alla qualità del software dell'organizzazione

• Avvio di discussioni a livello di gestione dedicate a eventi speciali sulla qualità del software, come gravi errori di qualità, minacce al completamento con successo dei progetti a causa di gravi carenze di personale professionale, crisi manageriali nell'unità SQA e così via

Responsabilità della direzione del dipartimento per SQA

Le responsabilità di assicurazione della qualità del middle management includono:

• Gestione del sistema di gestione della qualità del software (attività relative al sistema di qualità)

• Gestione delle attività relative ai progetti e ai servizi svolti da unità o team sotto l'autorità del manager specifico (attività relative al progetto)

Responsabilità relative al sistema di qualità

Questi includono le attività SQA da svolgere a livello di dipartimento:

• Preparazione del programma e del budget annuale delle attività SQA del dipartimento, sulla base del programma consigliato preparato dall'unità SQA

• Preparazione dei piani di sviluppo dei sistemi SQA del dipartimento, sulla base del piano consigliato preparato dall'unità SQA

• Controllo delle prestazioni del programma annuale delle attività SQA del dipartimento e dei progetti di sviluppo

• Presentazione delle problematiche SQA del dipartimento al top management

Responsabilità relative al progetto

Questi variano a seconda delle procedure dell'organizzazione e della distribuzione dell'autorità; di solito coinvolgono -

• Controllo della conformità alle procedure di garanzia della qualità nelle unità del dipartimento, inclusi gli organismi CAB, SCM e SCCA

• Follow-up dettagliato dei risultati della revisione del contratto e delle approvazioni delle proposte

• Revisione delle prestazioni dell'unità delle attività di revisione pianificate; approvazione dei documenti di progetto e completamento della fase di progetto

• Follow-up dei test del software e dei risultati dei test; approvazione dei prodotti software del progetto

• Monitoraggio dell'avanzamento dei programmi di sviluppo del software e delle deviazioni di budget

• Consulenza e supporto ai project manager nella risoluzione delle difficoltà di pianificazione, budget e rapporti con i clienti

• Monitoraggio della qualità della fornitura di servizi di manutenzione

• Follow-up dettagliato dei rischi del progetto e delle loro soluzioni

• Follow-up della conformità del progetto ai requisiti del cliente e alla soddisfazione del cliente

• Approvazione di grandi ordini di modifica del software e deviazioni significative dalle specifiche di progetto

Responsabilità della gestione del progetto sulla qualità del software

La maggior parte delle responsabilità di gestione del progetto sono definite nelle procedure e nelle istruzioni di lavoro; il project manager è la persona incaricata di assicurarsi che tutti i membri del team rispettino le suddette procedure e istruzioni.

I suoi compiti includono compiti professionali pratici e manageriali, in particolare i seguenti:

• Professional hands-on tasks

  • Preparazione del progetto e piani di qualità e loro aggiornamenti

  • Partecipazione al comitato congiunto cliente-fornitore

  • Follow-up ravvicinato del personale del team di progetto, inclusa la partecipazione al reclutamento, alla formazione e all'istruzione

• Management tasks

  I project manager affrontano le questioni di follow-up come:

  • Svolgimento delle attività di revisione e conseguenti correzioni

  • Attività di sviluppo software e manutenzione dell'unità, integrazione e test di sistema, correzioni e test di regressione

  • Esecuzione di prove di accettazione

  • Installazione del software in siti remoti del cliente ed esecuzione del sistema software da parte del cliente

  • Formazione SQA e istruzione dei membri del team di progetto

  • Orari e risorse assegnate alle attività del progetto

  • Richieste e soddisfazione del cliente

  • Rischi di sviluppo del progetto in evoluzione, applicazione di soluzioni e controllo dei risultati

La struttura dell'unità SQA varia in base al tipo e alle dimensioni dell'organizzazione. La figura seguente mostra un esempio di una struttura standard e tutti i componenti sotto un'unità SQA. In questo capitolo, discuteremo i ruoli e le responsabilità di ciascuna sottounità.

Compiti svolti dal capo dell'unità SQA

Il capo dell'unità SQA è responsabile di tutte le attività di garanzia della qualità svolte dall'unità SQA e dalle sue sottounità. Queste attività possono essere classificate nelle seguenti categorie:

• Attività di pianificazione
• Gestione dell'unità
• Attività professionali SQA

Attività di pianificazione

• Preparazione del programma annuale di attività proposto e del budget per l'unità

• Pianificazione e aggiornamento del sistema di gestione della qualità del software dell'organizzazione

• Preparazione dei programmi di attività SQA annuali raccomandati e dei piani di sviluppo dei sistemi SQA per i reparti di sviluppo e manutenzione del software

Attività di gestione

• Gestione delle attività del team SQA

• Monitoraggio dell'attuazione del programma di attività SQA

• Nomina di membri del team, membri del comitato SQA e amministratori fiduciari SQA

• Preparazione di rapporti speciali e periodici, ad esempio, lo stato dei problemi di qualità del software all'interno dell'organizzazione e rapporti mensili sulle prestazioni

Attività professionali SQA

• Partecipazione a comitati congiunti di progetto
• Partecipazione a revisioni formali del design
• Revisione e approvazione delle deviazioni dalle specifiche
• Consultazione con project manager e team leader
• Partecipazione a comitati e forum SQA

SQA del ciclo di vita del progetto

Le attività SQA relative alla sottounità del ciclo di vita del progetto possono essere classificate in due gruppi:

• Attività di follow-up e approvazione gestionali "pure" (attività di controllo del ciclo di vita del progetto)

• Partecipazione "pratica" o attiva alle attività SQA del team di progetto, dove sono richiesti contributi professionali (attività di partecipazione)

Attività di controllo del ciclo di vita del progetto

• Follow-up della conformità del team di sviluppo e manutenzione alle procedure SQA e alle istruzioni di lavoro

• Approvazione o raccomandazione di prodotti software secondo le procedure pertinenti

• Monitoraggio dell'erogazione dei servizi di manutenzione del software ai clienti interni ed esterni

• Monitoraggio della soddisfazione del cliente e mantenimento dei contatti con i rappresentanti del controllo qualità del cliente

Attività di partecipazione

Questi compiti includono la partecipazione a:

• Revisioni del contratto
• Preparazione e aggiornamento dello sviluppo del progetto e dei piani di qualità
• Revisioni formali del design
• Revisioni formali della progettazione dei subappaltatori
• Test del software, inclusi i test di accettazione del cliente
• Test di accettazione del software dei prodotti software dei subappaltatori
• Installazione di nuovi prodotti software

SQA Infrastructure Operations Tasks

I sistemi SQA impiegano una varietà di componenti dell'infrastruttura per funzionare senza problemi, vale a dire:

• Procedure e istruzioni di lavoro
• Supporto di dispositivi di qualità (modelli, elenchi di controllo)
• Formazione, istruzione e certificazione del personale
• Azioni preventive e correttive
• Gestione della configurazione
• Controllo della documentazione

Più specificamente, i compiti della sottounità SQA riguardo a questi componenti includono:

• Pubblicazione di versioni aggiornate di procedure, istruzioni di lavoro, modelli, liste di controllo e così via, unitamente alla loro diffusione in formato cartaceo e / o elettronico

• Trasmissione di formazione e istruzione in merito all'adesione e all'applicazione delle procedure SQA, istruzioni di lavoro e articoli simili al personale nuovo e attuale

• Istruzione degli amministratori SQA in merito a procedure nuove e riviste, strumenti e metodi di sviluppo, tra le altre componenti

• Monitoraggio e supporto all'implementazione di procedure SQA nuove e riviste

• Follow-up delle attività di certificazione del personale

• Proposta di soggetti che necessitano di azioni preventive e correttive, inclusa la partecipazione a comitati CAB

• Follow-up delle attività di gestione della configurazione, inclusa la partecipazione ai comitati CCA

• Follow-up del rispetto delle procedure di documentazione e delle istruzioni di lavoro

Attività di audit interno e certificazione SQA

I tipi di audit SQA eseguiti all'interno o da organizzazioni di software possono essere classificati come segue:

• Audit interni

• Audit di subappaltatori e fornitori per valutare i loro sistemi SQA

• Audit esterni eseguiti da enti di certificazione

• Audit esterni eseguiti da clienti che desiderano valutare il sistema SQA prima di accettare l'organizzazione come fornitore

Le prime due classi di audit sono avviate ed eseguite dalla subunità SQA, le ultime due da enti esterni.

L'unità SQA svolge le seguenti attività per gli audit interni SQA

• Preparazione di programmi annuali per audit interni SQA

• Esecuzione di audit SQA interni

• Follow-up delle correzioni e dei miglioramenti che devono essere effettuati dai team controllati e da altre unità

• Preparazione di rapporti di sintesi periodici sullo stato dei risultati dell'audit, comprese le raccomandazioni per i miglioramenti

L'unità SQA svolge le seguenti attività per gli audit di subappaltatori e fornitori:

• Preparazione del programma annuale per gli audit SQA di subappaltatori e fornitori

• Esecuzione di audit SQA di subappaltatori e fornitori

• Follow-up di correzioni e miglioramenti che devono essere effettuati dai subappaltatori e fornitori controllati

• Raccolta di dati sulle prestazioni di subappaltatori e fornitori da fonti interne ed esterne

• Valutazione periodica dei sistemi SQA dei subappaltatori e dei fornitori certificati dell'organizzazione sulla base di rapporti di audit e informazioni raccolte da altre fonti interne ed esterne. Il rapporto di valutazione include:

  • Raccomandazioni riguardanti la certificazione di subappaltatori e fornitori

  • Gli audit esterni eseguiti dagli organismi di certificazione comportano i seguenti compiti:

    • Coordinamento dei contenuti e del programma dell'audit di certificazione

    • Predisposizione di documenti specificati dagli enti di certificazione

    • Istruzione dei team controllati ed esecuzione dei preparativi necessari per gli audit di certificazione

    • Partecipazione ad audit di certificazione

    • Assicurarsi che vengano eseguite le correzioni e i miglioramenti necessari

Gli audit SQA eseguiti dai clienti dell'organizzazione comportano queste attività:

• Coordinamento dei contenuti e della pianificazione dell'audit

• Preparazione dei documenti specificati dal revisore del cliente

• Istruzione dei team controllati ed esecuzione dei preparativi necessari per gli audit SQA da parte dei clienti dell'organizzazione

• Partecipazione agli audit

• Assicurarsi che vengano eseguite le correzioni e i miglioramenti richiesti

Attività di supporto SQA

La maggior parte dei consumatori dei servizi di supporto SQA si trova all'interno dell'organizzazione. Includono project manager, team leader e fiduciari SQA. I loro compiti includono:

• Preparazione di piani di progetto e piani di qualità del progetto

• Squadre di revisione del personale

• Scelta delle misure per risolvere i rischi di sviluppo del software identificati

• Scelta di misure per risolvere ritardi nella pianificazione e sforamenti del budget

• Scelta delle metriche SQA e dei componenti dei costi del software

• Utilizzo del sistema informativo SQA

• Scelta di metodologie e strumenti di sviluppo che riflettono i dati sull'esperienza di guasto accumulati dall'unità SQA

Standard e procedure SQA Compiti

La sottounità SQA è intimamente coinvolta nella decisione degli standard SQA da adottare, nonché nello sviluppo e nel mantenimento delle procedure dell'organizzazione. Per adempiere agli obblighi connessi, l'unità SQA è tenuta a:

• Preparare un programma annuale per lo sviluppo di nuove procedure e aggiornamenti delle procedure

• Essere responsabile dello sviluppo di nuove procedure e degli aggiornamenti delle procedure, con la partecipazione a comitati e forum appropriati

• Follow-up sugli sviluppi e cambiamenti negli standard SQA e di ingegneria del software; introduzione di procedure aggiuntive e modifiche rilevanti per l'organizzazione

• Avviare aggiornamenti e adattamenti delle procedure in risposta ai cambiamenti negli standard professionali, inclusa l'adozione o l'eliminazione degli standard applicati dall'organizzazione

Attività di ingegneria SQA

Il follow-up dei progressi professionali, la soluzione delle difficoltà operative e l'analisi esperta dei fallimenti sono gli obiettivi immediati di questa sottounità SQA.

Quindi, le principali attività di ingegneria coinvolgono quanto segue:

• Verifica degli aspetti di qualità e produttività rispetto a nuovi strumenti di sviluppo e nuove versioni degli strumenti di sviluppo attualmente utilizzati

• Valutazione della qualità e della produttività di nuovi metodi di sviluppo e manutenzione e miglioramenti dei metodi

• Sviluppo di soluzioni alle difficoltà incontrate nell'applicazione degli strumenti e dei metodi di sviluppo del software attualmente utilizzati

• Sviluppo di metodi per misurare la qualità del software e la produttività del team

• Fornitura di supporto tecnologico ai comitati CAB durante l'analisi dei fallimenti nello sviluppo del software e la formulazione delle soluzioni proposte

Attività dei sistemi informativi SQA

I sistemi di informazione SQA hanno lo scopo di facilitare e migliorare il funzionamento dei sistemi SQA. I compiti coinvolti includono:

• Sviluppo di sistemi informativi SQA per unità di sviluppo software e manutenzione per

  • raccolta di dati sulle attività

  • elaborazione, ad esempio, di report periodici, elenchi, report di eccezioni e query

  • elaborazione, ad esempio, di report periodici, elenchi, report di eccezioni e query

• Sviluppo di sistemi informativi SQA che facilitano l'elaborazione da parte dell'unità SQA delle informazioni fornite dalle unità di sviluppo e manutenzione del software, comprese le stime delle metriche di qualità del software e dei costi di qualità del software

• Aggiornamento dei sistemi informativi SQA

• Sviluppo e manutenzione del sito Internet / Intranet SQA dell'organizzazione

Trustee SQA e loro compiti

Gli amministratori SQA sono quei membri che sono principalmente coinvolti nella promozione della qualità del software. Questi membri forniscono il supporto interno necessario per implementare con successo i componenti SQA.

I loro compiti possono variare a seconda delle organizzazioni. Di conseguenza, potrebbero essere attività correlate all'unità e / o all'organizzazione.

Attività relative alle unità

• Supportare i colleghi per risolvere le difficoltà durante l'implementazione delle procedure di qualità del software e delle istruzioni di lavoro

• Assistere il responsabile dell'unità nello svolgimento dei relativi compiti SQA

• Promuovere la conformità e monitorare l'implementazione delle procedure SQA e delle istruzioni di lavoro da parte dei colleghi

• Segnalare eventi di non conformità sostanziali e sistematici all'unità SQA

• Segnalare gravi errori di qualità del software all'unità SQA

Attività relative all'organizzazione

• Attivare modifiche e aggiornamenti delle procedure SQA e delle istruzioni di lavoro a livello di organizzazione

• Attivare miglioramenti dei processi di sviluppo e manutenzione nell'organizzazione

• Avviare le richieste al CAB per quanto riguarda le soluzioni ai guasti ricorrenti osservati nelle rispettive unità

• Identificare le esigenze di formazione SQA in tutta l'organizzazione e proporre un programma di formazione o istruzione appropriato che deve essere condotto dall'unità SQA

Comitati SQA e loro compiti

I comitati SQA possono essere permanenti o ad hoc. Le attività possono variare notevolmente da organizzazione a organizzazione.

• Permanent committees si occupano comunemente di SCC (Software Change Control), CA (azioni correttive), procedure, strumenti di sviluppo di metodi e metriche di qualità.

• Ad hoc committees si occupano comunemente di casi specifici di interesse generale come l'aggiornamento di una procedura specifica, l'analisi e la soluzione di un guasto del software, l'elaborazione di metriche software per un processo o prodotto mirato, l'aggiornamento dei costi di qualità del software e dei metodi di raccolta dati per un problema specifico.

I comitati SQA permanenti sono parte integrante del quadro organizzativo SQA; i loro compiti e il funzionamento sono generalmente definiti nelle procedure SQA dell'organizzazione.

I comitati ad hoc sono istituiti a breve termine per problema, con membri nominati dal dirigente responsabile per le questioni di qualità del software, il capo dell'Unità SQA, le sottounità SQA, comitati SQA permanenti o qualsiasi altro ente che ha avviato la sua formazione e ha un interesse per il lavoro. Questo organo definisce anche i compiti del comitato ad hoc.