Compare View

switch
from
...
to
 
Commits (6)
Showing 9 changed files   Show diff stats
oss2018/content/00-abstract.tex
  Diff comments   View file @0e1fef6
1 1 \begin{abstract}
2 2  
3   -Government and academia can collaborate on bringing innovation and filling design-reality gaps in e-government projects. However, differences in project management methods employed by the organizations is often a challenge for collaborative works. Bearing that in mind, we investigated a 30-month government-academia partnership to find appropriate ways to get around this obstacle. From the analysis of \textit{post-mortem} data as well as the results of questionnaires and interviews with project participants, we present a set of best practices based on FLOSS and agile software development approaches that favors team management in government-academia collaborations in e-government development projects.
  3 +Government and academia can collaborate on bringing innovation and filling
  4 +design-reality gaps in e-government projects. However, differences in project
  5 +management methods employed by the organizations is often a challenge for
  6 +collaborative works. Bearing that in mind, we investigated a 30-month
  7 +government-academia partnership to find appropriate ways to get around this
  8 +obstacle. From the analysis of \textit{post-mortem} data as well as the results
  9 +of questionnaires and interviews with project participants, we present a set of
  10 +best practices based on FLOSS and agile software development approaches that
  11 +favors team management in government-academia collaborations in e-government
  12 +development projects.
4 13  
5 14 \end{abstract}
6 15  
7   -\keywords{Open Source Software, Free Software, Agile Methods, Best Practices, Project Management, E-Government.}
  16 +\keywords{Open Source Software, Free Software, Agile Methods, Best Practices,
  17 +Project Management, E-Government.}
... ...
oss2018/content/01-introduction.tex
  Diff comments   View file @0e1fef6
... ... @@ -2,40 +2,46 @@
2 2  
3 3 E-government projects differ from others due to their complexity and extension
4 4 \cite{anthopoulos2016egovernment}. They are complex because they combine
5   -construction, innovation, information \& communications technologies, politics,
6   -and social impact. Their extension, on the other hand, is related to their
  5 +development, innovation, information \& communications technologies, politics,
  6 +and social impact. They are extensive, on the other hand, regarding their
7 7 scope, target audience, organizational size, time, and the corresponding
8   -resistance to change. Government-academia collaborative projects may be treated
9   -as an alternative to create novelty for e-government projects and to meet the
10   -needs of society. This collaborative work has challenges, such as organizing
11   -the collaboration project, aligning goals, synchronizing the pace of between
12   -government and academia \cite{anthopoulos2016egovernment}, and overcoming the
13   -failure trend of e-government projects \cite{goldfinch2007pessimism}.
  8 +resistance to change. Developing an innovative e-government project that meets
  9 +the needs of society is a issue that may be addressed alternatively through
  10 +collaborative projects between government and academia. However, this
  11 +collaborative work has challenges, such as organizing the collaboration project,
  12 +aligning goals, synchronizing the pace of between government and academia, and
  13 +overcoming the failure trend of e-government projects
  14 +\cite{goldfinch2007pessimism}.
14 15  
15   -Poor project management is one of the causes of e-government projects failure
16   -\cite{anthopoulos2016egovernment} which, in turn, grows into a critical issue
17   -when government and academia combine efforts to develop an e-gov solution.
18   -Academia commonly works on cutting edge technology while the government
19   -still relies on traditional techniques. Changing the development process in
20   -large-size institutions represents an organizational disturbance with impacts
21   -on structure, culture, and management practices \cite{nerur2015challenges}. As
22   -a result, government and academia have to harmonize their view to increase
23   -the chances of success in projects with tight deadlines and short budgets.
  16 +One of the leading causes of e-government project failure is poor project
  17 +management \cite{anthopoulos2016egovernment}. In this sense, the proper
  18 +management of the collaboration project should be a relevant concern when
  19 +government and academia combine efforts to develop an e-government solution.
  20 +Academia commonly works on cutting-edge development methodologies while the
  21 +government still relies on traditional techniques. Changing the development
  22 +process of one of this large-size institutions represents an organizational
  23 +disturbance with impacts on structure, culture, and management practices \cite{nerur2015challenges}. As a result, government
  24 +and academia have to harmonize their view to increasing the chances of success
  25 +in projects with tight deadlines and short budgets.
24 26  
25   -We believe that procedures from Free/Libre and Open Source Software (FLOSS) and
26   -agile values may be an option for harmonizing different management approaches,
27   -due to the plurality of FLOSS ecosystems and the diversity favored by agile
28   -methodologies. Open communication, project modularity, the community of users,
29   -and fast response to problems are just a few of the FLOSS ecosystem practices
30   -\cite{capiluppi, warsta}. Individuals and interactions, working software,
31   -customer collaboration, responding to change \cite{beck} are the values agile
32   -development. With this in mind, FLOSS and agile practices may improve the
33   -process management and the cooperation of distinct teams.
  27 +We believe the adoption of recommended community standards from Free/Libre and
  28 +Open Source Software (FLOSS) and agile values is a possible strategy to
  29 +harmonize different management approaches, due to the plurality of FLOSS
  30 +ecosystems and the diversity favored by agile methodologies. Open communication,
  31 +project modularity, the community of users, and fast response to problems are
  32 +just a few of the FLOSS ecosystem practices \cite{capiluppi, warsta}.
  33 +Individuals and interactions, working software, customer collaboration,
  34 +responding to change \cite{beck} are the values agile development. With this in
  35 +mind, FLOSS and agile practices may improve the cooperation of distinct teams.
34 36  
35 37 In this work, we investigate the empirical method developed during 30 months of a
36 38 government-academia project that helped to harmonize the differences between
37   -both organization management cultures. We trace the best practices based on
38   -FLOSS ecosystems and agile methodology. Finally, we collect data from the
39   -project repository and survey the project participants points of view to
40   -extract a set of best practices to conduct effective government-academia
41   -collaboration.
  39 +both organization management cultures. We present both quantitative and
  40 +qualitative analyses of the benefits of FLOSS and agile practices in an
  41 +e-government project. We identify and trace the best practices based on FLOSS
  42 +ecosystems and agile methodology. We collect and analyze data from the project
  43 +repository. Finally, we conducted a survey target at projects participants to
  44 +find their perception around the set of best practices, and which of them are
  45 +effective to government-academia collaboration. In doing so, we aim to help
  46 +academia better understand key issues they will be confronted with when engaging
  47 +in a government-academia software project.
... ...
oss2018/content/02-relatedwork.tex
  Diff comments   View file @0e1fef6
