<commit_before>\section{Processi primari}

\subsection{Fornitura}
\subsubsection{Studio di Fattibilità}
In seguito ad una discussione tra i componenti del gruppo sui capitolati proposti, è compito degli \Analisti{} redigere lo \textit{Studio di Fattibilità} di tali capitolati. Devono essere analizzati:
\begin{itemize}
	\item dominio tecnologico e applicativo: si valutano la conoscenza pregressa delle tecnologie richieste e del dominio applicativo;
	\item utenza: si valuta l'insieme di utenti a cui è rivolto il prodotto;
	\item rapporto costi/benefici: si valutano prodotti già esistenti, possibilità di affermazione nel mercato, costi di realizzazione e benefici del prodotto finito;
	\item rischi: si individuano i punti critici in cui la realizzazione potrebbe incorrere, a partire dalla conoscenza del dominio, fino alla verifica dei requisiti.
\end{itemize}
Deve essere quindi convocata una riunione interna per la decisione finale sul capitolato su cui svolgere il progetto.

\subsection{Sviluppo}

\subsubsection{Analisi dei Requisiti}
\paragraph{Ricerca dei requisiti}\mbox{}\\
Le funzionalità che caratterizzeranno il prodotto alla fornitura vengono concordate con gli \glossario{stakeholders} al momento della presentazione del capitolato d'appalto e attraverso il \glossario{gathering} di informazioni durante le riunioni. Viene fornita nel documento apposito \AnalisiDeiRequisiti{} la descrizione da parte del fornitore del suddetto prodotto.\\
Per assicurare una corretta e completa analisi deve essere stilato l'elenco dei casi d'uso.\\
Ogni caso d'uso deve essere descritto in modo formale seguendo le direttive presenti nel paragrafo \sezione{modellazione-casi-uso}.\\
I requisiti devono essere descritti fino al massimo livello di dettaglio nella Tabella dei Requisiti presente nel documento \AnalisiDeiRequisiti, includendo una descrizione delle fonti da cui derivano, siano esse interne o esterne.

