Merge branch 'master' of http://softwarepublico.gov.br/gitlab/softwarepublico/articles

Melissa Wen
2 parents 464b0aff 55614bd3
Showing 4 changed files with 66 additions and 62 deletions Show diff stats
opensym2017/content/05-requirements.tex
opensym2017/content/06-architecture.tex
opensym2017/content/08-process.tex
opensym2017/content/09-conclusion.tex
@@ -2,28 +2,32 @@
 \label{sec:requirements}
  
 By preparing the SPB Portal evolution, the Brazilian Government has executed
-three steps to collect the requirements. The first step was the collection of proposals using an online tool called Pligg and the open sharing of them on the Internet.
-In this step, the citizens have written and voted on proposals they
-were more interested in. At the end, the Brazilian Government collected about 100 proposals and its initial perspective was to give to the most voted ones the priority of implementation on the new SPB Portal.
+three steps to collect the requirements. The first step was the collection of
+proposals using an online tool called Pligg and the open sharing of them on the
+Internet.  In this step, the citizens have written and voted on proposals they
+were more interested in. At the end, the Brazilian Government collected about
+100 proposals and its initial perspective was to give to the most voted ones
+the priority of implementation on the new SPB Portal.
  
 The second step was two face-to-face meetings that aimed to discuss ideas (not
 necessarily based on the previous collected proposals) to improve the SPB
-Portal and its environments. On the first day, the
-participants were divided in two groups to discuss (i) features and
-technologies as well as (ii) user experience and general ideas regarding the
-SPB Portal. Each group has generated a ``mind map'' to summarize and to correlate its
-ideas.  During the second day, the participants were allocated in three groups
-to discuss features related to (i) the process of software evaluation and
-acceptance in the SPB Portal, (ii) approaches to share the SPB projects,
-and (iii) ways to attract universities and students to collaborate to SPB
-projects.
+Portal and its environments. On the first day, the participants were divided in
+two groups to discuss (i) features and technologies as well as (ii) user
+experience and general ideas regarding the SPB Portal. Each group has generated
+a ``mind map'' to summarize and to correlate its ideas.  During the second day,
+the participants were allocated in three groups to discuss features related to
+(i) the process of software evaluation and acceptance in the SPB Portal, (ii)
+approaches to share the SPB projects, and (iii) ways to attract universities
+and students to collaborate to SPB projects.
  
-The last step was a workshop with some IT representatives of the Federal Government and public organizations and, again, it was focused on collecting new proposals to evolve the SPB Portal.
+The last step was a workshop with some IT representatives of the Federal
+Government and public organizations and, again, it was focused on collecting
+new proposals to evolve the SPB Portal.
  
-After these unconnected three steps, the Brazilian government has generated a list of
-145 requirements. In order to mitigate the lack of focus in the requirement
-list, we have proposed to release an initial version to replace the old SPB
-portal, prioritizing the following features:
+After these unconnected three steps, the Brazilian Government has generated a
+list of 145 requirements. To provide a cohesive initial list of requirements,
+we have proposed to release the first stable version of the new platform to
+replace the old SPB Portal, prioritizing the following features:
  
 \begin{enumerate}
 \item An organized public software catalog;
@@ -35,8 +39,8 @@ portal, prioritizing the following features:
  
 Moreover, the new SPB Portal would only work properly if there was a unique
 authentication to use the provided features. Additionally, a unified interface
-was an important non-functional requirement to provide better user experience on
-the new platform.
+was an important non-functional requirement to provide better user experience
+on the new platform.
  
 Other requirements were in the wishlist such as an integrated search engine and
 a web-based source code static analysis monitor. By analyzing all of these
@@ -150,7 +150,7 @@ network created between them.
  
 \begin{figure*}[hbt]
   \centering
-    \includegraphics[width=.85\linewidth]{figures/arch3.png}
+    \includegraphics[width=.95\linewidth]{figures/arch3.png}
   \caption{Instanciation view of the SPB architecture.}
   \label{fig:architecture2}
 \end{figure*}
@@ -14,7 +14,7 @@ have joined the project to help with the more difficult issues and to transfer
 knowledge to the students. Their main task was to provide solutions for complex
 problems, working as developers. As these professionals are very skillful and
 the project could not fund full-time work for all of them, they worked
