Repository: SevenBitsSwe/7BitsDocs
Pull request #248: Ndp g pedice
Author: login: Sadixo
Labels: name: Verifica
description: Verifica del documento
name: Norme di progetto
description: Redazione del file Norme di progetto
Created: 2025-04-10T18:41:07Z | Merged: 2025-04-11T13:40:28Z



Diff:
diff --git a/PB/Documentazione Interna/Norme_di_progetto.pdf b/PB/Documentazione Interna/Norme_di_progetto.pdf
deleted file mode 100644
index b3323a66..00000000
Binary files a/PB/Documentazione Interna/Norme_di_progetto.pdf and /dev/null differ
diff --git a/PB/Documentazione Interna/Norme_di_progetto_v2.0.0.pdf b/PB/Documentazione Interna/Norme_di_progetto_v2.0.0.pdf
new file mode 100644
index 00000000..476af13b
Binary files /dev/null and b/PB/Documentazione Interna/Norme_di_progetto_v2.0.0.pdf differ
diff --git a/PB/Documentazione Interna/Norme_di_progetto.tex b/PB/Documentazione Interna/Norme_di_progetto_v2.0.0.tex
similarity index 95%
rename from PB/Documentazione Interna/Norme_di_progetto.tex
rename to PB/Documentazione Interna/Norme_di_progetto_v2.0.0.tex
index f1dd42e4..a07f70a0 100644
--- a/PB/Documentazione Interna/Norme_di_progetto.tex	
+++ b/PB/Documentazione Interna/Norme_di_progetto_v2.0.0.tex	
@@ -17,10 +17,10 @@
 \usepackage{float}
 \usepackage{longtable}
 
-\newcommand\version{1.0.5} %aggiunta versione come variabile
+\newcommand\version{2.0.0} %aggiunta versione come variabile
 
 \graphicspath{{images}}
-%\graphicspath{{../images/}}
+%\graphicspath{{../../images/}}
 
 % Imposta il livello di profondità dell'indice
 \setcounter{tocdepth}{4} % Aggiunge paragraph all'indice
@@ -110,18 +110,20 @@
 \hline
 \textbf{Versione} & \textbf{Data} & \textbf{Autore} & \textbf{Verificatore} & \textbf{Descrizione}\\
 \endhead
+    \hline
+    2.0.0 & 2025-04-10 & Leonardo Trolese & Manuel Gusella & Approvazione documento per PB$_G$\\
     \hline
     1.0.5 & 2025-04-03 & Federico Pivetta &  Manuel Gusella & Correzioni alle metriche e alla gestione della configurazione\\
     \hline
-    1.0.4 & 2025-03-26 & Manuel Gusella & Federico Pivetta & Aggiornamento processo di verifica della documentazione e aggiornato i ruoli\\
+    1.0.4 & 2025-03-26 & Manuel Gusella & Federico Pivetta & Aggiornamento processo$_G$ di verifica della documentazione$_G$ e aggiornato i ruoli\\
     \hline
     1.0.3 & 2025-03-26 & Leonardo Trolese & Federico Pivetta & Correzione sezione \hyperref[metriche_qualita]{metriche} a seguito di inizio stesura codice\\
     \hline
     1.0.2 & 2025-03-20 & Giovanni Cristellon & Federico Pivetta & Correzioni minori e aggiornamento della stesura dei verbali\\
     \hline
-    1.0.1 & 2025-03-12 & Federico Pivetta & Alfredo Rubino & Aggiunti paragrafi Specifica Tecnica, Manuale Utente, Qualità dell'architettura e Design Pattern\\
+    1.0.1 & 2025-03-12 & Federico Pivetta & Alfredo Rubino & Aggiunti paragrafi Specifica Tecnica, Manuale-utente$_G$, Qualità dell'architettura e Design-pattern$_G$\\
     \hline
-    1.0.0 & 2025-02-21 & Giovanni Cristellon & Manuel Gusella & Approvazione documento per RTB\\
+    1.0.0 & 2025-02-21 & Giovanni Cristellon & Manuel Gusella & Approvazione documento per RTB$_G$\\
     \hline
     0.5.18 & 2025-02-17 & Federico Pivetta & Uncas Peruzzi & Correzioni ai nomi dei documenti\\
     \hline
