Download as
Browse Code »

Commit 7993fa1ea3a4fa07b87d4236a1a4a473e438e086

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

[oss-2018] review

Showing 5 changed files with 78 additions and 215 deletions   Show diff stats
icse2018/content/00-abstract.tex
  Diff comments   View file @7993fa1
1 \begin{abstract} 1 \begin{abstract}
2 2
3 -TO-DO  
4 -  
5 -...  
6 -  
7 -...  
8 -  
9 -...  
10 -  
11 -...  
12 - 3 +In this paper, we examined the case of a 30-month government-academia development collaboration to map open source practices that reconciled the differences in software project management on both sides. We evidence the practices adopted from the data collected on the repository management tool of the developed platform itself. The benefits of the empirical management model created in this project are revealed by the results of surveys with participants on both sides of the project. These results suggest the adoption of open source practices to improve the software development in context with diversity of organizational culture and people mind-set.
13 4
14 \end{abstract} 5 \end{abstract}
15 6
icse2018/content/01-introduction.tex
  Diff comments   View file @7993fa1
1 \section{Introduction} 1 \section{Introduction}
2 2
3 E-government projects differ from others due to their complexity and 3 E-government projects differ from others due to their complexity and
4 -extension\cite{anthopoulos2016egovernment}. They are extensive in terms of  
5 -organizational size, time, scope, target audience and corresponding resistance  
6 -to change. They are also complex by combining Construction, Innovation and Information and Communications Technologies  
7 -in their context, in addition to politics and social impact. To create novelty for e-government projects and meet the needs of society, research  
8 -collaboration between government and academia can be considered as a way to  
9 -transfer technological knowledge. However, such collaboration also has  
10 -challenges, not only in relation to project organization and alignment of goals  
11 -and pace \cite{sandberg2017iacollaboration}, but also to overcome the failure 4 +extension\cite{anthopoulos2016egovernment}. They are complex because they combine construction, innovation, information \& communications technologies, politics and social impact. Their extension, on the other hand, is related to their scope, target audience, organizational size, time and the corresponding resistance
  5 +to change. Government-academia researches can be considered a way to create novelty for e-government projects and to meet the needs of society. However, this collaborative work also has challenges, such as to organize the project, to align goals, to synchronize the pace of both sides\cite{sandberg2017iacollaboration}, and to overcome the failure
12 trend of e-government projects \cite{goldfinch2007pessimism}. 6 trend of e-government projects \cite{goldfinch2007pessimism}.
13 7
14 -Poor project management is one of the top failure reasons of  
15 -e-government projects \cite{anthopoulos2016egovernment}. In Brazil, while  
16 -industry and academia prefer agile approach to manage their projects, -  
17 -characterized by people-oriented approach  
18 -\cite{highsmith2001agileSoftwareDevelopment}, the collaboration with clients  
19 -\cite{fowler2001newMethod}, small self-organized teams  
20 -\cite{cockburn2001peopleFactor}, and the flexibility regarding planning  
21 -\cite{highsmith2002agileEco} - the government culturally uses traditional  
22 -methods to discipline its software development process - focused on  
23 -documentation, processes oriented, and heavily based on tools  
24 -\cite{awad2005comparisonAgileTrad}. When government and academia decide to  
25 -come together for the development of an e-government solution, management  
26 -processes of each institution needs to be aligned. Changing the software  
27 -development process represents a complex organizational change that  
28 -impact several aspects such as structure, culture, and management practices  
29 -\cite{nerur2015challenges}. However, neither culture nor values can be  
30 -easily change and the effort for this kind of movement does not seem  
31 -feasible for development projects with tight deadlines and budgets. 8 +Poor project management is one of the main reasons why
  9 +e-government projects fail\cite{anthopoulos2016egovernment}. In Brazil, while
  10 +industry and academia prefer agile approaches to manage their projects, government organizations generally use traditional
  11 +methods to discipline its software development. When government and academia decide to
  12 +join forces to develop an e-government solution, these differences in project management become an issue. Changing the software
  13 +development process in a large-size institution represents a complex organizational change that has impacts on structure, culture, and management practices \cite{nerur2015challenges}. Therefore the effort for this kind of movement does not seem
  14 +feasible for projects with tight deadlines and budgets.
