Merge pull request #217 from Maxelweb/feature/wrNormeDiProgetto

Fix finale norme

Author: lorenzodeinegri

interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/Documentazione.tex

@@ -100,32 +100,30 @@ \section{Processi di Supporto}
 					\item i termini seguono l'ordine lessicografico;
 					\item ogni termine è spiegato in maniera chiara e in nessun modo ambigua.
 				\end{itemize}
-				La stesura del glossario deve avvenire in parallelo alla stesura dei documenti al fine di evitare confusione tra i termini. Inoltre, ogni parola nei documenti, presente nel glossario, deve essere caratterizzata dallo stile ``maiuscoletto'' con il pedice ``G''. Non si richiede tale stile se la parola presente nel documento è stata precendentemente caratterizzata con la suddetta notazione.
+				La stesura del glossario deve avvenire in parallelo alla stesura dei documenti al fine di evitare confusione tra i termini. Inoltre, ogni parola dei documenti riportata nel glossario, deve essere caratterizzata dallo stile ``maiuscoletto'' con il pedice ``G''. Non si richiede tale stile se la parola presente nel documento è stata precedentemente caratterizzata con la suddetta notazione.
 			\paragraph{Lettere}
-				La lettera di presentazione dovrà seguire il classico layout per lettere, il che implica la presenza dei mittenti e destinatari, il logo dell'azienda e la lista di tutti i documenti rilasciati, nonchè il preventivo per il progetto.
+				La lettera di presentazione dovrà seguire il classico layout per lettere, il che implica la presenza dei mittenti e destinatari, il logo del gruppo e la lista di tutti i documenti rilasciati, nonché il preventivo per il progetto.
 		\subsubsection{Norme tipografiche}
 			\paragraph{Convenzioni sui nomi dei file}
 				Si è deciso di usare la convenzione ``camel case'' per i nomi di file e cartelle. Le regole seguite saranno le seguenti:
 				\begin{itemize}
 					\item il nome dei file composti da più parole avranno la prima lettera minuscola ed ogni parola in seguito inizierà con una maiuscola;
 					\item tra le parole non sarà presente alcun separatore;
 					\item le preposizioni non verranno omesse;
-					\item sono omessi da questa sintassi le estensione dei file.
+					\item sono escluse da questa sintassi le estensione dei file.
 				\end{itemize}
 				Alcuni esempi corretti sono:
 				\begin{itemize}
-					\item studioDiFattibilitá.pdf;
-					\item immagine.png
+					\item convenzioniSuiNomiDeiFile.tex;
+					\item documentazione.tex
 				\end{itemize}
 				Alcuni esempi non corretti sono:
 				\begin{itemize}
-					\item StudioDiFattibilitá (la prima lettera è maiuscola);
-					\item studio Di Fattibilitá (usa un carattere separatore);
-					\item studio\_Di\_Fattibilitá (usa un carattere separatore);
-					\item studioFattibilitá (omette una preposizione).
+					\item ConvenzioniSuiNomiDeiFile (la prima lettera è maiuscola);
+					\item convenzioni Sui Nomi Dei File (usa un carattere separatore);
+					\item convenzioni\_Sui\_Nomi\_Dei\_File (usa un carattere separatore);
+					\item convenzioniNomiFile (omette preposizioni).
 				\end{itemize}
-			\paragraph{Glossario}
-				I termini appartenenti al glossario si possono identificare dallo stile della parola, in particolare si è deciso di utilizzare lo stile ``maiuscoletto'' con una ``G'' come pedice, es. \glock{Efficienza}. Inoltre, tutte le parole presenti nei titoli, didascalie e tabelle che appartengono al glossario non verranno segnalate dalla ``G''.
 			\paragraph{Stile del testo}
 				I vari stili del testo hanno una specifica funzione semantica.
 				\begin{itemize}
@@ -138,7 +136,7 @@ \section{Processi di Supporto}
 						\end{itemize}
 				\end{itemize}
 			\paragraph{Elenchi puntati}
