1
Download as
Browse Code »

Commit fda75672f921faf159e59c835bdd5a2a6b15d3be

Authored by Rodrigo Siqueira de Melo
1 parent a571497f

Review Siqueira: Meus TODOS

Showing 9 changed files with 145 additions and 73 deletions   Show diff stats
opensym2017/content/01-introduction.tex
  Diff comments   View file @fda7567
... ... @@ -10,9 +10,9 @@ Government released a portal named Brazilian Public Software
10 10 goal of sharing FOSS projects developed by, or for, the Brazilian
11 11 Government. Additionally, the Brazilian legal instrument on software
12 12 contracting (known as IN 04/2012) mandates that public agents must give
13   -priority to solutions available in the SPB Portal. In short, the
  13 +priority to solutions available on the SPB Portal. In short, the
14 14 acquisition of a proprietary solution must be explicitly justified by
15   -demonstrating that there is no suitable alternative in the SPB Portal.
  15 +demonstrating that there is no suitable alternative on the SPB Portal.
16 16 In 2013, the Brazilian Federal Court issued a ruling document
17 17 (\textit{Acórdão 2314/2013}) about an audit survey regarding the use of
18 18 agile methodologies in software development contracts with the public
... ... @@ -28,13 +28,15 @@ unjustifiable expending of taxpayers' money.
28 28  
29 29 % TODO: ^ references
30 30  
31   -Since 2009, the SPB Portal was having several technical issues. The
32   -original codebase was not being developed anymore, and there was a large
33   -amount of technical debt to overcome. The system was a modified version
34   -of an existing FOSS platform called
35   -OpenACS\footnote{\url{http://openacs.org}}, and the old SPB portal was
36   -not being updated anymore against the official OpenACS releases. In this
37   -scenario, the portal maintenance has become increasingly difficult.
  31 +
  32 +Since 2009, the SPB Portal was having several technical issues. The original
  33 +codebase was not being developed anymore, also, there was a large amount of
  34 +knowingly non-optimal or wrong design decisions to overcome (in other words,
  35 +technical debt \cite{refactoring}). The system was a modified version of an
  36 +existing FOSS platform called OpenACS \footnote{\url{http://openacs.org}}, and
  37 +the old SPB portal was not being updated anymore against the official OpenACS
  38 +releases. In this scenario, the portal maintenance has become increasingly
  39 +difficult.
38 40  
39 41 After some events and meetings to collect requirements from the federal
40 42 government and from the society, a new platform for the SPB Portal was
... ...
opensym2017/content/02-spb.tex
  Diff comments   View file @fda7567
... ... @@ -50,11 +50,11 @@ their software available on the SPB platform.
50 50 The concept of Brazilian Public Software goes beyond FOSS. In addition
51 51 to being licensed under a FOSS license, a SPB needs to have explicit
52 52 guarantees that it is a public good, and that project must be available
53   -in the SPB portal. Being a true public good assumes requirements that
  53 +on the SPB portal. Being a true public good assumes requirements that
54 54 can not be met solely by means of FOSS licensing. For example, there
55 55 must be a relaxed trademark usage policy by the original vendor that
56 56 does not stop eventual competitors from advertising services for that
57   -same software. Inclusion in the SPB Portal also has extra requirements,
  57 +same software. Inclusion on the SPB Portal also has extra requirements,
58 58 such as having a public version control system, installation manual, and
59 59 hardware requirements specification.
60 60  
... ...
opensym2017/content/03-requirements.tex
  Diff comments   View file @fda7567
... ... @@ -18,19 +18,19 @@ After these 3 rounds discussing the new SPB platform, the Brazilian government
18 18 listed about 145 requirements and developed a ``mind
19 19 map''\footnote{\url{https://softwarepublico.gov.br/social/spb/gallery/mapaconceitual.png}}
20 20 to guide the SPB portal evolution. In this scenario, the 10 most voted
21   -requirements were, for example:
  21 +requirements were:
22 22  
23 23 \begin{enumerate}
24 24  
25   -\item Source code repository with public access.
26   -\item Visit community pages without login.
27   -\item Distributed version control system.
28   -\item Scores of users and developers collaboration.
29   -\item Search software by features.
30   -\item Integration with social networks.
31   -\item Repository for future ideas and requirements.
32   -\item Friendly URL to access a public software community page.
33   -\item User feedback about a public software.
  25 +\item Source code repository with public access;
  26 +\item Visit community pages without login;
  27 +\item Distributed version control system;
  28 +\item Scores of users and developers collaboration;
  29 +\item Search software by features;
  30 +\item Integration with social networks;
  31 +\item Repository for future ideas and requirements;
  32 +\item Friendly URL to access a public software community page;
  33 +\item User feedback about a public software;
34 34 \item Report of the experience about the use of a public software.
35 35  
36 36 \end{enumerate}
... ... @@ -38,7 +38,7 @@ requirements were, for example:
38 38 \begin{figure}[hbt]
39 39 \centering
40 40 \includegraphics[width=\linewidth]{figures/technological-requirements.png}
41   - \caption{Technological requirements overview.}
  41 + \caption{Technological requirements.}
42 42 \label{fig:requirements}
43 43 \end{figure}
44 44  
... ... @@ -57,10 +57,10 @@ features such as:
57 57  
58 58 \begin{enumerate}
59 59  
60   -\item An organized public software catalog.
61   -\item Social network environment (profiles for users, software pages, and community pages).
62   -\item Content Management Systems (CMS) features.
63   -\item Web-based Git repository manager with wiki and issue tracking features.
  60 +\item An organized public software catalog;
  61 +\item Social network environment (profiles for users, software pages, and community pages);
  62 +\item Content Management Systems (CMS) features;
  63 +\item Web-based Git repository manager with wiki and issue tracking features;
64 64 \item Mailing lists and discussion forums.
65 65  
66 66 \end{enumerate}
... ... @@ -68,7 +68,7 @@ features such as:
68 68 Other requirements were also planned during the conception phase of the
69 69 SPB evolution project, such as an integrated search engine and a
70 70 web-based source code static analysis monitor. By analyzing all of these
71   -requirements, we proposed the technological requirements overview
  71 +requirements, we proposed the technological requirements
72 72 illustrated in Figure \ref{fig:requirements} to guide the development of
73 73 the new SPB platform. In other words, we have designed the SPB evolution
74 74 project based on existing FOSS tools. However, the integration of
... ...
opensym2017/content/04-architecture.tex
  Diff comments   View file @fda7567
... ... @@ -48,10 +48,10 @@ the change between applications. For that, Colab provides facilities
48 48 for:
49 49  
50 50 \begin{itemize}
51   - \item Centralized authentication
52   - \item Visual consistency
53   - \item Relaying of events between applications
54   - \item Integrated search engine
  51 + \item Centralized authentication;
  52 + \item Visual consistency;
  53 + \item Relaying of events between applications;
  54 + \item Integrated search engine.
55 55 \end{itemize}
56 56  
57 57 Colab implements this integration by working as a reverse proxy for the
... ... @@ -86,14 +86,9 @@ representation of that user account.
86 86 Colab also provides an integrated search engine, which can be configured
87 87 to specify exactly what data needs to be indexed for each of the
88 88 applications, and how to direct the user to that piece of information on
89   -the specific application.
90   -
91   -Initially, Colab had support for a small set of applications (Trac, GNU
92   -Mailman, and Apache Lucene) and support for them was hard-coded. Our
93   -team evolved Colab so that it can now receive plugins that add support
94   -new applications without the need of changes to the Colab core. We also
95   -developed plugins to be used in the SPB platform: Noosfero, GitLab, and
96   -Mezuro.
  89 +the specific application. Finally, our team evolved Colab so that it can now
  90 +receive plugins that add support new applications without the need of changes
  91 +to the Colab core.
97 92  
98 93 \subsection{Noosfero}
99 94  
... ... @@ -119,9 +114,9 @@ tracking.
119 114  
120 115 \subsection{Mezuro}
121 116  
122   -Mezuro\footnote{\url{http://mezuro.org/}} is a platform to collect source code
123   -metrics to monitor the internal quality of software written in C, C++,
124   -Java, Python, Ruby, and PHP.
  117 +Mezuro\footnote{\url{http://mezuro.org/}} \cite{mezuro_oss} is a platform to
  118 +collect source code metrics to monitor the internal quality of software written
  119 +in C, C++, Java, Python, Ruby, and PHP.
125 120  
126 121 In general, source code metrics tools also do not present a friendly way
127 122 to interpret its results and, even more, do not follow a standardization
... ... @@ -150,7 +145,7 @@ directing requests to one of the integrated applications. It
150 145 post-processes responses from the applications to apply a consistent
151 146 visual appearance, manages authentication, and provides a unified search
152 147 functionality: instead of using the redundant restricted search
153   -functionality of each application, a search in the SPB portal might
  148 +functionality of each application, a search on the SPB portal might
154 149 return content from any of the applications, be it web pages, mailing
155 150 list posts, or source code.
156 151  
... ...
opensym2017/content/05-features.tex
  Diff comments   View file @fda7567
... ... @@ -48,17 +48,19 @@ such as filters (by type of software or category), sorting and score.
48 48  
49 49 In order to expand the searching scope and cover more types of content, the SPB team
50 50 developed the global search tool. This tool unifies search mechanisms
51   -provided by the different collaborative software used in the SPB protal. Any user can
  51 +provided by the different collaborative software used on the SPB protal. Any user can
52 52 find a public content in the context of social networking, mailing list and
53 53 software development.
54 54  
55 55 \subsection{Software development tools}
56 56  
57   -The new SPB also provides
58   -tools to encourage developers to keep source code and its
59   -development activity within the platform. Any created software has, by default, a
60   -an associated git repository with wiki pages and issue tracking. These tools are
61   -supplied by the integration of Gitlab into the platform.
  57 +Usually, Collaborative Development Environments (CDE) demand a version control
  58 +system, trackers, build tools, knowledge centers, and communication tools
  59 +\cite{collaboration_tools}. The new SPB provides tools to encourage developers
  60 +to keep source code and its development activity within the platform as a CDE.
  61 +Every software in the platform has an associated git repository with wiki pages
  62 +and issue tracking. These tools are supplied by the integration of Gitlab into
  63 +the platform.
62 64  
63 65 Developers can also evaluate the software source code to measure software
64 66 quality. With Mezuro, they can schedule the analysis of the source-code and follow its
... ...
opensym2017/content/07-process.tex
  Diff comments   View file @fda7567
... ... @@ -31,7 +31,7 @@ Development, and Management (MP is the Brazilian acronym). All the project
31 31 decisions, validations, and scope definitions were made by them. In this way we
32 32 developed software product incrementally, with releases aligned to business
33 33 strategic objectives. As one can see, the project had many different
34   -kinds of stakeholders that had to be organized and synchronized.
  34 +sort of stakeholders that had to be organized and synchronized.
35 35  
36 36 \subsection{Team organization}
37 37  
... ... @@ -45,10 +45,10 @@ basic rules which guided the project organization:
45 45  
46 46 \begin{enumerate}
47 47 \item Classes have high priority for undergraduate students;
48   - \item Work in pairs whenever possible (locally or remotely).
  48 + \item Work in pairs whenever possible (locally or remotely);
49 49 \item There must be one morning or afternoon per week when
50 50 \emph{everyone} should be together physically in the laboratory
51   - (except of course the remote team members).
  51 + (except of course the remote team members);
52 52 \item Every 3 to 4 months, the senior developers would fly in and work
53 53 alongside the students for a few days.
54 54 \end{enumerate}
... ... @@ -100,13 +100,17 @@ seeing the screen in real time). For questions and fast discussion, we used
100 100 IRC. For general notification, we used the mailing lists.
101 101  
102 102 For managing the project we used the SPB Portal itself; first to validate it by
103   -ourselves, and also because it had all the required tools. We basically created
104   -one wiki page per release in the SPB Gitlab instance with a mapping between
105   -strategical, tactical, and operational views. In a practical point of view, one
106   -milestone per user history (feature), and one or more issues for addressing
107   -each feature. With this approach we achieved two important goals: keeping all
108   -the management as close possible to to the source code, and tracking every
109   -feature developed during the project.
  103 +ourselves; second, there is scientific evidence that tools similar to GitHub
  104 +\cite{opensourcestyle} (Gitlab in our case) can support Collaborative
  105 +Development Practices. We created one wiki page per release in the SPB (Gitlab)
  106 +with a mapping between strategical, tactical, and operational views. In a
  107 +practical point of view, one milestone per user history (feature), and one or
  108 +more issues for addressing each feature. With this approach, we achieved two
  109 +important goals: keeping all the management as close possible to the source
  110 +code and tracking every feature developed during the project. Our decision to
  111 +use Wiki initially was empirical, but later reinforced by a research conducted
  112 +by Joseph Chao showing the advantage of using Wikis \cite{chao2007student,
  113 +opensourcestyle}.
110 114  
111 115 \subsection{High-level project management and reporting}
112 116  
... ... @@ -128,7 +132,7 @@ diagram that represents our meeting organization.
128 132 \begin{figure}[hbt]
129 133 \centering
130 134 \includegraphics[width=\linewidth]{figures/meeting_flows.png}
131   - \caption{Meetings cycles}
  135 + \caption{Meetings cycles.}
132 136 \label{fig:meeting}
133 137 \end{figure}
134 138  
... ... @@ -160,15 +164,19 @@ To keep the track of all of those things we used the SPB itself,
160 164 especially Gitlab. Basically, we had:
161 165  
162 166 \begin{enumerate}
163   - \item Project repository: We have one organization with many repositories
164   - \item Milestones: Each milestone was used to register a release
  167 + \item Project repository: We have one organization with many repositories;
  168 + \item Milestones: Each milestone was used to register a release;
165 169 \item Wiki: Each release has one page on wiki with the compilation of
166   - strategical meeting
  170 + strategical meeting;
167 171 \item Issues: Each sprint planning generated issues, which we associated to
168 172 the specific milestone and updated the wiki with the issue number related
169 173 with them. Finally each developer assigned the issue to itself.
170 174 \end{enumerate}
171 175  
172   -Notice that this workflow gave us and the Brazilian government agents
173   -full traceability from a high level view of each feature to the lowest
174   -level (code).
  176 +Notice that this workflow gave us and the Brazilian government agents full
  177 +traceability from a high level view of each feature to the lowest level (code).
  178 +It is important to highlight that we converge to this workflow after many
  179 +experiments. For example, we used a tool named Redmine for organizing our tasks
  180 +during the sprints, however, this tool revealed inefficient for our case since
  181 +the government agents lost part of the project traceability. We realized that
  182 +centralize all the work in the SPB portal is the best option for our case.
... ...
opensym2017/content/09-lessons.tex
  Diff comments   View file @fda7567
... ... @@ -12,7 +12,7 @@ UnB.
12 12 %
13 13 They interacted with professionals that had diverse expertises, and were
14 14 able to participate in all levels of the software development process.
15   -This contribted to a great learning opportunity, and for a majority of
  15 +This contributed to a great learning opportunity, and for a majority of
16 16 them this was their first professional experience.
17 17  
18 18 \textbf{The participation of experienced professionals is crucial to
... ...
opensym2017/content/10-conclusion.tex
  Diff comments   View file @fda7567
... ... @@ -3,12 +3,12 @@
3 3  
4 4 In this paper we present and discuss issues experienced during a government-
5 5 funded project, in partnership with University of Brasilia and University of
6   -São Paulo, to evolve the Brazilian Public Software portal.
  6 +São Paulo, to evolve the Brazilian Public Software portal.
7 7  
8 8 The contributions of this paper are twofold. First, we present how was
9   -developed an unprecedent platform, delivered to Brazilian government. This
10   -platform - developed by an heterogenous team of professors, master and
11   -undergraduate students, IT professionals and governmental managers - provides
  9 +developed an unprecedented platform, delivered to Brazilian government. This
  10 +platform - developed by an heterogeneous team of professors, master and
  11 +undergraduate students, IT professionals and governmental managers - provides
12 12 several modern features from the integration of more than 10 FLOSS systems.
13 13  
14 14 Second, the 30 months project which developed this platform, results in an
... ... @@ -21,6 +21,16 @@ embraced opportunities in public and private sectos, within national borders
21 21 and abroad. Some others went further and started their own companies.
22 22  
23 23 We also shown that, with some adaptations/"translation processes", was possible
24   -to conciliate agile methodologies and FOSS practices to develop software to
25   -governmental organizations with functional hierarchical structures that use
  24 +to conciliate agile methodologies and FOSS practices to develop software to
  25 +governmental organizations with functional hierarchical structures that use
26 26 traditional development paradigm.
  27 +
  28 +The SPB project represented an opportunity for us to apply many of our belief
  29 +related to FLOSS and Agile Method. We put an enormous effort to create a
  30 +friendly environment for everybody involved in the project, and for showing to
  31 +the government another way to interact with FLOSS community and university. Our
  32 +work style was extremely open and we tried to be transparent for the entire
  33 +society. As a consequence, we believe that we still need to investigate more
  34 +all the data produced by the project and the impacts on the students. We
  35 +expected to conduct a post-mortem analyze in the project since we have many
  36 +open data and we applied many concepts that still extra validation.
... ...
opensym2017/spb.bib
  Diff comments   View file @fda7567
... ... @@ -257,3 +257,58 @@
257 257 note = {In: 2020 FLOSS Roadmap},
258 258 year = {2008}
259 259 }
  260 +
  261 +@book{refactoring,
  262 + title={Refactoring for software design smells: Managing technical debt},
  263 + author={Suryanarayana, Girish and Samarthyam, Ganesh and Sharma, Tushar},
  264 + year={2014},
  265 + publisher={Morgan Kaufmann}
  266 +}
  267 +
  268 +@article{mezuro_oss,
  269 + title={Mezuro: Understanding source code metrics},
  270 + author={Guedes and Meirelles and Manzo and Camarinha},
  271 + journal={International Conference on Open Source Systems},
  272 + volume={01},
  273 + year={2017},
  274 + publisher={OSS}
  275 +}
  276 +
  277 +@article{collaboration_tools,
  278 + title={Collaboration tools for global software engineering},
  279 + author={Lanubile, Filippo and Ebert, Christof and Prikladnicki, Rafael and Vizca{\'\i}no, Aurora},
  280 + journal={IEEE software},
  281 + volume={27},
  282 + number={2},
  283 + year={2010},
  284 + publisher={IEEE}
  285 +}
  286 +
  287 +@inproceedings{chao2007student,
1
  288 + title={Student project collaboration using Wikis},
  289 + author={Chao, Joseph},
  290 + booktitle={Software Engineering Education \& Training, 2007. CSEET'07. 20th Conference on},
  291 + pages={255--261},
  292 + year={2007},
  293 + organization={IEEE}
  294 +}
  295 +
  296 +@article{parker2007wiki,
  297 + title={Wiki as a teaching tool},
  298 + author={Parker, Kevin and Chao, Joseph},
  299 + journal={Interdisciplinary Journal of e-learning and Learning Objects},
  300 + volume={3},
  301 + number={1},
  302 + pages={57--72},
  303 + year={2007},
  304 + publisher={Informing Science Institute}
  305 +}
  306 +
  307 +@inproceedings{opensourcestyle,
  308 + title={Open source-style collaborative development practices in commercial projects using github},
  309 + author={Kalliamvakou, Eirini and Damian, Daniela and Blincoe, Kelly and Singer, Leif and German, Daniel M},
  310 + booktitle={Proceedings of the 37th International Conference on Software Engineering-Volume 1},
  311 + pages={574--585},
  312 + year={2015},
  313 + organization={IEEE Press}
  314 +}
... ...