<commit_before>\section{Introduzione}
\subsection{Scopo del documento}
Questo documento ha l’obiettivo di identificare e dettagliare la pianificazione del gruppo BugBuster
relativa allo sviluppo del progetto MaaS. La ripartizione del carico di lavoro e di responsabilità tra i
componenti del gruppo, e il conto economico preventivo sono oggetto di primo piano in tale documento.

\subsection{Scopo del prodotto}
Lo scopo del progetto è la realizzazione di un Software as a Service che si basa sul progetto MaaP . Il prodotto atteso si chiama MaaS ossia MongoDB as an Admin Service.

\subsection{Glossario}
Al fine di evitare ogni ambiguità relativa al linguaggio impiegato nei documenti viene fornito il Glossario
v1.1 , contenente la definizione dei termini marcati con una G pedice.

\subsection{Riferimenti}
\subsubsection{Interni}
\begin{itemize}
\item Norme di Progetto v1.1
\item Capitolato d'appalto C4: MaaS: MongoDB as an admin Service: \\ \href{http://www.math.unipd.it/~tullio/IS-1/2015/Progetto/C4p.pdf}{http://www.math.unipd.it/~tullio/IS-1/2015/Progetto/C4p.pdf} 
\item Vincoli sull’organigramma del gruppo e sull’offerta tecnico-economica: \\
\href{http://www.math.unipd.it/~tullio/IS-1/2015/Progetto/PD01b.html}{http://www.math.unipd.it/~tullio/IS-1/2015/Progetto/PD01b.html}
\end{itemize}
\subsubsection{Esterni}
\begin{itemize}
\item <NAME>, Software Engineering, Part 4: Software Management, 9th edition, Boston, Pearson Education, 2011
\end{itemize}

\subsection{Ciclo di vita}
L’interesse del committente è limitato al segmento di ciclo di vita che va dall’analisi dei requisiti al
rilascio del prodotto, escludendo dunque la successiva manutenzione ed il ritiro. Il modello di ciclo di
vita scelto è il modello incrementale, ritenuto preferibile in quanto permette di scomporre in sottosistemi
il problema principale, riducendo i rischi derivati dalla scarsa conoscenza da parte del gruppo delle
tecnologie necessarie, come illustrato nello \textit{Studio di fattibilità}. Questo modello permette inoltre di:
\begin{itemize}
\item Soddisfare primariamente i requisiti principali, e dedicarsi successivamente a quelli opzionali,
potendo però offrire al proponente un sistema funzionante;
\item Minimizzare i rischi di ritardo rispetto ai tempi stabiliti in quanto i cicli hanno durata breve e
sono precedentemente pianificati;
\item Rendere più semplice la verifica.
\end{itemize}
<commit_msg>Advantage points for incremental model added<commit_after>\section{Introduzione}
\subsection{Scopo del documento}
Questo documento ha l’obiettivo di identificare e dettagliare la pianificazione del gruppo BugBuster
relativa allo sviluppo del progetto MaaS. La ripartizione del carico di lavoro e di responsabilità tra i
componenti del gruppo, e il conto economico preventivo sono oggetto di primo piano in tale documento.

\subsection{Scopo del prodotto}
Lo scopo del progetto è la realizzazione di un Software as a Service che si basa sul progetto MaaP . Il prodotto atteso si chiama MaaS ossia MongoDB as an admin Service.

\subsection{Glossario}
Al fine di evitare ogni ambiguità relativa al linguaggio impiegato nei documenti viene fornito il Glossario
v1.0.0 , contenente la definizione dei termini marcati con una G pedice.

\subsection{Riferimenti}
\subsubsection{Interni}
\begin{itemize}
\item Norme di Progetto v1.1
\item Capitolato d'appalto C4: MaaS: MongoDB as an admin Service: \\ \href{http://www.math.unipd.it/~tullio/IS-1/2015/Progetto/C4p.pdf}{http://www.math.unipd.it/\~tullio/IS-1/2015/Progetto/C4p.pdf} 
\item Vincoli sull’organigramma del gruppo e sull’offerta tecnico-economica: \\
\href{http://www.math.unipd.it/~tullio/IS-1/2015/Progetto/PD01b.html}{http://www.math.unipd.it/\~tullio/IS-1/2015/Progetto/PD01b.html}
\end{itemize}
\subsubsection{Esterni}
\begin{itemize}
\item <NAME>, Software Engineering, Part 4: Software Management, 9th edition, Boston, Pearson Education, 2011
\item The Guide to the Software Engineering Body of Knowledge V3 (SWEBOK)
\end{itemize}

\subsection{Ciclo di vita}
L’interesse del committente è limitato al segmento di ciclo di vita che va dall’analisi dei requisiti al
rilascio del prodotto, escludendo dunque la successiva manutenzione ed il ritiro. Il modello di ciclo di
vita scelto è quello incrementale, ritenuto preferibile in quanto:
\begin{itemize}
\item Permette di monitorare l'evoluzione del progetto senza mai eseguire iterazioni ma solo incrementi
\item Alla conclusione di ogni processo si ha una base verificata che ne permette un veloce successivo incremento
\item Permette di alternare le attività tra loro
\end{itemize}

{'fraction_non_alphanumeric': 0.07119600607770783, 'fraction_numerical': 0.01649663555459084, 'mean_word_length': 5.210242587601078, 'pattern_counts': {'":': 0, '<': 5, '<?xml version=': 0, '>': 5, 'https://': 0, 'lorem ipsum': 0, 'www.': 8, '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': '1684006', 'n_tokens_mistral': 1606, 'n_tokens_neox': 1592, 'n_words': 548}