-				Ogni elemento dell'elenco deve essere seguito da un punto e virgola, fatta eccezione per l'ultimo elemento che sarà seguito da un punto; di conseguenza la prima lettera di ogni sentenza deve essere minuscola, ad eccezione della prima frase se quest'ultima inizia un paragrafo. Gli elenchi avranno punto elenco differente a seconda della loro tipologia:
+				Ogni elemento dell'elenco deve essere seguito da un punto e virgola, fatta eccezione per l'ultimo elemento che sarà seguito da un punto; di conseguenza la prima lettera di ogni voce dell'elenco deve essere minuscola, ad eccezione della prima frase se quest'ultima è posta all'inizio di paragrafo. Gli elenchi avranno punto elenco differente a seconda della loro tipologia:
 				\begin{itemize}
 					\item per gli elenchi non ordinati si è scelto di usare come punto elenco un cerchietto pieno e come sub-punto elenco il trattino;
 					\item per gli elenchi ordinati si è optato per un punto elenco ``flessibile'', ossia possono essere usati sia i numeri che i letterali, purché quest'ultimi siano in minuscolo, seguiti da un punto, esempio ``1.'' o ``a.''.
@@ -150,7 +148,7 @@ \section{Processi di Supporto}
 					\item \textbf{versione:} viene utilizzato il formato vXX.XX.XX.
 				\end{itemize}
 			\paragraph{Sigle}
-				Il progetto richiede la redazione di un insieme di documenti, sotto elencata è la lista dei documenti con relative sigle:
+				Il progetto richiede la redazione di un insieme di documenti; segue l'elenco dei documenti con relative sigle:
 				\begin{itemize}
 					\item documenti esterni:
 						\begin{itemize}
@@ -164,7 +162,7 @@ \section{Processi di Supporto}
 						\begin{itemize}
 							\item \textbf{glossario - G:} raccoglie tutti i termini che necessitano di una disambiguazione e/o una descrizione più approfondita;
 							\item \textbf{norme di progetto - NdP:} è una raccolta di tutte le regole e le norme utilizzate durante il ciclo di vita del software;
-							\item \textbf{studio di fattibilità - SdF:} descrive i vari capitolati, sia esclusi che scelti, analizzando brevemente il loro pro e contro.
+							\item \textbf{studio di fattibilità - SdF:} descrive i vari capitolati analizzando brevemente i loro pro e contro.
 						\end{itemize};
 					\item \textbf{verbali - V:} essi possono essere sia interni che esterni e descrivono in maniera concisa tutti gli argomenti discussi e le decisione prese durante un incontro.
 				\end{itemize}
@@ -195,19 +193,18 @@ \section{Processi di Supporto}
 					\item DB: \glock{database};
 					\item VCS: \glock{version control system}.
 				\end{itemize}
-		\subsubsection{Introduzione alle Metriche di Qualità}
-			\paragraph{QC-1 Comprensione}
-				\subparagraph{Scopo}
+		\subsubsection{Comprensione (QC-1)}
+				\paragraph{Scopo}
 					Per fornire una documentazione fruibile e comprensibile si è deciso di monitorare la sua qualità tramite delle metriche significative.
-				\subparagraph{Introduzione alle Metriche}
+				\paragraph{Introduzione alle Metriche di Qualità}
 					Per la funzionabilità si é deciso di utilizzare le seguenti metriche:
 					\begin{itemize}
 						\item QM-PROD-1 \glock{Indice di Gulpease} (GULP);
 						\item QM-PROD-2 Correttezza ortografica (CORT).
 					\end{itemize}
-				\subparagraph{QM-PROD-1 Indice di Gulpease (GULP)}
+				\paragraph{QM-PROD-1 Indice di Gulpease (GULP)}
 					\subparagraph{Descrizione}
