Software Público Brasileiro

\section{The Case Study}
\label{sec:casestudy}


The Brazilian Public Software portal is an e-government project for sharing
public software projects, specific type of systems that meets the needs of
modernization of the Brazilian public administration. The vailability of this
software in electronic via aims at saving public resources, benefiting the
State and society.

The first version of the portal was released in 2007 but the lack of new
development and sustainability projects made the platform obsolete with
uncontrollable crashes. With approximately 145 requirements mapped out in
dialogues with public agencies and society, a new platform needed to be
created.
%TODOc: refazer e avaliar se basta citarmos o nosso paper da OSS


The evolution of the Brazilian Public Software platform was a partnership
project between the Brazilian government and Brazilian public universities
between the years 2014 and 2016. The management and development team was made
up of staff from the Ministry of Planning (MPOG), professors from the
University of Brasília (UnB), professionals of the IT market, MSc students in
Computer Science at the University of São Paulo (USP), and undergraduate
students in Software Engineering at the University of Brasília. The project was
developed physically in the Advanced Laboratory of Production, Research and
Innovation in Software of UnB. In Brasília, capital of Brazil, the federal
government is the most important customer and the largest bidder of software
development contracts. Understanding the particularities of projects with the
government and being prepared to meet your goals and pace of production is
important for students professionally. Thus, this collaborative project was an
opportunity for the transfer of knowledge between academia and government and
for the practical application of the project management methods taught in the
undergraduate course in Software Engineering.
%TODO:Muita informação/detalhe desnessário


Differences in the organizational and managerial structure of the institutions
to which each member belonged generated differences in goals, requirements and
pace of execution. On the MPOG side, the requirements analysts were ministry
staff who interacted most actively with the development team, their
productivity was reported to their coordinator, and their coordinator reported
to the board of directors. The director of the department responsible for
software development had no autonomy over the deployment infrastructure. As the
development and deployment of the ministry followed a traditional approach,
opening a window of dialogue between these two departments for software
deployment in production was usually not costly. Thus, the development of a
software solution basically passed through the following steps: mapping
requirements, prepararing a contract of licitation, hiring of contract
executor, homologation of the product, delivery and deployment of the software,
and payment.

On the UnB side, the agile approach was used for development.
%
Due to the amount
and maturity of the requirements demanded and the novelty, in the governmental
context, of several features, the traditional methodologies was unsuitable for
the development of complex integrated software platform.
% TODO: bem truncado ^
The coordinator led
the dialogue with board of directors as well as managbed the interactions
between MPOG staff and dedveloper team. The development team was divided into
specific groups for the main contexts and there was self-coordination among
team members. The activities were organized by sprints of 15 days and the epics
in 4 months. The development was incremental, with intermediate deliveries.
%
Due
to differences in deployment pace between MPOG and UnB and other bureaucratic
issues, the first version of the portal was launched on the university
infrastructure and later migrated to the ministry infrastructure.
% TODO: podemos citar nosso paper aceito na IEEE e não citar este último detalhes


The main conflicts in the development process of the platform arose from the
very nature of traditional and agile approaches: the government expected fully
specified functionalities before implementation, a large volume of
documentation, formalization of reports with full functionality deliveries,
function point calculations for changes in requirements; the academy understood
that features should be broken down into small functionalities with short-term
deliverables for validation, decisions about what would be developed and how it
would be developed should be collaboratively taken between client and
developers, roles were flexible and organized organically.

%TODO: ainda falta fechar com algo