[oss2018] Minor coorections and adding comments

Paulo Meireles
1 parent 20c1f324
Showing 1 changed file with 74 additions and 5 deletions Show diff stats
icse2018/content/04-case.tex
@@ -2,14 +2,83 @@
 \label{sec:casestudy}
  
  
-The Brazilian Public Software portal is an e-government project for sharing Brazilian Public Software, a specific type of software that meets the needs of modernization of public administration. The availability of this software in electronic via aims at saving public resources, benefiting the State and society. The first version of the portal was released in 2007 and it was based on the OpenACS software. OpenACS was no longer maintained by the community and the lack of new development and sustainability projects made the platform obsolete with uncontrollable crashes. With approximately 145 requirements mapped out in dialogues with public agencies and society, a new platform needed to be created.
+The Brazilian Public Software portal is an e-government project for sharing
+public software projects, specific type of systems that meets the needs of
+modernization of the Brazilian public administration. The vailability of this
+software in electronic via aims at saving public resources, benefiting the
+State and society.
  
-The evolution of the Brazilian Public Software platform was a partnership project between the Brazilian government and Brazilian public universities between the years 2014 and 2016. The management and development team was made up of employees from the Ministry of Planning (MPOG), professors from the University of Brasília (UnB), professionals of the IT market, MSc students in Computer Science at the University of São Paulo (USP), and undergraduate students in Software Engineering at the University of Brasília. The project was developed physically in the Advanced Laboratory of Production, Research and Innovation in Software of UnB. In Brasília, capital of Brazil, the federal government is the most important customer and the largest bidder of software development contracts. Understanding the particularities of projects with the government and being prepared to meet your goals and pace of production is important for students professionally. Thus, this collaborative project was an opportunity for the transfer of knowledge between academia and government and for the practical application of the project management methods taught in the undergraduate course in Software Engineering.
+The first version of the portal was released in 2007 but the lack of new
+development and sustainability projects made the platform obsolete with
+uncontrollable crashes. With approximately 145 requirements mapped out in
+dialogues with public agencies and society, a new platform needed to be
+created.
+%TODOc: refazer e avaliar se basta citarmos o nosso paper da OSS
  
-Differences in the organizational and managerial structure of the institutions to which each member belonged generated differences in goals, requirements and pace of execution. On the MPOG side, the requirements analysts were ministry staff who interacted most actively with the development team, their productivity was reported to their coordinator, and their coordinator reported to the board of directors. The director of the department responsible for software development had no autonomy over the deployment infrastructure. As the development and deployment of the ministry followed a traditional approach, opening a window of dialogue between these two departments for software deployment in production was usually not costly. Thus, the development of a software solution basically passed through the following steps: mapping requirements, prepararing a contract of licitation, hiring of contract executor, homologation of the product, delivery and deployment of the software, and payment.
  
-On the UnB side, the agile approach was used for development. Due to the amount and maturity of the requirements demanded and the novelty, in the governmental context, of several features, the traditional methodologies was unsuitable for the development of complex integrated software platform. The coordinator led the dialogue with board of directors as well as managed the interactions between MPOG staff and developer team. The development team was divided into specific groups for the main contexts and there was self-coordination among team members. The activities were organized by sprints of 15 days and the epics in 4 months. The development was incremental, with intermediate deliveries. Due to differences in deployment pace between MPOG and UnB and other bureaucratic issues, the first version of the portal was launched on the university infrastructure and later migrated to the ministry infrastructure.
+The evolution of the Brazilian Public Software platform was a partnership
+project between the Brazilian government and Brazilian public universities
+between the years 2014 and 2016. The management and development team was made
+up of staff from the Ministry of Planning (MPOG), professors from the
+University of Brasília (UnB), professionals of the IT market, MSc students in
+Computer Science at the University of São Paulo (USP), and undergraduate
+students in Software Engineering at the University of Brasília. The project was
+developed physically in the Advanced Laboratory of Production, Research and
+Innovation in Software of UnB. In Brasília, capital of Brazil, the federal
+government is the most important customer and the largest bidder of software
+development contracts. Understanding the particularities of projects with the
+government and being prepared to meet your goals and pace of production is
+important for students professionally. Thus, this collaborative project was an
+opportunity for the transfer of knowledge between academia and government and
+for the practical application of the project management methods taught in the
+undergraduate course in Software Engineering.
+%TODO:Muita informação/detalhe desnessário
  
-The main conflicts in the development process of the platform arose from the very nature of traditional and agile approaches: the government expected fully specified functionalities before implementation, a large volume of documentation, formalization of reports with full functionality deliveries, function point calculations for changes in requirements; the academy understood that features should be broken down into small functionalities with short-term deliverables for validation, decisions about what would be developed and how it would be developed should be collaboratively taken between client and developers, roles were flexible and organized organically.
  