-partially on the project. In addition, they lived in either different Brazilian
+part-time on the project. In addition, they lived in either different Brazilian
 states or other countries, which led much of the communication to be online.
  
 In short, our work process was based on open and collaborative software
@@ -99,9 +99,9 @@ between strategical, tactical, and operational views. We had one milestone per
 user history (feature) and one or more issues for addressing each feature. With
 this approach we achieved two important goals: keeping all the management as
 close as possible to the source code and tracking every feature developed
-during the project. Our decision to use the Wiki initially was empirical, but
-later reinforced by a research conducted by Joseph Chao showing the advantage
-of using Wikis~\cite{chao2007student, opensourcestyle}.
+during the project. Initially, our decision to use the Wiki was empirical, but
+later such decision was reinforced by a research conducted by Joseph Chao
+showing the advantage of using Wikis~\cite{chao2007student, opensourcestyle}.
  
 \subsection{High-level Project Management and Reporting}
  
@@ -122,10 +122,10 @@ they stopped resisting.
  
 We defined some level of meeting granularity to avoid generating too much
 overhead to the developers. We had a strategical and a validating meeting with
-the Brazilian Government (the former once in a month and the latter each 15th
-day), a release planning with the entire team (one per month), and finally a
-sprint planning (one each 15th day).  Figure \ref{fig:meeting} is a diagram
-that represents our meeting organization.
+the Brazilian Government (the former once in month and the latter biweekly), a
+release planning with the entire team (one per month), and finally a sprint
+planning (biweekly).  Figure \ref{fig:meeting} is a diagram that represents our
+meeting organization.
  
 In the strategical meeting we usually defined the priorities and new features
 with the Brazilian Government. Normally the professors, the coach of each team,
@@ -141,13 +141,13 @@ After the strategical meeting with Brazilian Government agents, we had a
 planning phase with all teams together. In this part, each team worked together
 to convert the Government wishes into smaller parts which were represented by
 the epics of the release. Each coach was responsible for conducting the
-planning and recording it on the project Wiki. With this epic, each 15th day
-the team have documented their sprint schedule (with small achievements mapped
-to issues).
+planning and recording it on the project Wiki. With this epic, biweekly the
+team have documented their sprint schedule (with small achievements mapped to
+issues).
  
 To keep the Brazilian Government always updated, we invited them to work with
-us to validate the new features in progress. Normally we had a meeting each
-15th day. Basically, this was our work flow. We always kept everything
+us to validate the new features in progress. Normally we had a meeting
+biweekly. Basically, this was our work flow. We always kept everything
 extremely open to the Government (our way of working, and the one often used by
 FLOSS projects) and to the team.
  
@@ -158,9 +158,9 @@ especially Gitlab. Basically, we had:
   \item Project repository: we have one organization with many repositories;
   \item Wiki: each release has one Wiki page with the compilation of the
     strategical meeting;
-  \item Milestones: each milestone was used to register a user history (feature);
+  \item Milestones: each milestone was used to register a user story (feature);
   \item Issues: each sprint planning generated issues, which we associated to
-    the related milestone (feature as user history) and registered on the related Wiki page.
+    the related milestone (feature as user story) and registered on the related Wiki page.
     Finally, each developer assigned the issue to herself.
 \end{enumerate}
  
@@ -170,6 +170,6 @@ code).  It is important to highlight that we converged to this workflow after
 many experiments. For example, we used a tool named Redmine for organizing our
 tasks during some sprints. However, this tool revealed to be inefficient for
 our case since the government agents lost part of the project traceability. We
-realized that centralize all the work in the SPB Portal was the best option for
-our case.
+realized that centralizing all the work in the SPB Portal was the best option
+for our case.
  
@@ -21,7 +21,7 @@ sustainability and maintainability, the aforementioned FLOSS tools were
 integrated with minimum differences from their official versions and the new
 developed features were sent upstream to ensure an alignment between the portal
 systems and their respective official versions. In the integration process, the
-main softwares were identified, specific teams were formed to work with each
+main software were identified, specific teams were formed to work with each
 one of them and each team was composed of students with different levels of
 skills and at least one senior professional.
  
