[opensym] Athos' conclusion review and other improvements

Paulo Meireles
1 parent e09dc27b
Showing 3 changed files with 49 additions and 45 deletions Show diff stats
opensym2017/content/05-requirements.tex
opensym2017/content/06-architecture.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
@@ -159,7 +159,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*}
@@ -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
...	...
...	...	@@ -159,7 +159,7 @@ network created between them.
159	159
160	160	\begin{figure*}[hbt]
161	161	\centering
162		- \includegraphics[width=.85\linewidth]{figures/arch3.png}
	162	+ \includegraphics[width=.95\linewidth]{figures/arch3.png}
163	163	\caption{Instanciation view of the SPB architecture.}
164	164	\label{fig:architecture2}
165	165	\end{figure*}
...	...
...	...	@@ -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
...	...