-						La metrica GULP permette di misurare la leggibilità di un documento basandosi su alcuni criteri.
+						La metrica GULP permette di misurare la leggibilità di un documento basandosi sulla formula riportata di seguito.
 					\subparagraph{Unità di Misura}
 						La metrica è espressa tramite un numero intero.
 					\subparagraph{Formula}
@@ -222,10 +219,9 @@ \section{Processi di Supporto}
 							\item se il risultato è maggiore di 40 allora il documento esiste ed è leggibile da chi possiede un diploma superiore;
 							\item se il risultato è maggiore di 60 allora il documento esiste ed è leggibile da chi possiede una licenza media;
 							\item se il risultato è maggiore di 80 allora il documento esiste ed è leggibile da chi possiede una licenza elementare;
-							\item se il risultato è maggiore di 60 allora il documento esiste ed è leggibile da chi possiede una licenza media;
 							\item se il risultato è pari a 100 allora il documento esiste ed è molto più che leggibile.
 						\end{itemize}
-				\subparagraph{QM-PROD-2 Correttezza ortografica (CORT)}
+				\paragraph{QM-PROD-2 Correttezza ortografica (CORT)}
 					\subparagraph{Descrizione}
 					La metrica CORT permette di misurare la correttezza, a livello lessicografico, di un documento.
 					\subparagraph{Unità di Misura}
@@ -241,9 +237,9 @@ \section{Processi di Supporto}
 						\end{itemize}
 		\subsubsection{Elementi grafici}
 			\paragraph{Tabelle}
-				Le tabelle sono sempre accompagnate da un titolo ed il numero della tabella, esse sono indicizzate a parte.
+				Le tabelle sono sempre accompagnate da un titolo e dal numero della tabella; sono indicizzate separatamente rispetto al resto del contenuto.
 			\paragraph{Immagini}
-				Le immagini sono sempre accompagnate da una didascalia descrittiva ed il numero della figura, esse sono indicizzate a parte.
+				Le immagini sono sempre accompagnate da una didascalia descrittiva e dal numero della figura; sono indicizzate separatamente rispetto al resto del contenuto.
 			\paragraph{Diagrammi UML}
 				I diagrammi UML vengono inseriti all'interno della documentazione sotto forma di immagini.
 		\subsubsection{Strumenti}

interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/GaranziaQualita.tex

@@ -2,11 +2,11 @@ \subsection{Garanzia della Qualità}
 
 	\subsubsection{Scopo}
 
-		Si occupa di stabilire una metrica precisa per tutti i servizi nell'ambito della verifica e della validazione, mantenendo un certo grado di qualità che rimanga uniforme e misurabile durante tutto il ciclo di vita del software.
+		Si occupa di stabilire una metrica precisa per tutti i servizi nell'ambito della verifica e della validazione, mantenendo un dato livello di qualità che rimanga uniforme e misurabile durante tutto il ciclo di vita del software.
 
 	\subsubsection{Aspettative}
 
-		Il sistema di qualità deve fornire delle metriche di giudizio uniformi volte a quantificare in maniera comprensibile la correttezza dei documenti e del software. Ciò va unito anche all'affidabilità nello svolgimento dei processi di verifica, che vanno monitorati e guidati nell'intera procedura, senza lasciare a interpretazioni. Pertanto, ci si aspetta:
+		Il sistema di qualità deve fornire delle metriche di giudizio uniformi volte a quantificare con chiarezza la correttezza dei documenti e del software. Ciò va unito anche all'affidabilità nello svolgimento dei processi di verifica, che vanno monitorati e guidati nell'intera procedura, senza lasciare a interpretazioni. Pertanto, ci si aspetta:
 		\begin{itemize}
 			\item un prodotto software di qualità;
 			\item una documentazione completa e facilmente comprensibile per tutti;
@@ -25,13 +25,13 @@ \subsection{Garanzia della Qualità}
 		\end{itemize}
 
 		Per ogni processo mirato alla qualità si definiscono delle metriche che vengono riportate in ciascuna sezione del presente documento.
