Download as
Browse Code »

Commit 3c84d052041e549adc5ca1ca345d1b54c6b91b0f

Authored by Melissa Wen
1 parent c89935f3
Exists in master and in 3 other branches oss_2018, oss_2018_siqueira, rework_case_study

[oss-2018] refactoring case study

Showing 2 changed files with 58 additions and 78 deletions   Show diff stats
icse2018/content/01-introduction.tex
  Diff comments   View file @3c84d05
... ... @@ -40,7 +40,7 @@ However, neither culture nor values can be easily change and the effort for this
40 40 kind of movement does not seem feasible for development projects with tight
41 41 deadlines and budgets.
42 42  
43   -This paper present practical ways to harmonize the traditional and agile
  43 +This paper present practical ways to harmonize the project management traditional and agile
44 44 approach in the management of a partnership project between government and
45 45 academia. For this, we interviewed members involved in the project with distinct
46 46 roles: requirement analysts and stakeholders of the Brazilian Ministry of
... ...
icse2018/content/04-case.tex
  Diff comments   View file @3c84d05
1   -\section{The Case Study}
2   -\label{sec:casestudy}
  1 +The project to evolve the Brazilian Public Software Portal
  2 +\cite{meirelles2017spb} was a partnership between government and academia held
  3 +between 2014 and 2016. In order to solve maintenance problems and fill
  4 +design-reality gaps in the portal, the Ministry of Planning (MPOG) joined the
  5 +University of Brasília (UnB) and the University of São Paulo (USP) to develop a
  6 +platform with features and technologies novelties in the government context.
3 7  
4   -%TODO Repensar a escrita
  8 +The academic team carried out development activities in the Advanced Laboratory
  9 +of Production, Research and Innovation in Software Engineering of UnB. The
  10 +project management and development process in this laboratory is usually
  11 +executed adopting agile methodologies, such as Extreme Programming (XP), Scrum
  12 +and Kanban. For this project, a total of 42 undergraduate students, two master's
  13 +students and two coordinator-professors participated in the development team.
  14 +Six IT professionals were also hired as senior developers due their vast
  15 +experiences in Front-end/UX or in one of the softwares integrated to the
  16 +platform.
5 17  
  18 +The government team was composed of a director, a coordinator, and two IT
  19 +analysts from a department of MPOG. Although it was responsible for the
  20 +execution of this collaboration project, this department generally does not
  21 +execute development of ministry's software. This department is responsible for
  22 +contracting and homologating software development services and follows
  23 +traditional management approaches, such as the RUP.
6 24  
7   -The Brazilian Public Software portal is an e-government project for sharing
8   -public software projects, specific type of systems that meets the needs of
9   -modernization of the Brazilian public administration. The vailability of this
10   -software in electronic via aims at saving public resources, benefiting the
11   -State and society.
  25 +In order to manage the project progress, these two aforementioned teams
  26 +periodically met in person. These meetings initially only took place at the
  27 +ministry's headquarters to discuss strategic/political and technical goals.
  28 +These meetings were held monthly with the presence of two UnB professors, the
  29 +executive-secretary of the Presidency (project supporter) and all MPOG members
  30 +responsible for the project. The management of the development team was
  31 +concentrated in the academia side. The workflow was organized in Redmine in
  32 +biweekly sprints and 4-month releases, with intermediate deliveries hosted in
  33 +university environment. However, with the progress of the project, this format
  34 +proved to be inefficient. Conflicts between the internal management processes
  35 +and differences in pace and goals of each institution were compromising the
  36 +platform development.
12 37  
13   -The first version of the portal was released in 2007 but the lack of new
14   -development and sustainability projects made the platform obsolete with
15   -uncontrollable crashes. With approximately 145 requirements mapped out in
16   -dialogues with public agencies and society, a new platform needed to be
17   -created.
18   -%TODOc: refazer e avaliar se basta citarmos o nosso paper da OSS
  38 +In this case study, we focus on analyzing the dynamics between government and
  39 +academia for collaborative development. We aim to map the practices adopted in
  40 +the project management and development process to harmonize the cultural and
  41 +organizational differences of the institutions involved. Our analysis was guided
  42 +by the following research questions:
19 43  
  44 +\textbf{Q1.} {How to combine different teams with different management processes
  45 +in a government-academia collaboration project?}
