|
Categorie
Winzipedia Uso dell'wiki |
ControlloDellaQualitaIngegneriaDelSoftware.ControlloDellaQualita VersioniNascondi le modifiche minori - Mostra le modifiche Modificata la linea 19: da:
Se un processo a:
Se un processo male organizzato e tecnicamente carente difficilmente prodotti di . Un processo male organizzato se si verificano uno Modificate le linee 36-38: da:
* Malfunzionamento, * Difetto, anomalia, bug, fault, il difetto * Errore, riguarda una fase del processo utilizzato e non del prodotto. Un errore a:
* Malfunzionamento, funzionamento non corretto, non corrispondente alle specifiche, di un programma. legato al comportamento di un programma, non alla sua struttura statica. Il malfunzionamento dato da un difetto. * Difetto, anomalia, bug, fault, il difetto la causa di un malfunzionamento e si realizza in un componente non corretto. Riguarda la struttura statica. Se percorso durante di un programma genera un malfunzionamento. Questo implica che un difetto, se non percorso, rimane nascosto nel programma che, apparentemente, corretto e funziona. Un malfunzionamento essere generato da difetti e difetti possono avere un effetto complessivo nullo sul sistema. * Errore, riguarda una fase del processo utilizzato e non del prodotto. Un errore la causa della generazione di un difetto. dato da un errore , delle specifiche, di progettazione, di programmazione, di battitura, ecc. Riassumendo, si ha un errore che genera un difetto. Alla sua attivazione si ottiene un malfunzionamento. (Vedere anche la pagina Testing nella sezione Informatica 3.) Modificata la linea 40: da:
* Validazione, si deve controllare che si sta realizzando il prodotto corretto, quello a:
* Validazione, si deve controllare che si sta realizzando il prodotto corretto, quello che si aspetta il cliente. Modificata la linea 43: da:
un prodotto. La normativa di riferimento a:
un prodotto. La normativa di riferimento la ISO9126 (Software Product Modificata la linea 83: da:
* , di adattarsi ad ambienti diversi rispetto a quelli in cui a:
* , di adattarsi ad ambienti diversi rispetto a quelli in cui stato concepito Modificate le linee 94-95: da:
La valutazione della di un prodotto ha un suo peso determinato. Il processo di valutazione a:
La valutazione della di un prodotto basata sulla dei documenti (specifica, progetto, codice). di valutazione avviene lungo tutto il processo di sviluppo. di un prodotto ogni caratteristica ha un suo peso determinato. Il processo di valutazione composto da 4 passi fondamentali: Modificata la linea 101: da:
Ad ogni caratteristica di a:
Ad ogni caratteristica di assegnato un valore (importanza, , Modificata la linea 107: da:
Per ogni caratteristica di a:
Per ogni caratteristica di definito un modulo di di controllo Modificata la linea 120: da:
non passa, insufficiente, sufficiente, buono, ottimo. In questo modo a:
non passa, insufficiente, sufficiente, buono, ottimo. In questo modo Modificata la linea 124: da:
La valutazione ha delle complicazioni. Un prodotto software a:
La valutazione ha delle complicazioni. Un prodotto software costituito Modificata la linea 129: da:
globale di controllo a:
globale di controllo limitato conviene concentrarsi nei componenti Modificata la linea 134: da:
valore globale di una caratteristica di a:
valore globale di una caratteristica di spiegato in termini di valori Modificata la linea 138: da:
Il test del software a:
Il test del software la verifica dinamica del comportamento di un programma. Modificata la linea 143: da:
punti dati di D e controllare la coerenza dei risultati R. Un test ideale a:
punti dati di D e controllare la coerenza dei risultati R. Un test ideale un Modificata la linea 145: da:
nella pratica a:
nella pratica impossibile da realizzare, per ragioni pratiche, di costo e di Modificata la linea 148: da:
Il testing quindi a:
Il testing quindi uno strumento per accrescere la fiducia nei confronti Modificate le linee 155-156: da:
Il costo tipico del testing se nella questa percentuale a:
Il costo tipico del testing circa il 30% del costo totale di progetto, anche se nella questa percentuale estremamente variabile. I soldi disponibili Modificata la linea 158: da:
fornitore. Il test a:
fornitore. Il test una fase critica non solo per i costi ma collocato Modificata la linea 164: da:
non pagare. Per evitare questi problemi a:
non pagare. Per evitare questi problemi necessario definire una strategia Modificate le linee 177-178: da:
* Qual * Qual a:
* Qual la soluzione migliore dati i costi e i tempi * Qual la tecnica migliore in uno specifico caso Modificate le linee 185-186: da:
* Test funzionale (Black Box), vengono provate le funzioni del programma, indipendentemente da come il programma * Test strutturale (White Box), vengono provate le strutture interne del programma, considerando come a:
* Test funzionale (Black Box), vengono provate le funzioni del programma, indipendentemente da come il programma costruito. Si considera il programma come una scatola nera e si valutano solo gli ingressi e le uscite. * Test strutturale (White Box), vengono provate le strutture interne del programma, considerando come costruito il programma. Si utilizza la conoscenza della struttura interna del programma e si provano dei percorsi interni. Modificata la linea 189: da:
# Copertura funzionale, misura della di (definite nella specifica) coperte dal testing. La copertura funzionale esaustiva a:
# Copertura funzionale, misura della di (definite nella specifica) coperte dal testing. La copertura funzionale esaustiva data dal rapporto tra n. di funzioni esercitate almeno una volta nel test e il n. totale di funzioni. Una funzione non implementata per un errore a monte (come nello studio delle specifiche) non viene rilevata per quanto il test funzionale sia accurato. Modificata la linea 192: da:
Un caso di test a:
Un caso di test formato da quattro fasi: Modificata la linea 204: da:
* Definire un oracolo, a:
* Definire un oracolo, un criterio di verifica del successo Modificata la linea 217: da:
Un test funzionale a:
Un test funzionale formato da diversi casi, a seconda delle esigenze. Quelli Modificata la linea 225: da:
La specifica a:
La specifica un modello formale o semi-formale da cui possibile estrarre Modificata la linea 248: da:
* La specifica a:
* La specifica tradotta in una rete combinatoria che tratta cause ed Modificata la linea 263: da:
ogni scenario a:
ogni scenario definito un caso di test. Gli scenari definiti verranno poi Modificate le linee 275-276: da:
# Copertura dei cammini, ogni cammino deve essere percorso almeno una volta. Il numero massimo di percorrenze di un ciclo # Copertura del grafo di chiamata dei moduli, a:
# Copertura dei cammini, ogni cammino deve essere percorso almeno una volta. Il numero massimo di percorrenze di un ciclo la N copertura dei cicli. Cn=n. cammini percorsi / n. tot percorsi percorribili # Copertura del grafo di chiamata dei moduli, un criterio di copertura a grana grossa. Ogni arco che connette due moduli (chiamata di modulo) deve essere percorso almeno una volta. Modificata la linea 286: da:
* Test gerarchico, si parte dallo strato interno (per software con architettura a strati). Ogni strato deve essere testato dal punto di vista delle attese dal suo utente, a:
* Test gerarchico, si parte dallo strato interno (per software con architettura a strati). Ogni strato deve essere testato dal punto di vista delle attese dal suo utente, lo strato superiore. Modificata la linea 289: da:
Nei sistemi ad oggetti non si testano procedure ma classi e oggetti che incorporano procedure e dati (ogni oggetto ha una relazione di ingresso, di uscita e i suoi dati). Nel testing a:
Nei sistemi ad oggetti non si testano procedure ma classi e oggetti che incorporano procedure e dati (ogni oggetto ha una relazione di ingresso, di uscita e i suoi dati). Nel testing necessario tenere conto e del polimorfismo. Testare una classe vuol dire: Modificata la linea 293: da:
Nel testare e polimorfismo si deve considerare che non a:
Nel testare e polimorfismo si deve considerare che non localizzata. Inoltre, quando si ereditano delle funzioni, bene testare solo le differenze. Bisogna testare le diverse implementazioni per quegli oggetti che si riferiscono ad un certo codice solo a livello runtime. Modificata la linea 341: da:
Un processo di test a:
Un processo di test definito dalle seguenti fasi, che si intrecciano con quelle Modificata la linea 353: da:
Per facilitare e, in generale, velocizzare un processo di test a:
Per facilitare e, in generale, velocizzare un processo di test possibile realizzare Modificata la linea 363: da:
di test a:
di test una specifica competenza. utile che venga eseguita da Modificata la linea 365: da:
* Indipendenza di giudizio, dato che non a:
* Indipendenza di giudizio, dato che non legata ad aspetti particolari del prodotto Modificata la linea 375: da:
Il debugging a:
Il debugging avviato dal manifestarsi di un malfunzionamento causato da Modificata la linea 390: da:
Quando si ha una serie di dati che descrivono alcuni difetti a:
Quando si ha una serie di dati che descrivono alcuni difetti possibile Modificata la linea 401: da:
permettono di capire a che punto del lavoro si a:
permettono di capire a che punto del lavoro si arrivati, quanto si ha speso e Modificata la linea 403: da:
di ispezione a:
di ispezione composta da quattro fas. Nella prima il gruppo di progetto Modificate le linee 414-415: da:
* Il management non deve utilizzare i risultati per valutare il personale, lo scopo a:
* Il management non deve utilizzare i risultati per valutare il personale, lo scopo migliorare il prodotto. Valutare il personale , anche se indirettamente, peggiorare la del prodotto. una tecnica semplice ed utile che permette di: Modificata la linea 419: da:
La verifica a:
La verifica eseguita in modo strutturato attraverso un processo definito. Modificata la linea 425: da:
a:
percorsa e sono documentati difetti scoperti, valutazioni ed azioni Modificata la linea 435: da:
Il gruppo di ispezione a:
Il gruppo di ispezione formato da: Modificata la linea 450: da:
queste tecniche a:
queste tecniche del codice: Modificata la linea 461: da:
di codice, dalla dei commenti, a:
di codice, dalla dei commenti, possibile stimare la . Modificate le linee 467-469: da:
di (es. per , La metrica a:
di (es. per , utile la copertura del test, il n_di difetti trovati / linee di codice nella fase di test, il n_ di difetti trovati / linee di codice in esercizio). La misura il risultato della misurazione diuno specifico attributo. La metrica un insieme di regole per definire: Modificate le linee 482-483: da:
* La relazione a:
* La relazione stata formalizzata e validata e la stima ottenuta dal valore della caratteristica di ha una predittiva. Modificate le linee 485-486: da:
predittiva a:
difficile e controverso. utile in contesti definiti anche se la predittiva difficile da ottenere. Modificate le linee 489-491: da:
* Misura della ai fine , lo scopo * Monitoraggio della di prodotto durante il processo produttivo, lo scopo * Valutazione della per diagnosi e reingegnerizzazione, lo scopo a:
* Misura della ai fine , lo scopo valutare le caratteristiche di del prodotto (Esempio: , i cui valori sono definiti nei requisiti non funzionali). * Monitoraggio della di prodotto durante il processo produttivo, lo scopo di tenere sotto controllo il livello di del prodotto durante lo sviluppo, al fine di identificare i problemi in anticipo ed intervenire. Le misure possono essere svolte dal produttore o, in casi di rilasci intermedi ufficiali, dal committente del prodotto o da terza parte. * Valutazione della per diagnosi e reingegnerizzazione, lo scopo valutare la di un prodotto esistente la cui deve essere migliorata. Bisogna individuare la convenienza ed i costi della reingegnerizzazione e le modifiche da apportare. Al termine della valutazione fornita la diagnosi dello stato del prodotto e la terapia indicante le modifiche da intraprendere per della richiesta. Modificate le linee 497-499: da:
dove e * Fan In, Fan Out, * di , a:
dove e il numero di archi (flusso di controllo) e n il numero di nodi (comandi). Un valore elevato di V(G) per un modulo indica una struttura complessa di controllo che (assieme ad altri fattori) la del modulo stesso. Si dimostra che V(G)=d+1 (con d numero di decisioni binarie) misura un attributo della struttura di controllo di un programma. Non una misura di . * Fan In, Fan Out, applicato ad un modulo. Il fan in il numero di moduli che chiamano il modulo misurato, il fan out il numero di moduli che il modulo misurato chiama. Un fan in elevato suggerisce un alto grado di accoppiamento con il resto dei moduli , un fan out elevato suggerisce una interna elevata del modulo. * di , il numero di livelli nel grafo di specializzazione delle classi. il valore di elevato, il progetto complesso e difficile da capire. Modificata la linea 502: da:
Per ottenere stime di caratteristiche di a:
Per ottenere stime di caratteristiche di necessario: Modificata la linea 528: da:
* Numero di difetti sui prodotti rilasciati in esercizio / a:
* Numero di difetti sui prodotti rilasciati in esercizio / LoC Modificate le linee 2-3: da:
'''Autori:''' [[Profiles.Alberto|Alberto Taiocchi]] a:
'''Autori:''' [[Profiles.Alberto|Alberto Taiocchi]] Aggiunte le linee 1-528:
'''Autori:''' [[Profiles.Alberto|Alberto Taiocchi]]\\ ->'''Sommario''' !! Aspetti generali * Specifiche funzionali * Essere estendibile * Essere facile da usare * Fare un uso efficiente delle risorse hardware * Esigenze del cliente complementari: * Specifiche non scritte * Progettazione inesistente * Pianificazione carente * Configurazioni e versioni non gestite seguenti motivi: * Verifica, si deve controllare che si stia costruendo il prodotto nel modo giusto. * Adeguatezza, presenza e appropriatezza di un set di funzioni: * Accuratezza, fornire risultati (o effetti) giusti o accettabili; certo livello di prestazioni in determinate condizioni e per un certo periodo di tempo. Questi attributi sono: !!!! Efficienza Insieme di attributi correlati allo sforzo per effettuare certe modifiche. Gli attributi sono: # Esecuzione del piano di durante il processo # Raccolta risultati e applicazione di regole di interpretazione al fine di esprimere un giudizio finale. con utenti e il cliente. verifiche su documenti diversi utilizzando tecniche diverse. Si ispeziona il documento di specifica per verificare la ricchezza delle funzioni messe a disposizione se i risultati forniscono sufficiente garanzia di precisione). !!!! Esecuzione del piano di durante il processo Il piano viene eseguito dopo una delle fasi di studio del prodotto, come la progettazione architetturale o al termine della codifica. !!!! Raccolta risultati e applicazione di regole di interpretazione al fine di esprimere un giudizio finale Si effettua la raccolta dei risultati, si applicano delle regole di interpretazione e si valutano i risultati ottenuti. Criteri di valutazione possono essere: passa, possibile fornire delle spiegazioni al cliente sulle valutazioni, tali da poter essere utilizzate per migliorare il prodotto. critici, introducendo dei livelli nei moduli di controllo. !!!! Spiegazioni Questa fase ha il compito di fornire delle spiegazioni delle ragioni della valutazione tali da poter essere utilizzate per poter migliorare il prodotto. Il delle sottocaratteristiche e delle misure raccolte. !! Testing !!! Alcune note teoriche Tale verifica viene fatta con un numero finito di casi di test selezionati da un dominio di ingresso, rispetto ad un comportamento atteso specificato. Supponiamo di avere un programma P, funzione da dominio D (input) a un codominio R (output). Eseguire un test di P significa eseguire P per tutti i test esaustivo di D i cui risultati soddisfano le specifiche. Il caso esaustivo tempo. Allora bisogna selezionarne un sottoinsieme mirato che permetta di ottenere risultati utili al fine di accrescere la fiducia nel prodotto sofware. del prodotto. Si deve evitare di pensare al testing come strumento per creare un programma corretto, ma per realizzarne uno affidabile. Effettuando un rappresenta i comportamenti indesiderati del sistema. !!! Costi per effettuare il testing (budget del testing) sono pochi e a carico del nella fase finale del progetto, poco prima della data di consegna. Rischia di essere fatto di fretta, sotto pressione del cliente, per poter essere consegnato potrebbe non soddisfare il cliente. Il fornitore dovrebbe rimediare ai difetti allungando il periodo di lavoro e il cliente, insoddisfatto, continuerebbe a di test che definisca le risorse disponibili e le utilizzi in modo appropriato rispetto a: * Costi * Soddisfazione del cliente (diversa da quella del fornitore) * Tipologia di prodotto * Tipologia del cliente Il test deve essere pianificato ed eseguito attraverso un processo di testing. Le tecniche di testing servono per offrire delle possibili soluzioni (anche se non esistono delle soluzioni giuste o sbagliate) a tipici problemi che si devono affrontare, come: * Piano di test, elenco strutturato dei casi di test da eseguire in accordo con una strategia di test. (lista creata pensando ai casi di test delle parti principali del prodotto. Si compoone di nome del componente, codice che identifica la funzione - vedi specifiche - che deve realizzare, codice che identifica il caso di test, esito, descrizione del test). * Specifica del test, definizione delle caratteristiche di ogni caso di test !!! Tipologie di test e copertura Esistono tipologie di test: Esistono tre tipologie di copertura: !!! Struttura di un caso di test # Applicare i dati in ingresso # Effettuare azioni sul programma # Raccogliere i dati di uscita # Applicare un criterio per verificare che i dati di uscita corrispondono alla specifica (Criterio di successo o Oracolo). prodotti custom. Bisogna: * Predisporre il sistema nello stato iniziale prima di effettuare il test * Predisporre i dati di prova * Definire la procedura da seguire in modo corretto o sbagliato ed analizzarne i risultati. Sono entrambi test per verificare la robustezza del sistema. Si ottengono due tipi di test: * Test positivo, controlla il corretto funzionamento del programma a fronte di un uso corretto del sistema. Si inseriscono due numeri interi e il programma calcola la somma. * Caricamento di un dato * Verifica di corretto caricamento * Stampa * Verifica di corretta stampa * Cancellazione * Verifica di corretta cancellazione !!! Test funzionale (black box) possibili sono i seguenti: !!!!! Casi di test da specifiche testuali Si deve suddividere la specifica in aree funzionali omogenee. Per ogni area sono estratte le funzioni elementari semplicemente sottolineando le parole una lista delle funzioni organizzata in sezioni. !!!!! Casi di test da modelli casi di test applicando un criterio definito. Esempio: un automa a stati finiti con tabella descrittiva. !!!!! Classi di equivalenza del dominio di ingresso Si suppone che il programma si comporti allo stesso modo per ogni elemento della stessa classe. Si sceglie un caso di test per ogni classe.Ci sono delle di numeri interi, le classi possono essere: numeri minori di 0, maggiori di 0 e lo 0. !!!!! Valori limite I valori limite sono gli estremi delle classi di equivalenza. Sono le possibili normali, quelli limite possono essere dimenticati oppure gestiti con codice specifico. !!!!! Test negativi Per effettuare i casi di test si individuano classi di equivalenza di questi dati di input (classi non valide) !!!!! Grafi causa effetto Sono utilizzati per i casi di combinazioni complicate degli ingressi. Si selezionano casi di test significativi per verificare combinazioni di dati in ingresso che causano definite uscite. Si procede nel modo seguente: * Si identificano i fatti di ingresso e uscita (cause ed effetti); effetti. La rete aiuta a validare la specifica; * Seleziono un effetto; * Si riesegue il grafo effettuando tutte le combinazioni che generano * Per ogni combinazione si crea una colonna in una tavola di decisione; !!!!! Stima dei punti critici e scrivere specifici casi di test !!!!! Casi di test da scenari Si definisce un insieme di scenari di utilizzo. Per ogni scenario sono identificate riutilizzati nel test di collaudo finale. !!! Test strutturale (white box) Vengono definiti i casi di test sufficienti per rispettare un criterio di copertura di elementi definiti del programma. Il programma viene tradotto nel grafo di controllo, costituito da cerchi rapresentanti comandi, gruppi di comandi o condizioni e frecce rappresentanti i flussi di controllo. Il test strutturale viene eseguito basandosi su cinque criteri: # Copertura delle istruzioni, ogni istruzione (cerchio) deve essere percorsa almeno una volta. C0 = n istr.eseguite / n istruzioni # Copertura delle decisioni, ogni decisione (arco) del grafo di controllo deve essere percorsa almeno una volta. C1=n archi percorsi / n archi percorribili # Copertura delle condizioni, ogni singola decisione che compare nel grafo deve essere percorsa sia per lo stato di vero che per lo stato di falso !!! Test di modulo, integrazione di sistema il funzionamento collettivo. Si utilizzano metodi diversi: * Big Bang Test, il sistema viene integrato e poi verificato globalmente. * Drivers e Stub, sono componenti software sviluppati ad hoc per permettere il test di integrazione senza effettuare una implementazione !!! Test di sistemi ad oggetti * Test delle operazioni associate ad un oggetto * Definizione e interrogazione degli attributi I sistemi ad oggetti non sono una struttura gerarchica ma una rete. meno distinti e quindi bisogna studiare dei test che tengono conto di queste differenze. I livelli di test sono: * Test delle classi * Test di gruppi di oggetti che collaborano * Test del sistema completo !!! Test di accettazione / collaudo Il test di accettazione/collaudo utilizza la tecnica degli scenari. Si identificano un insieme di scenari di utilizzo, concordati con il cliente, i quali esercitano in casi considerati critici. Gli scenari di test includono anche caratteristiche non funzionali. !!! Test di non regressione Supponiamo di avere un insieme di casi di test T, eseguiti senza manifestare malfunzionamenti. Ad un certo punto si trova un difetto che viene corretto. T viene rifatta, per accertarsi che la modifica non abbia introdotto difetti procedura automatica di test. !!! Test di caratteristiche non funzionali Si possono costruire test relativi non solo a specifiche funzionali, ma anche a quelle non funzionali. Ad esempio: * Efficienza, misurare le prestazioni in condizioni definite !!! Strategia di test La teoria del testing e le relative tecniche convergono nella strategia di test. Gli ingredienti per costruire una strategia di test sono: * Costi e tempi, che sono sempre limitati * Caratteristiche ed esigenze del cliente * Cosa verificare * Come verificare * Quanto verificare Le risorse e i tempi disponibili vanno negoziati con il cliente. Si devono critici. Di conseguenza bisogna scegliere le tecniche di testing e i criteri di Infine si deve creare il documento della strategia di test che definisca le !!! Processo di test della progettazione del prodotto: # Definizione della strategia, che impatta significativamente sui costi # Specificazione # Preparazione del test black box # Progettazione architetturale # Inizio preparazione del test white box # Progettazione di dettaglio # Fine preparazione del test white box # Codifica # Esecuzione del test un programma che automatizza alcune fasi, noiose e lunghe da preparare, come: * Raggiungimento dello stato iniziale del sistema * Predisposizione dei dati di prova * Lancio del programma sotto test * Verifica del successo (oracolo) * Dello specifico progetto persone diverse dagli sviluppatori, per i seguenti motivi: * Esercizio di specifiche competenze dei tester * Utilizzo efficiente delle risorse umane, disponibili per altri lavori !!! Documenti Il processo di test rilascia dei documenti: * Piano di test * Specifiche dei casi di test * Rapporti di esecuzione dei piani di test !!! Debugging un difetto di programma. Permette di identificare e correggere il difetto che di generare effetti laterali non desiderati). !!! Analisi dei malfunzionamenti e dei difetti Quando si rilevano degli errori devono essere registrati al fine di essere utilizzati: * Per diagnosticare le cause e migliorare il prodotto I dati raccolti devono essere catalogati con processi ordinati: * Allocando i difetti al componente software, alle fasi, ai gruppi di lavoro I dati raccolti possono essere analizzati con diverse tecniche, tra cui: * Analisi e spiegazione causale dei difetti * Risorse non adeguate * Tempo ridotto * Progettazione carente !! Ispezioni !!! Concetto e tipi di ispezione Sono verifiche statiche di prodotto applicate alla documentazione (specifiche, architettura, ecc) e al codice sorgente. Hanno lo scopo di valutare aspetti quanto rimane, sia in termini di denaro sia in termini di tempo. La procedura ispezione esamina criticamente i documenti. I risultati vengono documentati e verranno intraprese azioni di sistemazione. Ci sono due tipi di ispezioni: Per applicare queste due ispezioni con successo ci sono delle condizioni da rispettare: * I documenti devono essere disponibili * Revisionare il progetto nei punti critici * Scoprire errori difficili da trovare con il testing del codice (dipendenti dal tempo) !!! Processo di ispezione Si utilizzano due tecniche: !!!! Walkthrought * Preparazione: si definisce un gruppo di revisione che riceve la documentazione da revisionare e la legge separatamente * Analisi di gruppo: sotto la guida di un coordinatore la documentazione richieste !!!! Inspection * Preparazione: i revisori esaminano i documenti guidati da una checklist * Esecuzione delle modifiche: gli autori eseguono le modifiche richieste * Follow Up: il responsabile dei visori controlla la corretta esecuzione delle modifiche ed eventualmente indice una nuova sessione di revisione. !!! Gruppo di ispezione * Gli estensori dei documenti da ispezionare * Almeno un revisore che non ha partecipato alla stesura dei documenti. Deve essere definito un responsabile del processo che lo pianifica e lo gestisce. Inoltre uno dei partecipanti si incarica di annotare i risultati e le decisioni !!! Checklist predefinita di aspetti da esaminare. Nella checklist abbiamo: * Aspetti da esaminare. * Difetti tipici. * Suggerimenti su come eseguire le verifiche. !!! Strumenti automatici di analisi Si utilizzano strumenti automatici di analisi statica. Si applicano a documenti scritti con linguaggi formali (tipicamente codice sorgente). Una di * Analisi del flusso di controllo (codice non raggiungibile). * Analisi di uso dei dati (come la dichiarazione di variabili mai utilizzate). * Analisi delle interfacce (consistenza tra la loro dichiarazione ed utilizzo). !! Misure !!! Misure di prodotto, concetti generali valutata non solo attraverso il testing o le ispezioni, ma anche raccogliendo misure relative a specifici aspetti del prodotto, al fine di stimare accoppiamento dei moduli, dalle dimensioni medie dei componenti in linee possono misurare indicatori utili per predire o tenere sotto controllo caratteristiche * Una procedura per assegnare numeri e simboli Le misure interne misurano: * La coesione ed accoppiamento dei moduli software * Le dimensioni medie del componente in linee di codice * Sono valutate sui documenti sono una serie di assunzioni che si devono considerare: Definire e validare una relazione tra gli indicatori e le caratteristiche di !!! Utilizzo Ecco come utilizzare le misure: !!! Esempi di misure di applicazione da realizzare. * Numero Ciclomatico (McCabe), dato il grafo di controllo di un programma, misura il numero di cammini linearmente indipendenti che, a partire dal nodo iniziale, raggiungono il nodo terminale: ->V(G)=e-n+2 Es. confronto penna USB - smart card. !!! Raccolta, interpretazione e integrazione * Raccogliere un insieme di misure diverse * Interpretare i singoli risultati Raccogliere un insieme di misure diverse vuol dire ottenere: * La dimensione media dei moduli in LOC * Numero ciclomatico medio dei moduli * Coesione ed accoppiamento Successivamente bisogna definire dei criteri per poter interpretare le misure !!! Misure di processo Le misure relative ai prodotti possono essere utilizzate anche per valutare, controllare e gestire i processi. Possiamo individuare: misure: * Numero di progetti fuori costo previsti a budget / numero totale di progetti * Numero di progetti fuori tempo previsto di consegna / numero totale di progetti * Numero di lamentele gravi di clienti * Numero di difetti sui prodotti rilasciati in esercizio / LOC |