Updating Context section

Paulo Meireles
1 parent 1eb83ff5
Showing 1 changed file with 20 additions and 20 deletions Show diff stats
ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md
@@ -42,11 +42,14 @@ In this article, we discuss the use of Continuous Delivery (CD) during our exper
 <!---
 Comment: "Background/intro - This could be more streamlined and focused. Maybe center around a question such as - What is different between gov and non-gov context using your data as to illustrate then tie that to what you had to do in your CI process to address this gap."
  
-Paulo: Vamos discordar do revisor. O ponto não foi gov e não gov. Vamos esclarecer que o SPB foi algo particular mesmo, cheio de nuâncias.
-Siqueira/Diego: ...
+Paulo: O ponto não foi gov e não gov. Vamos esclarecer que o SPB foi algo particular mesmo, cheio de nuâncias.
+
 -->
  
-(Refazer primeiro parágrafo do contexto)
+The SPB is a governmental program of the MP created to foster sharing and collaboration on Open Source Software (OSS) projects for the Brazilian public administration. The MP managed both software requirements and server infrastructure of their projects. However, its hierarchical and traditional processes made them unfamiliar with new software development techniques, such as CD. Any of our requests had to pass through layers of bureaucracy before being answered. Requesting access to their infrastructure to make the deploy was not different.
+
+During its lifetime, the project suffered significant interference from the board of directors because the portal represents an interface between government and society. In light of political interests, directors continually imposed changes to the platform while ignoring our technical advice. In 2015, the board of directors was changed and, with it, the vision of the project. New directors had different political agendas which affected the project's requirements previously approved.
+
  
 <!---
 Comment:
@@ -54,11 +57,10 @@ Comment:
  
 Siqueira/Paulo: Note que esse ponto gerou muita discussão e confusão. Mudei um pouco a estratégia de forma a responder o revisor e ao mesmo tempo tornar o texto mais fluido
  
-Melissa: Reformular o enunciado do problema. 
+Melissa: Reformula o enunciado do primeiro problema (FEITO por Siqueira e Diego). 
 -->
  
-The SPB evolution project started in 2014: a presidential election year and everyone involved was under pressure to show results. Even with the re-election of the Brazilian President, leaderships in governmental agencies ended up changing in 2015. Each one of them had different political agendas which affected the project's requirements previously approved. Besides that scenario of instability, we overcame three distinct issues: (1) achieving the goals which have guided the platform development, (2) widespread belief among the government agents that any project in partnership with a University is doomed to fail, and (3) the rudimentary and bureaucratic deployment approach in the MP infrastructure. Handling the interaction of these elements was challenging and the unstable Brazilian political scenario only made things worse.
-
+In this context, we overcame three distinct challenges: (1) find a system solution wherein government and development team agree, (2) widespread belief among the government agents that any project in partnership with a University is doomed to fail, and (3) the bureaucracies involved in the deployment process by the MP.
 <!---
 Comment: 
  
@@ -67,7 +69,7 @@ Comment:
 Siqueira/Paulo: Contamos essa história sem ter que entrar em detalhes aqui. Contudo, será preciso fazer a seção de pipeline harmonizar com isso
 -->
  
-To achieve the SPB project goals, we projected the SPB Portal as a CDE with additional social features. Due to the complexity of creating such a system from scratch, we decided to evolute and integrate existing open source tools to build a system-of-systems [?]. We work on a number of distinct systems such as social and collaboration network, Git repository manager, mailing list, source code metric evaluation, and a systems integration platform [OPENSYM]. We create a solution that orchestrates systems and allowed us to smoothly provide a unified interface for final users, including single sign-on and global searches. For that, we had to learn how each system worked and to come up with ideas of how to integrate them as fast as possible, with a team of mostly inexperienced developers. 
+Firstly, to find a system solution wherein government and development team agree, we designed the SPB Portal as a CDE with additional social features. Due to the complexity of creating such a system from scratch, we decided to adapt and integrate existing open source tools to build a system-of-systems [REF]. We created a solution that orchestrates systems and allowed us to smoothly provide a unified interface for final users, including single sign-on and global searches [4]. On top of that the new SPB Portal was an unprecedented platform to Brazilian government, with a complex deployment process.
  
 <!---
 Comment: "Can the authors provide some data as well? As I said this is a unique scenario and the community can greatly benefit. For example, how many devs at any given time, how many features/unit time (month/year), how frequently were releases made, how frequently did you meet with the client, how frequently did the requirements change are some example questions to which if we had data, it would place the study in greater context."