32 15
33 -This paper presents practical ways of harmonizing project management process  
34 -differences existing between government and academia based on free software  
35 -development practices. For this, we interviewed members involved in the project  
36 -with distinct roles: requirement analysts of the Brazilian Ministry of Planning  
37 -(MPOG), interns of the University of Brasília and University of São Paulo, and  
38 -senior developers. We also analyze data collected from the management and  
39 -communication tools. With these results, we evidence best practices adopted on a  
40 -30-months project to create an unprecedented platform for the Brazilian  
41 -government. Finally, we compare briefly the results of this current work to the  
42 -lessons learned reported in our previous work.\cite{meirelles2017spb}. 16 +This paper presents open source practices adopted to harmonize differences between government and academia project management. By examining a 30-month government-academia collaboration case, we map
  17 +the management practices of the referred project and show their benefits, using collected data from repository management tools and surveys with project participants of both sides: analysts from the Brazilian Ministry of Planning (MPOG) and developers from the University of Brasília and the University of São Paulo. At the end, we compare the results of this current work with the
  18 +lessons learned and reported in a previous paper\cite{meirelles2017spb}.
43 19
44 Section \ref{sec:relatedwork} describes related work. Section 20 Section \ref{sec:relatedwork} describes related work. Section
45 \ref{sec:researchdesign} describes our research questions and research 21 \ref{sec:researchdesign} describes our research questions and research
icse2018/content/04-methods.tex
  Diff comments   View file @7993fa1
1 \section{Research Design} 1 \section{Research Design}
2 \label{sec:researchdesign} 2 \label{sec:researchdesign}
3 3
4 -The focus on this paper is finding practical ways to reconcile cultural  
5 -differences in software development between academia and government, 4 +The focus on this paper is investigating practical ways to reconcile cultural
  5 +differences in software development process between academia and government,
6 without modifying their internal processes. Our analysis was guided by the 6 without modifying their internal processes. Our analysis was guided by the
7 following research questions: 7 following research questions:
8 8
9 -\textbf{RQ1.}{What practices based on open source development experiences would 9 +\textbf{RQ1.}\textit{What practices based on open source development experiences would
10 help to combine teams with different management processes in a 10 help to combine teams with different management processes in a
11 government-academia collaboration project?} 11 government-academia collaboration project?}
12 12
13 13
14 -\textbf{RQ2.}{How do open source development practices benefit the process of 14 +\textbf{RQ2.}\textit{How do open source development practices benefit the process of
15 developing an e-government platform in a government-academia collaboration?} 15 developing an e-government platform in a government-academia collaboration?}
16 16
17 To answer these questions, we use as a case study the evolution project of the 17 To answer these questions, we use as a case study the evolution project of the
18 -SPB portal \cite{meirelles2017spb}, a government and academia collaborative 18 +SPB portal \cite{meirelles2017spb}, a government-academia collaborative
19 development based on open source software integration. We designed two surveys 19 development based on open source software integration. We designed two surveys
20 -and an interview aimed at the different roles performed by the ex-project 20 +and an interview to the different roles performed by the ex-project
21 participants and collect public data from the project development environment 21 participants and collect public data from the project development environment
22 available on the developed platform itself. Our research approach is detailed 22 available on the developed platform itself. Our research approach is detailed
23 in the following subsections. 23 in the following subsections.
24 24
25 -\subsection{The case estudy} 25 +\subsection{The case study}
26 26
27 The project to evolve the Brazilian Public Software Portal 27 The project to evolve the Brazilian Public Software Portal
28 -\cite{meirelles2017spb} was a partnership between government and academia held  
29 -between 2014 and 2016. To solve maintenance problems and fill 28 +was a partnership between government and academia held
  29 +between 2014 and 2016\cite{meirelles2017spb}. To solve maintenance problems and fill
30 design-reality gaps in the portal, the Ministry of Planning (MPOG) joined the 30 design-reality gaps in the portal, the Ministry of Planning (MPOG) joined the
31 University of Brasília (UnB) and the University of São Paulo (USP) to develop a 31 University of Brasília (UnB) and the University of São Paulo (USP) to develop a
32 -platform based on the integration and evolution of existing open-source  
33 -software, with many features and technologies novelties in the government  
34 -context. 32 +platform based on the integration and evolution of five existing open source
  33 +software.this environment was a novelty in the context of the Brazilian government, due to the technologies employed and its diverse features, including social networking (Noosfero), mailing lists (MailMan), version control system (GitLab), and source code quality monitoring (Mezuro), all integrated using a system-of-systems software (Colab).
