<commit_before>\section{La strategia di gestione della qualità nel dettaglio}

\subsection{Risorse}
Le risorse umane vengono descritte nelle \NormeDiProgetto{}. I ruoli con maggiori responsabilità sono il \Responsabile{} e il \Verificatore{}, soprattutto per l'attività di \VV{}.
Le risorse tecnologiche corrispondono a tutti gli strumenti software e hardware utilizzati per la verifica sui processi e prodotti.

\subsection{Obiettivi per le metriche}\label{sec:metriche}
Per poter descrivere il processo di verifica è necessario che esso sia quantificabile. Questo avviene tramite misure basate su metriche prestabilite consultabili nelle \NormeDiProgetto{}.

\subsubsection{Metriche per la documentazione}\label{sec:metriche_documentazione}
\paragraph{Indice Gulpease}\mbox{}\\
Per garantire la leggibilità della documentazione in lingua italiana si fa riferimento a i seguenti punteggi minimi selezionati per raggiungere un grado di comprensibilità adeguato. Per rendere di facile comprensione i documenti è individuato come minimo di accettazione 40 punti corrispondente ad un livello di comprensibilità adeguato per lettori in possesso di diploma di scuola superiore e come range di ottimalità da 50 a 100 punti adatto a lettori in possesso di licenza di scuola media.

\begin{longtable}{|c|c|c|}
	\hline \multicolumn{1}{|c|}{\textbf{Documento}} & \multicolumn{1}{c|}{\textbf{Accettazione}} & \multicolumn{1}{c|}{\textbf{Ottimalità}} \\
	\hline 
	\endfirsthead
	
	\hline \multicolumn{1}{|c|}{\textbf{Documento}} & \multicolumn{1}{c|}{\textbf{Accettazione}} & \multicolumn{1}{c|}{\textbf{Ottimalità}} \\
	\hline 
	\endhead
	
	\hline \multicolumn{3}{|r|}{{Continua nella prossima pagina}} \\ 
	\hline
	\endfoot
	
	\hline
	\endlastfoot
	
	\hline \NormeDiProgetto{}  & 40-100 & 50-100 \\
	\hline \StudioDiFattibilita{}  & 40-100 & 50-100  \\
	\hline \PianoDiProgetto{}  & 40-100 & 50-100  \\
	\hline \PianoDiQualifica{}  & 40-100 & 50-100  \\
	\hline \AnalisiDeiRequisiti{}  & 40-100 & 50-100  \\
	\hline \Glossario{}  & 40-100 & 50-100  \\
	\hline VerbaleEsterno23\_12\_2016 & 40-100 & 50-100 \\
	\hline
	\caption{Valori indice di Gulpease - Fase A}
\end{longtable}

\paragraph{Indice Gunning Fog}\mbox{}\\
Per garantire la leggibilità della documentazione in lingua inglese il punteggio calcolato non deve superare 12, livello datto per un High School Senior Student, si individua l'ottimalità nel limite di 14 punti, corrispondente ad un livello adatto ad un College Sophomore.

\subsubsection{Metriche di processo}\label{sec:metriche_processo}
\paragraph{Schedule Variance}\mbox{}\\
Lo Schedule Variance Management permette di valutare lo stato dei progressi nella pianificazione. 
\[ SV=EV-PV \]
dove
\begin{itemize}
	\item $SV$ = Schedule Variance;
	\item $EV$ = Earned Value;
	\item $PV$ = Planned Value.
\end{itemize}
La formula calcola l'anticipo o il ritardo sulla pianificazione tramite la differenza fra il valore prodotto dal progetto nel momento della misurazione e il costo pianificato nel momento della misurazione.\\
Quando la Schedule Variance è di valore positivo si è in anticipo rispetto alla pianificazione. Se il valore è negativo si è in ritardo rispetto alla pianificazione. Quando il valore è zero si sta procedendo come pianificato.

\paragraph{Cost Variance}\mbox{}\\
Permette di calcolare le stime sull'utilizzo del budget. 
\[ CV=EV-AC \]
dove
\begin{itemize}
	\item $CV$ = Cost Variance;
	\item $EV$ = Earned Value;
	\item $AC$ = Actual Cost.
\end{itemize}
La formula calcola la differenza del costo maturato fra costo stimato e costo effettivamente sostenuto.