@@ -82,8 +84,6 @@ Comment:
 Siqueira/Paulo: Isso aqui também fica resolvido
 -->
  
-Our team was not from a typical company, but consisted mainly of undergraduate students. This led to a vast diversity and quick turnover of members. We had 42 different software engineering undergraduate students during the project: 24 in 2014, 36 in 2015, and 20 in 2016. We also had 2 designers and 6 senior developers from the Brazilian open source communities in charge of handling complex tasks and transferring knowledge to the undergrads. Finally, we had 2 professors responsible for interacting with the Brazilian government and controlling political pressures applied to the project.
-
 <!---
 Paulo: este parágrafo abaixo ficou tem redundância com o segundo do contexto.
  
@@ -96,15 +96,13 @@ Paulo: o segundo problema foi alterado em relação à primeira versão, mas a e
 Siqueira: trocar conhecimento técnico por interesse, disponibilidade ou esforço ...
 -->
  
-The second barrier we had to face was the widespread belief among the government agents that any project in partnership with a University is doomed to fail, which made interacting with us complicated. 
-%
-In particular, the SysAdmin team from the MP had low technical knowledge to deploy new versions of the new SPB Portal in a timely manner, hampering the benefits of the tool and preventing us from showing off the fruits of the project to those responsible for evaluating it. The requirement analysts from the MP were real representatives of the Brazilian government in the project and their role was to test new features, to provide feedback to the development team, and to report for the MP leaders. The SysAdmins in charge of managing the host machines wherein SPB Portal was running. They were, theoretically, responsible for deploying the project but the new SPB Portal was an unprecedented platform to Brazilian government, generating a complex deployment process for their.
+Secondly, we had to face the widespread belief among government agents that any project in partnership with a University is doomed to fail. Our team was not from a typical company, consisting mainly of undergraduate students coordinated by 2 professors. At the first year, our team was composed by 24 undergraduate students, 1 designer and 2 senior developers. In 2015, our  team grew  to 36 students, 2 designers, 8 senior developers.  At the end of in project, due to budget constraint, we had 20 students, 1 designer and 2 senior developers. Moreover,  the SPB Portal evolution was the first software development collaboration between university and government experienced by the MP analysts involved in this project.
  
 <!---
 Paulo: o terceiro problema é novo em relação à primeira versão, mas na prática tínhamos tratado a questão
 -->
  
-To overcame the deployment limitation, we realized we needed to take control over the deployment process. We used CD as a mean to fulfill the government expectations and to provide quick response to their requests, which were influenced most of the time by the uncertainties of the project's continuity. We believed we would keep the project alive, even in a politically unstable and technically complex scenario.  For this reason, we focused on automating the deploy process and formed a specific team dedicated to the deployment process. This team was responsible for maturing our CD pipeline, giving us confidence and agility to comply with government requirements.
+Lastly, our team thought of software deployment differently than the MP. On our side, we believe that frequent deliveries are better for the project’s success. However, the MP works with the idea of a single deployment at the end of the project. In other words, the MP was neither technically prepared nor the bureaucratic structured foresaw this kind of work style. In additionally, there was very little effort to deploy new versions of the system in a timely manner. That ended up hampering the benefits of the tool and preventing us from showing off the fruits of the project to those responsible for evaluating it.
  
 <!---
 "the article is missing the ah,ha moment. Was there something interesting that you learned (could be a small thing) that you use to adapt the CI process when applying it in a gov or large org context versus a smaller org? "
@@ -112,7 +110,7 @@ To overcame the deployment limitation, we realized we needed to take control ove
 Siqueira/Paulo: eis o AH-HA moment!
 -->
  
