From fc14ce475ad37456dd762b327ec9bfa2733f49f4 Mon Sep 17 00:00:00 2001 From: Lorenzo Dei Negri Date: Tue, 14 Jan 2020 16:06:00 +0100 Subject: [PATCH] Fix finale norme --- .../Sez3-ProcessiSupporto/Documentazione.tex | 44 +++++++++---------- .../Sez3-ProcessiSupporto/GaranziaQualita.tex | 14 +++--- .../GestConfigurazione.tex | 12 ++--- .../ProcDiRisoluzioneDeiProblemi.tex | 10 ++--- .../Sez3-ProcessiSupporto/Validazione.tex | 16 +++---- .../Sez3-ProcessiSupporto/Verifica.tex | 38 ++++++++-------- .../FormazionePersonale.tex | 4 +- .../GestProcessi.tex | 20 ++++----- 8 files changed, 77 insertions(+), 81 deletions(-) diff --git a/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/Documentazione.tex b/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/Documentazione.tex index cf17318..064d850 100644 --- a/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/Documentazione.tex +++ b/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/Documentazione.tex @@ -100,9 +100,9 @@ \section{Processi di Supporto} \item i termini seguono l'ordine lessicografico; \item ogni termine è spiegato in maniera chiara e in nessun modo ambigua. \end{itemize} - La stesura del glossario deve avvenire in parallelo alla stesura dei documenti al fine di evitare confusione tra i termini. Inoltre, ogni parola nei documenti, presente nel glossario, deve essere caratterizzata dallo stile ``maiuscoletto'' con il pedice ``G''. Non si richiede tale stile se la parola presente nel documento è stata precendentemente caratterizzata con la suddetta notazione. + La stesura del glossario deve avvenire in parallelo alla stesura dei documenti al fine di evitare confusione tra i termini. Inoltre, ogni parola dei documenti riportata nel glossario, deve essere caratterizzata dallo stile ``maiuscoletto'' con il pedice ``G''. Non si richiede tale stile se la parola presente nel documento è stata precedentemente caratterizzata con la suddetta notazione. \paragraph{Lettere} - La lettera di presentazione dovrà seguire il classico layout per lettere, il che implica la presenza dei mittenti e destinatari, il logo dell'azienda e la lista di tutti i documenti rilasciati, nonchè il preventivo per il progetto. + La lettera di presentazione dovrà seguire il classico layout per lettere, il che implica la presenza dei mittenti e destinatari, il logo del gruppo e la lista di tutti i documenti rilasciati, nonché il preventivo per il progetto. \subsubsection{Norme tipografiche} \paragraph{Convenzioni sui nomi dei file} Si è deciso di usare la convenzione ``camel case'' per i nomi di file e cartelle. Le regole seguite saranno le seguenti: @@ -110,22 +110,20 @@ \section{Processi di Supporto} \item il nome dei file composti da più parole avranno la prima lettera minuscola ed ogni parola in seguito inizierà con una maiuscola; \item tra le parole non sarà presente alcun separatore; \item le preposizioni non verranno omesse; - \item sono omessi da questa sintassi le estensione dei file. + \item sono escluse da questa sintassi le estensione dei file. \end{itemize} Alcuni esempi corretti sono: \begin{itemize} - \item studioDiFattibilitá.pdf; - \item immagine.png + \item convenzioniSuiNomiDeiFile.tex; + \item documentazione.tex \end{itemize} Alcuni esempi non corretti sono: \begin{itemize} - \item StudioDiFattibilitá (la prima lettera è maiuscola); - \item studio Di Fattibilitá (usa un carattere separatore); - \item studio\_Di\_Fattibilitá (usa un carattere separatore); - \item studioFattibilitá (omette una preposizione). + \item ConvenzioniSuiNomiDeiFile (la prima lettera è maiuscola); + \item convenzioni Sui Nomi Dei File (usa un carattere separatore); + \item convenzioni\_Sui\_Nomi\_Dei\_File (usa un carattere separatore); + \item convenzioniNomiFile (omette preposizioni). \end{itemize} - \paragraph{Glossario} - I termini appartenenti al glossario si possono identificare dallo stile della parola, in particolare si è deciso di utilizzare lo stile ``maiuscoletto'' con una ``G'' come pedice, es. \glock{Efficienza}. Inoltre, tutte le parole presenti nei titoli, didascalie e tabelle che appartengono al glossario non verranno segnalate dalla ``G''. \paragraph{Stile del testo} I vari stili del testo hanno una specifica funzione semantica. \begin{itemize} @@ -138,7 +136,7 @@ \section{Processi di Supporto} \end{itemize} \end{itemize} \paragraph{Elenchi puntati} - Ogni elemento dell'elenco deve essere seguito da un punto e virgola, fatta eccezione per l'ultimo elemento che sarà seguito da un punto; di conseguenza la prima lettera di ogni sentenza deve essere minuscola, ad eccezione della prima frase se quest'ultima inizia un paragrafo. Gli elenchi avranno punto elenco differente a seconda della loro tipologia: + Ogni elemento dell'elenco deve essere seguito da un punto e virgola, fatta eccezione per l'ultimo elemento che sarà seguito da un punto; di conseguenza la prima lettera di ogni voce dell'elenco deve essere minuscola, ad eccezione della prima frase se quest'ultima è posta all'inizio di paragrafo. Gli elenchi avranno punto elenco differente a seconda della loro tipologia: \begin{itemize} \item per gli elenchi non ordinati si è scelto di usare come punto elenco un cerchietto pieno e come sub-punto elenco il trattino; \item per gli elenchi ordinati si è optato per un punto elenco ``flessibile'', ossia possono essere usati sia i numeri che i letterali, purché quest'ultimi siano in minuscolo, seguiti da un punto, esempio ``1.'' o ``a.''. @@ -150,7 +148,7 @@ \section{Processi di Supporto} \item \textbf{versione:} viene utilizzato il formato vXX.XX.XX. \end{itemize} \paragraph{Sigle} - Il progetto richiede la redazione di un insieme di documenti, sotto elencata è la lista dei documenti con relative sigle: + Il progetto richiede la redazione di un insieme di documenti; segue l'elenco dei documenti con relative sigle: \begin{itemize} \item documenti esterni: \begin{itemize} @@ -164,7 +162,7 @@ \section{Processi di Supporto} \begin{itemize} \item \textbf{glossario - G:} raccoglie tutti i termini che necessitano di una disambiguazione e/o una descrizione più approfondita; \item \textbf{norme di progetto - NdP:} è una raccolta di tutte le regole e le norme utilizzate durante il ciclo di vita del software; - \item \textbf{studio di fattibilità - SdF:} descrive i vari capitolati, sia esclusi che scelti, analizzando brevemente il loro pro e contro. + \item \textbf{studio di fattibilità - SdF:} descrive i vari capitolati analizzando brevemente i loro pro e contro. \end{itemize}; \item \textbf{verbali - V:} essi possono essere sia interni che esterni e descrivono in maniera concisa tutti gli argomenti discussi e le decisione prese durante un incontro. \end{itemize} @@ -195,19 +193,18 @@ \section{Processi di Supporto} \item DB: \glock{database}; \item VCS: \glock{version control system}. \end{itemize} - \subsubsection{Introduzione alle Metriche di Qualità} - \paragraph{QC-1 Comprensione} - \subparagraph{Scopo} + \subsubsection{Comprensione (QC-1)} + \paragraph{Scopo} Per fornire una documentazione fruibile e comprensibile si è deciso di monitorare la sua qualità tramite delle metriche significative. - \subparagraph{Introduzione alle Metriche} + \paragraph{Introduzione alle Metriche di Qualità} Per la funzionabilità si é deciso di utilizzare le seguenti metriche: \begin{itemize} \item QM-PROD-1 \glock{Indice di Gulpease} (GULP); \item QM-PROD-2 Correttezza ortografica (CORT). \end{itemize} - \subparagraph{QM-PROD-1 Indice di Gulpease (GULP)} + \paragraph{QM-PROD-1 Indice di Gulpease (GULP)} \subparagraph{Descrizione} - La metrica GULP permette di misurare la leggibilità di un documento basandosi su alcuni criteri. + La metrica GULP permette di misurare la leggibilità di un documento basandosi sulla formula riportata di seguito. \subparagraph{Unità di Misura} La metrica è espressa tramite un numero intero. \subparagraph{Formula} @@ -222,10 +219,9 @@ \section{Processi di Supporto} \item se il risultato è maggiore di 40 allora il documento esiste ed è leggibile da chi possiede un diploma superiore; \item se il risultato è maggiore di 60 allora il documento esiste ed è leggibile da chi possiede una licenza media; \item se il risultato è maggiore di 80 allora il documento esiste ed è leggibile da chi possiede una licenza elementare; - \item se il risultato è maggiore di 60 allora il documento esiste ed è leggibile da chi possiede una licenza media; \item se il risultato è pari a 100 allora il documento esiste ed è molto più che leggibile. \end{itemize} - \subparagraph{QM-PROD-2 Correttezza ortografica (CORT)} + \paragraph{QM-PROD-2 Correttezza ortografica (CORT)} \subparagraph{Descrizione} La metrica CORT permette di misurare la correttezza, a livello lessicografico, di un documento. \subparagraph{Unità di Misura} @@ -241,9 +237,9 @@ \section{Processi di Supporto} \end{itemize} \subsubsection{Elementi grafici} \paragraph{Tabelle} - Le tabelle sono sempre accompagnate da un titolo ed il numero della tabella, esse sono indicizzate a parte. + Le tabelle sono sempre accompagnate da un titolo e dal numero della tabella; sono indicizzate separatamente rispetto al resto del contenuto. \paragraph{Immagini} - Le immagini sono sempre accompagnate da una didascalia descrittiva ed il numero della figura, esse sono indicizzate a parte. + Le immagini sono sempre accompagnate da una didascalia descrittiva e dal numero della figura; sono indicizzate separatamente rispetto al resto del contenuto. \paragraph{Diagrammi UML} I diagrammi UML vengono inseriti all'interno della documentazione sotto forma di immagini. \subsubsection{Strumenti} diff --git a/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/GaranziaQualita.tex b/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/GaranziaQualita.tex index ba3717c..6fb1078 100644 --- a/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/GaranziaQualita.tex +++ b/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/GaranziaQualita.tex @@ -2,11 +2,11 @@ \subsection{Garanzia della Qualità} \subsubsection{Scopo} - Si occupa di stabilire una metrica precisa per tutti i servizi nell'ambito della verifica e della validazione, mantenendo un certo grado di qualità che rimanga uniforme e misurabile durante tutto il ciclo di vita del software. + Si occupa di stabilire una metrica precisa per tutti i servizi nell'ambito della verifica e della validazione, mantenendo un dato livello di qualità che rimanga uniforme e misurabile durante tutto il ciclo di vita del software. \subsubsection{Aspettative} - Il sistema di qualità deve fornire delle metriche di giudizio uniformi volte a quantificare in maniera comprensibile la correttezza dei documenti e del software. Ciò va unito anche all'affidabilità nello svolgimento dei processi di verifica, che vanno monitorati e guidati nell'intera procedura, senza lasciare a interpretazioni. Pertanto, ci si aspetta: + Il sistema di qualità deve fornire delle metriche di giudizio uniformi volte a quantificare con chiarezza la correttezza dei documenti e del software. Ciò va unito anche all'affidabilità nello svolgimento dei processi di verifica, che vanno monitorati e guidati nell'intera procedura, senza lasciare a interpretazioni. Pertanto, ci si aspetta: \begin{itemize} \item un prodotto software di qualità; \item una documentazione completa e facilmente comprensibile per tutti; @@ -25,13 +25,13 @@ \subsection{Garanzia della Qualità} \end{itemize} Per ogni processo mirato alla qualità si definiscono delle metriche che vengono riportate in ciascuna sezione del presente documento. - La registrazione dei risultati ottenuti dall'analisi della qualità sono salvati con degli appositi report. + Le registrazioni dei risultati ottenuti dall'analisi della qualità sono salvate con degli appositi report. \paragraph{Obiettivi Qualità di Prodotto} La qualità del prodotto viene garantita attraverso l'attuazione dei processi di verifica e validazione basati su fondamenti normativi. In particolare, definiamo quanto segue: \begin{itemize} - \item \textbf{Verifica:} processo di analisi continua che garantisce qualità dei processi di fornitura del prodotto; + \item \textbf{Verifica:} processo di controllo che garantisce qualità dei processi di fornitura del prodotto; \item \textbf{Validazione:} processo di controllo del prodotto volto a confermare le aspettative, i requisiti e le funzionalità concordate. \end{itemize} @@ -42,8 +42,8 @@ \subsection{Garanzia della Qualità} La qualità di processo deve essere perseguita nel corso del ciclo di vita del software attraverso i principi di efficacia ed efficienza mirati al prodotto. Nello specifico definiamo quanto segue: \begin{itemize} - \item \textbf{Efficacia:} si richiede un prodotto valido in relazione alle aspettative; - \item \textbf{Efficienza:} i processi devono convergere con costi ridotti in termini di risorse a pari di qualità di prodotto. + \item \textbf{Efficacia:} si richiede un prodotto che soddisfi le richieste del proponente; + \item \textbf{Efficienza:} i processi devono convergere con costi ridotti in termini di risorse a pari qualità di prodotto. \end{itemize} Ciascun processo va migliorato durante la sua esecuzione facendo uso di monitoraggi mirati che permettano di acquisire, attraverso l'esperienza, una risposta critica alla qualità stessa del processo. @@ -75,7 +75,7 @@ \subsection{Garanzia della Qualità} \begin{itemize} \item QC : indica letteralmente \textit{Quality Characteristic}; - \item \(\lambda\) : numero intero che parte da 1 e indica la caratteristica di prodotto. + \item \(\lambda\) : numero intero che indica la caratteristica di prodotto e parte da 1. \end{itemize} \subsection{Classificazione delle Metriche} diff --git a/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/GestConfigurazione.tex b/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/GestConfigurazione.tex index c18853b..c3a402e 100644 --- a/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/GestConfigurazione.tex +++ b/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/GestConfigurazione.tex @@ -20,7 +20,7 @@ \subsubsection{Repository} \paragraph{Configurazione del Workflow} - Usando \textit{Git}, è possibile clonare e scaricare da remoto tutto il contenuto della repository per averne una copia in locale su cui poterci lavorare, visionando la cronologia dei file modificati ad ogni \glock{commit} da parte di un membro del gruppo. + Usando \textit{Git}, è possibile clonare e scaricare da remoto tutto il contenuto della repository per averne una copia in locale su cui poter lavorare, visionando la cronologia dei file modificati ad ogni \glock{commit} da parte di un membro del gruppo. \textit{Git}, inoltre, include la possibilità di creare dei \glock{branch} (locali e remoti) in cui poter sviluppare in maniera indipendente una funzionalità, che potrà essere integrata successivamente, senza bisogno di stare al passo con gli aggiornamenti della repository. Pertanto, si è deciso di stabilire il seguente canone di \glock{workflow} per quanto concerne la documentazione: @@ -40,7 +40,7 @@ \subsubsection{Repository} \subparagraph{Configurazione} - In generale, vengono utilizzati alcuni file con formati speciali per la configurazione della repository. Questi file vanno modificati solamente dall'\glock{amministratore}, o su richiesta, in base alle necessità. + In generale, vengono utilizzati alcuni file con formati speciali per la configurazione della repository. Questi file vanno modificati solamente dall'\glock{amministratore}, o su richiesta, anche da parte di altri membri del gruppo, in base alle necessità. \begin{itemize} \item \textbf{.gitignore} contiene tutte le regole per evitare di caricare nella repository dei formati non autorizzati (es: file eseguibili); \item \textbf{.yml} contiene la configurazione di una \glock{GitHub Action} per dirigere il \glock{Workflow}; @@ -51,10 +51,10 @@ \subsubsection{Repository} Per la documentazione si usano principalmente i seguenti tipi di file: \begin{itemize} - \item \textbf{file .tex:} che contiene il codice sorgente \LaTeX{} del documento; - \item \textbf{file .pdf:} che è il documento compilato; - \item \textbf{file .png:} che identifica una immagine; - \item \textbf{file .md:} che identifica un file scritto in \glock{Markdown}, generalmente usato per gli appunti. + \item \textbf{file .tex:} contiene il codice sorgente \LaTeX{} del documento; + \item \textbf{file .pdf:} è il documento compilato; + \item \textbf{file .png:} identifica una immagine; + \item \textbf{file .md:} identifica un file scritto in \glock{Markdown}, generalmente usato per gli appunti. \end{itemize} \paragraph{Struttura della repository} diff --git a/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/ProcDiRisoluzioneDeiProblemi.tex b/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/ProcDiRisoluzioneDeiProblemi.tex index 74afa3f..6eb6305 100644 --- a/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/ProcDiRisoluzioneDeiProblemi.tex +++ b/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/ProcDiRisoluzioneDeiProblemi.tex @@ -3,14 +3,14 @@ \subsection{Processo di risoluzione dei problemi} Il processo di risoluzione dei problemi definisce una procedura da seguire per analizzare e rimuovere dei problemi, qualsiasi sia la loro origine, scoperti durante l'esecuzione del processo di sviluppo, di manutenzione o di altri processi. \subsubsection{Scopo} - L'obiettivo del processo di risoluzione dei problemi è quello di fornire un mezzo tempestivo, efficace e documentato per assicurarsi che tutti i problemi vengano analizzati, documentati, risolti e, in un'ottica di miglioramento continuo evitati. + L'obiettivo del processo di risoluzione dei problemi è fornire un mezzo tempestivo, efficace e documentato per assicurarsi che tutti i problemi vengano analizzati, documentati, risolti e, in un'ottica di miglioramento continuo, evitati. \subsubsection{Aspettative} Istanziando questo processo si intende ottenere: \begin{itemize} - \item Una qualità della documentazione e del codice più elevata; - \item Un modo efficiente ed efficace per trovare e correggere errori evitando che si propaghino; - \item Un tracciamento continuo degli errori più comuni e delle loro fonti, in modo tale da risolverli all'origine. + \item una qualità della documentazione e del codice più elevata; + \item un modo efficiente ed efficace per trovare e correggere errori evitando che si propaghino; + \item un tracciamento continuo degli errori più comuni e delle loro fonti, in modo tale da risolverli all'origine. \end{itemize} \subsubsection{Attività} \paragraph{Implementazione del processo} @@ -56,4 +56,4 @@ \subsection{Processo di risoluzione dei problemi} \item Il procedimento di risoluzione dei problemi verrà valutato: si valuterà che i problemi siano stati effettivamente risolti, che le eventuali tendenze siano state annullate ed infine che non siano stati introdotti altri errori. \end{enumerate} \paragraph{Risoluzione del problema} - Quando uno o più problemi saranno scovati, nel prodotto software o in un'attività, dovrà essere preparato un report aprendo una issue nell'ITS (Issue tracking System) utilizzato per ogni problema individuato. Lo stesso report dovrà essere parte integrante del procedimento che è stato descritto nell'attività di istanziazione del processo. + Quando uno o più problemi saranno rilevati, nel prodotto software o in un'attività, dovrà essere preparato un report aprendo una issue nell'ITS (Issue tracking System) utilizzato per ogni problema individuato. Lo stesso report dovrà essere parte integrante del procedimento che è stato descritto nell'attività di istanziazione del processo. diff --git a/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/Validazione.tex b/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/Validazione.tex index bf262ba..2a592f5 100644 --- a/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/Validazione.tex +++ b/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/Validazione.tex @@ -1,9 +1,9 @@ \subsection{Validazione} \subsubsection{Scopo} - Lo scopo del processo di validazione consiste nel garantire che il prodotto rispetta le richieste del committente, e quindi che esegue correttamente. + Lo scopo del processo di validazione consiste nel garantire che il prodotto rispetti le richieste del committente, e quindi che esegua correttamente. \subsubsection{Aspettative} - Per garantire che venga raggiunto lo scopo del processo di validazione, si eseguono le attività con dei test documentati e l'output generato corrisponde a quello aspettato. + Per garantire che venga raggiunto lo scopo, le attività vengono testate dal processo di validazione, mandandole in esecuzione e confrontando l'output ottenuto con quello atteso. \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à} @@ -12,19 +12,19 @@ \subsection{Validazione} 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}: se il test è stato implementato; - \item \textbf{NI}: se 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}: se il test ha successo; - \item \textbf{F}: se 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. \subparagraph*{Test di Accettazione} I test di accettazione (o collaudo) accertano il soddisfacimento degli use case e dei requisiti concordati con il cliente. - Più in particolare test di accettazione servono a confermare che i requisiti derivati dai casi d'uso specificati nel capitolato siano stati soddisfatti. Questi test richiedono perciò la presenza del committente e del proponente. + Più in particolare i test di accettazione servono a confermare che i requisiti derivati dai casi d'uso specificati nel capitolato siano stati soddisfatti. Questi test richiedono perciò la presenza del committente e del proponente. Per classificare questi tipi di test verrà associata un codice ad ognuno di essi secondo il seguente modello: \begin{center} @@ -45,4 +45,4 @@ \subsection{Validazione} \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. + \textbf{Identificativo}: numero progressivo il cui obiettivo sarà di contraddistinguere il singolo componente da testare; parte da 1. \ 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 6f4a471..b412b1b 100644 --- a/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/Verifica.tex +++ b/interni/norme_progetto/res/sections/Sez3-ProcessiSupporto/Verifica.tex @@ -2,17 +2,17 @@ \subsection{Verifica} \subsubsection{Scopo} - Il processo di verifica ha lo scopo di capire se il prodotto è realizzato nel modo corretto secondo delle regole stabilite. + Il processo di verifica ha lo scopo di stabilire se il prodotto è realizzato nel modo corretto secondo delle regole stabilite. \subsubsection{Aspettative} Lo svolgimento del processo di verifica sarà garantito seguendo determinati punti: \begin{itemize} - \item Definizione di criteri di accettazione; - \item Prescrizione delle attività di verifica con relativa documentazione; - \item Test di verifica; - \item Correzione di eventuali \glock{difetti}. + \item definizione di criteri di accettazione; + \item prescrizione delle attività di verifica con relativa documentazione; + \item test di verifica; + \item correzione di eventuali \glock{difetti}. \end{itemize} \subsubsection{Descrizione} @@ -23,13 +23,13 @@ \subsection{Verifica} 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 si conosce dove possono trovarsi i possibili \textit{difetti}, 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 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 Parole/frasi in grassetto/corsivo; - \item Uso di riferimenti appropriati al Glossario/Documento. + \item elenchi puntati; + \item formato Date; + \item parole/frasi in grassetto/corsivo; + \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}: se il test è stato implementato; - \item \textbf{NI}: se 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}: se il test ha successo; - \item \textbf{F}: se 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. @@ -79,10 +79,10 @@ \subsection{Verifica} \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. + \textbf{Identificativo}: numero progressivo il cui obiettivo sarà di contraddistinguere il singolo componente da testare; parte da 1. \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. + 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} @@ -90,7 +90,7 @@ \subsection{Verifica} \end{center} dove: - \textbf{Identificativo}: numero progressivo il cui obiettivo sarà di contraddistinguere il singolo componente da testare. + \textbf{Identificativo}: numero progressivo il cui obiettivo sarà di contraddistinguere il singolo componente da testare; parte da 1. \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à. @@ -101,10 +101,10 @@ \subsection{Verifica} \end{center} dove: - \textbf{Identificativo}: numero progressivo il cui obiettivo sarà di contraddistinguere il singolo componente da testare. + \textbf{Identificativo}: numero progressivo il cui obiettivo sarà di contraddistinguere il singolo componente da testare; parte da 1. \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 causa il funzionamento scorretto di altre unità collegate all'unità modificata. + 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} diff --git a/interni/norme_progetto/res/sections/Sez4-ProcessiOrganizzativi/FormazionePersonale.tex b/interni/norme_progetto/res/sections/Sez4-ProcessiOrganizzativi/FormazionePersonale.tex index 42e1a89..8e8d897 100644 --- a/interni/norme_progetto/res/sections/Sez4-ProcessiOrganizzativi/FormazionePersonale.tex +++ b/interni/norme_progetto/res/sections/Sez4-ProcessiOrganizzativi/FormazionePersonale.tex @@ -1,10 +1,10 @@ \subsection{Formazione del personale} \subsubsection{Scopo} - 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. + 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. \subsubsection{Descrizione} - Ogni persona dovrà quindi auto documentarsi sui linguaggi e gli strumenti di programmazione che verranno utilizzati per tutto il periodo di sviluppo del progetto, se sconosciuti. + 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} Di seguito verranno elencate le tecnologie ed i linguaggi di programmazione necessari per lo svolgimento del capitolato con i relativi link al sito ufficiale: diff --git a/interni/norme_progetto/res/sections/Sez4-ProcessiOrganizzativi/GestProcessi.tex b/interni/norme_progetto/res/sections/Sez4-ProcessiOrganizzativi/GestProcessi.tex index de6b6a7..4db82da 100644 --- a/interni/norme_progetto/res/sections/Sez4-ProcessiOrganizzativi/GestProcessi.tex +++ b/interni/norme_progetto/res/sections/Sez4-ProcessiOrganizzativi/GestProcessi.tex @@ -50,7 +50,7 @@ \subsection{Gestione dei Processi} \paragraph{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 persone esterne al gruppo, quali committente e proponente del capitolato, ed è il responsabile ultimo dei risultati del progetto. + 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 In particolare si occupa di: @@ -306,7 +306,7 @@ \subsection{Gestione dei Processi} \item \textbf{Tipo:} indica la tipologia del verbale, ossia: \begin{itemize} \item \textbf{I:} indica che il verbale si riferisce ad un incontro interno; - \item \textbf{E:} indica che il verbale si riferisce ad un incontro esterno; + \item \textbf{E:} indica che il verbale si riferisce ad un incontro esterno. \end{itemize} \item \textbf{Numero:} numero intero progressivo che fornisce un'indicazione riguardo all'ordine temporale di svolgimento degli incontri. \end{itemize} @@ -350,19 +350,19 @@ \subsection{Gestione dei Processi} \item \textbf{P:} personale, riguardante le persone che fanno parte del gruppo, le loro conoscenze e le loro capacità; \item \textbf{R:} requisiti, riguardante le modifiche ai requisiti che possono avvenire durante lo sviluppo del progetto; \item \textbf{S:} strumentale, riguardante gli strumenti software impiegati per lo sviluppo del progetto, il loro utilizzo e le loro prestazioni; - \item \textbf{T:} tecnologico, riguardante le tecnologie hardware o software impiegate per lo sviluppo del progetto, il loro utilizzo e le loro funzionalità; + \item \textbf{T:} tecnologico, riguardante le tecnologie hardware o software impiegate per lo sviluppo del progetto, il loro utilizzo e le loro funzionalità. \end{itemize} \item \textbf{Probabilità:} livello di possibilità che il rischio si verifichi, che può essere può essere: \begin{itemize} \item \textbf{A}: alta; \item \textbf{M}: media; - \item \textbf{B}: bassa; + \item \textbf{B}: bassa. \end{itemize} \item \textbf{Gravità:} livello di pericolosità del rischio, che può essere: \begin{itemize} \item \textbf{A:} accettabile; \item \textbf{T:} tollerabile; - \item \textbf{I:} inaccettabile; + \item \textbf{I:} inaccettabile. \end{itemize} \item \textbf{ID:} numero intero progressivo che fornisce la numerazione dei vari rischi della stessa tipologia, probabilità e gravità. @@ -373,19 +373,19 @@ \subsection{Gestione dei Processi} Per la gestione dei rischi si farà uso delle seguenti metriche: \begin{itemize} - \item QM-PROC-6. Unbudgeted Risks (UR) + \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. + 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{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. + 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. La formula della metrica è la seguente: \[ \text{UR} = \text{UR} + 1 @@ -393,8 +393,8 @@ \subsection{Gestione dei Processi} \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. + \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{Strumenti}