20 46  
21   -The evolution of the Brazilian Public Software platform was a partnership
22   -project between the Brazilian government and Brazilian public universities
23   -between the years 2014 and 2016. The management and development team was made
24   -up of staff from the Ministry of Planning (MPOG), professors from the
25   -University of Brasília (UnB), professionals of the IT market, MSc students in
26   -Computer Science at the University of São Paulo (USP), and undergraduate
27   -students in Software Engineering at the University of Brasília. The project was
28   -developed physically in the Advanced Laboratory of Production, Research and
29   -Innovation in Software of UnB. In Brasília, capital of Brazil, the federal
30   -government is the most important customer and the largest bidder of software
31   -development contracts. Understanding the particularities of projects with the
32   -government and being prepared to meet your goals and pace of production is
33   -important for students professionally. Thus, this collaborative project was an
34   -opportunity for the transfer of knowledge between academia and government and
35   -for the practical application of the project management methods taught in the
36   -undergraduate course in Software Engineering.
37   -%TODO:Muita informação/detalhe desnessário
  47 +In this first moment, we describe what changes in the management model and the
  48 +development process have improved interactions between institutions, as well as
  49 +internally. To map the benefits obtained by these movements, we use evidence
  50 +obtained from interviews and online surveys with members on both sides, after
  51 +project closure. We also collect data from management and communication tools
  52 +used throughout the project.
38 53  
  54 +In a second moment, we address our analysis to issues related to organizational
  55 +differences and diversity of project members in terms of maturity and experience
  56 +in collaborative development. The harmony between teams sought not only to
  57 +approximate the mind-set and culture of teams but also to delimitate the
  58 +interactions between different roles and responsibilities. Evaluating this
  59 +synergy generates the second research question:
39 60  
40   -Differences in the organizational and managerial structure of the institutions
41   -to which each member belonged generated differences in goals, requirements and
42   -pace of execution. On the MPOG side, the requirements analysts were ministry
43   -staff who interacted most actively with the development team, their
44   -productivity was reported to their coordinator, and their coordinator reported
45   -to the board of directors. The director of the department responsible for
46   -software development had no autonomy over the deployment infrastructure. As the
47   -development and deployment of the ministry followed a traditional approach,
48   -opening a window of dialogue between these two departments for software
49   -deployment in production was usually not costly. Thus, the development of a
50   -software solution basically passed through the following steps: mapping
51   -requirements, prepararing a contract of licitation, hiring of contract
52   -executor, homologation of the product, delivery and deployment of the software,
53   -and payment.
  61 +\textbf{Q2.} \textit{Which boundaries should be established between government
  62 +and academia teams in collaboration interactions?}
54 63  
55   -On the UnB side, the agile approach was used for development.
56   -%
57   -Due to the amount
58   -and maturity of the requirements demanded and the novelty, in the governmental
59   -context, of several features, the traditional methodologies was unsuitable for
60   -the development of complex integrated software platform.
61   -% TODO: bem truncado ^
62   -The coordinator led
63   -the dialogue with board of directors as well as managbed the interactions
64   -between MPOG staff and dedveloper team. The development team was divided into
65   -specific groups for the main contexts and there was self-coordination among
66   -team members. The activities were organized by sprints of 15 days and the epics
67   -in 4 months. The development was incremental, with intermediate deliveries.
68   -%
69   -Due
70   -to differences in deployment pace between MPOG and UnB and other bureaucratic
71   -issues, the first version of the portal was launched on the university
72   -infrastructure and later migrated to the ministry infrastructure.
73   -% TODO: podemos citar nosso paper aceito na IEEE e não citar este último detalhes
74   -
75   -
76   -The main conflicts in the development process of the platform arose from the
77   -very nature of traditional and agile approaches: the government expected fully
78   -specified functionalities before implementation, a large volume of
79   -documentation, formalization of reports with full functionality deliveries,
80   -function point calculations for changes in requirements; the academy understood
81   -that features should be broken down into small functionalities with short-term
82   -deliverables for validation, decisions about what would be developed and how it
83   -would be developed should be collaboratively taken between client and
84   -developers, roles were flexible and organized organically.
85   -
86   -%TODO: ainda falta fechar com algo
  64 +We highlight positive and negative effects of boundaries created among project
  65 +member using evidences from interview responses and open field responses from
  66 +online surveys.
... ...