-These challenges made our relationship with the Government tense at the first year of the project, as well as, all political and technical issues alerted us for the fact that the project could be finished at any time if we could not overcome during the first year such problems. Therefore, the deployment limitation was the only real problem we could tackle in the short term. As a result, we worked to try and deploy one version of the project onto our own infrastructure and showed it to the government evaluators. This strategy proved them that we could efficiently deliver new features and fulfill their expectations and enticed them to demand these features in production. This, in turn, generated more pressure on the IT department responsible for the deployment routines. This was compounded with each CD cycle, allowing us to gradually built a new relationship among all parties and, by the end of the project, to become active participants in the deploy operations. CD kept the project alive for years during the worst political crisis after the re-democratization in Brazil.
+These challenges made our relationship with the MP tense, in particular at the first year of the project, and alerted us for the fact that the project could be finished at any time. The deployment limitation was the main technical issue we could tackle in the short term. As a result, we worked to deploy one version of the project onto our own infrastructure and showed it to the government evaluators. This strategy proved them that we could efficiently deliver new features, fulfill their expectations regarding the delivery of the requirements, and mobilized them to demand these features working in the MP infrastructure. This, in turn, generated more pressure on the IT department responsible for the deployment routines. This was compounded with each CD cycle, allowing us to gradually built a new relationship among all parties and, by the end of the project, to become active participants in the deploy operations.
  
 ## Our Continuous Delivery Pipeline
  
@@ -331,11 +329,13 @@ We thank our colleagues, Nelson Lago, Lucas Kanashiro and Rafael Manzo, and this
  
 1. G. Booch, A. W. Brown, "Collaborative Development Environments", in Advances in Computers, vol. 59, 2003, pp. 1–27.
 2. L. Chen, "Continuous Delivery: Huge Benefits, but Challenges Too", in IEEE Software, vol. 32, no. 2, 2015, pp. 50-54.
-3. Davis, Jennifer and Daniels, Katherine, Effective DevOps: building a culture of collaboration, affinity, and tooling at scale, 2016, " O'Reilly Media, Inc."
-4. Humble, J. and Farley, D., 2010. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Pearson Education.
-5. Savor, T., Douglas, M., Gentili, M., Williams, L., Beck, K. and Stumm, M., 2016, May. Continuous deployment at Facebook and OANDA. In Proceedings of the 38th International Conference on Software Engineering Companion (pp. 21-30). ACM.
-6. Anthopoulos, L., Reddick, C.G., Giannakidou, I. and Mavridis, N., 2016. Why e-government projects fail? An analysis of the Healthcare. gov website. Government Information Quarterly, 33(1), pp.161-173.
-7. Chen, L., 2015, May. Research opportunities in continuous delivery: reflections from two years' experiences in a large bookmaking company. In Proceedings of the Third International Workshop on Release Engineering (pp. 2-2). IEEE Press.
-8. Chen, L., 2015, May. Towards architecting for continuous delivery. In Software Architecture (WICSA), 2015 12th Working IEEE/IFIP Conference on (pp. 131-134). IEEE.
+3. REF system-of-system.
+4. Meirelles, P., Wen, M., Terceiro, A., Siqueira, R., Kanashiro, L., and Neri, H. 2017. Brazilian Public Software Portal: an integrated platform for collaborative development. In Proceedings of the 13th International Symposium on Open Collaboration (OpenSym '17). ACM, Article 16, 10 pages.
+5. Davis, Jennifer and Daniels, Katherine, Effective DevOps: building a culture of collaboration, affinity, and tooling at scale, 2016, " O'Reilly Media, Inc."
+6. Humble, J. and Farley, D., 2010. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Adobe Reader). Pearson Education.
+7. Savor, T., Douglas, M., Gentili, M., Williams, L., Beck, K. and Stumm, M., 2016, May. Continuous deployment at Facebook and OANDA. In Proceedings of the 38th International Conference on Software Engineering Companion (pp. 21-30). ACM.
+8. Chen, L., 2015, May. Research opportunities in continuous delivery: reflections from two years' experiences in a large bookmaking company. In Proceedings of the Third International Workshop on Release Engineering (pp. 2-2). IEEE Press.
+9. Chen, L., 2015, May. Towards architecting for continuous delivery. In Software Architecture (WICSA), 2015 12th Working IEEE/IFIP Conference on (pp. 131-134). IEEE.
+
...	...	@@ -42,11 +42,14 @@ In this article, we discuss the use of Continuous Delivery (CD) during our exper
42	42	<!---
43	43	Comment: "Background/intro - This could be more streamlined and focused. Maybe center around a question such as - What is different between gov and non-gov context using your data as to illustrate then tie that to what you had to do in your CI process to address this gap."
44	44
45		-Paulo: Vamos discordar do revisor. O ponto não foi gov e não gov. Vamos esclarecer que o SPB foi algo particular mesmo, cheio de nuâncias.
46		-Siqueira/Diego: ...
	45	+Paulo: O ponto não foi gov e não gov. Vamos esclarecer que o SPB foi algo particular mesmo, cheio de nuâncias.
	46	+