-		La registrazione dei risultati ottenuti dall'analisi della qualità sono salvati con degli appositi report.
+		Le registrazioni dei risultati ottenuti dall'analisi della qualità sono salvate con degli appositi report.
 
 		\paragraph{Obiettivi Qualità di Prodotto}
 
 			La qualità del prodotto viene garantita attraverso l'attuazione dei processi di verifica e validazione basati su fondamenti normativi. In particolare, definiamo quanto segue:
 			\begin{itemize}
-				\item \textbf{Verifica:} processo di analisi continua che garantisce qualità dei processi di fornitura del prodotto;
+				\item \textbf{Verifica:} processo di controllo che garantisce qualità dei processi di fornitura del prodotto;
 				\item \textbf{Validazione:} processo di controllo del prodotto volto a confermare le aspettative, i requisiti e le funzionalità concordate.
 			\end{itemize}
 
@@ -42,8 +42,8 @@ \subsection{Garanzia della Qualità}
 			La qualità di processo deve essere perseguita nel corso del ciclo di vita del software attraverso i principi di efficacia ed efficienza mirati al prodotto.
 			Nello specifico definiamo quanto segue:
 			\begin{itemize}
-				\item \textbf{Efficacia:} si richiede un prodotto valido in relazione alle aspettative;
-				\item \textbf{Efficienza:} i processi devono convergere con costi ridotti in termini di risorse a pari di qualità di prodotto.
+				\item \textbf{Efficacia:} si richiede un prodotto che soddisfi le richieste del proponente;
+				\item \textbf{Efficienza:} i processi devono convergere con costi ridotti in termini di risorse a pari qualità di prodotto.
 			\end{itemize}
 
 			Ciascun processo va migliorato durante la sua esecuzione facendo uso di monitoraggi mirati che permettano di acquisire, attraverso l'esperienza, una risposta critica alla qualità stessa del processo.
@@ -75,7 +75,7 @@ \subsection{Garanzia della Qualità}
 
 		\begin{itemize}
 			\item QC : indica letteralmente \textit{Quality Characteristic};
-			\item \(\lambda\) : numero intero che parte da 1 e indica la caratteristica di prodotto.
+			\item \(\lambda\) : numero intero che indica la caratteristica di prodotto e parte da 1.
 		\end{itemize}
 
 		\subsection{Classificazione delle Metriche}

interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/GestConfigurazione.tex

@@ -20,7 +20,7 @@ \subsubsection{Repository}
 
 	\paragraph{Configurazione del Workflow}
 
-	Usando \textit{Git}, è possibile clonare e scaricare da remoto tutto il contenuto della repository per averne una copia in locale su cui poterci lavorare, visionando la cronologia dei file modificati ad ogni \glock{commit} da parte di un membro del gruppo.
+	Usando \textit{Git}, è possibile clonare e scaricare da remoto tutto il contenuto della repository per averne una copia in locale su cui poter lavorare, visionando la cronologia dei file modificati ad ogni \glock{commit} da parte di un membro del gruppo.
 	\textit{Git}, inoltre, include la possibilità di creare dei \glock{branch} (locali e remoti) in cui poter sviluppare in maniera indipendente una funzionalità, che potrà essere integrata successivamente, senza bisogno di stare al passo con gli aggiornamenti della repository.
 
 	Pertanto, si è deciso di stabilire il seguente canone di \glock{workflow} per quanto concerne la documentazione:
@@ -40,7 +40,7 @@ \subsubsection{Repository}
 
 		\subparagraph{Configurazione}
 
-		In generale, vengono utilizzati alcuni file con formati speciali per la configurazione della repository. Questi file vanno modificati solamente dall'\glock{amministratore}, o su richiesta, in base alle necessità.
+		In generale, vengono utilizzati alcuni file con formati speciali per la configurazione della repository. Questi file vanno modificati solamente dall'\glock{amministratore}, o su richiesta, anche da parte di altri membri del gruppo, in base alle necessità.
 		\begin{itemize}
 			\item \textbf{.gitignore} contiene tutte le regole per evitare di caricare nella repository dei formati non autorizzati (es: file eseguibili);
 			\item \textbf{.yml} contiene la configurazione di una \glock{GitHub Action} per dirigere il \glock{Workflow};