\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{Metriche per l'analisi}\mbox{}\\
Consentono di monitorare e controllare costi, scheduling e qualità. Consentono di prevedere quale sarà la misura del processo software all'inizio del suo ciclo di vita, per poterne rapportare le risorse.

\subparagraph{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.

\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$.

\subparagraph{Complessità ciclomatica}\mbox{}\\

Per mantenere sotto controlla la complessità del software prodotto è calcolata la complessità ciclomatica del codice. 
Sono dichiarati come accettabili range di complessità per i risultati ottenuti dal calcolo: range 1-10 riguardano programmi semplici con poco rishio d'errore e range 11-20 adatti a programmi complessi ma a rischio moderato in modo da massimizzarne la manutenibilità e semplicità di testing.

\paragraph{Metriche per la codifica}\mbox{}
\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}

\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)}
\`{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{Metriche di gestione degli errori}\mbox{}\\
\begin{longtable}{|P{6cm}|c|c|P{4cm}|}<commit_msg>Metriche Halstead PDQ<commit_after>\section{La strategia di gestione della qualità nel dettaglio}

\subsection{Risorse}
Le risorse umane vengono descritte nelle \NormeDiProgetto{}. I ruoli con maggiori responsabilità sono il \Responsabile{} e il \Verificatore{}, soprattutto per l'attività di \VV{}.
Le risorse tecnologiche corrispondono a tutti gli strumenti software e hardware utilizzati per la verifica sui processi e prodotti.

\subsection{Obiettivi per le metriche}\label{sec:metriche}
Per poter descrivere il processo di verifica è necessario che esso sia quantificabile. Questo avviene tramite misure basate su metriche prestabilite consultabili nelle \NormeDiProgetto{}.

\subsubsection{Metriche per la documentazione}\label{sec:metriche_documentazione}
\paragraph{Indice Gulpease}\mbox{}\\
Per garantire la leggibilità della documentazione in lingua italiana si fa riferimento a i seguenti punteggi minimi selezionati per raggiungere un grado di comprensibilità adeguato. Per rendere di facile comprensione i documenti è individuato come minimo di accettazione 40 punti corrispondente ad un livello di comprensibilità adeguato per lettori in possesso di diploma di scuola superiore e come range di ottimalità da 50 a 100 punti adatto a lettori in possesso di licenza di scuola media.

\begin{longtable}{|c|c|c|}
	\hline \multicolumn{1}{|c|}{\textbf{Documento}} & \multicolumn{1}{c|}{\textbf{Accettazione}} & \multicolumn{1}{c|}{\textbf{Ottimalità}} \\
	\hline 
	\endfirsthead
	
	\hline \multicolumn{1}{|c|}{\textbf{Documento}} & \multicolumn{1}{c|}{\textbf{Accettazione}} & \multicolumn{1}{c|}{\textbf{Ottimalità}} \\
	\hline 
	\endhead
	
	\hline \multicolumn{3}{|r|}{{Continua nella prossima pagina}} \\ 
	\hline
	\endfoot
	
	\hline
	\endlastfoot
	
	\hline \NormeDiProgetto{}  & 40-100 & 50-100 \\
	\hline \StudioDiFattibilita{}  & 40-100 & 50-100  \\
	\hline \PianoDiProgetto{}  & 40-100 & 50-100  \\
	\hline \PianoDiQualifica{}  & 40-100 & 50-100  \\
	\hline \AnalisiDeiRequisiti{}  & 40-100 & 50-100  \\
	\hline \Glossario{}  & 40-100 & 50-100  \\
	\hline VerbaleEsterno23\_12\_2016 & 40-100 & 50-100 \\
	\hline
	\caption{Valori indice di Gulpease - Fase A}
\end{longtable}

\paragraph{Indice Gunning Fog}\mbox{}\\
Per garantire la leggibilità della documentazione in lingua inglese il punteggio calcolato non deve superare 12, livello datto per un High School Senior Student, si individua l'ottimalità nel limite di 14 punti, corrispondente ad un livello adatto ad un College Sophomore.

\subsubsection{Metriche di processo}\label{sec:metriche_processo}
\paragraph{Schedule Variance}\mbox{}\\
Lo Schedule Variance Management permette di valutare lo stato dei progressi nella pianificazione. 
\[ SV=EV-PV \]
dove
\begin{itemize}
	\item $SV$ = Schedule Variance;
	\item $EV$ = Earned Value;
	\item $PV$ = Planned Value.
\end{itemize}
La formula calcola l'anticipo o il ritardo sulla pianificazione tramite la differenza fra il valore prodotto dal progetto nel momento della misurazione e il costo pianificato nel momento della misurazione.\\
Quando la Schedule Variance è di valore positivo si è in anticipo rispetto alla pianificazione. Se il valore è negativo si è in ritardo rispetto alla pianificazione. Quando il valore è zero si sta procedendo come pianificato.

\paragraph{Cost Variance}\mbox{}\\
Permette di calcolare le stime sull'utilizzo del budget. 
\[ CV=EV-AC \]
dove
\begin{itemize}
	\item $CV$ = Cost Variance;
	\item $EV$ = Earned Value;
	\item $AC$ = Actual Cost.
\end{itemize}
La formula calcola la differenza del costo maturato fra costo stimato e costo effettivamente sostenuto.

\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{Metriche per l'analisi}\mbox{}\\
Consentono di monitorare e controllare costi, scheduling e qualità. Consentono di prevedere quale sarà la misura del processo software all'inizio del suo ciclo di vita, per poterne rapportare le risorse.

\subparagraph{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.

\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$.

\subparagraph{Complessità ciclomatica}\mbox{}\\

Per mantenere sotto controlla la complessità del software prodotto è calcolata la complessità ciclomatica del codice. 
Sono dichiarati come accettabili range di complessità per i risultati ottenuti dal calcolo: range 1-10 riguardano programmi semplici con poco rishio d'errore e range 11-20 adatti a programmi complessi ma a rischio moderato in modo da massimizzarne la manutenibilità e semplicità di testing.

\paragraph{Metriche per la codifica}\mbox{}
\subparagraph{Metriche di Halstead}\mbox{}\\

Lo difficoltà di scrittura e comprensione del programma calcolato con le metriche di Halstead:
\begin{itemize}
	\item range ottimale: 0-15;
	\item range di accettazione 0-25.
\end{itemize}

Lo sforzo complessivo di scrittura del programma è calcolato con le metriche di Halstead:
\begin{itemize}
	\item range ottimale: 0-300;
	\item range di accettazione: 0-400.
\end{itemize}

Il volume del programma è calcolato con le metriche di Halstead:
\begin{itemize}
	\item range ottimale: 20-100;
	\item range di accettazione: 20-1500.
\end{itemize}

\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)}
\`{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{Metriche di gestione degli errori}\mbox{}\\
\begin{longtable}{|P{6cm}|c|c|P{4cm}|}
{'fraction_non_alphanumeric': 0.07954935376872926, 'fraction_numerical': 0.01595562164016928, 'mean_word_length': 4.83873121869783, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6347427', 'n_tokens_mistral': 5899, 'n_tokens_neox': 5811, 'n_words': 2119}