47	47	-->
48	48
49		-(Refazer primeiro parágrafo do contexto)
	49	+The SPB is a governmental program of the MP created to foster sharing and collaboration on Open Source Software (OSS) projects for the Brazilian public administration. The MP managed both software requirements and server infrastructure of their projects. However, its hierarchical and traditional processes made them unfamiliar with new software development techniques, such as CD. Any of our requests had to pass through layers of bureaucracy before being answered. Requesting access to their infrastructure to make the deploy was not different.
	50	+
	51	+During its lifetime, the project suffered significant interference from the board of directors because the portal represents an interface between government and society. In light of political interests, directors continually imposed changes to the platform while ignoring our technical advice. In 2015, the board of directors was changed and, with it, the vision of the project. New directors had different political agendas which affected the project's requirements previously approved.
	52	+
50	53
51	54	<!---
52	55	Comment:
...	...	@@ -54,11 +57,10 @@ Comment:
54	57
55	58	Siqueira/Paulo: Note que esse ponto gerou muita discussão e confusão. Mudei um pouco a estratégia de forma a responder o revisor e ao mesmo tempo tornar o texto mais fluido
56	59
57		-Melissa: Reformular o enunciado do problema.
	60	+Melissa: Reformula o enunciado do primeiro problema (FEITO por Siqueira e Diego).
58	61	-->
59	62
60		-The SPB evolution project started in 2014: a presidential election year and everyone involved was under pressure to show results. Even with the re-election of the Brazilian President, leaderships in governmental agencies ended up changing in 2015. Each one of them had different political agendas which affected the project's requirements previously approved. Besides that scenario of instability, we overcame three distinct issues: (1) achieving the goals which have guided the platform development, (2) widespread belief among the government agents that any project in partnership with a University is doomed to fail, and (3) the rudimentary and bureaucratic deployment approach in the MP infrastructure. Handling the interaction of these elements was challenging and the unstable Brazilian political scenario only made things worse.
61		-
	63	+In this context, we overcame three distinct challenges: (1) find a system solution wherein government and development team agree, (2) widespread belief among the government agents that any project in partnership with a University is doomed to fail, and (3) the bureaucracies involved in the deployment process by the MP.
62	64	<!---
63	65	Comment:
64	66
...	...	@@ -67,7 +69,7 @@ Comment:
67	69	Siqueira/Paulo: Contamos essa história sem ter que entrar em detalhes aqui. Contudo, será preciso fazer a seção de pipeline harmonizar com isso
68	70	-->
69	71
70		-To achieve the SPB project goals, we projected the SPB Portal as a CDE with additional social features. Due to the complexity of creating such a system from scratch, we decided to evolute and integrate existing open source tools to build a system-of-systems [?]. We work on a number of distinct systems such as social and collaboration network, Git repository manager, mailing list, source code metric evaluation, and a systems integration platform [OPENSYM]. We create a solution that orchestrates systems and allowed us to smoothly provide a unified interface for final users, including single sign-on and global searches. For that, we had to learn how each system worked and to come up with ideas of how to integrate them as fast as possible, with a team of mostly inexperienced developers.
	72	+Firstly, to find a system solution wherein government and development team agree, we designed the SPB Portal as a CDE with additional social features. Due to the complexity of creating such a system from scratch, we decided to adapt and integrate existing open source tools to build a system-of-systems [REF]. We created a solution that orchestrates systems and allowed us to smoothly provide a unified interface for final users, including single sign-on and global searches [4]. On top of that the new SPB Portal was an unprecedented platform to Brazilian government, with a complex deployment process.