35 34
36 The academic team carried out development activities in the Advanced Laboratory 35 The academic team carried out development activities in the Advanced Laboratory
37 -of Production, Research and Innovation in Software Engineering (LAPPIS) of UnB. 36 +of Production, Research and Innovation in Software Engineering (LAPPIS) at UnB.
38 The project management and development process in this laboratory is usually 37 The project management and development process in this laboratory is usually
39 -executed adopting free software practices and agile approach. For this project,  
40 -a total of 42 undergraduate students, two MSc students and two  
41 -coordinator-professors participated in the development team. Six IT  
42 -professionals were also hired as senior developers due their vast experiences in  
43 -Front-end/UX or in one of the softwares integrated to the platform.  
44 -  
45 -The government team was composed of a director, a coordinator, and two IT  
46 -analysts from a department of MPOG. Although it was responsible for the  
47 -execution of this collaboration project, this department generally does not  
48 -execute development of ministry's software. This department is responsible for  
49 -contracting and homologating software development services and follows  
50 -traditional management approaches, such as the RUP. 38 +executed adopting empirical practices from open source communities and agile methodologies. For this project,
  39 +a total of 42 undergraduate students and two coordinator-professors participated in the development team. Six IT professionals were also hired as senior developers due their experiences in open source projects and two designers specialized in User eXperience.
51 40
  41 +The government team was composed of one director, one coordinator, and two IT
  42 +analysts from a department of MPOG. Although they were responsible for the
  43 +execution of this collaboration, their department generally does not
  44 +execute development of ministry's software, its responsibility is
  45 +contracting and homologating software development services, following
  46 +traditional management approaches, such as the RUP, CMMI, and PMBOK.
  47 +
  48 +% Conteúdo OK melhorar construção
52 These two aforementioned teams periodically met in person for the purpose of 49 These two aforementioned teams periodically met in person for the purpose of
53 -managing the project progress. These meetings initially only took place at the  
54 -ministry's headquarters to discuss strategic/political and technical goals.  
55 -These meetings were held monthly with the presence of two UnB professors, the  
56 -executive-secretary of the Presidency (project supporter) and all MPOG members  
57 -responsible for the project. The management of the development team was  
58 -concentrated in the academia side. The workflow was organized in Redmine in  
59 -biweekly sprints and 4-month releases, with intermediate deliveries hosted in  
60 -university environment. However, with the progress of the project, this format  
61 -proved to be inefficient. Conflicts between the internal management processes 50 +managing the project progress, discussing strategic/political and technical goals. Initially, these meetings took place at the ministry's headquarters and, usually, only directors and professors participated. The management of the development team was
  51 +concentrated in the academic side and was organized in
  52 +biweekly sprints and 4-month releases. However, with the progress of the project, this workflow proved to be inefficient. Conflicts between the internal management processes
62 and differences in pace and goals of each institution were compromising the 53 and differences in pace and goals of each institution were compromising the
63 platform development. 54 platform development.
64 55
65 \subsection{Survey and data collection} 56 \subsection{Survey and data collection}
66 57
67 -We divided the UnB development team into two groups of respondents according to  
68 -their roles during the project: UnB Interns and Senior Developers. For each 58 +We divided the UnB development team into two groups of target participants according to
  59 +their roles during the project: \textit{UnB Interns} and \textit{Senior Developers}. For each
69 group, we designed an online survey with topics related to project organization, 60 group, we designed an online survey with topics related to project organization,
70 development process, communication and relationship between members, acquired 61 development process, communication and relationship between members, acquired
71 -knowledge and experience with free software. We also interviewed two MPOG  
72 -analysts who directly interacted with the development team and project 62 +knowledge and experience with free software. We also interviewed two \textit{MPOG
  63 +analysts} who directly interacted with the development team and project