1 1 \section{Related work}
2 2 \label{sec:relatedwork}
3 3  
4   -% TODO: Verificar se não vale a pena citar os fatores que o Strode descobriu.
5   -% Eu acho que deixaria a frase mais completa
6 4 Discussions on how to introduce new management methods into an organization are
7 5 present in several works. Nerur et al. recognized critical issues concerning
8 6 the migration from traditional to agile software development by comparing
... ... @@ -22,21 +20,22 @@ management of software projects. Chookittikul et al. evaluated the increasing
22 20 use of the agile techniques in software development companies in Thailand.
23 21 The authors suggested that universities should create curricula that develop
24 22 in their undergraduate students practical skills required by industry (mainly
25   -agile practices) to promote growth inlocal software businesses \cite{cho2011gap}.
26   -They report the use of Scrum in an industry-academia research consortium
27   -(involving ten industry partners and five universities in Sweden)
28   -\cite{sandberg2017iacollaboration}. Through a case study, they show that being
29   -able to unite the main activities of interest of the organizations involved is
30   -essential for the success of collaborative research between industry and
31   -academia.
  23 +agile practices) to promote growth in local software businesses
  24 +\cite{cho2011gap}. Sandberg et al. report the use of Scrum in an
  25 +industry-academia research consortium (involving ten industry partners and five
  26 +universities in Sweden) \cite{sandberg2017iacollaboration}. Through a case
  27 +study, they demonstrate that being able to bring together the meaningful
  28 +activities of the stakeholders is essential to the success of collaborative
  29 +research between industry and academia.
32 30  
33 31 Complex and large-scale organizations, such as the public administration, have
34 32 to deal with multiple project variables. Alleman et al. describe a production
35 33 deployment for the US government, focusing on the methodology applied to address
36   -long-term planning and value estimation \cite{alleman2003making}. The application of agile
37   -methods in the Brazilian public sector is approached by Melo et
38   -al. \cite{melo2013agileBr} and De Sousa et al. \cite{de2016using}, both are
39   -experiences limited to pilot projects.
  34 +long-term planning and value estimation \cite{alleman2003making}. In the
  35 +Brazilian context, Melo et al. \cite{melo2013agileBr} investigates the growing
  36 +adoption of agile methodologies in this country's IT industry. The results of
  37 +their survey highlight some mismatch that companies faces when developing
  38 +software for public administration.
40 39  
41 40 Several works tried to highlight the FLOSS practices, while others attempted to
42 41 determine the relationship between FLOSS practices and agile methods.
... ... @@ -52,4 +51,9 @@ Eric Raymond describes many of his experiences and decisions in his work with
52 51 FLOSS communities \cite{raymond}, this report has many intersections with the
53 52 agile manifesto.
54 53  
55   -This paper differs itself from others by studying the development collaboration between government and academia of a production level platform. From questionnaires, interviews, and development activities data, we extracted best practices that helped to harmonize the interactions between two different development process and satisfied the management process of both sides. We analyzed the decisions made from the FLOSS and agile perspectives.
  54 +This paper differs itself from others by studying the government-academia
  55 +collaboration for developing a production-level solution. From questionnaires,
  56 +interviews, and development activities data, we extracted best practices that
  57 +helped to harmonize the interactions between two different development process
  58 +and satisfied the management process of both sides. We analyzed the decisions
  59 +made from the FLOSS and agile perspectives.
... ...
oss2018/content/03-methods.tex
  Diff comments   View file @0e1fef6
1 1 \section{Research Design}
2 2 \label{sec:researchdesign}
3 3  
4   -% TODO (by Siqueira): Tenho a impressão de que esse parágrafo cairia bem no último parágrafo
5   -% da introdução. Pelo menos a ideia dele uma vez que resume bem o trabalho
6   -In this paper, we studied practical alternatives to harmonize different
7   -software development processes. We are interested in the relationship between
8   -government and academia from the project management perspective, without the
9   -enforcement of changing their internal processes. We present two research
10   -questions that guided our work:
  4 +In this paper, we studied practical alternatives to harmonize the software
  5 +project lifecycle when confronting different development processes from crucial
  6 +stakeholders. We are interested in the relationship between government and
  7 +academia from the project management perspective, without the enforcement of
  8 +changing their internal processes. We present two research questions that guided
  9 +our work:
11 10  
12 11 \textbf{RQ1. }\textit{How to introduce open source and agile best practices into
13 12 government-academia collaboration projects?}
... ... @@ -18,7 +17,7 @@ government-academia collaborative projects?}
18 17 To answer these questions, we use the case study as research method. We selected
19 18 as a case the evolution of the Brazilian Public Software portal (SPB)
20 19 \cite{meirelles2017spb}, a government-academia collaborative project based on
21   -FLOSS systems. To validate our answers, we picked three different points of
  20 +FLOSS systems. To validate our answers, we covered three different points of