71	73
72	74	<!---
73	75	Comment: "Can the authors provide some data as well? As I said this is a unique scenario and the community can greatly benefit. For example, how many devs at any given time, how many features/unit time (month/year), how frequently were releases made, how frequently did you meet with the client, how frequently did the requirements change are some example questions to which if we had data, it would place the study in greater context."
...	...	@@ -82,8 +84,6 @@ Comment:
82	84	Siqueira/Paulo: Isso aqui também fica resolvido
83	85	-->
84	86
85		-Our team was not from a typical company, but consisted mainly of undergraduate students. This led to a vast diversity and quick turnover of members. We had 42 different software engineering undergraduate students during the project: 24 in 2014, 36 in 2015, and 20 in 2016. We also had 2 designers and 6 senior developers from the Brazilian open source communities in charge of handling complex tasks and transferring knowledge to the undergrads. Finally, we had 2 professors responsible for interacting with the Brazilian government and controlling political pressures applied to the project.
86		-
87	87	<!---
88	88	Paulo: este parágrafo abaixo ficou tem redundância com o segundo do contexto.
89	89
...	...	@@ -96,15 +96,13 @@ Paulo: o segundo problema foi alterado em relação à primeira versão, mas a e
96	96	Siqueira: trocar conhecimento técnico por interesse, disponibilidade ou esforço ...
97	97	-->
98	98
99		-The second barrier we had to face was the widespread belief among the government agents that any project in partnership with a University is doomed to fail, which made interacting with us complicated.
100		-%
101		-In particular, the SysAdmin team from the MP had low technical knowledge to deploy new versions of the new SPB Portal in a timely manner, hampering the benefits of the tool and preventing us from showing off the fruits of the project to those responsible for evaluating it. The requirement analysts from the MP were real representatives of the Brazilian government in the project and their role was to test new features, to provide feedback to the development team, and to report for the MP leaders. The SysAdmins in charge of managing the host machines wherein SPB Portal was running. They were, theoretically, responsible for deploying the project but the new SPB Portal was an unprecedented platform to Brazilian government, generating a complex deployment process for their.
	99	+Secondly, we had to face the widespread belief among government agents that any project in partnership with a University is doomed to fail. Our team was not from a typical company, consisting mainly of undergraduate students coordinated by 2 professors. At the first year, our team was composed by 24 undergraduate students, 1 designer and 2 senior developers. In 2015, our team grew to 36 students, 2 designers, 8 senior developers. At the end of in project, due to budget constraint, we had 20 students, 1 designer and 2 senior developers. Moreover, the SPB Portal evolution was the first software development collaboration between university and government experienced by the MP analysts involved in this project.
102	100
103	101	<!---
104	102	Paulo: o terceiro problema é novo em relação à primeira versão, mas na prática tínhamos tratado a questão
105	103	-->
106	104
107		-To overcame the deployment limitation, we realized we needed to take control over the deployment process. We used CD as a mean to fulfill the government expectations and to provide quick response to their requests, which were influenced most of the time by the uncertainties of the project's continuity. We believed we would keep the project alive, even in a politically unstable and technically complex scenario. For this reason, we focused on automating the deploy process and formed a specific team dedicated to the deployment process. This team was responsible for maturing our CD pipeline, giving us confidence and agility to comply with government requirements.
	105	+Lastly, our team thought of software deployment differently than the MP. On our side, we believe that frequent deliveries are better for the project’s success. However, the MP works with the idea of a single deployment at the end of the project. In other words, the MP was neither technically prepared nor the bureaucratic structured foresaw this kind of work style. In additionally, there was very little effort to deploy new versions of the system in a timely manner. That ended up hampering the benefits of the tool and preventing us from showing off the fruits of the project to those responsible for evaluating it.
