NDP metriche progettazione e codifica

ricollocamento

LaTex/documenti/NormeDiProgetto/capitolo-processiprimari.tex

@@ -123,6 +123,23 @@ \subsubsection{Progettazione}
 I test di integrazione devono essere eseguiti tramite strumenti automatici quando possibile. \`{E} compito dei \Verificatori{} verificarne l'integrità.\\
 Devono essere eseguiti inoltre test di regressione in caso di modifiche, per accertare che queste non causino errori nelle parti già sottoposte a verifica con esito positivo. In questo modo viene garantito che le modifiche effettuate non pregiudichino le funzionalità esistenti e già testate.
 
+\paragraph{Metriche per la progettazione}\mbox{}\\
+Si concentrano sulle caratteristiche dell'architettura ad alto livello. Si basano sull'analisi di modelli di progetto nei quali sono evidenziati i moduli di sistema e i dati scambiati.
+
+\subparagraph{Accoppiamento}\mbox{}\\
+L'accoppiamento determina il numero di collaborazioni tra classi, ovvero il numero di altre classi cui una classe è accoppiata.\\
+L'accoppiamento può avvenire a seguito di lettura o modifica di attributi, chiamata di metodi o istanziazione di oggetti. Un uso eccessivo è negativo per la modularità ed il riuso: più una classe è indipendente più è riutilizzabile. L'accoppiamento influisce anche sull'impatto delle modifiche in altri moduli: valori elevati di accoppiamento complicano le attività di testing e le modifiche.
+\[ U = M \cdot N \]
+$M$ componenti in accoppiamento con $N$ altri componenti producono un grado di interdipendenza $U$.
+\textit{Fan-In} denomina quante classi utilizzano la classe presa in esame durante la loro esecuzione, Fan-In determina la dipendenza dal resto del codice prodotto. 
+\textit{Fan-Out} denomina quante classi vengono utilizzate dalla classe presa in esame durante la sua esecuzione, alti livelli di Fan-Out determinano alti livelli di accoppiamento rendendo il codice complesso da testare, livelli bassi di Fan-Out corrispondono a codice più facilmente riusabile per altri scopi dato che è indipendente totalmente o quasi dal resto del progetto.
+
+\subparagraph{Complessità ciclomatica}\mbox{}\\
+Questa tecnica utilizza elementi della teoria dei grafi per schematizzare il flusso di controllo del programma. Rappresenta gruppi di istruzioni in nodi e le interazioni fra loro in archi: i nodi corrispondono ai gruppi di istruzioni, mentre gli archi connettono gruppi di istruzioni che possono essere eseguite sequenzialmente.\\
+Dato un grafo $G$ di $n$ nodi ed $e$ archi, la complessità ciclomatica è data da:
+\[ V\left(G\right) = e - n + 2 \]
+Valori alti di complessità indicano poca manutenibilità del codice e maggiore quantità di test per la verifica, ma valori bassi possono indicare poca efficienza.
+
 \subsubsection{Codifica}
 Tutti i file contenenti codice o documentazione dovranno essere conformi alla codifica \glossario{UTF-8}.
 
@@ -138,6 +155,145 @@ \subsubsection{Codifica}
 \paragraph{Ricorsione}\mbox{}\\
 La ricorsione deve essere evitata quando possibile, onde evitare un elevato consumo di memoria a discapito delle performance del prodotto finale.
 
+\paragraph{Metriche per la codifica}\mbox{}
+\subparagraph{Numero di parametri per funzione}\mbox{}\\
+Indica il numero di parametri passati ad un metodo; un valore molto alto potrebbe indicare eccessiva complessità e una suddivisione non efficace in sotto-metodi.
+
+\subparagraph{Metriche di Halstead}\mbox{}\\
+Misurano l'implementazione del programma in base al codice sorgente considerato come un algoritmo, quindi come un insieme di operatori e operandi.\\
+Vengono così contrassegnati i componenti del codice:
+\begin{itemize}
+	\item $\eta_{1}$ = numero di operatori distinti;
+	\item $\eta_{2}$ = numero di operandi distinti;
+	\item $N1$ = numero totale di occorrenze degli operatori; 
+	\item $N2$ = numero totale di occorrenze degli operandi;
+\end{itemize}
+Secondo questa marcatura possiamo calcolare:
+\begin{itemize}
+	\item il vocabolario del programma:
+	\[ \eta = \eta_{1} + \eta_{2} \]
+	\item la lunghezza del programma:
+	\[ N = N1 + N2 \]
+	\item la lunghezza calcolata del programma: 
+	\[ {\hat {N}}=\eta_{1} \cdot \log_{2}\eta_{1}+\eta_{2} \cdot \log_{2}\eta_{2} \]
+	\item il volume del programma:
+	\[ V = N \cdot \log_{2}\eta \] 
+	dove
+	\begin{itemize}
+		\item $ \log_{2}\eta $ è il numero di bit necessari per rappresentare il vocabolario;
+		\item $ V $ è il numero di bit necessari per rappresentare il programma nella sua forma minima.\footnote{Il concetto di volume è legato quindi al contenuto di informazione del programma e dovrebbe dipendere unicamente dall'algoritmo scelto, non dall'espressività del linguaggio di programmazione.}
+	\end{itemize}
+	\item la difficoltà di scrittura e comprensione del programma:
+	\[ D = \frac{\eta_{1}}{2} \cdot \frac{N_{2}}{\eta_{2}} \]
+	\item lo sforzo complessivo sostenuto nella scrittura del programma:
+	\[ E = D \cdot V \]
+	\item il tempo di scrittura del programma:
+	\[ T=\frac{E}{18}\ secondi\]
+	\item il numero di bug in proporzione allo sforzo richiesto:
+	\[ B = \frac{E^{\frac{2}{3}}}{3000} \]	
+\end{itemize}
+
+\subparagraph{Core size}\mbox{}\\
+I core file sono file altamente interconnessi da una catena di dipendenze cicliche, i quali sono maggiormente propensi ad avere difetti. Core size è la percentuale di file con una o più dipendenze che hanno un alto fan-in ed un alto fan-out. Il calcolo di questa metrica viene effettuato attraverso strumenti automatici.
+
+\subparagraph{Indice di manutenibilità}\mbox{}\\
+Misura l’attitudine di una entità in assegnate condizioni di utilizzazione a essere mantenuta o riportata in uno stato nel quale può svolgere la funzione richiesta, quando la manutenzione è eseguita nelle condizioni date, con procedure e mezzi prescritti. Viene calcolato attraverso strumenti automatici.
+
+\paragraph{Metriche per la verifica}\mbox{}
+\subparagraph{Code coverage}\mbox{}\\
+Misura la capacità di coprire, mediante esecuzione di test, tutte le linee di codice di un modulo. Una copertura topologica del test del 100\% di tipo code coverage garantisce di aver eseguito almeno una volta tutte le istruzioni, ma non tutti i rami.
+
+\subparagraph{Modified condition/decision coverage (MC/DC)}\mbox{}\\
+\`{E} una combinazione delle metriche di \textit{function coverage} (copertura delle funzioni chiamate) e \textit{branch coverage} (copertura dei branch delle strutture di controllo). Questa metrica richiede che ogni punto di entrata o uscita in un programma sia invocato almeno una volta e che per ogni decisione condizionale vengano considerati tutti i possibili esiti. La versione \textit{modified} richiede inoltre che entrambe le coperture siano soddisfatte, ed in particolare che ogni condizione influenzi gli esiti condizionali indipendentemente.\footnote{Si rimanda al seguente link \url{https://en.wikipedia.org/wiki/Code_coverage} per esempi esplicativi.}
+
+\subparagraph{Test eseguiti}\mbox{}
+Rappresenta la percentuale di test eseguiti rispetto a quelli pianificati. Viene calcolata come
+\[\frac{N_{TE}}{N_{TT}} \cdot 100 \]
+dove
+\begin{itemize}
+	\item $N_{TE}$: numero di test eseguiti;
+	\item $N_{TT}$: numero di test totali pianificati.
+\end{itemize}
+
+\subparagraph{Test superati}\mbox{}\\
+Indica la percentuale di test superati rispetto a quelli eseguiti. Viene calcolata come
+\[ \frac{N_{TS}}{N_{TE}} \cdot 100 \]
+dove
+\begin{itemize}
+	\item $N_{TS}$: numero di test superati;
+	\item $N_{TE}$: numero di test eseguiti.
+\end{itemize}
+
+\subparagraph{Metriche di gestione degli errori}\mbox{}\\
+I parametri utilizzati:
+\begin{itemize}
+	\item \textbf{Criticità}: indica la gravità dell'errore rispetto all'avanzamento del progetto. Può assumere i seguenti valori:
+	\begin{itemize}
+		\item \textbf{bassa}: l'errore non compromette il corretto avanzamento del progetto;
+		\item \textbf{media}: l'errore non è bloccante, ma può compromettere il corretto avanzamento del progetto;
+		\item \textbf{alta}: l'errore è bloccante e compromette l'avanzamento del progetto.	
+	\end{itemize}
+	\item \textbf{Priorità}: indica la priorità di risoluzione dell'errore. Può assumere i seguenti valori:
+	\begin{itemize}
+		\item \textbf{bassa}: l'errore deve essere risolto entro la milestone successiva;
+		\item \textbf{media}: l'errore deve essere risolto entro una settimana dalla segnalazione;
+		\item \textbf{alta}: l'errore deve essere risolto nel più breve tempo possibile.
+	\end{itemize}
+	\item \textbf{Modalità}: indica la modalità di gestione dell'errore. Può assumere i seguenti valori:
+	\begin{itemize}
+		\item \textbf{correzione immediata}: il \Verificatore{} può correggere immediatamente l'errore se ne è in grado;
+		\item \textbf{segnalazione}: il \Verificatore{} deve effettuare una segnalazione, secondo le procedure indicate nelle \NormeDiProgetto{}.
+	\end{itemize}
+\end{itemize}
+
+\subsubsection{Metriche di prodotto}
+Hanno l'obiettivo di misurare la qualità del prodotto software nelle sue caratteristiche fisiche quali dimensioni, funzionabilità, manutenibilità e usabilità.
+
+\paragraph{Functional Size Measurement}\mbox{}\\
+Functional Size Measurement (FSM) è una tecnica per misurare il software in termini di funzionalità che esso offre. Lo standard \glossario{ISO}/\glossario{IEC} 14143 definisce FSM come una quantificazione dei Functional User Requirements (FUR), ovvero i requisiti che descrivono ciò che il software dovrebbe fare in termini di compiti e servizi, escludendo quindi le costrizioni in termini di qualità, organizzazione, ambiente e implementazione.\\
+Vantaggi di FSM:
+\begin{itemize}
+	\item è indipendente dalla tecnologia usata per implementare e sviluppare il software;
+	\item è idealmente la componente misurativa delle prestazioni del progetto, poiché queste possono essere comparate come le varie tecnologie, piattaforme, e altro ancora;
+	\item può essere stimata dallo stato dei requisiti a priori.
+\end{itemize}
+\`{E} pertanto utilizzabile per una valutazione preventiva dei costi del progetto.\\
+Il calcolo della copertura offerta è effettuato mediante la formula
+\[ \left(1 - \frac{N_{FM}}{N_{FI}} \right) \cdot 100 \]
+dove
+\begin{itemize}
+	\item $N_{FM}$: numero di funzionalità mancanti;
+	\item $N_{FI}$: numero di funzionalità individuate. 
+\end{itemize}
+
+\paragraph{Accuratezza rispetto alle attese}\mbox{}\\
+Rappresenta la percentuale di risultati dei test che rispettano quanto previsto. Viene calcolata come
+\[ \left(1 - \frac{N_{RD}}{N_{TE}} \right) \cdot 100 \]
+dove
+\begin{itemize}
+	\item $N_{RD}$: numero di test che producono risultati discordanti;
+	\item $N_{TE}$: numero di test eseguiti.
+\end{itemize}
+
+\paragraph{Fallimento dei test}\mbox{}\\
+Rappresenta la percentuale di operazioni di test che si sono concluse con fallimento. Viene calcolato come
+\[ \frac{N_{FR}}{N_{TE}} \cdot 100\]
+dove
+\begin{itemize}
+	\item $N_{FR}$: numero di fallimenti ricevuti;
+	\item $N_{TE}$: numero di test eseguiti.
+\end{itemize}
+
+\paragraph{Gestione delle operazioni non permesse}\mbox{}\\
+Rappresenta la percentuale di funzionalità che gestiscono correttamente errori che potrebbero verificarsi. Viene calcolato come
+\[ \frac{N_{EE}}{N_{TE}} \cdot 100\]
+dove
+\begin{itemize}
+	\item $N_{EE}$: numero di errori evitati durante i test;
+	\item $N_{TE}$: numero di test eseguiti che prevedono l'esecuzione di operazioni non corrette.
+\end{itemize} 
+
+
 \subsection{Verifica}
 L’attività di verifica deve essere svolta in modo continuativo durante l'avanzamento del progetto. Sono quindi definite modalità operative per agevolare il lavoro dei \Verificatori.