Commit 730ce0ceb52cf55a183d72f5e7656f3b837f4449
1 parent
df760de3
Exists in
master
and in
3 other branches
[icse2018] fix make
Showing
2 changed files
with
16 additions
and
18 deletions
Show diff stats
icse2018/content/01-introduction.tex
... | ... | @@ -3,8 +3,8 @@ |
3 | 3 | %Falar sobre unir tradicional (guiado por tarefas e atividades) e agil (guiado por funcionalidades) - nerur et al |
4 | 4 | %Falar sobre mudanças estrutura organizacional organica (agil) e burocratica (tradicional) |
5 | 5 | |
6 | -E-government projects are different from the others due to their complexity in | |
7 | -terms of organizational size; proportional resistance to changes; innovation; | |
6 | +Egovernment projects are different from the others due to their complexity in | |
7 | +terms of organizational size, proportional resistance to changes, innovation, | |
8 | 8 | impacts to end users and policies. The partnership between government and |
9 | 9 | academia could be seen as a means of transferring technological knowledge for |
10 | 10 | the creation of innovative e-government projects. This type of collaboration has |
... | ... | @@ -23,31 +23,31 @@ characterized by the predictive approach, focus on documentation, processes |
23 | 23 | oriented, and heavy based on tools\cite{comparisonAgileTraditional}. The agile |
24 | 24 | method, on the other hand, embraces the adaptative approach. It is characterized |
25 | 25 | by the people-oriented approach \cite{agileSoftwareDevelopment}, the |
26 | -collaboration with clients \cite{theNewMethodology}, small self-organized teams | |
26 | +collaboration with clients \cite{theNewMethodology}, small selforganized teams | |
27 | 27 | \cite{peopleFactor}, and the flexibility regarding planning |
28 | 28 | \cite{agileSoftwareDevelopmentEco}. In a nutshell, both methodologies intend to |
29 | 29 | increase the chance of the project success. While industry and academia are |
30 | 30 | aligned on the use of agile methodologies for software development, the |
31 | -traditional approach is still preferred by the government (?). | |
31 | +traditional approach is still preferred by the government. | |
32 | 32 | |
33 | 33 | When government and academia decide to come together for the development of an |
34 | 34 | e-government solution, management processes of each institution needs to be |
35 | 35 | aligned. Changing the software development process represents a complex |
36 | 36 | organizational change that impact several aspects such as structure, culture, |
37 | -and management practices. However, neither culture nor values can be easily | |
38 | -modified and the effort for this kind of movement does not seem feasible for | |
37 | +and management practices. However, neither culture nor values can be easily | |
38 | +change and the effort for this kind of movement does not seem feasible for | |
39 | 39 | development projects with tight deadlines and budgets. |
40 | 40 | |
41 | -In this article we present practical ways to harmonize the traditional and agile | |
41 | +This paper present practical ways to harmonize the traditional and agile | |
42 | 42 | approach in the management of a partnership project between government and |
43 | -academia. These practices are evidenced and validated using the case of the SPB | |
44 | -project, which created an unprecedented platform for the Brazilian government. | |
45 | -For this, we interviewed the various roles involved in the project: employees | |
46 | -and stakeholders of the planning ministry and senior students and developers | |
47 | -from the University of Brasília and São Paulo. Together, we analyze data | |
48 | -collected from the management and communication tools used during 30 months of | |
49 | -the project to find best practices, discuss the conflicts and validate lessons | |
50 | -learned reported in our previous work\cite{meirelles2017spb} . | |
43 | +academia. For this, we interviewed members involved in the project with distinct | |
44 | +roles: requirement analysts and stakeholders of the Brazilian Ministry of | |
45 | +Planning (MPOG), students from the University of Brasília and São Paulo and | |
46 | +senior developers. We also analyze data collected from the management and | |
47 | +communication tools. We these results, we evidence best practices adopted on a | |
48 | +30-months project to create an unprecedented platform for the Brazilian | |
49 | +government. We also validate lessons learned reported in our previous | |
50 | +work\cite{meirelles2017spb}. | |
51 | 51 | |
52 | 52 | % TODO: Verificar as seções |
53 | 53 | Section \ref{sec:relatedwork} discuss the related work on blablabla. Section \ref{sec:casestudy} presents blablabla. Section | ... | ... |
icse2018/content/04-case.tex
1 | 1 | \section{The Case Study} |
2 | 2 | \label{sec:casestudy} |
3 | 3 | |
4 | -%In this section, we present the SPB platform (its goals and its users) and describe the three-years-long project for the evolution of the platform (its development and management process and its organizational structure: team, coordination, roles and interactions). We will also describe the governmental organizational structure and how they managed the project (staff, roles, documentation / reports required) and, finally, we will present possible points of conflict and their possible impacts on the project. | |
5 | - | |
6 | 4 | |
7 | 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. |
8 | 6 | |
9 | -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 & 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. | |
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. | |
10 | 8 | |
11 | 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. |
12 | 10 | ... | ... |