Download as
Browse Code »

Commit a69f0d8e35472a6e3356e90b6fb83f164d198af8

Authored by Melissa Wen
2 parents ea18fde2 cb1c2bf9
Exists in master

[oss-2018] review the case study

Showing 1 changed file with 37 additions and 29 deletions   Show diff stats
oss2018/content/03-methods.tex
  Diff comments   View file @a69f0d8
... ... @@ -23,33 +23,34 @@ repository.
23 23 \subsection{The case study}
24 24  
25 25 The project to evolve the SPB portal was a partnership between government and
26   -academia held between 2014 and 2016 \cite{meirelles2017spb}. The old version of
  26 +academia held between 2014 and 2016~\cite{meirelles2017spb}. The old version of
27 27 SPB suffered from maintenance problems and design-reality gaps. In this sense,
28   -The Ministry of Planning (MPOG) decided to join the University of Brasília
29   -(UnB) and the University of São Paulo (USP) to develop a new platform. This
30   -platform had as its primary requirement to be based on existing FLOSS projects
31   -and integrate multiple systems into one, providing the end user with a unified
32   -experience.
  28 +the Ministry of Planning (MPOG) decided to join the University of Brasília
  29 +(UnB) and the University of São Paulo (USP) to develop a new platform.
  30 +This platform had the primary requirement to be based on existing FLOSS
  31 +projects and integrate multiple systems into one, providing the end user with a
  32 +unified experience.
33 33  
34 34 In short, the SPB portal evolved into a Collaborative Development Environment
35   -(CDE) \cite{booch2003}. It was a novelty in the context of the Brazilian
36   -government, due to the technologies employed and its diverse features. The
37   -portal includes social networking, mailing lists, version control system, and
38   -source code quality monitoring. All software is integrated using a
39   -system-of-systems framework \cite{meirelles2017spb}.
  35 +(CDE)\cite{booch2003}. It was a novelty in the context of the Brazilian
  36 +government, due to the technologies employed and its diverse features, which
  37 +includes social networking, mailing lists, version control system, and source
  38 +code quality monitoring. All software is integrated using a system-of-systems
  39 +framework \cite{meirelles2017spb}. These characteristics led the project to
  40 +interact with different FLOSS projects and communities.
40 41  
41 42 The platform development took place at the Advanced Laboratory of Production,
42 43 Research, and Innovation in Software Engineering (LAPPIS/UnB) and the FLOSS
43   -Competence Center at USP (CCSL/USP). Undergraduate interns, IT professionals and
44   -professors formed a partially distributed development team. While interns and
45   -professors worked in-person, most IT professionals worked remotely. Their
46   -activities followed the workflow of biweekly sprints and 4-month releases.
  44 +Competence Center at USP (CCSL/USP), both with experience in FLOSS development.
  45 +Undergraduate interns, IT professionals, and professors formed a partially
  46 +distributed development team. Their activities followed the workflow
  47 +of biweekly sprints and 4-month releases.
47 48  
48   -On the managerial aspect, at the project
49   -beginning, the collaboration management and strategic discussions happened only
50   -once a month, when project leaders and MPOG directors met in person at the
51   -ministry's headquarters. Table~\ref{tab:gov-academia-diff} summarizes the
52   -organizational differences in both involved sides.
  49 +On the managerial aspect, at the project beginning, the collaboration
  50 +management and strategic discussions happened only once a month, when project
  51 +leaders and MPOG directors met in person at the ministry's headquarters.
  52 +Table~\ref{tab:gov-academia-diff} summarizes the organizational differences in
  53 +both involved sides.
53 54  
54 55 \vspace*{-.5cm}
55 56  
... ... @@ -80,15 +81,22 @@ organizational differences in both involved sides.
80 81  
81 82 \vspace*{-.8cm}
82 83  
83   -During the project progress, this workflow proved to be inefficient. Conflicts
84   -between the internal management processes and differences in pace and goals of
85   -each institution were compromising the platform development. To improve the
86   -project management process and reducing the mismatch between government and
87   -academia, professors, with the senior developers' collaboration, incrementally
88   -employed a set of best practices based on FLOSS and agile values. Throughout
89   -the project, the development leaders made decisions in a non-systematic way to
90   -promote the usage of these techniques. In this paper, we analyzed and codified
91   -these decisions and identified how they favored the collaboration progress.
  84 +During the course of the project, we were unable to fully extract all the
  85 +possible benefits from this workflow. Conflicts between the internal
  86 +management processes and differences in pace and goals of each institution were
  87 +compromising the platform development. To improve the project management
  88 +process and reducing the mismatch between government and academia, professors,
  89 +with the senior developers' collaboration, incrementally employed a set of best
  90 +practices based on FLOSS and agile values.
  91 +
  92 +Although the government initiative to work with the university, they had a
  93 +natural barrier to accept the non-traditional development approaches. The
  94 +development leaders made decisions in a non-systematic way to promote the usage
  95 +of FLOSS and agile techniques in such way that the government understood the
  96 +value of the collaboration. In this scenario, the SPB project became a proper
  97 +case to comprehend the processes harmonization between government and
  98 +university. In this paper, we analyzed and codified the set of project
  99 +decisions and how they favored the collaboration progress.
92 100  
93 101 \subsection{Survey, Interview and Data Collection}
94 102  
... ...