22 21 view: developers, government agent, and data collected from the project
23 22 repository.
24 23  
... ... @@ -39,70 +38,93 @@ portal includes social networking, mailing lists, version control system, and
39 38 source code quality monitoring. All of this software is integrated using a
40 39 system-of-systems framework \cite{meirelles2017spb}.
41 40  
42   -The platform development activities happened in the Advanced Laboratory
43   -of Production, Research, and Innovation in Software Engineering (LAPPIS) at
44   -UnB. The laboratory born from a professor that is part of Brazillian FLOSS
45   -community and another one that spreads out agile values. Thus, naturally,
46   -LAPPIS embrace the best practices of both ecosystems. For this project, the
47   -laboratory had a total of 42 undergraduate interns, and two professors engaged
48   -in the development team. Finally, the project hired six senior developers with
49   -significant experience with FLOSS communities, and two designers specialized in
50   -User Experience (UX).
51   -
52   -The government team was composed of one director, one coordinator, and two IT
53   -analysts from MPOG. They were responsible for contracts and collaboration
54   -management, which means they do not produce software. The MPOG analysts had
55   -their background in traditional management approaches, such as RUP, CMMI,
56   -and PMBOK.
57   -
58   -The leaders of LAPPIS and MPOG periodically met in person to manage the project
59   -progress, discussing strategic issues and technical goals. Initially, these
60   -meetings took place at the Ministry's headquarters and, usually, only directors
61   -and professors participated. On the academic side, the management of the
62   -development teams often spent two weeks per sprint and released a new version
63   -every 4 months. During the project progress, this workflow proved to be
64   -inefficient. Conflicts between the internal management processes and
65   -differences in pace and goals of each institution were compromising the
66   -platform development.
67   -
68   -Professors, with the senior developers' collaboration, incrementally employed a
69   -set of best practices based on FLOSS and agile values for improving
70   -the project management process and reducing the conflict between government
71   -and academia. Throughout the project, the LAPPIS team built an experimental
72   -management model to harmonize the different cultures. The development leaders
73   -made decisions in a non-systematic way to promote the usage of these best
74   -practices. In this paper, we analyze and codify these decisions and its
75   -benefits.
  41 +The development of the platform took place at the Advanced Laboratory of
  42 +Production, Research, and Innovation in Software Engineering (LAPPIS/UnB) and
  43 +followed the workflow of biweekly sprints and 4-month releases. On the
  44 +managerial aspect, at the project beginning, the collaboration management and
  45 +strategic discussions happened only once a month, when Lappis leaders and MPOG
  46 +directors met in person at the ministry's headquarters. Table
  47 +\ref{gov-academia-diff-table} summarizes the organizational differences in both
  48 +involved sides.
  49 +
  50 +\vspace*{-.5cm}
  51 +
  52 +\begin{table}[h]
  53 +\centering
  54 +\def\arraystretch{1.2}
  55 +\setlength\tabcolsep{0.2cm}
  56 +\resizebox{\textwidth}{!}{%
  57 +\begin{tabular}{m{4.3cm}!{\color{white}\vrule}m{7cm}!{\color{white}\vrule}m{8cm}}
  58 +\rowcolor[HTML]{c0d6e4}
  59 +\textbf{Collaboration peaces} & \textbf{Academia} & \textbf{Goverment} \\
  60 +\rowcolor[HTML]{f2f2f2}
  61 +\textbf{Responsibilities} & Platform development activites & Contracts and collaboration management \\
  62 +\rowcolor[HTML]{fafafa}
  63 +\textbf{Team size} &
  64 +\begin{tabular}[c]{@{}l@{}} 42 undergraduate interns; \\ 2 professors; \\ 6 senior developers with significant \\ experience in FLOSS projects;\\ 2 User eXperience specialist \end{tabular} &
  65 +\begin{tabular}[c]{@{}l@{}} 1 director; \\ 1 coordinator; \\ 2 requirement analysts \end{tabular} \\
  66 +\rowcolor[HTML]{f2f2f2}
  67 +\textbf{Workplace} & LAPPIS at UnB & MPOG headquarters \\
  68 +\rowcolor[HTML]{fafafa}
  69 +\begin{tabular}[c]{@{}l@{}}\textbf{Management} \textbf{approaches}\end{tabular} & Agile methods and practices from FLOSS development & Traditional methods, such as RUP, CMMI, and PMBOK \\
  70 +\end{tabular}%
  71 +}
  72 +\caption{Differences between academia and government sides}
  73 +\label{gov-academia-diff-table}
  74 +\end{table}
  75 +
  76 +\vspace*{-1cm}
  77 +
  78 +During the project progress, this workflow proved to be inefficient. Conflicts
  79 +between the internal management processes and differences in pace and goals of
  80 +each institution were compromising the platform development. To improve the
  81 +project management process and reducing the mismatching between government and
  82 +academia, professors, with the senior developers' collaboration, incrementally
  83 +employed a set of best practices based on FLOSS and agile values. Throughout
  84 +the project, the development leaders made decisions in a non-systematic way to
  85 +promote the usage of these techniques. In this paper, we analyze and codify
  86 +these decisions and how they favored the collaboration progress.
76 87  
77 88 \subsection{Survey, Interview and Data Collection}
78 89  
79   -We divided the development team into two groups of participants according to
80   -their roles during the project: undergraduate interns and IT professionals.
81   -For each set of members, we designed an online questionnaire with topics
82   -related to (1) project organization, (2) development process, (3) communication
83   -and relationship with members, (4) acquired knowledge and (5) experience
84   -with FLOSS projects. We also interviewed two MPOG analysts who directly
85   -interacted with the development team and project development process. The
86   -interview questions had four parts: (1) Professional profile;(2) Organization,
87   -communication and development methodologies (3) Satisfaction with the developed
88   -platform; (4) Lessons learned.
89   -
90   -We sent the online questionnaire to 42 interns and 8 IT professionals. All
91   -interns worked as a developer and received a scholarship. We got a total of 37
92   -interns responses, and all professionals joined on it. On average, interns had
93   -22 years and professionals had 30 years, wherein 8\% and 13\% respectively were
94   -women. About 43\% of the interns had the SPB project as their first contact
95   -with FLOSS. On average, the IT professionals had 11 years of experience, worked
96   -in at least 5 different companies, participated in 4 to 80 distinct projects,
97   -and 86\% of them had some background with FLOSS before the SPB project.
98   -
99   -We also interviewed two MPOG analysts separately. Each interview took an
100   -average of 2 hours with 28 open questions. They are over 30 years old, and they
101   -have more than 7 years working in the government. The analysts said that SPB
102   -project represented their first experience of government-academia
103   -collaboration.
104   -
105   -Finally, we analyzed the data from the principal project repository considering
  90 +We separated the project team into three groups: undergraduate interns, senior
  91 +developers, and MPOG analysts. For the first two we sent online questionnaires,
  92 +and for the last one, we conducted 2-hour interviews. Table \ref{survey-table}
  93 +presents the details of these processes.
  94 +
  95 +\vspace*{-.5cm}
  96 +
  97 +\begin{table}[h]
  98 +\centering
  99 +\def\arraystretch{1.2}
  100 +\setlength\tabcolsep{0.2cm}
  101 +\resizebox{\textwidth}{!}{%
  102 +\begin{tabular}{m{4cm}!{\color{white}\vrule}m{5cm}!{\color{white}\vrule}m{6cm}!{\color{white}\vrule}m{6cm}}
  103 +\rowcolor[HTML]{c6b3df}
  104 +\textbf{} & \textbf{\nohyphens{Undergraduate Interns}} & \textbf{Senior Developers} & \textbf{MPOG Analysts} \\
  105 +\rowcolor[HTML]{fafafa}
  106 +\textbf{Research technique} & Online questionnaire & Online questionnaire & Interview \\
  107 +\rowcolor[HTML]{f2f2f2}
  108 +\textbf{Discussed topics} & \multicolumn{2}{l!{\color{white}\vrule}}{\begin{tabular}[c]{@{}l@{}}(1) project organization,\\ (2) the development process,\\ (3) communication and relationship with members,\\ (4) knowledge sharing\\ (5) experience with FLOSS projects\end{tabular}} & \begin{tabular}[c]{@{}l@{}}(1) professional profile;\\ (2) organization, communication \\ and development methodologies;\\ (3) satisfaction with \\ the developed platform;\\ (4) lessons learned\end{tabular} \\
  109 +\rowcolor[HTML]{fafafa}
  110 +\textbf{Number of interviewed} & 42 & 8 & 2 \\
  111 +\rowcolor[HTML]{f2f2f2}
  112 +\textbf{Rate of responses} & 88\% (37) & 100\% & 100\% \\
  113 +\rowcolor[HTML]{fafafa}
  114 +\textbf{Average age at the end of the project} & 22 years old & 30 years old & more than 30 years \\
  115 +\rowcolor[HTML]{f2f2f2}
  116 +\textbf{Gender} & \begin{tabular}[c]{@{}l@{}}8\% women \\ 92\% man\end{tabular} & \begin{tabular}[c]{@{}l@{}}13\% women \\ 87\% man\end{tabular} & 100\% women \\
  117 +\rowcolor[HTML]{fafafa}
  118 +\begin{tabular}[c]{@{}l@{}}\textbf{Experience} \\ \textbf{background}\end{tabular} & 43\% of the interns had the SPB project as their first contact with FLOSS & 11 years of experience; worked in at least 5 companies; participated in 4 to 80 distinct projects; 86\%of them had some background with FLOSS before the SPB project & more than 7 years working in the government; SPB project represented their first experience of government-academia collaboration \\
  119 +\end{tabular}%
  120 +}
  121 +\caption{Surveying the project participants}
  122 +\label{survey-table}
  123 +\end{table}
  124 +
  125 +\vspace*{-1cm}
  126 +
  127 +Finally, we analyzed the data from the central project repository considering
