[oss-2018] Conclusion, final remarks and title fixes

Melissa Wen
1 parent 34525353
Showing 2 changed files with 53 additions and 31 deletions Show diff stats
icse2018/content/07-discussion.tex
icse2018/spb-oss-2018.tex
 \section{Discussion and Final Remarks}
 \label{sec:discussion}
  
-In this paper we examine the empirical model of project management applied in a
-software development case in collaboration between government and academia. We
-mapped the practices that harmonized the cultural and organizational differences
-of the institutions involved. In the case study, the project team as a whole had
-not only distinct mind set, but also different levels of maturity and experience
-in topics such as cooperation projects, collaborative development, the adopted
-technologies, and FLOSS. To protect the development team, mostly undergraduates
-with less experience, boundaries were established in the interaction between
-ministry and university. The objectives were: to avoid communication noise, to
-maintain team confidence and motivation, and to increase productivity in terms
-of developed features.
-
-Although the surveys and interviews were performed around one year after the
-project was completed, the strong interaction over the 30 months allowed us to
-extract details of the memories of each of the respondents. Still, we recognize
-that many details and other evidence may have been lost by this hiatus. In other
-hand, the participants also showed a more mature reflection because they could
-related the experienced situations in the project with other works performed
-after project end.
-
-In this research, the answers evidence lessons learned reported in a previous
-work of a part of the authors \cite{meirelles2017spb}. In this previous work,
-the lessons learned are reported from a partial point of view, from participants
-on the academic side of the project and who at the time took leadership roles.
-These new evidences found ratifies this view, welcoming the government side and
-others involved.
-
-(Coleta das respostas em português, falta traduzir. Para avaliar conteúdo e relevância)
+In this paper we examined the empirical model built in a collaborative project
+between government and academia that successfully harmonized the differences in
+the common approaches to software development management used by each side. We
+mapped the key decisions made over the 30-months of the project, that aimed to
+improve communication and the development process as a whole. We also elaborated
+two surveys and one interviews that were conducted separately for three groups
+of participants.  We obtained a total of responses of 37 undergraduated
+students, eight IT market professionals, and two  government officials. Finally,
+we collected post-mortem public data on project management carried out on the
+platform itself. The results revealed nine practices were developed from three
+main decisions taken and 11 benefits were obtained with the adoption of these
+practices.
+
+In our previous work \cite {meirelles2017spb}, we presented the unprecedent
+platform developed in the case study project and seven lessons learned taking into account only the
+academia-side view. The new results acquired in the current work corroborate
+with these lessons, adding the point of view of the government and the academia
+in diverse performed levels. In addition, these results suggest that many free
+software development practices can be replicated in other contexts in which the
+diversity and plurality of its stakeholders need to be leveled and reconciled.
+
+The results obtained also showed questions that were not overcome during the
+project and which we believe need to be evaluated for future collaborations
+between government and academia for software development:
+\begin {itemize}
+\item Improving understanding about collaboration: \textit{"During development,
+we realized that the development team also felt like the owner of the project,
+not just a mere executor. partnership, then it had a lot of that team issue to
+suggest things to be put into the project. It was not a customer relationship it
+was a partnership relationship, so there was a lot of issue suggesting by the
+team to be put into the project"}
+\item Discussion of roles and responsibilities: \textit{"Who had the power to
+make a decision? There was no one, because it was a very equal relationship. The
+two organs were on the same hierarchical level within the work plane. But this
+does not work well, you have to leave well defined to whom the last word belongs
+in the decisions, because the conflicts will always happen."}.
+\item Look for a balance in the requirements definition. The responses showed
+that the government felt that it was not detailed enough and the development
+team felt that the requirements needed to be matured with the use.
+\item Smoothing the intermediations between the different roles \textit{"When we
+had the [UnB] coordinator, when we forwarded a direct question to a developer,
+the coordinator responded. So that was negative, because we felt a little
+coerced from talking directly to the teams"}
+\end {itemize}
+
+As future work, we will reapply in another government-academia paternship
+project the practices evidenced in this case study, and conduct
+qualitative and quantitative research throughout its execution. We intend to
+prove the effectiveness in adopting free software development practices to
+align the demands and expectations of a G-A collaboration.
  
 \begin{comment}
  
@@ -14,10 +14,10 @@
  
 \begin{document}
 \sloppy
-\title{Conciliating Distinct Processes of Management and Software Development}
-\subtitle{A three-year empirical study from the evolution of a government platform}
+\title{Reconciling Distinct Processes of Management and Software Development}
+\subtitle{A three-year empirical study from the evolution of an open source government platform}
  
-\titlerunning{Conciliating Development Processes}
+\titlerunning{Reconciling Development Processes}
  
 \author{.}
1	1	\section{Discussion and Final Remarks}
2	2	\label{sec:discussion}
3	3
4		-In this paper we examine the empirical model of project management applied in a
5		-software development case in collaboration between government and academia. We
6		-mapped the practices that harmonized the cultural and organizational differences
7		-of the institutions involved. In the case study, the project team as a whole had
8		-not only distinct mind set, but also different levels of maturity and experience
9		-in topics such as cooperation projects, collaborative development, the adopted
10		-technologies, and FLOSS. To protect the development team, mostly undergraduates
11		-with less experience, boundaries were established in the interaction between
12		-ministry and university. The objectives were: to avoid communication noise, to
13		-maintain team confidence and motivation, and to increase productivity in terms
14		-of developed features.
15		-
16		-Although the surveys and interviews were performed around one year after the
17		-project was completed, the strong interaction over the 30 months allowed us to
18		-extract details of the memories of each of the respondents. Still, we recognize
19		-that many details and other evidence may have been lost by this hiatus. In other
20		-hand, the participants also showed a more mature reflection because they could
21		-related the experienced situations in the project with other works performed
22		-after project end.
23		-
24		-In this research, the answers evidence lessons learned reported in a previous
25		-work of a part of the authors \cite{meirelles2017spb}. In this previous work,
26		-the lessons learned are reported from a partial point of view, from participants
27		-on the academic side of the project and who at the time took leadership roles.
28		-These new evidences found ratifies this view, welcoming the government side and
29		-others involved.
30		-
31		-(Coleta das respostas em português, falta traduzir. Para avaliar conteúdo e relevância)
	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
	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.
	16	+
	17	+In our previous work \cite {meirelles2017spb}, we presented the unprecedent
	18	+platform developed in the case study project and seven lessons learned taking into account only the
	19	+academia-side view. The new results acquired in the current work corroborate
	20	+with these lessons, adding the point of view of the government and the academia
	21	+in diverse performed levels. In addition, these results suggest that many free
	22	+software development practices can be replicated in other contexts in which the
	23	+diversity and plurality of its stakeholders need to be leveled and reconciled.
	24	+
	25	+The results obtained also showed questions that were not overcome during the
	26	+project and which we believe need to be evaluated for future collaborations
	27	+between government and academia for software development:
	28	+\begin {itemize}
	29	+\item Improving understanding about collaboration: \textit{"During development,
	30	+we realized that the development team also felt like the owner of the project,
	31	+not just a mere executor. partnership, then it had a lot of that team issue to
	32	+suggest things to be put into the project. It was not a customer relationship it
	33	+was a partnership relationship, so there was a lot of issue suggesting by the
	34	+team to be put into the project"}
	35	+\item Discussion of roles and responsibilities: \textit{"Who had the power to
	36	+make a decision? There was no one, because it was a very equal relationship. The
	37	+two organs were on the same hierarchical level within the work plane. But this
	38	+does not work well, you have to leave well defined to whom the last word belongs
	39	+in the decisions, because the conflicts will always happen."}.
	40	+\item Look for a balance in the requirements definition. The responses showed
	41	+that the government felt that it was not detailed enough and the development
	42	+team felt that the requirements needed to be matured with the use.
	43	+\item Smoothing the intermediations between the different roles \textit{"When we
	44	+had the [UnB] coordinator, when we forwarded a direct question to a developer,
	45	+the coordinator responded. So that was negative, because we felt a little
	46	+coerced from talking directly to the teams"}
	47	+\end {itemize}
	48	+
	49	+As future work, we will reapply in another government-academia paternship
	50	+project the practices evidenced in this case study, and conduct
	51	+qualitative and quantitative research throughout its execution. We intend to
	52	+prove the effectiveness in adopting free software development practices to
	53	+align the demands and expectations of a G-A collaboration.
32	54
33	55	\begin{comment}
34	56
...	...
...	...	@@ -14,10 +14,10 @@
14	14
15	15	\begin{document}
16	16	\sloppy
17		-\title{Conciliating Distinct Processes of Management and Software Development}
18		-\subtitle{A three-year empirical study from the evolution of a government platform}
	17	+\title{Reconciling Distinct Processes of Management and Software Development}
	18	+\subtitle{A three-year empirical study from the evolution of an open source government platform}
19	19
20		-\titlerunning{Conciliating Development Processes}
	20	+\titlerunning{Reconciling Development Processes}
21	21
22	22	\author{.}
23	23
...	...