diff --git a/esterni/piano_qualifica/main.tex b/esterni/piano_qualifica/main.tex index 675ed2b..e0df71a 100644 --- a/esterni/piano_qualifica/main.tex +++ b/esterni/piano_qualifica/main.tex @@ -1,6 +1,6 @@ %!TEX output_directory = .cache % --------------------------- -% [ Piano di Progetto ] +% [ Piano di Qualifica ] % ---------------------- % Red Round Robin % Progetto di SWE (2019-20) @@ -16,7 +16,7 @@ \newcommand{\docVersione}{1.0.0\docBaseline} \newcommand{\docNomeProgetto}{ ThiReMa Project } \newcommand{\docStatus}{Approvato} -\newcommand{\docUso}{esterno} +\newcommand{\docUso}{Esterno} \newcommand{\docDescrizione}{ Il documento contiene un piano di qualifica atto a garantire la qualità del suo prodotto. } @@ -26,7 +26,7 @@ \newcommand{\docDestinatari}{ SanMarco Informatica \\& Prof. Tullio Vardanega \\& - Prof Riccardo Cardin \\& + Prof. Riccardo Cardin \\& Red Round Robin } \newcommand{\docRedattori}{ diff --git a/esterni/piano_qualifica/res/registro.tex b/esterni/piano_qualifica/res/registro.tex index 6eca8c3..779c47e 100644 --- a/esterni/piano_qualifica/res/registro.tex +++ b/esterni/piano_qualifica/res/registro.tex @@ -10,6 +10,9 @@ \section*{Registro delle modifiche} \endfirsthead % ----- Modificare da qui ----- + + 1.0.1+b0.4 & Scrittura e verifica sezione \S3 & 2020-02-17 & Giuseppe Vito Bitetti & Amministratore \\ + \hline 1.0.0+b0.4 & Approvazione per il rilascio esterno & 2020-01-15 & Alessandro Tommasin & Responsabile \\ \hline 0.2.0+b0.4 & Approvazione documento & 2020-01-15 & Alessandro Tommasin & Responsabile \\ @@ -30,4 +33,4 @@ \section*{Registro delle modifiche} \hline \end{longtable} -\end{center} \ No newline at end of file +\end{center} diff --git a/esterni/piano_qualifica/res/sections/Sez1-Introduzione/Introduzione.tex b/esterni/piano_qualifica/res/sections/Sez1-Introduzione/Introduzione.tex index 2bc53f2..d92bca0 100644 --- a/esterni/piano_qualifica/res/sections/Sez1-Introduzione/Introduzione.tex +++ b/esterni/piano_qualifica/res/sections/Sez1-Introduzione/Introduzione.tex @@ -4,19 +4,19 @@ \section{Introduzione} \subsection{Scopo del prodotto} Lo scopo del prodotto è lo sviluppo di una web-application che, una volta ricevute delle misurazioni da uno o più sensori eterogenei, sia in grado di fornire ad un specifico ente il monitoraggio dei sensori stessi e di offrire un servizio di previsione basato sull'andamento di dati, come ad esempio prevedere un deterioramento complessivo tale da generare una necessaria azione di manutenzione preventiva, notificando il tutto tramite \glock{Telegram}. - \subsection{Glossario e Documenti esterni} + \subsection{Glossario e documenti esterni} Per evitare possibili ambiguità relative alle terminologie (che andranno indicate in \textsc{maiuscoletto})utilizzate nei vari documenti, verranno utilizzate due simboli: \begin{itemize} - \item Una \textit{D} al pedice per indicare il nome di un particolare documento. - \item Una \textit{G} al pedice per indicare un termine che sarà + \item una \textit{D} al pedice per indicare il nome di un particolare documento; + \item una \textit{G} al pedice per indicare un termine che sarà presente nel \dext{Glossario v1.0.0}. \end{itemize} \subsection{Riferimenti} \subsubsection{Normativi} \begin{itemize} - \item \textbf{Norme di progetto:} \dext{Norme di Progetto v1.0.0}; - \item \textbf{Capitolato d’appalto C6 - ThiReMa - Things Relationship Management:}\\ + \item \textbf{norme di progetto:} \dext{Norme di Progetto v1.0.0}; + \item \textbf{capitolato d’appalto C6 - ThiReMa - Things Relationship Management:}\\ \url{https://www.math.unipd.it/~tullio/IS-1/2019/Progetto/C6.pdf} \end{itemize} \subsubsection{Informativi} @@ -25,11 +25,11 @@ \section{Introduzione} \url{https://en.wikipedia.org/wiki/ISO/IEC_9126} \item \textbf{ISO/IEC 12207:}\\ \url{https://www.math.unipd.it/~tullio/IS-1/2009/Approfondimenti/ISO_12207-1995.pdf} - \item \textbf{Indice di Gulpease:}\\ + \item \textbf{indice di Gulpease:}\\ \url{https://it.wikipedia.org/wiki/Indice_Gulpease} - \item \textbf{Slide del corso di Ingegneria del Software, qualità del software:}\\ + \item \textbf{slide del corso di Ingegneria del Software - qualità del software:}\\ \url{https://www.math.unipd.it/~tullio/IS-1/2019/Dispense/L12.pdf} - \item \textbf{Slide del corso di Ingegneria del Software, qualità di processo:}\\ + \item \textbf{slide del corso di Ingegneria del Software - qualità di processo:}\\ \url{https://www.math.unipd.it/~tullio/IS-1/2019/Dispense/L13.pdf} \end{itemize} diff --git a/esterni/piano_qualifica/res/sections/Sez2-QualitaDiProdotto/Comprensione.tex b/esterni/piano_qualifica/res/sections/Sez2-QualitaDiProdotto/Comprensione.tex index d4eee2c..5e20d39 100644 --- a/esterni/piano_qualifica/res/sections/Sez2-QualitaDiProdotto/Comprensione.tex +++ b/esterni/piano_qualifica/res/sections/Sez2-QualitaDiProdotto/Comprensione.tex @@ -1,5 +1,5 @@ \subsubsection{QC-1 Comprensione} -Tutti i documenti devono essere leggibili e comprensibili, queste qualitá derivano dalla correttezza lessicografica, grammaticale, e semantica. +Tutti i documenti devono essere leggibili e comprensibili, queste qualità derivano dalla correttezza lessicografica, grammaticale, e semantica. \paragraph{Obiettivi} \begin{itemize} \item \textbf{leggibilità:} per garantire la leggibilità dei documenti si è deciso di utilizzare l'\glock{indice di Gulpease} come indicatore per questa caratteristica; diff --git a/esterni/piano_qualifica/res/sections/Sez2-QualitaDiProdotto/QualitaDiProdotto.tex b/esterni/piano_qualifica/res/sections/Sez2-QualitaDiProdotto/QualitaDiProdotto.tex index 886e122..e79347d 100644 --- a/esterni/piano_qualifica/res/sections/Sez2-QualitaDiProdotto/QualitaDiProdotto.tex +++ b/esterni/piano_qualifica/res/sections/Sez2-QualitaDiProdotto/QualitaDiProdotto.tex @@ -1,10 +1,10 @@ \section{Qualità di prodotto} - Per garantire e valutare la qualità del prodotto il gruppo ha deciso di fare riferimento allo standard ISO/IEC 9126, il quale definisce i parametri per produrre un prodotto di buona qualità, questi parametri quantificano il grado di raggiungimento di tale caratteristica. Oltre alle qualità presenti nello standard sopra citato il gruppo ha deciso di utilizare altri parametri per quantificare la qualità della documentazione fornita con il prodotto software. Di seguito sono riportate le qualità che il gruppo ha ritenuto appropriate per quanto riguarda lo stato attuale del progetto. -% \subsection{Qualità del software} -% \input{res/sections/Sez2-QualitaDiProdotto/Funzionabilita} -% \input{res/sections/Sez2-QualitaDiProdotto/Affidabilita} -% \input{res/sections/Sez2-QualitaDiProdotto/Efficienza} -% \input{res/sections/Sez2-QualitaDiProdotto/Usabilita} -% \input{res/sections/Sez2-QualitaDiProdotto/Manutenibilita} + Per garantire e valutare la qualità del prodotto il gruppo ha deciso di fare riferimento allo standard ISO/IEC 9126, il quale definisce i parametri per produrre un prodotto di buona qualità, questi parametri quantificano il grado di raggiungimento di tale caratteristica. Oltre alle qualità presenti nello standard sopra citato il gruppo ha deciso di utilizzare altri parametri per quantificare la qualità della documentazione fornita con il prodotto software. Di seguito sono riportate le qualità che il gruppo ha ritenuto appropriate per quanto riguarda lo stato attuale del progetto. + \subsection{Qualità del software} + \input{res/sections/Sez2-QualitaDiProdotto/Funzionabilita} + \input{res/sections/Sez2-QualitaDiProdotto/Affidabilita} + \input{res/sections/Sez2-QualitaDiProdotto/Efficienza} + \input{res/sections/Sez2-QualitaDiProdotto/Usabilita} + \input{res/sections/Sez2-QualitaDiProdotto/Manutenibilita} \subsection{Qualità dei documenti} \input{res/sections/Sez2-QualitaDiProdotto/Comprensione} diff --git a/esterni/piano_qualifica/res/sections/Sez3-QualitaDiProcesso/QualitaDiProcesso.tex b/esterni/piano_qualifica/res/sections/Sez3-QualitaDiProcesso/QualitaDiProcesso.tex index b8c9983..d612390 100644 --- a/esterni/piano_qualifica/res/sections/Sez3-QualitaDiProcesso/QualitaDiProcesso.tex +++ b/esterni/piano_qualifica/res/sections/Sez3-QualitaDiProcesso/QualitaDiProcesso.tex @@ -1,22 +1,22 @@ -\section{Qualità di Processo} +\section{Qualità di processo} \subsection{Introduzione} Nello svolgimento del progetto, i processi fanno uso di criteri di qualità, attraverso i quali è possibile perseguire un miglioramento continuo che porti alla più completa soddisfazione di questi criteri. In questo progetto, si è scelto di fare uso del metodo PDCA e dello standard ISO/IEC 15504 (SPICE). Attraverso \glock{PDCA} e \glock{SPICE}, è possibile garantire uno svolgimento dei processi che tendono, attraverso l'esperienza, a migliorarsi e ad assicurare al cliente l'ottenimento di un prodotto di qualità. In questa sezione si espongono i livelli di qualità accettabili e ottimali sulla base delle metriche scelte all'interno del documento \dext{Norme di Progetto v1.0.0}. -\subsection{Monitoraggio dei Processi} +\subsection{Monitoraggio dei processi} I processi monitorati con delle metriche precise di qualità sono i seguenti: \begin{itemize} - \item QP-1. Gestione delle Risorse (Piano di Progetto); - \item QP-2. Gestione dei Rischi. -% \item QP-3. Analisi dei Requisiti -% \item QP-4. Verifica del software + \item QP-1. Gestione delle risorse; + \item QP-2. Gestione dei rischi. + \item QP-3. Analisi dei Requisiti + \item QP-4. Verifica del software \end{itemize} - \subsubsection{QP-1. Gestione delle Risorse} + \subsubsection{QP-1. Gestione delle risorse} Il processo di gestione delle risorse si riserva di gestire la copertura delle risorse disponibili e delle attività schedulate all'interno del \dext{Piano di Progetto v1.0.0}. Di seguito vengono esposte le metriche utilizzate, che possono essere visionate all'interno del documento \dext{Norme di Progetto v1.0.0}. @@ -30,14 +30,14 @@ \subsection{Monitoraggio dei Processi} \item QM-PROC-5. Cost Variance (CV). \end{itemize} - \paragraph{Indici di Qualità} + \paragraph{Indici di qualità} \begin{center} \rowcolors{2}{white}{lightest-grayest} \begin{longtable}{|c|c|c|} \hline \rowcolor{lighter-grayer} - \textbf{ID Metrica} & \textbf{Valore Preferibile} & \textbf{Valore Accettabile}\\ + \textbf{ID metrica} & \textbf{Valore preferibile} & \textbf{Valore accettabile}\\ \hline \endfirsthead \hline @@ -51,11 +51,11 @@ \subsection{Monitoraggio dei Processi} \hline QM-PROC-5 (CV) & \(0\%\) & \(\ge -5\%\) \\ \hline - \caption{Indici di qualità per le metriche di Gestione delle Risorse} + \caption{Indici di qualità per le metriche di gestione delle risorse} \end{longtable} \end{center} - \subsubsection{QP-2. Gestione dei Rischi} + \subsubsection{QP-2. Gestione dei rischi} Il processo di gestione dei rischi monitora la comparsa di nuovi rischi che possono avvenire durante le fasi del progetto. Per ogni fase del progetto si eseguirà una relativa analisi retrospettiva dei rischi precedentemente segnalati e, in caso di nuovi rischi, si cercherà di risolverli nel minor tempo possibile. @@ -67,106 +67,105 @@ \subsection{Monitoraggio dei Processi} \item QM-PROC-6. Unbudgeted Risks (BCWS). \end{itemize} - \paragraph{Indici di Qualità} + \paragraph{Indici di qualità} \begin{center} \rowcolors{2}{white}{lightest-grayest} \begin{longtable}{|c|c|c|} \hline \rowcolor{lighter-grayer} - \textbf{ID Metrica} & \textbf{Valore Preferibile} & \textbf{Valore Accettabile}\\ + \textbf{ID metrica} & \textbf{Valore preferibile} & \textbf{Valore accettabile}\\ \hline \endfirsthead \hline QM-PROC-6 (UR) & \(0 \text{rischi}\) & \(\le 5 \text{rischi}\) \\ \hline - \caption{Indici di qualità per le metriche di Gestione dei Rischi} + \caption{Indici di qualità per le metriche di gestione dei rischi} \end{longtable} \end{center} - - Di seguito il grafico che rappresenta i rischi non preventivati per il periodo di Analisi dei Requisiti: - + + Di seguito il grafico che rappresenta i rischi non preventivati per il periodo di analisi dei requisiti: + \begin{figure}[H] \centering \includegraphics[width=0.8\linewidth]{./res/images/rischi.png} - \caption{Grafico periodo/rischio nel periodo di Analisi dei Requisiti} - \label{fig:Grafico rischi periodo di Analisi dei Requisiti} + \caption{Grafico periodo/rischio nel periodo di analisi dei requisiti} + \label{fig:Grafico periodo/rischio nel periodo di analisi dei requisiti} \end{figure} -% \subsubsection{QP-3. Analisi dei Requisiti} -% -% Il processo di Analisi dei Requisiti vuole tenere traccia di tutti i requisiti portati a termine fino alla data corrente e dell'eventuale valore aggiunto che possono costituire i requisiti non obbligatori. -% Di seguito vengono esposte le metriche utilizzate, che possono essere visionate all'interno del documento \dext{Norme di Progetto v1.0.0}. -% -% \paragraph{Metriche utilizzate} -% -% \begin{itemize} -% \item QM-PROC-7. Satisfied Mandatory Requirements (SMR) -% \item QM-PROC-8. Satisfied Desirable Requirements (SDR) -% \item QM-PROC-9. Satisfied Optional Requirements (SOR) -% \end{itemize} -% -% -% \paragraph{Indici di Qualità} -% -% \begin{center} -% \rowcolors{2}{white}{lightest-grayest} -% \begin{longtable}{|c|c|c|} -% \hline -% \rowcolor{lighter-grayer} -% \textbf{ID Metrica} & \textbf{Valore Preferibile} & \textbf{Valore Accettabile}\\ -% \hline -% \endfirsthead -% \hline -% QM-PROC-7 (SMR) & \(\geq 100\%\) & \(\geq 100\%\) \\ -% \hline -% QM-PROC-8 (SDR) & \(\geq 50\%\) & \(\geq 15\%\) \\ -% \hline -% QM-PROC-9 (SOR) & \(\geq 15\%\) & \(\geq 0\%\) \\ -% \hline -% \caption{Indici di qualità per le metriche di Analisi dei Requisiti} -% \end{longtable} -% \end{center} -% -% \subsubsection{QP-4. Verifica del Software} -% -% Il processo di Verifica del Software pone come obiettivo il controllo dello sviluppo software a livello di codifica. -% Di seguito vengono esposte le metriche utilizzate, che possono essere visionate all'interno del documento \dext{Norme di Progetto v1.0.0}. -% -% \paragraph{Metriche utilizzate} -% -% \begin{itemize} -% %NDR: da usare dopo -% %\item QM-PROC-10. Branch Coverage (BCOV) -% %\item QM-PROC-11. Condition Coverage (COCOV) -% %\item QM-PROC-12. Statement Coverage (SCOV) -% \item QM-TEST-1. Passed Test Cases Percentage (PTCP) -% \item QM-TEST-2. Failed Test Cases Percentage (FTCP) -% \item QM-TEST-3. Bug-Fixing Percentage (BFP) -% \item QM-TEST-4. Test Effectiveness (TE) -% \end{itemize} -% -% -% \paragraph{Indici di Qualità} -% -% \begin{center} -% \rowcolors{2}{white}{lightest-grayest} -% \begin{longtable}{|c|c|c|} -% \hline -% \rowcolor{lighter-grayer} -% \textbf{ID Metrica} & \textbf{Valore Preferibile} & \textbf{Valore Accettabile}\\ -% \hline -% \endfirsthead -% \hline -% %QM-PROC-10 (BCOV) & \(\geq 75\%\) & \(\geq 50\%\) \\ \hline -% %QM-PROC-11 (COCOV) & \(\geq 50\%\) & \(\geq 25\%\) \\ \hline -% %QM-PROC-12 (SCOV) & \(\geq 75\%\) & \(\geq 50\%\) \\ \hline -% QM-TEST-1 (PTCP) & \(\geq 100\%\) & \(\geq 100\%\) \\ \hline -% QM-TEST-2 (FTCP) & \(\geq 0\%\) & \(\geq 0\%\) \\ \hline -% QM-TEST-3 (BFP) & \(\geq 100\%\) & \(\geq 100\%\) \\ \hline -% QM-TEST-4 (TE) & \(\geq 75\%\) & \(\geq 50\%\) \\ \hline -% \hline -% \caption{Indici di qualità per le metriche di Verifica del Software} -% \end{longtable} -% \end{center} -% + \subsubsection{QP-3. Analisi dei Requisiti} + + Il processo di Analisi dei Requisiti vuole tenere traccia di tutti i requisiti portati a termine fino alla data corrente e dell'eventuale valore aggiunto che possono costituire i requisiti non obbligatori. + Di seguito vengono esposte le metriche utilizzate, che possono essere visionate all'interno del documento \dext{Norme di Progetto v1.0.0}. + + \paragraph{Metriche utilizzate} + + \begin{itemize} + \item QM-PROC-7. Satisfied Mandatory Requirements (SMR) + \item QM-PROC-8. Satisfied Desirable Requirements (SDR) + \item QM-PROC-9. Satisfied Optional Requirements (SOR) + \end{itemize} + + + \paragraph{Indici di Qualità} + + \begin{center} + \rowcolors{2}{white}{lightest-grayest} + \begin{longtable}{|c|c|c|} + \hline + \rowcolor{lighter-grayer} + \textbf{ID Metrica} & \textbf{Valore Preferibile} & \textbf{Valore Accettabile}\\ + \hline + \endfirsthead + \hline + QM-PROC-7 (SMR) & \(\geq 100\%\) & \(\geq 100\%\) \\ + \hline + QM-PROC-8 (SDR) & \(\geq 50\%\) & \(\geq 15\%\) \\ + \hline + QM-PROC-9 (SOR) & \(\geq 15\%\) & \(\geq 0\%\) \\ + \hline + \caption{Indici di qualità per le metriche di Analisi dei Requisiti} + \end{longtable} + \end{center} + + \subsubsection{QP-4. Verifica del Software} + + Il processo di Verifica del Software pone come obiettivo il controllo dello sviluppo software a livello di codifica. + Di seguito vengono esposte le metriche utilizzate, che possono essere visionate all'interno del documento \dext{Norme di Progetto v1.0.0}. + + \paragraph{Metriche utilizzate} + + \begin{itemize} + %NDR: da usare dopo + \item QM-PROC-10. Branch Coverage (BCOV) + \item QM-PROC-11. Condition Coverage (COCOV) + \item QM-PROC-12. Statement Coverage (SCOV) + \item QM-TEST-1. Passed Test Cases Percentage (PTCP) + \item QM-TEST-2. Failed Test Cases Percentage (FTCP) + \item QM-TEST-3. Bug-Fixing Percentage (BFP) + \item QM-TEST-4. Test Effectiveness (TE) + \end{itemize} + + + \paragraph{Indici di Qualità} + + \begin{center} + \rowcolors{2}{white}{lightest-grayest} + \begin{longtable}{|c|c|c|} + \hline + \rowcolor{lighter-grayer} + \textbf{ID Metrica} & \textbf{Valore Preferibile} & \textbf{Valore Accettabile}\\ + \hline + \endfirsthead + \hline + QM-PROC-10 (BCOV) & \(\geq 75\%\) & \(\geq 50\%\) \\ \hline + QM-PROC-11 (COCOV) & \(\geq 50\%\) & \(\geq 25\%\) \\ \hline + QM-PROC-12 (SCOV) & \(\geq 75\%\) & \(\geq 50\%\) \\ \hline + QM-TEST-1 (PTCP) & \(\geq 100\%\) & \(\geq 100\%\) \\ \hline + QM-TEST-2 (FTCP) & \(\geq 0\%\) & \(\geq 0\%\) \\ \hline + QM-TEST-3 (BFP) & \(\geq 100\%\) & \(\geq 100\%\) \\ \hline + QM-TEST-4 (TE) & \(\geq 75\%\) & \(\geq 50\%\) \\ \hline + \hline + \caption{Indici di qualità per le metriche di Verifica del Software} + \end{longtable} + \end{center} diff --git a/esterni/piano_qualifica/res/sections/Sez4-Test/Test.tex b/esterni/piano_qualifica/res/sections/Sez4-Test/Test.tex index 1a7a3a5..34e1001 100644 --- a/esterni/piano_qualifica/res/sections/Sez4-Test/Test.tex +++ b/esterni/piano_qualifica/res/sections/Sez4-Test/Test.tex @@ -1,26 +1,26 @@ \section{Test} - Per la classificazione dei test si fa riferimento alle sezioni Verifica e Validazione delle \dext{Norme di Progetto v1.0.0}. + Per la classificazione dei test si fa riferimento alle sezioni verifica e validazione delle \dext{Norme di Progetto v1.0.0}. - \subsection{Tipologie di test:} + \subsection{Tipologie di test} I test saranno di quattro tipologie differenti: \begin{itemize} - \item \textbf{Test di Accettazione [TA]} - \item \textbf{Test di Sistema [TS]} - \item \textbf{Test di Integrazione [TI]} - \item \textbf{Test di Unità [TU]} + \item \textbf{test di accettazione [TA]} + \item \textbf{test di sistema [TS]} + \item \textbf{test di integrazione [TI]} + \item \textbf{test di unità [TU]} \end{itemize} - \subsection{Test di Accettazione} + \subsection{Test di accettazione} I test di accettazione sono utilizzati per dimostrare che il prodotto sviluppato soddisfa tutti i requisiti individuati dal capitolato e concordati con il proponente: è alla presenza di questi, infatti, che tali test vengono eseguiti, in sede di collaudo finale del prodotto. - \subsection{Test di Sistema} + \subsection{Test di sistema} \begin{center} - Riepilogo Test di Sistema - \rowcolors{2}{white}{lightest-grayest} + Riepilogo dei test di sistema + \rowcolors{2}{lightest-grayest}{white} \begin{longtable}{|c|p{10cm}|c|} \hline \rowcolor{lighter-grayer} @@ -221,18 +221,16 @@ \section{Test} \hline TSA-F-70 & Si verifichi che i dispositivi comunichino con i \glock{gateway} i dati da inviare. & NI \\ \hline - %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Test di sistema per i requisiti prestazionali %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% - TSA-P-1 & Si verifichi che la web application sia compatibile con il browser Firefox dalla versione 69.0. & NI \\ %niiiice - \hline - TSA-P-2 & Si verifichi che la web application sia compatibile con il browser Chrome dalla versione 75.0. & NI \\ + TSA-F-71 & Si verifichi che la web app permetta di accedere a tutte le sue funzionalità da browser nelle modalità desktop e tablet. & NI \\ \hline - TSA-P-3 & Si verifichi che la web application sia compatibile con il browser Safari dalla versione 13.0. & NI \\ + TSA-F-71.1 & Si verifichi che la web app permetta di visualizzare grafici e dati da browser nella modalità mobile. & NI \\ \hline - TSB-P-4 & Si verifichi che la web application sia compatibile con il browser Edge dalla versione 42.0. & NI \\ + TSB-F-71.2 & Si verifichi che la web app permetta di compilare moduli interni da browser nella modalità mobile. & NI \\ \hline - TSA-P-5 & Si verifichi che i tempi di risposta della web app per disegnare grafici siano inferiori ai 7.5 secondi. & NI \\ + %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Test di sistema per i requisiti prestazionali %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + TSA-P-1 & Si verifichi che i tempi di risposta della web app per disegnare grafici siano inferiori ai 7.5 secondi. & NI \\ \hline - TSA-P-6 & Si verifichi che il sistema riesca a gestire un carico di almeno 30 utenti connessi contemporaneamente alla web app. & NI \\ + TSA-P-2 & Si verifichi che il sistema riesca a gestire un carico di almeno 30 utenti connessi contemporaneamente alla web app. & NI \\ \hline %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Test di sistema per i requisiti di qualità %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% TSB-Q-3.1 & Si verifichi che la documentazione delle API sia stata scritta utilizzata per la denominazione della funzioni messe a disposizione. & NI \\ @@ -243,34 +241,34 @@ \section{Test} \hline TSB-Q-9 & Si verifichi che la web app superi la validazione W3C & NI \\ \hline - TSB-Q-10 & Si verifichi che la web app sia stata sviluppata utilizzando il framework \glock{Bootstrap}. & NI \\ - \hline %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Test per i requisiti di vincolo %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% - TSA-V-1 & Si verifichi che la web app permetta l'accesso a tutte le sue funzionalità nella modalità desktop e tablet. & NI \\ + TSA-V-1 & Si verifichi che le istanze del sistema siano gestite tramite \glock{Docker}. & NI \\ \hline - TSA-V-1.1 & Si verifichi che la web app permetta la visualizzazione di grafici e dati da browser in modalità mobile. & NI \\ + TSA-V-2 & Si verifichi che la ricezione degli avvisi avvenga tramite un bot Telegram. & NI \\ + \hline + TSA-V-3 & Si verifichi che il sistema faccia uso dell'ecosistema \glock{Kafka}. & NI \\ \hline - TSB-V-1.2 & Si verifichi che la web app permetta la compilazione di moduli da browser in modalità mobile. & NI \\ + TSA-V-4 & Si verifichi che il sistema faccia uso di un time-series database per la memorizzazione dei dati dei sensori. & NI \\ \hline - TSA-V-2 & Si verifichi che le istanze del sistema siano gestite tramite \glock{Docker} & NI \\ + TSA-V-5 & Si verifichi che il sistema faccia uso di un protocollo per comunicare con il gateway. & NI \\ \hline - TSA-V-3 & Si verifichi che la ricezione degli avvisi avvenga tramite un bot Telegram. & NI \\ - \hline - TSA-V-4 & Si verifichi che il sistema faccia uso dell'ecosistema \glock{Kafka}. & NI \\ + TSA-V-6 & Si verifichi che il sistema faccia uso di API per la comunicazione con le applicazioni. & NI \\ + \hline + TSA-V-7 & Si verifichi che la web app sia compatibile con il browser \glock{Firefox} dalla versione 69.0. & NI \\ \hline - TSA-V-5 & Si verifichi che il sistema faccia uso di un time-series database per la memorizzazione dei dati dei sensori. & NI \\ + TSA-V-8 & Si verifichi che la web app sia compatibile con il browser \glock{Chrome} dalla versione 75.0. & NI \\ \hline - TSA-V-6 & Si verifichi che il sistema faccia uso di un protocollo per comunicare con il gateway. & NI \\ + TSA-V-9 & Si verifichi che la web app sia compatibile con il browser \glock{Safari} dalla versione 13.0. & NI \\ \hline - TSA-V-7 & Si verifichi che il sistema faccia uso di API per la comunicazione con le applicazioni. & NI \\ + TSB-V-10 & Si verifichi che la web app sia compatibile con il browser \glock{Edge} dalla versione 42.0. & NI \\ \hline - TSA-V-8 & Si verifichi che il sistema mostri una correlazioni tra almeno due dati. & NI \\ + TSA-V-11 & Si verifichi che la web app sia stata sviluppata utilizzando il framework \glock{Bootstrap} & NI \\ \hline - TSA-V-9 & Si verifichi che il sistema permetta di visualizzare dati inviati da un dispositivo. & NI \\ + TSA-V-12 & Si verifichi che tutta la documentazione relativa al software sia stata scritta in lingua italiana. & NI \\ \hline - TSA-V-10 & Si verifichi che il sistema permetta di inviare input ad un dispositivo. & NI \\ + TSA-V-12.1 & Si verifichi che il software sia accompagnato da un manuale amministratore, contenente le informazioni utili per la distribuzione e l'installazione del prodotto. & NI \\ \hline - TSA-V-11 & Si verifichi che il sistema permetta di censire un dispositivo. & NI \\ + TSA-V-12.2 & Si verifichi che il software sia accompagnato da un manuale utente, contenente le informazioni utili per l'utilizzo del prodotto da parte degli utenti e dei moderatori ente. & NI \\ \hline \caption{Tabella contenente un riepilogo dei test di sistema} @@ -278,8 +276,8 @@ \section{Test} \end{center} - \subsection{Test di Integrazione} - Le specifiche di questi test verranno scritte successivamente rispettando il \glock{modello a V}. + \subsection{Test di integrazione} + Le specifiche di questi test verranno scritte successivamente, rispettando il \glock{modello a V}. - \subsection{Test di Unità} - Le specifiche di questi test verranno scritte successivamente rispettando il \glock{modello a V}. + \subsection{Test di unità} + Le specifiche di questi test verranno scritte successivamente, rispettando il \glock{modello a V}. diff --git a/esterni/piano_qualifica/res/sections/Sez6-ValutazioniMiglioramento/Valutazione.tex b/esterni/piano_qualifica/res/sections/Sez6-ValutazioniMiglioramento/Valutazione.tex index f1053a8..877b99a 100644 --- a/esterni/piano_qualifica/res/sections/Sez6-ValutazioniMiglioramento/Valutazione.tex +++ b/esterni/piano_qualifica/res/sections/Sez6-ValutazioniMiglioramento/Valutazione.tex @@ -51,7 +51,7 @@ \section{Valutazioni di miglioramento} & Essendo il capitolato chiaramente privo di approfondimenti sui bisogni del committente, è risultato difficile ottenere da essi i requisiti di progetto. & -Gli analisti hanno deciso di svolgere quest'attività scambiandosi continuamente i propri risultati e chiedendo chiarimenti agli altri quando necessario. Inoltre, è stato fissato un incontro col committente di modo che sia possibile avere un feedback diretto sulla valenza e coerenza dei requisiti ottenuti, data l'inesperienza dei membri sull'attività di \textit{analisi dei requisiti}. \\ +Gli analisti hanno deciso di svolgere quest'attività scambiandosi continuamente i propri risultati e chiedendo chiarimenti agli altri quando necessario. Inoltre, è stato fissato un incontro col committente di modo che sia possibile avere un feedback diretto sulla valenza e coerenza dei requisiti ottenuti, data l'inesperienza dei membri sull'attività di analisi dei requisiti. \\ \hline \hline @@ -101,7 +101,7 @@ \section{Valutazioni di miglioramento} & Questo strumento di scrittura è stato una novità per quasi tutti i membri del gruppo. All'inizio, in molti avevano errori di compilazione nei propri file, per cui non riuscivano a produrre opportuni file pdf. & -Dopo il primo mese e mezzo dalla formazione del gruppo, un membro particolarmente esperto di \LaTeX ha creato un template da far utilizzare a tutti i membri per la produzione della documentazione, riducendo ai minimi termini il numero di comandi da imparare per utilizzare questo software efficacemente.\\ +Dopo il primo mese e mezzo dalla formazione del gruppo, un membro particolarmente esperto di \LaTeX ha creato un template da far utilizzare a tutti i membri per la produzione della documentazione, riducendo ai minimi termini il numero di comandi da imparare per utilizzare questo software efficacemente.\\ \hline \caption{Tabella contenente le valutazioni sugli strumenti} \end{longtable} diff --git a/interni/norme_progetto/main.tex b/interni/norme_progetto/main.tex index 8945146..e10188b 100644 --- a/interni/norme_progetto/main.tex +++ b/interni/norme_progetto/main.tex @@ -9,6 +9,7 @@ % Configurazione primaria del documento + % -------------- \newcommand{\docNome}{ NORME DI PROGETTO } @@ -16,7 +17,7 @@ \newcommand{\docVersione}{1.0.0\docBaseline} \newcommand{\docNomeProgetto}{ ThiReMa Project} \newcommand{\docStatus}{Approvato} -\newcommand{\docUso}{interno} +\newcommand{\docUso}{Interno} \newcommand{\docDescrizione}{ Il documento contiene tutta la normativa di progetto relativa al \textit{way of working} del gruppo, le attività e le convenzioni da rispettare per lo sviluppo del prodotto. } diff --git a/interni/norme_progetto/res/images/submodules.png b/interni/norme_progetto/res/images/submodules.png new file mode 100644 index 0000000..3b23a8e Binary files /dev/null and b/interni/norme_progetto/res/images/submodules.png differ diff --git a/interni/norme_progetto/res/registro.tex b/interni/norme_progetto/res/registro.tex index 75acf67..0a1877d 100644 --- a/interni/norme_progetto/res/registro.tex +++ b/interni/norme_progetto/res/registro.tex @@ -12,14 +12,19 @@ \section*{Registro delle modifiche} % ----- Modificare da qui ----- + 1.0.1+b0.4 & Aggiornamento sezione \S3.2 & 2020-02-17 & Giuseppe Vito Bitetti & Amministratore \\ \hline 1.0.0+b0.4 & Approvazione per il rilascio esterno & 2019-01-15 & Alessandro Tommasin & Responsabile \\ \hline - 0.2.0+b0.3 & Approvazione documento & 2020-01-01 & Lorenzo Dei Negri & Responsabile \\ + 0.3.0+b0.3 & Aggiornamento sezione \S3.5 e \S3.7 & 2019-12-28 & Nicolò Frison & Amministratore \\ \hline - 0.1.5+b0.2 & Stesura e verifica sezione \S3.9 & 2019-12-22 & Giuseppe Vito Bitetti e Alessandro Tommasin & Amministratore e verificatore \\ + 0.2.1+b0.2 & Verifica sezione \S3.4, \S3.5, \S3.6, \S3.7 e \S3.9 & 2020-12-27 & Alessandro Tommasin e Mariano Sciacco & Verificatore\\ + \hline + 0.2.0+b0.2 & Approvazione documento & 2020-12-24 & Lorenzo Dei Negri & Responsabile \\ \hline - 0.1.4+b0.2 & Stesura e verifica sezione \S3.4, \S3.5, \S3.6 e \S3.7 & 2019-12-18 & Nicolò Frison e Giovanni Vidotto & Amministratore e verificatore \\ + 0.1.5+b0.1 & Stesura e verifica sezione \S3.9 & 2019-12-22 & Giuseppe Vito Bitetti e Alessandro Tommasin & Amministratore e verificatore \\ + \hline + 0.1.4+b0.1 & Stesura e verifica sezione \S3.4, \S3.5, \S3.6 e \S3.7 & 2019-12-18 & Nicolò Frison e Giovanni Vidotto & Amministratore e verificatore \\ \hline 0.1.3+b0.1 & Stesura e verifica sezione \S4.2 & 2019-12-14 & Giuseppe Vito Bitetti e Nicolò Frison & Amministratore e verificatore \\ \hline diff --git a/interni/norme_progetto/res/sections/Sez1-Introduzione/introduzione.tex b/interni/norme_progetto/res/sections/Sez1-Introduzione/introduzione.tex index 2dc7f67..1fa131c 100644 --- a/interni/norme_progetto/res/sections/Sez1-Introduzione/introduzione.tex +++ b/interni/norme_progetto/res/sections/Sez1-Introduzione/introduzione.tex @@ -3,27 +3,27 @@ \section{Introduzione} Il documento ha lo scopo di definire le regole su cui si basa il \textit{way of working} del gruppo Red Round Robin per lo svolgimento del progetto. Le attività che possono essere trovate all'interno di questo documento sono state prese da processi appartenenti allo standard ISO/IEC 12207:1995. Tutti i membri del gruppo sono quindi tenuti a prendere visione di questo documento così da garantire uniformità e coesione all'interno del progetto. \subsection{Scopo del prodotto} Il capitolato C6 si pone l'obiettivo di creare una web-application che consenta l'analisi di grosse moli di dati ricevuti da sensori di natura eterogenea. Tale applicazione mette a disposizione un'interfaccia che permette di visualizzare alcuni dati di interesse od eventuali correlazioni tra i dati stessi. Infine, per ogni tipologia di dato è possibile assegnare il monitoraggio di ogni tipologia di dato ad un particolare ente. - \subsection{Glossario e Documenti esterni} + \subsection{Glossario e documenti esterni} Per evitare possibili ambiguità relative alle terminologie (che andranno indicate in \textsc{maiuscoletto}) utilizzate nei vari documenti, saranno adottati due simboli: \begin{itemize} - \item Una \textit{D} a pedice per indicare il nome di un particolare documento. - \item Una \textit{G} a pedice per indicare un termine che sarà + \item una \textit{D} a pedice per indicare il nome di un particolare documento. + \item una \textit{G} a pedice per indicare un termine che sarà presente nel \dext{Glossario v1.0.0}. \end{itemize} \subsection{Riferimenti} \subsubsection{Riferimenti normativi} \begin{itemize} - \item \textbf{Capitolato d'appalto C6 - ThiReMa: } \\ + \item \textbf{capitolato d'appalto C6 - ThiReMa: } \\ \url{https://www.math.unipd.it/~tullio/IS-1/2019/Progetto/C6.pdf} \end{itemize} \subsubsection{Riferimenti informativi} \begin{itemize} \item \textbf{Standard ISO/IEC 12207:1995: } \\ \url{https://www.math.unipd.it/~tullio/IS-1/2009/Approfondimenti/ISO_12207-1995.pdf} - \item \textbf{Documentazione git: }\url{https://git-scm.com/docs} - \item \textbf{Documentazione GitHub: }\url{https://help.github.com/en/github} - \item \textbf{Documentazione LaTeX: }\url{https://www.latex-project.org/help/documentation/} + \item \textbf{documentazione git: }\url{https://git-scm.com/docs} + \item \textbf{documentazione GitHub: }\url{https://help.github.com/en/github} + \item \textbf{documentazione LaTeX: }\url{https://www.latex-project.org/help/documentation/} \item \textbf{Cost Variance: } \url{http://acqnotes.com/acqnote/tasks/cost-variances} \item \textbf{Schedule Variance: } \url{http://acqnotes.com/acqnote/tasks/schedule-variances} \end{itemize} diff --git a/interni/norme_progetto/res/sections/Sez2-ProcessiPrimari/Fornitura.tex b/interni/norme_progetto/res/sections/Sez2-ProcessiPrimari/Fornitura.tex index 9e802d1..ae00f80 100644 --- a/interni/norme_progetto/res/sections/Sez2-ProcessiPrimari/Fornitura.tex +++ b/interni/norme_progetto/res/sections/Sez2-ProcessiPrimari/Fornitura.tex @@ -1,4 +1,4 @@ -\section{Processi Primari} +\section{Processi primari} \subsection{Fornitura} @@ -10,16 +10,43 @@ \subsection{Fornitura} \item redigere un documento che descriva nel dettaglio come il fornitore (il gruppo) intenda organizzare il lavoro che porterà alla realizzazione del prodotto oggetto del capitolato scelto; \item stabilire se il materiale prodotto dai membri del fornitore per soddisfare i compiti a loro assegnati faccia quanto atteso e sia di qualità. \end{itemize} -Le tre attività elencate sopra sono formalizzate rispettivamente nello \textit{Studio di Fattibilità}, nel \textit{Piano di Progetto} e nel \textit{Piano di Qualifica}. \subsubsection{Aspettative} -Il gruppo si prefigge l'obiettivo di confrontarsi frequentemente col proponente, per capire se il lavoro svolto è in linea con quanto richiesto dal capitolato scelto, e chiarire eventuali requisiti ove necessario. + Il gruppo si prefigge l'obiettivo di confrontarsi frequentemente col proponente, per capire se il lavoro svolto è in linea con quanto richiesto dal capitolato scelto, e chiarire eventuali requisiti ove necessario. \subsubsection{Descrizione} - Di seguito verranno definiti sinteticamente gli argomenti principali di cui trattano i documenti citati in precedenza. Per approfondire, si rimanda alle omonime sezioni. + Di seguito verranno definite sinteticamente le attività principali di cui è composto il processo di fornitura. \subsubsection{Attività} - - \paragraph{Studio di fattibilità} - Nello \textit{Studio di Fattibilità}, per ogni capitolato proposto, si fornisce una breve descrizione del prodotto desiderato e delle sue caratteristiche, oltre a citare quali tecnologie sono richieste per realizzarlo. Infine, gli analisti del gruppo espongono gli aspetti positivi, quelli negativi e i fattori di rischio riscontrati. A fronte di questa analisi, nella sezione delle \textit{Conclusioni} si motiva perchè il capitolato è stato rifiutato o accettato dal gruppo. - \paragraph{Piano di progetto} - In questo documento, il responsabile di progetto e gli amministratori sono tenuti a fare un'analisi dei rischi completa, partendo da quelli individuati dagli analisti nello \textit{Studio di Fattibiltà}, approfondendoli e aggiungendone altri qualora ve ne fossero. Inoltre, è indispensabile decidere quale \glock{Modello di Sviluppo} tra quelli standardizzati prendere come riferimento per svolgere tutti i compiti che porteranno alla realizzazione del prodotto finito. Una volta scelto il \glock{Modello di Sviluppo}, i redattori procedono alla definizione, nella sezione \textit{Pianificazione}, di quali compiti eseguire nelle diverse fasi del progetto e definiscono delle deadline entro le quali vanno portati a termine. Infine, viene stimato il costo complessivo per la realizzazione del progetto in un preventivo a finire da proporre al committente, oltre a dei consuntivi di periodo che determinano se i costi del progetto effettivi rilevati durante la realizzazione del prodotto sono in linea con le stime definite nel preventivo. - \paragraph{Piano di qualifica} - I verificatori redigono questo documento allo scopo di garantire \textit{qualità al prodotto}, sia lato cliente che lato fornitore, e \textit{qualità di processo}, in modo da essere certi che i membri lavorino, durante la realizzazione delle varie attività, siano esse di supporto alla realizzazione del prodotto o prodotto esse stesse, secondo le metriche scelte. In particolare, vengono definiti i \textit{test} ai quali viene sottoposto il prodotto per assicurarsi che soddisfi i requisiti individuati dagli analisti, e si sottolineano i punti in cui è possibile apportare miglioramenti ai processi di supporto e al processo di verifica stesso. Dopodichè, per ogni attività significativa sottoposta a verifica, viene redatto un resoconto che mostra i livelli di qualità raggiunti relativamente alle metriche adottate. \ No newline at end of file + + \paragraph{Inizializzazione} + Gli analisti del gruppo Red Round Robin devono effettuare una valutazione dei capitolati proposti tramite uno studio di fattibilità. + Il documento dovrà contenere, per ogni capitolato, una breve descrizione del capitolato stesso e delle tecnologie proposte, i suoi aspetti positivi e quelli negativi. Dovrà essere presente infine una conclusione che riassume la motivazione per la quale si è scelto un capitolato rispetto ad un altro. + In base a questo documento dovrà essere scelto uno dei capitolati proposti. + \paragraph{Preparazione della risposta} + Il gruppo dovrà preparare una lettera di presentazione in cui si candida come fornitore del prodotto implicato dal capitolato scelto. + \paragraph{Pianificazione} + Il gruppo deve stipulare un piano per la gestione del progetto e della qualità; più nello specifico dovrà realizzare: + \begin{itemize} + \item un piano di progetto, contenente: + \begin{itemize} + \item analisi e riscontro dei rischi; + \item il modello di sviluppo scelto; + \item una pianificazione coesa con il modello di sviluppo; + \item preventivo e un consuntivo di periodo. + \end{itemize} + \item un piano di qualifica, contenente: + \begin{itemize} + \item le qualità di processo; + \item le qualità di prodotto; + \item le specifiche dei test; + \item il resoconto delle attività di verifica; + \item le valutazioni di miglioramento. + \end{itemize} + \end{itemize} + + \paragraph{Esecuzione e controllo} + Il gruppo Red Round Robin dovrà seguire quando descritto nei piani elencati in precedenza monitorando i costi, le problematiche riscontrate, l'avanzamento nello sviluppo e la qualità. + \paragraph{Revisione e valutazione} + Il gruppo Red Round Robin dovrà coordinare le revisioni delle attività svolte e le comunicazioni con il proponente ed il committente. Il gruppo dovrà inoltre eseguire la verifica e la validazione del prodotto garantendo che il prodotto sia conforme con quanto pattuito con il proponente ed il committente. + \paragraph{Rilascio e completamento} + Il gruppo dovrà rilasciare il prodotto in maniera conforme a quanto pattuito con il proponente ed il committente. + \subsubsection{Strumenti} + Per il processo di fornitura non sono stati individuati particolari strumenti da impiegare. \ No newline at end of file diff --git a/interni/norme_progetto/res/sections/Sez2-ProcessiPrimari/Sviluppo.tex b/interni/norme_progetto/res/sections/Sez2-ProcessiPrimari/Sviluppo.tex index 5ed0ffc..a016b8d 100644 --- a/interni/norme_progetto/res/sections/Sez2-ProcessiPrimari/Sviluppo.tex +++ b/interni/norme_progetto/res/sections/Sez2-ProcessiPrimari/Sviluppo.tex @@ -4,29 +4,29 @@ \subsection{Sviluppo} \subsubsection{Aspettative} Per una corretta implementazione di questo processo è necessario fissare: \begin{itemize} - \item Obbiettivi di sviluppo; - \item Vincoli tecnologici e di design. + \item obiettivi di sviluppo; + \item vincoli tecnologici e di design. \end{itemize} Il prodotto finale deve rispettare i requisiti e le aspettative del proponente, superando i test definiti dalle norme di qualità. \subsubsection{Descrizione} Il processo di sviluppo, secondo lo standard ISO/IEC 12207:1995, si articola nelle seguenti attività: \begin{itemize} - \item Analisi dei Requisiti; - \item Progettazione; - \item Codifica. + \item analisi dei requisiti; + \item progettazione; + \item codifica. \end{itemize} \subsubsection{Attività} Di seguito verranno analizzate dettagliatamente le attività menzionate nella sezione precedente. \paragraph{Analisi dei requisiti} \subparagraph{Scopo} - Gli Analisti si occupano di stilare il documento di \dext{Analisi dei Requisiti v1.0.0}, il cui scopo è definire ed elencare tutti i requisiti del capitolato. Il documento finale conterrà: + Gli analisti si occupano di stilare il documento \dext{Analisi dei Requisiti v1.0.0}, il cui scopo è definire ed elencare tutti i requisiti del capitolato. Il documento finale conterrà: \begin{itemize} - \item Descrizione generale del prodotto; - \item Argomentazioni precise ed affidabili per i Progettisti; - \item Casi d'uso rappresentati tramite diagrammi UML; - \item Funzionalità e requisiti concordi con le richieste del cliente; - \item Tracciamento dei requisiti individuati. + \item descrizione generale del prodotto; + \item argomentazioni precise ed affidabili per i progettisti; + \item casi d'uso rappresentati tramite diagrammi UML; + \item funzionalità e requisiti concordi con le richieste del cliente; + \item tracciamento dei requisiti individuati. \end{itemize} \subparagraph{Aspettative} Creazione del documento formale contente tutti i requisiti richiesti dal proponente per la realizzazione del capitolato. @@ -37,7 +37,7 @@ \subsection{Sviluppo} \end{center} Dove: \begin{itemize} - \item \textbf{R:} Requisito + \item \textbf{R:} requisito \item \textbf{Priorità:} ogni requisito assumerà uno dei seguenti valori: \begin{itemize} \item \textbf{A:} obbligatorio, strettamente necessario; @@ -57,43 +57,43 @@ \subsection{Sviluppo} \end{center} \end{itemize} \subparagraph{Classificazione dei casi d'uso} - Gli Analisti, dopo la stesura dei requisiti, hanno anche il compito di identificare ed elencare i casi d’uso. Ognuno di essi è identificato, in maniera univoca, secondo il seguente schema identificativo: + Gli analisti, dopo la stesura dei requisiti, hanno anche il compito di identificare ed elencare i casi d’uso. Ognuno di essi è identificato, in maniera univoca, secondo il seguente schema identificativo: \begin{center} \textbf{UC[codiceCaso].[codiceSottoCaso].[codiceSottoSottoCaso]} \end{center} Ogni caso d'uso oltre al codice di identificazione deve contenere, integralmente o parzialmente, i seguenti campi: \begin{itemize} - \item \textbf{Diagrammi UML:} diagrammi realizzati usando la versione 2.0 del linguaggio; - \item \textbf{Attori primari:} attori principali del caso d’uso; - \item \textbf{Attori secondari:} attori secondari del caso d’uso; - \item \textbf{Descrizione:} breve descrizione del caso d'uso; - \item \textbf{Attori secondari:} attori secondari del caso d’uso; - \item \textbf{Estensioni:} eventuali estensioni coinvolte; - \item \textbf{Inclusioni:} eventuali inclusioni coinvolte; - \item \textbf{Precondizione:} condizioni che devono essere soddisfatte perché si verifichino gli eventi del caso d’uso; - \item \textbf{Postcondizione:} condizioni che devono essere soddisfatte dopo il verificarsi degli eventi del caso d’uso; - \item \textbf{Scenario principale:} flusso degli eventi, in forma di elenco numerato, con eventuale riferimento ad ulteriori casi d’uso. + \item \textbf{diagrammi UML:} diagrammi realizzati usando la versione 2.0 del linguaggio; + \item \textbf{attori primari:} attori principali del caso d’uso; + \item \textbf{attori secondari:} attori secondari del caso d’uso; + \item \textbf{descrizione:} breve descrizione del caso d'uso; + \item \textbf{attori secondari:} attori secondari del caso d’uso; + \item \textbf{estensioni:} eventuali estensioni coinvolte; + \item \textbf{inclusioni:} eventuali inclusioni coinvolte; + \item \textbf{precondizione:} condizioni che devono essere soddisfatte perché si verifichino gli eventi del caso d’uso; + \item \textbf{postcondizione:} condizioni che devono essere soddisfatte dopo il verificarsi degli eventi del caso d’uso; + \item \textbf{scenario principale:} flusso degli eventi, in forma di elenco numerato, con eventuale riferimento ad ulteriori casi d’uso. \end{itemize} \paragraph {Progettazione} \subparagraph{Scopo} - L'attività di progettazione avviene una volta concluso il documento di Analisi dei Requisiti, in essa i progettisti hanno il compito di definire una soluzione soddisfacente del problema. + L'attività di progettazione avviene una volta concluso il documento \dext{Analisi dei Requisiti v1.0.0}, in essa i progettisti hanno il compito di definire una soluzione soddisfacente del problema. \subparagraph{Aspettative} Realizzazione dell'architettura del sistema. \subparagraph{Descrizione} Questa fase si divide nelle seguenti fasi: \begin{itemize} - \item \textbf{Tecnology baseline:} specifiche della progettazione del prodotto e delle sue componenti, insieme dei diagrammi UML dell'architettura ed i test di verifica; - \item \textbf{Product baseline:} specifica più dettagliata dell'attività di progettazione e definisce i test necessari per la verifica. - \item \textbf{Diagrammi UML:} diagrammi utilizzati per rendere più chiare le soluzioni progettuali utilizzate; si suddividono in: + \item \textbf{tecnology baseline:} specifiche della progettazione del prodotto e delle sue componenti, insieme dei diagrammi UML dell'architettura ed i test di verifica; + \item \textbf{product baseline:} specifica più dettagliata dell'attività di progettazione e definisce i test necessari per la verifica; + \item \textbf{diagrammi UML:} diagrammi utilizzati per rendere più chiare le soluzioni progettuali utilizzate; si suddividono in: \begin{itemize} - \item \textbf{Diagrammi delle attività:} descrivono un processo o un algoritmo; - \item \textbf{Diagrammi delle classi:} rappresentano gli oggetti del sistema e loro relazioni; - \item \textbf{Diagrammi dei casi d'uso:} descrivono le funzioni offerte dal sistema; - \item \textbf{Diagrammi dei package:} descrivono le dipendenze tra classi raggruppate in package; - \item \textbf{Diagrammi di sequenza:} descrivono una sequenza di processi o funzioni. + \item \textbf{diagrammi delle attività:} descrivono un processo o un algoritmo; + \item \textbf{diagrammi delle classi:} rappresentano gli oggetti del sistema e loro relazioni; + \item \textbf{diagrammi dei casi d'uso:} descrivono le funzioni offerte dal sistema; + \item \textbf{diagrammi dei package:} descrivono le dipendenze tra classi raggruppate in package; + \item \textbf{diagrammi di sequenza:} descrivono una sequenza di processi o funzioni; \end{itemize} - \item \textbf{Tecnologie utilizzate:} elenco dettagliato delle tecnologie impiegate; + \item \textbf{tecnologie utilizzate:} elenco dettagliato delle tecnologie impiegate. \end{itemize} \paragraph{Codifica} @@ -102,7 +102,7 @@ \subsection{Sviluppo} \subparagraph{Aspettative} L’obiettivo è lo sviluppo del software richiesto dal proponente utilizzando le norme di programmazione stabilite in modo da: \begin{itemize} - \item ottenere codice leggibile ed uniforme per i Programmatori; + \item ottenere codice leggibile ed uniforme per i programmatori; \item agevolare le fasi di manutenzione, verifica e validazione. \end{itemize} % \subparagraph{Stile di codifica} @@ -131,4 +131,6 @@ \subsection{Sviluppo} % \subparagraph{API Producer, Consumer, Connect e Streams} % API consigliate per la produzione di componenti custom per Kafka; % -% \ No newline at end of file +% +\subsubsection{Strumenti} + Per il processo di fornitura non sono stati individuati particolari strumenti da impiegare. \ No newline at end of file diff --git a/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/Documentazione.tex b/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/Documentazione.tex index 988200f..4b08237 100644 --- a/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/Documentazione.tex +++ b/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/Documentazione.tex @@ -1,4 +1,4 @@ -\section{Processi di Supporto} +\section{Processi di supporto} \subsection{Documentazione} @@ -8,240 +8,262 @@ \section{Processi di Supporto} Si vuole fornire uno strumento per la stesura dei documenti unico per tutto il gruppo in modo da avere una documentazione uniforme e aderente agli standard e regole sotto riportate. \subsubsection{Descrizione} Questo capitolo fornisce i dettagli su come deve essere redatta e verificata la documentazione. Tutte le norme descritte devono essere rispettate in pieno da tutti i documenti, sia interni che esterni, rilasciati durante il ciclo di vita del software. - \subsubsection{Ciclo di vita} - Il ciclo di vita dei documenti è suddiviso in varie attività, eventualmente ripetibili: - \begin{itemize} - \item \textbf{Stesura:} è il processo di scrittura del documento in sé; questa attività viene assegnata ad un redattore che, terminato il suo svolgimento, farà riferimento al responsabile, il quale autorizzerà l'avanzamento del documento all'attività successiva; - \item \textbf{Verifica:} è l'attività eseguita dai verificatori, i quali hanno il compito di controllare che la stesura del documento sia avvenuta in modo corretto, sintatticamente e semanticamente, seguendo le norme di progetto. Ogni problema viene riferito al responsabile che provvederà a notificare il redattore e riporterà il documento all'attività di stesura. Quando questa attività sarà portata a termine con successo il responsabile farà avanzare il documento nell'ultima attività del ciclo di vita; - \item \textbf{Approvazione:} è l'ultima attività del ciclo di vita del documento, in cui il verificatore ha terminato il suo compito ed ha comunicato l'esito positivo al responsabile. Il responsabile procederà a confermare il documento ed eseguire il rilascio. - \end{itemize} - \subsubsection{Template LaTeX} - Si è deciso di utilizzare una struttura template \LaTeX{} per facilitare il versionamento e la stesura dei documenti. Inoltre, l'utilizzo di tale struttura fornisce uniformità al layout di tutti i documenti. - \subsubsection{Struttura dei documenti} - Un file ``main.tex'' provvederà a raccogliere tutte le sezioni, pacchetti e comandi necessari per la sua compilazione. Tutti i documenti hanno una struttura predefinita e determinata. - \paragraph{Frontespizio} - Il frontespizio ha la funzione di fornire i dati principali del documento. Esso presenterà il logo e il nome del gruppo, il titolo del documento e la sua appartenenza ad un determinato progetto, le informazioni sul documento quali: - \begin{itemize} - \item \textbf{versione:} versione attuale del documento; - \item \textbf{uso:} destinazione d'uso del documento, che potrà essere ``interno'' o ``esterno''; - \item \textbf{stato:} attuale stato del documento, che potrà essere ``in redazione'' o ``approvato''; - \item \textbf{destinatari:} destinatari del documento; - \item \textbf{redattori:} lista dei membri del gruppo che si sono occupati della stesura dello specifico documento; - \item \textbf{verificatori:} lista dei membri del gruppo che si sono occupati della verifica dello specifico documento; - \item \textbf{approvazione:} nominativo del membro del gruppo che ha approvato il documento per il rilascio. - \end{itemize} - Tutti gli elementi di questa pagina sono centrati ed incolonnati. - \paragraph{Registro modifiche} - \label{par: Registro modifiche} - Il registro delle modifiche occupa la seconda pagina del documento e consiste in una tabella contenente le informazioni riguardanti il ciclo di vita del documento. Più precisamente, la tabella riporta per ogni modifica: - \begin{itemize} - \item \textbf{versione:} versione del documento relativa alla modifica effettuata; - \item \textbf{descrizione:} breve descrizione della modifica effettuata; - \item \textbf{data:} data in cui la modifica è stata effettuata; - \item \textbf{autore:} nominativo della persona che ha effettuato la modifica; - \item \textbf{ruolo:} ruolo della persona che ha effettuato la modifica; - \end{itemize} - \paragraph{Indice} - L'indice ha lo scopo di riepilogare e dare una visione generale della struttura del documento, mostrando le parti di cui è composto. L'indice ha una struttura standard: numero e titolo del capitolo, con eventuali sottosezioni, e il numero della pagina del contenuto; inoltre, ogni titolo è un link alla pagina del contenuto. L'indice dei contenuti è seguito da un eventuale indice per le tabelle e le figure presenti nel documento. - \paragraph{Contenuto principale} - La struttura del contenuto principale di una pagina è strutturato con: - \begin{itemize} - \item in alto a sinistra è presente il logo del gruppo; - \item in alto a destra è riportata la sezione alla quale la pagina appartiene; - \item il contenuto principale è posto tra l'intestazione e il piè di pagina; - \item una riga divide il contenuto principale e il piè di pagina; - \item in basso a sinistra è presente il nome del documenti con relativa versione; - \item in basso a destra riporta il numero della pagina attuale ed il numero totale delle pagine che compongono il documento; se la pagina non fa parte del contenuto principale la sua numerazione avviene tramite i numeri romani. - \end{itemize} - \subsubsection{Classificazione dei documenti} - \paragraph{Documenti ufficiosi} - I documenti ufficiosi sono utilizzati all'interno dell'ambiente di lavoro ed sono divisi in due categorie: - \begin{itemize} - \item \textbf{informativi:} hanno il solo scopo di passare informazioni meno rilevanti tra i membri del gruppo (es. appunti, richieste, riflessioni); - \item \textbf{proto-ufficiali:} sono tutti i documenti che in futuro diventeranno ``ufficiali'' ma sono in attesa di revisione e verifica. - \end{itemize} - \paragraph{Documenti ufficiali} - Si dicono ufficiali i documenti che: - \begin{itemize} - \item sono stati revisionati, verificati ed approvati dal responsabile di progetto; - \item sono gli unici rilasciabili all'esterno del gruppo di progetto. + + \subsubsection{Attività} + \paragraph{Implementazione del processo} + + \subparagraph{Ciclo di vita} + Il ciclo di vita dei documenti è suddiviso in varie attività, eventualmente ripetibili: + \begin{itemize} + \item \textbf{stesura:} è il processo di scrittura del documento in sé; questa attività viene assegnata ad un redattore che, terminato il suo svolgimento, farà riferimento al responsabile, il quale autorizzerà l'avanzamento del documento all'attività successiva; + \item \textbf{verifica:} è l'attività eseguita dai verificatori, i quali hanno il compito di controllare che la stesura del documento sia avvenuta in modo corretto, sintatticamente e semanticamente, seguendo le norme di progetto. Ogni problema viene riferito al responsabile che provvederà a notificare il redattore e riporterà il documento all'attività di stesura. Quando questa attività sarà portata a termine con successo il responsabile farà avanzare il documento nell'ultima attività del ciclo di vita; + \item \textbf{approvazione:} è l'ultima attività del ciclo di vita del documento, in cui il verificatore ha terminato il suo compito ed ha comunicato l'esito positivo al responsabile. Il responsabile procederà a confermare il documento ed eseguire il rilascio. \end{itemize} - \paragraph{Verbali} - I verbali hanno lo scopo di riassumere, in modo coinciso e preciso, tutti gli argomenti che sono stati discussi in una riunione, sia interna che esterna. È prevista un'unica stesura del verbale per ogni riunione in quanto una modifica ad una decisione avrebbe un effetto retroattivo. I verbali seguono la stessa struttura di tutti gli altri documenti ad eccezione fatta della numerazione delle pagine, che usa la notazione romana anziché araba. Inoltre, il verbale è suddiviso in: - \begin{itemize} - \item \textbf{introduzione:} essa contiene: - \begin{itemize} - \item \textbf{luogo:} luogo o la piattaforma online, in caso di incontri virtuali; - \item \textbf{data:} data dell'incontro; - \item \textbf{ora di inizio:} l'ora dell'inizio dell'incontro in formato HH:MM; - \item \textbf{ora di fine:} l'ora della fine dell'incontro in formato HH:MM; - \item \textbf{ordine del giorno:} consiste in una lista degli argomenti che il gruppo si è proposto di discutere durante l'incontro; - \item \textbf{presenze:} contiene il numero totale dei partecipanti, la lista dei presenti e la lista degli assenti con eventuale giustifica; - \item \textbf{segretario: } scelto tra i componenti del gruppo e incaricato di prendere nota delle discussioni effettuate per poi redigere il verbale della riunione. - \end{itemize} - \item \textbf{svolgimento:} per ogni punto presente nell'ordine del giorno, viene riportato un riassunto di ciò che è stato trattato durante l'incontro; - \item \textbf{tracciamento delle decisioni:} è un riepilogo in formato tabellare delle decisioni prese durante l'incontro; esso è composto da: - \begin{itemize} - \item \textbf{codice:} del tipo ``VT\_AAAA-MM-GG\_X.Y'' dove la prima lettera indica che il documento è un verbale(V), la seconda indica la sua tipologia, esterno(E) o interno(I), seguito dalla data dell'incontro a cui fa riferimento e terminato, infine, da un numero che indica il numero del verbale(X) ed un secondo numero che indica il punto all'ordine del giorno a cui si riferisce(Y); - \item \textbf{descrizione:} breve descrizione riassuntiva della decisione presa riguardante il punto dell'ordine del giorno. + + \subparagraph{Documenti ufficiosi} + I documenti ufficiosi sono utilizzati all'interno dell'ambiente di lavoro ed sono divisi in due categorie: + \begin{itemize} + \item \textbf{informativi:} hanno il solo scopo di passare informazioni meno rilevanti tra i membri del gruppo (es. appunti, richieste, riflessioni); + \item \textbf{proto-ufficiali:} sono tutti i documenti che in futuro diventeranno ``ufficiali'' ma sono in attesa di revisione e verifica. \end{itemize} - \end{itemize} - Ogni verbale dovrà essere denominato seguendo il formato ``Verbale riunione \#X'', dove la ``X'' corrisponde al numero del verbale in ordine temporale. - \paragraph{Glossario} - Il glossario ha la funzione di disambiguare alcune parole all'interno di determinati contesti. Al suo interno saranno presenti tutte parole con le seguenti caratteristiche: - \begin{itemize} - \item sono presenti in almeno un documento; - \item trattano argomenti di natura tecnica; - \item trattano argomenti ambigui e/o poco conosciuti; - \item rappresentano delle sigle e/o degli acronimi non di uso comune. - \end{itemize} - Inoltre, il glossario è strutturato in maniera precisa seguendo due regole: - \begin{itemize} - \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 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 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 escluse da questa sintassi le estensione dei file. - \end{itemize} - Alcuni esempi corretti sono: - \begin{itemize} - \item convenzioniSuiNomiDeiFile.tex; - \item documentazione.tex - \end{itemize} - Alcuni esempi non corretti sono: - \begin{itemize} - \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{Stile del testo} - I vari stili del testo hanno una specifica funzione semantica. - \begin{itemize} - \item \textbf{corsivo:} viene utilizzato per denotare termini tecnici appartenenti ad una particolare tecnologia, esempio \textit{branch}; - \item \textbf{grassetto:} viene utilizzato per evidenziare le parole con la definizione della stessa in seguito, per esempio in un elenco puntato, queste includeranno i due punti in grassetto, per esempio ``\textbf{def.:} abbreviazione per la parola definizione''; oppure per denotare le sezioni e sotto-sezioni dei documenti; - \item \textbf{maiuscoletto:} viene utilizzato per denotare parole che sono: - \begin{itemize} - \item riferimenti a documenti esterni, con pedice una ``D''; - \item appartenenti al glossario, con pedice una ``G''. - \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 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.''. - \end{itemize} - \paragraph{Formati comuni} - \begin{itemize} - \item \textbf{data:} viene utilizzato lo standard ISO 8601, esempio 2020-01-22, per la rappresentazione di tutte le date presenti della documentazione; - \item \textbf{ora:} viene utilizzato il formato HH:MM; - \item \textbf{versione:} viene utilizzato il formato vXX.YY.ZZ+bJJ.KK. - \end{itemize} - \paragraph{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} - \item \textbf{analisi dei requisiti - AdR:} descrive le caratteristiche del software; - \item \textbf{piano di progetto - PdP:} riguarda la gestione del progetto, ossia descrive parametri come fattibilità, costi, vincoli del progetto; - \item \textbf{piano di qualifica - PdQ:} descrive la qualità del software e dei processi coinvolti, come e con quali strumenti si intende raggiungere tale qualità; - \item \textbf{manuale utente - MU:} manuale per gli utilizzatori del software; - \item \textbf{manuale sviluppatore - MS:} manuale per gli sviluppatori e manutentori. - \end{itemize} - \item documenti interni: + \subparagraph{Documenti ufficiali} + Si dicono ufficiali i documenti che: + \begin{itemize} + \item sono stati revisionati, verificati ed approvati dal responsabile di progetto; + \item sono gli unici rilasciabili all'esterno del gruppo di progetto. + \end{itemize} + I documenti che verranno prodotti sono: + \subparagraph{Studio di fattibilità} + Lo \textit{studio di fattibilità} ha l'obiettivo di descrivere brevemente ciò che ogni \glock{capitolato} ha da proporre, elencando quelli che il nostro gruppo ha considerato come i loro aspetti più interessanti e le loro criticità. I destinatari di questo documento sono i membri del gruppo Red Round Robin. + \subparagraph{Piano di progetto} + Lo scopo del \textit{piano di progetto} è quello di organizzare le attività, analizzandone i rischi, suddividendole ed assegnandole ai vari membri del gruppo, in modo tale da raggiungere i risultati nel modo più efficace ed efficiente possibile. I destinatari di questo documento sono il committente ed il proponente oltre al gruppo Red Round Robin. + \subparagraph{Piano di qualifica} + Il \textit{piano di qualifica} ha lo scopo di presentare i metodi di verifica e validazione adottate dal gruppo Red Round Robin per garantire la qualità di prodotto e di processo. Per assicurarci di ciò, viene applicato un sistema di verifica continua che permette l'individuazione di eventuali errori in modo da poterli individuare e risolvere efficacemente limitando gli sprechi di tempo. I destinatari di questo documento sono il proponente ed il committente oltre al gruppo Red Round Robin. + \subparagraph{Analisi dei requisiti} + Lo scopo dell'\textit{analisi dei requisiti} è la candidatura del gruppo Red Round Robin allo svolgimento del progetto relativo al capitolato C6 - ThiReMa. All'interno di questa analisi è possibile seguire la classificazione, il tracciamento e la descrizione dettagliata dei requisiti individuati dall'analisi del capitolato scelto. I destinatari di questo documento sono i membri del gruppo Red Round Robin, il committente e il proponente. + \subparagraph{Verbali} + I verbali hanno lo scopo di riassumere, in modo coinciso e preciso, tutti gli argomenti che sono stati discussi in una riunione, sia interna che esterna. È prevista un'unica stesura del verbale per ogni riunione in quanto una modifica ad una decisione avrebbe un effetto retroattivo. + \subparagraph{Glossario} + Il glossario ha la funzione di disambiguare alcune parole all'interno di determinati contesti. I destinatari del documento sono i membri del gruppo Red Round Robin, il committente e il proponente. + + \paragraph{Sviluppo e design} + \subparagraph{Template LaTeX} + Si è deciso di utilizzare una struttura template \LaTeX{} per facilitare il versionamento e la stesura dei documenti. Inoltre, l'utilizzo di tale struttura fornisce uniformità al layout di tutti i documenti. + \subparagraph{Struttura generale dei documenti} + Un file ``main.tex'' provvederà a raccogliere tutte le sezioni, pacchetti e comandi necessari per la sua compilazione. Tutti i documenti hanno una struttura predefinita e determinata. + \subparagraph{Frontespizio} + Il frontespizio ha la funzione di fornire i dati principali del documento. Esso presenterà il logo e il nome del gruppo, il titolo del documento e la sua appartenenza ad un determinato progetto, le informazioni sul documento quali: + \begin{itemize} + \item \textbf{versione:} versione attuale del documento; + \item \textbf{uso:} destinazione d'uso del documento, che potrà essere ``interno'' o ``esterno''; + \item \textbf{stato:} attuale stato del documento, che potrà essere ``in redazione'' o ``approvato''; + \item \textbf{destinatari:} destinatari del documento; + \item \textbf{redattori:} lista dei membri del gruppo che si sono occupati della stesura dello specifico documento; + \item \textbf{verificatori:} lista dei membri del gruppo che si sono occupati della verifica dello specifico documento; + \item \textbf{approvazione:} nominativo del membro del gruppo che ha approvato il documento per il rilascio. + \end{itemize} + Tutti gli elementi di questa pagina sono centrati ed incolonnati. + \subparagraph{Registro modifiche} + \label{par: Registro modifiche} + Il registro delle modifiche occupa la seconda pagina del documento e consiste in una tabella contenente le informazioni riguardanti il ciclo di vita del documento. Più precisamente, la tabella riporta per ogni modifica: + \begin{itemize} + \item \textbf{versione:} versione del documento relativa alla modifica effettuata; + \item \textbf{descrizione:} breve descrizione della modifica effettuata; + \item \textbf{data:} data in cui la modifica è stata effettuata; + \item \textbf{autore:} nominativo della persona che ha effettuato la modifica; + \item \textbf{ruolo:} ruolo della persona che ha effettuato la modifica. + \end{itemize} + \subparagraph{Indice} + L'indice ha lo scopo di riepilogare e dare una visione generale della struttura del documento, mostrando le parti di cui è composto. L'indice ha una struttura standard: numero e titolo del capitolo, con eventuali sottosezioni, e il numero della pagina del contenuto; inoltre, ogni titolo è un link alla pagina del contenuto. L'indice dei contenuti è seguito da un eventuale indice per le tabelle e le figure presenti nel documento. + \subparagraph{Contenuto principale} + La struttura del contenuto principale di una pagina è strutturato con: \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 analizzando brevemente i loro pro e contro. + \item in alto a sinistra è presente il logo del gruppo; + \item in alto a destra è riportata la sezione alla quale la pagina appartiene; + \item il contenuto principale è posto tra l'intestazione e il piè di pagina; + \item una riga divide il contenuto principale e il piè di pagina; + \item in basso a sinistra è presente il nome del documenti con relativa versione; + \item in basso a destra riporta il numero della pagina attuale ed il numero totale delle pagine che compongono il documento; se la pagina non fa parte del contenuto principale la sua numerazione avviene tramite i numeri romani; \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} - Inoltre, il ciclo di vita del progetto è diviso in quattro fasi: - \begin{itemize} - \item \textbf{revisione dei requisiti - RR:} studio iniziale del capitolato; - \item \textbf{revisione di progettazione - RP:} definizione dell'architettura e della fattibilità del software; - \item \textbf{revisione di qualifica - RQ:} produzione di codice e descrizione dettagliata delle sue componenti; - \item \textbf{revisione di accettazione - RA:} approvazione del prodotto da parte del cliente e rilascio del software. - \end{itemize} - Altre sigle utilizzate all'interno dei documenti sono: + \subparagraph{Verbali} + I verbali seguono la stessa struttura di tutti gli altri documenti ad eccezione fatta della numerazione delle pagine, che usa la notazione romana anziché araba. Inoltre, il verbale è suddiviso in: + \begin{itemize} + \item \textbf{introduzione:} essa contiene: + \begin{itemize} + \item \textbf{luogo:} luogo o la piattaforma online, in caso di incontri virtuali; + \item \textbf{data:} data dell'incontro; + \item \textbf{ora di inizio:} l'ora dell'inizio dell'incontro in formato HH:MM; + \item \textbf{ora di fine:} l'ora della fine dell'incontro in formato HH:MM; + \item \textbf{ordine del giorno:} consiste in una lista degli argomenti che il gruppo si è proposto di discutere durante l'incontro; + \item \textbf{presenze:} contiene il numero totale dei partecipanti, la lista dei presenti e la lista degli assenti con eventuale giustifica; + \item \textbf{segretario: } scelto tra i componenti del gruppo e incaricato di prendere nota delle discussioni effettuate per poi redigere il verbale della riunione; + \end{itemize} + \item \textbf{svolgimento:} per ogni punto presente nell'ordine del giorno, viene riportato un riassunto di ciò che è stato trattato durante l'incontro; + \item \textbf{tracciamento delle decisioni:} è un riepilogo in formato tabellare delle decisioni prese durante l'incontro; esso è composto da: + \begin{itemize} + \item \textbf{codice:} del tipo ``VT\_AAAA-MM-GG\_X.Y'' dove la prima lettera indica che il documento è un verbale(V), la seconda indica la sua tipologia, esterno(E) o interno(I), seguito dalla data dell'incontro a cui fa riferimento e terminato, infine, da un numero che indica il numero del verbale(X) ed un secondo numero che indica il punto all'ordine del giorno a cui si riferisce(Y); + \item \textbf{descrizione:} breve descrizione riassuntiva della decisione presa riguardante il punto dell'ordine del giorno. + \end{itemize} + \end{itemize} + Ogni verbale dovrà essere denominato seguendo il formato ``Verbale riunione \#X'', dove la ``X'' corrisponde al numero del verbale in ordine temporale. + \subparagraph{Glossario} + All'interno del glossario saranno presenti tutte parole con le seguenti caratteristiche: + \begin{itemize} + \item sono presenti in almeno un documento; + \item trattano argomenti di natura tecnica; + \item trattano argomenti ambigui e/o poco conosciuti; + \item rappresentano delle sigle e/o degli acronimi non di uso comune. + \end{itemize} + Inoltre, il glossario è strutturato in maniera precisa seguendo due regole: + \begin{itemize} + \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 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. + \subparagraph{Lettere} + 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. + \subparagraph{Norme tipografiche} + \subparagraph{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 escluse da questa sintassi le estensione dei file. + \end{itemize} + Alcuni esempi corretti sono: + \begin{itemize} + \item convenzioniSuiNomiDeiFile.tex; + \item documentazione.tex + \end{itemize} + Alcuni esempi non corretti sono: + \begin{itemize} + \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} + \subparagraph{Stile del testo} + i vari stili del testo hanno una specifica funzione semantica. + \begin{itemize} + \item \textbf{corsivo:} viene utilizzato per denotare termini tecnici appartenenti ad una particolare tecnologia, esempio \textit{branch}; + \item \textbf{grassetto:} viene utilizzato per evidenziare le parole con la definizione della stessa in seguito, per esempio in un elenco puntato, queste includeranno i due punti in grassetto, per esempio ``\textbf{def.:} abbreviazione per la parola definizione''; oppure per denotare le sezioni e sotto-sezioni dei documenti; + \item \textbf{maiuscoletto:} viene utilizzato per denotare parole che sono: + \begin{itemize} + \item riferimenti a documenti esterni, con pedice una ``D''; + \item appartenenti al glossario, con pedice una ``G''. + \end{itemize} + \end{itemize} + \subparagraph{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 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.''. + \end{itemize} + \subparagraph{Formati comuni} + \begin{itemize} + \item \textbf{data:} viene utilizzato lo standard ISO 8601, esempio 2020-01-22, per la rappresentazione di tutte le date presenti della documentazione; + \item \textbf{ora:} viene utilizzato il formato HH:MM; + \item \textbf{versione:} viene utilizzato il formato vXX.YY.ZZ+bJJ.KK. + \end{itemize} + \subparagraph{Sigle} + Il progetto richiede la redazione di un insieme di documenti; segue l'elenco dei documenti con relative sigle: + \begin{itemize} + \item \textbf{documenti esterni:} + \begin{itemize} + \item \textbf{analisi dei requisiti - AdR:} descrive le caratteristiche del software; + \item \textbf{piano di progetto - PdP:} riguarda la gestione del progetto, ossia descrive parametri come fattibilità, costi, vincoli del progetto; + \item \textbf{piano di qualifica - PdQ:} descrive la qualità del software e dei processi coinvolti, come e con quali strumenti si intende raggiungere tale qualità; + \item \textbf{manuale utente - MU:} manuale per gli utilizzatori del software; + \item \textbf{manuale sviluppatore - MS:} manuale per gli sviluppatori e manutentori. + \end{itemize} + \item \textbf{documenti interni:} + \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 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} + Inoltre, il ciclo di vita del progetto è diviso in quattro fasi: + \begin{itemize} + \item \textbf{revisione dei requisiti - RR:} studio iniziale del capitolato; + \item \textbf{revisione di progettazione - RP:} definizione dell'architettura e della fattibilità del software; + \item \textbf{revisione di qualifica - RQ:} produzione di codice e descrizione dettagliata delle sue componenti; + \item \textbf{revisione di accettazione - RA:} approvazione del prodotto da parte del cliente e rilascio del software. + \end{itemize} + Altre sigle utilizzate all'interno dei documenti sono: + \begin{itemize} + \item AWS: \glock{amazon web service}; + \item ETH: ethereum; + \item EVM: ethereum virtual machine; + \item LR: \glock{regressione lineare}; + \item SVM: \glock{support vector machine}; + \item ML: \glock{machine learning}; + \item JS: \glock{JavaScript}; + \item AoA: angolo di arrivo; + \item UI: \glock{user interface}; + \item PaaS: platform as a service; + \item IaaS: infrastructure as a service; + \item FaaS: function as a service; + \item CaaS: container as a service; + \item BaaS: back end as a service; + \item IoT: internet of things; + \item DB: \glock{database}; + \item VCS: \glock{version control system}. + \end{itemize} + + \subparagraph{Elementi grafici} + \subparagraph{Tabelle} + Le tabelle sono sempre accompagnate da un titolo e dal numero della tabella; sono indicizzate separatamente rispetto al resto del contenuto. + \subparagraph{Immagini} + Le immagini sono sempre accompagnate da una didascalia descrittiva e dal numero della figura; sono indicizzate separatamente rispetto al resto del contenuto. + \subparagraph{Diagrammi UML} + I diagrammi UML vengono inseriti all'interno della documentazione sotto forma di immagini. + + \subsubsection{Metriche - Comprensione (QC-1)} + \paragraph{Scopo} + Per fornire una documentazione fruibile e comprensibile si è deciso di monitorare la sua qualità tramite delle metriche significative. + \paragraph{Introduzione alle metriche di qualità} + Per la funzionabilità si è deciso di utilizzare le seguenti metriche: \begin{itemize} - \item AWS: \glock{amazon web service}; - \item ETH: ethereum; - \item EVM: ethereum virtual machine; - \item LR: \glock{regressione lineare}; - \item SVM: \glock{support vector machine}; - \item ML: \glock{machine learning}; - \item JS: \glock{JavaScript}; - \item AoA: angolo di arrivo; - \item UI: \glock{user interface}; - \item PaaS: platform as a service; - \item IaaS: infrastructure as a service; - \item FaaS: function as a service; - \item CaaS: container as a service; - \item BaaS: back end as a service; - \item IoT: internet of things; - \item DB: \glock{database}; - \item VCS: \glock{version control system}. + \item QM-PROD-1 \glock{Indice di Gulpease} (GULP); + \item QM-PROD-2 Correttezza ortografica (CORT). \end{itemize} - \subsubsection{Comprensione (QC-1)} - \paragraph{Scopo} - Per fornire una documentazione fruibile e comprensibile si è deciso di monitorare la sua qualità tramite delle metriche significative. - \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} - \paragraph{QM-PROD-1 Indice di Gulpease (GULP)} - \subparagraph{Descrizione} - 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} - La formula della metrica è la seguente: - \( - GULP = 89+\frac{300\times\# frasi-10\times\#lettere}{\#parole} - \) - \subparagraph{Risultato} - Il risultato della formula ha i seguenti significati: - \begin{itemize} - \item se il risultato è pari 0 allora il documento non esiste e/o la sua leggibilità è terribile; - \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 è pari a 100 allora il documento esiste ed è molto più che leggibile. + \paragraph{QM-PROD-1 Indice di Gulpease (GULP)} + \subparagraph{Descrizione} + 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} + La formula della metrica è la seguente: + \( + GULP = 89+\frac{300\times\# frasi-10\times\#lettere}{\#parole} + \) + \subparagraph{Risultato} + Il risultato della formula ha i seguenti significati: + \begin{itemize} + \item se il risultato è pari 0 allora il documento non esiste e/o la sua leggibilità è terribile; + \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 è pari a 100 allora il documento esiste ed è molto più che leggibile. \end{itemize} - \paragraph{QM-PROD-2 Correttezza ortografica (CORT)} - \subparagraph{Descrizione} + \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} - La metrica è espressa tramite un numero intero. - \subparagraph{Formula} - La formula della metrica è la seguente: - \textit{CORT = \# numero di errori ortografici} - \subparagraph{Risultato} - Il risultato della formula ha i seguenti significati: - \begin{itemize} - \item se il risultato è pari 0 allora il documento non esiste o non ha errori ortografici; - \item se il risultato è maggiore di 0 allora il documento esiste e presenta errori ortografici. - \end{itemize} - \subsubsection{Elementi grafici} - \paragraph{Tabelle} - 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 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. + \subparagraph{Unità di Misura} + La metrica è espressa tramite un numero intero. + \subparagraph{Formula} + La formula della metrica è la seguente: + \textit{CORT = \# numero di errori ortografici} + \subparagraph{Risultato} + Il risultato della formula ha i seguenti significati: + \begin{itemize} + \item se il risultato è pari 0 allora il documento non esiste o non ha errori ortografici; + \item se il risultato è maggiore di 0 allora il documento esiste e presenta errori ortografici. + \end{itemize} + \subsubsection{Strumenti} \paragraph{LaTeX} Per la scrittura dei documenti è stato scelto di usare \LaTeX{}, esso è un linguaggio di markup basato sul programma di tipografia digitale \TeX{}. Questo permette di scrivere documenti in maniera modulare e collaborativa. diff --git a/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/GaranziaQualita.tex b/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/GaranziaQualita.tex index 6fb1078..ce6ebab 100644 --- a/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/GaranziaQualita.tex +++ b/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/GaranziaQualita.tex @@ -1,4 +1,4 @@ -\subsection{Garanzia della Qualità} +\subsection{Garanzia della qualità} \subsubsection{Scopo} @@ -27,43 +27,45 @@ \subsection{Garanzia della Qualità} Per ogni processo mirato alla qualità si definiscono delle metriche che vengono riportate in ciascuna sezione del presente documento. Le registrazioni dei risultati ottenuti dall'analisi della qualità sono salvate con degli appositi report. - \paragraph{Obiettivi Qualità di Prodotto} + \paragraph{Obiettivi di 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 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. + \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} L'insieme di questi processi deve portare a un miglioramento continuo del prodotto, che viene sottoposto agli standard di qualità riportati nel \textit{way of working}. - \paragraph{Obiettivi Qualità di Processo} + \paragraph{Obiettivi qualità di processo} 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 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. + \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. - \subsection{Classificazione dei Processi} + \subsubsection{Attività} - Nell'ambito di qualità, i processi vengono tracciati con il seguente identificativo: + \paragraph{Classificazione dei processi} - \[ - \text{QP}-[\lambda] - \] + Nell'ambito di qualità, i processi vengono tracciati con il seguente identificativo: - Dove: + \[ + \text{QP}-[\lambda] + \] - \begin{itemize} - \item QP : indica letteralmente \textit{Quality Process}; - \item \(\lambda\) : numero intero che indica il processo e parte da 1. - \end{itemize} + Dove: - \subsection{Classificazione delle Caratteristiche del Prodotto} + \begin{itemize} + \item QP: indica letteralmente \textit{Quality Process}; + \item \(\lambda\): numero intero che indica il processo e parte da 1. + \end{itemize} + + \paragraph{Classificazione delle caratteristiche di prodotto} Nell'ambito di qualità, le caratteristiche del prodotto vengono tracciate con il seguente identificativo: @@ -74,11 +76,11 @@ \subsection{Garanzia della Qualità} Dove: \begin{itemize} - \item QC : indica letteralmente \textit{Quality Characteristic}; - \item \(\lambda\) : numero intero che indica la caratteristica di prodotto e parte da 1. + \item QC: indica letteralmente \textit{Quality Characteristic}; + \item \(\lambda\): numero intero che indica la caratteristica di prodotto e parte da 1. \end{itemize} - \subsection{Classificazione delle Metriche} + \paragraph{Classificazione delle metriche} Le metriche sono i criteri che vengono utilizzati per misurare nei processi e nel prodotto i gradi di qualità raggiunti. A ciascuna metrica si associa il seguente identificatore: @@ -89,614 +91,624 @@ \subsection{Garanzia della Qualità} Dove: \begin{itemize} - \item QM : indica letteralmente \textit{Quality Metric} - \item \(\delta\) : riguarda la tipologia della metrica e può assumere i valori riportati di seguito: + \item QM: indica letteralmente \textit{Quality Metric}; + \item \(\delta\): riguarda la tipologia della metrica e può assumere i valori riportati di seguito: \begin{itemize} \item \textbf{PROC}: indica che la metrica si associa per un processo; \item \textbf{PROD}: indica che la metrica si associa per il prodotto; \item \textbf{TEST}: indica che la metrica si associa per i test; \end{itemize} - \item \(\lambda\) : numero intero che indica la metrica e parte da 1. + \item \(\lambda\): numero intero che indica la metrica e parte da 1. \end{itemize} -% \subsubsection{Elenco delle metriche} -% -% Per ciascuna attività, sia che riguardi la documentazione, il software o il monitoraggio di processo, si riporta nella relativa sezione una classificazione delle metriche di qualità. -% -% \subsubsection{QP-1 Gestione delle Risorse} -% -% \paragraph{Scopo} -% -% Si vuole gestire la copertura di risorse disponibili per la realizzazione del progetto, monitorando i costi aggiuntivi e le tempistiche non rispettate dalla schedulazione pianificata. Questo può essere utile al cliente per capire in fase di sviluppo l'andamento del progetto a livello di gestione delle risorse. -% -% \paragraph{Introduzione alle Metriche} -% -% Per la gestione delle risorse si farà uso delle seguenti metriche: -% -% \begin{itemize} -% \item QM-PROC-1. Budgeted Cost of Work Scheduled (BCWS); -% \item QM-PROC-2. Actual Cost of Work Performed (ACWP); -% \item QM-PROC-3. Budgeted Cost of Work Performed (BCWP); -% \item QM-PROC-4. Schedule Variance (SV); -% \item QM-PROC-5. Cost Variance (CV). -% \end{itemize} -% -% \paragraph{QM-PROC-1. Budgeted Cost of Work Scheduled (BCWS)} -% -% \subparagraph{Descrizione} -% La metrica BCWS definisce il costo pianificato per realizzare le attività di progetto alla data corrente. -% -% \subparagraph{Unità di Misura} -% Il costo pianificato è misurato in EURO. -% -% \paragraph{QM-PROC-2. Actual Cost of Work Performed (ACWP)} -% -% \subparagraph{Descrizione} -% La metrica ACWP definisce il costo effettivamente sostenuto per realizzare le attività di progetto alla data corrente. -% -% \subparagraph{Unità di Misura} -% Il costo sostenuto è misurato in EURO. -% -% \paragraph{QM-PROC-3. Budgeted Cost of Work Performed (BCWP)} -% -% \subparagraph{Descrizione} -% La metrica BCWP definisce il valore delle attività realizzate alla data corrente. In altre parole, misura il valore del prodotto fino ad ora realizzato. -% -% \subparagraph{Unità di Misura} -% Il valore del prodotto è misurato in EURO. -% -% \paragraph{QM-PROC-4. Schedule Variance (SV)} -% -% \subparagraph{Descrizione} -% La metrica SV indica se si è in anticipo, in ritardo o in linea rispetto alle schedulazioni pianificate per il progetto. Questo può essere utile per il cliente per valutare l'efficacia del gruppo nei confronti della realizzazione del progetto. -% -% \subparagraph{Unità di Misura} -% La metrica viene espressa in percentuale. -% -% \subparagraph{Formula} -% La formula per il calcolo della metrica è la seguente: -% -% \[ -% \text{SV} = \frac{\text{BCWP} - \text{BCWS}}{\text{BCWS}} \times 100 -% \] -% -% \subparagraph{Risultato} -% \begin{itemize} -% \item Un risultato \textbf{positivo} (\(> 0\)) indica che il progetto è avanti rispetto alla schedulazione; -% \item Un risultato \textbf{negativo} (\(< 0\)) indica che il progetto è indietro rispetto alla schedulazione; -% \item Un risultato \textbf{pari a zero} indica che il progetto è in linea rispetto alla schedulazione. -% \end{itemize} -% -% \paragraph{QM-PROC-5. Cost Variance (CV)} -% -% \subparagraph{Descrizione} -% La metrica CV indica se il valore del costo realmente maturato è maggiore, minore o uguale rispetto al costo effettivo. In altre parole, permette di comprendere con che livello di efficienza il gruppo sta sviluppando il progetto, rispetto a quanto pianificato. -% -% \subparagraph{Unità di Misura} -% La metrica viene espressa in percentuale. -% -% \subparagraph{Formula} -% La formula per il calcolo della metrica è la seguente: -% -% \[ -% \text{CV} = \frac{\text{BCWP} - \text{ACWP}}{\text{BCWP}} \times 100 -% \] -% -% \subparagraph{Risultato} -% \begin{itemize} -% \item Un risultato \textbf{positivo} (\(> 0\)) indica che il progetto sta sviluppando con un costo minore rispetto a quanto pianificato (maggiore efficienza); -% \item Un risultato \textbf{negativo} (\(< 0\)) indica che il progetto sta sviluppando con un costo maggiore rispetto a quanto pianificato (minore efficienza); -% \item Un risultato \textbf{pari a zero} indica che il progetto sta sviluppando con un costo in linea rispetto a quello pianificato. -% \end{itemize} -% -% \subsubsection{QP-2 Gestione dei Rischi} -% -% \paragraph{Scopo} -% -% Si vuole monitorare i rischi che possono incorrere durante lo svolgimento del progetto, dalla loro scoperta fino alla loro risoluzione. -% -% \paragraph{Introduzione alle Metriche} -% -% Per la gestione dei rischi si farà uso delle seguenti metriche: -% -% \begin{itemize} -% \item QM-PROC-6. Unbudgeted Risks (UR) -% \end{itemize} -% -% \paragraph{QM-PROC-6. Unbudgeted Risks (UR)} -% -% \subparagraph{Descrizione} -% La metrica UR viene utilizzata per tracciare in modo incrementale tutti i nuovi rischi non precedentemente preventivati che avvengono durante una fase del progetto. -% -% \subparagraph{Unità di Misura} -% La metrica viene espressa con un valore intero che parte da 0. -% -% \subparagraph{Formula} -% Per ogni rischio non preventivato e non individuato precedentemente che viene viene rilevato, si incrementa di una unità il numero di rischi rilevati fino alla data corrente, a partire da una fase del progetto. -% La formula della metrica è la seguente: -% \[ -% \text{UR} = \text{UR} + 1 -% \] -% -% \subparagraph{Risultato} -% \begin{itemize} -% \item Un valore pari a 0, indica che non sono stati trovati rischi nella fase del progetto; -% \item Un valore superiore a 0, indica che sono stati trovati rischi nella fase del progetto. -% \end{itemize} -% -% \subsubsection{QP-3 Analisi dei Requisiti} -% -% \paragraph{Scopo} -% -% Si vuole monitorare l'avanzamento dello sviluppo dei requisiti illustrati nel documento di \dext{Analisi dei Requisiti v1.0.0}. Questo può essere utile al cliente, per comprendere la percentuale di completamento del progetto nel corso del tempo. -% -% \paragraph{Introduzione alle Metriche} -% -% Per la gestione dei rischi si farà uso delle seguenti metriche: -% -% \begin{itemize} -% \item QM-PROC-7. Satisfied Mandatory Requirements (SMR); -% \item QM-PROC-8. Satisfied Desirable Requirements (SDR); -% \item QM-PROC-9. Satisfied Optional Requirements (SOR). -% \end{itemize} -% -% \paragraph{QM-PROC-7. Satisfied Mandatory Requirements (SMR)} -% -% \subparagraph{Descrizione} -% La metrica SMR indica il quantitativo di requisiti obbligatori soddisfatti (progettati, sviluppati, verificati e validati) fino alla data corrente. Questa metrica permette sia al gruppo, che al cliente, di comprendere la percentuale di completamento del progetto. -% -% \subparagraph{Unità di Misura} -% La metrica viene espressa in percentuale. -% -% \subparagraph{Formula} -% La formula della metrica è la seguente: -% \[ -% \text{SMR} = \frac{\text{requisiti obbligatori soddisfatti}}{\text{requisiti obbligatori totali}} \times 100 -% \] -% -% \subparagraph{Risultato} -% \begin{itemize} -% \item Un risultato pari a 0\% indica indica che non è stato soddisfatto ancora alcun requisito obbligatorio; -% \item Un risultato pari a 100\% indica che sono stati soddisfatti tutti i requisiti obbligatori. -% \end{itemize} -% -% \paragraph{QM-PROC-8. Satisfied Desirable Requirements (SDR)} -% -% \subparagraph{Descrizione} -% La metrica SDR indica il quantitativo di requisiti desiderabili soddisfatti (progettati, sviluppati, verificati e validati) fino alla data corrente. -% -% \subparagraph{Unità di Misura} -% La metrica viene espressa in percentuale. -% -% \subparagraph{Formula} -% La formula della metrica è la seguente: -% \[ -% \text{SDR} = \frac{\text{requisiti desiderabili soddisfatti}}{\text{requisiti desiderabili totali}} \times 100 -% \] -% -% \subparagraph{Risultato} -% \begin{itemize} -% \item Un risultato pari a 0\% indica indica che non è stato soddisfatto ancora alcun requisito desiderabile; -% \item Un risultato pari a 100\% indica che sono stati soddisfatti tutti i requisiti desiderabili. -% \end{itemize} -% -% \paragraph{QM-PROC-9. Satisfied Optional Requirements (SOR)} -% -% \subparagraph{Descrizione} -% La metrica SDR indica il quantitativo di requisiti desiderabili soddisfatti (progettati, sviluppati, verificati e validati) fino alla data corrente. -% -% \subparagraph{Unità di Misura} -% La metrica viene espressa in percentuale. -% -% \subparagraph{Formula} -% La formula della metrica è la seguente: -% \[ -% \text{SOR} = \frac{\text{requisiti opzionali soddisfatti}}{\text{requisiti opzionali totali}} \times 100 -% \] -% -% \subparagraph{Risultato} -% \begin{itemize} -% \item Un risultato pari a 0\% indica indica che non è stato soddisfatto ancora alcun requisito opzionale; -% \item Un risultato pari a 100\% indica che sono stati soddisfatti tutti i requisiti opzionali. -% \end{itemize} -% -% \subsubsection{QP-4. Verifica del Software} -% -% \paragraph{Scopo} -% -% Durante tutta la fase di sviluppo, si vuole monitorare il processo di Verifica del Software mettendo in luce aspetti che riguardano la complessità e la copertura di test a livello di codice. Questo può essere utile per il cliente e per il gruppo per comprendere l'avanzamento delle attività di verifica del software fino alla data attuale. -% -% \paragraph{Introduzione alle Metriche} -% -% Per la Verifica del Software si farà uso delle seguenti metriche: -% -% \begin{itemize} -% -% %\item QM-PROC-10. Branch Coverage (BCOV); -% %\item QM-PROC-11. Condition Coverage (COCOV); -% %\item QM-PROC-12. Statement Coverage (SCOV); -% \item QM-TEST-13. Passed Test Cases Percentage (PTCP); -% \item QM-TEST-14. Failed Test Cases Percentage (FTCP); -% \item QM-TEST-15. Bug-Fixing Percentage (BFP); -% \item QM-TEST-16. Test Effectiveness (TE). -% \end{itemize} -% -% \paragraph{QM-PROC-10. Branch Coverage (BCOV)} -% -% \subparagraph{Descrizione} -% La metrica BC viene utilizzata per assicurare l'esecuzione di ogni possibile ramo (branch) decisionale del programma almeno una volta. Questo permette di comprendere quali rami decisionali non vengono effettivamente eseguiti e testati. -% -% \subparagraph{Unità di Misura} -% La metrica viene espressa in percentuale. -% -% \subparagraph{Formula} -% La formula della metrica è la seguente: -% \[ -% \text{BCOV} = \frac{\text{Numero di rami eseguiti}}{\text{Numero totale di rami}} \times 100 -% \] -% -% \subparagraph{Risultato} -% \begin{itemize} -% \item Se il risultato è pari a 0\%, la copertura è nulla. -% \item Se il risultato è pari al 100\%, la copertura è totale. -% \item Se il risultato è maggiore di 0\%, ma minore di 100\%, la copertura è parziale. -% \end{itemize} -% -% \paragraph{QM-PROC-11. Condition Coverage (COCOV)} -% -% \subparagraph{Descrizione} -% La metrica CC verifica che ogni condizione di tipo booleano realizzata con gli operatori logici venga considerata sia vera che falsa. Questo permette di avere una migliore sensibilità sul controllo di flusso del programma. -% -% \subparagraph{Unità di Misura} -% La metrica viene espressa in percentuale. -% -% \subparagraph{Formula} -% La formula della metrica è la seguente: -% \[ -% \text{COCOV} = \frac{\text{Numero di operandi eseguiti}}{\text{Numero totale di operandi}} \times 100 -% \] -% -% \subparagraph{Risultato} -% \begin{itemize} -% \item Se il risultato è pari a 0\%, la copertura è nulla. -% \item Se il risultato è pari al 100\%, la copertura è totale. -% \item Se il risultato è maggiore di 0\%, ma minore di 100\%, la copertura è parziale. -% \end{itemize} -% -% -% \paragraph{QM-PROC-12. Statement Coverage (SCOV)} -% -% \subparagraph{Descrizione} -% La metrica SC viene utilizzata per calcolare e misurare il numero di statement che possono essere eseguiti, posto un determinato input. L'obiettivo è quello di riuscire a coprire tramite i test il maggior numero di statement, rispetto a quelli totali. -% -% \subparagraph{Unità di Misura} -% La metrica viene espressa in percentuale. -% -% \subparagraph{Formula} -% La formula della metrica è la seguente: -% \[ -% \text{SCOV} = \frac{\text{Numero di statement eseguiti}}{\text{Numero totale di statement}} \times 100 -% \] -% -% \subparagraph{Risultato} -% \begin{itemize} -% \item Se il risultato è pari a 0\%, la copertura è nulla. -% \item Se il risultato è pari al 100\%, la copertura è totale. -% \item Se il risultato è maggiore di 0\%, ma minore di 100\%, la copertura è parziale. -% \end{itemize} -% -% \paragraph{QM-TEST-1. Passed Test Cases Percentage (PTCP)} -% -% \subparagraph{Descrizione} -% La metrica PTCP si utilizza per misurare la percentuale di test passati con successo in una specifica fase del progetto fino alla data corrente. -% -% \subparagraph{Unità di Misura} -% La metrica viene espressa in percentuale. -% -% \subparagraph{Formula} -% La formula della metrica è la seguente: -% \[ -% \text{PTCP} = \frac{\text{Numero di test passati}}{\text{Numero totale di test eseguiti}} \times 100 -% \] -% -% \subparagraph{Risultato} -% \begin{itemize} -% \item Se il risultato è pari a 0\%, nessun test realizzato per il software è andato a buon fine; -% \item Se il risultato è pari al 100\%, tutti i test realizzati per il software sono andati a buon fine; -% \item Se il risultato è compreso tra 0\% e 100\%, non tutti i test realizzati per il software sono andati a buon fine. -% \end{itemize} -% -% \paragraph{QM-TEST-2. Failed Test Cases Percentage (FTCP)} -% -% \subparagraph{Descrizione} -% La metrica FTCP viene usata per misurare la percentuale di test falliti in una specifica fase del progetto fino alla data corrente. -% -% \subparagraph{Unità di Misura} -% La metrica viene espressa in percentuale. -% -% \subparagraph{Formula} -% La formula della metrica è la seguente: -% \[ -% \text{FTCP} = \frac{\text{Numero di test falliti}}{\text{Numero totale di test eseguiti}} \times 100 -% \] -% -% \subparagraph{Risultato} -% \begin{itemize} -% \item Se il risultato è pari a 0\%, non ci sono test realizzati per il software che sono falliti; -% \item Se il risultato è pari al 100\%, tutti i test realizzati per il software sono falliti; -% \item Se il risultato è compreso tra 0\% e 100\%, non tutti i test realizzati per il software sono andati a buon fine. -% \end{itemize} -% -% \paragraph{QM-TEST-3. Bug-Fixing Percentage (BFP)} -% -% \subparagraph{Descrizione} -% La metrica BFP si utilizza per misurare il quantitativo di errori corretti nel codice rispetto agli errori trovati fino alla data corrente. -% -% \subparagraph{Unità di Misura} -% La metrica viene espressa in percentuale. -% -% \subparagraph{Formula} -% La formula della metrica è la seguente: -% \[ -% \text{BFP} = \frac{\text{Numero di difetti corretti}}{\text{Numero di difetti trovati}} \times 100 -% \] -% -% \subparagraph{Risultato} -% \begin{itemize} -% \item Se il risultato è pari a 0\%, nessun difetto è stato risolto; -% \item Se il risultato è pari al 100\%, tutti i difetti sono stati risolti; -% \item Se il risultato è compreso tra 0\% e 100\%, non tutti i difetti sono stati corretti. -% \end{itemize} -% -% \paragraph{QM-TEST-4. Test Effectiveness (TE)} -% -% \subparagraph{Descrizione} -% La metrica TE si utilizza per misurare l'efficacia con cui si trovano dei difetti attraverso i test. -% -% \subparagraph{Unità di Misura} -% La metrica viene espressa in percentuale. -% -% \subparagraph{Formula} -% La formula della metrica è la seguente: -% \[ -% \text{TE} = \frac{\text{Difetti trovati con i test}}{\text{Numero totale di difetti trovati}} \times 100 -% \] -% -% \subparagraph{Risultato} -% \begin{itemize} -% \item Se il risultato è pari a 0\%, nessun difetto è stato risolto; -% \item Se il risultato è pari al 100\%, tutti i difetti sono stati risolti; -% \item Se il risultato è compreso tra 0\% e 100\%, non tutti i difetti sono stati corretti. -% \end{itemize} -% -% \subsubsection{QC-1 Funzionabilità} -% \paragraph{Scopo} -% Durante lo sviluppo si vuole monitorare la capacità del prodotto di soddisfare tutti i requisiti richiesti dall'utente. -% \paragraph{Introduzione alle Metriche} -% Per la funzionabilità si é deciso di utilizzare la seguente metrica: -% \begin{itemize} -% \item QM-PROD-1 Implementazione (IMP). -% \end{itemize} -% \paragraph{QM-PROD-1 Implementazione (IMP)} -% \subparagraph{Descrizione} -% La metrica IMP si utilizza per valutare l'avanzamento dello sviluppo delle funzionalità richieste. -% \subparagraph{Unità di Misura} -% La metrica è espressa in percentuale. -% \subparagraph{Formula} -% La formula della metrica è la seguente: -% \( -% IMP = \frac{\# funzionalita implementate}{\# funzionalita proposte}\times100 -% \) -% \subparagraph{Risultato} -% Il risultato della formula ha i seguenti significati: -% \begin{itemize} -% \item se il risultato è pari a 0\% allora nessuna funzionalità è stata implementata; -% \item se il risultato è compreso tra 0\% e 100\% allora parte delle funzionalità sono state implementate; -% \item se il risultato è pari a 100\% allora tutte le funzionalità sono state implementate. -% \end{itemize} -% -% \subsubsection{QC-2 Affidabilità} -% \paragraph{Scopo} -% Durante lo sviluppo si vuole monitorare l'affidabilità e correttezza, così come la sua tolleranza agli errori. -% \paragraph{Introduzione alle Metriche} -% Per l'affidabilità si é deciso di utilizzare le seguenti metriche: -% \begin{itemize} -% \item QM-PROD-2 Densità errori (DE); -% \item QM-PROD-3 Complessità dei test di classe (CTCLA). -% \end{itemize} -% \paragraph{ QM-PROD-2 Densità errori (DE)} -% \subparagraph{Descrizione} -% La metrica DE permette di misurare in maniera precisa la tolleranza e correttezza di ogni componente del prodotto, mostrando attraverso una percentuale la sua stabilità. -% \subparagraph{Unità di Misura} -% La metrica è espressa in percentuale. -% \subparagraph{Formula} -% La formula della metrica è la seguente: -% \(DE = \frac{\# test passati}{\# test condotti}\times100\) -% \subparagraph{Risultato} -% Il risultato della formula ha i seguenti significati: -% \begin{itemize} -% \item se il risultato è pari a 0\% allora il prodotto non è stato testato o ha fallito i test al quale è stato sottoposto; -% \item se il risultato è compreso tra 0\% e 100\% allora parte del prodotto è stato testato e/o il prodotto ha passato parte dei test; -% \item se il risultato è pari a 100\% allora tutte le parti sono state testate e il prodotto ha passato tutti i test. -% \end{itemize} -% \paragraph{QM-PROD-3 Complessità dei test di classe (CTCLA)} -% \subparagraph{Descrizione} -% La metrica CTCLA trova il suo utilizzo nel monitoraggio dei test che coinvolgono il prodotto e le sue componenti. Essa permette di sapere se ci sono componenti non testate. -% \subparagraph{Unità di Misura} -% La metrica è espressa tramite un numero intero. -% \subparagraph{Formula} -% La formula della metrica è la seguente: -% \textit{CTCLA = \# dei test che coinvolgono la classe} -% \subparagraph{Risultato} -% Il risultato della formula ha i seguenti significati: -% \begin{itemize} -% \item se il risultato è pari a 0 allora il prodotto o componente non è stato incluso in alcun test; -% \item se il risultato è maggiore di 0 allora il prodotto o componente è stato incluso in almeno un test. -% \end{itemize} -% -% \subsubsection{QC-3 Efficienza} -% \paragraph{Scopo} -% È necessari misurare l'efficienza del prodotto in modo da fornire all'utente un software usabile, piacevole e veloce. -% \paragraph{Introduzione alle Metriche} -% Per l'efficienza si è deciso di utilizzare la seguente metrica: -% \begin{itemize} -% \item QM-PROD-4 Risposta media (RM). -% \end{itemize} -% \paragraph{QM-PROD-4 Risposta media (RM)} -% \subparagraph{Descrizione} -% La metrica RM punta a misurare l'efficienza di elaborazione del prodotto in modo da fornire all'utente un'esperienza piacevole di utilizzo. -% \subparagraph{Unità di Misura} -% La metrica è espressa millisecondi (\textit{ms}) -% \subparagraph{Formula} -% La formula della metrica è la seguente: -% \( -% RM = \frac{\sum_{n=1}^{z} tempo di risposta in ms}{z} -% \) -% dove $z$ è il numero di misurazioni effettuate. -% \subparagraph{Risultato} -% Il risultato della formula ha i seguenti significati: -% \begin{itemize} -% \item se il risultato è indica il tempo di risposta medio del prodotto. -% \end{itemize} -% -% \subsubsection{QC-4 Usabilità} -% \paragraph{Scopo} -% Si vuole misurare l'usabilità del prodotto in modo da fornire all'utente un'esperienza piacevole durante il suo utilizzo, nonché fornire un prodotto facile da apprendere ed utilizzare. -% \paragraph{Introduzione alle Metriche} -% Per la funzionabilità si é deciso di utilizzare le seguenti metriche: -% \begin{itemize} -% \item QM-PROD-5 Profondità dell'albero delle azioni (PAA); -% \item QM-PROD-6 Profondità dell'albero delle pagine (PAP). -% \end{itemize} -% \paragraph{QM-PROD-5 Profondità dell'albero delle azioni (PAA)} -% \subparagraph{Descrizione} -% La metrica PAA permette di misurare l'operabilità e la comprensibilità del prodotto da parte dell'utente. Essa misura il numero di azioni effettuate dall'utente prima di poter arrivare al suo obbiettivo. -% \subparagraph{Unità di Misura} -% La metrica è espressa tramite un numero intero. -% \subparagraph{Formula} -% La formula della metrica è la seguente: -% \textit{PAA = \# delle azioni} -% dove ogni click corrisponde ad un'azione. -% \subparagraph{Risultato} -% Il risultato della formula ha i seguenti significati: -% \begin{itemize} -% \item se il risultato è pari 0 allora l'obbiettivo non è raggiungibile e/o l'utente non ne ha accesso; -% \item se il risultato è maggiore di 0 allora l'obbiettivo è raggiungibile in un numero finito di azioni. -% \end{itemize} -% \paragraph{QM-PROD-6 Profondità dell'albero delle pagine (PAP)} -% \subparagraph{Descrizione} -% La metrica PAP permette di misurare l'apprendibilità, l'operabilità e l'attrattiva del prodotto dal punto di vista del cliente. Essa misura il numero di pagine visitate dall'utente prima di poter arrivare al suo obbiettivo. -% \subparagraph{Unità di Misura} -% La metrica è espressa tramite un numero intero. -% \subparagraph{Formula} -% La formula della metrica è la seguente: -% \textit{PAP = \# delle pagine visitate dall'utente} -% \subparagraph{Risultato} -% Il risultato della formula ha i seguenti significati: -% \begin{itemize} -% \item se il risultato è pari a 0 allora la pagina obbiettivo non esiste o l'utente non ne ha accesso; -% \item se il risultato è maggiore di 0 allora la pagina obbiettivo è raggiungibile in un numero finito di passaggi. -% \end{itemize} -% -% \subsubsection{QC-5 Manutenibilità} -% \paragraph{Scopo} -% La manutenibilità viene monitorata in modo da fornire un prodotto modificabile ed estendibile, in modo da poter estendere facilmente sia la vita del prodotto che le sue funzionalità. -% \paragraph{Introduzione alle Metriche} -% Per la funzionabilità si é deciso di utilizzare le seguenti metricche: -% \begin{itemize} -% \item QM-PROD-QM-PROD-7 Complessità del codice (CCOD); -% \item QM-PROD-8 Complessità della classe (CCLA); -% \item QM-PROD-9 Complessità del metodo (CMET). -% \end{itemize} -% \paragraph{QM-PROD-7 Complessità del codice (CCOD)} -% \subparagraph{Descrizione} -% La metrica CCOD permette di misurare la chiarezza dei commenti rispetto la lunghezza del codice scritto. -% \subparagraph{Unità di Misura} -% La metrica è espressa tramite un numero reale. -% \subparagraph{Formula} -% La formula della metrica è la seguente: -% \( -% CCOD = \frac{\# linee commento}{\# linee codice} -% \) -% \subparagraph{Risultato} -% Il risultato della formula ha i seguenti significati: -% \begin{itemize} -% \item se il risultato è pari a 0 allora il codice non è stato commentato; -% \item se il risultato è maggiore di 0 allora il codice ha almeno una riga di commento. -% \end{itemize} -% \paragraph{QM-PROD-8 Complessità della classe (CCLA)} -% \subparagraph{Descrizione} -% La metrica CCLA misure il numero di metodi presenti in ogni classe e permette di valutare la complessità generale della stessa. -% \subparagraph{Unità di Misura} -% La metrica è espressa tramite un numero intero. -% \subparagraph{Formula} -% La formula della metrica è la seguente: -% \textit{CCLA = \# numero metodi} -% \subparagraph{Risultato} -% Il risultato della formula ha i seguenti significati: -% \begin{itemize} -% \item se il risultato è pari a 0 allora la classe non esiste e/o non ha metodi che le appartengono; -% \item se il risultato è maggiore di 0 allora la classe esiste ed ha un numero finito di metodi. -% \end{itemize} -% \paragraph{QM-PROD-9 Complessità del metodo (CMET)} -% \subparagraph{Descrizione} -% La metrica CMET permette di valutare la complessità di ogni metodo rispetto la sua modificabilità, ossia permette di capire se un metodo è una \glock{maschera} o esegue azioni rilevanti. -% \subparagraph{Unità di Misura} -% La metrica è espressa tramite un numero reale. -% \subparagraph{Formula} -% La formula della metrica è la seguente: -% \( -% CMET = \frac{\# linee codice}{\# chiamate interne ad altri metodi+1} -% \) -% \subparagraph{Risultato} -% Il risultato della formula ha i seguenti significati: -% \begin{itemize} -% \item se il risultato è pari a 0 allora il metodo non esiste e/o non è stato implementato; -% \item se il risultato è maggire di 0 allora il metodo è stato implementato ed potrebbe effettuare chiamate interne. -% \end{itemize} -% Più è alto il risultato meno è la complessità del metodo. -% -% \subsubsection{QC-1 Comprensione} -% \paragraph{Scopo} -% Per fornire una documentazione fruibile e comprensibile si è deciso di monitorare la sua qualità tramite delle metriche significative. -% \paragraph{Introduzione alle Metriche} -% Per la funzionabilità si é deciso di utilizzare le seguenti metriche: -% \begin{itemize} -% \item QM-PROD-10 Indice di Gulpease (GULP); -% \item QM-PROD-11 Correttezza ortografica (CORT). -% \end{itemize} -% \paragraph{QM-PROD-10 Indice di Gulpease (GULP)} -% \subparagraph{Descrizione} -% La metrica GULP permette di misurare la leggibilità di un documento basandosi su alcuni criteri. -% \subparagraph{Unità di Misura} -% La metrica è espressa tramite un numero intero. -% \subparagraph{Formula} -% La formula della metrica è la seguente: -% \( -% GULP = 89+\frac{300\times\# frasi-10\times\#lettere}{\#parole} -% \) -% \subparagraph{Risultato} -% Il risultato della formula ha i seguenti significati: -% \begin{itemize} -% \item se il risultato è pari 0 allora il documento non esiste e/o la sua leggibilità è terribile; -% \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} -% \paragraph{M-PROD-11 Correttezza ortografica (CORT)} -% \subparagraph{Descrizione} -% La metrica CORT permette di misurare la correttezza, a livello lessicografico, di un documento. -% \subparagraph{Unità di Misura} -% La metrica è espressa tramite un numero intero. -% \subparagraph{Formula} -% La formula della metrica è la seguente: -% \textit{CORT = \# numero di errori ortografici} -% \subparagraph{Risultato} -% Il risultato della formula ha i seguenti significati: -% \begin{itemize} -% \item se il risultato è pari 0 allora il documento non esiste o non ha errori ortografici; -% \item se il risultato è maggiore di 0 allora il documento esiste e presenta errori ortografici. -% \end{itemize} -% + + \subsubsection{Strumenti} + + Non sono stati identificati degli strumenti particolari per la garanzia di qualità. + + %ndr: da modificare + + + +% ---------------------------------------------------------------------- + + \subsubsection{Elenco delle metriche} + + Per ciascuna attività, sia che riguardi la documentazione, il software o il monitoraggio di processo, si riporta nella relativa sezione una classificazione delle metriche di qualità. + + \subsubsection{QP-1 Gestione delle Risorse} + + \paragraph{Scopo} + + Si vuole gestire la copertura di risorse disponibili per la realizzazione del progetto, monitorando i costi aggiuntivi e le tempistiche non rispettate dalla schedulazione pianificata. Questo può essere utile al cliente per capire in fase di sviluppo l'andamento del progetto a livello di gestione delle risorse. + + \paragraph{Introduzione alle Metriche} + + Per la gestione delle risorse si farà uso delle seguenti metriche: + + \begin{itemize} + \item QM-PROC-1. Budgeted Cost of Work Scheduled (BCWS); + \item QM-PROC-2. Actual Cost of Work Performed (ACWP); + \item QM-PROC-3. Budgeted Cost of Work Performed (BCWP); + \item QM-PROC-4. Schedule Variance (SV); + \item QM-PROC-5. Cost Variance (CV). + \end{itemize} + + \paragraph{QM-PROC-1. Budgeted Cost of Work Scheduled (BCWS)} + + \subparagraph{Descrizione} + La metrica BCWS definisce il costo pianificato per realizzare le attività di progetto alla data corrente. + + \subparagraph{Unità di Misura} + Il costo pianificato è misurato in EURO. + + \paragraph{QM-PROC-2. Actual Cost of Work Performed (ACWP)} + + \subparagraph{Descrizione} + La metrica ACWP definisce il costo effettivamente sostenuto per realizzare le attività di progetto alla data corrente. + + \subparagraph{Unità di Misura} + Il costo sostenuto è misurato in EURO. + + \paragraph{QM-PROC-3. Budgeted Cost of Work Performed (BCWP)} + + \subparagraph{Descrizione} + La metrica BCWP definisce il valore delle attività realizzate alla data corrente. In altre parole, misura il valore del prodotto fino ad ora realizzato. + + \subparagraph{Unità di Misura} + Il valore del prodotto è misurato in EURO. + + \paragraph{QM-PROC-4. Schedule Variance (SV)} + + \subparagraph{Descrizione} + La metrica SV indica se si è in anticipo, in ritardo o in linea rispetto alle schedulazioni pianificate per il progetto. Questo può essere utile per il cliente per valutare l'efficacia del gruppo nei confronti della realizzazione del progetto. + + \subparagraph{Unità di Misura} + La metrica viene espressa in percentuale. + + \subparagraph{Formula} + La formula per il calcolo della metrica è la seguente: + + \[ + \text{SV} = \frac{\text{BCWP} - \text{BCWS}}{\text{BCWS}} \times 100 + \] + + \subparagraph{Risultato} + \begin{itemize} + \item Un risultato \textbf{positivo} (\(> 0\)) indica che il progetto è avanti rispetto alla schedulazione; + \item Un risultato \textbf{negativo} (\(< 0\)) indica che il progetto è indietro rispetto alla schedulazione; + \item Un risultato \textbf{pari a zero} indica che il progetto è in linea rispetto alla schedulazione. + \end{itemize} + + \paragraph{QM-PROC-5. Cost Variance (CV)} + + \subparagraph{Descrizione} + La metrica CV indica se il valore del costo realmente maturato è maggiore, minore o uguale rispetto al costo effettivo. In altre parole, permette di comprendere con che livello di efficienza il gruppo sta sviluppando il progetto, rispetto a quanto pianificato. + + \subparagraph{Unità di Misura} + La metrica viene espressa in percentuale. + + \subparagraph{Formula} + La formula per il calcolo della metrica è la seguente: + + \[ + \text{CV} = \frac{\text{BCWP} - \text{ACWP}}{\text{BCWP}} \times 100 + \] + + \subparagraph{Risultato} + \begin{itemize} + \item Un risultato \textbf{positivo} (\(> 0\)) indica che il progetto sta sviluppando con un costo minore rispetto a quanto pianificato (maggiore efficienza); + \item Un risultato \textbf{negativo} (\(< 0\)) indica che il progetto sta sviluppando con un costo maggiore rispetto a quanto pianificato (minore efficienza); + \item Un risultato \textbf{pari a zero} indica che il progetto sta sviluppando con un costo in linea rispetto a quello pianificato. + \end{itemize} + + \subsubsection{QP-2 Gestione dei Rischi} + + \paragraph{Scopo} + + Si vuole monitorare i rischi che possono incorrere durante lo svolgimento del progetto, dalla loro scoperta fino alla loro risoluzione. + + \paragraph{Introduzione alle Metriche} + + Per la gestione dei rischi si farà uso delle seguenti metriche: + + \begin{itemize} + \item QM-PROC-6. Unbudgeted Risks (UR) + \end{itemize} + + \paragraph{QM-PROC-6. Unbudgeted Risks (UR)} + + \subparagraph{Descrizione} + La metrica UR viene utilizzata per tracciare in modo incrementale tutti i nuovi rischi non precedentemente preventivati che avvengono durante una fase del progetto. + + \subparagraph{Unità di Misura} + La metrica viene espressa con un valore intero che parte da 0. + + \subparagraph{Formula} + Per ogni rischio non preventivato e non individuato precedentemente che viene viene rilevato, si incrementa di una unità il numero di rischi rilevati fino alla data corrente, a partire da una fase del progetto. + La formula della metrica è la seguente: + \[ + \text{UR} = \text{UR} + 1 + \] + + \subparagraph{Risultato} + \begin{itemize} + \item Un valore pari a 0, indica che non sono stati trovati rischi nella fase del progetto; + \item Un valore superiore a 0, indica che sono stati trovati rischi nella fase del progetto. + \end{itemize} + + \subsubsection{QP-3 Analisi dei Requisiti} + + \paragraph{Scopo} + + Si vuole monitorare l'avanzamento dello sviluppo dei requisiti illustrati nel documento di \dext{Analisi dei Requisiti v1.0.0}. Questo può essere utile al cliente, per comprendere la percentuale di completamento del progetto nel corso del tempo. + + \paragraph{Introduzione alle Metriche} + + Per la gestione dei rischi si farà uso delle seguenti metriche: + + \begin{itemize} + \item QM-PROC-7. Satisfied Mandatory Requirements (SMR); + \item QM-PROC-8. Satisfied Desirable Requirements (SDR); + \item QM-PROC-9. Satisfied Optional Requirements (SOR). + \end{itemize} + + \paragraph{QM-PROC-7. Satisfied Mandatory Requirements (SMR)} + + \subparagraph{Descrizione} + La metrica SMR indica il quantitativo di requisiti obbligatori soddisfatti (progettati, sviluppati, verificati e validati) fino alla data corrente. Questa metrica permette sia al gruppo, che al cliente, di comprendere la percentuale di completamento del progetto. + + \subparagraph{Unità di Misura} + La metrica viene espressa in percentuale. + + \subparagraph{Formula} + La formula della metrica è la seguente: + \[ + \text{SMR} = \frac{\text{requisiti obbligatori soddisfatti}}{\text{requisiti obbligatori totali}} \times 100 + \] + + \subparagraph{Risultato} + \begin{itemize} + \item Un risultato pari a 0\% indica indica che non è stato soddisfatto ancora alcun requisito obbligatorio; + \item Un risultato pari a 100\% indica che sono stati soddisfatti tutti i requisiti obbligatori. + \end{itemize} + + \paragraph{QM-PROC-8. Satisfied Desirable Requirements (SDR)} + + \subparagraph{Descrizione} + La metrica SDR indica il quantitativo di requisiti desiderabili soddisfatti (progettati, sviluppati, verificati e validati) fino alla data corrente. + + \subparagraph{Unità di Misura} + La metrica viene espressa in percentuale. + + \subparagraph{Formula} + La formula della metrica è la seguente: + \[ + \text{SDR} = \frac{\text{requisiti desiderabili soddisfatti}}{\text{requisiti desiderabili totali}} \times 100 + \] + + \subparagraph{Risultato} + \begin{itemize} + \item Un risultato pari a 0\% indica indica che non è stato soddisfatto ancora alcun requisito desiderabile; + \item Un risultato pari a 100\% indica che sono stati soddisfatti tutti i requisiti desiderabili. + \end{itemize} + + \paragraph{QM-PROC-9. Satisfied Optional Requirements (SOR)} + + \subparagraph{Descrizione} + La metrica SDR indica il quantitativo di requisiti desiderabili soddisfatti (progettati, sviluppati, verificati e validati) fino alla data corrente. + + \subparagraph{Unità di Misura} + La metrica viene espressa in percentuale. + + \subparagraph{Formula} + La formula della metrica è la seguente: + \[ + \text{SOR} = \frac{\text{requisiti opzionali soddisfatti}}{\text{requisiti opzionali totali}} \times 100 + \] + + \subparagraph{Risultato} + \begin{itemize} + \item Un risultato pari a 0\% indica indica che non è stato soddisfatto ancora alcun requisito opzionale; + \item Un risultato pari a 100\% indica che sono stati soddisfatti tutti i requisiti opzionali. + \end{itemize} + + \subsubsection{QP-4. Verifica del Software} + + \paragraph{Scopo} + + Durante tutta la fase di sviluppo, si vuole monitorare il processo di Verifica del Software mettendo in luce aspetti che riguardano la complessità e la copertura di test a livello di codice. Questo può essere utile per il cliente e per il gruppo per comprendere l'avanzamento delle attività di verifica del software fino alla data attuale. + + \paragraph{Introduzione alle Metriche} + + Per la Verifica del Software si farà uso delle seguenti metriche: + + \begin{itemize} + + \item QM-PROC-10. Branch Coverage (BCOV); + \item QM-PROC-11. Condition Coverage (COCOV); + \item QM-PROC-12. Statement Coverage (SCOV); + \item QM-TEST-13. Passed Test Cases Percentage (PTCP); + \item QM-TEST-14. Failed Test Cases Percentage (FTCP); + \item QM-TEST-15. Bug-Fixing Percentage (BFP); + \item QM-TEST-16. Test Effectiveness (TE). + \end{itemize} + + \paragraph{QM-PROC-10. Branch Coverage (BCOV)} + + \subparagraph{Descrizione} + La metrica BC viene utilizzata per assicurare l'esecuzione di ogni possibile ramo (branch) decisionale del programma almeno una volta. Questo permette di comprendere quali rami decisionali non vengono effettivamente eseguiti e testati. + + \subparagraph{Unità di Misura} + La metrica viene espressa in percentuale. + + \subparagraph{Formula} + La formula della metrica è la seguente: + \[ + \text{BCOV} = \frac{\text{Numero di rami eseguiti}}{\text{Numero totale di rami}} \times 100 + \] + + \subparagraph{Risultato} + \begin{itemize} + \item Se il risultato è pari a 0\%, la copertura è nulla. + \item Se il risultato è pari al 100\%, la copertura è totale. + \item Se il risultato è maggiore di 0\%, ma minore di 100\%, la copertura è parziale. + \end{itemize} + + \paragraph{QM-PROC-11. Condition Coverage (COCOV)} + + \subparagraph{Descrizione} + La metrica CC verifica che ogni condizione di tipo booleano realizzata con gli operatori logici venga considerata sia vera che falsa. Questo permette di avere una migliore sensibilità sul controllo di flusso del programma. + + \subparagraph{Unità di Misura} + La metrica viene espressa in percentuale. + + \subparagraph{Formula} + La formula della metrica è la seguente: + \[ + \text{COCOV} = \frac{\text{Numero di operandi eseguiti}}{\text{Numero totale di operandi}} \times 100 + \] + + \subparagraph{Risultato} + \begin{itemize} + \item Se il risultato è pari a 0\%, la copertura è nulla. + \item Se il risultato è pari al 100\%, la copertura è totale. + \item Se il risultato è maggiore di 0\%, ma minore di 100\%, la copertura è parziale. + \end{itemize} + + + \paragraph{QM-PROC-12. Statement Coverage (SCOV)} + + \subparagraph{Descrizione} + La metrica SC viene utilizzata per calcolare e misurare il numero di statement che possono essere eseguiti, posto un determinato input. L'obiettivo è quello di riuscire a coprire tramite i test il maggior numero di statement, rispetto a quelli totali. + + \subparagraph{Unità di Misura} + La metrica viene espressa in percentuale. + + \subparagraph{Formula} + La formula della metrica è la seguente: + \[ + \text{SCOV} = \frac{\text{Numero di statement eseguiti}}{\text{Numero totale di statement}} \times 100 + \] + + \subparagraph{Risultato} + \begin{itemize} + \item Se il risultato è pari a 0\%, la copertura è nulla. + \item Se il risultato è pari al 100\%, la copertura è totale. + \item Se il risultato è maggiore di 0\%, ma minore di 100\%, la copertura è parziale. + \end{itemize} + + \paragraph{QM-TEST-1. Passed Test Cases Percentage (PTCP)} + + \subparagraph{Descrizione} + La metrica PTCP si utilizza per misurare la percentuale di test passati con successo in una specifica fase del progetto fino alla data corrente. + + \subparagraph{Unità di Misura} + La metrica viene espressa in percentuale. + + \subparagraph{Formula} + La formula della metrica è la seguente: + \[ + \text{PTCP} = \frac{\text{Numero di test passati}}{\text{Numero totale di test eseguiti}} \times 100 + \] + + \subparagraph{Risultato} + \begin{itemize} + \item Se il risultato è pari a 0\%, nessun test realizzato per il software è andato a buon fine; + \item Se il risultato è pari al 100\%, tutti i test realizzati per il software sono andati a buon fine; + \item Se il risultato è compreso tra 0\% e 100\%, non tutti i test realizzati per il software sono andati a buon fine. + \end{itemize} + + \paragraph{QM-TEST-2. Failed Test Cases Percentage (FTCP)} + + \subparagraph{Descrizione} + La metrica FTCP viene usata per misurare la percentuale di test falliti in una specifica fase del progetto fino alla data corrente. + + \subparagraph{Unità di Misura} + La metrica viene espressa in percentuale. + + \subparagraph{Formula} + La formula della metrica è la seguente: + \[ + \text{FTCP} = \frac{\text{Numero di test falliti}}{\text{Numero totale di test eseguiti}} \times 100 + \] + + \subparagraph{Risultato} + \begin{itemize} + \item Se il risultato è pari a 0\%, non ci sono test realizzati per il software che sono falliti; + \item Se il risultato è pari al 100\%, tutti i test realizzati per il software sono falliti; + \item Se il risultato è compreso tra 0\% e 100\%, non tutti i test realizzati per il software sono andati a buon fine. + \end{itemize} + + \paragraph{QM-TEST-3. Bug-Fixing Percentage (BFP)} + + \subparagraph{Descrizione} + La metrica BFP si utilizza per misurare il quantitativo di errori corretti nel codice rispetto agli errori trovati fino alla data corrente. + + \subparagraph{Unità di Misura} + La metrica viene espressa in percentuale. + + \subparagraph{Formula} + La formula della metrica è la seguente: + \[ + \text{BFP} = \frac{\text{Numero di difetti corretti}}{\text{Numero di difetti trovati}} \times 100 + \] + + \subparagraph{Risultato} + \begin{itemize} + \item Se il risultato è pari a 0\%, nessun difetto è stato risolto; + \item Se il risultato è pari al 100\%, tutti i difetti sono stati risolti; + \item Se il risultato è compreso tra 0\% e 100\%, non tutti i difetti sono stati corretti. + \end{itemize} + + \paragraph{QM-TEST-4. Test Effectiveness (TE)} + + \subparagraph{Descrizione} + La metrica TE si utilizza per misurare l'efficacia con cui si trovano dei difetti attraverso i test. + + \subparagraph{Unità di Misura} + La metrica viene espressa in percentuale. + + \subparagraph{Formula} + La formula della metrica è la seguente: + \[ + \text{TE} = \frac{\text{Difetti trovati con i test}}{\text{Numero totale di difetti trovati}} \times 100 + \] + + \subparagraph{Risultato} + \begin{itemize} + \item Se il risultato è pari a 0\%, nessun difetto è stato risolto; + \item Se il risultato è pari al 100\%, tutti i difetti sono stati risolti; + \item Se il risultato è compreso tra 0\% e 100\%, non tutti i difetti sono stati corretti. + \end{itemize} + + \subsubsection{QC-1 Funzionabilità} + \paragraph{Scopo} + Durante lo sviluppo si vuole monitorare la capacità del prodotto di soddisfare tutti i requisiti richiesti dall'utente. + \paragraph{Introduzione alle Metriche} + Per la funzionabilità si é deciso di utilizzare la seguente metrica: + \begin{itemize} + \item QM-PROD-1 Implementazione (IMP). + \end{itemize} + \paragraph{QM-PROD-1 Implementazione (IMP)} + \subparagraph{Descrizione} + La metrica IMP si utilizza per valutare l'avanzamento dello sviluppo delle funzionalità richieste. + \subparagraph{Unità di Misura} + La metrica è espressa in percentuale. + \subparagraph{Formula} + La formula della metrica è la seguente: + \( + IMP = \frac{\# funzionalita implementate}{\# funzionalita proposte}\times100 + \) + \subparagraph{Risultato} + Il risultato della formula ha i seguenti significati: + \begin{itemize} + \item se il risultato è pari a 0\%, allora nessuna funzionalità è stata implementata; + \item se il risultato è compreso tra 0\% e 100\%, allora parte delle funzionalità sono state implementate; + \item se il risultato è pari a 100\%, allora tutte le funzionalità sono state implementate. + \end{itemize} + + \subsubsection{QC-2 Affidabilità} + \paragraph{Scopo} + Durante lo sviluppo si vuole monitorare l'affidabilità e correttezza, così come la sua tolleranza agli errori. + \paragraph{Introduzione alle Metriche} + Per l'affidabilità si é deciso di utilizzare le seguenti metriche: + \begin{itemize} + \item QM-PROD-2 Densità errori (DE); + \item QM-PROD-3 Complessità dei test di classe (CTCLA). + \end{itemize} + \paragraph{ QM-PROD-2 Densità errori (DE)} + \subparagraph{Descrizione} + La metrica DE permette di misurare in maniera precisa la tolleranza e correttezza di ogni componente del prodotto, mostrando attraverso una percentuale la sua stabilità. + \subparagraph{Unità di Misura} + La metrica è espressa in percentuale. + \subparagraph{Formula} + La formula della metrica è la seguente: + \(DE = \frac{\# test passati}{\# test condotti}\times100\) + \subparagraph{Risultato} + Il risultato della formula ha i seguenti significati: + \begin{itemize} + \item se il risultato è pari a 0\%, allora il prodotto non è stato testato o ha fallito i test al quale è stato sottoposto; + \item se il risultato è compreso tra 0\%, e 100\%, allora parte del prodotto è stato testato e/o il prodotto ha passato parte dei test; + \item se il risultato è pari a 100\%, allora tutte le parti sono state testate e il prodotto ha passato tutti i test. + \end{itemize} + \paragraph{QM-PROD-3 Complessità dei test di classe (CTCLA)} + \subparagraph{Descrizione} + La metrica CTCLA trova il suo utilizzo nel monitoraggio dei test che coinvolgono il prodotto e le sue componenti. Essa permette di sapere se ci sono componenti non testate. + \subparagraph{Unità di Misura} + La metrica è espressa tramite un numero intero. + \subparagraph{Formula} + La formula della metrica è la seguente: + \textit{CTCLA = \# dei test che coinvolgono la classe} + \subparagraph{Risultato} + Il risultato della formula ha i seguenti significati: + \begin{itemize} + \item se il risultato è pari a 0, allora il prodotto o componente non è stato incluso in alcun test; + \item se il risultato è maggiore di 0, allora il prodotto o componente è stato incluso in almeno un test. + \end{itemize} + + \subsubsection{QC-3 Efficienza} + \paragraph{Scopo} + È necessari misurare l'efficienza del prodotto in modo da fornire all'utente un software usabile, piacevole e veloce. + \paragraph{Introduzione alle Metriche} + Per l'efficienza si è deciso di utilizzare la seguente metrica: + \begin{itemize} + \item QM-PROD-4 Risposta media (RM). + \end{itemize} + \paragraph{QM-PROD-4 Risposta media (RM)} + \subparagraph{Descrizione} + La metrica RM punta a misurare l'efficienza di elaborazione del prodotto in modo da fornire all'utente un'esperienza piacevole di utilizzo. + \subparagraph{Unità di Misura} + La metrica è espressa millisecondi (\textit{ms}) + \subparagraph{Formula} + La formula della metrica è la seguente: + \( + RM = \frac{\sum_{n=1}^{z} tempo di risposta in ms}{z} + \) + dove $z$ è il numero di misurazioni effettuate. + \subparagraph{Risultato} + Il risultato della formula ha i seguenti significati: + \begin{itemize} + \item se il risultato è indica il tempo di risposta medio del prodotto. + \end{itemize} + + \subsubsection{QC-4 Usabilità} + \paragraph{Scopo} + Si vuole misurare l'usabilità del prodotto in modo da fornire all'utente un'esperienza piacevole durante il suo utilizzo, nonché fornire un prodotto facile da apprendere ed utilizzare. + \paragraph{Introduzione alle Metriche} + Per la funzionabilità si é deciso di utilizzare le seguenti metriche: + \begin{itemize} + \item QM-PROD-5 Profondità dell'albero delle azioni (PAA); + \item QM-PROD-6 Profondità dell'albero delle pagine (PAP). + \end{itemize} + \paragraph{QM-PROD-5 Profondità dell'albero delle azioni (PAA)} + \subparagraph{Descrizione} + La metrica PAA permette di misurare l'operabilità e la comprensibilità del prodotto da parte dell'utente. Essa misura il numero di azioni effettuate dall'utente prima di poter arrivare al suo obbiettivo. + \subparagraph{Unità di Misura} + La metrica è espressa tramite un numero intero. + \subparagraph{Formula} + La formula della metrica è la seguente: + \textit{PAA = \# delle azioni} + dove ogni click corrisponde ad un'azione. + \subparagraph{Risultato} + Il risultato della formula ha i seguenti significati: + \begin{itemize} + \item se il risultato è pari 0 allora l'obbiettivo non è raggiungibile e/o l'utente non ne ha accesso; + \item se il risultato è maggiore di 0 allora l'obbiettivo è raggiungibile in un numero finito di azioni. + \end{itemize} + \paragraph{QM-PROD-6 Profondità dell'albero delle pagine (PAP)} + \subparagraph{Descrizione} + La metrica PAP permette di misurare l'apprendibilità, l'operabilità e l'attrattiva del prodotto dal punto di vista del cliente. Essa misura il numero di pagine visitate dall'utente prima di poter arrivare al suo obbiettivo. + \subparagraph{Unità di Misura} + La metrica è espressa tramite un numero intero. + \subparagraph{Formula} + La formula della metrica è la seguente: + \textit{PAP = \# delle pagine visitate dall'utente} + \subparagraph{Risultato} + Il risultato della formula ha i seguenti significati: + \begin{itemize} + \item se il risultato è pari a 0 allora la pagina obbiettivo non esiste o l'utente non ne ha accesso; + \item se il risultato è maggiore di 0 allora la pagina obbiettivo è raggiungibile in un numero finito di passaggi. + \end{itemize} + + \subsubsection{QC-5 Manutenibilità} + \paragraph{Scopo} + La manutenibilità viene monitorata in modo da fornire un prodotto modificabile ed estendibile, in modo da poter estendere facilmente sia la vita del prodotto che le sue funzionalità. + \paragraph{Introduzione alle Metriche} + Per la funzionabilità si é deciso di utilizzare le seguenti metricche: + \begin{itemize} + \item QM-PROD-QM-PROD-7 Complessità del codice (CCOD); + \item QM-PROD-8 Complessità della classe (CCLA); + \item QM-PROD-9 Complessità del metodo (CMET). + \end{itemize} + \paragraph{QM-PROD-7 Complessità del codice (CCOD)} + \subparagraph{Descrizione} + La metrica CCOD permette di misurare la chiarezza dei commenti rispetto la lunghezza del codice scritto. + \subparagraph{Unità di Misura} + La metrica è espressa tramite un numero reale. + \subparagraph{Formula} + La formula della metrica è la seguente: + \( + CCOD = \frac{\# linee commento}{\# linee codice} + \) + \subparagraph{Risultato} + Il risultato della formula ha i seguenti significati: + \begin{itemize} + \item se il risultato è pari a 0, allora il codice non è stato commentato; + \item se il risultato è maggiore di 0, allora il codice ha almeno una riga di commento. + \end{itemize} + \paragraph{QM-PROD-8 Complessità della classe (CCLA)} + \subparagraph{Descrizione} + La metrica CCLA misure il numero di metodi presenti in ogni classe e permette di valutare la complessità generale della stessa. + \subparagraph{Unità di Misura} + La metrica è espressa tramite un numero intero. + \subparagraph{Formula} + La formula della metrica è la seguente: + \textit{CCLA = \# numero metodi} + \subparagraph{Risultato} + Il risultato della formula ha i seguenti significati: + \begin{itemize} + \item se il risultato è pari a 0, allora la classe non esiste e/o non ha metodi che le appartengono; + \item se il risultato è maggiore di 0, allora la classe esiste ed ha un numero finito di metodi. + \end{itemize} + \paragraph{QM-PROD-9 Complessità del metodo (CMET)} + \subparagraph{Descrizione} + La metrica CMET permette di valutare la complessità di ogni metodo rispetto la sua modificabilità, ossia permette di capire se un metodo è una \glock{maschera} o esegue azioni rilevanti. + \subparagraph{Unità di Misura} + La metrica è espressa tramite un numero reale. + \subparagraph{Formula} + La formula della metrica è la seguente: + \( + CMET = \frac{\# linee codice}{\# chiamate interne ad altri metodi+1} + \) + \subparagraph{Risultato} + Il risultato della formula ha i seguenti significati: + \begin{itemize} + \item se il risultato è pari a 0, allora il metodo non esiste e/o non è stato implementato; + \item se il risultato è maggire di 0, allora il metodo è stato implementato ed potrebbe effettuare chiamate interne. + \end{itemize} + Più è alto il risultato meno è la complessità del metodo. + + \subsubsection{QC-1 Comprensione} + \paragraph{Scopo} + Per fornire una documentazione fruibile e comprensibile si è deciso di monitorare la sua qualità tramite delle metriche significative. + \paragraph{Introduzione alle Metriche} + Per la funzionabilità si é deciso di utilizzare le seguenti metriche: + \begin{itemize} + \item QM-PROD-10 Indice di Gulpease (GULP); + \item QM-PROD-11 Correttezza ortografica (CORT). + \end{itemize} + \paragraph{QM-PROD-10 Indice di Gulpease (GULP)} + \subparagraph{Descrizione} + La metrica GULP permette di misurare la leggibilità di un documento basandosi su alcuni criteri. + \subparagraph{Unità di Misura} + La metrica è espressa tramite un numero intero. + \subparagraph{Formula} + La formula della metrica è la seguente: + \( + GULP = 89+\frac{300\times\# frasi-10\times\#lettere}{\#parole} + \) + \subparagraph{Risultato} + Il risultato della formula ha i seguenti significati: + \begin{itemize} + \item se il risultato è pari 0, allora il documento non esiste e/o la sua leggibilità è terribile; + \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} + \paragraph{M-PROD-11 Correttezza ortografica (CORT)} + \subparagraph{Descrizione} + La metrica CORT permette di misurare la correttezza, a livello lessicografico, di un documento. + \subparagraph{Unità di Misura} + La metrica è espressa tramite un numero intero. + \subparagraph{Formula} + La formula della metrica è la seguente: + \textit{CORT = \# numero di errori ortografici} + \subparagraph{Risultato} + Il risultato della formula ha i seguenti significati: + \begin{itemize} + \item se il risultato è pari 0, allora il documento non esiste o non ha errori ortografici; + \item se il risultato è maggiore di 0, allora il documento esiste e presenta errori ortografici. + \end{itemize} diff --git a/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/ProcDiRisoluzioneDeiProblemi.tex b/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/GestCambiamenti.tex similarity index 60% rename from interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/ProcDiRisoluzioneDeiProblemi.tex rename to interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/GestCambiamenti.tex index 6eb6305..96a3da8 100644 --- a/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/ProcDiRisoluzioneDeiProblemi.tex +++ b/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/GestCambiamenti.tex @@ -1,9 +1,9 @@ -\subsection{Processo di risoluzione dei problemi} +\subsection{Gestione dei cambiamenti} - 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. + Il processo di gestione dei cambiamenti 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 è 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 gestione dei cambiamenti è 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: @@ -14,16 +14,16 @@ \subsection{Processo di risoluzione dei problemi} \end{itemize} \subsubsection{Attività} \paragraph{Implementazione del processo} - Il processo di risoluzione dei problemi dovrà essere istanziato ogni volta che sarà necessario gestire un problema e dovrà soddisfare i seguenti requisiti: + Il processo di gestione dei cambiamenti dovrà essere istanziato ogni volta che sarà necessario gestire un problema e dovrà soddisfare i seguenti requisiti: \begin{enumerate} - \item Il processo dovrà essere un ciclo chiuso, assicurandosi che: + \item il processo dovrà essere un ciclo chiuso, assicurandosi che: \begin{itemize} - \item tutti i problemi rilevati dovranno essere prontamente riportati ed immessi nel Processo di risoluzione dei problemi; + \item tutti i problemi rilevati dovranno essere prontamente riportati ed immessi nel processo di gestione dei cambiamenti; \item dovranno essere avvisate le parti interessate; - \item le cause dovranno essere identificate, analizzate e nel limite del possibile rimosse. + \item le cause dovranno essere identificate, analizzate e nel limite del possibile rimosse; \end{itemize} - \item Il processo utilizzerà uno schema per categorizzare e dare la giusta priorità ai problemi scovati; + \item il processo utilizzerà uno schema per categorizzare e dare la giusta priorità ai problemi scovati; \begin{center} \rowcolors{2}{lightest-grayest}{white} @@ -38,22 +38,26 @@ \subsection{Processo di risoluzione dei problemi} \end{longtable} \end{center} - La priorità potrà avere i seguenti valori: + la priorità potrà avere i seguenti valori: \begin{itemize} - \item \textbf{A}, richiedendo quindi una tempestiva risoluzione; - \item \textbf{B}, per problemi la cui risoluzione potrebbe aggravarsi nel tempo; - \item \textbf{C}, se il problema ha una possibilità molto ridotta di aggravarsi o provocare altri problemi. + \item \textbf{A:} richiedendo quindi una tempestiva risoluzione; + \item \textbf{B:} per problemi la cui risoluzione potrebbe aggravarsi nel tempo; + \item \textbf{C:} se il problema ha una possibilità molto ridotta di aggravarsi o provocare altri problemi; \end{itemize} - La tipologia avrà invece i seguenti valori: + la tipologia avrà invece i seguenti valori: \begin{itemize} - \item \textbf{O}, per i problemi ortografici; - \item \textbf{C}, per problemi legati al contenuto. + \item \textbf{O:} per i problemi ortografici; + \item \textbf{C:} per problemi legati al contenuto; \end{itemize} - L'identificativo sarà un numero progressivo a partire da 1. + l'identificativo sarà un numero progressivo a partire da 1; - \item Verranno effettuate delle analisi per verificare la presenza di tendenze nei problemi riportati; + \item verranno effettuate delle analisi per verificare la presenza di tendenze nei problemi riportati; - \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. + \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 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. + \subsubsection{Strumenti} + \paragraph{GitHub} + Per creare report si è deciso di utilizzare l'ITS fornito da \glock{GitHub}, in quanto fornisce anche un sistema di versionamento ed è conosciuto da tutti i membri del gruppo. + Questo ITS fornisce inoltre la possibilità di collegare i commit del cambiamento con la issue legata al report, in modo tale da poter tracciare tutto il percorso dala modifica alla risoluzione del problema. diff --git a/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/GestConfigurazione.tex b/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/GestConfigurazione.tex index c3a402e..8f67398 100644 --- a/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/GestConfigurazione.tex +++ b/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/GestConfigurazione.tex @@ -1,98 +1,47 @@ -\subsection{Gestione della Configurazione} +\subsection{Gestione della configurazione} % Inizio gestione della configurazione \subsubsection{Scopo} -La gestione della configurazione definisce i principi normativi utili a predisporre il \glock{workspace} per tutto il gruppo, semplificando e automatizzando la conservazione dei documenti e del software. +La gestione della configurazione definisce i principi normativi utili a predisporre il \glock{workspace} per tutto il gruppo, semplificando e automatizzando la conservazione dei documenti e delle componenti software, che andranno a formare il prodotto finale. -\subsubsection{Repository} +\subsubsection{Aspettative} -La repository è un luogo remoto in cui vengono mantenuti, salvati e versionati tutti i file che riguardano il progetto per tutto il ciclo di vita del prodotto. Questa risiede in modo condiviso all'interno di \glock{GitHub} ed è accessibile solamente ai membri del team. - - \paragraph{Integrazione di VCS e ITS con GitHub} - - La repository fa uso di un \textit{Version Control System} (VCS) di tipo distribuito sotto il motore \textit{Git}, che permette la condivisione dal locale al remoto del proprio spazio di lavoro su un luogo comune. Attraverso l'utilizzo di un web browser, è possibile collegarsi a \textit{GitHub} e controllare i file contenuti nella repository, usando come indirizzo web: - - \href{http://project.redroundrobin.site}{http://project.redroundrobin.site} - - Inoltre, \textit{GitHub} integra un \textit{Issue Tracking System} (ITS) che permette di tracciare lo sviluppo tramite ticketing, assegnando a ciascun membro del team una o più \glock{issue} in base alle necessità. - - \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 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: - \begin{itemize} - \item \verb!master! branch: branch principale su cui vengono fatti i rilasci ad ogni \glock{milestone}; - \item \verb!develop! branch: branch di sviluppo su cui viene fatta integrazione di nuove funzionalità concluse; - \item \verb!feature/xxxx! branch: branch indipendente usato da uno o più membri del gruppo per sviluppare una sezione o fare una revisione di un documento; - \begin{itemize} - \item \textbf{xxxx:} si riferisce al numero della \glock{issue} o al titolo della funzionalità da integrare. - \item il \textit{feature branch} riferisce generalmente una singola \glock{issue} ed è rimosso alla sua chiusura. - \end{itemize} - \end{itemize} - - Ad ogni milestone viene associata una release interna alla repository, così da tenere traccia di una \glock{baseline}. - - \paragraph{Formati dei File} - - \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, 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}; - \item \textbf{File senza formati} contengono configurazioni aggiuntive per \glock{GitHub} (es: template delle \glock{Issue}); - \end{itemize} - - \subparagraph{Documentazione} - - Per la documentazione si usano principalmente i seguenti tipi di file: - \begin{itemize} - \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} - - \subparagraph{Configurazione} - - La repository si compone di diverse tipologie di cartelle. Oltre alle cartelle che riguardano la documentazione e il software, è presente una cartella che viene usata ai fini della configurazione di \glock{GitHub}. - \begin{itemize} - \item \verb!.github/!: cartella per la repository di \glock{Github} con i file di configurazione per le \glock{Github Actions} e l'\glock{Issue Tracking System}. - \end{itemize} - - \subparagraph{Documentazione} - - La documentazione nella repository si compone di 4 cartelle principali: - \begin{itemize} - \item \verb!interni/!: contiene tutta la documentazione interna; - \item \verb!esterni/!: contiene tutta la documentazione esterna; - \item \verb!template/!: contiene tutti i template delle varie tipologie di documento; - \item \verb!notes/!: contiene tutte le note aggiuntive (\textit{non}-\LaTeX{}) sui seminari, le guide e l'organizzazione. - \end{itemize} +La gestione della configurazione si predispone a rendere usabile l'ambiente di lavoro, controllando attivamente e autonomamente tutte le attività in modo metodico e organizzato. Ciò è importante perché riduce la complessità di coordinamento nel corso dello sviluppo del prodotto, sia che riguardi la documentazione, sia che riguardi le componenti software. +\subsubsection{Descrizione} +Il processo di gestione della configurazione si compone di una serie di attività e strumenti atte a costituire un ambiente di lavoro semplice e ordinato. +In particolare, si fa uso dei seguenti strumenti: +\begin{itemize} + \item repository; + \item tecnologie impiegate. +\end{itemize} +Gli strumenti vengono utilizzati per svolgere le seguenti attività: +\begin{itemize} + \item versionamento e rilascio del prodotto; + \item versionamento e rilascio dei documenti; + \item versionamento e rilascio dei componenti software; + \item Continuous Integration; + \item notification \& monitoring; +\end{itemize} -\subsubsection{Versionamento e Rilascio} +\subsubsection{Attività} - \paragraph{Prodotto} + \paragraph{Versionamento e rilascio del prodotto} Il prodotto viene inteso come l'insieme di componenti che dovranno essere progettate, sviluppate, verificate e validate prima di essere consegnate al cliente. Il prodotto si compone principalmente di: \begin{itemize} \item documentazione; - \item software. + \item componenti software. \end{itemize} Ciascuna componente viene versionata seguendo la propria evoluzione, mentre nel caso del prodotto si segue un versionamento più macroscopico e basato sulle \glock{baseline}. Nell'ambito del progetto, il gruppo ha deciso di integrare una prassi di versionamento che permetta di avere un riferimento del prodotto dalle singole componenti sviluppate. - \subparagraph{Codice di Versionamento} + \subparagraph{Sintassi codice di versionamento} Per una versione del prodotto associato a una baseline si associa il seguente identificativo: @@ -101,32 +50,35 @@ \subsubsection{Versionamento e Rilascio} \] \begin{itemize} - \item \((\alpha)\): numero identificativo del rilascio del prodotto; + \item \((\alpha)\): numero identificativo del rilascio del prodotto \begin{itemize} \item parte da 0 e non si resetta mai; - \item viene incrementato quando tutte le componenti sono state concluse e pronte per la consegna al cliente. + \item viene incrementato quando tutte le componenti sono state concluse e pronte per la consegna al cliente; \end{itemize} - \item \((\beta)\): numero identificativo che viene associato a una baseline del prodotto; + \item \((\beta)\): numero identificativo che viene associato a una baseline del prodotto: \begin{itemize} - \item parte da 0 e si resetta quando \(\alpha\) viene incrementato; + \item parte da 0 e si resetta quando \(\alpha\) viene incrementato; \item viene incrementato quando si raggiunge una nuova baseline di prodotto. - \end{itemize} \end{itemize} - \subparagraph{Esempi Codice di Versionamento} + \subparagraph{Esempi di versionamento del prodotto} \begin{itemize} - \item \textbf{v0.5.1+b0.1}: indica la versione 0.5.1 di una componente proveniente dalla baseline di prodotto in versione 0.1 - \item \textbf{v1.13.1+b0.2}: indica la versione 1.12.1 di una componente proveniente dalla baseline di prodotto in versione 0.2 - \item \textbf{v3.0.2+b1.3}: indica la versione 3.0.2 di una componente proveniente dalla baseline di prodotto in versione 1.3 + \item \textbf{v0.5.1+b0.1}: indica la versione 0.5.1 di una componente proveniente dalla baseline di prodotto in versione 0.1; + \item \textbf{v1.13.1+b0.2}: indica la versione 1.12.1 di una componente proveniente dalla baseline di prodotto in versione 0.2; + \item \textbf{v3.0.2+b1.3}: indica la versione 3.0.2 di una componente proveniente dalla baseline di prodotto in versione 1.3. \end{itemize} - \paragraph{Documentazione} + \subparagraph{Rilascio} + + Il rilascio del prodotto viene effettuato nel momento in cui la prima cifra della versione viene incrementata. Ad essa si devono allineare tutte le altre componenti con delle versione approvate ed autorizzate per il rilascio. + + \paragraph{Versionamento e rilascio dei documenti} Tutti i file che riguardano la documentazione vengono conservati in una repository e ogni documento viene versionato per mezzo di un identificativo, in base alla loro fase di avanzamento. Questo permette di poter fare riferimento alle nuove versioni del documento durante tutto il ciclo di vita del software. - \subparagraph{Codice di Versionamento} + \subparagraph{Sintassi codice di versionamento} Ciascun documento possiede un identificativo di versionamento su ogni pagina che ha il seguente formalismo: @@ -135,50 +87,51 @@ \subsubsection{Versionamento e Rilascio} \] \begin{itemize} - \item \((\alpha)\): numero identificativo del rilascio del documento; - \begin{itemize} - \item parte da 0 e non si resetta mai; - \item viene incrementato solo dal responsabile a seguito di una approvazione. - \end{itemize} - \item \((\beta)\): numero identificativo che rappresenta un avanzamento sostanziale dopo le revisioni del documento; - \begin{itemize} - \item parte da 0 e si resetta solo a incrementi di \(\alpha\); - \item viene incrementato solo dai revisori. - \end{itemize} - \item \((\gamma)\): numero rappresentativo di una aggiunta, modifica o eliminazione fatta al documento - \begin{itemize} - \item parte da 0 e si resetta solo a incrementi di \(\beta\) o di \(\alpha\); - \item viene incrementato da un redattore o da un revisore in base alle necessità. - \end{itemize} + \item \((\alpha)\): numero identificativo del rilascio esterno del documento al proponente e/o al committente + \begin{itemize} + \item parte da 0 e non si resetta mai; + \item viene incrementato solo dal responsabile a seguito di una approvazione di rilascio del documento verso un destinatario esterno al team; + \end{itemize} + \item \((\beta)\): numero identificativo che rappresenta un'approvazione del documento + \begin{itemize} + \item parte da 0 e si resetta solo a incrementi di \(\alpha\); + \item viene incrementato solo dal responsabile a seguito del raggiungimento di una baseline se il prodotto è conforme; + \end{itemize} + \item \((\gamma)\): numero rappresentativo di una aggiunta o modifica verificata fatta al documento + \begin{itemize} + \item parte da 0 e si resetta solo a incrementi di \(\beta\) o di \(\alpha\); + \item viene incrementato da un revisore dopo aver verificato che una sezione sia conforme a quanto deciso. + \end{itemize} \end{itemize} - \subparagraph{Esempi Codice di Versionamento} + Generalmente ogni documento prima di poter essere rilasciato verso l'esterno dovrà essere stato approvato e rilasciato internamente. + + \subparagraph{Esempi codice di versionamento dei documenti} \begin{itemize} - \item \verb!v0.2.1! - \item \verb!v1.12.1! - \item \verb!v3.0.2! + \item \verb!v0.2.1!; + \item \verb!v1.12.1!; + \item \verb!v3.0.2!. \end{itemize} \subparagraph{Gestione delle modifiche} - Le modifiche ai documenti vengono gestite seguendo il \textbf{Registro delle Modifiche} presente in tutti i documenti nella pagina successiva al frontespizio. All'interno di questo documento si tiene traccia di ogni aggiunta, modifica, eliminazione, revisione o approvazione da parte di tutti i membri del team. La normativa sul formalismo può essere trovata al paragrafo \ref{par: Registro modifiche} a pagina \pageref{par: Registro modifiche}. + Le modifiche ai documenti vengono gestite seguendo il \textbf{registro delle modifiche} presente in tutti i documenti nella pagina successiva al frontespizio. All'interno di questo documento si tiene traccia di ogni aggiunta, modifica, eliminazione, revisione o approvazione da parte di tutti i membri del team. La normativa sul formalismo può essere trovata al paragrafo \ref{par: Registro modifiche} a pagina \pageref{par: Registro modifiche}. \subparagraph{Rilascio} Un documento viene rilasciato alle parti proponenti solamente quando vi è un incremento del primo numero (\(\alpha\)), che ne implica una approvazione da parte del responsabile. \\ Per quanto concerne la distribuzione interna, tutti gli \glock{artefatti} dei documenti realizzati durante la fase di sviluppo sono resi disponibili in modo rapido e automatizzato a tutti i membri del gruppo, a cui vengono notificate tutte le modifiche tramite il \glock{workspace} di \textit{Slack}. - \subparagraph{Integrazione con il Versionamento di Prodotto} + \subparagraph{Integrazione con il versionamento di prodotto} La documentazione viene interpretata come componente, e in quanto tale riceve come aggiunta al proprio codice di versionamento anche l'identificativo di prodotto. Questo identificativo aggiuntivo viene esplicitato solamente all'interno del documento e non nella denominazione dei file. - \paragraph{Software} + \paragraph{Versionamento e rilascio dei componenti software} I sorgenti del software che riguardano la codifica e la configurazione del prodotto da realizzare sono mantenuti nella repository, insieme alla documentazione. Ogni file viene versionato con un apposito storico delle modifiche, mentre ogni componente software viene versionata come \glock{baseline} di prodotto in relazione alle funzionalità presenti e dei requisiti obbligatori implementati. - - \subparagraph{Codice di Versionamento} + \subparagraph{Sintassi codice di versionamento} Il versionamento del software viene eseguito sulla base delle implementazioni effettuate a livello di codifica. In aggiunta, si definisce una sintassi di stato nella versione per definirne l'usabilità. @@ -188,36 +141,36 @@ \subsubsection{Versionamento e Rilascio} \] \begin{itemize} - \item \((\delta)\): numero identificativo del rilascio software per una \glock{major release}; + \item \((\delta)\): numero identificativo del rilascio software per una \glock{major release} \begin{itemize} \item parte da 0 e non si resetta mai; - \item viene incrementato solo dopo aver implementato tutti i requisiti obbligatori. + \item viene incrementato solo dopo aver implementato tutti i requisiti obbligatori; \end{itemize} - \item \((\epsilon)\): numero identificativo per una \glock{minor release}; + \item \((\epsilon)\): numero identificativo per una \glock{minor release} \begin{itemize} \item parte da 0 e si resetta solo a incrementi di \(\delta\); - \item viene incrementato solo dopo l'implementazione di uno o più requisiti. + \item viene incrementato solo dopo l'implementazione di uno o più requisiti; \end{itemize} - \item \((\mu)\): numero rappresentativo per una \glock{patch}; + \item \((\mu)\): numero rappresentativo per una \glock{patch} \begin{itemize} \item parte da 0 e si resetta solo a incrementi di \(\epsilon\) o di \(\delta\); - \item viene incrementato a ogni modifica di uno o più requisiti e ad ogni cambio di configurazione del software. + \item viene incrementato a ogni modifica di uno o più requisiti e ad ogni cambio di configurazione del software; \end{itemize} - \item \((\lambda)\): sigla che identifica uno stato del software; può avere i seguenti significati in ordine crescente di stato: + \item \((\lambda)\): sigla che identifica uno stato del software; può avere i seguenti significati in ordine crescente di stato \begin{itemize} - \item \verb!dev!: derivante da \textbf{dev}elopment, versione ancora in sviluppo. + \item \verb!dev!: derivante da \textbf{dev}elopment, versione ancora in sviluppo \begin{itemize} \item software non completo, che ha ricevuto aggiunte, modifiche o eliminazioni recenti; - \item può contenere errori che fanno fallire i test; - \item \textbf{non} si presta all'uso di un utente finale. + \item passa tutti i test sviluppati fino a quel momento; + \item \textbf{non} si presta all'uso di un utente finale, poiché incompleto nelle funzionalità sviluppate; \end{itemize} - \item \verb!rc!: \textbf{r}elease \textbf{c}andidate, versione candidata al rilascio; + \item \verb!rc!: \textbf{r}elease \textbf{c}andidate, versione candidata al rilascio \begin{itemize} \item software che contiene tutti o una parte dei requisiti obbligatori richiesti; \item passa tutte le tipologie di test; - \item si presta all'uso di un utente finale. + \item si presta all'uso di un utente finale; \end{itemize} - \item \verb!stable!: versione \textbf{stabile}, pronta al rilascio pubblico. + \item \verb!stable!: versione \textbf{stabile}, pronta al rilascio pubblico \begin{itemize} \item software completo che implementa tutti i requisiti obbligatori; \item passa tutte le tipologie di test ed è validato; @@ -226,71 +179,327 @@ \subsubsection{Versionamento e Rilascio} \end{itemize} \end{itemize} - Una versione del software subisce un incremento di stato in base alla verifica da parte del meccanismo automatico di \glock{test}. In particolare: + Una versione del software subisce un incremento di stato in base alla sua completezza in termini di funzionalità e requisiti soddisfatti. In particolare: \begin{itemize} \item una versione può ricevere lo stato di \verb!rc! solo se il primo numero (\(\delta\)) o il secondo numero (\(\epsilon\)) è diverso da 0; \item una versione può ricevere lo stato di \verb!stable! solo se il primo numero (\(\delta\)) è diverso da 0. \end{itemize} - \subparagraph{Esempi Codice di Versionamento} + \subparagraph{Esempi codice di versionamento} \begin{itemize} - \item \verb!v0.3.5-dev! : versione non completa, non usabile e forse funzionante; + \item \verb!v0.3.5-dev! : versione non completa, non usabile e in parte funzionante; \item \verb!v0.7.0-rc! : versione non completa, usabile, funzionante e con alcuni requisiti implementati; - \item \verb!v1.0.0-rc! : versione forse completa, usabile, funzionante e in attesa di validazione; - \item \verb!v1.0.0-stable! : versione completa, usabile, funzionante, verificata e validata. + \item \verb!v1.0.0-rc! : versione completa, usabile, funzionante, verificata e validata; + \item \verb!v1.0.0-stable! : versione completa, usabile, funzionante, verificata e validata, pronta al rilascio o al collaudo. \end{itemize} \subparagraph{Rilascio} Le release del software vengono eseguite internamente nella \glock{repository} in base alle funzionalità sviluppate. Inoltre, i rilasci interni saranno normati come segue: \begin{itemize} - \item le versioni \verb!stable! e/o \glock{Major Release} devono essere approvate dall'\glock{amministratore} e dal \glock{responsabile}. - \item le versioni \verb!rc! e/o \glock{Minor Release} devono essere approvate, previa notifica di conferma di tutti i \glock{test}, dall'\glock{amministratore} e dai \glock{verificatori}. - \item le versioni \verb!dev! e/o \glock{Patch} non richiedono approvazione e possono essere rilasciate autonomamente dal \glock{programmatore}. + \item le versioni \verb!stable! e/o \glock{Major Release} devono essere approvate dall'\glock{amministratore} e dal \glock{responsabile}; + \item le versioni \verb!rc! e/o \glock{Minor Release} devono essere approvate, previa notifica di conferma di tutti i \glock{test}, dall'\glock{amministratore} e dai \glock{verificatori}; + \item le versioni \verb!dev! e/o \glock{Patch} non richiedono approvazione e possono essere rilasciate autonomamente dal programmatore. \end{itemize} - \subparagraph{Integrazione con il Versionamento di Prodotto} + \subparagraph{Integrazione con il versionamento di prodotto} Il software, che è formato da diverse parti con le proprie evoluzioni, viene considerato come componente del prodotto. Pertanto, nel codice di versionamento viene aggiunto in coda l'identificativo della baseline di prodotto su cui si basa. Questa prassi non si applica alla nomenclatura dei nomi dei file che riportano la versione. -\subsubsection{Tecnologie} + \paragraph{Continuous Integration} -Le tecnologie coinvolte per la configurazione del workflow del progetto sono essenzialmente di 2 tipologie: -\begin{itemize} - \item Tecnologie per le comunicazioni e lo scheduling delle riunioni; - \item Tecnologie per la repository, con integrazione di soluzioni DevOps per lo sviluppo del software e dei documenti. -\end{itemize} + L'attività di \textit{Continuous Integration} viene impiegata per eseguire degli incrementi a livello di funzionalità delle componenti del prodotto. In particolare, permette di controllare l'aggiunta e la rimozione di parti di codice con i test che vengono appositamente creati. - \paragraph{Repository remota e locale} + La \textit{Continuous Integration} permette quindi di lavorare in modo sufficientemente sicuro, così da avere a disposizione un prodotto sempre funzionante che viene costruito a piccoli pezzi, i cui errori possono essere facilmente identificati e revisionati da parte dei programmatori e dei verificatori. - La repository viene gestita principalmente in un server remoto, accessibile tramite il portale di \href{https://github.com}{Github.com} da tutti i membri del team. + \subparagraph{Github Actions} - Il processo di sviluppo, tuttavia, avviene in locale, eseguendo una clonazione della repository con tutti i branch attivi tramite uno dei seguenti programmi: + Nell'ambito del progetto, si fa uso delle \glock{Github Actions} per eseguire l'attività di integrazione continua. Una \textit{action} è un insieme di uno o più operazioni (\textit{job}) che devono essere eseguiti su una istanza virtuale di un sistema operativo. È importante fare riferimento a quanto segue: + \begin{itemize} + \item una singola operazione, per considerarsi corretta, deve avere un codice di uscita (\textit{exit code}) positivo (0); + \item il fallimento di una \glock{Github Actions} può avvenire nel momento in cui il processo venga manualmente annullato, oppure una operazione ha avuto un codice di uscita negativo (1); + \item una operazione può essere eseguita sulla istanza corrente del sistema operativo selezionato dalla configurazione corrente; + \item gran parte delle operazioni vengono eseguite su \glock{Docker} in contenitori indipendenti e su nuove istanze appositamente generate; + \item una \textit{action} può essere avviata sulla repository ospitante. + \end{itemize} + + La struttura sequenziale delle operazioni è la seguente: + + \begin{itemize} + \item configurazione delle operazioni da eseguire; + \item esecuzione delle operazioni con riscontro dei codici di uscita; + \item esito finale e notifica sui canali telematici agli attori interessati. + \end{itemize} + + \subparagraph{Documentazione} + + La repository è stata configurata per garantire una buona accessibilità e correttezza nello sviluppo dei documenti di progetto da parte dei membri del team. A tal proposito, è stato messo in atto un processo di integrazione continua in ambiente di sviluppo nel momento in cui si vuole eseguire un incremento di versione di un documento. + Seguendo la configurazione del workflow adottata per il progetto, a partire da una modifica di un documento che viene eseguito su un branch \verb!feature/!, il documento deve essere sempre compilabile in \LaTeX{}. + Viene quindi eseguito un controllo preventivo prima di permettere l'integrazione finale delle modifiche tali da essere convalidate. + + \begin{enumerate} + \item ad ogni \textit{pull request} da un branch \verb!feature! al \verb!develop!, viene eseguita una \glock{build} di controllo di tutti i documenti modificati; + \item la \glock{build} crea un \glock{artefatto} con tutti i documenti PDF, che viene salvato nella repository e reso disponibile per essere visionato da remoto: + \begin{itemize} + \item \href{https://artifacts.redroundrobin.site}{artifacts.redroundrobin.site} + \end{itemize} + \item tramite gli appositi canali di comunicazione, vengono notificati tutti i membri del team delle nuove modifiche ai documenti. + \end{enumerate} + + Nel caso di \textbf{errori} nella compilazione dei file, viene inviato un avviso all'ultima persona che ha eseguito il \glock{commit} e vengono mantenuti gli ultimi file correttamente compilati. + + \subparagraph{Componenti software} + + I singoli componenti fanno uso delle \glock{Github Actions} per l'attività di integrazione continua. In particolare, in base alla tipologia di componente, vengono create delle operazioni di controllo basate sui \glock{Test} per verificare i requisiti del progetto. + + + \paragraph{Notification \& monitoring} + + L'attività di \textit{notification \& monitoring} permette di notificare i membri del team al fine di avere sempre sotto controllo le modifiche effettuate in un componente del prodotto. Questo, ad esempio, permette di venire a conoscenza dei fallimenti o successi per l'attività di \textit{Continuous Integration}. In questo caso, notifiche più specifiche possono essere inviate solamente ai membri interessati che sono stati coinvolti nel processo di modifica della componente. + \newline + Generalmente, si usano i seguenti canali telematici per le notifiche: \begin{itemize} - \item \textbf{Github Desktop:} applicazione ufficiale di Github, molto semplice e leggera, disponibile per Linux, Mac OS e Windows; - \item \textbf{GitKraken:} applicazione compatibile e più avanzata di Github desktop, disponibile per tutte le piattaforme; - \item \textbf{Git CLI:} applicazione da terminale, disponibile per tutte le piattaforme con tutti i comandi utili per Git. + \item pagina delle GitHub Actions della repository; + \item email automatiche; + \item canali Slack. \end{itemize} - Per ciascun programma viene richiesta autenticazione, che può avvenire tramite semplice login (username e password) o tramite generazione di chiavi SSH, successivamente importate in maniera guidata su Github. + Il \textbf{monitoraggio} viene eseguito principalmente per mezzo di notifiche. Tuttavia, poiché il coordinamento risulta essere di essenziale importanza, si è deciso di integrare uno strumento che traccia in tempo reale gli ultimi avvenimenti all'interno di una repository da parte dei singoli membri del gruppo. + Questo strumento, denominato \textit{Workflow Tracker}, permette di individuare l'ultimo branch in cui un utente ha lavorato, così da ridurre i conflitti di modifiche in modo preventivo e sapere le ultime attività all'interno della repository. + \newline + Lo strumento è pubblicamente visibile e reperibile al seguente indirizzo per tutti i membri del gruppo: + \begin{itemize} + \item \href{https://workflow.redroundrobin.site}{workflow.redroundrobin.site} + \end{itemize} + Il \textit{workflow tracker} aggiorna automaticamente ogni 20 secondi gli ultimi movimenti all'interno di una repository e identifica tutti gli autori che hanno eseguito un'azione di \textit{push} all'interno della repository. + + +\subsubsection{Strumenti} + + % Da aggiungere Google Drive, Gantt project e Draw.io + + \paragraph{Repository} + + %ndr: da aggiornare con i git submodules - \paragraph{DevOps} + La repository è un luogo remoto in cui vengono mantenuti, salvati e versionati tutti i file che riguardano il progetto per tutto il ciclo di vita del prodotto. Questa risiede in modo condiviso all'interno di \glock{GitHub} ed è accessibile solamente ai membri del team. - La repository, che fa uso di \glock{Github}, integra nativamente uno strumento denominato \glock{Github Actions} che permette la configurazione delle seguenti operazioni \glock{DevOps}: + \subparagraph{Versionamento con GitHub} + + La repository fa uso di un \textit{Version Control System} (VCS) di tipo distribuito sotto il motore \textit{Git}, che permette la condivisione dal locale al remoto del proprio spazio di lavoro su un luogo comune. Attraverso l'utilizzo di un web browser, è possibile collegarsi a \textit{GitHub} e controllare i file contenuti in una repository. + + \subparagraph{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 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: + \begin{itemize} + \item \verb!master! branch: branch principale su cui vengono fatti i rilasci ad ogni \glock{milestone}; + \item \verb!develop! branch: branch di sviluppo su cui viene fatta integrazione di nuove funzionalità concluse; + \item \verb!feature/xxxx! branch: branch indipendente usato da uno o più membri del gruppo per sviluppare una sezione o fare una revisione di un documento; + \begin{itemize} + \item \textbf{xxxx:} si riferisce al numero della \glock{issue} o al titolo della funzionalità da integrare. + \item il \textit{feature branch} riferisce generalmente una singola \glock{issue} ed è rimosso alla sua chiusura. + \end{itemize} + \end{itemize} + + Ad ogni milestone viene associata una release interna alla repository, così da tenere traccia di una \glock{baseline}. + + \subparagraph{Cartelle di configurazione} + + La repository si compone di diverse tipologie di cartelle. Oltre alle cartelle che riguardano la documentazione e il software, è presente una cartella che viene usata ai fini della configurazione di \glock{GitHub}. + \begin{itemize} + \item \verb!.github/!: cartella per la repository di \glock{Github} con i file di configurazione per le \glock{Github Actions} e l'\glock{Issue Tracking System}. + \end{itemize} + + \subparagraph{Formati dei file per le 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, 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}; + \item \textbf{file senza formati} contengono configurazioni aggiuntive per \glock{GitHub} (es: template delle \glock{Issue}); + \end{itemize} + + \subparagraph{Formati dei file per i documenti} + + Per la documentazione si usano principalmente i seguenti tipi di file: + \begin{itemize} + \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{Project board} + + Al fine di ottenere un coordinamento il più possibile trasparente dei compiti di un singolo membro del gruppo, si è deciso di introdurre, attraverso la suite di \glock{Github}, una \textbf{project board} generale che permette di visionare l'andamento dei task, dalla loro creazione fino al loro completamento. + La project board può essere acceduta e visionata solamente dai membri del team al seguente indirizzo: + + \href{http://project.redroundrobin.site}{http://project.redroundrobin.site} + + + \subparagraph{Issue tracking system} + + \textit{GitHub} integra un \textit{Issue Tracking System} (ITS) che permette di tracciare lo sviluppo tramite ticketing, assegnando a ciascun membro del team una o più \glock{issue} in base alle necessità. L'ITS viene attivato su ogni repository di progetto e viene poi raggruppato tramite linking dalla project board generale. Una \glock{issue} descrive un problema che deve essere risolto, sia esso riguardante l'introduzione di una nuova funzionalità, sia per la risoluzione di un bug. Inoltre, una qualunque \glock{issue} può essere: + \begin{itemize} + \item assegnata a uno o più membri del team; + \item aperta o chiusa; + \item assegnata a una milestone; + \item assegnata a una project board; + \item discussa a modi \textit{forum} da tutti i membri del gruppo. + \end{itemize} + + + \paragraph{Git submodules} + + Analizzando il quantitativo di componenti software, sono stati individuati dei possibili problemi che potrebbero sorgere qualora si decidesse di mantenere tutte le componenti del prodotto in un solo luogo. Un grande quantitativo di cartelle può causare confusione e rallentamento nello sviluppo, specialmente nel momento in cui si rende necessario \textbf{collaborare} tramite i branch. Decidendo di lavorare con un workflow basato sui \textit{branch feature}, il fatto di lavorare su più componenti può portare a un \textbf{livello di astrazione maggiore}, che può comportare problemi di coordinamento e conflitti nelle componenti realizzate. + + \subparagraph{Introduzione ai sotto-moduli} + + Al fine di porre rimedio a questa eventuale problematica, si è deciso di introdurre una funzionalità di \glock{Git} per poter separare lo sviluppo delle componenti software in più \textbf{sotto-moduli}. Ciascun sotto-modulo viene identificato come una repository indipendente, dove viene sviluppata una componente software seguendo la stessa configurazione di \textit{workflow}. + Tutti i sotto-moduli possono essere singolarmente recuperati e versionati in una repository principale, in cui si va a comporre l'intero prodotto seguendo l'andamento di rilascio delle relative \textit{baseline} di prodotto. + + \begin{itemize} + \item Un sotto-modulo si identifica come repository di \glock{github}. + \item Un sotto-modulo può essere aggiornato nella repository principale seguendo gli ultimi commit nel branch principale o recuperando la versione di rilascio. + \item Nella repository principale, solo l'amministratore aggiorna manualmente le versioni dei componenti (o sotto-moduli) in base ai rilasci di prodotto. + \end{itemize} + + \subparagraph{Repository principale} + + La repository principale si compone di tutti i sotto-moduli che vengono versionati in base all'ultimo commit nel sotto-modulo o in base alla versione rilasciata del sotto-modulo. + La struttura di dipendenza delle repository è la seguente: + + \begin{itemize} + \item \verb!swe-thirema!: repository principale con il prodotto intero + \begin{itemize} + \item \verb!swe-docs!: sotto-modulo per la documentazione + \item \verb!swe-webapp!: sotto-modulo per il sito web di progetto + \item \verb!swe-api!: sotto-modulo per le \glock{API} + \item \verb!swe-telegram!: sotto-modulo per il \glock{Bot Telegram} + \item \verb!swe-kafka-db!: sotto-modulo per i database e \glock{Apache Kafka} + \item \verb!swe-gateway!: sotto-modulo per il \glock{Gateway} e i dispositivi + \end{itemize} + \end{itemize} + + \begin{figure}[H] + \centering + \includegraphics[scale=0.7]{res/images/submodules} + \caption{Grafico riassuntivo dei Git submodules utilizzati nel progetto} + \end{figure} + + La repository principale può essere acceduta dal seguente indirizzo: + + \href{https://github.com/Maxelweb/swe-thirema}{thirema.redroundrobin.site} + + \subparagraph{Sotto-modulo swe-docs} + + \begin{itemize} + \item \textbf{Descrizione:} contiene tutta la documentazione di progetto. + \item \textbf{Nome completo:} \verb!Maxelweb/swe-docs! + \item \textbf{URL:} \href{https://github.com/Maxelweb/swe-docs}{docs.redroundrobin.site} + \item \textbf{Linguaggi di sviluppo:} \LaTeX{} + \item \textbf{Struttura delle cartelle:} + \begin{itemize} + \item \verb!interni/!: contiene tutta la documentazione interna; + \item \verb!esterni/!: contiene tutta la documentazione esterna; + \item \verb!template/!: contiene tutti i template delle varie tipologie di documento; + \item \verb!notes/!: contiene tutte le note aggiuntive (\textit{non}-\LaTeX{}) sui seminari, le guide e l'organizzazione. + \end{itemize} + \end{itemize} + + \subparagraph{Sotto-modulo swe-webapp} + + \begin{itemize} + \item \textbf{Descrizione:} contiene il sito web richiesto dal progetto. + \item \textbf{Nome completo:} \verb!Maxelweb/swe-webapp! + \item \textbf{URL:} \href{https://github.com/Maxelweb/swe-webapp}{webapp.redroundrobin.site} + \item \textbf{Linguaggi di sviluppo:} \glock{PHP}, \glock{Javascript} + \end{itemize} + + \subparagraph{Sotto-modulo swe-api} + + \begin{itemize} + \item \textbf{Descrizione:} contiene le \glock{API} per la comunicazione tra \glock{Apache Kafka} e le applicazioni esterne. + \item \textbf{Nome completo:} \verb!Maxelweb/swe-api! + \item \textbf{URL:} \href{https://github.com/Maxelweb/swe-api}{api.redroundrobin.site} + \item \textbf{Linguaggi di sviluppo:} \glock{Java} + \end{itemize} + + \subparagraph{Sotto-modulo swe-telegram} + + \begin{itemize} + \item \textbf{Descrizione:} contiene il \glock{Bot Telegram}. + \item \textbf{Nome completo:} \verb!Maxelweb/swe-telegram! + \item \textbf{URL:} \href{https://github.com/Maxelweb/swe-telegram}{telegram.redroundrobin.site} + \item \textbf{Linguaggi di sviluppo:} \glock{Javascript} + \end{itemize} + + \subparagraph{Sotto-modulo swe-kafka-db} + + \begin{itemize} + \item \textbf{Descrizione:} contiene il componente per la configurazione di \glock{Kafka} e dei database. + \item \textbf{Nome completo:} \verb!Maxelweb/swe-kafka-db! + \item \textbf{URL:} \href{https://github.com/Maxelweb/swe-kafka-db}{kafka-db.redroundrobin.site} + \item \textbf{Linguaggi di sviluppo:} \glock{YML}, \glock{SQL} + \end{itemize} + + \subparagraph{Sotto-modulo swe-gateway} + + \begin{itemize} + \item \textbf{Descrizione:} contiene l'implementazione di un \glock{Gateway} con l'integrazione di un dispositivo. + \item \textbf{Nome completo:} \verb!Maxelweb/swe-gateway! + \item \textbf{URL:} \href{https://github.com/Maxelweb/swe-gateway}{gateway.redroundrobin.site} + \item \textbf{Linguaggi di sviluppo:} \glock{Java} + \end{itemize} + + + \paragraph{Tecnologie di supporto e software} + + Le tecnologie e i software coinvolti per la configurazione del workflow si pongono i seguenti obiettivi: \begin{itemize} - \item \textbf{Continuous Build:} compilazione continua dei sorgenti software; - \item \textbf{Continuous Integration:} integrazione continua del software con uso di \glock{Test}; - \item \textbf{Continuous Delivery:} consegna continua del software sfruttando gli incrementi minori per eseguire test più spesso; - \item \textbf{Continuous Deployment:} distribuzione continua e messa in funzione del software; - \item \textbf{Notification \& Monitoring:} invio di notifiche ai membri del team e monitoraggio delle attività di \glock{DevOps}. + \item uniformare il \textit{modus operandi} del gruppo, consentendo di collaborare su programmi comuni e multipiattaforma; + \item automatizzare il lavoro per delegare gli impieghi che possono essere svolti tramite macchina, velocizzando lo sviluppo. \end{itemize} - Nel nostro caso, le \glock{Github Actions} permettono di fare in un'unica configurazione i passaggi fondamentali in base al \glock{workflow} che ci interessa svolgere. + \subparagraph{Programmi per la gestione della repository} + + La repository viene gestita principalmente in un server remoto, accessibile tramite il portale di \href{https://github.com}{Github.com} da tutti i membri del team. + Il processo di sviluppo, tuttavia, avviene in locale, eseguendo una clonazione della repository con tutti i branch attivi tramite uno dei seguenti programmi: + \begin{itemize} + \item \textbf{Github Desktop:} applicazione ufficiale di Github, molto semplice e leggera, disponibile per Linux, Mac OS e Windows; + \item \textbf{GitKraken:} applicazione compatibile e più avanzata di Github desktop, disponibile per tutte le piattaforme; + \item \textbf{Git CLI:} applicazione da terminale, disponibile per tutte le piattaforme con tutti i comandi utili per Git. + \end{itemize} + Per ciascun programma viene richiesta autenticazione, che può avvenire tramite semplice login (username e password) o tramite generazione di chiavi SSH, successivamente importate tramite una procedura guidata su \glock{Github}. + + \subparagraph{Automazione del workflow} + + La repository, che fa uso di \glock{Github}, integra nativamente uno strumento denominato \glock{Github Actions} che permette di configurare le seguenti attività: + \begin{itemize} + \item \textbf{Continuous Integration:} integrazione continua del software con controllo sui \glock{Test}; + \item \textbf{Continuous Delivery:} consegna continua del software sfruttando gli incrementi minori per eseguire test più spesso; + \item \textbf{Continuous Deployment:} distribuzione continua e messa in funzione del software; + \item \textbf{Notification \& Monitoring:} invio di notifiche ai membri del team e monitoraggio delle attività di \glock{DevOps}. + \end{itemize} + Nel nostro caso, le \glock{Github Actions} permettono di fare in un solo file di configurazione tutti i passaggi in base al \glock{workflow} che ci interessa integrare. + \newline + Delle operazioni descritte precedentemente, si fa uso solamente di: + \begin{itemize} + \item Countinuous Integration; + \item Notification \& Monitoring. + \end{itemize} + I rimanenti processi verranno eventualmente impiegati per la manutenzione del prodotto. + % ndr: RIMOSSO A SEGUITO DI COLLOQUIO CON TULLIO +% ndr2: fix con uso delle cartelle e fix dei verbali, da approvare % \subsubsection{Processi di DevOps} % Da verificarne la posizione e il contenuto diff --git a/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/Validazione.tex b/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/Validazione.tex index 2a592f5..eead412 100644 --- a/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/Validazione.tex +++ b/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/Validazione.tex @@ -7,18 +7,18 @@ \subsection{Validazione} \subsubsection{Descrizione} Il processo di validazione esegue il test completo sul sistema affinché sia chiaro se sono state rispettate le necessità del committente, il che porta a definire se il prodotto esegue in modo corretto. Per poter effettuare questo processo è necessario che venga eseguito dopo il processo di verifica, in modo che tutte le unità del sistema permettano il test completo su di esso. \subsubsection{Attività} - \paragraph{Test}\mbox{}\\ + \paragraph{Test}\mbox{} In questo processo viene eseguito il test di accettazione, effettuato insieme al committente per verificare se il prodotto rispetta le richieste. Per elencare le specifiche del test si è scelta una rappresentazione tabellare contenente il codice del componente da testare, la descrizione dei test, il suo stato di avanzamento e il risultato del test stesso secondo la seguente nomenclatura: \\ Stato: \begin{itemize} - \item \textbf{I}: il test è stato implementato; - \item \textbf{NI}: il test non è ancora stato implementato. + \item \textbf{I:} il test è stato implementato; + \item \textbf{NI:} il test non è ancora stato implementato. \end{itemize} Risultato: \begin{itemize} - \item \textbf{S}: il test ha successo; - \item \textbf{F}: il test ha fallito. + \item \textbf{S:} il test ha successo; + \item \textbf{F:} il test ha fallito. \end{itemize} Tuttavia si è scelto di omettere il risultato dei test in quanto non significativo allo stato attuale del prodotto. @@ -28,21 +28,26 @@ \subsection{Validazione} Per classificare questi tipi di test verrà associata un codice ad ognuno di essi secondo il seguente modello: \begin{center} - \textbf{TA[Priorità]-[Tipologia]-[Identificativo]} + \textbf{TA[Priorità]-[Tipologia]-[Identificativo]} \end{center} - dove: + Dove: - \textbf{Priorità}: indica la priorità del requisito associato al test e potrà avere i seguenti valori: \begin{itemize} - \item \textbf{A}: Obbligatorio, strettamente necessario; - \item \textbf{B}: Desiderabile, non strettamente necessario; - \item \textbf{C}: Relativamente utile o contrattabile in corso d'opera. - \end{itemize} - \textbf{Tipologia}: indica la tipologia del requisito associato al test e potrà avere i seguenti valori: - \begin{itemize} - \item \textbf{F}: funzionale; - \item \textbf{P}: prestazionale; - \item \textbf{Q}: qualitativo; - \item \textbf{V}: vincolo. - \end{itemize} - \textbf{Identificativo}: numero progressivo il cui obiettivo sarà di contraddistinguere il singolo componente da testare; parte da 1. \ No newline at end of file + \item \textbf{Priorità:} indica la priorità del requisito associato al test e potrà avere i seguenti valori: + \begin{itemize} + \item \textbf{A:} obbligatorio, strettamente necessario; + \item \textbf{B:} desiderabile, non strettamente necessario; + \item \textbf{C:} relativamente utile o contrattabile in corso d'opera. + \end{itemize} + \item \textbf{Tipologia:} indica la tipologia del requisito associato al test e potrà avere i seguenti valori: + \begin{itemize} + \item \textbf{F:} funzionale; + \item \textbf{P:} prestazionale; + \item \textbf{Q:} qualitativo; + \item \textbf{V:} vincolo. + \end{itemize} + \item \textbf{Identificativo:} numero progressivo il cui obiettivo sarà di contraddistinguere il singolo componente da testare; parte da 1. + \end{itemize} + + \subsubsection{Strumenti} + Non sono stati individuati degli strumenti per il processo di validazione. \ No newline at end of file diff --git a/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/Verifica.tex b/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/Verifica.tex index b412b1b..827f6e2 100644 --- a/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/Verifica.tex +++ b/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/Verifica.tex @@ -22,14 +22,14 @@ \subsection{Verifica} \subparagraph{Analisi statica}\mbox{}\\ L'analisi statica viene effettuata sul prodotto senza necessità di eseguirlo e serve per verificare che non ci siano errori o \textit{difetti}. I due tipi di analisi statica sono: \begin{itemize} - \item Walkthrough: consiste nell'analizzare i vari documenti e file in tutto il loro contenuto per trovare eventuali \textit{difetti}. Il verificatore controlla se sono presenti \textit{difetti} e, in caso ne trovi, la correzione verrà effettuata dagli sviluppatori; - \item Inspection: in questa tecnica è noto a priori dove debbano essere ricercati i possibili \textit{difetti} del prodotto, quindi non si analizzano i documenti e file per intero, ma solo le parti in cui di solito sono presenti. Il verificatore compone una lista di controllo (checklist) inserendo i punti in cui si possono rilevare possibili \textit{difetti}, controlla in quei punti della lista e, se trova delle incorrettezze, la correzione viene poi effettuata dagli sviluppatori. \\ + \item \textbf{walkthrough:} consiste nell'analizzare i vari documenti e file in tutto il loro contenuto per trovare eventuali \textit{difetti}. Il verificatore controlla se sono presenti \textit{difetti} e, in caso ne trovi, la correzione verrà effettuata dagli sviluppatori; + \item \textbf{inspection:} in questa tecnica è noto a priori dove debbano essere ricercati i possibili \textit{difetti} del prodotto, quindi non si analizzano i documenti e file per intero, ma solo le parti in cui di solito sono presenti. Il verificatore compone una lista di controllo (checklist) inserendo i punti in cui si possono rilevare possibili \textit{difetti}, controlla in quei punti della lista e, se trova delle incorrettezze, la correzione viene poi effettuata dagli sviluppatori. \\ Di seguito alcuni possibili punti in cui trovare \textit{difetti} all'interno della documentazione: \begin{itemize} \item elenchi puntati; - \item formato Date; + \item formato date; \item parole/frasi in grassetto/corsivo; - \item uso di riferimenti appropriati al Glossario/Documento. + \item uso di riferimenti appropriati al glossario/documento. \end{itemize} \end{itemize} \subparagraph{Analisi dinamica}\mbox{}\\ @@ -46,13 +46,13 @@ \subsection{Verifica} Per elencare le specifiche dei test si è scelta una rappresentazione tabellare contenente il codice del componente da testare, la descrizione dei test, il suo stato di avanzamento e il risultato del test stesso secondo la seguente nomenclatura: \\ Stato: \begin{itemize} - \item \textbf{I}: il test è stato implementato; - \item \textbf{NI}: il test non è ancora stato implementato. + \item \textbf{I:} il test è stato implementato; + \item \textbf{NI:} il test non è ancora stato implementato. \end{itemize} Risultato: \begin{itemize} - \item \textbf{S}: il test ha successo; - \item \textbf{F}: il test ha fallito. + \item \textbf{S:} il test ha successo; + \item \textbf{F:} il test ha fallito. \end{itemize} Tuttavia si è scelto di omettere il risultato dei test in quanto non significativo allo stato attuale del prodotto. @@ -62,50 +62,56 @@ \subsection{Verifica} Per classificare questa tipologia di test si utilizzerà un codice utilizzando il seguente modello: \begin{center} - \textbf{TS[Priorità]-[Tipologia]-[Identificativo]} + \textbf{TS[Priorità]-[Tipologia]-[Identificativo]} \end{center} - dove: + Dove: - \textbf{Priorità}: indica la priorità del requisito associato al test e potrà avere i seguenti valori: \begin{itemize} - \item \textbf{A}: Obbligatorio, strettamente necessario; - \item \textbf{B}: Desiderabile, non strettamente necessario; - \item \textbf{C}: Relativamente utile o contrattabile in corso d'opera. - \end{itemize} - \textbf{Tipologia}: indica la tipologia del requisito associato al test e potrà avere i seguenti valori: - \begin{itemize} - \item \textbf{F}: funzionale; - \item \textbf{P}: prestazionale; - \item \textbf{Q}: qualitativo; - \item \textbf{V}: vincolo. - \end{itemize} - \textbf{Identificativo}: numero progressivo il cui obiettivo sarà di contraddistinguere il singolo componente da testare; parte da 1. + \item \textbf{Priorità:} indica la priorità del requisito associato al test e potrà avere i seguenti valori: + \begin{itemize} + \item \textbf{A:} obbligatorio, strettamente necessario; + \item \textbf{B:} desiderabile, non strettamente necessario; + \item \textbf{C:} relativamente utile o contrattabile in corso d'opera. + \end{itemize} + \item \textbf{Tipologia:} indica la tipologia del requisito associato al test e potrà avere i seguenti valori: + \begin{itemize} + \item \textbf{F:} funzionale; + \item \textbf{P:} prestazionale; + \item \textbf{Q:} qualitativo; + \item \textbf{V:} vincolo. + \end{itemize} + \item \textbf{Identificativo:} numero progressivo il cui obiettivo sarà di contraddistinguere il singolo componente da testare; parte da 1. + \end{itemize} \subparagraph*{Test di integrazione} Test eseguiti su componenti del software per verificare se l'insieme di unità si interfaccia come dovrebbe. Questo test è eseguito in modo ricorrente: ogni volta che un insieme di unità esegue correttamente, esso viene integrato con altri insiemi di unità, fino al test completo sul sistema. Per classificare questa tipologia di test si utilizzerà un codice utilizzando il seguente modello: \begin{center} - \textbf{TI-[Identificativo]} + \textbf{TI-[Identificativo]} \end{center} - dove: - - \textbf{Identificativo}: numero progressivo il cui obiettivo sarà di contraddistinguere il singolo componente da testare; parte da 1. - + Dove: + + \begin{itemize} + \item \textbf{Identificativo:} numero progressivo il cui obiettivo sarà di contraddistinguere il singolo componente da testare; parte da 1. + \end{itemize} + \subparagraph*{Test di unità} Test eseguiti sul funzionamento di unità di software in modo automatico: viene definito l'input e l'output atteso per verificare il corretto funzionamento dell'unità. Per classificare questa tipologia di test si utilizzerà un codice utilizzando il seguente modello: \begin{center} - \textbf{TU-[Identificativo]} + \textbf{TU-[Identificativo]} \end{center} - dove: - - \textbf{Identificativo}: numero progressivo il cui obiettivo sarà di contraddistinguere il singolo componente da testare; parte da 1. - + Dove: + + \begin{itemize} + \item \textbf{Identificativo:} numero progressivo il cui obiettivo sarà di contraddistinguere il singolo componente da testare; parte da 1. + \end{itemize} + \subparagraph*{Test di regressione} Test eseguito ogni volta che un'unità viene modificata allo scopo di trovare \textit{difetti} nelle funzionalità già testate, potendo garantire che le funzionalità preesistenti non abbiano cambiato comportamento. Si rieseguono tutti i test necessari affinché si possa essere certi che la modifica non causi il funzionamento scorretto di altre unità collegate all'unità modificata. \subsubsection{Strumenti} - \subparagraph{Text Studio} - Sono stati utilizzati i \glock{correttori ortografici} integrati nell'\glock{ide} Text Studio per la trascrizione della documentazione. \ No newline at end of file + \paragraph{Text Studio} + Sono stati utilizzati i \glock{correttori ortografici} integrati nell'\glock{ide} Text Studio per la redazione della documentazione. \ No newline at end of file diff --git a/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/processiSupporto.tex b/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/processiSupporto.tex index b817789..54f6c56 100644 --- a/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/processiSupporto.tex +++ b/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/processiSupporto.tex @@ -1,6 +1,6 @@ \yetAnotherSectionNamed{Sez3-ProcessiSupporto/Documentazione} \yetAnotherSectionNamed{Sez3-ProcessiSupporto/GestConfigurazione} -\yetAnotherSectionNamed{Sez3-ProcessiSupporto/ProcDiRisoluzioneDeiProblemi} +\yetAnotherSectionNamed{Sez3-ProcessiSupporto/GestCambiamenti} \yetAnotherSectionNamed{Sez3-ProcessiSupporto/GaranziaQualita} \yetAnotherSectionNamed{Sez3-ProcessiSupporto/Verifica} \yetAnotherSectionNamed{Sez3-ProcessiSupporto/Validazione} \ No newline at end of file diff --git a/interni/norme_progetto/res/sections/Sez4-ProcessiOrganizzativi/FormazionePersonale.tex b/interni/norme_progetto/res/sections/Sez4-ProcessiOrganizzativi/FormazionePersonale.tex index 8e8d897..7fea95b 100644 --- a/interni/norme_progetto/res/sections/Sez4-ProcessiOrganizzativi/FormazionePersonale.tex +++ b/interni/norme_progetto/res/sections/Sez4-ProcessiOrganizzativi/FormazionePersonale.tex @@ -1,12 +1,14 @@ \subsection{Formazione del personale} \subsubsection{Scopo} - I membri del gruppo RedRoundRobin sono tenuti a formarsi individualmente sulle tecnologie richieste per il completamento del progetto e, nel caso di incomprensioni o problemi nell'utilizzo di esse, il proponente si dichiara disponibile a corsi di formazione e chiarimenti. + I membri del gruppo Red Round Robin sono tenuti a formarsi individualmente sulle tecnologie richieste per il completamento del progetto e, nel caso di incomprensioni o problemi nell'utilizzo di esse, il proponente si dichiara disponibile a corsi di formazione e chiarimenti. \subsubsection{Descrizione} Ogni persona dovrà documentarsi sui linguaggi e gli strumenti di programmazione che verranno utilizzati per tutto il periodo di sviluppo del progetto, se sconosciuti. - \subsubsection{Piano di formazione} + \subsubsection{Attività} + + \paragraph{Materiale per la formazione} Di seguito verranno elencate le tecnologie ed i linguaggi di programmazione necessari per lo svolgimento del capitolato con i relativi link al sito ufficiale: \begin{itemize} \item \textbf{Java}: \href{https://www.java.com/}{www.java.com}; @@ -17,3 +19,5 @@ \subsection{Formazione del personale} \end{itemize} %Eventuali corsi formativi aggiuntivi verranno inseriti in seguito. + \subsubsection{Strumenti} + Non sono stati individuati degli strumenti che accompagnino questo processo. \ No newline at end of file diff --git a/interni/norme_progetto/res/sections/Sez4-ProcessiOrganizzativi/GestProcessi.tex b/interni/norme_progetto/res/sections/Sez4-ProcessiOrganizzativi/GestProcessi.tex index 10bb287..bee71cf 100644 --- a/interni/norme_progetto/res/sections/Sez4-ProcessiOrganizzativi/GestProcessi.tex +++ b/interni/norme_progetto/res/sections/Sez4-ProcessiOrganizzativi/GestProcessi.tex @@ -1,6 +1,6 @@ -\section{Processi Organizzativi} +\section{Processi organizzativi} -\subsection{Gestione dei Processi} +\subsection{Gestione dei processi} \subsubsection{Scopo} @@ -39,16 +39,14 @@ \subsection{Gestione dei Processi} \item calcolo delle risorse necessarie per terminare il progetto, visto il bilancio del lavoro svolto nel periodo; \item revisione delle attività sulla base dei riscontri dei rischi. \end{itemize} + \subsubsection{Attività} + \paragraph{Inizializzazione e campo d'applicazione} + Il responsabile e l'amministratore devono stabilire la fattibilità del processo controllando che le risorse a disposizione siano disponibili, adeguate ed appropriate. + \paragraph{Pianificazione} + Il responsabile deve preparare i piani per l'esecuzione dei processi; deve suddividere i ruoli e l'assegnazione oraria per i membri del gruppo, garantendo che ogni componente assuma, nel corso del progetto, almeno una volta ogni ruolo. + I ruoli richiesti dal progetto sono i seguenti: - \subsubsection{Ruoli di Progetto} - - Ogni membro del gruppo deve ricoprire più ruoli, i quali sono cambiati a rotazione con una frequenza che permetta ad ogni componente di assumere almeno una volta ogni ruolo previsto per il progetto e, allo stesso tempo, di garantire la continuità delle attività in corso. - \newline - Le attività assegnate ad ogni ruolo sono programmate ed organizzate nel \dext{Piano di Progetto}. - \newline - Di seguito vengono descritti tutti i ruoli richiesti dal progetto. - - \paragraph{Responsabile} + \subparagraph{Responsabile} Il responsabile accentra tutte le responsabilità di pianificazione, controllo, gestione e coordinamento di attività e risorse all'interno del progetto. Inoltre svolge la funzione di intermediario verso le figure esterne al gruppo, quali committente e proponente del capitolato, ed è il responsabile ultimo dei risultati del progetto. \newline @@ -59,11 +57,11 @@ \subsection{Gestione dei Processi} \item approvare l'emissione dei documenti; \item coordinare le attività, le risorse e i componenti del gruppo; \item gestire le criticità incontrate dal gruppo; - \item redigere l'\glock{Organigramma} e il Piano di Progetto; - \item approvare l'Offerta sottoposta al committente. + \item redigere l'\glock{Organigramma} e il piano di progetto; + \item approvare l'offerta sottoposta al committente. \end{itemize} - \paragraph{Amministratore} + \subparagraph{Amministratore} L'amministratore è incaricato della gestione dell'ambiente di lavoro. \newline @@ -74,71 +72,60 @@ \subsection{Gestione dei Processi} \item è responsabile della redazione ed attuazione dei piani e delle procedure per la gestione della qualità; \item controlla le versioni e le configurazioni del prodotto; \item gestisce la documentazione del progetto; - \item collabora alla redazione del Piano di Progetto; - \item redige le Norme di Progetto. + \item collabora alla redazione del piano di progetto; + \item redige le norme di progetto. \end{itemize} - \paragraph{Analista} - L'analista è il responsabile di tutte le attività di analisi svolte durante l'Analisi dei Requisiti, al cui termine hanno fine anche tutti i sui incarichi all'interno del gruppo. Egli infatti è una figura che non è presente all'interno del gruppo per tutta la durata del progetto. + \subparagraph{Analista} + L'analista è il responsabile di tutte le attività di analisi svolte durante l'analisi dei requisiti, al cui termine hanno fine anche tutti i sui incarichi all'interno del gruppo. Egli infatti è una figura che non è presente all'interno del gruppo per tutta la durata del progetto. \newline L'analista ha il compito di: \begin{itemize} \item studiare il dominio applicativo del progetto; \item definire i requisiti del progetto; - \item redigere lo Studio di Fattibilità e l'Analisi dei Requisiti. + \item redigere lo studio di fattibilità e l'analisi dei requisiti. \end{itemize} - \paragraph{Progettista} + \subparagraph{Progettista} - Il progettista è il responsabile di tutte le attività di progettazione svolte durante la Progettazione dell'Architettura e la Progettazione di Dettaglio. + Il progettista è il responsabile di tutte le attività di progettazione svolte durante la progettazione dell'architettura e la progettazione di dettaglio. \newline Il progettista deve: \begin{itemize} \item prendere decisioni riguardanti gli aspetti tecnici del progetto, favorendo l'efficacia e l'efficienza; \item definire l'architettura del prodotto da sviluppare, perseguendo la sua efficienza, efficacia e manutenibilità, tramite l'utilizzo di apposite tecnologie individuate a partire dai requisiti definiti dall'analista; - \item redigere la Specifica Tecnica, la Definizione di Prodotto e la parte pragmatica del Piano di Qualifica. + \item redigere la specifica tecnica, la definizione di prodotto e la parte pragmatica del piano di qualifica. \end{itemize} - \paragraph{Programmatore} + \subparagraph{Programmatore} Il programmatore è il responsabile di tutte le attività di codifica effettuate per lo sviluppo del progetto. \newline In particolare, il programmatore è responsabile: \begin{itemize} - \item dell'implementazione della Specifica Tecnica redatta dal progettista; + \item dell'implementazione della specifica tecnica redatta dal progettista; \item della codifica mirata alla realizzazione del prodotto; \item della codifica di componenti di ausilio necessarie per l'esecuzione delle prove di verifica e validazione. \end{itemize} - \paragraph{Verificatore} + \subparagraph{Verificatore} Il verificatore è il responsabile di tutte le attività di verifica dei documenti e del codice scritti dagli altri componenti del gruppo. Il suo compito è trovare errori, di qualunque tipo, nei prodotti che controlla e di segnalare tali errori a chi ha la responsabilità diretta sul quel prodotto, in modo che possa apportare le dovute correzioni. \newline Il verificatore non ha il compito di correggere gli errori rilevati, deve quindi: \begin{itemize} - \item esaminare i prodotti in fase di revisione, utilizzando le tecniche e gli strumenti definiti nelle Norme di Progetto; + \item esaminare i prodotti in fase di revisione, utilizzando le tecniche e gli strumenti definiti nelle norme di progetto; \item indicare eventuali errori riscontrati nel prodotto in esame; \item segnalare eventuali errori rilevati al responsabile dell'oggetto in fase di verifica, in modo che possa correggerli. \end{itemize} - \subsubsection{Introduzione ale Procedure} - - Sono state definite delle procedure da adottare all'interno del gruppo durante la realizzazione del progetto, le quali hanno lo scopo di regolamentare tutte le operazioni di gestione e coordinamento del lavoro, con il fine di garantire efficacia ed efficienza. - - - \subsubsection{Gestione delle Risorse (QP-1)} - - \paragraph{Scopo} - - Si vuole gestire la copertura di risorse disponibili per la realizzazione del progetto, monitorando i costi aggiuntivi e le tempistiche non rispettate dalla schedulazione pianificata. Questo può essere utile al cliente per capire in fase di sviluppo l'andamento del progetto a livello di gestione delle risorse. - - \paragraph{Introduzione alle Metriche di Qualità} - - Per la gestione delle risorse si farà uso delle seguenti metriche: + \subparagraph{Metriche di qualità} + Si vuole gestire la copertura di risorse disponibili per la realizzazione del progetto, monitorando i costi aggiuntivi e le tempistiche non rispettate dalla schedulazione pianificata. Questo può essere utile al cliente per capire in fase di sviluppo l'andamento del progetto a livello di gestione delle risorse. + Per la gestione delle risorse si farà uso delle seguenti metriche: \begin{itemize} \item QM-PROC-1. Budgeted Cost of Work Scheduled (BCWS); @@ -148,37 +135,37 @@ \subsection{Gestione dei Processi} \item QM-PROC-5. Cost Variance (CV). \end{itemize} - \paragraph{QM-PROC-1. Budgeted Cost of Work Scheduled (BCWS)} + \subparagraph{QM-PROC-1. Budgeted Cost of Work Scheduled (BCWS)} \subparagraph{Descrizione} - La metrica BCWS definisce il costo pianificato per realizzare le attività di progetto alla data corrente. + La metrica BCWS definisce il costo pianificato per realizzare le attività di progetto alla data corrente. - \subparagraph{Unità di Misura} - Il costo pianificato è misurato in EURO. + \subparagraph{Unità di misura} + Il costo pianificato è misurato in EURO. - \paragraph{QM-PROC-2. Actual Cost of Work Performed (ACWP)} + \subparagraph{QM-PROC-2. Actual Cost of Work Performed (ACWP)} \subparagraph{Descrizione} - La metrica ACWP definisce il costo effettivamente sostenuto per realizzare le attività di progetto alla data corrente. + La metrica ACWP definisce il costo effettivamente sostenuto per realizzare le attività di progetto alla data corrente. \subparagraph{Unità di Misura} - Il costo sostenuto è misurato in EURO. + Il costo sostenuto è misurato in EURO. - \paragraph{QM-PROC-3. Budgeted Cost of Work Performed (BCWP)} + \subparagraph{QM-PROC-3. Budgeted Cost of Work Performed (BCWP)} \subparagraph{Descrizione} - La metrica BCWP definisce il valore delle attività realizzate alla data corrente. In altre parole, misura il valore del prodotto fino ad ora realizzato. + La metrica BCWP definisce il valore delle attività realizzate alla data corrente. In altre parole, misura il valore del prodotto fino ad ora realizzato. - \subparagraph{Unità di Misura} - Il valore del prodotto è misurato in EURO. + \subparagraph{Unità di misura} + Il valore del prodotto è misurato in EURO. - \paragraph{QM-PROC-4. Schedule Variance (SV)} + \subparagraph{QM-PROC-4. Schedule Variance (SV)} \subparagraph{Descrizione} - La metrica SV indica se si è in anticipo, in ritardo o in linea rispetto alle schedulazioni pianificate per il progetto. Questo può essere utile per il cliente per valutare l'efficacia del gruppo nei confronti della realizzazione del progetto. + La metrica SV indica se si è in anticipo, in ritardo o in linea rispetto alle schedulazioni pianificate per il progetto. Questo può essere utile per il cliente per valutare l'efficacia del gruppo nei confronti della realizzazione del progetto. - \subparagraph{Unità di Misura} - La metrica viene espressa in percentuale. + \subparagraph{Unità di misura} + La metrica viene espressa in percentuale. \subparagraph{Formula} La formula per il calcolo della metrica è la seguente: @@ -186,21 +173,21 @@ \subsection{Gestione dei Processi} \[ \text{SV} = \frac{\text{BCWP} - \text{BCWS}}{\text{BCWS}} \times 100 \] - - \subparagraph{Risultato} + + \subparagraph{Risultato} \begin{itemize} - \item Un risultato \textbf{positivo} (\(> 0\)) indica che il progetto è avanti rispetto alla schedulazione; - \item Un risultato \textbf{negativo} (\(< 0\)) indica che il progetto è indietro rispetto alla schedulazione; - \item Un risultato \textbf{pari a zero} indica che il progetto è in linea rispetto alla schedulazione. + \item un risultato \textbf{positivo} (\(> 0\)) indica che il progetto è avanti rispetto alla schedulazione; + \item un risultato \textbf{negativo} (\(< 0\)) indica che il progetto è indietro rispetto alla schedulazione; + \item un risultato \textbf{pari a zero} indica che il progetto è in linea rispetto alla schedulazione. \end{itemize} - \paragraph{QM-PROC-5. Cost Variance (CV)} + \subparagraph{QM-PROC-5. Cost Variance (CV)} \subparagraph{Descrizione} - La metrica CV indica se il valore del costo realmente maturato è maggiore, minore o uguale rispetto al costo effettivo. In altre parole, permette di comprendere con che livello di efficienza il gruppo sta sviluppando il progetto, rispetto a quanto pianificato. + La metrica CV indica se il valore del costo realmente maturato è maggiore, minore o uguale rispetto al costo effettivo. In altre parole, permette di comprendere con che livello di efficienza il gruppo sta sviluppando il progetto, rispetto a quanto pianificato. \subparagraph{Unità di Misura} - La metrica viene espressa in percentuale. + La metrica viene espressa in percentuale. \subparagraph{Formula} La formula per il calcolo della metrica è la seguente: @@ -208,32 +195,32 @@ \subsection{Gestione dei Processi} \[ \text{CV} = \frac{\text{BCWP} - \text{ACWP}}{\text{BCWP}} \times 100 \] - + \subparagraph{Risultato} \begin{itemize} - \item Un risultato \textbf{positivo} (\(> 0\)) indica che il progetto sta sviluppando con un costo minore rispetto a quanto pianificato (maggiore efficienza); - \item Un risultato \textbf{negativo} (\(< 0\)) indica che il progetto sta sviluppando con un costo maggiore rispetto a quanto pianificato (minore efficienza); - \item Un risultato \textbf{pari a zero} indica che il progetto sta sviluppando con un costo in linea rispetto a quello pianificato. + \item un risultato \textbf{positivo} (\(> 0\)) indica che il progetto sta sviluppando con un costo minore rispetto a quanto pianificato (maggiore efficienza); + \item un risultato \textbf{negativo} (\(< 0\)) indica che il progetto sta sviluppando con un costo maggiore rispetto a quanto pianificato (minore efficienza); + \item un risultato \textbf{pari a zero} indica che il progetto sta sviluppando con un costo in linea rispetto a quello pianificato. \end{itemize} - \subsubsection{Gestione delle Comunicazioni} - - Le comunicazioni vengono gestite sfruttando tutte le potenzialità di \glock{Slack}, il quale permette di creare un \textit{workspace} con degli appositi canali di comunicazione. Si usano i seguenti canali e prefissi: - \begin{itemize} - \item \verb!#announcement:! canale di annunci importanti; - \item \verb!#offtopic:! canale di svago per parlare di argomenti extra-lavorativi; - \item \verb!#gen_[*]:! canali generali per il software e la documentazione; - \item \verb!#bot_[*]:! canali dedicati per le notifiche di \glock{Github} e di \glock{Google}; - \item \verb!#int_[*]:! canali specifici per i documenti interni di progetto; - \item \verb!#ext_[*]:! canali specifici per i documenti esterni di progetto; - \item \verb!#devops_[*]:! canali di notifica per le operazioni di \glock{DevOps} per i documenti interni di progetto. - \end{itemize} + \paragraph{Gestione delle comunicazioni} - Per organizzare le riunioni si fa uso di \textbf{Google Calendar}, grazie a cui è possibile fissare degli appuntamenti sul calendario comune di tutti, notificando o meno la propria presenza. - In modo più informale, infine, si fa anche uso di una chat di \textbf{Telegram} per coordinarsi su eventuali cambi di luogo o per discutere di argomenti extra-lavorativi. + Le comunicazioni vengono gestite sfruttando tutte le potenzialità di \glock{Slack}, il quale permette di creare un \textit{workspace} con degli appositi canali di comunicazione. Si usano i seguenti canali e prefissi: + \begin{itemize} + \item \verb!#announcement:! canale di annunci importanti; + \item \verb!#offtopic:! canale di svago per parlare di argomenti extra-lavorativi; + \item \verb!#gen_[*]:! canali generali per il software e la documentazione; + \item \verb!#bot_[*]:! canali dedicati per le notifiche di \glock{Github} e di \glock{Google}; + \item \verb!#int_[*]:! canali specifici per i documenti interni di progetto; + \item \verb!#ext_[*]:! canali specifici per i documenti esterni di progetto; + \item \verb!#devops_[*]:! canali di notifica per le operazioni di \glock{DevOps} per i documenti interni di progetto. + \end{itemize} + + Per organizzare le riunioni si fa uso di \textbf{Google Calendar}, grazie a cui è possibile fissare degli appuntamenti sul calendario comune di tutti, notificando o meno la propria presenza. + In modo più informale, infine, si fa anche uso di una chat di \textbf{Telegram} per coordinarsi su eventuali cambi di luogo o per discutere di argomenti extra-lavorativi. - \paragraph{Comunicazioni Interne} + \subparagraph{Comunicazioni interne} Le comunicazioni interne riguardano i soli membri del gruppo e sono volte a favorire la collaborazione e la suddivisione del lavoro tra i componenti stessi. \newline @@ -248,7 +235,7 @@ \subsection{Gestione dei Processi} Come strumento di comunicazione è stato scelto \glock{Slack}, tramite il quale è stato creato un \glock{workspace} del gruppo al cui interno sono stati predisposti diversi canali separati, uno per ogni task in svolgimento. Ogni membro del gruppo può scrivere in ognuno dei canali presenti ed ottenere informazioni riguardanti lo stato di progresso del lavoro e le eventuali problematiche riscontrate, facilitando quindi la collaborazione. \end{itemize} - \paragraph{Comunicazioni Esterne} + \subparagraph{Comunicazioni esterne} Le comunicazioni esterne riguardano, oltre ai membri del gruppo, anche il committente e l'azienda proponente, la quale si interfaccia con il gruppo tramite un suo referente interno. L'interazione con le figure esterne è di sola competenza del responsabile, il quale provvederà a tenere costantemente aggiornato il gruppo riguardo gli sviluppi del suo operato. \newline @@ -256,13 +243,13 @@ \subsection{Gestione dei Processi} Oltre alla posta elettronica, per favorire una riscontro più rapido e diretto con il proponente, quest'ultimo ha predisposto un \glock{workspace} \glock{Slack} con, all'interno, un apposito canale riservato alle comunicazioni con il gruppo. Di conseguenza il responsabile ha provveduto alla creazione di un singolo account \glock{Slack} del gruppo, utilizzato unicamente per comunicare con il proponente all'interno del canale. Per ridurre il carico di lavoro del responsabile è stato scelto di permettere l'accesso all'account sopra citato da parte di ciascun membro del gruppo, in modo da facilitare la fruizione degli argomenti trattati con il proponente. Tuttavia la partecipazione attiva al canale è permessa soltanto al responsabile. - \subsubsection{Gestione degli Incontri} + \paragraph{Gestione degli incontri} In caso di necessità, il responsabile può organizzare delle riunioni volte a trattare argomenti critici, che richiedono un confronto diretto tra tutti i componenti del gruppo ed, eventualmente, con il proponente. \newline Ogni incontro dovrà essere fissato in accordo con tutti i partecipanti, in base alle loro disponibilità. Per semplificarne la gestione, il responsabile deve creare un apposito evento su Google Calendar, tramite l'account del gruppo, con tutte le informazioni riguardanti la riunione. L'evento deve poi essere condiviso con tutti i componenti del gruppo, in modo che ne possano prendere visione ed essere immediatamente informati di eventuali modifiche tramite il servizio email di notifica di Google. - \paragraph{Incontri Interni} + \subparagraph{Incontri interni} Agli incontri interni partecipano solamente i membri del gruppo, i quali sono tenuti a farsi trovare nel luogo prestabilito entro l'orario indicato. \newline @@ -277,7 +264,7 @@ \subsection{Gestione dei Processi} Come strumento di comunicazione a chiamate è stato scelto \glock{Discord}, che permette, tramite la predisposizione di un apposito server del gruppo, di realizzare una suddivisione a canali vocali degli argomenti da trattare nelle diverse discussioni. Questi canali sono del tutto analoghi, per funzionamento, a quelli messi a disposizione da \glock{Slack}, con l'unica differenza che la comunicazione al loro interno avviene tramite chiamate vocali. \end{itemize} - \paragraph{Incontri Esterni} + \subparagraph{Incontri esterni} Negli incontri esterni, assieme ai membri del gruppo, sono coinvolti anche uno o più rappresentanti dell'azienda proponente. \newline @@ -292,7 +279,7 @@ \subsection{Gestione dei Processi} Come strumento di comunicazione a chiamate è stato scelto Skype, che permette di effettuare facilmente videochiamate con una o più persone. \end{itemize} - \paragraph{Verbali degli Incontri} + \subparagraph{Verbali degli incontri} Successivamente ad un incontro, sia esso interno od esterno, il segretario incaricato dal rappresentate ne redige il verbale. \newline @@ -312,7 +299,7 @@ \subsection{Gestione dei Processi} \item \textbf{Numero:} numero intero progressivo che fornisce un'indicazione riguardo all'ordine temporale di svolgimento degli incontri. \end{itemize} - \subsubsection{Gestione degli Strumenti di Coordinamento} + \paragraph{Gestione degli strumenti di coordinamento} In ogni momento, durante lo sviluppo del progetto, tutti i membri del gruppo devono poter sapere quali compiti sono pianificati, quali sono in corso e quali sono già stati completati. Inoltre, ognuno deve essere a conoscenza dei compiti a lui assegnati e della relativa data di scadenza per il loro completamento, in modo da poter gestire il proprio carico di lavoro. Infine, il responsabile deve poter assegnare nuovi compiti ai membri del gruppo e controllarne lo stato di avanzamento per verificarne la coerenza con la pianificazione. \newline @@ -334,7 +321,7 @@ \subsection{Gestione dei Processi} \end{itemize} È stato scelto l'\glock{Issue Tracking System} di \glock{GitHub} in quanto è completamente integrato con il \glock{repository} del progetto, è semplice da gestire e si adatta a più casi di utilizzo. - \subsubsection{Gestione dei Rischi (QP-2)} + \paragraph{Gestione dei rischi (QP-2)} I rischi che si verificano durante lo svolgimento del progetto devono essere prontamente rilevati, classificati e documentati nel \textit{Piano di Progetto}, prevedendo, inoltre, delle strategie per la loro gestione. Una volta fatto ciò, oltre a individuare nuovi rischi, è necessario monitorare i quelli noti, attuando le corrette strategie di mitigazione nel caso in cui essi si verifichino nuovamente. \newline @@ -369,7 +356,7 @@ \subsection{Gestione dei Processi} \end{itemize} - \paragraph{Introduzione alle Metriche di Qualità} + \subparagraph{Metriche di qualità} Per la gestione dei rischi si farà uso delle seguenti metriche: @@ -377,13 +364,13 @@ \subsection{Gestione dei Processi} \item QM-PROC-6. Unbudgeted Risks (UR). \end{itemize} - \paragraph{QM-PROC-6. Unbudgeted Risks (UR)} + \subparagraph{QM-PROC-6. Unbudgeted Risks (UR)} \subparagraph{Descrizione} - La metrica UR viene utilizzata per tracciare in modo incrementale tutti i nuovi rischi non precedentemente preventivati che si presentano durante una fase del progetto. + La metrica UR viene utilizzata per tracciare in modo incrementale tutti i nuovi rischi non precedentemente preventivati che si presentano durante una fase del progetto. - \subparagraph{Unità di Misura} - La metrica viene espressa con un valore intero che parte da 0. + \subparagraph{Unità di misura} + La metrica viene espressa con un valore intero che parte da 0. \subparagraph{Formula} Per ogni rischio non preventivato e non individuato precedentemente che viene rilevato, si incrementa di una unità il numero di rischi rilevati fino alla data corrente, a partire da una fase del progetto. @@ -391,13 +378,20 @@ \subsection{Gestione dei Processi} \[ \text{UR} = \text{UR} + 1 \] - + \subparagraph{Risultato} \begin{itemize} \item un valore pari a 0, indica che non sono stati trovati rischi nella fase del progetto; \item un valore superiore a 0, indica che sono stati trovati rischi nella fase del progetto. \end{itemize} + \paragraph{Esecuzione e controllo} + L'amministratore deve monitorare l'esecuzione dei processi, fornendo sia report interni per quanto riguarda lo stato di avanzamento del progetto, che report esterni verso il committente. + L'amministratore dovrà inoltre investigare, analizzare e risolvere i problemi riscontrati durante l'esecuzione dei processi, assicurandosi che l'impatto di ciascun cambiamento sia controllato, monitorato e documentato. + + \paragraph{Conclusione} + L'amministratore dovrà infine determinare se il processo in discussione possa essere considerato come concluso, documentando gli eventuali risultati forniti dalla strumentazione per quanto riguarda la completezza. + \subsubsection{Strumenti} Durante lo svolgimento del progetto, per favorire l'attuazione delle procedure descritte in precedenza, il gruppo ha scelto di utilizzare i seguenti strumenti: