diff --git a/Norme di progetto.pdf b/Norme di progetto.pdf index 87eaaf0..2267aba 100644 Binary files a/Norme di progetto.pdf and b/Norme di progetto.pdf differ diff --git a/SorgentiTex/Norme di progetto/main.tex b/SorgentiTex/Norme di progetto/main.tex index 48b1fc5..80cf3a2 100644 --- a/SorgentiTex/Norme di progetto/main.tex +++ b/SorgentiTex/Norme di progetto/main.tex @@ -79,7 +79,7 @@ \section{Riferimenti} \item \url{https://www.math.unipd.it/~tullio/IS-1/2023/Dispense/T11.pdf}\\ (Ultimo accesso: 2024-02-08). \end{itemize} - \item \textit{(Glossario v2.0.0(0))}. + \item \textit{(Glossario v3.0.0(0))}. \end{itemize} @@ -276,7 +276,7 @@ \subsubsubsection{Linee guida stesura consuntivo di periodo} \subsubsection{Piano di Qualifica } -Il (Piano di qualifica v2.0.0(0)) definisce le strategie, gli obiettivi e le attività per garantire la qualità del prodotto finale. Vengono definite in +Il (Piano di qualifica v3.0.0(0)) definisce le strategie, gli obiettivi e le attività per garantire la qualità del prodotto finale. Vengono definite in tale documento le metriche di valutazione e validazione del progetto e la specifica degli obiettivi di qualità del prodotto finale. Tali parametri vengono stabiliti in accordo ai requisiti e alle aspettative del proponente e talvolta a discrezione del team sulla base delle valutazioni fatte nel corso di studi. Il suo scopo è assicurare che il prodotto soddisfi gli standard di qualità definiti e che @@ -318,7 +318,7 @@ \subsubsubsection{Scopo} relativamente al prodotto software. \subsubsubsection{Implementazione dell'attività} -L'attività di analisi dei requisiti, la quale viene documentata all'interno del documento (Analisi dei requisiti v2.0.0(0)), viene svolta seguendo le seguenti fasi: +L'attività di analisi dei requisiti, la quale viene documentata all'interno del documento (Analisi dei requisiti v3.0.0(0)), viene svolta seguendo le seguenti fasi: \begin{itemize} \item Studio accurato del capitolato e delle esigenze del committente; \item Individuazione dei casi d'uso (e relativa produzione dei diagrammi dei casi d'uso) e dei requisiti; @@ -413,7 +413,7 @@ \subsubsubsection{Requisiti: Suddivisione} \end{itemize} \subsubsubsection{Diagrammi} -I diagrammi dei casi d'uso e di attività riportati all'interno del documento (Analisi dei requisiti v2.0.0(0)) devono seguire la notazione e le specifiche indicate da \textit{UML\pg v2.5}. +I diagrammi dei casi d'uso e di attività riportati all'interno del documento (Analisi dei requisiti v3.0.0(0)) devono seguire la notazione e le specifiche indicate da \textit{UML\pg v2.5}. \subsubsubsection{Applicazione milestone SEMAT} SWEetCode nell'esecuzione dell'attività di analisi dei requisiti ha deciso di adottare la pianificazione in \textit{milestone\pg} presentata @@ -424,7 +424,7 @@ \subsubsubsection{Applicazione milestone SEMAT} \item \textit{PB-AdR: Acceptable}: i requisiti fissati definiscono un sistema soddisfacente per l'utente; \item \textit{PB-AdR: Fulfilled}: il prodotto soddisfa abbastanza requisiti da meritare la piena approvazione dell'azienda proponente. \end{itemize} - + \subsubsubsection{Strumenti} \begin{itemize} \item \textit{Diagrams.net}. @@ -436,7 +436,7 @@ \subsubsubsection{Scopo} La progettazione serve a dominare la complessità del prodotto, decomponendolo in parti componibili e organizzate. \subsubsubsection{Documentazione} -L'attività di progettazione produce il documento (Specifica tecnica (v3.0.0(1))). Questo documento serve a descrivere l'architettura del prodotto e a guidare in modo chiaro e privo di ambiguità il lavoro dei programmatori attraverso la progettazione di dettaglio. +L'attività di progettazione produce il documento (Specifica tecnica (v3.0.0(0))). Questo documento serve a descrivere l'architettura del prodotto e a guidare in modo chiaro e privo di ambiguità il lavoro dei programmatori attraverso la progettazione di dettaglio. Il documento tratta le seguenti tematiche: \begin{itemize} \item \textbf{Scelte tecnologiche}: analisi delle tecnologie e delle librerie selezionate e delle motivazioni a supporto di queste scelte; @@ -469,7 +469,7 @@ \subsubsubsection{Linee guida progettazione delle componenti} \end{enumerate} \end{itemize} \subsubsubsection{Linee guida progettazione di dettaglio} -Il documento Specifica tecnica (v3.0.0(1)) nella sezione (\S Progettazione di dettaglio) analizza in maniera precisa e chiara i moduli, raggruppandoli per appartenenza alle componenti del sistema.\\ +Il documento Specifica tecnica (v3.0.0(0)) nella sezione (\S Progettazione di dettaglio) analizza in maniera precisa e chiara i moduli, raggruppandoli per appartenenza alle componenti del sistema.\\ Per ogni componente viene allegato un \textit{Diagramma delle classi}.\\ Per ogni classe vengono elencate le proprietà che le caratterizzano, tra le quali: \begin{itemize} @@ -529,10 +529,10 @@ \subsubsubsection{Progettazione logica} In particolare, i progettisti devono: \begin{itemize} - \item Progettare le interfacce esterne al software e tra i componenti del software; + \item Progettare le componenti del software; \item Definire e progettare le strutture dati necessarie per soddisfare i requisiti; \item Documentare una versione preliminare del (Manuale utente); - \item Pianificare e definire, collaborando con i verificatori, i test di integrazione tra componenti; + \item Pianificare e definire, collaborando con i verificatori, i test di sistema del software; \item Valutare e revisionare l'architettura definita nei passi precedenti, coinvolgendo tutti i membri del team e altre parti interessate. In particolare, il team collaborerà con dei membri dell'azienda proponente in modo da ottenere consigli e correzioni da fonti autorevoli e con esperienza. \end{itemize} @@ -555,7 +555,7 @@ \subsubsubsection{Progettazione di dettaglio} \end{itemize} \subsubsubsection{Diagrammi} -I diagrammi delle classiriportati all'interno del documento (Specifica tecnica (v3.0.0(1))) devono seguire la notazione e le specifiche indicate da \textit{UML v2.5}. +I diagrammi delle classiriportati all'interno del documento (Specifica tecnica (v3.0.0(0))) devono seguire la notazione e le specifiche indicate da \textit{UML v2.5}. \subsubsubsection{Strumenti} \begin{itemize} @@ -647,7 +647,7 @@ \subsubsubsubsection{Convenzioni sintattiche} \item \textbf{Più istruzioni su una linea}: evitare più istruzioni sulla stessa linea. \end{itemize} -\subsubsubsection{Stile di codifica: Javascript (React)} +\subsubsubsection{Stile di codifica: Javascript (NextJS)} \subsubsubsubsection{Struttura dei file} La struttura di un sorgente \textit{Javascript\pg} è definita dalle seguenti parti: \begin{itemize} \item Import: insieme di istruzioni di import che seguono l'ordine: @@ -657,7 +657,7 @@ \subsubsubsubsection{Struttura dei file} La struttura di un sorgente \textit{Jav \end{enumerate} \item Funzioni: definiscono un componente o funzioni di utilità. \end{itemize} -\subsubsubsubsection{Struttura dei componenti} La struttura di un \textit{componente React\pg} è definita dalle seguenti parti, se necessarie: +\subsubsubsubsection{Struttura dei componenti} La struttura di un \textit{componente NextJS\pg} è definita dalle seguenti parti, se necessarie: \begin{enumerate} \item \textbf{Arrow function}: definisce il componente; \item \textbf{Funzioni ausiliarie}: funzioni di supporto che aiutano a gestire casi complessi e aumentano il riuso; @@ -724,9 +724,18 @@ \subsubsubsection{Stile di codifica: HTML e CSS} \subsubsection{Testing del codice} \label{sec:codeTesting} In questa sezione vengono esposti i tipi e la notazione dei test che vengono eseguiti sul codice come parte del piano di verifica per garantire la correttezza del prodotto. -\subsubsubsection{Test di unità} +\subsubsubsection{Tipi di test} +I test effettuati vengono suddivisi nelle seguenti categorie: +\begin{itemize} + \item Test di unità; + \item Test di integrazione; + \item Test di sistema; + \item Test di regressione. +\end{itemize} + +\subsubsubsubsection{Test di unità} \begin{itemize} - \item \textbf{Stesura}: i Verificatori sono incaricati di formulare i test di unità durante la fase di progettazione di dettaglio, descritta in (\S \nameref{sec:progettazione_di_dettaglio}); + \item \textbf{Stesura}: i Verificatori sono incaricati di implementare i test di unità stabiliti durante la fase di progettazione di dettaglio, descritta in (\S \nameref{sec:progettazione_di_dettaglio}); \item \textbf{Descrizione}: questi test sono progettati in conformità alle specifiche di ciascuna unità software, consentendo l'associazione di più test a una singola unità, qualora necessario, costruendo una suite di test dedicata a quell'unità. La loro esecuzione potrebbe richiedere l'utilizzo di stub o driver, strumenti che permettono di testare le singole unità simulando alcuni dei loro componenti, nel caso in cui non fossero tutti disponibili per l'esecuzione (pratica essenziale, specialmente quando l'ambiente è ancora piuttosto scarno); \item \textbf{Categorie}: i test di unità possono essere suddivisi in due categorie: @@ -742,9 +751,9 @@ \subsubsubsection{Test di unità} %Questo approccio mira a garantire un processo sistematico ed efficiente, assicurando che ciascuna unità software sia accuratamente testata e rispetti le specifiche stabilite durante la progettazione dettagliata. -\subsubsubsection{Test di integrazione} +\subsubsubsubsection{Test di integrazione} \begin{itemize} - \item \textbf{Stesura}: i test di integrazione vengono definiti dai verificatori durante la fase di progettazione architetturale; + \item \textbf{Stesura}:i Verificatori sono incaricati di implementare i test di integrazione stabiliti durante la fase di progettazione di dettaglio, descritta in (\S \nameref{sec:progettazione_di_dettaglio}); \item \textbf{Descrizione}: si applicano alle componenti individuate con lo scopo di rilevare difetti di progettazione, errori a livello di unit testing, incompatibilità e incongruenza nell'uso delle interfacce o errata integrazione con altre applicazioni. Devono assemblare incrementalmente, ampliando il loro raggio di azione di volta in volta; \item \textbf{Categorie}: esistono due strategie di integrazione: \begin{itemize} @@ -754,22 +763,22 @@ \subsubsubsection{Test di integrazione} \end{itemize} -\subsubsubsection{Test di sistema} +\subsubsubsubsection{Test di sistema} \begin{itemize} - \item \textbf{Stesura}: questa fase di testing viene definita dai verificatori e avviene dopo il completamento dei test di unità e dei test di integrazione e prima del collaudo con il committente; - \item \textbf{Descrizione}: i test di sistema mirano a valutare il sistema nel suo complesso per garantire che soddisfi tutti i requisiti delineati nel documento (Analisi dei requisiti v2.0.0(0)). Vegnono considerati come test funzionali (o black-box), non richiedono conoscenza della logica e del funzionamento interno del software. + \item \textbf{Stesura}: questa fase di testing viene effettuata dai verificatori e avviene dopo il completamento dei test di unità e dei test di integrazione e prima del collaudo con il committente; + \item \textbf{Descrizione}: i test di sistema mirano a valutare il sistema nel suo complesso per garantire che soddisfi tutti i requisiti delineati nel documento (Analisi dei requisiti v3.0.0(0)). Vegnono considerati come test funzionali (o black-box), non richiedono conoscenza della logica e del funzionamento interno del software. \end{itemize} -\subsubsubsection{Test di regressione} +\subsubsubsubsection{Test di regressione} \begin{itemize} - \item \textbf{Stesura}: questa fase di testing viene definita dai verificatori e avviene dopo il completamento dei test di unità, dei test di integrazione, dei test di sistema e prima del collaudo con il committente; + \item \textbf{Selezione}: questa fase di testing viene definita dai verificatori e avviene dopo il completamento dei test di unità, dei test di integrazione, dei test di sistema e prima del collaudo con il committente; \item \textbf{Descrizione}: i test di regressione sono un tipo specifico di test che include una selezione dei test già implementati (di unità, di integrazione e di sistema), per verificare che le modifiche apportate al software non abbiano introdotto nuovi difetti o non abbiano alterato il comportamento esistente del sistema. In altre parole, essi mirano a garantire che le modifiche apportate durante lo sviluppo del software non abbiano effetti collaterali negativi su funzionalità precedentemente testate e correttamente funzionanti. \end{itemize} -\subsubsection{Test: Notazione} +\subsubsubsection{Test: Notazione} I test vengono identificati con la seguente notazione: \textbf{T[Tipo].[Codice]}\\ nella quale: @@ -785,7 +794,7 @@ \subsubsection{Test: Notazione} \item \lbrack \textbf{Codice}] identifica i test per ogni tipologia. È composto da un unico numero progressivo univoco se il test non ha padre, mentre se si tratta di un sotto-test, segue il formato \textbf{[Codice\_padre].[Numero\_figlio]}; questa struttura è ricorsiva, quindi non pone un limite alla profondità della gerarchia. \end{itemize} -\subsubsection{Test: Stato} +\subsubsubsection{Test: Stato} Ogni test è associato a uno stato che indica il risultato di soddisfacimento di esso nell'ultima versione rilasciata del prodotto software. Lo stato può assumere i seguenti valori: \begin{itemize} \item I (Indisponibile, test non in funzione); @@ -795,12 +804,34 @@ \subsubsection{Test: Stato} \subsubsection{Integrazione software} -Tale sezione sarà realizzata a seguito della versione v2.0.0 delle (Norme di progetto). +La \textit{Continuous Integration\pg} (CI) è una pratica fondamentale nel nostro processo di sviluppo software che mira a integrare in modo continuo e automatico le +modifiche al codice nel repository condiviso. Al fine di garantire la qualità e la stabilità del codice, oltre che permettere una panoramica immediata dello stato +attuale dell'attività di codifica, è essenziale stabilire regole chiare riguardanti il processo di CI e il rilascio del software.\\ +Di seguito sono elencate le norme di progetto relative alla CI. + +\subsubsubsection{Branching} +Il repository è strutturato in due branch principali: +\begin{itemize} + \item \textbf{Main}: branch principale del repository, contiene il codice sorgente stabile e funzionante; + \item \textbf{PB}: branch di sviluppo, contiene il codice sorgente in fase di sviluppo e test relativi alla fase PB. +\end{itemize} +Ogni modifica o aggiunta di codice viene effettuata in un branch separato, creato a partire dal branch PB, seguendo la convenzione +\textit{'mod-code-Cognome'}, dove \textit{'Cognome'} viene sostituito dal cognome del membro che ha creato il branch. + +\subsubsubsection{Pull Request} +Una volta completata la modifica o l'aggiunta di codice, il membro che ha creato il branch deve aprire una pull request per richiedere la revisione del codice.\\ +Al fine di garantire un corretto versionamento (\S \nameref{sec:version}), il titolo della pull request deve seguire la convenzione: +\begin{itemize} + \item \textbf{Feat: *TEXT*}: per l'aggiunta di nuove funzionalità, moduli o componenti, dove \textit{*TEXT*} rappresenta una breve descrizione della funzionalità aggiunta; + \item \textbf{Fix: *TEXT*}: per la correzione di bug, errori o malfunzionamenti, dove \textit{*TEXT*} rappresenta una breve descrizione del bug corretto. +\end{itemize} +Ogni apertura di una pull request comporta l'avvio automatico di una \textit{Github Action\pg} denominata \textit{'Test'}, che esegue i test di unità, +di integrazione e sistema definiti nel documento (Piano di qualifica (v3.0.0(0)), \S Test di unità, \S Test di integrazione, \S Test di sistema).\\ +Grazie alla configurazione di adeguate Github Protection Rules attive nei branch \textit{'main'} e \textit{'PB'}, la pull request può essere approvata dai verificatori solamente a +condizione di superamento di tutti i test presenti nel repository al momento della creazione della pull request.\\ +Il team si impegna a garantire il corretto funzionamento dei test al momento della creazione della pull request, in modo da evitare l'introduzione di errori nel codice sorgente remoto, +senza permettere la manipolazione dei test stessi al fine di ottenere l'approvazione della pull request. -\subsubsection{Installazione software} -Tale sezione sarà realizzata a seguito della versione v2.0.0 delle (Norme di progetto). -%-Docker -%-Configurazione iniziale % PROCESSI DI SUPPORTO \newpage @@ -997,13 +1028,13 @@ \subsubsection{Produzione} \item La produzione della documentazione in formato \textit{Latex} viene gestita tramite la condivisione dei sorgenti attraverso \textit{GitHub}, quindi è buona pratica che ogni membro ne possieda a priori la versione aggiornata. Se così non fosse, il responsabile di stesura aggiorna in locale la versione della documentazione, mediante un'istruzione \textit{git pull}; \item Il responsabile di stesura scarica il template necessario alla stesura del documento; \item Il responsabile di stesura opera la stesura del documento; - \item Una volta che la stesura viene ritenuta stabile (dal responsabile di stesura), tramite l'automazione descritta in (Norme di progetto v2.0.0(0), \S \nameref{sec:automazione_docs}), crea una \textit{pull request} nel repository \href{https://github.com/sweetcode-team/Knowledge_Management_AI}{\textcolor{black}{\textit{Knowledge\_Management\_AI}}} su \textit{GitHub}. + \item Una volta che la stesura viene ritenuta stabile (dal responsabile di stesura), tramite l'automazione descritta in (Norme di progetto v3.0.0(0), \S \nameref{sec:automazione_docs}), crea una \textit{pull request} nel repository \href{https://github.com/sweetcode-team/Knowledge_Management_AI}{\textcolor{black}{\textit{Knowledge\_Management\_AI}}} su \textit{GitHub}. \end{itemize} \item \textbf{Verifica e Validazione}: La fase di verifica viene realizzata dal revisore del documento e funziona come segue: \begin{itemize} \item Il documento viene - sottoposto ad un controllo di contenuto e sintassi da parte del verificatore, che tiene conto delle linee guida definite dal team nelle (Norme di progetto v2.0.0(0), \S \nameref{sec:documents}); + sottoposto ad un controllo di contenuto e sintassi da parte del verificatore, che tiene conto delle linee guida definite dal team nelle (Norme di progetto v3.0.0(0), \S \nameref{sec:documents}); \item Se il documento è di tipo esterno, una volta passata la verifica da parte del revisore, l'atto viene condiviso con l'ente terzo in causa, per essere sottoposto ad una sua ulteriore verifica e validazione. \item In caso di esito positivo la \textit{pull request} viene risolta mentre, in caso di esito negativo, essa viene rifiutata e si ritorna alla @@ -1044,7 +1075,7 @@ \subsubsection{Manutenzione} \item \textbf{Push della modifica}: \begin{itemize} \item Per procedere, la stesura della modifica deve venire ritenuta stabile, tramite l'automazione descritta in - (Norme di progetto v2.0.0(0), \S \nameref{sec:automazione_docs}); + (Norme di progetto v3.0.0(0), \S \nameref{sec:automazione_docs}); \item Viene creata una \textit{pull request} nel repository \href{https://github.com/sweetcode-team/Knowledge_Management_AI}{\textcolor{black}{\textit{Knowledge\_Management\_AI}}} su \textit{GitHub} per la nuova versione del documento da parte di chi ha operato la modifica. \end{itemize} @@ -1157,7 +1188,7 @@ \subsubsubsubsection{Automazione chiusura ticket} \textit{Jira} mette a disposiz \begin{itemize} \item Si introduce un'automazione di chiusura automatica dei ticket presenti all'interno dell'\textit{ITS}; \item Ogni volta che un membro del team - effettua un commit nel repository finalizzato alla chiusura di un \textit{ticket}, il contenuto di tale commit, grazie all'esecuzione di uno script Python creato dal team (Norme di progetto v2.0.0(0), \nameref{sec:automazione_docs}) + effettua un commit nel repository finalizzato alla chiusura di un \textit{ticket}, il contenuto di tale commit, grazie all'esecuzione di uno script Python creato dal team (Norme di progetto v3.0.0(0), \nameref{sec:automazione_docs}) presenterà al suo interno l'operazione "\textit{SWE-\#id\_ticket}"; \item A seguito dell'approvazione della pull request da parte del verificatore, il \textit{ticket} associato a quel particolare \textit{ID} passerà in automatico allo stato \textit{Completato}. @@ -1229,12 +1260,12 @@ \subsubsubsection{Scopo} \subsubsubsection{Automazione release} L'automazione del \textit{versionamento\pg} consente di rilasciare nuove release in modo automatico, seguendo le regole di -cambio versione indicate in (Norme di progetto v2.0.0(0), \S \nameref{sec:version}) e avviene procedendo come segue: +cambio versione indicate in (Norme di progetto v3.0.0(0), \S \nameref{sec:version}) e avviene procedendo come segue: \begin{itemize} \item Attraverso l'uso di \textit{GitHub Actions\pg}, l'accettazione di una pull request, - eseguita seguendo le norme indicate nel paragrafo (Norme di progetto v2.0.0(0), \S \nameref{sec:pull_request}), è immediatamente seguita dalla pubblicazione della nuova versione (il tipo di cambio versione viene indicato dal prefisso del titolo della pull request). + eseguita seguendo le norme indicate nel paragrafo (Norme di progetto v3.0.0(0), \S \nameref{sec:pull_request}), è immediatamente seguita dalla pubblicazione della nuova versione (il tipo di cambio versione viene indicato dal prefisso del titolo della pull request). \end{itemize} -Questa automazione si integra in modo efficace con quella citata nel paragrafo (Norme di progetto v2.0.0(0), \S \nameref{sec:automazione_docs}). +Questa automazione si integra in modo efficace con quella citata nel paragrafo (Norme di progetto v3.0.0(0), \S \nameref{sec:automazione_docs}). Ciò che separa l'esecuzione consecutiva delle due automazioni è la creazione della pull request e la sua accettazione. La richiesta dell'intervento umano, in questo caso, non è un fattore limitante, ma rappresenta due ulteriori fasi di verifica, che garantiscono la pulizia del repository remota e la correttezza del suo contenuto. @@ -1248,8 +1279,8 @@ \subsubsubsection{Automazione versionamento documenti} \begin{itemize} \item Il componente del gruppo che carica o modifica un documento esegue il push in locale di tale documento, comilando lo script Python del team; \item Il componente del gruppo che ha eseguito lo script deve recarsi nel sito web del repository su GitHub e creare la Pull Request; - \item Questa verrà successivamente analizzata e accettata o rifiutata in base ai criteri descritti nel (Piano di qualifica v2.0.0(0)) e - secondo le modalità citate nel paragrafo (Norme di progetto v2.0.0(0), \S \nameref{sec:ciclo_vita}). + \item Questa verrà successivamente analizzata e accettata o rifiutata in base ai criteri descritti nel (Piano di qualifica v3.0.0(0)) e + secondo le modalità citate nel paragrafo (Norme di progetto v3.0.0(0), \S \nameref{sec:ciclo_vita}). \end{itemize} L'utilizzo di questa automazione permette di ridurre gli errori legati all'aggiornamento e alla pubblicazione di nuove versioni dei documenti, e riduce notevolmente il carico di lavoro assegnato ai componenti del gruppo, limitando @@ -1329,7 +1360,7 @@ \subsubsubsection{Qualità del processo} \item \textbf{M.PC.1.PMS}: \begin{itemize} \item \textbf{Nome}: Percentuale di metriche soddisfatte; - \item \textbf{Descrizione}: Valore che indica la percentuale di metriche soddisfatte; una metrica si dice "soddisfatta" se la sua misurazione supera il valore accettabile specificato nel documento (Piano di qualifica v2.0.0(0)); + \item \textbf{Descrizione}: Valore che indica la percentuale di metriche soddisfatte; una metrica si dice "soddisfatta" se la sua misurazione supera il valore accettabile specificato nel documento (Piano di qualifica v3.0.0(0)); \item \textbf{Caratteristica di riferimento}: - \item \textbf{Motivo}: Questa metrica ci assicura il raggiungimento di un buon livello di qualità generale nello svolgimento del progetto; \item \textbf{Misurazione}: \ \[ M=\frac{N° Metriche \ soddisfatte}{N° Metriche\ totali} * 100 \] \\ @@ -1338,7 +1369,7 @@ \subsubsubsection{Qualità del processo} \item \textbf{M.PC.2.RNP}: \begin{itemize} \item \textbf{Nome}: Rischi non previsti; - \item \textbf{Descrizione}: Valore che specifica il numero di rischi verificatisi che non rientrano tra quelli esaminati nel documento di (Analisi dei requisiti v2.0.0(0)); + \item \textbf{Descrizione}: Valore che specifica il numero di rischi verificatisi che non rientrano tra quelli esaminati nel documento di (Analisi dei requisiti v3.0.0(0)); \item \textbf{Caratteristica di riferimento}: - \item \textbf{Motivo}: Valore che indica se è stata fatta una accurata analisi dei rischi a monte della pianificazione. \item \textbf{Misurazione}: \[ @@ -1351,7 +1382,7 @@ \subsubsubsection{Qualità del processo} \item \textbf{M.PC.3.VP}: \begin{itemize} \item \textbf{Nome}: Variazione di piano; - \item \textbf{Descrizione}: Variazione utilizzata per analizzare se ogni attività o task del progetto, in un dato istante di tempo, è in linea o in ritardo rispetto alla pianificazione specificata nel documento (Piano di progetto v2.0.0(0)). Ai seguenti valori si associano i seguenti significati: + \item \textbf{Descrizione}: Variazione utilizzata per analizzare se ogni attività o task del progetto, in un dato istante di tempo, è in linea o in ritardo rispetto alla pianificazione specificata nel documento (Piano di progetto v3.0.0(0)). Ai seguenti valori si associano i seguenti significati: \begin{itemize} \item > 0 significa che si sta procedendo con un certo ritardo; \item = 0 si è in linea con quanto pianificato. @@ -1389,7 +1420,7 @@ \subsubsubsection{Qualità del processo} \item \textbf{Nome}: Indice di stabilità dei requisiti; \item \textbf{Descrizione}: Indice che traccia la variazione dei requisiti nell’arco del progetto; \item \textbf{Caratteristica di riferimento}: - - \item \textbf{Motivo}: Questo valore indica eventuali discostamenti dai requisiti analizzati nel documento di (Analisi dei requisiti v2.0.0(0)); + \item \textbf{Motivo}: Questo valore indica eventuali discostamenti dai requisiti analizzati nel documento di (Analisi dei requisiti v3.0.0(0)); \item \textbf{Misurazione}: \[ M=100- \frac{RM + RC + RA}{RTI} *100 \] \\ \begin{itemize} \item RM= Requisiti modificati; @@ -1661,7 +1692,7 @@ \subsubsubsubsection{Esterne} \subsubsection{Obiettivi di qualità: Struttura} -Gli obiettivi di qualità, divisi in obiettivi di processo e di prodotto, vengono indicati nel documento (Piano di qualifica v2.0.0(0)). Ognuno di questi è descritto da: +Gli obiettivi di qualità, divisi in obiettivi di processo e di prodotto, vengono indicati nel documento (Piano di qualifica v3.0.0(0)). Ognuno di questi è descritto da: \begin{itemize} \item \textbf{Metrica}: codice della metrica; \item \textbf{Nome}: nome esteso della metrica; @@ -1677,7 +1708,7 @@ \subsubsection{Strumenti} \subsection{Verifica} \subsubsection{Scopo} -Il processo di verifica ha lo scopo di determinare se ciò che viene prodotto è conforme ai requisiti stabiliti e ai vincoli qualitativi specificati nel (Piano di qualifica v2.0.0(0)). +Il processo di verifica ha lo scopo di determinare se ciò che viene prodotto è conforme ai requisiti stabiliti e ai vincoli qualitativi specificati nel (Piano di qualifica v3.0.0(0)). Lo scopo principale della verifica è garantire la completezza e la correttezza del prodotto, fornendo evidenze oggettive e misurabili. \subsubsection{Descrizione} @@ -1706,7 +1737,7 @@ \subsubsubsection{Ispezione} L'ispezione è una tecnica che utilizza liste di co Data l'iniziale inesperienza del team, per i primi periodi è stato utilizzato l'approccio walkthrough. Nel momento in cui le liste di controllo diventeranno sufficientemente ampie per permettere una verifica adeguata, l'ispezione permetterà al team di svolgere questa attività più velocemente, preservando una grande quantità di risorse.\\ -Le liste di controllo sono raccolte nel documento (Piano di qualifica v2.0.0(0), \S Checklist). +Le liste di controllo sono raccolte nel documento (Piano di qualifica v3.0.0(0), \S Checklist). \subsubsection{Analisi dinamica} L'analisi dinamica è una metodologia di verifica che richiede l'esecuzione effettiva del software al fine di valutarne il comportamento, le performance e la correttezza durante l'esecuzione. @@ -1717,7 +1748,7 @@ \subsubsection{Analisi dinamica} \subsection{Validazione} \subsubsection{Scopo} -Il processo di validazione è finalizzato a determinare se i requisiti stabiliti da contratto all'interno del documento (Analisi dei requisiti v2.0.0(0)) vengono soddisfatti nel +Il processo di validazione è finalizzato a determinare se i requisiti stabiliti da contratto all'interno del documento (Analisi dei requisiti v3.0.0(0)) vengono soddisfatti nel prodotto sottoposto a tale processo. \subsubsection{Implementazione del processo} @@ -1769,7 +1800,7 @@ \subsubsection{Implementazione del processo} \subsubsection{Revisioni di project management congiunte} Le revisioni di project management congiunte pongono a revisione i seguenti materiali: \begin{itemize} - \item Stato del progetto in relazione alle pianificazioni presenti nel (Piano di progetto v2.0.0(0)); + \item Stato del progetto in relazione alle pianificazioni presenti nel (Piano di progetto v3.0.0(0)); \item Scadenze valutate sulla base dello stato del prodotto in relazioni alle date di consegna accordate. \end{itemize} I fini di tale revisione congiunta consistono nel far progredire le attività secondo quanto pianificato, mantenendo il controllo del progetto e @@ -1807,7 +1838,7 @@ \subsubsection{Implementazione del processo} \subsubsection{Revisioni di project management} Le revisioni di project management pongono a revisione i seguenti materiali: \begin{itemize} - \item Stato del progetto in relazione alle pianificazioni presenti nel (Piano di progetto v2.0.0(0)); + \item Stato del progetto in relazione alle pianificazioni presenti nel (Piano di progetto v3.0.0(0)); \item Scadenze valutate sulla base dello stato del prodotto in relazioni alle date di consegna accordate. \end{itemize} I fini di tale revisione consistono nel far progredire le attività secondo quanto pianificato, anche in termini di tempi e costi, mantenendo il controllo del progetto e @@ -1885,7 +1916,7 @@ \subsubsubsection{Amministratore} \item Gestire errori e segnalazioni di malfunzionamenti di meccanismi nell'infrastruttura. \end{itemize} \subsubsubsection{Analista} -Questo ruolo ha la funzione di analizzare il problema e definire i requisiti del prodotto. Necessita di una buona conoscenza del dominio del problema. Raccoglie le sue produzioni nel documento (Analisi dei requisiti v2.0.0(0)). +Questo ruolo ha la funzione di analizzare il problema e definire i requisiti del prodotto. Necessita di una buona conoscenza del dominio del problema. Raccoglie le sue produzioni nel documento (Analisi dei requisiti v3.0.0(0)). Questo ruolo è fondamentale all'inizio, ma la sua utilità cala con l'avanzare del progetto. \subsubsubsection{Progettista} Si occupa di determinare le scelte realizzative e le specifiche architetturali del prodotto. Deve avere buone competenze tecniche e tecnologiche. L'utilità di questo ruolo è alta inizialmente, durante il processo di sviluppo, ma tende a calare dalla fase di manutenzione in poi. @@ -2045,7 +2076,7 @@ \subsubsubsection{Norme comportamentali} \subsubsubsection{Gestione dei rischi} La definizione e la gestione dei rischi sono attività svolte dal responsabile e dall'amministratore. -I risultati di queste attività sono incluse nel documento (Piano di progetto v2.0.0(0)). +I risultati di queste attività sono incluse nel documento (Piano di progetto v3.0.0(0)). Le seguenti sezioni definiscono le modalità tramite le quali questi rischi vengono documentati. \subsubsubsubsection{Notazione} diff --git a/SorgentiTex/Norme di progetto/registroversioni.tex b/SorgentiTex/Norme di progetto/registroversioni.tex index abcd073..396497d 100644 --- a/SorgentiTex/Norme di progetto/registroversioni.tex +++ b/SorgentiTex/Norme di progetto/registroversioni.tex @@ -16,6 +16,8 @@ \section*{Registro delle versioni} \endlastfoot +\hline +v2.27.7(17) & $2024-04-09$ & \quantities{Bresolin G.} & Michelon R. & Aggiunta sezione Integrazione software.\\ \hline v2.27.7(14) & $2024-04-06$ & \quantities{Bresolin G.} & Orlandi G. & Aggiornamento sezione Progettazione: modifiche documentazione e strumenti.\\ \hline