\subparagraph{Modellazione dei casi d'uso}\mbox{}\label{modellazione-casi-uso}\\
Ogni caso d'uso deve essere descritto con:
\begin{itemize}
	\item titolo;
	\item attori;
	\item scopo e descrizione breve;
	\item precondizioni;
	\item flusso principale degli eventi, considerando eventuali distinzioni dei casi al suo interno;
	\item post-condizione.
\end{itemize}
Il caso d'uso deve essere accompagnato da un grafico riassuntivo in \glossario{UML} 2.5, titolato come il caso d'uso.\\
I casi d'uso devono essere catalogati secondo le seguenti norme:
\begin{center}
	UC[numero][caso]
\end{center}
dove:
\begin{itemize}
	\item \textit{UC} specifica che si sta parlando di un caso d'uso;
	\item \textit{numero} è assoluto e rappresenta un riferimento univoco al caso d'uso in questione;
	\item \textit{caso} individua eventuali diramazioni all'interno dello stesso caso d’uso.
\end{itemize}

\subparagraph{Classificazione dei requisiti}\mbox{}\\
I requisiti emersi dal capitolato devono essere catalogati secondo le seguenti norme:
\begin{center}
	R[utilità strategica][attributi di prodotto][numero]
\end{center}
dove:
\begin{itemize}
	\item \textit{R} specifica che si sta parlando di un requisito;
	\item \textit{utilità strategica} assume uno dei seguenti valori:
	\begin{enumerate}
		\item se il requisito è obbligatorio;
		\item se il requisito è desiderabile;
		\item se il requisito è opzionale.
	\end{enumerate}
	\item \textit{attributi di prodotto} assume uno dei seguenti valori:
	\begin{itemize}
		\item [F] se il requisito è funzionale;
		\item [P] se il requisito è prestazionale;
		\item [Q] se il requisito è di qualità;
		\item [V] se il requisito è di vincolo.
	\end{itemize}
	\item \textit{numero} è assoluto e rappresenta un riferimento univoco al requisito in questione.
\end{itemize}

\paragraph{Tracciamento}\mbox{}\\
\`{E} compito degli \Analisti{} controllare la corrispondenza tra i requisiti e le loro fonti (capitolato, casi d'uso, verbali di riunioni). Questa corrispondenza deve essere presentata nelle due tabelle di tracciamento Fonti-Requisiti e Requisiti-Fonti per facilitarne la consultazione. 

\subsubsection{Progettazione}
\paragraph{Specifica Tecnica}\mbox{}\\
\`{E} compito dei \Progettisti{} descrivere la \PA{} ad alto livello del prodotto nella \SpecificaTecnica.

\subparagraph{Diagrammi UML}\mbox{}\\
Devono essere realizzati i seguenti diagrammi:
\begin{itemize}
	\item diagrammi dei \glossario{package};
	\item diagrammi delle classi;
	\item diagrammi di sequenza;
	\item diagrammi di attività.
\end{itemize}

\subparagraph{Design pattern}\mbox{}\\
Devono essere descritti i \glossario{design pattern} utilizzati specificando:
\begin{itemize}
	\item scopo del \glossario{design pattern};
	\item funzionamento del \glossario{design pattern};
	\item diagramma delle classi generico del \glossario{design pattern}.
\end{itemize}

\subparagraph{Tracciamento Componenti}\mbox{}\\
Deve essere tracciata la corrispondenza tra requisiti e componenti che li soddisfano.

\paragraph{Definizione di Prodotto}\mbox{}\\
\`{E} compito dei \Progettisti{} stilare la \DefinizioneDiProdotto, in cui è descritta la \PD{} del prodotto, ampliando quanto detto nella \SpecificaTecnica.

\subparagraph{Diagrammi UML}\mbox{}\\
Devono essere aggiornati i seguenti diagrammi:
\begin{itemize}
	\item Diagrammi delle classi;
	\item Diagrammi di sequenza;
	\item Diagrammi di attività.
\end{itemize}

\subparagraph{Definizione di Classe}\mbox{}\\
Nella \DefinizioneDiProdotto{} deve essere descritta ogni classe progettata, secondo lo standard \glossario{UML} 2.5. La descrizione deve essere costituita da:
\begin{itemize}
	\item \textbf{attributi}: vanno indicati l'accessibilità, il nome e la descrizione di ognuno;
	\item \textbf{metodi}: vanno indicati l'accessibilità, il nome e la descrizione di ognuno;
	\item \textbf{parametri}: vanno racchiusi tra parentesi tonde e devono essere riportati con nome e tipo, separati da due punti;
	\item \textbf{argomenti}: vanno indicati la direzione tra parentesi quadre, nome e tipo separati da due punti, seguiti da una breve descrizione.
\end{itemize}
Ogni classe deve inoltre essere accompagnata da una descrizione che ne includa lo scopo e le funzionalità.

\subparagraph{Tracciamento delle Classi}\mbox{}\\
Deve essere tracciata la corrispondenza tra requisiti e classi che li soddisfano.

\subparagraph{Test}\mbox{}\\
\`{E} compito dei \Progettisti{} configurare in modo adeguato i test di unità e di integrazione, tramite \glossario{driver}, \glossario{stub} ed altri eventuali strumenti.\\
\`{E} responsabilità del \Programmatore{} attuare i test di unità più semplici, mentre i restanti devono essere eseguiti tramite strumenti automatici.\\
I test di integrazione devono essere eseguiti tramite strumenti automatici quando possibile. \`{E} compito dei \Verificatori{} verificarne l'integrità.\\
Devono essere eseguiti inoltre test di regressione in caso di modifiche, per accertare che queste non causino errori nelle parti già sottoposte a verifica con esito positivo. In questo modo viene garantito che le modifiche effettuate non pregiudichino le funzionalità esistenti e già testate.

\subsubsection{Codifica}
Tutti i file contenenti codice o documentazione dovranno essere conformi alla codifica \glossario{UTF-8}.

\paragraph{Convenzioni} \label{sec:convenzioni}\mbox{}\\
Al fine di ottimizzare il passaggio tra progettazione e prodotto finale, i \Programmatori{} sono tenuti a rispettare le convenzioni che seguono.\\
Si è deciso di seguire le linee guida specificate nel capitolato e concordate con il proponente:
\begin{itemize}
	\item \glossario{Airbnb JavaScript style guide};\footnote{\url{https://github.com/airbnb/javascript}}
	\item \glossario{12 Factors app}\footnote{\url{https://12factor.net/}} documentandone l'utilizzo;
	\item limitare i commenti alle sole parti di codice che richiedano una spiegazione immediata del loro funzionamento;
	\item evitare le \glossario{callback}, o motivarne opportunamente l’uso.
\end{itemize}
\paragraph{Ricorsione}\mbox{}\\
La ricorsione deve essere evitata quando possibile, onde evitare un elevato consumo di memoria a discapito delle performance del prodotto finale.

\subsubsection{Verifica}
L’attività di verifica deve essere svolta in modo continuativo durante l'avanzamento del progetto. Sono quindi definite modalità operative per agevolare il lavoro dei \Verificatori.

\paragraph{Analisi statica}\mbox{}\\
\`{E} prevista l'attività di analisi statica, applicata a tutti i processi del progetto, per individuare errori nella documentazione e nel software prodotto. Viene eseguita da \Verificatori{} e \Programmatori{}, con ruoli distinti.

\subparagraph{Walkthrough} \mbox{}\\
Si esegue una lettura critica del documento (o codice), a largo spettro e senza alcun presupposto. A seguito di questa attività deve essere redatta una lista che riporti gli errori rilevati con più frequenza, la quale verrà inserita in questo documento per favorire l'uso della tecnica \glossario{inspection} nelle verifiche successive.

\subparagraph{Inspection} \mbox{}\\
Si esegue una lettura mirata del documento (o codice), focalizzando la ricerca sui presupposti individuati tramite precedenti analisi \glossario{walkthrough}.

\subparagraph{Linting}\mbox{}\\
Vengono identificate nel codice prodotto strutture che non rispettano le linee guida imposte tramite strumenti automatici che analizzano il codice e individuano pattern indesiderati o discrepanze.\\
Alcuni di questi sono:\begin{itemize}
	\item variabili usate prima di essere inizializzate;  
	\item divisioni per zero;
	\item condizioni costanti;
	\item operazioni il cui risultato probabilmente potrebbe risultare esterno all'intervallo di valori rappresentabili con il tipo usato.
\end{itemize}
Lo strumento utilizzato per questo tipo di analisi è \glossario{ESLint}, ottimizzato per la \glossario{Airbnb JavaScript style guide} indicata in \sezione{sec:convenzioni} di questo documento. \glossario{ESLint} viene descritto in \sezione{sec:eslint}.

\paragraph{Analisi dinamica}\mbox{}\\
\`{E} prevista l’attività di analisi dinamica per il software prodotto per verificarne il corretto funzionamento, in quanto si avvale dell'esecuzione di test su di esso.<commit_msg>aggiornato paragrafo processo verifica<commit_after>\section{Processi primari}

\subsection{Fornitura}
\subsubsection{Studio di Fattibilità}
In seguito ad una discussione tra i componenti del gruppo sui capitolati proposti, è compito degli \Analisti{} redigere lo \textit{Studio di Fattibilità} di tali capitolati. Devono essere analizzati:
\begin{itemize}
	\item dominio tecnologico e applicativo: si valutano la conoscenza pregressa delle tecnologie richieste e del dominio applicativo;
	\item utenza: si valuta l'insieme di utenti a cui è rivolto il prodotto;
	\item rapporto costi/benefici: si valutano prodotti già esistenti, possibilità di affermazione nel mercato, costi di realizzazione e benefici del prodotto finito;
	\item rischi: si individuano i punti critici in cui la realizzazione potrebbe incorrere, a partire dalla conoscenza del dominio, fino alla verifica dei requisiti.
\end{itemize}
Deve essere quindi convocata una riunione interna per la decisione finale sul capitolato su cui svolgere il progetto.

\subsection{Sviluppo}

\subsubsection{Analisi dei Requisiti}
\paragraph{Ricerca dei requisiti}\mbox{}\\
Le funzionalità che caratterizzeranno il prodotto alla fornitura vengono concordate con gli \glossario{stakeholders} al momento della presentazione del capitolato d'appalto e attraverso il \glossario{gathering} di informazioni durante le riunioni. Viene fornita nel documento apposito \AnalisiDeiRequisiti{} la descrizione da parte del fornitore del suddetto prodotto.\\
Per assicurare una corretta e completa analisi deve essere stilato l'elenco dei casi d'uso.\\
Ogni caso d'uso deve essere descritto in modo formale seguendo le direttive presenti nel paragrafo \sezione{modellazione-casi-uso}.\\
I requisiti devono essere descritti fino al massimo livello di dettaglio nella Tabella dei Requisiti presente nel documento \AnalisiDeiRequisiti, includendo una descrizione delle fonti da cui derivano, siano esse interne o esterne.

\subparagraph{Modellazione dei casi d'uso}\mbox{}\label{modellazione-casi-uso}\\
Ogni caso d'uso deve essere descritto con:
\begin{itemize}
	\item titolo;
	\item attori;
	\item scopo e descrizione breve;
	\item precondizioni;
	\item flusso principale degli eventi, considerando eventuali distinzioni dei casi al suo interno;
	\item post-condizione.
\end{itemize}
Il caso d'uso deve essere accompagnato da un grafico riassuntivo in \glossario{UML} 2.5, titolato come il caso d'uso.\\
I casi d'uso devono essere catalogati secondo le seguenti norme:
\begin{center}
	UC[numero][caso]
\end{center}
dove:
\begin{itemize}
	\item \textit{UC} specifica che si sta parlando di un caso d'uso;
	\item \textit{numero} è assoluto e rappresenta un riferimento univoco al caso d'uso in questione;
	\item \textit{caso} individua eventuali diramazioni all'interno dello stesso caso d’uso.
\end{itemize}

\subparagraph{Classificazione dei requisiti}\mbox{}\\
I requisiti emersi dal capitolato devono essere catalogati secondo le seguenti norme:
\begin{center}
	R[utilità strategica][attributi di prodotto][numero]
\end{center}
dove:
\begin{itemize}
	\item \textit{R} specifica che si sta parlando di un requisito;
	\item \textit{utilità strategica} assume uno dei seguenti valori:
	\begin{enumerate}
		\item se il requisito è obbligatorio;
		\item se il requisito è desiderabile;
		\item se il requisito è opzionale.
	\end{enumerate}
	\item \textit{attributi di prodotto} assume uno dei seguenti valori:
	\begin{itemize}
		\item [F] se il requisito è funzionale;
		\item [P] se il requisito è prestazionale;
		\item [Q] se il requisito è di qualità;
		\item [V] se il requisito è di vincolo.
	\end{itemize}
	\item \textit{numero} è assoluto e rappresenta un riferimento univoco al requisito in questione.
\end{itemize}

\paragraph{Tracciamento}\mbox{}\\
\`{E} compito degli \Analisti{} controllare la corrispondenza tra i requisiti e le loro fonti (capitolato, casi d'uso, verbali di riunioni). Questa corrispondenza deve essere presentata nelle due tabelle di tracciamento Fonti-Requisiti e Requisiti-Fonti per facilitarne la consultazione. 

\subsubsection{Progettazione}
\paragraph{Specifica Tecnica}\mbox{}\\
\`{E} compito dei \Progettisti{} descrivere la \PA{} ad alto livello del prodotto nella \SpecificaTecnica.

\subparagraph{Diagrammi UML}\mbox{}\\
Devono essere realizzati i seguenti diagrammi:
\begin{itemize}
	\item diagrammi dei \glossario{package};
	\item diagrammi delle classi;
	\item diagrammi di sequenza;
	\item diagrammi di attività.
\end{itemize}

\subparagraph{Design pattern}\mbox{}\\
Devono essere descritti i \glossario{design pattern} utilizzati specificando:
\begin{itemize}
	\item scopo del \glossario{design pattern};
	\item funzionamento del \glossario{design pattern};
	\item diagramma delle classi generico del \glossario{design pattern}.
\end{itemize}

\subparagraph{Tracciamento Componenti}\mbox{}\\
Deve essere tracciata la corrispondenza tra requisiti e componenti che li soddisfano.

\paragraph{Definizione di Prodotto}\mbox{}\\
\`{E} compito dei \Progettisti{} stilare la \DefinizioneDiProdotto, in cui è descritta la \PD{} del prodotto, ampliando quanto detto nella \SpecificaTecnica.

\subparagraph{Diagrammi UML}\mbox{}\\
Devono essere aggiornati i seguenti diagrammi:
\begin{itemize}
	\item Diagrammi delle classi;
	\item Diagrammi di sequenza;
	\item Diagrammi di attività.
\end{itemize}

\subparagraph{Definizione di Classe}\mbox{}\\
Nella \DefinizioneDiProdotto{} deve essere descritta ogni classe progettata, secondo lo standard \glossario{UML} 2.5. La descrizione deve essere costituita da:
\begin{itemize}
	\item \textbf{attributi}: vanno indicati l'accessibilità, il nome e la descrizione di ognuno;
	\item \textbf{metodi}: vanno indicati l'accessibilità, il nome e la descrizione di ognuno;
	\item \textbf{parametri}: vanno racchiusi tra parentesi tonde e devono essere riportati con nome e tipo, separati da due punti;
	\item \textbf{argomenti}: vanno indicati la direzione tra parentesi quadre, nome e tipo separati da due punti, seguiti da una breve descrizione.
\end{itemize}
Ogni classe deve inoltre essere accompagnata da una descrizione che ne includa lo scopo e le funzionalità.

\subparagraph{Tracciamento delle Classi}\mbox{}\\
Deve essere tracciata la corrispondenza tra requisiti e classi che li soddisfano.

\subparagraph{Test}\mbox{}\\
\`{E} compito dei \Progettisti{} configurare in modo adeguato i test di unità e di integrazione, tramite \glossario{driver}, \glossario{stub} ed altri eventuali strumenti.\\
\`{E} responsabilità del \Programmatore{} attuare i test di unità più semplici, mentre i restanti devono essere eseguiti tramite strumenti automatici.\\
I test di integrazione devono essere eseguiti tramite strumenti automatici quando possibile. \`{E} compito dei \Verificatori{} verificarne l'integrità.\\
Devono essere eseguiti inoltre test di regressione in caso di modifiche, per accertare che queste non causino errori nelle parti già sottoposte a verifica con esito positivo. In questo modo viene garantito che le modifiche effettuate non pregiudichino le funzionalità esistenti e già testate.

\subsubsection{Codifica}
Tutti i file contenenti codice o documentazione dovranno essere conformi alla codifica \glossario{UTF-8}.

\paragraph{Convenzioni} \label{sec:convenzioni}\mbox{}\\
Al fine di ottimizzare il passaggio tra progettazione e prodotto finale, i \Programmatori{} sono tenuti a rispettare le convenzioni che seguono.\\
Si è deciso di seguire le linee guida specificate nel capitolato e concordate con il proponente:
\begin{itemize}
	\item \glossario{Airbnb JavaScript style guide};\footnote{\url{https://github.com/airbnb/javascript}}
	\item \glossario{12 Factors app}\footnote{\url{https://12factor.net/}} documentandone l'utilizzo;
	\item limitare i commenti alle sole parti di codice che richiedano una spiegazione immediata del loro funzionamento;
	\item evitare le \glossario{callback}, o motivarne opportunamente l’uso.
\end{itemize}
\paragraph{Ricorsione}\mbox{}\\
La ricorsione deve essere evitata quando possibile, onde evitare un elevato consumo di memoria a discapito delle performance del prodotto finale.

\subsubsection{Verifica}
L’attività di verifica deve essere svolta in modo continuativo durante l'avanzamento del progetto. Sono quindi definite modalità operative per agevolare il lavoro dei \Verificatori.

\paragraph{Analisi statica}\mbox{}\\
\`{E} prevista l'attività di analisi statica, applicata a tutti i processi del progetto, per individuare errori nella documentazione e nel software prodotto. Viene eseguita da \Verificatori{} e \Programmatori{}, con ruoli distinti.

\subparagraph{Walkthrough} \mbox{}\\
Si esegue una lettura critica del documento (o codice), a largo spettro e senza alcun presupposto. A seguito di questa attività deve essere redatta una lista che riporti gli errori rilevati con più frequenza, la quale verrà inserita in questo documento per favorire l'uso della tecnica \glossario{inspection} nelle verifiche successive.

\subparagraph{Inspection} \mbox{}\\
Si esegue una lettura mirata del documento (o codice), focalizzando la ricerca sui presupposti individuati tramite precedenti analisi \glossario{walkthrough}.

\subparagraph{Linting}\mbox{}\\
Vengono identificate nel codice prodotto strutture che non rispettano le linee guida imposte tramite strumenti automatici che analizzano il codice e individuano pattern indesiderati o discrepanze.\\
Alcuni di questi sono:\begin{itemize}
	\item variabili usate prima di essere inizializzate;  
	\item divisioni per zero;
	\item condizioni costanti;
	\item operazioni il cui risultato probabilmente potrebbe risultare esterno all'intervallo di valori rappresentabili con il tipo usato.
\end{itemize}
Lo strumento utilizzato per questo tipo di analisi è \glossario{ESLint}, ottimizzato per la \glossario{Airbnb JavaScript style guide} indicata in \sezione{sec:convenzioni} di questo documento. \glossario{ESLint} viene descritto in \sezione{sec:eslint}.

\subparagraph{Complexity report}\mbox{}\\
È un'applicazione installabile come modulo per Node.js e misura metriche riguardanti codice JavaScript, in particolare:
\begin{itemize}
	\item complessità ciclomatica;
	\item numero di parametri per funzioni;
	\item Halstead;
	\item core size;
	\item indice di manutenibilità.
\end{itemize}

\paragraph{Analisi dinamica}\mbox{}\\
\`{E} prevista l’attività di analisi dinamica per il software prodotto per verificarne il corretto funzionamento, in quanto si avvale dell'esecuzione di test su di esso.
Vengono utilizzati gli strumenti Mocha e Chai, integrati con lo strumento di testing offerto da Meteor\footnote{Per maggiori dettagli si rimanda al sito ufficiale https://guide.meteor.com/testing.html}

\subparagraph{Test}\mbox{}\\
Vengono svolti vari test, riportati nel \PianoDiQualifica{} e catalogati come segue:
\begin{center}
	T[tipo][numero]
\end{center}
dove
\begin{itemize}
	\item \textit{T} specifica che si sta parlando di un test;
	\item \textit{tipo} assume uno dei seguenti valori:
	\begin{itemize}
		\item [U] se il test è di unità;
		\item [I] se il test è di integrazione;
		\item [R] se il test è di regressione;
		\item [S] se il test è di sistema;
		\item [V] se il test è di validazione.
	\end{itemize}
	\item \textit{numero} è assoluto e rappresenta un riferimento univoco al test in questione.
\end{itemize}
In particolare:
\begin{itemize}
	\item i test di unità verificano che le singole componenti non abbiano errori prese individualmente;
	\item i test di integrazione verificano che più unità collaborino correttamente;
	\item i test di regressione verificano che le modifiche apportate non invalidino i test già svolti in precedenza;
	\item i test di sistema verificano che il prodotto soddisfi tutti i requisiti;
	\item i test di validazione coincidono con il collaudo finale.
\end{itemize}



{'fraction_non_alphanumeric': 0.07375113533151681, 'fraction_numerical': 0.0008174386920980927, 'mean_word_length': 5.194374120956399, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 5, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1887864', 'n_tokens_mistral': 7242, 'n_tokens_neox': 7326, 'n_words': 2670}