106 128 all the issues and commits. From April 2015 to June 2016, 59 distinct authors
107 129 opened 879 issues, 64 different users made the total of 4,658 comments. The
108   -development team made 3,256 commits in the central project repository.
  130 +development team made 3,256 commits in this abovementioned repository.
... ...
oss2018/content/04-results.tex
  Diff comments   View file @0e1fef6
... ... @@ -9,34 +9,27 @@ private channels, such as professional e-mails, personal meetings, and
9 9 telephone calls. Therefore, the quantitative data found for this period
10 10 are not conclusive or have little expressiveness, and we do not examine them.
11 11  
12   -The second phase, from April 2015 to the end of the project (June 2016), has a
13   -more considerable wealth of data. Much of the management and communication
14   -activities were recorded and published on online channels and tools. During
15   -this period, several FLOSS practices and agile values were applied to the
16   -development process to harmonize the cultural and organizational divergences of
17   -the institutions involved. At the end of the project, an empirical approach to
18   -communication and management was built using the development leaders'
19   -experiences in FLOSS and agile projects to cater to government bureaucracies.
20   -
21   -In this section, we list the macro-decisions taken during the project and the
22   -practices that made these decisions concrete. We use data collected from the
23   -central repository to map best practices and, with the respondents' answers, we
24   -analyzed how each decision benefited the project collaboration.
25   -
26   -The development team decided to \textbf{use of the system under development to
27   -develop the system itself}. The team released the first version of the new SPB
28   -portal nine months after the project beginning. Due to the platform features
29   -for software development and social network, the development coordinators decided to
30   -use the platform under construction to develop the system itself. Gradually, in
31   -addition to development activities, government and academia migrated the
32   -project management and the communication between teams to the portal
33   -environment. In short, the wiki feature was used for logging meetings, defining
  12 +The second phase, from April 2015 to the end of the project (June 2016), has
  13 +meaningful data. Much of the management and communication activities were
  14 +recorded and published on online channels and tools. During this period, the
  15 +development leaders' employed several FLOSS practices and agile values in the
  16 +development process. At the end of the project, the academic team had an
  17 +empirical management approach for meeting the government bureaucracies.
  18 +
  19 +\subsection{Use of the system under development to develop the system itself}
  20 +
  21 +Due to the platform features for software development and
  22 +social network, the development coordinators decided to use the platform under
  23 +construction to develop the system itself. Gradually, in addition to development
  24 +activities, government and academia migrated the project management and the
  25 +communication between teams to the portal environment.
  26 +
  27 +In short, the wiki feature was used for logging meetings, defining
34 28 goals, planning sprints, documenting deployment procedures and user guides. The
35 29 issue tracker was used for discussing requirements, monitoring features under
36 30 development, requesting and recording changes, and validating the delivered
37   -functionalities. Finally, the mailing list was used by the entire team for
38   -collaborative construction of requirements, defining schedules, and scheduling
39   -meetings between institutions.
  31 +functionalities. Finally, the mailing list was used for collaborative construction
  32 +of requirements, defining schedules, and scheduling meetings between institutions.
40 33  
41 34 Our surveys report Mailing list (100\%) and Issue Tracker (62.5\%) as the main
42 35 means of interaction between senior developers and interns. Developers and MPOG
... ... @@ -46,41 +39,41 @@ staff also interacted mostly via Mailing List (87.5\%) and Issue tracker
46 39 that \textit{``Communicating well goes far beyond the speed. It means enabling
47 40 someone to tell everyone about everything that is happening in the project. We
48 41 did not use emails, we use more mailing list and avoid emails. This usage
49   -helped us a lot because everything was public and did not pollute our email
50   -box. So, when you wanted to know something, you could access the SPB list to
51   -see everything that was happening.''}.
  42 +helped us considerably. Everything was public and did not pollute our email
  43 +box. So, when you wanted to know something, you could access the SPB list and
  44 +see everything''}.
52 45  
53 46 Migrating to the SPB platform also \textbf{easied monitoring of activities and
54 47 increased interactions between developers and public servants}. The data
55   -collected from the repository evidence the frequent use of the platform by the
56   -academic and the government teams. In the last 15 months of the project, the
57   -central repository issues were opened by 59 different authors, 8 of them MPOG
58   -agents. These issues received comments from 64 distinct users, 9 of them from
59   -MPOG. When we consider the issues with much interaction, those who had ten
60   -comments or more, we notice that the government team also felt comfortable with
  48 +collected from the repository highlight the frequent use of the platform by both
  49 +sides teams. In the last 15 months of the project, 59 different authors opened the
  50 +central repository issues, 8 of them were MPOG agents. These issues received comments
  51 +from 64 distinct users, 9 of them from MPOG. When we consider the issues with more interactions, those which had ten
  52 +comments or more, we notice that the government team also felt comfortable in