73 development process. The interview questions could be classified into four 64 development process. The interview questions could be classified into four
74 parts: Professional profile; Organization, communication and development 65 parts: Professional profile; Organization, communication and development
75 methodologies in the context of government and project; Satisfaction with the 66 methodologies in the context of government and project; Satisfaction with the
76 developed platform; Lessons learned. 67 developed platform; Lessons learned.
77 68
78 -\begin{enumerate}  
79 - \item \textit{UnB interns:} We sent the link of the online survey through  
80 -emails to 42 undergraduate students who participated in any time of the project 69 +We sent the link of the online survey through emails to 42 UnB interns (undergraduate students), who participated in any time of the project
81 as developer receiving scholarship. We received a total of 37 responses. Their 70 as developer receiving scholarship. We received a total of 37 responses. Their
82 average age is 25 years old and 91.9\% of them are male. Currently, 35.1\% 71 average age is 25 years old and 91.9\% of them are male. Currently, 35.1\%
83 continue at university as undergraduate or graduate students, 18.9\% work as 72 continue at university as undergraduate or graduate students, 18.9\% work as
@@ -86,9 +75,7 @@ entrepreneurs, 8.1\% are unemployed and the others work as teachers or civil @@ -86,9 +75,7 @@ entrepreneurs, 8.1\% are unemployed and the others work as teachers or civil
86 servants. 43.2\% said the SPB project was their first experience with free 75 servants. 43.2\% said the SPB project was their first experience with free
87 software. 76 software.
88 77
89 - \item \textit{Senior Developers:} We also sent the link of the online survey  
90 -through emails to eight advanced level researchers (MSc students or IT market  
91 -professionals who participated in some period of the project). All of them 78 +We also sent the link of the online survey through emails to eight senior developers (IT market professionals). All of them
92 answered the questionnaire. Their average age is 32 years old and 87.5\% are 79 answered the questionnaire. Their average age is 32 years old and 87.5\% are
93 male. They have an average of 11 years of experience in the IT market, and 80 male. They have an average of 11 years of experience in the IT market, and
94 currently 62.5\% of respondents are company employees, 37.5\% are freelance 81 currently 62.5\% of respondents are company employees, 37.5\% are freelance
@@ -97,21 +84,19 @@ worked on average in 5 companies and participated in 4 to 80 projects. They @@ -97,21 +84,19 @@ worked on average in 5 companies and participated in 4 to 80 projects. They
97 participated in this collaborative project between 7 to 24 months. 85.7\% of 84 participated in this collaborative project between 7 to 24 months. 85.7\% of
98 them had some experience with free software before the SPB project. 85 them had some experience with free software before the SPB project.
99 86
100 - \item \textit{MPOG Analysts:} two MPOG IT analysts were interviewed separately. 87 +Two MPOG IT analysts were interviewed separately.
101 Each interview took an average of 2 hours with 28 open questions. They are more 88 Each interview took an average of 2 hours with 28 open questions. They are more
102 than 30 years old and have been government employees for more than 7 years. 89 than 30 years old and have been government employees for more than 7 years.
103 Only one of them continues working in the same ministry. For both, this 90 Only one of them continues working in the same ministry. For both, this
104 collaborative project was their first experience of government-academia 91 collaborative project was their first experience of government-academia
105 development collaboration. 92 development collaboration.
106 -\end{enumerate}  
107 93
108 Finally, we quantitatively analyze data about the development of the project, 94 Finally, we quantitatively analyze data about the development of the project,
109 -publicly available on the SPB platform. We collected from the repository manager  
110 -of the platform, Gitlab - integrated platform software tool, all open issues  
111 -and commits made between April 2015 to February 2016 and related to the  
112 -main repository of the platform, that is, the development repositories of the  
113 -integrated software were not considered. For issues, the data collected were:  
114 -project name, author of the issue, opening date, issue title and number of 95 +publicly available on the SPB platform. We collected from the repository manager tool of the platform all open issues and commits related to the main repository of the platform, that is, the development repositories of the integrated software were not considered.
  96 +For issues, we collected:
  97 +project name, author of the issue, opening date, issue title, and number of
115 comments. We also collected informations about: total open issues, total 98 comments. We also collected informations about: total open issues, total
116 commits, different authors of issues, total of different authors of issues, 99 commits, different authors of issues, total of different authors of issues,
117 -total of comments, authors of comments, total of authors other than comments. 100 +total of comments, authors of comments, total of authors other than comments.
  101 +During the period from April 2015 to June 2016, 879 issues was opened by 59 distinct authors with a total of 4658 comments and 64 distinct commentators. The development team made 3256 commits in the repository provided by SPB platform, the first one in July 2014 and the last one in August 2016.
  102 +
