Commit e174606afaa5253d1a1df4374bfb3db5c711e7e4
1 parent
a62adb2e
Exists in
master
Siqueiras contribution
Showing
9 changed files
with
119 additions
and
62 deletions
Show diff stats
opensym2017/content/01-introduction.tex
... | ... | @@ -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 | ... | ... |
opensym2017/content/02-spb.tex
... | ... | @@ -50,7 +50,7 @@ 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 | ... | ... |
opensym2017/content/04-requirements.tex
... | ... | @@ -18,27 +18,27 @@ 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. | |
34 | -\item Report of the experience about the use of 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 | +\item Report of the experience about the use of a public software; | |
35 | 35 | |
36 | 36 | \end{enumerate} |
37 | 37 | |
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,18 +57,18 @@ 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. | |
64 | -\item Mailing lists and discussion forums. | |
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 | +\item Mailing lists and discussion forums; | |
65 | 65 | |
66 | 66 | \end{enumerate} |
67 | 67 | |
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/05-architecture.tex
... | ... | @@ -50,17 +50,17 @@ for: |
50 | 50 | \begin{itemize} |
51 | 51 | \item \textit{Centralized authentication}: Users are automatically |
52 | 52 | identified for each application without having to enter login |
53 | -credentials on each of them. | |
53 | +credentials on each of them; | |
54 | 54 | \item \textit{Visual consistency}: Colab is able to change the HTML |
55 | 55 | code produced by the integrated applications, such as defining default |
56 | 56 | template or reusing common HTML pages, in order to provide a unified |
57 | -interface. | |
57 | +interface; | |
58 | 58 | \item \textit{Relaying of events between applications}: The |
59 | 59 | integrated applications or Colab itself are able to trigger an action |
60 | -on another application. | |
60 | +on another application; | |
61 | 61 | \item \textit{Integrated search engine}: It is possible to set up |
62 | 62 | exactly which data needs to be indexed from each application and how |
63 | -users are directed to this information on correspondent application. | |
63 | +users are directed to this information on correspondent application; | |
64 | 64 | \end{itemize} |
65 | 65 | |
66 | 66 | Colab implements this integration by working as a reverse proxy for the |
... | ... | @@ -70,9 +70,7 @@ Colab before reaching them. |
70 | 70 | Initially, Colab had support for a small set of applications (Trac, GNU |
71 | 71 | Mailman, and Apache Lucene) and support for them was hard-coded. Our |
72 | 72 | team evolved Colab so that it can now receive plugins that add support |
73 | -new applications without the need of changes to the Colab core. We also | |
74 | -developed plugins to be used in the SPB platform: Noosfero, GitLab, and | |
75 | -Mezuro. | |
73 | +new applications without the need of changes to the Colab core. | |
76 | 74 | |
77 | 75 | \subsection{Noosfero} |
78 | 76 | |
... | ... | @@ -98,9 +96,9 @@ tracking. |
98 | 96 | |
99 | 97 | \subsection{Mezuro} |
100 | 98 | |
101 | -Mezuro\footnote{\url{http://mezuro.org/}} is a platform to collect source code | |
102 | -metrics to monitor the internal quality of software written in C, C++, | |
103 | -Java, Python, Ruby, and PHP. | |
99 | +Mezuro\footnote{\url{http://mezuro.org/}} \cite{mezuro_oss} is a platform to | |
100 | +collect source code metrics to monitor the internal quality of software written | |
101 | +in C, C++, Java, Python, Ruby, and PHP. | |
104 | 102 | |
105 | 103 | In general, source code metrics tools also do not present a friendly way |
106 | 104 | to interpret its results and, even more, do not follow a standardization |
... | ... | @@ -129,7 +127,7 @@ directing requests to one of the integrated applications. It |
129 | 127 | post-processes responses from the applications to apply a consistent |
130 | 128 | visual appearance, manages authentication, and provides a unified search |
131 | 129 | functionality: instead of using the redundant restricted search |
132 | -functionality of each application, a search in the SPB portal might | |
130 | +functionality of each application, a search o n the SPB portal might | |
133 | 131 | return content from any of the applications, be it web pages, mailing |
134 | 132 | list posts, or source code. |
135 | 133 | ... | ... |
opensym2017/content/06-features.tex
... | ... | @@ -48,12 +48,15 @@ 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 portal. 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 | +Usually, Collaborative Development Environments (CDE) demand a version control | |
58 | +system, trackers, build tools, knowledge centers, and communication tools | |
59 | +\cite{collaboration_tools}. | |
57 | 60 | The new SPB also provides |
58 | 61 | tools to encourage developers to keep source code and its |
59 | 62 | development activity within the platform. Any created software has, by default, a | ... | ... |
opensym2017/content/08-process.tex
... | ... | @@ -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} |
... | ... | @@ -106,7 +106,10 @@ strategical, tactical, and operational views. In a practical point of view, one |
106 | 106 | milestone per user history (feature), and one or more issues for addressing |
107 | 107 | each feature. With this approach we achieved two important goals: keeping all |
108 | 108 | the management as close possible to to the source code, and tracking every |
109 | -feature developed during the project. | |
109 | +feature developed during the project. Our decision to | |
110 | +use Wiki initially was empirical, but later reinforced by a research conducted | |
111 | +by Joseph Chao showing the advantage of using Wikis \cite{chao2007student, | |
112 | +opensourcestyle}. | |
110 | 113 | |
111 | 114 | \subsection{High-level project management and reporting} |
112 | 115 | |
... | ... | @@ -128,7 +131,7 @@ diagram that represents our meeting organization. |
128 | 131 | \begin{figure}[hbt] |
129 | 132 | \centering |
130 | 133 | \includegraphics[width=\linewidth]{figures/meeting_flows.png} |
131 | - \caption{Meetings cycles} | |
134 | + \caption{Meetings cycles.} | |
132 | 135 | \label{fig:meeting} |
133 | 136 | \end{figure} |
134 | 137 | |
... | ... | @@ -160,15 +163,19 @@ To keep the track of all of those things we used the SPB itself, |
160 | 163 | especially Gitlab. Basically, we had: |
161 | 164 | |
162 | 165 | \begin{enumerate} |
163 | - \item Project repository: We have one organization with many repositories | |
164 | - \item Milestones: Each milestone was used to register a release | |
166 | + \item Project repository: We have one organization with many repositories; | |
167 | + \item Milestones: Each milestone was used to register a release; | |
165 | 168 | \item Wiki: Each release has one page on wiki with the compilation of |
166 | - strategical meeting | |
169 | + strategical meeting; | |
167 | 170 | \item Issues: Each sprint planning generated issues, which we associated to |
168 | 171 | the specific milestone and updated the wiki with the issue number related |
169 | 172 | with them. Finally each developer assigned the issue to itself. |
170 | 173 | \end{enumerate} |
171 | 174 | |
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). | |
175 | +Notice that this workflow gave us and the Brazilian government agents full | |
176 | +traceability from a high level view of each feature to the lowest level (code). | |
177 | +It is important to highlight that we converge to this workflow after many | |
178 | +experiments. For example, we used a tool named Redmine for organizing our tasks | |
179 | +during the sprints, however, this tool revealed inefficient for our case since | |
180 | +the government agents lost part of the project traceability. We realized that | |
181 | +centralize all the work in the SPB portal is the best option for our case. | ... | ... |
opensym2017/content/10-lessons.tex
... | ... | @@ -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/11-conclusion.tex
... | ... | @@ -11,7 +11,7 @@ platform - developed by an heterogenous team of professors, master and |
11 | 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 | -Second, the 30 months project which developed this platform, results in an | |
14 | +Second, the 30 months project which developed this platform results in an | |
15 | 15 | important case that it is possible to mitigate issues seen as conflicting to IT |
16 | 16 | development environment and between industry and academy. We shown that, as |
17 | 17 | long as the institution can provide a healthy and challenging environment to |
... | ... | @@ -19,8 +19,17 @@ its students, its is possible to conciliate studies and professional training |
19 | 19 | in universities. After the end of the project, some students successfully |
20 | 20 | embraced opportunities in public and private sectos, within national borders |
21 | 21 | and abroad. Some others went further and started their own companies. |
22 | - | |
23 | 22 | We also shown that, with some adaptations/"translation processes", was possible |
24 | 23 | to conciliate agile methodologies and FOSS practices to develop software to |
25 | 24 | governmental organizations with functional hierarchical structures that use |
26 | 25 | traditional development paradigm. |
26 | + | |
27 | +The SPB project represented an opportunity for us to apply many of our belief | |
28 | +related to FLOSS and Agile Method. We put an enormous effort to create a | |
29 | +friendly environment for everybody involved in the project, and for showing to | |
30 | +the government another way to interact with FLOSS community and university. Our | |
31 | +work style was extremely open and we tried to be transparent for the entire | |
32 | +society. As a consequence, we believe that we still need to investigate more | |
33 | +all the data produced by the project and the impacts on the students. We | |
34 | +expected to conduct a post-mortem analyze in the project since we have many | |
35 | +open data and we applied many concepts that still extra validation. | ... | ... |
opensym2017/spb.bib
... | ... | @@ -197,22 +197,15 @@ |
197 | 197 | year = {2003} |
198 | 198 | } |
199 | 199 | |
200 | -@inproceedings{chao2007, | |
201 | - added-at = {2015-11-18T00:00:00.000+0100}, | |
202 | - author = {Chao, Joseph}, | |
203 | - biburl = {https://www.bibsonomy.org/bibtex/261af946a27913bd7eab12c1e6aa3db3a/dblp}, | |
204 | - booktitle = {CSEET}, | |
205 | - ee = {http://doi.ieeecomputersociety.org/10.1109/CSEET.2007.49}, | |
206 | - interhash = {9d86cf791b047bb6d9484c32cfa0ee92}, | |
207 | - intrahash = {61af946a27913bd7eab12c1e6aa3db3a}, | |
208 | - isbn = {0-7695-2893-7}, | |
209 | - keywords = {dblp}, | |
210 | - pages = {255-261}, | |
211 | - publisher = {IEEE Computer Society}, | |
212 | - timestamp = {2015-11-19T11:37:24.000+0100}, | |
213 | - title = {Student Project Collaboration Using Wikis.}, | |
200 | +@inproceedings{chao2007student, | |
201 | + title={Student project collaboration using Wikis}, | |
202 | + author={Chao, Joseph}, | |
203 | + booktitle={Software Engineering Education \& Training, 2007. CSEET'07. 20th Conference on}, | |
204 | + pages={255--261}, | |
205 | + year={2007}, | |
214 | 206 | url = {http://dblp.uni-trier.de/db/conf/csee/csee2007.html}, |
215 | - year = {2007} | |
207 | + publisher = {IEEE Computer Society}, | |
208 | + organization={IEEE} | |
216 | 209 | } |
217 | 210 | |
218 | 211 | @inproceedings{tosi2015, |
... | ... | @@ -257,3 +250,50 @@ |
257 | 250 | note = {In: 2020 FLOSS Roadmap}, |
258 | 251 | year = {2008} |
259 | 252 | } |
253 | + | |
254 | + | |
255 | +@book{refactoring, | |
256 | + title={Refactoring for software design smells: Managing technical debt}, | |
257 | + author={Suryanarayana, Girish and Samarthyam, Ganesh and Sharma, Tushar}, | |
258 | + year={2014}, | |
259 | + publisher={Morgan Kaufmann} | |
260 | +} | |
261 | + | |
262 | +@article{mezuro_oss, | |
263 | + title={Mezuro: Understanding source code metrics}, | |
264 | + author={Guedes and Meirelles and Manzo and Camarinha}, | |
265 | + journal={International Conference on Open Source Systems}, | |
266 | + volume={01}, | |
267 | + year={2017}, | |
268 | + publisher={OSS} | |
269 | +} | |
270 | + | |
271 | +@article{collaboration_tools, | |
272 | + title={Collaboration tools for global software engineering}, | |
273 | + author={Lanubile, Filippo and Ebert, Christof and Prikladnicki, Rafael and Vizca{\'\i}no, Aurora}, | |
274 | + journal={IEEE software}, | |
275 | + volume={27}, | |
276 | + number={2}, | |
277 | + year={2010}, | |
278 | + publisher={IEEE} | |
279 | +} | |
280 | + | |
281 | +@article{parker2007wiki, | |
282 | + title={Wiki as a teaching tool}, | |
283 | + author={Parker, Kevin and Chao, Joseph}, | |
284 | + journal={Interdisciplinary Journal of e-learning and Learning Objects}, | |
285 | + volume={3}, | |
286 | + number={1}, | |
287 | + pages={57--72}, | |
288 | + year={2007}, | |
289 | + publisher={Informing Science Institute} | |
290 | +} | |
291 | + | |
292 | +@inproceedings{opensourcestyle, | |
293 | + title={Open source-style collaborative development practices in commercial projects using github}, | |
294 | + author={Kalliamvakou, Eirini and Damian, Daniela and Blincoe, Kelly and Singer, Leif and German, Daniel M}, | |
295 | + booktitle={Proceedings of the 37th International Conference on Software Engineering-Volume 1}, | |
296 | + pages={574--585}, | |
297 | + year={2015}, | |
298 | + organization={IEEE Press} | |
299 | +} | ... | ... |