61 53 using the tool to interact directly with the development team. In a set of 102
62   -issues with much interaction, MPOG staff created 43 of them (this represents
63   -42\% of the most active issues). For the MPOG analysts, interaction via
64   -repository improved communication. \textit{``There was a lot of evolution, a
65   -lot of communication via Gitlab.''}. Migrating to the platform also led MPOG
  54 +active issues, MPOG staff created 43 of them (this represents 42\% of the most active issues).
  55 +
  56 +For the MPOG analysts, interaction via
  57 +repository improved communication. \textit{``There was a big evolution, we
  58 +increased our communication via Gitlab''}. Migrating to the platform also led MPOG
66 59 staff to \textbf{trust the developed code}: \textit{``Everything was validated.
67 60 We tested the functionalities and developed the project on the SPB platform
68   -itself. Consequently, the use of the system validated most of the features.
69   -From the moment we began to use it for development, this validation was
70   -constant. We felt confident in the code developed.''}.
  61 +itself. Hence, the use of the system homologated most of its features. From the
  62 +moment we began to use it for developing, this validation was constant. We felt
  63 +confident in the code produced''}.
71 64  
72 65 The abovementioned decision also collaborated to meet the government's demand
73 66 for meticulous documentation of the software design and stages of development
74   -without bureaucratizing or modifying the development process. The team started
75   -to \textbf{produce documentation and records organically} on the platform
76   -itself, as mentioned in one of the MPOG responses: \textit{``For me, it was a
77   -great learning experience. There are a lot of things documented in emails as
78   -well as in the portal itself. When necessary, we can access the tools and find
79   -out how we develop a solution. We can recover these positive points.''}.
  67 +without bureaucratizing or modifying the development process. The usage of the
  68 +platform for project team management conducted \textbf{the organic production
  69 +of documentation and records}, as mentioned in one of the MPOG responses: \textit{``It was a great
  70 +learning experience. There are many things documented in emails as well as
  71 +in the portal itself. We can access the tools at any time and find out how we
  72 +develop a solution. We can remember the positive project points''}.
80 73  
  74 +\subsection{Brings together government staff and development team}
81 75  
82   -The development coordinators worked to \textbf{brings together government staff
83   -and development team}. At the beginning of the project, the interviewed MPOG
  76 +In the first phase of the project, the interviewed MPOG
84 77 analysts did not participate in any direct interaction with any university
85 78 representative, even though they were the ones in charge of the government in
86 79 ensuring the collaboration agreement and the delivery of the products. Because
... ... @@ -89,70 +82,70 @@ meetings. They reported that there was significant communication noise in the
89 82 internal dialogues with their superiors, as well as between their superiors and
90 83 the development team.
91 84  
92   -In the second phase of the project, these analysts came to represent the
93   -government directly in the dialogues with the academia, and they started to
94   -visit bi-weekly the university's laboratory. One of the analysts believed that
95   -\textit{``at this point, the communication started to change.''}. The new
96   -dynamic \textit{reduced communication misunderstandings and unified the two
  85 +In the second phase of the project, these analysts became direct representatives
  86 +of the government and started to visit the university's laboratory bi-weekly.
  87 +One of the analysts believed that
  88 +\textit{``at this point, the communication started to change''}. The new
  89 +dynamics \textit{reduced communication misunderstandings and unified both
97 90 sides}, as reported by another interviewee: \textit{``It was very positive. We
98 91 liked to go there and to interact with the team. I think it brought more unity,
99   -more integration into the project.''}. {73\%} of the interns considered positive
  92 +more integration into the project''}. {73\%} of the interns considered positive
100 93 the direct participation of the MPOG staff, and {81\%} of them believed the
101 94 presence of government staff in sprint ceremonies was relevant for the project
102 95 development. For 76\% of the interns, writing the requirements together with the
103 96 MPOG staff was very important to \textbf{better meet expectations of both
104 97 sides}. According to one of them, \textit{``Joint planning and timely meetings
105   -were very important for understanding the needs of MPOG.''}.
  98 +were very important for understanding the needs of MPOG''}.
106 99  
107 100 The closest dialogue between government and academia generated empathy, as
108 101 reported by one of the interviewees: \textit{``Knowing people in person makes a
109 102 big difference in the relationship because it causes empathy. You know who that
110   -person is, it's not simply a name.''}. This point helped to \textbf{synchronize
111   -the execution pace of activities}: \textit{``When we visited the lab and met
112   -the team, we realized that this encouraged us to validate resources faster and
113   -give faster feedback to the team. In return, they also quickly answered us any
114   -question.''}.
  103 +person is. He's not merly a name''}. Consequently, this empathy helped to \textbf{synchronize
  104 +the execution pace of activities}: \textit{``Visiting the lab and meeting
  105 +the developers encouraged us to validate resources faster and give faster feedback to
  106 +the team. In return, they also quickly answered us any question''}.
115 107  
116 108 The implementation of a Continuous Delivery pipeline also reinforced the teams'
117 109 synchronization \cite{siqueira2018cd} . For 81\% of the interns and 75\% of the senior
118 110 developers, deploying new versions of the SPB portal in production was a
119 111 motivator during the project. On the government side, this approach helped to
120   -\textbf{overcome the government bias regarding the low productivity of
  112 +\textbf{overcome the government bias toward low productivity of
121 113 collaborative projects with academia}, as mentioned by themselves:
122 114 \textit{``Government staff has a bias that universities do not deliver
123 115 products. However, in this project, we made many deliveries with high quality.
124   -Nowadays I think if we had paid the same amount for a company, it would not
125   -have done what we did with the quality we delivered.''}. Additionally, the
126   -deployment of each new version also \textbf{improve the translation of the
  116 +Nowadays, I think if we had paid the same amount for a company, it would not
  117 +have done the amount of features we did with the technical quality we have''}. Additionally, the
  118 +deployment of each new version also \textbf{share a common understanding of the
127 119 process from one side to the other}, as mentioned by a MPOG analyst: \textit{``We
128   -had a strategic level view. When we went to the technical level, we had
129   -difficulty to plan each four-month release. However, in the final stages of the
130   -project, I realized that this was not a problem because the team made the
131   -deliveries and the results were available in production. The team was
132   -qualified, the code had quality, and the project was well executed. So in
133   -practice, our difficulty interpreting the technical details did not impact
134   -release planning.''}.
135   -
136   -The project leaders \textbf{divided the development team into priority fronts,
137   -and for each one, hire at least one specialist from the IT market}. The
138   -development team had four work areas divided by the main demands of the
  120 +had only the strategic vision of the project. When we needed to deal with
  121 +technical issues, we had some difficulty planning the four-month releases.
  122 +However, in the last stages of the project I realized that this was not a
  123 +problem. The team was delivering and the results were available in production.
  124 +The team was qualified, the code had quality, and the project was well executed.
  125 +So in practice, our difficulty in interpreting the technical details did not
  126 +impact the release planning''}.
  127 +
  128 +\subsection{Organized development team into priority fronts, and for each one, hire at least one specialist from the IT market}
  129 +
  130 +The development team had four work areas divided by the main demands of the