icse2018/content/05-results.tex
  Diff comments   View file @7993fa1
@@ -12,62 +12,7 @@ At the end of the project, an empirical @@ -12,62 +12,7 @@ At the end of the project, an empirical
12 model of management and development process was created by aligning experiences 12 model of management and development process was created by aligning experiences
13 from the FLOSS universe, academic research and bureaucracies needed by the 13 from the FLOSS universe, academic research and bureaucracies needed by the
14 government. In this section, we present by context the practices adopted in this 14 government. In this section, we present by context the practices adopted in this
15 -second phase and show the benefits generated by its deployment, as summarized  
16 -in the Table \ref{practices-table}.  
17 -  
18 -%% TODO: explicar a estrutura e cada campo da tabela  
19 -  
20 -\begin{table}[]  
21 -\centering  
22 -\resizebox{\textwidth}{!}{%  
23 -\begin{tabular}{ | m{4cm} m{10cm} m{10cm} | }  
24 -\hline  
25 -\textbf{Decision} & \textbf{Practice Explanation} & \textbf{Benefits} \\ \hline  
26 -\textbf{Project management and communication on the developing platform itself}  
27 -&  
28 -\begin{itemize}  
29 -\item Migration of project management and communication into  
30 -the platform under development using its integrated software components Gitlab  
31 -and Mailman  
32 -\end{itemize} &  
33 -\begin{itemize}  
34 -\item Trusting developed code;  
35 -\item Communicating with transparency and efficiency;  
36 -\item Easier monitoring and increasing interactions between development team and public servants;  
37 -\item Producting organically documentation and records;  
38 -\end{itemize} \\ \hline  
39 -  
40 -\textbf{Bring together government staff and development team} &  
41 -\begin{itemize}  
42 -\item Biweekly gov staff, senior developers and coaches met to planning and  
43 -review sprint at the UnB headquarters. \item Most of features under development  
44 -were discussed on Gitlab Issue Tracker. \item Only strategic decisions or  
45 -bureaucratic issues involve board directors. \item Continuous Delivery  
46 -\end{itemize} &  
47 -\begin{itemize}  
48 -\item Reducing communication misunderstood and better meeting expectations of both sides;  
49 -\item Overcoming the government bias regarding low productivity of collaboration with academia;  
50 -\item Aligning both activities execution pace;  
51 -\item Improving the translation of the process from one side to the other;  
52 -\end{itemize} \\ \hline  
53 -  
54 -\textbf{Split development team into priority work fronts with IT market specialists} &  
55 -\begin{itemize}  
56 -\item The development was divided into four fronts (DevOps / UX / Noosfero / Colab) with a certain self-organization of tasks.  
57 -\item IT market professionals with recognized experience on each front were hired to work in person or remotely.  
58 -\item For each front, there was at least one senior developer and the role of coach.  
59 -\item The meta-coach role was also defined to coordinate tasks between teams.  
60 -\end{itemize} &  
61 -\begin{itemize}  
62 -\item Helping to reconciliate development processes and decision-making;  
63 -\item Creating support-points for students, senior developers, and gov staff;  
64 -\item Transfering of knowledge from industry and FLOSS community to both academia and government;  
65 -\end{itemize}\\ \hline  
66 -\end{tabular}%  
67 -}  
68 -\caption{Empirical SPB management method and its benefits}  
69 -\label{practices-table}  
70 -\end{table} 15 +second phase and show the benefits generated by its deployment.
71 16
72 \subsection{Project management and communication on the developing platform 17 \subsection{Project management and communication on the developing platform
73 itself} 18 itself}
@@ -96,13 +41,11 @@ know something, could go there and look at what was happening''}. @@ -96,13 +41,11 @@ know something, could go there and look at what was happening''}.
96 Migrating to SPB platform also provided an \textbf{easier monitoring and 41 Migrating to SPB platform also provided an \textbf{easier monitoring and
97 increase interactions between development team and public servants by 42 increase interactions between development team and public servants by
98 coordinators}. As shown by collected data, in the last 15 months of the project, 43 coordinators}. As shown by collected data, in the last 15 months of the project,
99 -775 issues and 4,658 issue comments was registered in the main repository  
100 -(without considering the software repositories that integrated the platform)  
101 -within the SPB platform. The issues have 59 different authors (8 from MPOG  
102 -staff), and commented by 64 different users (9 form MPOG staff and users). 44 +the issues have 59 different authors (8 from MPOG
  45 +staff), and commented by 64 different users (9 from MPOG staff and users).
