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.
	@@ -150,7 +150,7 @@ network created between them.		@@ -150,7 +150,7 @@ network created between them.
150		150
151	\begin{figure*}[hbt]	151	\begin{figure*}[hbt]
152	\centering	152	\centering
153	- \includegraphics[width=.85\linewidth]{figures/arch3.png}	153	+ \includegraphics[width=.95\linewidth]{figures/arch3.png}
154	\caption{Instanciation view of the SPB architecture.}	154	\caption{Instanciation view of the SPB architecture.}
155	\label{fig:architecture2}	155	\label{fig:architecture2}
156	\end{figure*}	156	\end{figure*}