139 131 project: User Experience, DevOps, Integration of Systems, and Social
140   -Networking. For each of them, at least one professional in the IT market was
141   -hired to raise the quality of the product. Senior developers have a vast
142   -experience in the FLOSS systems and tools used in the project.
  132 +Networking. For each segment, at least one professional in the IT market was
  133 +hired to raise the quality of the product. Senior developers have been selected
  134 +based on their vast experience in FLOSS systems and their knowledge on tools
  135 +used in the project.
143 136  
144   -The participation of senior developers in the project contributed to
  137 +The presence of senior developers in the project contributed to
145 138 \textbf{conciliate the development processes of each institution and make
146 139 better technical decisions}, as quoted in one of the answers to the senior
147 140 developer's questionnaire: \textit{``I think my main contribution was to
148   -balance the relations between the MPOG staff and the university team.''}. {63\%} of
  141 +balance the relations between the MPOG staff and the university team''}. {63\%} of
149 142 the senior developers believed they have collaborated to conciliate the management
150   -and development process between the two institutions and also {63\%} of them
151   -that they helped MPOG staff to express their requests more clearly. Government
  143 +and development process between the two institutions and also {63\%} of them
  144 +helped MPOG staff express their requests more clearly. Government
152 145 analysts were also more open to suggestions from these developers:
153   -\textit{``They are developers of the upstream projects of the systems that
  146 +\textit{``They are upstream developers of the systems that
154 147 integrate the platform. They conveyed trust, and then we trust in the developed
155   -code.''}. According to questionnaire responses, they largely agreed with the
  148 +code''}. According to questionnaire responses, senior developers largely agreed with the
156 149 project development process. For 63\%, this process has close similarity to
157 150 their previous experiences. In contrast, {62.5\%} of them did not understand
158 151 the MPOG's project management process and {50\%} believed this process could
... ... @@ -161,19 +154,19 @@ affect their project productivity.
161 154 The senior developers were also responsible for \textbf{improving the management
162 155 and technical knowledge} of the interns about practices from industry and open
163 156 source projects. {91\%} of the interns believed that working with professionals
164   -was essential for learning. Working with senior developers was important during
165   -the project for all of them. {75\%} of the senior developers believed that ``Working
  157 +was essential for learning, and, for all of them, working with senior developers
  158 +was important during the project. {75\%} of the senior developers believed that ``Working
166 159 in pairs with a senior'' and 63\% that ``Participate in joint review tasks''
167 160 were the tasks with the involvement of them that most contributed to the
168 161 evolution of university interns in the project. {75\%} believed that the knowledge
169   -taught by them to a intern was widespread among the others in the team.
170   -Government analysts also pointed this acquisition of knowledge: \textit{``On
171   -the side of the universities, what we noticed was a significant improvement in the platform
172   -with the hiring of the original developers of the systems. They had a guide on
  162 +shared by them to one intern was widespread among the others in the team.
  163 +Government analysts also pointed this knowledge sharing: \textit{``On
  164 +the university side, we noticed a significant improvement in the platform
  165 +with the hiring of the systems original developers. They had a guide on
173 166 how to best develop each feature and were able to solve non-trivial problems
174   -quickly.''}.
  167 +quickly''}.
175 168  
176   -Dividing the development team and hiring senior developers allowed each team to
  169 +Organizing the development team and hiring senior developers allowed each team to
177 170 \textbf{self-organize and gain more autonomy in the management of their tasks}.
178 171 There was a development coach to lead each team, and a ``meta-coach'' supported
179 172 all of them in their internal management activities. The coaches (most advanced
... ... @@ -184,8 +177,5 @@ interaction with the team. MPOG analysts saw coaches as facilitators their
184 177 activities and communication with the development team. They said \textit{``I
185 178 interacted more with the project coordinator (professor) and team coaches''},
186 179 \textit{``Usually, we contact a coach to clarify some requirements or to
187   -understand some feature. We interact more with coaches because they are more
188   -accessible than senior developers. Sometimes the coach would take our question
189   -to the senior developer.''}.
190   -
191   -%TODO: talvez encaixar aqui a troca de papéis
  180 +understand some feature. The coaches were more available than senior
  181 +developers and, sometimes, they would take our question to a senior developer''}.
... ...
oss2018/content/05-discussion.tex
  Diff comments   View file @0e1fef6
1 1 \section{Discussion}
2 2 \label{sec:discussion}
3 3  
4   -Organizational culture is built and reinforced every life year of a large-size
5   -organization. These cultural values reflect on the internal management
6   -processes and the norms of communication among its members. In the context of
7   -software development projects, each institution adopts development methods that
8   -best meet its managerial procedures and organizational routines. When two
9   -large-size organizations decide to develop a solution collaboratively, the
10   -development methods and workflow of one may conflict with the interests of the
11   -other. In a case of government-academia collaboration, conciliating their
12   -different management processes is crucial, since the poor and unadaptable
13   -management could lead the project to fail, resulting in the waste of
14   -population-funded resources.
  4 +Our results reveal a set of nine management practices successfully employed in
  5 +abovementioned case. We analyzed unsystematic decisions made during a 30-month
  6 +collaborative project and identified three macro-decisions that harmonized the
  7 +differences of the management processes of each organization. We evidenced from
  8 +data collection, and responses of the members of both sides to the
  9 +questionnaires and interviews, the benefits obtained through the adoption of
  10 +this empirical method. The Table \ref{practices-table} summarizes
  11 +macro-decisions, practices, and benefits.
15 12  
16   -\begin{table}[hbt]
  13 +\vspace*{-.5cm}
  14 +
  15 +\begin{table}[h]
17 16 \centering
  17 +\def\arraystretch{1.5}
  18 +\setlength\tabcolsep{0.5cm}