@@ -51,10 +51,10 @@ \subsubsection{Repository}
 
 		Per la documentazione si usano principalmente i seguenti tipi di file:
 		\begin{itemize}
-			\item \textbf{file .tex:} che contiene il codice sorgente \LaTeX{} del documento;
-			\item \textbf{file .pdf:} che è il documento compilato;
-			\item \textbf{file .png:} che identifica una immagine;
-			\item \textbf{file .md:} che identifica un file scritto in \glock{Markdown}, generalmente usato per gli appunti.
+			\item \textbf{file .tex:} contiene il codice sorgente \LaTeX{} del documento;
+			\item \textbf{file .pdf:} è il documento compilato;
+			\item \textbf{file .png:} identifica una immagine;
+			\item \textbf{file .md:} identifica un file scritto in \glock{Markdown}, generalmente usato per gli appunti.
 		\end{itemize}
 
 	\paragraph{Struttura della repository}

interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/ProcDiRisoluzioneDeiProblemi.tex

@@ -3,14 +3,14 @@ \subsection{Processo di risoluzione dei problemi}
 	Il processo di risoluzione dei problemi definisce una procedura da seguire per analizzare e rimuovere dei problemi, qualsiasi sia la loro origine, scoperti durante l'esecuzione del processo di sviluppo, di manutenzione o di altri processi.
 
 	\subsubsection{Scopo}
-		L'obiettivo del processo di risoluzione dei problemi è quello di fornire un mezzo tempestivo, efficace e documentato per assicurarsi che tutti i problemi vengano analizzati, documentati, risolti e, in un'ottica di miglioramento continuo evitati.
+		L'obiettivo del processo di risoluzione dei problemi è fornire un mezzo tempestivo, efficace e documentato per assicurarsi che tutti i problemi vengano analizzati, documentati, risolti e, in un'ottica di miglioramento continuo, evitati.
 
 	\subsubsection{Aspettative}
 		Istanziando questo processo si intende ottenere:
 		\begin{itemize}
-		 	\item Una qualità della documentazione e del codice più elevata;
-		 	\item Un modo efficiente ed efficace per trovare e correggere errori evitando che si propaghino;
-		 	\item Un tracciamento continuo degli errori più comuni e delle loro fonti, in modo tale da risolverli all'origine.
+		 	\item una qualità della documentazione e del codice più elevata;
+		 	\item un modo efficiente ed efficace per trovare e correggere errori evitando che si propaghino;
+		 	\item un tracciamento continuo degli errori più comuni e delle loro fonti, in modo tale da risolverli all'origine.
 		 \end{itemize}
 	\subsubsection{Attività}
 		\paragraph{Implementazione del processo}
@@ -56,4 +56,4 @@ \subsection{Processo di risoluzione dei problemi}
 				\item Il procedimento di risoluzione dei problemi verrà valutato: si valuterà che i problemi siano stati effettivamente risolti, che le eventuali tendenze siano state annullate ed infine che non siano stati introdotti altri errori.
 			\end{enumerate}
 		\paragraph{Risoluzione del problema}
-			Quando uno o più problemi saranno scovati, nel prodotto software o in un'attività, dovrà essere preparato un report aprendo una issue nell'ITS (Issue tracking System) utilizzato per ogni problema individuato. Lo stesso report dovrà essere parte integrante del procedimento che è stato descritto nell'attività di istanziazione del processo.
+			Quando uno o più problemi saranno rilevati, nel prodotto software o in un'attività, dovrà essere preparato un report aprendo una issue nell'ITS (Issue tracking System) utilizzato per ogni problema individuato. Lo stesso report dovrà essere parte integrante del procedimento che è stato descritto nell'attività di istanziazione del processo.