103 Considering issues with higher level of interaction those that have 10 or more 46 Considering issues with higher level of interaction those that have 10 or more
104 -comments, in a set of 84 issues, MPOG staff authored 36 issues (which represents  
105 -about 43\% of these most active issues). A MPOG analyst highlighted that 47 +comments, in a set of 102 issues, MPOG staff authored 43 issues (which represents
  48 +42\% of these most active issues). A MPOG analyst highlighted that
106 \textit{``there was a lot of evolution, a lot of communication via Gitlab''}. 49 \textit{``there was a lot of evolution, a lot of communication via Gitlab''}.
107 This interaction also led MPOG staff to \textbf{trust developed code}: 50 This interaction also led MPOG staff to \textbf{trust developed code}:
108 \textit{``Everything was validated, we tested the features and the project was 51 \textit{``Everything was validated, we tested the features and the project was
@@ -220,3 +163,4 @@ for this was that the coaches were more likely to meet the requirements, to @@ -220,3 +163,4 @@ for this was that the coaches were more likely to meet the requirements, to
220 ask questions about requirements, to understand some features. interaction with 163 ask questions about requirements, to understand some features. interaction with
221 leaders than with senior developers. Sometimes the coaches brought the question 164 leaders than with senior developers. Sometimes the coaches brought the question
222 to the senior developers''}. 165 to the senior developers''}.
  166 +
icse2018/content/06-discussion.tex
  Diff comments   View file @7993fa1
@@ -4,15 +4,13 @@ @@ -4,15 +4,13 @@
4 In this paper we examined the empirical model built in a collaborative project 4 In this paper we examined the empirical model built in a collaborative project
5 between government and academia that successfully harmonized the differences in 5 between government and academia that successfully harmonized the differences in
6 the common approaches to software development management used by each side. We 6 the common approaches to software development management used by each side. We
7 -mapped the key decisions made over the 30-months of the project, that aimed to  
8 -improve communication and the development process as a whole. We also elaborated  
9 -two surveys and one interviews that were conducted separately for three groups  
10 -of participants. We obtained a total of responses of 37 undergraduated  
11 -students, eight IT market professionals, and two government officials. Finally,  
12 -we collected post-mortem public data on project management carried out on the  
13 -platform itself. The results revealed nine practices were developed from three  
14 -main decisions taken and 11 benefits were obtained with the adoption of these  
15 -practices. 7 +mapped the key decisions made over the 30-months of the project, that aimed at
  8 +improvement of the communication and the development process as a whole. We also elaborated
  9 +two surveys and one interview that were conducted separately for three groups
  10 +of participants. We obtained a total of 47 respondents: 37 interns, eight IT market professionals, and two government officials. Finally,
  11 +we collected \textit{post-mortem} public data on project management carried out on the
  12 +platform itself. The results revealed that nine practices were developed from three
  13 +key decisions taken, and these practices brought 11 benefits, as summarized in the Table \ref{practices-table}.
16 14
17 \begin{table}[] 15 \begin{table}[]
18 \centering 16 \centering
@@ -66,57 +64,26 @@ bureaucratic issues involve board directors. \item Continuous Delivery @@ -66,57 +64,26 @@ bureaucratic issues involve board directors. \item Continuous Delivery
66 \label{practices-table} 64 \label{practices-table}
67 \end{table} 65 \end{table}
68 66
69 -...summarized in the Table \ref{practices-table} ... 67 +\textbf{RQ1.}\textit{What practices based on open source development experiences would
  68 +help to combine teams with different management processes in a
  69 +government-academia collaboration project?}
70 70
71 -\todo{Responder questões de pesquisa} 71 +We mapped nine practices to reconcile the differences between government and academia in a collaborative project. These practices cover aspects from communication of the project to the delivery process of developed code, as presented in the second column of the table above (Practice Explanation).
72 72
  73 +\textbf{RQ2.}\textit{How do open source development practices benefit the process of
  74 +developing an e-government platform in a government-academia collaboration?}