18 19 \resizebox{\textwidth}{!}{%
19   -\begin{tabular}{ | m{4cm} m{10cm} m{10cm} | }
20   -\hline
21   -\textbf{Decision} & \textbf{Practice Explanation} & \textbf{Benefits} \\ \hline
22   -\textbf{Use of the system under development to develop the system itself} &
  20 +\begin{tabular}{ m{4cm} m{9cm} m{9cm} }
  21 +\rowcolor[HTML]{b7d0b9}
  22 +\textbf{Decision} & \textbf{Practice Explanation} & \textbf{Benefits} \\
  23 +\rowcolor[HTML]{fafafa}
  24 +\begin{flushleft}
  25 +\textbf{Use of the system under development to develop the system itself}
  26 +\end{flushleft} &
  27 +\begin{flushleft}
23 28 \begin{itemize}
  29 +\setlength{\itemsep}{2pt}
24 30 \item The features and tools of the platform under development supported the project management and communication activities.
25   -\end{itemize} &
  31 +\end{itemize}
  32 +\end{flushleft} &
  33 +\begin{flushleft}
26 34 \begin{itemize}
  35 +\setlength{\itemsep}{2pt}
27 36 \item Communicating with transparency and efficiency;
28 37 \item Monitoring of activities;
29 38 \item More interactions between developers and public servants;
30 39 \item Trust the developed code;
31 40 \item Organic documentation;
32   -\end{itemize} \\ \hline
33   -
34   -\textbf{Bring together government staff and development team} &
35   -\begin{itemize}
  41 +\end{itemize}
  42 +\end{flushleft} \\
  43 +\rowcolor[HTML]{f2f2f2}
  44 +\begin{flushleft}
  45 +\textbf{Bring together government staff and development team}
  46 +\end{flushleft} &
  47 +\begin{flushleft}
  48 +\begin{itemize}
  49 +\setlength{\itemsep}{2pt}
36 50 \item Government staff, academic coordinators, senior developers and team coaches biweekly meet at the university lab, academia headquarters, for sprint planning and review.
37   -\item Conduct on the platform the technical discussions between government staff and the development team.
  51 +\item Conducte on the platform technical discussions between government staff and the development team.
38 52 \item Involve government board directors only in strategic planning of the project.
39   -\item Build a continuous delivery pipeline with steps involving both sides.
40   -\end{itemize} &
  53 +\item Build a continuous delivery pipeline with stages involving both sides.
  54 +\end{itemize} \end{flushleft} &
  55 +\begin{flushleft}
41 56 \begin{itemize}
  57 +\setlength{\itemsep}{2pt}
42 58 \item Reducing communication misunderstanding;
43 59 \item Better meeting expectations of both sides;
44   -\item Improvement of decision-making process;
  60 +\item Improvement of the decision-making process;
45 61 \item Overcoming the government bias regarding low productivity of collaborative projects with academia;
46 62 \item Synchronizing the execution pace of activities;
47   -\item Improve the translation of the process from one side to the other.
48   -\end{itemize} \\ \hline
49   -
50   -\textbf{Divide the development team into priority fronts, and for each one, hire at least one specialist from the IT market} &
  63 +\item Sharing a common understanding of the process from one side to the other.
  64 +\end{itemize} \end{flushleft} \\
  65 +\rowcolor[HTML]{fafafa}
  66 +\begin{flushleft}
  67 +\textbf{Organize the development team into priority fronts, and for each one, hire at least one specialist from the IT market}
  68 +\end{flushleft} &
51 69 \begin{itemize}
  70 +\setlength{\itemsep}{2pt}
52 71 \item The coordinators separated the development team into priority work areas considering the main demands of the project.
53 72 \item IT market professionals with recognized experience on each front were hired to work in person or remotely.
54 73 \item Define among the interns the leadership roles: a coach for each front, and a meta-coach of the entire development team.
55 74 \item Each team has certain self-organization, being guided by one intern-coach and at least one senior developer.
56 75 \end{itemize} &
57 76 \begin{itemize}
  77 +\setlength{\itemsep}{2pt}
58 78 \item Conciliating the development processes of each institution, taking better technical decisions;
59 79 \item Improving the management and technical knowledge;
60 80 \item Self-organizing and gaining autonomy in the management of their tasks.
61   -\end{itemize}\\ \hline
  81 +\end{itemize}\\
62 82 \end{tabular}%
63 83 }
64 84 \caption{Empirical SPB management decisions and its benefits.}
65 85 \label{practices-table}
66 86 \end{table}
67 87  
68   -\vspace{-.9cm}
69   -
70   -We investigated the management method employed at the SPB portal project, a
71   -partnership between the Brazilian government and universities. The development
72   -leaders empirically built an approach using FLOSS and agile development
73   -practices and values. As a result, we identified a set of best practices which
74   -improves the workflow and relationship between the organizations involved. Our
75   -results reveal a set of nine management practices successfully employed in
76   -abovementioned case. We analyzed unsystematic decisions made during a 30-month
77   -collaborative project and identified three macro-decisions that harmonized the
78   -differences of the management processes of each organization. We evidenced from
79   -data collection, and responses of the members of both sides to the
80   -questionnaires and interviews, the benefits obtained through the adoption of
81   -this empirical method. The Table \ref{practices-table} summarizes
82   -macro-decisions, practices, and benefits.
83   -
84   -Regarding our first research question \textit{``How to introduce open source and
85   -agile best practices into government-academia collaboration projects?''}, we
86   -examined the SPB project and identified three macro-decisions taken by the
87   -academic coordinators that led them to intuitively and non-systematically adopt
88   -FLOSS and agile practices in the development process. We extracted nine best
89   -management practices and verified their efficient use collecting data from the
90   -management tool and interviewing the project participants.
91   -
92   -The interviewed responses allowed us to understand how FLOSS and agile
93   -practices have benefited the people and project management. Based on that, we
94   -answered our second research question \textit{``What practices favor
95   -effective team management in government-academia collaborative projects?''},
96   -making to explicit in Table \ref{practices-table} eleven benefits obtained from
97   -the use of the nine best practices.
  88 +\vspace*{-1cm}
98 89  
99 90 The results of this current work corroborate the lessons learned in our
100 91 previous work on studying the SPB project case \cite{meirelles2017spb}.
101 92 Evidence from the data collected, responses to questionnaires, and interviews
102 93 reinforce what has been reported by the academic coordination of the project,
103 94 adding the point of views of government and other roles involved on the
104   -academic side. In short, the government staff had difficulty to understand how
105   -collaboration works. They took time to realize that the project was not a
106   -client-executor relationship and that both organizations were at the same
107   -hierarchical level in the work plan. Finally, they also felt the project needed
108   -a decision-maker role to resolve impasses between organizations, and the
109   -development coordinators sometimes took on that.
  95 +academic side. In short, the government staff took time to understand how
  96 +collaboration works and to realize that the project was not a client-executor
  97 +relationship and both organizations were at the same hierarchical level
  98 +in the work plan.