+Differences in the organizational and managerial structure of the institutions
+to which each member belonged generated differences in goals, requirements and
+pace of execution. On the MPOG side, the requirements analysts were ministry
+staff who interacted most actively with the development team, their
+productivity was reported to their coordinator, and their coordinator reported
+to the board of directors. The director of the department responsible for
+software development had no autonomy over the deployment infrastructure. As the
+development and deployment of the ministry followed a traditional approach,
+opening a window of dialogue between these two departments for software
+deployment in production was usually not costly. Thus, the development of a
+software solution basically passed through the following steps: mapping
+requirements, prepararing a contract of licitation, hiring of contract
+executor, homologation of the product, delivery and deployment of the software,
+and payment.
  
+On the UnB side, the agile approach was used for development.
+%
+Due to the amount
+and maturity of the requirements demanded and the novelty, in the governmental
+context, of several features, the traditional methodologies was unsuitable for
+the development of complex integrated software platform.
+% TODO: bem truncado ^
+The coordinator led
+the dialogue with board of directors as well as managbed the interactions
+between MPOG staff and dedveloper team. The development team was divided into
+specific groups for the main contexts and there was self-coordination among
+team members. The activities were organized by sprints of 15 days and the epics
+in 4 months. The development was incremental, with intermediate deliveries.
+%
+Due
+to differences in deployment pace between MPOG and UnB and other bureaucratic
+issues, the first version of the portal was launched on the university
+infrastructure and later migrated to the ministry infrastructure.
+% TODO: podemos citar nosso paper aceito na IEEE e não citar este último detalhes
+
+
+The main conflicts in the development process of the platform arose from the
+very nature of traditional and agile approaches: the government expected fully
+specified functionalities before implementation, a large volume of
+documentation, formalization of reports with full functionality deliveries,
+function point calculations for changes in requirements; the academy understood
+that features should be broken down into small functionalities with short-term
+deliverables for validation, decisions about what would be developed and how it
+would be developed should be collaboratively taken between client and
+developers, roles were flexible and organized organically.
+
+%TODO: ainda falta fechar com algo
...	...	@@ -2,14 +2,83 @@
2	2	\label{sec:casestudy}
3	3
4	4
5		-The Brazilian Public Software portal is an e-government project for sharing Brazilian Public Software, a specific type of software that meets the needs of modernization of public administration. The availability of this software in electronic via aims at saving public resources, benefiting the State and society. The first version of the portal was released in 2007 and it was based on the OpenACS software. OpenACS was no longer maintained by the community and the lack of new development and sustainability projects made the platform obsolete with uncontrollable crashes. With approximately 145 requirements mapped out in dialogues with public agencies and society, a new platform needed to be created.
	5	+The Brazilian Public Software portal is an e-government project for sharing
	6	+public software projects, specific type of systems that meets the needs of
	7	+modernization of the Brazilian public administration. The vailability of this
	8	+software in electronic via aims at saving public resources, benefiting the
	9	+State and society.
6	10
7		-The evolution of the Brazilian Public Software platform was a partnership project between the Brazilian government and Brazilian public universities between the years 2014 and 2016. The management and development team was made up of employees from the Ministry of Planning (MPOG), professors from the University of Brasília (UnB), professionals of the IT market, MSc students in Computer Science at the University of São Paulo (USP), and undergraduate students in Software Engineering at the University of Brasília. The project was developed physically in the Advanced Laboratory of Production, Research and Innovation in Software of UnB. In Brasília, capital of Brazil, the federal government is the most important customer and the largest bidder of software development contracts. Understanding the particularities of projects with the government and being prepared to meet your goals and pace of production is important for students professionally. Thus, this collaborative project was an opportunity for the transfer of knowledge between academia and government and for the practical application of the project management methods taught in the undergraduate course in Software Engineering.
	11	+The first version of the portal was released in 2007 but the lack of new
	12	+development and sustainability projects made the platform obsolete with
	13	+uncontrollable crashes. With approximately 145 requirements mapped out in
	14	+dialogues with public agencies and society, a new platform needed to be
	15	+created.
	16	+%TODOc: refazer e avaliar se basta citarmos o nosso paper da OSS
