Skip to content
This repository was archived by the owner on Jul 1, 2020. It is now read-only.

Fix finale norme #217

Merged
merged 1 commit into from
Jan 14, 2020
Merged

Fix finale norme #217

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
44 changes: 20 additions & 24 deletions interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/Documentazione.tex
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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}
Expand All @@ -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.''.
Expand All @@ -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}
Expand All @@ -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}
Expand Down Expand Up @@ -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}
Expand All @@ -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}
Expand All @@ -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}
Expand Down
14 changes: 7 additions & 7 deletions interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/GaranziaQualita.tex
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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;
Expand All @@ -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}

Expand All @@ -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.
Expand Down Expand Up @@ -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}
Expand Down
12 changes: 6 additions & 6 deletions interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/GestConfigurazione.tex
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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:
Expand All @@ -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};
Expand All @@ -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}
Expand Down
10 changes: 5 additions & 5 deletions interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/ProcDiRisoluzioneDeiProblemi.tex
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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}
Expand Down Expand Up @@ -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.
Loading