Commit f196d625de81118aaf4e289e8d83ca69b0f1bdd7
Exists in
master
and in
3 other branches
Merge branch 'master' of softwarepublico.gov.br:softwarepublico/articles
Conflicts: opensym2017/spb.bib
Showing
6 changed files
with
181 additions
and
146 deletions
Show diff stats
opensym2017/content/00-abstract.tex
1 | 1 | \begin{abstract} |
2 | 2 | |
3 | -The Brazilian Public Software (SPB) is a program by the Brazilian Federal | |
4 | -Government to foster the sharing and collaboration on Free/Libre/Open Source | |
5 | -Software (FLOSS) solutions for the public administration. In the one hand, | |
6 | -Brazilian Public Softwares have some differences from FLOSS projects, in | |
7 | -particular, the software is considered a public good and the Federal government | |
8 | -assumes some responsibilities related to its use. In the other hand, the | |
3 | +The Brazilian Public Software (SPB) is a program promoted by the Brazilian Federal | |
4 | +Government to foster sharing and collaboration on Free/Libre/Open Source | |
5 | +Software (FLOSS) solutions for the public administration. On the one hand, | |
6 | +Brazilian Public Software has some differences from other FLOSS projects. In | |
7 | +particular, the public software is considered a public good and the Federal Government | |
8 | +assumes some responsibilities related to its use. On the other hand, the | |
9 | 9 | software development principles are the same: the trend towards |
10 | -decentralization in decision-making, the information and development sharing, | |
11 | -and the continuous feedback. In this context, we have designed a platform based | |
12 | -on the integration and evolution of existing FLOSS tools. Nowadays, the SPB | |
13 | -Portal provides several modern features for software collaborative development, | |
14 | -helping the Brazilian public administration to share its solutions. In this | |
10 | +decentralization in decision-making, information and code sharing, | |
11 | +and continuous feedback. In this context, we have designed the SPB Portal, a platform based | |
12 | +on the integration and evolution of existing FLOSS tools. Nowadays, it | |
13 | +provides several modern features for software collaborative development, | |
14 | +helping the Brazilian public administration in sharing its solutions. In this | |
15 | 15 | paper, we present this integrated software development platform that was |
16 | -developed for the program by a heterogeneous team composed by professors, | |
17 | -master students, undergraduate students and professionals from FLOSS | |
16 | +developed for the SPB program by a heterogeneous team composed by professors, | |
17 | +master students, undergraduate students, and professionals from FLOSS | |
18 | 18 | communities. The development of this platform used several FLOSS applications, |
19 | -providing a non-trivial integration among them, as well as, have generated | |
20 | -several contributed features back to them. In this experience report, alongside | |
21 | -the platform architecture, features, and the user experience efforts carried | |
22 | -out, we also discuss our work process, based on agile and free software | |
23 | -development practices, and the lessons learned in 30 months work on the SPB | |
19 | +providing a non-trivial integration among them. This effort has also produced | |
20 | +several new features that were contributed back to these FLOSS applications. In this experience report, alongside | |
21 | +the platform architecture, the features, and the user experience challenges, | |
22 | +we also discuss our work process, based on agile and free software | |
23 | +development practices, and the lessons learned in 30 months of work on the SPB | |
24 | 24 | project. |
25 | 25 | |
26 | 26 | \end{abstract} | ... | ... |
opensym2017/content/01-introduction.tex
... | ... | @@ -2,49 +2,50 @@ |
2 | 2 | \label{sec:intro} |
3 | 3 | |
4 | 4 | The Brazilian Federal Government has been |
5 | -improving its software adoption and development processes. For | |
5 | +improving its processes for software contracting and development. For | |
6 | 6 | instance, in 2003, the recommendation to adopt Free/Libre/Open Source |
7 | -Software (FLOSS) become a public policy. In 2007, the Brazilian | |
8 | -Government released a portal named Brazilian Public Software | |
9 | -(\textit{Software Público Brasileiro} -- SPB, in Portuguese), with the | |
7 | +Software (FLOSS) became a public policy. In 2007, the Brazilian | |
8 | +Government released the Brazilian Public Software Portal | |
9 | +(\textit{Portal do Software Público Brasileiro}, in Portuguese), with the | |
10 | 10 | goal of sharing FLOSS projects developed by, or for, the Brazilian |
11 | 11 | Government. Additionally, the Brazilian legal instrument on software |
12 | -contracting (known as IN 04/2012) mandates that public agents must give | |
13 | -priority to solutions available on the SPB Portal. In short, the | |
12 | +contracting (known as IN 04/2012) mandates that public agents must | |
13 | +prioritize solutions available on the SPB Portal. The | |
14 | 14 | acquisition of a proprietary solution must be explicitly justified by |
15 | 15 | demonstrating that there is no suitable alternative on the SPB Portal. |
16 | -In 2013, the Brazilian Federal Court issued a ruling document | |
17 | -(\textit{Acórdão 2314/2013}) about an audit survey regarding the use of | |
18 | -agile methodologies in software development contracts with the public | |
19 | -administration. | |
16 | +In 2013, the Brazilian Federal Court issued a ruling | |
17 | +(\textit{Acórdão 2314/2013}) about contracts between the public administration | |
18 | +and suppliers using agile methodologies in software development. | |
20 | 19 | |
21 | -Despite of that, in practice, free software or agile methodologies, that is, | |
22 | -collaborative and empirical software development methods are not widely | |
23 | -practiced and understood by the Brazilian government agents. Thus, the | |
24 | -hierarchical and traditional processes from the government and the lack | |
25 | -of expertise in real-world software development of its agents produces a | |
26 | -situation of inefficient software development contracts and | |
27 | -unjustifiable expending of taxpayers' money. | |
20 | +Despite of these legal advancements, in practice, Brazilian government agents | |
21 | +still do not practice, or even understand, | |
22 | +collaborative and empirical software development methods, | |
23 | +such as free software or agile methodologies. Thus, | |
24 | +hierarchical and traditional processes and the lack | |
25 | +of expertise of public agents in real-world software development produce | |
26 | +inefficiency in software development contracts, besides | |
27 | +unjustifiable expending of taxpayers money. | |
28 | 28 | |
29 | -Since 2009, the SPB Portal was having several technical issues. The original | |
30 | -codebase was not being developed anymore, also, there was a large amount of | |
31 | -knowingly non-optimal or wrong design decisions to overcome (in other words, | |
32 | -technical debt \cite{refactoring}). The system was a modified version of an | |
29 | +Since 2009, the SPB Portal has had several technical issues. The original | |
30 | +codebase development has stopped, leaving substantial | |
31 | +technical debt~\cite{refactoring}. | |
32 | +The system was a modified version of an | |
33 | 33 | existing FLOSS platform called OpenACS \footnote{\url{http://openacs.org}}, and |
34 | -the old SPB portal was not being updated anymore against the official OpenACS | |
35 | -releases. In this scenario, the portal maintenance has become increasingly | |
34 | +the old SPB Portal did not receive updates from OpenACS releases. | |
35 | +In this scenario, the portal maintenance has become increasingly | |
36 | 36 | difficult. |
37 | 37 | |
38 | -After some events and meetings to collect requirements from the federal | |
39 | -government and from the society, a new platform for the SPB Portal was | |
40 | -developed, among January 2014 and June 2016, by the University of Brasília | |
38 | +After collecting requirements from the Federal | |
39 | +Government and society, a new platform for the SPB Portal was | |
40 | +developed, between January 2014 and June 2016, by the University of Brasília | |
41 | 41 | (UnB) and the University of São Paulo (USP) in a partnership with the Brazilian |
42 | -Ministry of Budget, Planning, and Management (MP). It was designed as an | |
43 | -integrated platform for collaborative software development \cite{bobr2003}, and | |
44 | -includes functionality for social networking, mailing lists, version control | |
42 | +Ministry of Planning, Budget, and Management (MP). It was designed as an | |
43 | +integrated platform for collaborative software development \cite{bobr2003}, | |
44 | +including social networking, mailing lists, version control | |
45 | 45 | system, and source code quality monitoring. To coordinate and develop this |
46 | -project during 30 months, UnB received from the Brazilian Federal Government a | |
47 | -total of 2,619,965.00 BRL (about 750,000.00 USD in June 2016). | |
46 | +project during 30 months, UnB was funded by a grant | |
47 | +of 2,619,965.00 BRL (about 750,000.00 USD in June 2016) | |
48 | +from the Federal Government. | |
48 | 49 | |
49 | 50 | \begin{figure*}[hbt] |
50 | 51 | \centering |
... | ... | @@ -53,44 +54,45 @@ total of 2,619,965.00 BRL (about 750,000.00 USD in June 2016). |
53 | 54 | \label{fig:spb} |
54 | 55 | \end{figure*} |
55 | 56 | |
56 | -The project was developed by a team of 3 professors, 2 masters students, and | |
57 | -approximately 50 undergraduate students (not all of them at the same time, | |
58 | -though -- graduations and other events triggered changes in the team) together | |
59 | -with 2 professional designers and 6 senior developers from free software | |
60 | -communities. The professors and all undergraduate student were from UnB, and | |
61 | -the master students were from USP. Regarding the designers and senior | |
62 | -developers, 7 of 8 they were living outside of Brasília: Curitiba/Brazil, São | |
63 | -Paulo/Brazil, Ribeirão Preto/Brazil, Salvador/Brazil, Santo Domingo/Dominican | |
64 | -Republic, and Montreal/Canada. In other words, we had a team working in | |
65 | -distributed collaborative virtual environment. This diversity of actors and the | |
66 | -relationships between industry, academy and government also made the project a | |
57 | +The project was developed by a team of three professors, two masters students, | |
58 | +about fifty undergraduate students (not all of them at the same time, | |
59 | +since the team changed along the time), | |
60 | +two professional designers, and six senior developers from free software | |
61 | +communities. Professors and undergraduate students were from UnB and | |
62 | +master students were from USP. Regarding the designers and senior | |
63 | +developers, seven of eight were living outside Brasília, the UnB location. | |
64 | +Two of them were abroad at Dominican Republic and Canada. | |
65 | +In other words, we had a distributed team working in a | |
66 | +collaborative virtual environment. This diversity of actors and the | |
67 | +relationships between industry, academy, and government also made the project a | |
67 | 68 | valued opportunity to explore the benefits and challenges of using |
68 | -FLOSS\cite{kon2011,deKoenigsberg2008, fagerholm2013, fagerholm2014} and | |
69 | -Agile\cite{steghofer2016, harzl2017} practices for Software Engineering | |
69 | +FLOSS~\cite{kon2011,deKoenigsberg2008, fagerholm2013, fagerholm2014} and | |
70 | +Agile~\cite{steghofer2016, harzl2017} practices for Software Engineering | |
70 | 71 | education. |
71 | 72 | |
72 | 73 | Figure \ref{fig:spb} shows the home page of this integrated platform. |
73 | -All development was done in the open, and the changes we needed in the | |
74 | -FLOSS tools were contributed back to their respective communities. Our | |
74 | +All the code was developed as open source. The changes we needed in the | |
75 | +FLOSS tools were implemented by ourselves and | |
76 | +contributed back to their respective communities. Our | |
75 | 77 | process was based on agile practices and FLOSS communities interaction. |
76 | -We defined development cycles and released 5 versions of the new SPB | |
78 | +We incrementally released five versions of the new SPB | |
77 | 79 | Portal. The first release (beta) was in September 2014, only 9 months |
78 | 80 | from the beginning of the project. The old portal was shut down in |
79 | 81 | September 2015. Finally, the last version, illustrated in Figure 1, was |
80 | 82 | released in June 2016. |
81 | 83 | |
82 | -In this paper, we present an overview of this new generation of the SPB Portal. | |
83 | -The paper shares the methodology employed to develop this project, in | |
84 | -partnership with the Brazilian Federal Government, to comply with its | |
85 | -requirements at the same time to be as faithful as possible to FLOSS | |
86 | -development \cite{mockus2002, tosi2015}. Moreover, we discuss several lessons | |
87 | -learned to provide a distributed collaborative virtual environment involving | |
88 | -alarge undergraduate student team and remote senior developers. Lastly, we | |
89 | -released an unprecedented platform for the Brazilian government applying | |
84 | +In this paper, we present an overview of the new SPB Portal. | |
85 | +The paper shares the methodology employed to develop this project. | |
86 | +This methodology has the goals of satisfying Government | |
87 | +requirements and adhering as much as possible to FLOSS and agile | |
88 | +practices~\cite{mockus2002, tosi2015}. Moreover, we discuss lessons | |
89 | +learned in providing a distributed and collaborative virtual environment involving | |
90 | +a large undergraduate students team and remote senior developers. Finally, we | |
91 | +released an innovative platform for helping the Brazilian government to apply | |
90 | 92 | empirical software development methods. This case can help other projects to |
91 | 93 | overcome similar software engineering challenges in the future, as well as to |
92 | 94 | illustrate how universities can improve the real-world experience of their |
93 | -students by means of this kind of project. | |
95 | +students. | |
94 | 96 | |
95 | 97 | The remainder of this work is organized as follows. |
96 | 98 | Section \ref{sec:spb}... | ... | ... |
opensym2017/content/11-lessons.tex
1 | 1 | \section{Lessons Learned} |
2 | 2 | \label{sec:lessons} |
3 | 3 | |
4 | -\textbf{How to involve students real-world projects, interacting with | |
4 | +\textbf{How to involve students in real-world projects, interacting with | |
5 | 5 | real customers.} |
6 | 6 | % |
7 | 7 | Our team was mainly composed of software engineering undergraduate |
8 | -student, who had the opportunity to interact with senior developers and | |
9 | -designers inside the team, as well as with the team of technicians and | |
8 | +students, who had the opportunity to interact with senior developers and | |
9 | +designers on the team, as well as with the team of technicians and | |
10 | 10 | managers from the Brazilian Government, and the management team from |
11 | 11 | UnB. |
12 | 12 | % |
13 | -They interacted with professionals that had diverse expertises, and were | |
13 | +The students interacted with professionals of diverse fields of expertise, and they were | |
14 | 14 | able to participate in all levels of the software development process. |
15 | -This contributed to a great learning opportunity, and for a majority of | |
16 | -them this was their first professional experience. | |
15 | +This contributed to a great learning opportunity. Moreover, for the majority of | |
16 | +the students, this was a first professional experience. | |
17 | 17 | |
18 | 18 | \textbf{The participation of experienced professionals is crucial to |
19 | -success of the project.} | |
19 | +the success of the project.} | |
20 | 20 | One important factor for the students was the composition of the teams |
21 | 21 | with the participation of experienced professionals. |
22 | 22 | % |
... | ... | @@ -27,7 +27,7 @@ pressure. |
27 | 27 | % |
28 | 28 | On the management side, the active participation of professors -- who |
29 | 29 | are, in the end, the ones responsible for the project -- is crucial to |
30 | -make sure student participation is conducted in a healthy way, and is an | |
30 | +make sure students participation is conducted in a healthy way, and it is an | |
31 | 31 | instance of leading by example. |
32 | 32 | |
33 | 33 | \textbf{A balanced relationship between academia and industry.} |
... | ... | @@ -47,66 +47,66 @@ And even under a potentially adverse environment, the project delivered |
47 | 47 | the desired solution with success. |
48 | 48 | % |
49 | 49 | At the end of the project, we noted that the skills developed by the |
50 | -students were at the state of art of the software engineering practice. | |
50 | +students were at the software engineering state of the art. | |
51 | 51 | After the project ended, we had team members successfully embracing |
52 | -opportunities in public, private, national and international | |
53 | -organizations, in addition to those students that went into | |
54 | -entrepreneurship and opened their own companies. | |
52 | +opportunities in public, private, national, and international | |
53 | +organizations, in addition to those students that | |
54 | +opened their own companies. | |
55 | 55 | |
56 | 56 | \textbf{Managing different organizational cultures.} |
57 | 57 | In the beginning of the project, the Brazilian Government stakeholders |
58 | -had certain expectations about the development of project that, let's | |
59 | -say, didn't exactly match our work based on agile and FOSS practices. | |
58 | +had certain expectations about the project development that, let's | |
59 | +say, didn't exactly match our work style based on agile and FOSS practices. | |
60 | 60 | % |
61 | -We had to develop strategies that would support different these | |
61 | +We had to develop strategies that would support these different | |
62 | 62 | organizational cultures. As reported in Section \ref{sec:process}, the |
63 | 63 | MP is organized in a functional hierarchical organizational structure, |
64 | -typically, a traditional development paradigm. Therefore, we had to | |
64 | +typically adopting a traditional development paradigm. Therefore, we had to | |
65 | 65 | create a translation process between our team and the MP managers who |
66 | -managed the project on their side assuming a traditional, waterfall | |
66 | +managed the project on their side assuming a traditional waterfall | |
67 | 67 | process. |
68 | 68 | |
69 | -\textbf{Manage higher-level and lower-level goals separately.} | |
70 | -During the initial phase of the project the MP team would often bring | |
71 | -strategic discussions to technical/operational meetings, where we were | |
72 | -supposed to discuss practical, technical decisions. | |
69 | +\textbf{Managing higher-level and lower-level goals separately.} | |
70 | +During the initial phase of the project, the MP team has brought | |
71 | +strategic discussions to technical/operational meetings that | |
72 | +were supposed to be about practical technical decisions. | |
73 | 73 | % |
74 | 74 | This produced a highly complex communication and management environment, |
75 | -overloading the professors because they were supposed to be responsible | |
76 | -for maintaining the strategic alignment of the MP synchronized with | |
77 | -implementation plans of the development team, specially in light of the | |
78 | -aforementioned culture mismatch. Mixing both concerns in the same | |
75 | +overloading the professors because they were supposed | |
76 | +for maintaining the MP strategy synchronized with the | |
77 | +implementation plans of the development team. This was hard, especially because the | |
78 | +aforementioned cultural mismatch. Mixing both concerns in the same | |
79 | 79 | discussions caused confusion on both sides. |
80 | 80 | % |
81 | -Towards the middle and end of the project we were able to keep those | |
81 | +From the middle of the project we were able to keep those | |
82 | 82 | concerns separated, what eased the work of everyone involved. |
83 | 83 | |
84 | 84 | \textbf{Living with ill-advised political decisions.} |
85 | 85 | At the initial phases of the project, by political and personal |
86 | 86 | motivation, the main stakeholders from the Brazilian government imposed |
87 | -the use of Colab to guide the development of the new SPB platform. Our | |
87 | +the use of Colab to guide the development of the new SPB platform. Our | |
88 | 88 | team was totally against the idea because we already knew that Colab was |
89 | 89 | a very experimental project and its adoption could dramatically increase |
90 | -the project complexity. Even though we provided technical reasons to | |
91 | -not utilize Colab, MP was adamant and we had to manage this problem. As | |
92 | -explained in section \ref{sec:architecture} we did massive changes to | |
93 | -it, and at the end of the project we completely rewrote Colab and made | |
90 | +the project complexity. Even though we provided technical reasons to | |
91 | +not utilize Colab, the MP was adamant and we had to manage this problem. As | |
92 | +explained in section \ref{sec:architecture}, we did massive changes to | |
93 | +Colab, and at the end of the project we have completely rewritten it to make | |
94 | 94 | it stable. It is important to notice that the MP compelled us to accept |
95 | -a technical issue based only on political interests, without considering | |
95 | +a technical decision based only on political interests, without considering | |
96 | 96 | all the resources that would be spent due to that decision. At the end |
97 | 97 | of the project, we verified that Colab indeed consumed a vast amount of |
98 | -the budget and increased the project complexity. In the end of the | |
98 | +the budget and increased the project complexity. At the end of the | |
99 | 99 | project and after our analysis on the decision made by the MP, we |
100 | -understand that MP's managers are capable of ignoring technical reasons | |
101 | -in favor to a political decision. | |
100 | +understand that MP managers are capable of ignoring technical reasons | |
101 | +in favor of political decisions. | |
102 | 102 | |
103 | 103 | \textbf{Consider sustainability from the beginning.} |
104 | -In the process of deploying the SPB platform in the MP structure, we had | |
104 | +In the process of deploying the SPB platform in the MP infrastructure we had | |
105 | 105 | to interact with the MP technicians. We did several workshops, training |
106 | 106 | and a meticulous documentation describing all the required procedures to |
107 | 107 | update the platform, however, we realized that the MP technicians |
108 | 108 | constantly avoid the responsibility. After noticing the aforementioned |
109 | -situation, we organized a specific DevOps that completely automated all | |
109 | +situation, we organized a DevOps team that completely automated all | |
110 | 110 | the deployment procedure. We simplified all the platform deployment to a |
111 | 111 | few steps: (1) initial configurations (just ssh configuration) and (2) |
112 | 112 | the execution of simple commands to completely update the platform. By |
... | ... | @@ -114,8 +114,8 @@ the end of the project, we observed that the MP technicians invariably |
114 | 114 | still depended on our support to update the platform even with all the |
115 | 115 | automation provided by us. We were sadly left with a feeling of |
116 | 116 | uncertainty about the future of the platform after the project ended. In |
117 | -hindsight, we realize that the MP dedicated systems analysts and | |
117 | +hindsight, we realize that the MP dedicated system analysts and | |
118 | 118 | managers to the project, but not operations technicians. The later |
119 | -should have been more involved with the process so they could at least | |
120 | -comfortable with managing the platform infrastructure. | |
119 | +should have been more involved with the process so they could at least be | |
120 | +comfortable in managing the platform infrastructure. | |
121 | 121 | ... | ... |
opensym2017/content/12-conclusion.tex
1 | 1 | \section{Conclusion} |
2 | 2 | \label{sec:conclusion} |
3 | 3 | |
4 | -In this paper we present and discuss issues experienced during a government- | |
5 | -funded project, in partnership with University of Brasilia and University of | |
6 | -São Paulo, to evolve the Brazilian Public Software portal. | |
7 | - | |
8 | -The contributions of this paper are twofold. First, we present how an unprecedent | |
9 | -platform was developed and delivered to Brazilian government. This | |
10 | -platform - developed by an heterogenous team of professors, masters and | |
11 | -undergraduate students, IT professionals and governmental managers - provides | |
12 | -several modern features from the integration of more than 10 FLOSS systems. | |
13 | - | |
14 | -Second, the thirty-month long project in which the SPB platform was developed points | |
15 | -out that it is possible to mitigate issues seen as conflicting to the IT | |
16 | -development environment and between industry and academy. The team was engaged in | |
17 | -providing a friendly working environment as well as in showing to governmental agents | |
18 | -another way to interact with the FLOSS community and the university. In the paper, | |
19 | -we try to show that, as long as the institution can provide a healthy and challenging | |
20 | -environment to its students, one may conciliate studies and professional training | |
21 | -in universities. After the end of the project, some students successfully | |
22 | -embraced opportunities in public and private sectos, within national borders | |
23 | -and abroad. Some others went further and started their own companies. | |
4 | +In this paper we presented and discussed issues experienced during a government-funded | |
5 | +project, in partnership with the University of Brasilia and the University of | |
6 | +São Paulo, to evolve the Brazilian Public Software Portal. | |
7 | +Its contributions are twofold. First, we present the strategy used to develop | |
8 | +and to deliver an unprecedented platform to Brazilian government. Second, | |
9 | +based on the results of the SPB Portal project, we point out that it is | |
10 | +possible to mitigate conflicts experienced in the development environment | |
11 | +and to conciliate governmental and academy cultures. | |
12 | + | |
13 | +The SPB portal integrates more than 10 FOSS tools and provides several features, | |
14 | +such as social network, mailing list, version control, content management and | |
15 | +source code quality monitoring. Concerned with the platform susteinability and | |
16 | +maintainabilty, the aforementioned 10 FOSS tools were integrated with minimum | |
17 | +differences from their official versions and the new developed features were | |
18 | +sent upstream to ensure an alignment between the portal systems and their | |
19 | +respective official versions. In the integration process, the main softwares | |
20 | +were identified, specific teams were formed to work with each one of them | |
21 | +and each team was composed of students with different levels of skills and at | |
22 | +least one senior professional. | |
23 | + | |
24 | +In terms of mitigating conflicts, we tried to show that, as long as the | |
25 | +institution can provide a healthy and challenging environment to its students, | |
26 | +one may conciliate studies and professional training in universities. | |
27 | +In our work process, based on open and collaborative software development | |
28 | +practices, students could negotiate their work schedule as well as count on IT | |
29 | +professionals to solve development issues. | |
30 | +Among the students, we have defined coachs for each team and a meta-coach | |
31 | +(coach of whole project). All coaches, together with professors, have | |
32 | +intermediated the comunication between client (Ministry of Planning of Brasil) | |
33 | +and the rest of the group. | |
34 | +After the end of the project, some students successfully | |
35 | +embraced opportunities in public and private sectors, within national borders | |
36 | +and abroad. Some other students went further and started their own companies. | |
37 | + | |
24 | 38 | We also demonstrate that, with some adaptations/"translation processes", it is feasible |
25 | -to conciliate agile methodologies and FOSS practices in order to develop software to | |
39 | +to conciliate agile methodologies and FOSS practices to develop software to | |
26 | 40 | governmental organizations with functional hierarchical structures that use |
27 | 41 | traditional development paradigm. |
42 | +Aiming at reducing client questions about workconclusion, a DevOps front was | |
43 | +created to automate all deploy process and also to work in continuous | |
44 | +delivery. The government was brought to our work environment and interacted | |
45 | +with our management and comunication tools. For the project success, we | |
46 | +focused on providing a friendly working environment as well as on showing to | |
47 | +governmental agents another way to interact with the FLOSS community and the | |
48 | +university. | |
49 | + | |
50 | +\leo{Padronziar uso FOSS vs FLOSS. Qual vcs preferem?} | |
28 | 51 | |
29 | -Future work should use the many data produced by the project to validate and evaluate | |
30 | -how the used FLOSS and Agile practices have impacted the students and also the | |
31 | -governmental development process. For this, we would conduce a \textit{post-mortem} | |
32 | -analyse using the project open data and a survey targeted the involved actors. | |
52 | +Future work should use data produced by the project to validate and evaluate | |
53 | +how the used FOSS and Agile practices have impacted the students and the | |
54 | +governmental development process. For this, we would conduce a \textit{postmortem} | |
55 | +analysis using the project open data and a survey targeting the involved actors. | |
33 | 56 | |
57 | +\textbf{Final remarks} | |
34 | 58 | |
35 | 59 | The portal is available at \url{softwarepublico.gov.br}. All |
36 | 60 | documentation, including detailed architecture and operation manuals are |
37 | 61 | also available\footnote{\url{https://softwarepublico.gov.br/doc/} |
38 | -(in Portuguese only at the moment)}). | |
62 | +(in Portuguese only at the moment)}. | |
39 | 63 | % |
40 | 64 | All the integrated tools are FOSS and our contributions were published |
41 | 65 | in open repositories, available on the SPB Portal itself. We also |
42 | -contributed these features back to the respective communities: that | |
43 | -benefits those communities, as well as us since we can share future | |
66 | +contributed these features back to the respective communities, which | |
67 | +benefits both those communities and us, since we can share future | |
44 | 68 | development and maintenance effort with other organizations that |
45 | -participate in their projects. | |
69 | +participate in these projects. | |
46 | 70 | |
47 | 71 | %=========== |
48 | 72 | % Conclusion | ... | ... |
opensym2017/spb.bib
... | ... | @@ -189,7 +189,8 @@ |
189 | 189 | doi = {10.1016/S0065-2458(03)59001-5}, |
190 | 190 | timestamp = {Sat, 20 May 2017 00:22:37 +0200}, |
191 | 191 | biburl = {http://dblp.uni-trier.de/rec/bib/journals/ac/BoochB03}, |
192 | - bibsource = {dblp computer science bibliography, http://dblp.org} | |
192 | + bibsource = {dblp computer science bibliography, http://dblp.org}, | |
193 | + publisher={Elsevier} | |
193 | 194 | } |
194 | 195 | |
195 | 196 | @inproceedings{chao2007student, |
... | ... | @@ -199,8 +200,7 @@ |
199 | 200 | pages={255--261}, |
200 | 201 | year={2007}, |
201 | 202 | url = {http://dblp.uni-trier.de/db/conf/csee/csee2007.html}, |
202 | - publisher = {IEEE Computer Society}, | |
203 | - organization={IEEE} | |
203 | + publisher = {IEEE Computer Society} | |
204 | 204 | } |
205 | 205 | |
206 | 206 | @inproceedings{tosi2015, | ... | ... |
opensym2017/spb.tex
... | ... | @@ -72,6 +72,13 @@ |
72 | 72 | % by using the "\todo{...}" command. Make sure to disable the draft |
73 | 73 | % option again before submitting your final document. |
74 | 74 | \usepackage{todonotes} |
75 | +\newcommand{\leo}[2][]{\todo[inline,color=yellow!70, #1]{\emph{Léo:} #2}} | |
76 | +\newcommand{\paulo}[2][]{\todo[inline,color=yellow!70, #1]{\emph{Paulo:} #2}} | |
77 | +\newcommand{\melissa}[2][]{\todo[inline,color=yellow!70, #1]{\emph{Melissa:} #2}} | |
78 | +\newcommand{\terceiro}[2][]{\todo[inline,color=yellow!70, #1]{\emph{Terceiro:} #2}} | |
79 | +\newcommand{\siqueira}[2][]{\todo[inline,color=yellow!70, #1]{\emph{Siqueira:} #2}} | |
80 | +\newcommand{\lucas}[2][]{\todo[inline,color=yellow!70, #1]{\emph{Lucas:} #2}} | |
81 | +\newcommand{\hilmer}[2][]{\todo[inline,color=yellow!70, #1]{\emph{Hilmer:} #2}} | |
75 | 82 | |
76 | 83 | % Paper metadata (use plain text, for PDF inclusion and later |
77 | 84 | % re-using, if desired). Use \emtpyauthor when submitting for review |
... | ... | @@ -164,6 +171,8 @@ |
164 | 171 | } |
165 | 172 | } |
166 | 173 | |
174 | + | |
175 | + | |
167 | 176 | \maketitle |
168 | 177 | %------------------------------------------------------------------------------ |
169 | 178 | \input{content/00-abstract} | ... | ... |