@@ -66,8 +66,8 @@ university.
  
 \subsection{Lessons Learned}
  
-From the answers of our initial open questions, we also can highlighted six
-lessons learned to make easier to share our experience during the development
+From the answers of our initial open questions, we can also highlight six
+lessons learned to better share our experience during the development
 of the new SPB Portal.
  
 \textbf{The participation of experienced professionals is crucial to
@@ -117,11 +117,10 @@ brought strategic discussions to technical/operational meetings that were
 supposed to be about practical technical decisions.
 %
 This produced a highly complex communication and management environment,
-overloading the professors because they were supposed for maintaining the
-Government strategy synchronized with the implementation plans of the
-development team.  This was hard, especially because the aforementioned
-cultural mismatch. Mixing both concerns in the same discussions caused
-confusion on both sides.
+overloading the professors, who were supposed to maintain the Government
+strategy synchronized with the implementation plans of the development team.
+This was hard, especially because the aforementioned cultural mismatch. Mixing
+both concerns in the same discussions caused confusion on both sides.
 %
 From the middle of the project we were able to keep those concerns separated,
 what eased the work of everyone involved.
@@ -134,8 +133,8 @@ guide the development of the new SPB platform. Our team was totally against the
 idea because we already knew that Colab was a very experimental project and its
 adoption could dramatically increase the project complexity. Even though, we
 provided technical reasons to not utilize Colab, the Government was adamant and
-we had to manage this problem. We did massive changes to Colab, and at the end
-of the project we have completely rewritten it to make it stable. It is
+we had to manage this problem. We did massive changes to Colab, and by the end
+of the project we had completely rewritten it to make it stable. It is
 important to notice that the Government compelled us to accept a technical
 decision based only on political interests, without considering all the
 resources that would be spent due to that decision. At the end of the project,
@@ -149,19 +148,20 @@ capable of ignoring technical reasons in favor of political decisions.
 In the process of deploying the SPB platform in the Brazilian Government
 infrastructure we had to interact with the Government technicians. We did
 several workshops, training and a meticulous documentation describing all the
-required procedures to update the platform, however, we realized that they
-constantly avoid the responsibility. After noticing the aforementioned
-situation, we organized a DevOps team that completely automated all the
-deployment procedure. We simplified all the platform deployment to a few steps:
-(i) initial configurations (just ssh configuration) and (ii) the execution of
-simple commands to completely update the platform. By the end of the project,
-we observed that the Government technicians invariably still depended on our
-support to update the platform even with all the automation provided by us. We
-were sadly left with a feeling of uncertainty about the future of the platform
-after the project ended. In hindsight, we realize that the Brazilian Government
-dedicated system analysts and managers to the project, but not operations
-technicians. The later should have been more involved with the process so they
-could at least be comfortable in managing the platform infrastructure.
+required procedures to update the platform, however, we realized that the
+technicians would constantly avoid the responsibility. After noticing the
+aforementioned situation, we organized a DevOps team that completely automated
+all the deployment procedure. We simplified all the platform deployment to a
+few steps: (i) initial configurations (just ssh configuration) and (ii) the
+execution of simple commands to completely update the platform. By the end of
+the project, we observed that the Government technicians invariably still
+depended on our support to update the platform even with all the automation
+provided by us. We were sadly left with a feeling of uncertainty about the
+future of the platform after the project ended. In hindsight, we realize that
+the Brazilian Government dedicated system analysts and managers to the project,
+but not operations technicians. The later should have been more involved with
+the process so they could at least be comfortable in managing the platform
+infrastructure.
  
 \subsection{Final Remarks and Future Work}
  
@@ -201,9 +201,9 @@ the involved stakeholders.
  
 %* 47\% é desenvolvido em PHP.
  
-% foi constatado que aproximadamente 75\% dos softwares \textbf{não} possuem seus códigos-fonte versionados nesta ferramenta. Realizado algumas pesquisas, foi encontrado o código-fonte em outros serviços (Github, Bitbucket).
+% foi constatado que aproximadamente 75\% dos software \textbf{não} possuem seus códigos-fonte versionados nesta ferramenta. Realizado algumas pesquisas, foi encontrado o código-fonte em outros serviços (Github, Bitbucket).
  
-% Foram adicionados 31 softwares do SPB em ambas as ferramentas (Mezuro e Code Climate), desenvolvidos em PHP e Python. Estas adições resultaram na análise descrita nos próximos parágrafos. No Mezuro, dos 31 softwares adicionados, somente 4 obtiveram sucesso na avaliação. No Code Climate, 16 softwares realizaram a \textit{build} da avaliação com sucesso. Nos que falharam, alguns dos erros foram encontrados em três das \textit{engines}: ora em \textit{duplication}, ora na \textit{phpmd}, ora na \textit{eslint}.
+% Foram adicionados 31 software do SPB em ambas as ferramentas (Mezuro e Code Climate), desenvolvidos em PHP e Python. Estas adições resultaram na análise descrita nos próximos parágrafos. No Mezuro, dos 31 software adicionados, somente 4 obtiveram sucesso na avaliação. No Code Climate, 16 software realizaram a \textit{build} da avaliação com sucesso. Nos que falharam, alguns dos erros foram encontrados em três das \textit{engines}: ora em \textit{duplication}, ora na \textit{phpmd}, ora na \textit{eslint}.
  
 % também foram inseridos no Mezuro para avaliação, 5 projetos dos 17 desenvolvidos em Java, com o intuito de ser um contraponto ao Code Climatepor esta não compreender a análise de projetos em Java, C, ou C++. Infelizmente nenhuma das \textit{builds} resultou em resultados concretos.
...	...	@@ -2,28 +2,32 @@
2	2	\label{sec:requirements}
3	3
4	4	By preparing the SPB Portal evolution, the Brazilian Government has executed
5		-three steps to collect the requirements. The first step was the collection of proposals using an online tool called Pligg and the open sharing of them on the Internet.
6		-In this step, the citizens have written and voted on proposals they
7		-were more interested in. At the end, the Brazilian Government collected about 100 proposals and its initial perspective was to give to the most voted ones the priority of implementation on the new SPB Portal.
	5	+three steps to collect the requirements. The first step was the collection of
	6	+proposals using an online tool called Pligg and the open sharing of them on the
	7	+Internet. In this step, the citizens have written and voted on proposals they
	8	+were more interested in. At the end, the Brazilian Government collected about
	9	+100 proposals and its initial perspective was to give to the most voted ones
	10	+the priority of implementation on the new SPB Portal.
8	11
9	12	The second step was two face-to-face meetings that aimed to discuss ideas (not
10	13	necessarily based on the previous collected proposals) to improve the SPB
11		-Portal and its environments. On the first day, the
12		-participants were divided in two groups to discuss (i) features and
13		-technologies as well as (ii) user experience and general ideas regarding the
14		-SPB Portal. Each group has generated a ``mind map'' to summarize and to correlate its
15		-ideas. During the second day, the participants were allocated in three groups
16		-to discuss features related to (i) the process of software evaluation and
17		-acceptance in the SPB Portal, (ii) approaches to share the SPB projects,
18		-and (iii) ways to attract universities and students to collaborate to SPB
19		-projects.
	14	+Portal and its environments. On the first day, the participants were divided in
	15	+two groups to discuss (i) features and technologies as well as (ii) user
	16	+experience and general ideas regarding the SPB Portal. Each group has generated
	17	+a ``mind map'' to summarize and to correlate its ideas. During the second day,
	18	+the participants were allocated in three groups to discuss features related to
	19	+(i) the process of software evaluation and acceptance in the SPB Portal, (ii)
	20	+approaches to share the SPB projects, and (iii) ways to attract universities
	21	+and students to collaborate to SPB projects.
20	22
21		-The last step was a workshop with some IT representatives of the Federal Government and public organizations and, again, it was focused on collecting new proposals to evolve the SPB Portal.
	23	+The last step was a workshop with some IT representatives of the Federal
	24	+Government and public organizations and, again, it was focused on collecting
	25	+new proposals to evolve the SPB Portal.
22	26
23		-After these unconnected three steps, the Brazilian government has generated a list of
24		-145 requirements. In order to mitigate the lack of focus in the requirement
25		-list, we have proposed to release an initial version to replace the old SPB
26		-portal, prioritizing the following features:
	27	+After these unconnected three steps, the Brazilian Government has generated a
	28	+list of 145 requirements. To provide a cohesive initial list of requirements,
	29	+we have proposed to release the first stable version of the new platform to
	30	+replace the old SPB Portal, prioritizing the following features:
27	31
28	32	\begin{enumerate}
29	33	\item An organized public software catalog;
...	...	@@ -35,8 +39,8 @@ portal, prioritizing the following features:
35	39
36	40	Moreover, the new SPB Portal would only work properly if there was a unique
37	41	authentication to use the provided features. Additionally, a unified interface
38		-was an important non-functional requirement to provide better user experience on
39		-the new platform.
	42	+was an important non-functional requirement to provide better user experience
	43	+on the new platform.
40	44
41	45	Other requirements were in the wishlist such as an integrated search engine and
42	46	a web-based source code static analysis monitor. By analyzing all of these
...	...
...	...	@@ -150,7 +150,7 @@ network created between them.
150	150
151	151	\begin{figure*}[hbt]
152	152	\centering
153		- \includegraphics[width=.85\linewidth]{figures/arch3.png}
	153	+ \includegraphics[width=.95\linewidth]{figures/arch3.png}
154	154	\caption{Instanciation view of the SPB architecture.}
155	155	\label{fig:architecture2}
156	156	\end{figure*}
...	...
...	...	@@ -14,7 +14,7 @@ have joined the project to help with the more difficult issues and to transfer
14	14	knowledge to the students. Their main task was to provide solutions for complex
15	15	problems, working as developers. As these professionals are very skillful and
16	16	the project could not fund full-time work for all of them, they worked
17		-partially on the project. In addition, they lived in either different Brazilian
	17	+part-time on the project. In addition, they lived in either different Brazilian
18	18	states or other countries, which led much of the communication to be online.
19	19
20	20	In short, our work process was based on open and collaborative software
...	...	@@ -99,9 +99,9 @@ between strategical, tactical, and operational views. We had one milestone per
99	99	user history (feature) and one or more issues for addressing each feature. With
100	100	this approach we achieved two important goals: keeping all the management as
101	101	close as possible to the source code and tracking every feature developed
102		-during the project. Our decision to use the Wiki initially was empirical, but
103		-later reinforced by a research conducted by Joseph Chao showing the advantage
104		-of using Wikis~\cite{chao2007student, opensourcestyle}.
	102	+during the project. Initially, our decision to use the Wiki was empirical, but
	103	+later such decision was reinforced by a research conducted by Joseph Chao
	104	+showing the advantage of using Wikis~\cite{chao2007student, opensourcestyle}.
105	105
106	106	\subsection{High-level Project Management and Reporting}
107	107
...	...	@@ -122,10 +122,10 @@ they stopped resisting.
122	122
123	123	We defined some level of meeting granularity to avoid generating too much
124	124	overhead to the developers. We had a strategical and a validating meeting with
125		-the Brazilian Government (the former once in a month and the latter each 15th
126		-day), a release planning with the entire team (one per month), and finally a
127		-sprint planning (one each 15th day). Figure \ref{fig:meeting} is a diagram
128		-that represents our meeting organization.
	125	+the Brazilian Government (the former once in month and the latter biweekly), a
	126	+release planning with the entire team (one per month), and finally a sprint
	127	+planning (biweekly). Figure \ref{fig:meeting} is a diagram that represents our
	128	+meeting organization.
129	129
130	130	In the strategical meeting we usually defined the priorities and new features
131	131	with the Brazilian Government. Normally the professors, the coach of each team,
...	...	@@ -141,13 +141,13 @@ After the strategical meeting with Brazilian Government agents, we had a
141	141	planning phase with all teams together. In this part, each team worked together
142	142	to convert the Government wishes into smaller parts which were represented by
143	143	the epics of the release. Each coach was responsible for conducting the
144		-planning and recording it on the project Wiki. With this epic, each 15th day
145		-the team have documented their sprint schedule (with small achievements mapped
146		-to issues).
	144	+planning and recording it on the project Wiki. With this epic, biweekly the
	145	+team have documented their sprint schedule (with small achievements mapped to
	146	+issues).
147	147
148	148	To keep the Brazilian Government always updated, we invited them to work with
149		-us to validate the new features in progress. Normally we had a meeting each
150		-15th day. Basically, this was our work flow. We always kept everything
	149	+us to validate the new features in progress. Normally we had a meeting
	150	+biweekly. Basically, this was our work flow. We always kept everything
151	151	extremely open to the Government (our way of working, and the one often used by
152	152	FLOSS projects) and to the team.
153	153
...	...	@@ -158,9 +158,9 @@ especially Gitlab. Basically, we had:
158	158	\item Project repository: we have one organization with many repositories;
159	159	\item Wiki: each release has one Wiki page with the compilation of the
160	160	strategical meeting;
161		- \item Milestones: each milestone was used to register a user history (feature);
	161	+ \item Milestones: each milestone was used to register a user story (feature);
162	162	\item Issues: each sprint planning generated issues, which we associated to
163		- the related milestone (feature as user history) and registered on the related Wiki page.
	163	+ the related milestone (feature as user story) and registered on the related Wiki page.
164	164	Finally, each developer assigned the issue to herself.
165	165	\end{enumerate}
166	166
...	...	@@ -170,6 +170,6 @@ code). It is important to highlight that we converged to this workflow after
170	170	many experiments. For example, we used a tool named Redmine for organizing our
171	171	tasks during some sprints. However, this tool revealed to be inefficient for
172	172	our case since the government agents lost part of the project traceability. We
173		-realized that centralize all the work in the SPB Portal was the best option for
174		-our case.
	173	+realized that centralizing all the work in the SPB Portal was the best option
	174	+for our case.