73 75
74 -In our previous work \cite {meirelles2017spb}, we presented the unprecedent  
75 -platform developed in the case study project and seven lessons learned taking into account only the  
76 -academia-side view. The new results acquired in the current work corroborate  
77 -with these lessons, adding the point of view of the government and the academia  
78 -in diverse performed levels. In addition, these results suggest that many free  
79 -software development practices can be replicated in other contexts in which the  
80 -diversity and plurality of its stakeholders need to be leveled and reconciled. 76 +The results of the surveys revealed the benefits of implementing each set of practices for the case study. The third column of the table (Benefits) shows how the practices adopted impacted on the relationship between members from both sides, on the understanding of project development process, and on the appropriation of the developed platform.
81 77
82 -% How to involve students real-world projects, interacting with real customers  
83 -%The participation of experienced professionals is crucial to succcess of the project}  
84 -%A balanced relationship between academia and industry}  
85 -%Managing different organizational cultures}  
86 -%Manage higher-level and lower-level goals separately}  
87 -%Living will ill-advised political decisions}  
88 -%Consider sustainability from the beginning} 78 +The new evidences corroborate with the lessons learned and reported in our previous work \cite{meirelles2017spb}, adding the point of view of the government and the academia in diverse performed levels. Moreover, our results suggest that many open source practices could be replicated in different contexts in which the diversity and plurality of its stakeholders need to be leveled and reconciled.
89 79
90 -The results obtained also showed questions that were not overcome during the  
91 -project and which we believe need to be evaluated for future collaborations  
92 -between government and academia for software development:  
93 -\begin {itemize}  
94 -\item Improving understanding about collaboration: \textit{"During development,  
95 -we realized that the development team also felt like the owner of the project,  
96 -not just a mere executor. partnership, then it had a lot of that team issue to  
97 -suggest things to be put into the project. It was not a customer relationship it  
98 -was a partnership relationship, so there was a lot of issue suggesting by the  
99 -team to be put into the project"}  
100 -\item Discussion of roles and responsibilities: \textit{"Who had the power to  
101 -make a decision? There was no one, because it was a very equal relationship. The  
102 -two organs were on the same hierarchical level within the work plane. But this  
103 -does not work well, you have to leave well defined to whom the last word belongs  
104 -in the decisions, because the conflicts will always happen."}.  
105 -\item Look for a balance in the requirements definition. The responses showed  
106 -that the government felt that it was not detailed enough and the development  
107 -team felt that the requirements needed to be matured with the use.  
108 -\item Smoothing the intermediations between the different roles \textit{"When we  
109 -had the [UnB] coordinator, when we forwarded a direct question to a developer,  
110 -the coordinator responded. So that was negative, because we felt a little  
111 -coerced from talking directly to the teams"}  
112 -\end {itemize} 80 +This current work also exposed issues that were not overcome during the
  81 +project and need to be evaluated for future government-academia collaborations for software development. In the interviews, MPOG analysts reported some difficulties during the project in understanding the idea of collaboration. They said they needed time to realize that the project was not client-executor relationship, but a partnership, and both organizations were ate the same hierarchical level in the work plane. They lacked the role of decision maker in times of deadlock and in the requirements definition. Additionally, the analysts reported they sometimes felt coerced by coordinators when they tried to communicate directly with the interns.
113 82
114 -As future work, we intend to reapply in another government-academia paternship 83 +We consider limitations of this work to be the lack of traceable qualitative and quantitative records related to the first phase of the project (about the organization prior to the adoption of the practices mentioned above) and the application of surveys only after project completion, depending on the good memory of the interviewees about 30 months of the project.
  84 +
  85 +As future work, we intend to apply in another government-academia partnership
115 project the practices evidenced from this case study, and conduct 86 project the practices evidenced from this case study, and conduct
116 qualitative and quantitative research throughout its execution. We also intend to 87 qualitative and quantitative research throughout its execution. We also intend to
117 -analyze the effectiveness in adopting free software development practices to 88 +analyze the effectiveness in adopting open source practices to
118 align the demands and expectations of a G-A collaboration. 89 align the demands and expectations of a G-A collaboration.
119 -  
120 -  
121 -  
122 -