110 99  
111 100 The decisions, practices, and benefits presented in the Table
112 101 \ref{practices-table} should be evaluated and used in contexts with more
113   -substantial plurality and diversity of government stakeholders. As threats to
114   -the validity of this work, we point out the lack of communication records and
  102 +substantial plurality and diversity of government stakeholders. This study has
  103 +a few obvious limitations. Firstly, we point out the lack of communication records and
115 104 low traceability of the management data referring to the first phase of the
116   -project. We also consider as a threat the hiatus between the completion of the
  105 +project. Secondly, we consider a drawback the hiatus between the completion of the
117 106 project and the conduction of interviews and questionnaires, since we rely on
118   -the memory of the interviewees to rescue the events. Furthermore, the new work
119   -experiences of the respondents after the project and their current working
120   -mindset may also modify their interpretation of the topics addressed in the
121   -questionnaire and consequently their responses.
122   -
123   -Finally, we collected a significant amount of data and testimonials related to
124   -the teaching of software engineering. We consider that the project studied is
125   -also an educational case. It is an example of how to teach information
126   -technology students FLOSS and agile approaches applied to production-level
127   -software development. As future work, we intend to analyze this collected
128   -information to propose improvements in the teaching of software engineering for
129   -undergraduates.
  107 +the memory of the interviewees to rescue the events. Lastly, the current
  108 +situation of the respondents, such as their current working midset, may also
  109 +alter their perception on the on the topics addressed in the questionnaire and
  110 +consequently their responses.
... ...
oss2018/content/06-conclusion.tex
  Diff comments   View file @0e1fef6
... ... @@ -13,32 +13,29 @@ different management processes is crucial, since the poor and unadaptable
13 13 management could lead the project to fail, resulting in the waste of
14 14 population-funded resources.
15 15  
16   -We investigated the management method employed at the SPB portal project, a
17   -partnership between the Brazilian government and universities. This approach
18   -was empirically built using FLOSS and agile development practices and values.
19   -As a result, we identified a set of best practices which improves the workflow
20   -and relationship between the organizations involved.
  16 +In this study, we investigated the management method employed at the SPB portal
  17 +project, a partnership between the Brazilian government and universities. As a
  18 +result, we identified a set of FLOSS and agile best practices, empirically
  19 +employed by development leaders, which improved the workflow and relationship
  20 +between the organizations involved.
21 21  
22   -Regarding our first research question \textit{How to introduce open source and
23   -agile best practices into government-academia collaboration project?}, we
  22 +Regarding our first research question \textit{``How to introduce open source and
  23 +agile best practices into government-academia collaboration projects?''}, we
24 24 examined the SPB project and identified three macro-decisions taken by the
25   -academic coordinators that led them to intuitively and non-systematically adopt
26   -FLOSS and agile practices in the development process. We extracted nine best
27   -management practices and verified their efficient use collecting data from the
28   -management tool and interviewing the project participants.
  25 +academic coordinators that drove them to intuitively and unsystematically adopt
  26 +nine FLOSS and agile best practices in the development process.
29 27  
30 28 The interviewed responses allowed us to understand how FLOSS and agile
31 29 practices have benefited the people and project management. Based on that, we
32   -answered our second research question \textit{What practices would favor
33   -effective team management in government-academia collaborative project?},
  30 +answered our second research question \textit{``What practices favor
  31 +effective team management in government-academia collaborative projects?''},
34 32 making to explicit in Table \ref{practices-table} eleven benefits obtained from
35   -the use of the nine best practices aforementioned.
  33 +the use of the best practices.
36 34  
37 35 Finally, we collected a significant amount of data and testimonials related to
38   -the teaching of software engineering. We consider that the project studied is
39   -also an educational case. It is an example of how to teach information
40   -technology students FLOSS and agile approaches applied to production-level
41   -software development. As future work, we intend to analyze this collected
42   -information to propose improvements in the teaching of software engineering for
43   -undergraduates.
  36 +the teaching of software engineering. We consider the project studied an
  37 +educational case, an example of teaching FLOSS and agile techniques applied to
  38 +real-world software development. As future work, we intend to analyze this collected
  39 +information to propose improvements in software engineering undergraduates
  40 +education methodology.
44 41  
... ...
oss2018/spb-oss-2018.bib
  Diff comments   View file @0e1fef6
... ... @@ -140,15 +140,6 @@
140 140 publisher={Elsevier}
141 141 }
142 142  
143   -@inproceedings{de2016using,
144   - title={Using scrum in outsourced government projects: An action research},
145   - author={de Sousa, Thatiany Lima and Venson, Elaine and da Costa Figueiredo, Rejane Maria and Kosloski, Ricardo Ajax and Junior, Luiz Carlos Miyadaira Ribeiro},
146   - booktitle={System Sciences (HICSS), 2016 49th Hawaii International Conference on},
147   - pages={5447--5456},
148   - year={2016},
149   - organization={IEEE}
150   -}
151   -
152 143 @inproceedings{melo2013agileBr,
153 144 author = {Melo, Claudia and Santos, Viviane and Katayama, Eduardo and Corbucci, Hugo and Prikladnicki, Rafael and Goldman, Alfredo and Kon, Fabio},
154 145 year = {2013},
... ...
oss2018/spb-oss-2018.tex
  Diff comments   View file @0e1fef6
1   -\documentclass{llncs}
2 1  
  2 +\documentclass{llncs}
  3 +\usepackage[table,xcdraw]{xcolor}
3 4 \usepackage{llncsdoc}
4 5 \usepackage{graphicx,url}
5 6 \usepackage[utf8]{inputenc}
6 7 \usepackage{float}
7 8 \usepackage{setspace}
8   -
  9 +\usepackage{hyphenat}
9 10 \usepackage{tabularx}
10 11 \usepackage{cite}
11 12 \usepackage{hyperref}
12 13 \usepackage{comment}
13 14 \usepackage{todonotes}
  15 +\usepackage{colortbl}
14 16 %------------------------------------------------------------------------------
15 17  
16 18 \begin{document}
... ... @@ -40,7 +42,7 @@
40 42 \input{content/03-methods}
41 43 \input{content/04-results}
42 44 \input{content/05-discussion}
43   -%\input{content/06-conclusion}
  45 +\input{content/06-conclusion}
44 46  
45 47 \bibliographystyle{splncs03}
46 48 \bibliography{spb-oss-2018}
... ...