8	17
9		-Differences in the organizational and managerial structure of the institutions to which each member belonged generated differences in goals, requirements and pace of execution. On the MPOG side, the requirements analysts were ministry staff who interacted most actively with the development team, their productivity was reported to their coordinator, and their coordinator reported to the board of directors. The director of the department responsible for software development had no autonomy over the deployment infrastructure. As the development and deployment of the ministry followed a traditional approach, opening a window of dialogue between these two departments for software deployment in production was usually not costly. Thus, the development of a software solution basically passed through the following steps: mapping requirements, prepararing a contract of licitation, hiring of contract executor, homologation of the product, delivery and deployment of the software, and payment.
10	18
11		-On the UnB side, the agile approach was used for development. Due to the amount and maturity of the requirements demanded and the novelty, in the governmental context, of several features, the traditional methodologies was unsuitable for the development of complex integrated software platform. The coordinator led the dialogue with board of directors as well as managed the interactions between MPOG staff and developer team. The development team was divided into specific groups for the main contexts and there was self-coordination among team members. The activities were organized by sprints of 15 days and the epics in 4 months. The development was incremental, with intermediate deliveries. Due to differences in deployment pace between MPOG and UnB and other bureaucratic issues, the first version of the portal was launched on the university infrastructure and later migrated to the ministry infrastructure.
	19	+The evolution of the Brazilian Public Software platform was a partnership
	20	+project between the Brazilian government and Brazilian public universities
	21	+between the years 2014 and 2016. The management and development team was made
	22	+up of staff from the Ministry of Planning (MPOG), professors from the
	23	+University of Brasília (UnB), professionals of the IT market, MSc students in
	24	+Computer Science at the University of São Paulo (USP), and undergraduate
	25	+students in Software Engineering at the University of Brasília. The project was
	26	+developed physically in the Advanced Laboratory of Production, Research and
	27	+Innovation in Software of UnB. In Brasília, capital of Brazil, the federal
	28	+government is the most important customer and the largest bidder of software
	29	+development contracts. Understanding the particularities of projects with the
	30	+government and being prepared to meet your goals and pace of production is
	31	+important for students professionally. Thus, this collaborative project was an
	32	+opportunity for the transfer of knowledge between academia and government and
	33	+for the practical application of the project management methods taught in the
	34	+undergraduate course in Software Engineering.
	35	+%TODO:Muita informação/detalhe desnessário
12	36
13		-The main conflicts in the development process of the platform arose from the very nature of traditional and agile approaches: the government expected fully specified functionalities before implementation, a large volume of documentation, formalization of reports with full functionality deliveries, function point calculations for changes in requirements; the academy understood that features should be broken down into small functionalities with short-term deliverables for validation, decisions about what would be developed and how it would be developed should be collaboratively taken between client and developers, roles were flexible and organized organically.
14	37
	38	+Differences in the organizational and managerial structure of the institutions
	39	+to which each member belonged generated differences in goals, requirements and
	40	+pace of execution. On the MPOG side, the requirements analysts were ministry
	41	+staff who interacted most actively with the development team, their
	42	+productivity was reported to their coordinator, and their coordinator reported
	43	+to the board of directors. The director of the department responsible for
	44	+software development had no autonomy over the deployment infrastructure. As the
	45	+development and deployment of the ministry followed a traditional approach,
	46	+opening a window of dialogue between these two departments for software
	47	+deployment in production was usually not costly. Thus, the development of a
	48	+software solution basically passed through the following steps: mapping
	49	+requirements, prepararing a contract of licitation, hiring of contract
	50	+executor, homologation of the product, delivery and deployment of the software,
	51	+and payment.
15	52
	53	+On the UnB side, the agile approach was used for development.
	54	+%
	55	+Due to the amount
	56	+and maturity of the requirements demanded and the novelty, in the governmental
	57	+context, of several features, the traditional methodologies was unsuitable for
	58	+the development of complex integrated software platform.
	59	+% TODO: bem truncado ^
	60	+The coordinator led
	61	+the dialogue with board of directors as well as managbed the interactions
	62	+between MPOG staff and dedveloper team. The development team was divided into
	63	+specific groups for the main contexts and there was self-coordination among
	64	+team members. The activities were organized by sprints of 15 days and the epics
	65	+in 4 months. The development was incremental, with intermediate deliveries.
	66	+%
	67	+Due
	68	+to differences in deployment pace between MPOG and UnB and other bureaucratic
	69	+issues, the first version of the portal was launched on the university
	70	+infrastructure and later migrated to the ministry infrastructure.
	71	+% TODO: podemos citar nosso paper aceito na IEEE e não citar este último detalhes
	72	+
	73	+
	74	+The main conflicts in the development process of the platform arose from the
	75	+very nature of traditional and agile approaches: the government expected fully
	76	+specified functionalities before implementation, a large volume of
	77	+documentation, formalization of reports with full functionality deliveries,
	78	+function point calculations for changes in requirements; the academy understood
	79	+that features should be broken down into small functionalities with short-term
	80	+deliverables for validation, decisions about what would be developed and how it
	81	+would be developed should be collaboratively taken between client and
	82	+developers, roles were flexible and organized organically.
	83	+
	84	+%TODO: ainda falta fechar com algo
...	...