01-introduction.tex
5.94 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
\section{Introduction}
\label{sec:intro}
The Brazilian Federal Government has been
improving its software adoption and development processes. For
instance, in 2003, the recommendation to adopt Free/Libre/Open Source
Software (FLOSS) become a public policy. In 2007, the Brazilian
Government released a portal named Brazilian Public Software
(\textit{Software Público Brasileiro} -- SPB, in Portuguese), with the
goal of sharing FLOSS projects developed by, or for, the Brazilian
Government. Additionally, the Brazilian legal instrument on software
contracting (known as IN 04/2012) mandates that public agents must give
priority to solutions available on the SPB Portal. In short, the
acquisition of a proprietary solution must be explicitly justified by
demonstrating that there is no suitable alternative on the SPB Portal.
In 2013, the Brazilian Federal Court issued a ruling document
(\textit{Acórdão 2314/2013}) about an audit survey regarding the use of
agile methodologies in software development contracts with the public
administration.
Despite of that, in practice, free software or agile methodologies, that is,
collaborative and empirical software development methods are not widely
practiced and understood by the Brazilian government agents. Thus, the
hierarchical and traditional processes from the government and the lack
of expertise in real-world software development of its agents produces a
situation of inefficient software development contracts and
unjustifiable expending of taxpayers' money.
Since 2009, the SPB Portal was having several technical issues. The original
codebase was not being developed anymore, also, there was a large amount of
knowingly non-optimal or wrong design decisions to overcome (in other words,
technical debt \cite{refactoring}). The system was a modified version of an
existing FLOSS platform called OpenACS \footnote{\url{http://openacs.org}}, and
the old SPB portal was not being updated anymore against the official OpenACS
releases. In this scenario, the portal maintenance has become increasingly
difficult.
After some events and meetings to collect requirements from the federal
government and from the society, a new platform for the SPB Portal was
developed, among January 2014 and June 2016, by the University of Brasília
(UnB) and the University of São Paulo (USP) in a partnership with the Brazilian
Ministry of Budget, Planning, and Management (MP). It was designed as an
integrated platform for collaborative software development \cite{bobr2003}, and
includes functionality for social networking, mailing lists, version control
system, and source code quality monitoring. To coordinate and develop this
project during 30 months, UnB received from the Brazilian Federal Government a
total of 2,619,965.00 BRL (about 750,000.00 USD in June 2016).
\begin{figure*}[hbt]
\centering
\includegraphics[width=.9\linewidth]{figures/home-SPB_2.png}
\caption{The new SPB Portal.}
\label{fig:spb}
\end{figure*}
The project was developed by a team of 3 professors, 2 masters students, and
approximately 50 undergraduate students (not all of them at the same time,
though -- graduations and other events triggered changes in the team) together
with 2 professional designers and 6 senior developers from free software
communities. The professors and all undergraduate student were from UnB, and
the master students were from USP. Regarding the designers and senior
developers, 7 of 8 they were living outside of Brasília: Curitiba/Brazil, São
Paulo/Brazil, Ribeirão Preto/Brazil, Salvador/Brazil, Santo Domingo/Dominican
Republic, and Montreal/Canada. In other words, we had a team working in
distributed collaborative virtual environment. This diversity of actors and the
relationships between industry, academy and government also made the project a
valued opportunity to explore the benefits and challenges of using
FLOSS\cite{kon2011,deKoenigsberg2008, fagerholm2013, fagerholm2014} and
Agile\cite{steghofer2016, harzl2017} practices for Software Engineering
education.
Figure \ref{fig:spb} shows the home page of this integrated platform.
All development was done in the open, and the changes we needed in the
FLOSS tools were contributed back to their respective communities. Our
process was based on agile practices and FLOSS communities interaction.
We defined development cycles and released 5 versions of the new SPB
Portal. The first release (beta) was in September 2014, only 9 months
from the beginning of the project. The old portal was shut down in
September 2015. Finally, the last version, illustrated in Figure 1, was
released in June 2016.
In this paper, we present an overview of this new generation of the SPB Portal.
The paper shares the methodology employed to develop this project, in
partnership with the Brazilian Federal Government, to comply with its
requirements at the same time to be as faithful as possible to FLOSS
development \cite{mockus2002, tosi2015}. Moreover, we discuss several lessons
learned to provide a distributed collaborative virtual environment involving
alarge undergraduate student team and remote senior developers. Lastly, we
released an unprecedented platform for the Brazilian government applying
empirical software development methods. This case can help other projects to
overcome similar software engineering challenges in the future, as well as to
illustrate how universities can improve the real-world experience of their
students by means of this kind of project.
The remainder of this work is organized as follows.
Section \ref{sec:spb}...
Section \ref{sec:relatedwork} enumerates a number of related works on the...
Section \ref{sec:researchdesign} presents the research design...
Section \ref{sec:requirements} reports ...
Section \ref{sec:architecture} ...
Section \ref{sec:features} ...
Section \ref{sec:ux} ...
Section \ref{sec:process} ...
Section \ref{sec:contributions} ...
Section \ref{sec:lessons} ...
Finally, Sections \ref{sec:conclusion} concludes the paper highlighting its
main contributions and pointing paths to future works.