175	175
...	...
...	...	@@ -21,7 +21,7 @@ sustainability and maintainability, the aforementioned FLOSS tools were
21	21	integrated with minimum differences from their official versions and the new
22	22	developed features were sent upstream to ensure an alignment between the portal
23	23	systems and their respective official versions. In the integration process, the
24		-main softwares were identified, specific teams were formed to work with each
	24	+main software were identified, specific teams were formed to work with each
25	25	one of them and each team was composed of students with different levels of
26	26	skills and at least one senior professional.
27	27
...	...	@@ -66,8 +66,8 @@ university.
66	66
67	67	\subsection{Lessons Learned}
68	68
69		-From the answers of our initial open questions, we also can highlighted six
70		-lessons learned to make easier to share our experience during the development
	69	+From the answers of our initial open questions, we can also highlight six
	70	+lessons learned to better share our experience during the development
71	71	of the new SPB Portal.
72	72
73	73	\textbf{The participation of experienced professionals is crucial to
...	...	@@ -117,11 +117,10 @@ brought strategic discussions to technical/operational meetings that were
117	117	supposed to be about practical technical decisions.
118	118	%
119	119	This produced a highly complex communication and management environment,
120		-overloading the professors because they were supposed for maintaining the
121		-Government strategy synchronized with the implementation plans of the
122		-development team. This was hard, especially because the aforementioned
123		-cultural mismatch. Mixing both concerns in the same discussions caused
124		-confusion on both sides.
	120	+overloading the professors, who were supposed to maintain the Government
	121	+strategy synchronized with the implementation plans of the development team.
	122	+This was hard, especially because the aforementioned cultural mismatch. Mixing
	123	+both concerns in the same discussions caused confusion on both sides.
125	124	%
126	125	From the middle of the project we were able to keep those concerns separated,
127	126	what eased the work of everyone involved.
...	...	@@ -134,8 +133,8 @@ guide the development of the new SPB platform. Our team was totally against the
134	133	idea because we already knew that Colab was a very experimental project and its
135	134	adoption could dramatically increase the project complexity. Even though, we
136	135	provided technical reasons to not utilize Colab, the Government was adamant and
137		-we had to manage this problem. We did massive changes to Colab, and at the end
138		-of the project we have completely rewritten it to make it stable. It is
	136	+we had to manage this problem. We did massive changes to Colab, and by the end
	137	+of the project we had completely rewritten it to make it stable. It is
139	138	important to notice that the Government compelled us to accept a technical
140	139	decision based only on political interests, without considering all the
141	140	resources that would be spent due to that decision. At the end of the project,
...	...	@@ -149,19 +148,20 @@ capable of ignoring technical reasons in favor of political decisions.
149	148	In the process of deploying the SPB platform in the Brazilian Government
150	149	infrastructure we had to interact with the Government technicians. We did
151	150	several workshops, training and a meticulous documentation describing all the
152		-required procedures to update the platform, however, we realized that they
153		-constantly avoid the responsibility. After noticing the aforementioned
154		-situation, we organized a DevOps team that completely automated all the
155		-deployment procedure. We simplified all the platform deployment to a few steps:
156		-(i) initial configurations (just ssh configuration) and (ii) the execution of
157		-simple commands to completely update the platform. By the end of the project,
158		-we observed that the Government technicians invariably still depended on our
159		-support to update the platform even with all the automation provided by us. We
160		-were sadly left with a feeling of uncertainty about the future of the platform
161		-after the project ended. In hindsight, we realize that the Brazilian Government
162		-dedicated system analysts and managers to the project, but not operations
163		-technicians. The later should have been more involved with the process so they
164		-could at least be comfortable in managing the platform infrastructure.
	151	+required procedures to update the platform, however, we realized that the
	152	+technicians would constantly avoid the responsibility. After noticing the
	153	+aforementioned situation, we organized a DevOps team that completely automated
	154	+all the deployment procedure. We simplified all the platform deployment to a
	155	+few steps: (i) initial configurations (just ssh configuration) and (ii) the
	156	+execution of simple commands to completely update the platform. By the end of
	157	+the project, we observed that the Government technicians invariably still
	158	+depended on our support to update the platform even with all the automation
	159	+provided by us. We were sadly left with a feeling of uncertainty about the
	160	+future of the platform after the project ended. In hindsight, we realize that
	161	+the Brazilian Government dedicated system analysts and managers to the project,
	162	+but not operations technicians. The later should have been more involved with
	163	+the process so they could at least be comfortable in managing the platform
	164	+infrastructure.
165	165
166	166	\subsection{Final Remarks and Future Work}
167	167
...	...	@@ -201,9 +201,9 @@ the involved stakeholders.
201	201
202	202	%* 47\% é desenvolvido em PHP.
203	203
204		-% foi constatado que aproximadamente 75\% dos softwares \textbf{não} possuem seus códigos-fonte versionados nesta ferramenta. Realizado algumas pesquisas, foi encontrado o código-fonte em outros serviços (Github, Bitbucket).
	204	+% foi constatado que aproximadamente 75\% dos software \textbf{não} possuem seus códigos-fonte versionados nesta ferramenta. Realizado algumas pesquisas, foi encontrado o código-fonte em outros serviços (Github, Bitbucket).
205	205
206		-% Foram adicionados 31 softwares do SPB em ambas as ferramentas (Mezuro e Code Climate), desenvolvidos em PHP e Python. Estas adições resultaram na análise descrita nos próximos parágrafos. No Mezuro, dos 31 softwares adicionados, somente 4 obtiveram sucesso na avaliação. No Code Climate, 16 softwares realizaram a \textit{build} da avaliação com sucesso. Nos que falharam, alguns dos erros foram encontrados em três das \textit{engines}: ora em \textit{duplication}, ora na \textit{phpmd}, ora na \textit{eslint}.
	206	+% Foram adicionados 31 software do SPB em ambas as ferramentas (Mezuro e Code Climate), desenvolvidos em PHP e Python. Estas adições resultaram na análise descrita nos próximos parágrafos. No Mezuro, dos 31 software adicionados, somente 4 obtiveram sucesso na avaliação. No Code Climate, 16 software realizaram a \textit{build} da avaliação com sucesso. Nos que falharam, alguns dos erros foram encontrados em três das \textit{engines}: ora em \textit{duplication}, ora na \textit{phpmd}, ora na \textit{eslint}.
207	207
208	208	% também foram inseridos no Mezuro para avaliação, 5 projetos dos 17 desenvolvidos em Java, com o intuito de ser um contraponto ao Code Climatepor esta não compreender a análise de projetos em Java, C, ou C++. Infelizmente nenhuma das \textit{builds} resultou em resultados concretos.
209	209
...	...