108	106
109	107	<!---
110	108	"the article is missing the ah,ha moment. Was there something interesting that you learned (could be a small thing) that you use to adapt the CI process when applying it in a gov or large org context versus a smaller org? "
...	...	@@ -112,7 +110,7 @@ To overcame the deployment limitation, we realized we needed to take control ove
112	110	Siqueira/Paulo: eis o AH-HA moment!
113	111	-->
114	112
115		-These challenges made our relationship with the Government tense at the first year of the project, as well as, all political and technical issues alerted us for the fact that the project could be finished at any time if we could not overcome during the first year such problems. Therefore, the deployment limitation was the only real problem we could tackle in the short term. As a result, we worked to try and deploy one version of the project onto our own infrastructure and showed it to the government evaluators. This strategy proved them that we could efficiently deliver new features and fulfill their expectations and enticed them to demand these features in production. This, in turn, generated more pressure on the IT department responsible for the deployment routines. This was compounded with each CD cycle, allowing us to gradually built a new relationship among all parties and, by the end of the project, to become active participants in the deploy operations. CD kept the project alive for years during the worst political crisis after the re-democratization in Brazil.
	113	+These challenges made our relationship with the MP tense, in particular at the first year of the project, and alerted us for the fact that the project could be finished at any time. The deployment limitation was the main technical issue we could tackle in the short term. As a result, we worked to deploy one version of the project onto our own infrastructure and showed it to the government evaluators. This strategy proved them that we could efficiently deliver new features, fulfill their expectations regarding the delivery of the requirements, and mobilized them to demand these features working in the MP infrastructure. This, in turn, generated more pressure on the IT department responsible for the deployment routines. This was compounded with each CD cycle, allowing us to gradually built a new relationship among all parties and, by the end of the project, to become active participants in the deploy operations.
116	114
117	115	## Our Continuous Delivery Pipeline
118	116
...	...	@@ -331,11 +329,13 @@ We thank our colleagues, Nelson Lago, Lucas Kanashiro and Rafael Manzo, and this
331	329
332	330	1. G. Booch, A. W. Brown, "Collaborative Development Environments", in Advances in Computers, vol. 59, 2003, pp. 1–27.
333	331	2. L. Chen, "Continuous Delivery: Huge Benefits, but Challenges Too", in IEEE Software, vol. 32, no. 2, 2015, pp. 50-54.
334		-3. Davis, Jennifer and Daniels, Katherine, Effective DevOps: building a culture of collaboration, affinity, and tooling at scale, 2016, " O'Reilly Media, Inc."
335		-4. Humble, J. and Farley, D., 2010. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Pearson Education.
336		-5. Savor, T., Douglas, M., Gentili, M., Williams, L., Beck, K. and Stumm, M., 2016, May. Continuous deployment at Facebook and OANDA. In Proceedings of the 38th International Conference on Software Engineering Companion (pp. 21-30). ACM.
337		-6. Anthopoulos, L., Reddick, C.G., Giannakidou, I. and Mavridis, N., 2016. Why e-government projects fail? An analysis of the Healthcare. gov website. Government Information Quarterly, 33(1), pp.161-173.
338		-7. Chen, L., 2015, May. Research opportunities in continuous delivery: reflections from two years' experiences in a large bookmaking company. In Proceedings of the Third International Workshop on Release Engineering (pp. 2-2). IEEE Press.
339		-8. Chen, L., 2015, May. Towards architecting for continuous delivery. In Software Architecture (WICSA), 2015 12th Working IEEE/IFIP Conference on (pp. 131-134). IEEE.
	332	+3. REF system-of-system.
	333	+4. Meirelles, P., Wen, M., Terceiro, A., Siqueira, R., Kanashiro, L., and Neri, H. 2017. Brazilian Public Software Portal: an integrated platform for collaborative development. In Proceedings of the 13th International Symposium on Open Collaboration (OpenSym '17). ACM, Article 16, 10 pages.
	334	+5. Davis, Jennifer and Daniels, Katherine, Effective DevOps: building a culture of collaboration, affinity, and tooling at scale, 2016, " O'Reilly Media, Inc."
	335	+6. Humble, J. and Farley, D., 2010. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Adobe Reader). Pearson Education.
	336	+7. Savor, T., Douglas, M., Gentili, M., Williams, L., Beck, K. and Stumm, M., 2016, May. Continuous deployment at Facebook and OANDA. In Proceedings of the 38th International Conference on Software Engineering Companion (pp. 21-30). ACM.
	337	+8. Chen, L., 2015, May. Research opportunities in continuous delivery: reflections from two years' experiences in a large bookmaking company. In Proceedings of the Third International Workshop on Release Engineering (pp. 2-2). IEEE Press.
	338	+9. Chen, L., 2015, May. Towards architecting for continuous delivery. In Software Architecture (WICSA), 2015 12th Working IEEE/IFIP Conference on (pp. 131-134). IEEE.
	339	+
340	340
341	341
...	...