@@ -271,8 +273,8 @@ \section{Processi primari}
     \end{enumerate}
 
     \subsubsection{Rapporti con l'azienda proponente}
-    L'azienda proponente$_G$ SyncLab$_G$ si è resa disponibile mediante diversi canali tra cui: e-mail, Discord e Google Meet ad una comunicazione frequente con il gruppo Seven Bits, così da risolvere tempestivamente eventuali domande o dubbi che possono emergere durante lo svolgimento del progetto$_G$.\\
-    Durante la prima riunione organizzativa con l'azienda, è stata definita l'organizzazione dei periodi di sprint$_G$, inizialmente stabilendo una durata di due settimane per ciascun ciclo. Tuttavia, a seguito della revisione RTB, questa è stata ridotta ad una settimana per accelerare il ritmo di lavoro e garantire il rispetto della data di consegna.\\
+    L'azienda proponente$_G$ SyncLab$_G$ si è resa disponibile mediante diversi canali tra cui: e-mail, Discord$_G$ e Google-meet$_G$ ad una comunicazione frequente con il gruppo Seven Bits, così da risolvere tempestivamente eventuali domande o dubbi che possono emergere durante lo svolgimento del progetto$_G$.\\
+    Durante la prima riunione organizzativa con l'azienda, è stata definita l'organizzazione dei periodi di sprint$_G$, inizialmente stabilendo una durata di due settimane per ciascun ciclo. Tuttavia, a seguito della revisione RTB$_G$, questa è stata ridotta ad una settimana per accelerare il ritmo di lavoro e garantire il rispetto della data di consegna.\\
     Al termine di ogni sprint$_G$ avviene un incontro SAL$_G$ (Stato di Avanzamento Lavori), durante il quale vengono analizzati i risultati del lavoro svolto e si procede con una sprint-review$_G$. Inoltre, tra un SAL$_G$ e l'altro, secondo le necessità di proponente$_G$ e team, è possibile concordare un incontro intermedio per monitorare i progressi raggiunti e rispondere ad eventuali quesiti emersi.\\
     Ogni incontro con l'azienda viene formalizzato attraverso un verbale esterno. Tale verbale è successivamente sottoposto alla proponente$_G$ per la validazione mediante firma, in modo da ottenere un'approvazione formale del resoconto delle discussioni svolte durante la riunione.\\
 
@@ -289,22 +291,22 @@ \section{Processi primari}
         È un documento che ha l'obiettivo di garantire la qualità del prodotto e dei processi durante l'intero ciclo-di-vita$_G$ del progetto$_G$, per questo motivo sarà aggiornato nel tempo per riflettere eventuali modifiche e i risultati delle verifiche effettuate. Include le sezioni sulla qualità di processo$_G$, sulla qualità di prodotto, le modalità di testing e il cruscotto$_G$ di valutazione delle qualità.\\
 
         \paragraph{Specifica Tecnica}
-        È un documento che descrive gli aspetti tecnici e progettuali del prodotto software, offrendo una visione dell'architettura implementativa e di deployment attraverso l'analisi di moduli, design pattern e scelte tecnologiche. Ha l'obiettivo di monitorare le decisioni progettuali, guidare lo sviluppo e garantire la tracciabilità dei requisiti, costituendo così un punto di riferimento fondamentale per tutti gli stakeholder.\\
+        È un documento che descrive gli aspetti tecnici e progettuali del prodotto software, offrendo una visione dell'architettura implementativa e di deployment attraverso l'analisi di moduli, design-pattern$_G$ e scelte tecnologiche. Ha l'obiettivo di monitorare le decisioni progettuali, guidare lo sviluppo e garantire la tracciabilità dei requisiti, costituendo così un punto di riferimento fondamentale per tutti gli stakeholder$_G$.\\
 
         \paragraph{Manuale Utente}
-        È un documento che fornisce una guida sull'utilizzo della piattaforma software "NearYou - Smart custom advertising platform", sviluppata per l'azienda proponente SyncLab$_G$. Descrive le principali funzionalità, le modalità di interazione e le opzioni di personalizzazione, oltre a fornire informazioni sui requisiti minimi, le procedure di configurazione e come sfruttare al meglio le potenzialità del sistema.\\
+        È un documento che fornisce una guida sull'utilizzo della piattaforma software "NearYou - Smart custom advertising platform", sviluppata per l'azienda proponente$_G$ SyncLab$_G$. Descrive le principali funzionalità, le modalità di interazione e le opzioni di personalizzazione, oltre a fornire informazioni sui requisiti minimi, le procedure di configurazione e come sfruttare al meglio le potenzialità del sistema$_G$.\\
 
         \paragraph{Glossario}
         È un documento che raccoglie dei termini specifici e le loro definizioni chiare e concise. Il suo scopo è quello di facilitare la comprensione dei concetti chiave presenti nei vari documenti redatti.\\
 
         \paragraph{Lettera di Presentazione}
-        La Lettera di Presentazione è un documento che accompagna la consegna del prodotto software e della relativa documentazione$_G$ durante le fasi di revisione di progetto$_G$. Il contenuto di questo documento comprende un link alla pagina web che contiene tutta la documentazione$_G$ finora prodotta, un preventivo aggiornato rispetto a quello presentato alla revisione precedente, e dei link alle varie repository del gruppo.\\
+        La Lettera di Presentazione è un documento che accompagna la consegna del prodotto software e della relativa documentazione$_G$ durante le fasi di revisione di progetto$_G$. Il contenuto di questo documento comprende un link alla pagina web che contiene tutta la documentazione$_G$ finora prodotta, un preventivo aggiornato rispetto a quello presentato alla revisione precedente, e dei link alle varie repository$_G$ del gruppo.\\
 
     \subsubsection{Strumenti}
     Gli strumenti utilizzati per la gestione del processo$_G$ di fornitura sono i seguenti:
     \begin{itemize}
         \item \textbf{Canva}: Piattaforma che permette la creazione di presentazioni multimediali, utilizzata per la realizzazione dei diari di bordo;
-        \item \textbf{Google Meet e Discord}: Servizi che permettono di effettuare videochiamate, utilizzati dal team per le discussioni sincrone e asincrone con la proponente$_G$;
+        \item \textbf{Google Meet e Discord$_G$}: Servizi che permettono di effettuare videochiamate, utilizzati dal team per le discussioni sincrone e asincrone con la proponente$_G$;
         \item \textbf{Google Sheets}: Servizio che permette la creazione di fogli di calcolo, utilizzato dal gruppo per la rendicontazione delle ore produttive impiegate durante ogni sprint$_G$.
     \end{itemize}
 
@@ -315,7 +317,7 @@ \section{Processi primari}
     Le linee guida descritte in questa sezione sono volte a strutturare il lavoro in modo chiaro e uniforme, promuovendo la qualità del prodotto finale. Seguendo standard solidi e definiti, nel caso specifico l'ISO/IEC 12207:1995, si crea un ambiente di lavoro orientato a garantire la coerenza nei metodi utilizzati e il rispetto delle aspettative.\\
     L'obiettivo è consegnare un prodotto software di alta qualità, che soddisfi le esigenze richieste, rispettando le tempistiche e garantendo il successo del progetto$_G$.\\
 
-    \subsubsection{Analisi-dei-Requisiti}
+    \subsubsection{Analisi dei Requisiti}
     \label{analisi}
         \paragraph{Descrizione e Scopo}
         L'Analisi-dei-Requisiti$_G$ è la prima fase cruciale del processo$_G$ di sviluppo software. Lo scopo principale di questa fase è definire con chiarezza le funzionalità e le caratteristiche che il sistema$_G$ dovrà offrire, in base alle necessità degli utenti. Per raggiungere tale obiettivo, è essenziale stabilire una comunicazione efficace con la proponente$_G$, assicurandosi che tutte le esigenze siano documentate e validate. Questo processo$_G$ permette di chiarire gli obiettivi del prodotto, identificare i vincoli operativi e fornire ai Progettisti le informazioni necessarie per sviluppare un'architettura coerente e un design adeguato. Il risultato di questa attività è formalizzato nel documento \textit{Analisi\_dei\_Requisiti}, redatto dagli Analisti, che contiene una descrizione dettagliata degli obiettivi del prodotto, delle funzionalità previste e delle caratteristiche degli utenti. Include inoltre una sezione dedicata ai casi d'uso, che descrivono le interazioni tra gli attori e il sistema$_G$.\\
@@ -361,7 +363,7 @@ \section{Processi primari}
             \begin{figure}[H]
             \centering
             \includegraphics[width=0.45\textwidth]{Attore.PNG}
-            \caption{Rappresentazione di un attore$_G$.}
+            \caption{Rappresentazione di un attore.}
             \end{figure}
 
             \item \textbf{Casi d'uso}\\
@@ -370,7 +372,7 @@ \section{Processi primari}
             \begin{figure}[H]
             \centering
             \includegraphics[width=0.30\textwidth]{UC.PNG}
-            \caption{Rappresentazione di un caso-d'uso$_G$.}
+            \caption{Rappresentazione di un caso-d'uso.}
             \end{figure}
 
             \item \textbf{Sottocasi d'uso}\\
@@ -386,7 +388,7 @@ \section{Processi primari}
             \begin{figure}[H]
             \centering
             \includegraphics[width=0.4\textwidth]{Sistema.PNG}
-            \caption{Rappresentazione di un sistema$_G$.}
+            \caption{Rappresentazione di un sistema.}
             \end{figure}
 
             \item \textbf{Associazione}\\
@@ -394,7 +396,7 @@ \section{Processi primari}
             \begin{figure}[H]
             \centering
             \includegraphics[width=0.5\textwidth]{AssociazioneAttore.PNG}
-            \caption{Rappresentazione di una associazione tra attore$_G$ e UC.}
+            \caption{Rappresentazione di una associazione tra attore e UC.}
             \end{figure}
 
             \item \textbf{Generalizzazione (attori)}\\
@@ -486,7 +488,7 @@ \section{Processi primari}
             MPD03 & Requisiti Opzionali Soddisfatti\\
             \hline
           \end{tabular}
-          \caption{Metriche relative all'attività di analisi-dei-requisiti}
+          \caption{Metriche relative all'attività di analisi dei requisiti}
         \end{table}
 
     \subsubsection{Progettazione}
@@ -496,10 +498,10 @@ \section{Processi primari}
         Prima di avviare la progettazione vera e propria, si intraprende una fase preliminare che prevede la creazione di un PoC$_G$ (Proof of Concept), un prototipo preliminare "usa e getta" realizzato per dimostrare la fattibilità tecnologica del prodotto previsto. Questa fase serve a confermare le tecnologie da adottare e a definire insieme alla proponente$_G$ le componenti principali che costituiranno l'MVP (Minimum Viable Product).\\
 
         \paragraph{Qualità dell'architettura}
-        Una buona architettura software è fondamentale per il successo di un progetto. Di seguito sono elencate le principali qualità che caratterizzano una buona architettura:
+        Una buona architettura software è fondamentale per il successo di un progetto$_G$. Di seguito sono elencate le principali qualità che caratterizzano una buona architettura:
         \begin{itemize}
-            \item \textbf{Sufficienza}: l'architettura soddisfa tutti i requisti funzionali e non funzionali definiti per il sistema;
-            \item \textbf{Comprensibilità}: l'architettura è facilmente comprensibile da tutti gli stakeholder, facilitando la manutenzione e l'evoluzione del sistema;
+            \item \textbf{Sufficienza}: l'architettura soddisfa tutti i requisti funzionali e non funzionali definiti per il sistema$_G$;
+            \item \textbf{Comprensibilità}: l'architettura è facilmente comprensibile da tutti gli stakeholder$_G$, facilitando la manutenzione e l'evoluzione del sistema$_G$;
             \item \textbf{Modularità}: l'architettura è suddivisa in moduli separati e indipendenti, che possono essere sviluppati, testati e aggiornati autonomamente;
             \item \textbf{Robustezza}: l'architettura è progettata per essere resistente a diversi tipi di ingressi, gestendo correttamente anche condizioni di errore o situazioni impreviste;
             \item \textbf{Flessibilità}: l'architettura può adattarsi facilmente a nuovi requisiti, cambiamenti o evoluzione delle tecnologie senza richiedere modifiche radicali o strutturali;
@@ -507,12 +509,12 @@ \section{Processi primari}
             \item \textbf{Efficienza}: l'architettura è progettata per ottimizzare l'utilizzo delle risorse, garantendo prestazioni elevate con il minor consumo di risorse possibile;
             \item \textbf{Affidabilità}: la capacità del software di svolgere correttamente le sue funzioni in modo coerente e prevedibile nel tempo;
             \item \textbf{Disponibilità}: il software è disponibile e operativo quando richiesto, riducendo al minimo i periodi di inattività;
-            \item \textbf{Sicurezza rispetto a malfunzionamenti}: l'architettura è progettata per garantire che il sistema continui a funzionare correttamente anche in caso di guasti o malfunzionamenti;
-            \item \textbf{Sicurezza rispetto a intrusioni}: il sistema è protetto da accessi non autorizzati e tentativi di intrusione, garantendo la riservatezza e l'integrità dei dati;
+            \item \textbf{Sicurezza rispetto a malfunzionamenti}: l'architettura è progettata per garantire che il sistema$_G$ continui a funzionare correttamente anche in caso di guasti o malfunzionamenti;
+            \item \textbf{Sicurezza rispetto a intrusioni}: il sistema$_G$ è protetto da accessi non autorizzati e tentativi di intrusione, garantendo la riservatezza e l'integrità dei dati;
             \item \textbf{Semplicità}: l'architettura è il più semplice possibile, riducendo la complessità e facilitando la comprensione, la manutenzione e l'evoluzione;
             \item \textbf{Incapsulazione}: i dettagli implementativi interni delle componenti sono nascosti all'esterno, permettendo l'accesso solo attraverso un'interfaccia definita;
             \item \textbf{Coesione}: la misura in cui i componenti all'interno di un modulo o un'unità lavorano insieme per un obiettivo comune senza essere eccessivamente interdipendenti;
-            \item \textbf{Basso accoppiamento}: il grado di dipendenza tra i diversi moduli o componenti del software deve essere minimizzato per migliorare la manutenibilità e flessibilità del sistema.
+            \item \textbf{Basso accoppiamento}: il grado di dipendenza tra i diversi moduli o componenti del software deve essere minimizzato per migliorare la manutenibilità e flessibilità del sistema$_G$.
         \end{itemize}
 
         \paragraph{Diagrammi delle classi}
@@ -589,13 +591,13 @@ \section{Processi primari}
         \end{itemize}
 
         \paragraph{Design Pattern}
-        I design pattern costituiscono delle soluzioni progettuali consolidate a problemi ricorrenti nello sviluppo software. Essi rappresentano delle best practices che permettono di migliorare la qualità, la manutenibilità e la scalabilità del codice, facilitando la comprensione e la comunicazione tra sviluppatori. I design pattern non sono implementazioni specifiche, ma schemi generali che possono essere adattati a diversi contesti e linguaggi di programmazione. Essi si suddividono in tre categorie principali:
+        I design-pattern$_G$ costituiscono delle soluzioni progettuali consolidate a problemi ricorrenti nello sviluppo software. Essi rappresentano delle best-practices$_G$ che permettono di migliorare la qualità, la manutenibilità e la scalabilità del codice, facilitando la comprensione e la comunicazione tra sviluppatori. I design-pattern$_G$ non sono implementazioni specifiche, ma schemi generali che possono essere adattati a diversi contesti e linguaggi di programmazione. Essi si suddividono in tre categorie principali:
         \begin{itemize}
-            \item \textbf{Creazionali}: gestiscono il processo di creazione degli oggetti in modo flessibile ed efficiente (es. Singleton, Builder o Abstract Factory);
+            \item \textbf{Creazionali}: gestiscono il processo$_G$ di creazione degli oggetti in modo flessibile ed efficiente (es. Singleton, Builder o Abstract Factory);
             \item \textbf{Strutturali}: definiscono le modalità per semplificare e ottimizzare la struttura del codice (es. Adapter, Decorator, Facade o Proxy);
             \item \textbf{Comportamentali}: migliorano la comunicazione e cooperazione tra gli oggetti (es. Command, Iterator, Observer, Strategy o Template Method).
         \end{itemize}
-        L'adozione dei design pattern può introdurre un certo grado di complessità nel codice, pertanto è fondamentale valutarne l'utilizzo con attenzione. È importante adottarli solo quando i benefici giustificano l'aumento della complessità, evitando di rendere il sistema più difficile da comprendere e gestire qualora non sia necessario.
+        L'adozione dei design-pattern$_G$ può introdurre un certo grado di complessità nel codice, pertanto è fondamentale valutarne l'utilizzo con attenzione. È importante adottarli solo quando i benefici giustificano l'aumento della complessità, evitando di rendere il sistema$_G$ più difficile da comprendere e gestire qualora non sia necessario.
 
         \paragraph{Metriche}
         \begin{table}[H]
@@ -681,7 +683,7 @@ \section{Processi primari}
     Gli strumenti utilizzati per la gestione del processo$_G$ di sviluppo sono i seguenti:
     \begin{itemize}
         \item \textbf{Draw.io}: Software utilizzato per creare diagrammi e grafici di vario tipo, in particolare è stato impiegato per realizzare i diagrammi UML$_G$ per i casi d'uso, nel documento di \textit{Analisi\_dei\_Requisiti};
-        \item \textbf{StarUML}: Software per la modellazione UML utilizzato per creare diagrammi delle classi e altri diagrammi di progettazione software, in particolare è stato impiegato per definire l'architettura del nostro prodotto software;
+        \item \textbf{StarUML}: Software per la modellazione UML$_G$ utilizzato per creare diagrammi delle classi e altri diagrammi di progettazione software, in particolare è stato impiegato per definire l'architettura del nostro prodotto software;
         \item \textbf{Visual Studio Code}: L'IDE principale scelto per la codifica, grazie alla sua versatilità e facilità d'uso.
     \end{itemize}
 
@@ -753,7 +755,7 @@ \section{Processi di supporto}
 
         \paragraph{Verbali}
         I verbali sono dei documenti di sintesi di un incontro che sia interno al team o esterno con l'azienda, per questo motivo la loro struttura è diversa rispetto agli altri documenti ufficiali.\\
-        La differenza più lampante è la mancanza del registro modifiche al loro interno, visto che sono documenti che non hanno bisogno di un ciclo di vita prolungato.\\
+        La differenza più lampante è la mancanza del registro modifiche al loro interno, visto che sono documenti che non hanno bisogno di un ciclo-di-vita$_G$ prolungato.\\
         I verbali hanno lo scopo di tenere traccia di chi ha partecipato agli incontri ed in particolare quali decisioni sono state prese.\\
         Sono composti da 2 sezioni principali:
         \begin{itemize}
@@ -834,29 +836,29 @@ \section{Processi di supporto}
         \begin{enumerate}
             \item Creazione di un branch$_G$ dedicato esclusivamente alla redazione di un documento specifico;
             \item Creazione del documento a partire da un template comune a tutti i documenti (esclusi i verbali). La versione iniziale del documento corrisponde a \{0.1.0\};
-            \item Creazione di un branch di feauture per la redazione di una sezione del documento, o per una modifica da apportare al documento partendo dal branch$_G$ del documento;
+            \item Creazione di un branch$_G$ di feauture per la redazione di una sezione del documento, o per una modifica da apportare al documento partendo dal branch$_G$ del documento;
             \item Compilazione dei campi della sezione Registro modifiche;
             \item Creazione di una pull-request dal branch$_G$ di feauture, precedentemente creato, al branch$_G$ del documento desiderato;
             \item Verifica della documentazione$_G$ prodotta da parte del Verificatore indicato nel Registro modifiche e associato alle modifiche effettuate in quella seduta di lavoro;
             \item Se ci sono correzioni o ulteriori modifiche da effettuare, queste devono essere prima indicate tramite suggestion, attraverso la sezione di Review della pull-request, e successivamente apportate alla feature in cui si sta lavorando;
-            \item Se la pull-request viene approvata, si esegue il merge$_G$ nel branch del documento e si elimina il branch di feature creato;
+            \item Se la pull-request viene approvata, si esegue il merge$_G$ nel branch$_G$ del documento e si elimina il branch$_G$ di feature creato;
             \item Si ripetono le operazioni indicate dal punto \{3\} al punto \{8\} fino a quando il documento non è stato completato;
             \item Quando il documento è completo si aprirà una pull-request verso il branch$_G$ Main e, dopo l'approvazione del documento da parte dei due Verificatori presenti durante il periodo di lavoro, si esegue il merge$_G$ nel branch$_G$ Main. Successivamente, si procede ad eliminare il branch$_G$ dedicato, solo se non sono previsti ulteriori sviluppi.
         \end{enumerate}
 
     \subsubsection{Ciclo di vita del software}
-    Il ciclo di vita del software adottato si basa su un approccio ispirato al modello di Gitflow semplificato.
-    In particolare, si fa uso di branch$_G$ derivati da Main, con verifiche e merge che rispettano il workflow descritto di seguito.
+    Il ciclo-di-vita$_G$ del software adottato si basa su un approccio ispirato al modello di Gitflow semplificato.
+    In particolare, si fa uso di branch$_G$ derivati da Main, con verifiche e merge$_G$ che rispettano il workflow descritto di seguito.
 
     \paragraph{Workflow Software}
     Il software segue il seguente workflow:
     \begin{itemize}
         \item Creazione di un nuovo branch$_G$ funzionale derivato da un branch$_G$ collettivo, il quale a sua volta deriva direttamente dal branch$_G$ Main. Ogni branch$_G$ collettivo è dedicato a un gruppo di funzionalità correlate o a una specifica fase dello sviluppo;
         \item Sviluppo della parte assegnata nel branch$_G$ funzionale. Ogni modifica rilevante deve essere tracciata mediante issue$_G$ associata;
-        \item Test locale e/o automatizzato della funzionalità sviluppata, con l'obiettivo di garantirne il corretto funzionamento e l'assenza di regressioni. Al termine, viene aperta una pull-request$_G$ (PR) per richiedere il merge$_G$ nel branch$_G$ collettivo;
+        \item Test$_G$ locale e/o automatizzato della funzionalità sviluppata, con l'obiettivo di garantirne il corretto funzionamento e l'assenza di regressioni. Al termine, viene aperta una pull-request$_G$ (PR) per richiedere il merge$_G$ nel branch$_G$ collettivo;
         \item Merge$_G$ del branch$_G$ funzionale nel branch$_G$ collettivo, effettuato solo dopo la validazione della funzionalità da parte di un Verificatore;
-        \item Eliminazione del branch$_G$ funzionale una volta completato il merge$_G$ nel branch$_G$ collettivo, al fine di mantenere ordinata la struttura della repository;
-        \item Verifica del branch$_G$ collettivo da parte del Verificatore, che controlla la coerenza tra le parti, l'integrabilità delle componenti e l'assenza di conflitti. Tale verifica include l'analisi del risultato delle GitHub Actions, che eseguono test automatizzati e restituiscono metriche tramite badge integrati nella PR;
+        \item Eliminazione del branch$_G$ funzionale una volta completato il merge$_G$ nel branch$_G$ collettivo, al fine di mantenere ordinata la struttura della repository$_G$;
+        \item Verifica del branch$_G$ collettivo da parte del Verificatore, che controlla la coerenza tra le parti, l'integrabilità delle componenti e l'assenza di conflitti. Tale verifica include l'analisi del risultato delle GitHub-actions$_G$, che eseguono test$_G$ automatizzati e restituiscono metriche tramite badge integrati nella PR;
         \item Creazione di una pull-request$_G$ dal branch$_G$ collettivo al branch$_G$ Main, subordinata all’approvazione di tutte le modifiche da parte del Verificatore;
         \item Solo a seguito della verifica positiva e dell'approvazione formale della PR è consentito il merge$_G$ definitivo nel branch$_G$ Main.
     \end{itemize}
@@ -866,7 +868,7 @@ \section{Processi di supporto}
     \begin{itemize}
         \item \href{https://github.com/SevenBitsSwe/7BitsDocs}{https://github.com/SevenBitsSwe/7BitsDocs}: questa repository$_G$ è utilizzata per revisionare e mantenere aggiornati i documenti redatti, permettendo ai membri del gruppo di gestire in modo efficiente la documentazione$_G$;
         \item \href{https://github.com/SevenBitsSwe/PoC}{https://github.com/SevenBitsSwe/PoC}: questa repository$_G$ è dedicata alla condivisione e verifica del codice sorgente relativo al prodotto software realizzato per la revisione RTB$_G$. Viene utilizzata dal team per lavorare sul codice del prodotto, consentendo una gestione centralizzata dello sviluppo e delle modifiche apportate al software;
-        \item \href{https://github.com/SevenBitsSwe/MVP}{https://github.com/SevenBitsSwe/MVP}: questa repository$_G$ è usata per la condivisione e la verifica del codice sorgente relativo al prodotto software realizzato per la revisione PB$_G$. Viene utilizzata dal team per lavorare sul codice del MVP.
+        \item \href{https://github.com/SevenBitsSwe/MVP}{https://github.com/SevenBitsSwe/MVP}: questa repository$_G$ è usata per la condivisione e la verifica del codice sorgente relativo al prodotto software realizzato per la revisione PB$_G$. Viene utilizzata dal team per lavorare sul codice del MVP$_G$.
     \end{itemize}
 
         \paragraph{Struttura della repository 7BitsDocs}
@@ -951,7 +953,7 @@ \section{Processi di supporto}
     \paragraph{Classificazione dei test}
     I test$_G$ vengono identificati in base alla loro tipologia e tramite un codice numerico, specifico all'interno della categoria. I test$_G$ devono avere la seguente forma:
     \begin{quote}
-    \textbf{T[Tipologia Test][Codice]}\\
+    \textbf{T[Tipologia Test$_G$][Codice]}\\
     \end{quote}
     Dove:
     \item [-] \textbf{Tipologia}:
@@ -1132,8 +1134,8 @@ \section{Processi organizzativi}
             \item \textbf{Priorità}: assegna un livello di urgenza o importanza alla issue$_G$ (Urgente, Importante, Moderato, Secondario);
             \item \textbf{Grandezza}: stima la complessità o il livello di sforzo richiesto per completare il compito (XS, S, M, L, XL);
             \item \textbf{Iterazione}: specifica a quale sprint$_G$ la issue$_G$ è assegnata;
-            \item \textbf{Data di inizio}: data in cui viene iniziato il lavoro descritto dalla issue;
-            \item \textbf{Data di fine}: data in cui viene terminata la issue.
+            \item \textbf{Data di inizio}: data in cui viene iniziato il lavoro descritto dalla issue$_G$;
+            \item \textbf{Data di fine}: data in cui viene terminata la issue$_G$.
         \end{itemize}
         \item \textbf{Milestone}: identifica il traguardo o obiettivo specifico a cui la issue$_G$ è associata.
     \end{itemize}
@@ -1176,11 +1178,11 @@ \section{Processi organizzativi}
     Le comunicazioni si suddividono in:
 
         \paragraph{Comunicazioni interne}
-        Le comunicazioni interne avverranno attraverso due canali principali: Telegram e Discord. Telegram, un servizio di messaggistica istantanea, sarà utilizzato per le conversazioni rapide e informali, mentre Discord, una piattaforma che supporta chat e videochiamate, sarà impiegato per le riunioni a distanza e le discussioni più complesse.\\
-        Le attività quotidiane e le comunicazioni generali si svolgeranno su Telegram, mentre le questioni critiche saranno affrontate durante degli incontri su Discord.
+        Le comunicazioni interne avverranno attraverso due canali principali: Telegram e Discord$_G$. Telegram, un servizio di messaggistica istantanea, sarà utilizzato per le conversazioni rapide e informali, mentre Discord$_G$, una piattaforma che supporta chat e videochiamate, sarà impiegato per le riunioni a distanza e le discussioni più complesse.\\
+        Le attività quotidiane e le comunicazioni generali si svolgeranno su Telegram, mentre le questioni critiche saranno affrontate durante degli incontri su Discord$_G$.
 
         \paragraph{Comunicazioni esterne}
-        Le comunicazioni esterne avverranno tramite scambio di email, utilizzando l'indirizzo sevenbits.swe.unipd@gmail.com. Questo canale sarà utilizzato per organizzare incontri con la proponente$_G$, inviare documenti da visionare o firmare. Inoltre, su Discord è presente una sezione testuale dedicata alle comunicazioni rapide o dubbi con la proponente$_G$.
+        Le comunicazioni esterne avverranno tramite scambio di email, utilizzando l'indirizzo sevenbits.swe.unipd@gmail.com. Questo canale sarà utilizzato per organizzare incontri con la proponente$_G$, inviare documenti da visionare o firmare. Inoltre, su Discord$_G$ è presente una sezione testuale dedicata alle comunicazioni rapide o dubbi con la proponente$_G$.
 
     \subsubsection{Riunioni}
     Le riunioni sono fondamentali per il progresso del progetto$_G$, poiché offrono l'opportunità di confrontarsi, prendere decisioni e risolvere eventuali problematiche. Servono anche per monitorare lo stato di avanzamento delle attività e garantire il raggiungimento degli obiettivi prefissati.
@@ -1188,10 +1190,10 @@ \section{Processi organizzativi}
     Le riunioni si distinguono in:
 
         \paragraph{Riunioni interne}
-        Le riunioni interne sono pianificate settimanalmente ogni mercoledì alle ore 16:00 o, in alternativa, subito dopo le riunioni esterne. In caso di necessità, possono essere richieste riunioni straordinarie durante la settimana, organizzate tramite un sondaggio sul canale Telegram. Tutte le riunioni si terranno sul canale Discord del gruppo. I membri del gruppo si impegnano a partecipare attivamente, cercando di garantire la loro presenza. In caso di impossibilità a partecipare, ogni membro potrà recuperare la sintesi delle discussioni e le decisioni prese leggendo il verbale della riunione.
+        Le riunioni interne sono pianificate settimanalmente ogni mercoledì alle ore 16:00 o, in alternativa, subito dopo le riunioni esterne. In caso di necessità, possono essere richieste riunioni straordinarie durante la settimana, organizzate tramite un sondaggio sul canale Telegram. Tutte le riunioni si terranno sul canale Discord$_G$ del gruppo. I membri del gruppo si impegnano a partecipare attivamente, cercando di garantire la loro presenza. In caso di impossibilità a partecipare, ogni membro potrà recuperare la sintesi delle discussioni e le decisioni prese leggendo il verbale della riunione.
 
         \paragraph{Riunioni esterne}
-        Le riunioni esterne coinvolgono i membri del gruppo, la proponente$_G$ e i committenti. Gli incontri con la proponente$_G$ si terranno sulla piattaforma Google Meet, con l'indirizzo comunicato al gruppo dall'azienda. I membri del gruppo si impegnano a partecipare attivamente, cercando di garantire la loro presenza. In caso di impossibilità a partecipare, ogni membro potrà recuperare la sintesi delle discussioni e le decisioni prese leggendo il verbale della riunione.
+        Le riunioni esterne coinvolgono i membri del gruppo, la proponente$_G$ e i committenti. Gli incontri con la proponente$_G$ si terranno sulla piattaforma Google-meet$_G$, con l'indirizzo comunicato al gruppo dall'azienda. I membri del gruppo si impegnano a partecipare attivamente, cercando di garantire la loro presenza. In caso di impossibilità a partecipare, ogni membro potrà recuperare la sintesi delle discussioni e le decisioni prese leggendo il verbale della riunione.
 
     \subsection{Miglioramento}
     \label{miglioramento}


Reviews:
user: login: Sadixo
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-10T18:42:41Z
user: login: alfredorubino
state: APPROVED
author_association: CONTRIBUTOR
submitted_at: 2025-04-10T19:12:23Z
user: login: alfredorubino
state: DISMISSED
author_association: CONTRIBUTOR
submitted_at: 2025-04-10T19:16:39Z
user: login: Aniysi
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-11T09:59:45Z
user: login: Aniysi
state: APPROVED
author_association: CONTRIBUTOR
submitted_at: 2025-04-11T13:40:07Z

Review comments:
diff_hunk: @@ -1469,7 +1471,7 @@ \subsubsection{Portabilità}
       \end{itemize}
 \end{itemize}
 
-\subsection{Metriche di qualità di Processo}
+\subsection{Metriche di qualità di Processo$_G$}
path: PB/Documentazione Interna/Norme_di_progetto_v2.0.0.tex
user: login: Sadixo
body: ```suggestion
\subsection{Metriche di qualità di Processo}
```
created_at: 2025-04-10T18:42:35Z
author_association: CONTRIBUTOR
diff_hunk: @@ -922,7 +924,7 @@ \section{Processi di supporto}
 
     \paragraph{Test di unità}
     Test$_G$ eseguiti su singole unità del software, come funzioni o metodi, in modo indipendente dal resto del sistema$_G$. L'obiettivo è assicurare che ogni unità di codice funzioni correttamente.\\
-    Devono essere eseguiti per primi visto che le unità garantiscono il corretto funzionamento dei singoli metodi che poi verranno integrati tra di loro.\\
+    Devono essere eseguiti per primi visto che le unità garantiscono il corretto funzionamento dei singoli metodi che PoI$_G$ verranno integrati tra di loro.\\
path: PB/Documentazione Interna/Norme_di_progetto_v2.0.0.tex
user: login: alfredorubino
body: ```suggestion
    Devono essere eseguiti per primi visto che le unità garantiscono il corretto funzionamento dei singoli metodi che poi verranno integrati tra di loro.\\
```
created_at: 2025-04-10T19:16:19Z
author_association: CONTRIBUTOR
diff_hunk: @@ -834,29 +836,29 @@ \section{Processi di supporto}
         \begin{enumerate}
             \item Creazione di un branch$_G$ dedicato esclusivamente alla redazione di un documento specifico;
             \item Creazione del documento a partire da un template comune a tutti i documenti (esclusi i verbali). La versione iniziale del documento corrisponde a \{0.1.0\};
-            \item Creazione di un branch di feauture per la redazione di una sezione del documento, o per una modifica da apportare al documento partendo dal branch$_G$ del documento;
+            \item Creazione di un branch$_G$ di feauture per la redazione di una sezione del documento, o per una modifica da apportare al documento partendo dal branch$_G$ del documento;
             \item Compilazione dei campi della sezione Registro modifiche;
             \item Creazione di una pull-request dal branch$_G$ di feauture, precedentemente creato, al branch$_G$ del documento desiderato;
             \item Verifica della documentazione$_G$ prodotta da parte del Verificatore indicato nel Registro modifiche e associato alle modifiche effettuate in quella seduta di lavoro;
             \item Se ci sono correzioni o ulteriori modifiche da effettuare, queste devono essere prima indicate tramite suggestion, attraverso la sezione di Review della pull-request, e successivamente apportate alla feature in cui si sta lavorando;
-            \item Se la pull-request viene approvata, si esegue il merge$_G$ nel branch del documento e si elimina il branch di feature creato;
+            \item Se la pull-request viene approvata, si esegue il merge$_G$ nel branch$_G$ del documento e si elimina il branch$_G$ di feature creato;
             \item Si ripetono le operazioni indicate dal punto \{3\} al punto \{8\} fino a quando il documento non è stato completato;
             \item Quando il documento è completo si aprirà una pull-request verso il branch$_G$ Main e, dopo l'approvazione del documento da parte dei due Verificatori presenti durante il periodo di lavoro, si esegue il merge$_G$ nel branch$_G$ Main. Successivamente, si procede ad eliminare il branch$_G$ dedicato, solo se non sono previsti ulteriori sviluppi.
         \end{enumerate}
 
     \subsubsection{Ciclo di vita del software}
-    Il ciclo di vita del software adottato si basa su un approccio ispirato al modello di Gitflow semplificato.
-    In particolare, si fa uso di branch$_G$ derivati da Main, con verifiche e merge che rispettano il workflow descritto di seguito.
+    Il ciclo-di-vita$_G$ del software adottato si basa su un approccio ispirato al modello di Gitflow semplificato.
+    In particolare, si fa uso di branch$_G$ derivati da Main, con verifiche e merge$_G$ che rispettano il workflow descritto di seguito.
 
     \paragraph{Workflow Software}
     Il software segue il seguente workflow:
     \begin{itemize}
         \item Creazione di un nuovo branch$_G$ funzionale derivato da un branch$_G$ collettivo, il quale a sua volta deriva direttamente dal branch$_G$ Main. Ogni branch$_G$ collettivo è dedicato a un gruppo di funzionalità correlate o a una specifica fase dello sviluppo;
         \item Sviluppo della parte assegnata nel branch$_G$ funzionale. Ogni modifica rilevante deve essere tracciata mediante issue$_G$ associata;
-        \item Test locale e/o automatizzato della funzionalità sviluppata, con l'obiettivo di garantirne il corretto funzionamento e l'assenza di regressioni. Al termine, viene aperta una pull-request$_G$ (PR) per richiedere il merge$_G$ nel branch$_G$ collettivo;
+        \item Test$_G$ locale e/o automatizzato della funzionalità sviluppata, con l'obiettivo di garantirne il corretto funzionamento e l'assenza di regressioni. Al termine, viene aperta una pull-request$_G$ (PR) per richiedere il merge$_G$ nel branch$_G$ collettivo;
         \item Merge$_G$ del branch$_G$ funzionale nel branch$_G$ collettivo, effettuato solo dopo la validazione della funzionalità da parte di un Verificatore;
-        \item Eliminazione del branch$_G$ funzionale una volta completato il merge$_G$ nel branch$_G$ collettivo, al fine di mantenere ordinata la struttura della repository;
-        \item Verifica del branch$_G$ collettivo da parte del Verificatore, che controlla la coerenza tra le parti, l'integrabilità delle componenti e l'assenza di conflitti. Tale verifica include l'analisi del risultato delle GitHub Actions, che eseguono test automatizzati e restituiscono metriche tramite badge integrati nella PR;
+        \item Eliminazione del branch$_G$ funzionale una volta completato il merge$_G$ nel branch$_G$ collettivo, al fine di mantenere ordinata la struttura della repository$_G$;
+        \item Verifica del branch$_G$ collettivo da parte del Verificatore, che controlla la coerenza tra le parti, l'integrabilità delle componenti e l'assenza di conflitti. Tale verifica include l'analisi del risultato delle Github-actions$_G$, che eseguono test$_G$ automatizzati e restituiscono metriche tramite badge integrati nella PR;
path: PB/Documentazione Interna/Norme_di_progetto_v2.0.0.tex
user: login: Aniysi
body: ```suggestion
        \item Verifica del branch$_G$ collettivo da parte del Verificatore, che controlla la coerenza tra le parti, l'integrabilità delle componenti e l'assenza di conflitti. Tale verifica include l'analisi del risultato delle GitHub-actions$_G$, che eseguono test$_G$ automatizzati e restituiscono metriche tramite badge integrati nella PR;
```
created_at: 2025-04-11T09:58:53Z
author_association: CONTRIBUTOR

PR comments:
user: login: Aniysi
created_at: 2025-04-11T10:30:13Z
body: Ho commitatto le review (sia mie che di alfredo) e ricompilato, ora dovremmo poter fare la merge 
author_association: CONTRIBUTOR
user: login: Sadixo
created_at: 2025-04-11T12:10:44Z
body: > Ho commitatto le review (sia mie che di alfredo) e ricompilato, ora dovremmo poter fare la merge

è da approvare la PR
author_association: CONTRIBUTOR