<commit_before>\section{Visione generale della strategia di verifica}
La volont\`a del team \`e quella di automatizzare il pi\`u possibile il lavoro di verifica. Saranno quindi utilizzati dei \textit{tools} adeguatamente configurati, con lo scopo di avere un riscontro affidabile e quantitativo che permetta di assicurare il grado di qualit\`a voluto. 

\subsection{Definizione degli obiettivi}
\subsubsection{Qualit\`a di processo}
Molto spesso i prodotti scadenti derivano da processi scadenti. Per questo motivo, e per le seguenti ragioni, assicurare la qualità dei processi \`e un obiettivo primario per il team BugBusters:
\begin{itemize}
	\item aiuta ad ottimizzare l'uso di risorse;
	\item permette di contenere i costi;
	\item migliora la stima dei rischi e degli impegni.
\end{itemize}
Un processo dovrebbe essere in grado di migliorare costantemente le proprie performance, che devono quindi essere costantemente misurabili e misurate. Inoltre, le attivit\`a di ciascun processo e i costi associati devono essere in linea con quanto indicato nel \textit{Piano di Progetto}. \\
Si \`e dunque deciso di perseguire la qualit\`a servendosi dei seguenti modelli: 
% todo: note a pie di pagina o link??
\begin{itemize}
	\item \textit{SPICE} (Simulation \textbf{P}rogram with \textbf{I}ntegrated \textbf{C}ircuit \textbf{E}mphasis): definito nello standard ISO/IEC 15504, per poter valutare in modo oggettivo i processi dal punto di vista della maturit\`a;
	\item \textit{PCDA} (\textbf{P}lan \textbf{D}o \textbf{C}hek \textbf{A}ct): per il controllo delle attività di processo ripetibili e misurabili e per la manutenibilità dei processi stessi incrementandone la qualit\`a.
\end{itemize}

\subsubsection{Qualit\`a di prodotto}
Lo standard ISO/IEC 9126 classifica la qualit\`a del software e definisce delle metriche per la sua misurazione. Il team BugBusters ha scelto di utilizzare queste metriche, al fine di assicurare la qualit\`a del prodotto finale.

\subsection{Procedure di controllo}
\subsubsection{Qualit\`a di processo}
La pianificazione delle attivit\`a volte al miglioramento continuo dei processi sono descritte nel \textit{Piano di Progetto v1.0.0}. Le linee guida per la gestione della qualit\`a del processo, invece, seguono il modello PCDA e descrivono come devono essere attuate le procedure di controllo:
\begin{itemize}
	\item la pianificazione deve essere dettagliata, e le attivit\`a pianificate devono essere monitorate;
	\item le risorse necessarie per conseguire gli obiettivi devono essere definite;
	\item il miglioramento della qualit\`a del processo deve essere verificato attraverso l'utilizzo di apposite metriche, che verranno descritte in seguito.
\end{itemize}

\subsubsection{Qualit\`a di prodotto}
Il controllo per la qualit\`a del prodotto definisce i seguenti processi:
\begin{itemize}
	\item \textit{\textbf{SQA}} (\textbf{S}oftware \textbf{Q}uality \textbf{A}ssurance}): si occupa di assicurare che i processi siano implementati secondo quanto pianificato e che siano forniti sistemi di misurazione dei processi;
	\item \textbf{verifica}: si occupa di accertare che l'esecuzione dei processi non abbia introdotto degli errori, e accerta il rispetto delle regole, delle convenzioni e delle procedure;
	\item \textbf{validazione}: si occupa di accertare che i prodotti realizzati siano conformi alle attese.
\end{itemize}

\subsection{Strategia}
Nel piano di progetto vengono fissate delle scadenze che devono necessariamente essere rispettate: \`e dunque necessario definire un'efficace strategia di qualifica. I controlli saranno effettuati in maniera automatica secondo quanto previsto nelle \textit{Norme di Progetto v1.0.0}. 

\subsection{Responsabilit\`a}
La responsabilit\`a della verifica viene affidata al \textit{Responsabile di progetto} e ai \textit{Verificatori} secondo quanto previsto nel \textit{Piano di Progetto v1.0.0}.

\subsection{Risorse}
Vengono consumati due tipi di risorse:
\begin{itemize}
	\item \textbf{umane}: in particolare il \textit{Responsabile di progetto} e il \textit{Verificatore}; le ore impiegate vengono contabilizzate e messe a calendario secondo quanto previsto dal \textit{Piano di Progetto v1.0.0} e dalle \href{regole}{http://www.math.unipd.it/~tullio/IS-1/2015/Dispense/PD01.pdf} del progetto didattico. Ai fini della qualifica, tuttavia, si pu\`o tralasciare l'aspetto economico, in quanto esso non rientra nel dominio del presente documento;
		\item \textbf{tecnologiche}: i \textit{tool} utilizzati per il controllo della qualit\`a. Le operazioni effettuate  consumeranno unit\`a di calcolo considerate a costo nullo, in quanto le elaborazioni verranno effettuate su macchine per le quali non \`e richiesto nessun contributo e per un tempo non degno di nota.
\end{itemize}

\subsection{Misure e Metriche}
Di seguito sono elencate le metriche utilizzate per valutare i processi in modo quantitativo.
\subsubsection{Metriche per i processi}
Le seguenti metriche rappresentano un indicare volto a monitorare i tempi e i costi associati al progetto. Sono metriche di tipo \textit{consuntivo} che danno un riscontro immediato sullo stato attuale: gli indici verranno valutati dal \textit{Responsabile di progetto} e, se necessario, verranno presi provvedimenti per sistemare la situazione. 

\paragraph{Durata del progetto}
Rappresenta la durata del progetto espresso in numero di mesi o, per progetti di dimensioni contenute, in settimane. \`E utilizzata per valutare l'effettiva disponibilità del prodotto realizzato.\\
\textit{Durata del progetto = Numero di mesi (o di settimane o di giorni)}

\paragraph{Schedule Variance}
Indica se si \`e in linea, in anticipo o in ritardo rispetto alla schedulazione delle attività di progetto
pianificate. \\
\textit{SV = BCW P − BCW S} \\
Dove:
\begin{itemize}
	\item \textbf{BCW P}: indica il valore delle attivit\`a realizzate alla data corrente;
	\item \textbf{BCW S}: indica il costo pianificato per realizzare le attività di progetto alla data corrente.
\end{itemize}
\`E un indicatore di
efficacia soprattutto nei confronti del \textit{Cliente}. Se SV > 0 significa che il progetto sta procedendo
con maggior velocit\`a rispetto a quanto pianificato, viceversa se negativo.

\paragraph{Budget Variance}
Indica se alla data corrente si \`e speso di pi\`u o di meno rispetto a quanto previsto.\\
\textit{BV = BCW S − ACW P}\\
Dove:
\begin{itemize}
	\item \textbf{BCW S}: indica il costo pianificato per realizzare le attivit\`a di progetto alla data corrente;
	\item \textbf{ACW P}: indica il costo effettivo sostenuto alla data corrente. \`E un indicatore con
un valore unicamente contabile e finanziario. Se BV > 0 significa che il progetto sta spendendo
il proprio budget con minor velocit\`a di quanto pianificato, viceversa se negativo.
\end{itemize}

\paragraph{Produttivit\`a}
% todo<commit_msg>Added some process' metrics and removed 'Durata del progetto'<commit_after>\section{Visione generale della strategia di verifica}
La volont\`a del team \`e quella di automatizzare il pi\`u possibile il lavoro di verifica. Saranno quindi utilizzati dei \textit{tools} adeguatamente configurati, con lo scopo di avere un riscontro affidabile e quantitativo che permetta di assicurare il grado di qualit\`a voluto. 

\subsection{Definizione degli obiettivi}
\subsubsection{Qualit\`a di processo}
Molto spesso i prodotti scadenti derivano da processi scadenti. Per questo motivo, e per le seguenti ragioni, assicurare la qualità dei processi \`e un obiettivo primario per il team BugBusters:
\begin{itemize}
	\item aiuta ad ottimizzare l'uso di risorse;
	\item permette di contenere i costi;
	\item migliora la stima dei rischi e degli impegni.
\end{itemize}
Un processo dovrebbe essere in grado di migliorare costantemente le proprie performance, che devono quindi essere costantemente misurabili e misurate. Inoltre, le attivit\`a di ciascun processo e i costi associati devono essere in linea con quanto indicato nel \textit{Piano di Progetto}. \\
Si \`e dunque deciso di perseguire la qualit\`a servendosi dei seguenti modelli: 
% todo: note a pie di pagina o link??
\begin{itemize}
	\item \textit{SPICE} (Simulation \textbf{P}rogram with \textbf{I}ntegrated \textbf{C}ircuit \textbf{E}mphasis): definito nello standard ISO/IEC 15504, per poter valutare in modo oggettivo i processi dal punto di vista della maturit\`a;
	\item \textit{PCDA} (\textbf{P}lan \textbf{D}o \textbf{C}hek \textbf{A}ct): per il controllo delle attività di processo ripetibili e misurabili e per la manutenibilità dei processi stessi incrementandone la qualit\`a.
\end{itemize}

\subsubsection{Qualit\`a di prodotto}
Lo standard ISO/IEC 9126 classifica la qualit\`a del software e definisce delle metriche per la sua misurazione. Il team BugBusters ha scelto di utilizzare queste metriche, al fine di assicurare la qualit\`a del prodotto finale.

\subsection{Procedure di controllo}
\subsubsection{Qualit\`a di processo}
La pianificazione delle attivit\`a volte al miglioramento continuo dei processi sono descritte nel \textit{Piano di Progetto v1.0.0}. Le linee guida per la gestione della qualit\`a del processo, invece, seguono il modello PCDA e descrivono come devono essere attuate le procedure di controllo:
\begin{itemize}
	\item la pianificazione deve essere dettagliata, e le attivit\`a pianificate devono essere monitorate;
	\item le risorse necessarie per conseguire gli obiettivi devono essere definite;
	\item il miglioramento della qualit\`a del processo deve essere verificato attraverso l'utilizzo di apposite metriche, che verranno descritte in seguito.
\end{itemize}

\subsubsection{Qualit\`a di prodotto}
Il controllo per la qualit\`a del prodotto definisce i seguenti processi:
\begin{itemize}
	\item \textit{\textbf{SQA}} (\textbf{S}oftware \textbf{Q}uality \textbf{A}ssurance}): si occupa di assicurare che i processi siano implementati secondo quanto pianificato e che siano forniti sistemi di misurazione dei processi;
	\item \textbf{verifica}: si occupa di accertare che l'esecuzione dei processi non abbia introdotto degli errori, e accerta il rispetto delle regole, delle convenzioni e delle procedure;
	\item \textbf{validazione}: si occupa di accertare che i prodotti realizzati siano conformi alle attese.
\end{itemize}

\subsection{Strategia}
Nel piano di progetto vengono fissate delle scadenze che devono necessariamente essere rispettate: \`e dunque necessario definire un'efficace strategia di qualifica. I controlli saranno effettuati in maniera automatica secondo quanto previsto nelle \textit{Norme di Progetto v1.0.0}. 

\subsection{Responsabilit\`a}
La responsabilit\`a della verifica viene affidata al \textit{Responsabile di progetto} e ai \textit{Verificatori} secondo quanto previsto nel \textit{Piano di Progetto v1.0.0}.

\subsection{Risorse}
Vengono consumati due tipi di risorse:
\begin{itemize}
	\item \textbf{umane}: in particolare il \textit{Responsabile di progetto} e il \textit{Verificatore}; le ore impiegate vengono contabilizzate e messe a calendario secondo quanto previsto dal \textit{Piano di Progetto v1.0.0} e dalle \href{regole}{http://www.math.unipd.it/~tullio/IS-1/2015/Dispense/PD01.pdf} del progetto didattico. Ai fini della qualifica, tuttavia, si pu\`o tralasciare l'aspetto economico, in quanto esso non rientra nel dominio del presente documento;
		\item \textbf{tecnologiche}: i \textit{tool} utilizzati per il controllo della qualit\`a. Le operazioni effettuate  consumeranno unit\`a di calcolo considerate a costo nullo, in quanto le elaborazioni verranno effettuate su macchine per le quali non \`e richiesto nessun contributo e per un tempo non degno di nota.
\end{itemize}

\subsection{Misure e Metriche}
Di seguito sono elencate le metriche utilizzate per valutare i processi in modo quantitativo.

\subsubsection{Metriche per il prodotto}
%todo, messo prima per la necessità di esprimere le unità di misura della dimensione del progetto

\subsubsection{Metriche per i processi}
Le seguenti metriche rappresentano un indicare volto a monitorare i tempi e i costi associati al progetto. Sono metriche di tipo \textit{consuntivo} che danno un riscontro immediato sullo stato attuale: gli indici verranno valutati dal \textit{Responsabile di progetto} e, se necessario, verranno presi provvedimenti per sistemare la situazione. 

\paragraph{Schedule Variance}
Indica se si \`e in linea, in anticipo o in ritardo rispetto alla schedulazione delle attività di progetto
pianificate. \\
\textit{SV = EV − PV} \\
Dove:
\begin{itemize}
	\item \textbf{EV}: indica il valore delle attivit\`a realizzate alla data corrente;
	\item \textbf{PV}: indica il costo pianificato per realizzare le attività di progetto alla data corrente.
\end{itemize}
\`E un indicatore di efficacia soprattutto nei confronti del \textit{Cliente}. Se SV > 0 significa che il progetto sta procedendo con maggior velocit\`a rispetto a quanto pianificato, viceversa se negativo. Alla fine del progetto questo indice assumer\`a il valore 0, perch\`e in quel momento tutte le attivit\`a saranno state realizzate.

\paragraph{Budget Variance}
Indica se alla data corrente si \`e speso di pi\`u o di meno rispetto a quanto previsto.\\
\textit{BV = EV – AC}\\
Dove:
\begin{itemize}
	\item \textbf{EV}: indica il costo pianificato per realizzare le attivit\`a di progetto alla data corrente;
	\item \textbf{AC}: indica il costo effettivo sostenuto alla data corrente. \`E un indicatore con
un valore unicamente contabile e finanziario. Se BV > 0 significa che il progetto sta spendendo
il proprio budget con minor velocit\`a di quanto pianificato, viceversa se negativo.
\end{itemize}

\paragraph{Produttivit\`a}
% todo

\paragraph{Numero di cambiamenti apportati}
Rappresenta il numero di modifiche apportate al progetto in corso d'opera. Queste modifiche possono riguardare i requisiti rilevati, le funzionalit\`a, la progettazione, il codice e i manuali o documenti scritti, e sono causate, molto spesso, da un cambiamento dei requisiti, sia esso voluto dal committente o derivato da un'errata interpretazione del fornitore. Misurare il numero di modifiche apportate al progetto \`e dunque fondamentale al fine di valutare gli impatti sui tempi di realizzazione e sui costi.//
\textit{M = MA} //
Dove \textbf{MA} indica le modifiche apportate al progetto.

\paragraph{Numero di errori rilevati}
Rappresenta il numero di errori rilevati nel prodotto durante le diverse fasi di sviluppo. Gli errori possono essere di tre tipi:
\begin{itemize}
	\item \textbf{di documentazione}, rilevati durante le attivit\`a di revisione;
	\item \textbf{di codice}, rilevati durante le attivit\`a di test;
		item \textbf{di progettazione}.
\end{itemize}
Questa metrica \`e fondamentale per valutare la qualit\`a del prodotto sviluppato e l'efficacia delle attivit\`a di revisione e test. Il numero di errori \`e normalizzato rispetto alle dimensioni del progetto (in KLOCs o FPs).//
\textit{NE = NER / DP} //
Dove:
\begin{itemize}
	\item \textbf{NER} \`e il nuemro di errori rilevati;
	\item \textbf{DP} \`e la dimensione del progetto espressa in KLOCs o FPs.
\end{itemize}
{'fraction_non_alphanumeric': 0.06799523305084745, 'fraction_numerical': 0.004038665254237288, 'mean_word_length': 5.027533918595371, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 7, 'https://': 0, 'lorem ipsum': 0, 'www.': 2, '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': '3525532', 'n_tokens_mistral': 5066, 'n_tokens_neox': 5101, 'n_words': 1975}