Commit e174606afaa5253d1a1df4374bfb3db5c711e7e4
1 parent
a62adb2e
Exists in
master
and in
3 other branches
Siqueiras contribution
Showing
9 changed files
with
119 additions
and
62 deletions
Show diff stats
opensym2017/content/01-introduction.tex
| @@ -10,9 +10,9 @@ Government released a portal named Brazilian Public Software | @@ -10,9 +10,9 @@ Government released a portal named Brazilian Public Software | ||
| 10 | goal of sharing FOSS projects developed by, or for, the Brazilian | 10 | goal of sharing FOSS projects developed by, or for, the Brazilian |
| 11 | Government. Additionally, the Brazilian legal instrument on software | 11 | Government. Additionally, the Brazilian legal instrument on software |
| 12 | contracting (known as IN 04/2012) mandates that public agents must give | 12 | contracting (known as IN 04/2012) mandates that public agents must give |
| 13 | -priority to solutions available in the SPB Portal. In short, the | 13 | +priority to solutions available on the SPB Portal. In short, the |
| 14 | acquisition of a proprietary solution must be explicitly justified by | 14 | acquisition of a proprietary solution must be explicitly justified by |
| 15 | -demonstrating that there is no suitable alternative in the SPB Portal. | 15 | +demonstrating that there is no suitable alternative on the SPB Portal. |
| 16 | In 2013, the Brazilian Federal Court issued a ruling document | 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 | 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 | 18 | agile methodologies in software development contracts with the public |
opensym2017/content/02-spb.tex
| @@ -50,7 +50,7 @@ their software available on the SPB platform. | @@ -50,7 +50,7 @@ their software available on the SPB platform. | ||
| 50 | The concept of Brazilian Public Software goes beyond FOSS. In addition | 50 | The concept of Brazilian Public Software goes beyond FOSS. In addition |
| 51 | to being licensed under a FOSS license, a SPB needs to have explicit | 51 | to being licensed under a FOSS license, a SPB needs to have explicit |
| 52 | guarantees that it is a public good, and that project must be available | 52 | guarantees that it is a public good, and that project must be available |
| 53 | -in the SPB portal. Being a true public good assumes requirements that | 53 | +on the SPB portal. Being a true public good assumes requirements that |
| 54 | can not be met solely by means of FOSS licensing. For example, there | 54 | can not be met solely by means of FOSS licensing. For example, there |
| 55 | must be a relaxed trademark usage policy by the original vendor that | 55 | must be a relaxed trademark usage policy by the original vendor that |
| 56 | does not stop eventual competitors from advertising services for that | 56 | does not stop eventual competitors from advertising services for that |
opensym2017/content/04-requirements.tex
| @@ -18,27 +18,27 @@ After these 3 rounds discussing the new SPB platform, the Brazilian government | @@ -18,27 +18,27 @@ After these 3 rounds discussing the new SPB platform, the Brazilian government | ||
| 18 | listed about 145 requirements and developed a ``mind | 18 | listed about 145 requirements and developed a ``mind |
| 19 | map''\footnote{\url{https://softwarepublico.gov.br/social/spb/gallery/mapaconceitual.png}} | 19 | map''\footnote{\url{https://softwarepublico.gov.br/social/spb/gallery/mapaconceitual.png}} |
| 20 | to guide the SPB portal evolution. In this scenario, the 10 most voted | 20 | to guide the SPB portal evolution. In this scenario, the 10 most voted |
| 21 | -requirements were, for example: | 21 | +requirements were: |
| 22 | 22 | ||
| 23 | \begin{enumerate} | 23 | \begin{enumerate} |
| 24 | 24 | ||
| 25 | -\item Source code repository with public access. | ||
| 26 | -\item Visit community pages without login. | ||
| 27 | -\item Distributed version control system. | ||
| 28 | -\item Scores of users and developers collaboration. | ||
| 29 | -\item Search software by features. | ||
| 30 | -\item Integration with social networks. | ||
| 31 | -\item Repository for future ideas and requirements. | ||
| 32 | -\item Friendly URL to access a public software community page. | ||
| 33 | -\item User feedback about a public software. | ||
| 34 | -\item Report of the experience about the use of a public software. | 25 | +\item Source code repository with public access; |
| 26 | +\item Visit community pages without login; | ||
| 27 | +\item Distributed version control system; | ||
| 28 | +\item Scores of users and developers collaboration; | ||
| 29 | +\item Search software by features; | ||
| 30 | +\item Integration with social networks; | ||
| 31 | +\item Repository for future ideas and requirements; | ||
| 32 | +\item Friendly URL to access a public software community page; | ||
| 33 | +\item User feedback about a public software; | ||
| 34 | +\item Report of the experience about the use of a public software; | ||
| 35 | 35 | ||
| 36 | \end{enumerate} | 36 | \end{enumerate} |
| 37 | 37 | ||
| 38 | \begin{figure}[hbt] | 38 | \begin{figure}[hbt] |
| 39 | \centering | 39 | \centering |
| 40 | \includegraphics[width=\linewidth]{figures/technological-requirements.png} | 40 | \includegraphics[width=\linewidth]{figures/technological-requirements.png} |
| 41 | - \caption{Technological requirements overview.} | 41 | + \caption{Technological requirements.} |
| 42 | \label{fig:requirements} | 42 | \label{fig:requirements} |
| 43 | \end{figure} | 43 | \end{figure} |
| 44 | 44 | ||
| @@ -57,18 +57,18 @@ features such as: | @@ -57,18 +57,18 @@ features such as: | ||
| 57 | 57 | ||
| 58 | \begin{enumerate} | 58 | \begin{enumerate} |
| 59 | 59 | ||
| 60 | -\item An organized public software catalog. | ||
| 61 | -\item Social network environment (profiles for users, software pages, and community pages). | ||
| 62 | -\item Content Management Systems (CMS) features. | ||
| 63 | -\item Web-based Git repository manager with wiki and issue tracking features. | ||
| 64 | -\item Mailing lists and discussion forums. | 60 | +\item An organized public software catalog; |
| 61 | +\item Social network environment (profiles for users, software pages, and community pages); | ||
| 62 | +\item Content Management Systems (CMS) features; | ||
| 63 | +\item Web-based Git repository manager with wiki and issue tracking features; | ||
| 64 | +\item Mailing lists and discussion forums; | ||
| 65 | 65 | ||
| 66 | \end{enumerate} | 66 | \end{enumerate} |
| 67 | 67 | ||
| 68 | Other requirements were also planned during the conception phase of the | 68 | Other requirements were also planned during the conception phase of the |
| 69 | SPB evolution project, such as an integrated search engine and a | 69 | SPB evolution project, such as an integrated search engine and a |
| 70 | web-based source code static analysis monitor. By analyzing all of these | 70 | web-based source code static analysis monitor. By analyzing all of these |
| 71 | -requirements, we proposed the technological requirements overview | 71 | +requirements, we proposed the technological requirements |
| 72 | illustrated in Figure \ref{fig:requirements} to guide the development of | 72 | illustrated in Figure \ref{fig:requirements} to guide the development of |
| 73 | the new SPB platform. In other words, we have designed the SPB evolution | 73 | the new SPB platform. In other words, we have designed the SPB evolution |
| 74 | project based on existing FOSS tools. However, the integration of | 74 | project based on existing FOSS tools. However, the integration of |
opensym2017/content/05-architecture.tex
| @@ -50,17 +50,17 @@ for: | @@ -50,17 +50,17 @@ for: | ||
| 50 | \begin{itemize} | 50 | \begin{itemize} |
| 51 | \item \textit{Centralized authentication}: Users are automatically | 51 | \item \textit{Centralized authentication}: Users are automatically |
| 52 | identified for each application without having to enter login | 52 | identified for each application without having to enter login |
| 53 | -credentials on each of them. | 53 | +credentials on each of them; |
| 54 | \item \textit{Visual consistency}: Colab is able to change the HTML | 54 | \item \textit{Visual consistency}: Colab is able to change the HTML |
| 55 | code produced by the integrated applications, such as defining default | 55 | code produced by the integrated applications, such as defining default |
| 56 | template or reusing common HTML pages, in order to provide a unified | 56 | template or reusing common HTML pages, in order to provide a unified |
| 57 | -interface. | 57 | +interface; |
| 58 | \item \textit{Relaying of events between applications}: The | 58 | \item \textit{Relaying of events between applications}: The |
| 59 | integrated applications or Colab itself are able to trigger an action | 59 | integrated applications or Colab itself are able to trigger an action |
| 60 | -on another application. | 60 | +on another application; |
| 61 | \item \textit{Integrated search engine}: It is possible to set up | 61 | \item \textit{Integrated search engine}: It is possible to set up |
| 62 | exactly which data needs to be indexed from each application and how | 62 | exactly which data needs to be indexed from each application and how |
| 63 | -users are directed to this information on correspondent application. | 63 | +users are directed to this information on correspondent application; |
| 64 | \end{itemize} | 64 | \end{itemize} |
| 65 | 65 | ||
| 66 | Colab implements this integration by working as a reverse proxy for the | 66 | Colab implements this integration by working as a reverse proxy for the |
| @@ -70,9 +70,7 @@ Colab before reaching them. | @@ -70,9 +70,7 @@ Colab before reaching them. | ||
| 70 | Initially, Colab had support for a small set of applications (Trac, GNU | 70 | Initially, Colab had support for a small set of applications (Trac, GNU |
| 71 | Mailman, and Apache Lucene) and support for them was hard-coded. Our | 71 | Mailman, and Apache Lucene) and support for them was hard-coded. Our |
| 72 | team evolved Colab so that it can now receive plugins that add support | 72 | team evolved Colab so that it can now receive plugins that add support |
| 73 | -new applications without the need of changes to the Colab core. We also | ||
| 74 | -developed plugins to be used in the SPB platform: Noosfero, GitLab, and | ||
| 75 | -Mezuro. | 73 | +new applications without the need of changes to the Colab core. |
| 76 | 74 | ||
| 77 | \subsection{Noosfero} | 75 | \subsection{Noosfero} |
| 78 | 76 | ||
| @@ -98,9 +96,9 @@ tracking. | @@ -98,9 +96,9 @@ tracking. | ||
| 98 | 96 | ||
| 99 | \subsection{Mezuro} | 97 | \subsection{Mezuro} |
| 100 | 98 | ||
| 101 | -Mezuro\footnote{\url{http://mezuro.org/}} is a platform to collect source code | ||
| 102 | -metrics to monitor the internal quality of software written in C, C++, | ||
| 103 | -Java, Python, Ruby, and PHP. | 99 | +Mezuro\footnote{\url{http://mezuro.org/}} \cite{mezuro_oss} is a platform to |
| 100 | +collect source code metrics to monitor the internal quality of software written | ||
| 101 | +in C, C++, Java, Python, Ruby, and PHP. | ||
| 104 | 102 | ||
| 105 | In general, source code metrics tools also do not present a friendly way | 103 | In general, source code metrics tools also do not present a friendly way |
| 106 | to interpret its results and, even more, do not follow a standardization | 104 | to interpret its results and, even more, do not follow a standardization |
| @@ -129,7 +127,7 @@ directing requests to one of the integrated applications. It | @@ -129,7 +127,7 @@ directing requests to one of the integrated applications. It | ||
| 129 | post-processes responses from the applications to apply a consistent | 127 | post-processes responses from the applications to apply a consistent |
| 130 | visual appearance, manages authentication, and provides a unified search | 128 | visual appearance, manages authentication, and provides a unified search |
| 131 | functionality: instead of using the redundant restricted search | 129 | functionality: instead of using the redundant restricted search |
| 132 | -functionality of each application, a search in the SPB portal might | 130 | +functionality of each application, a search o n the SPB portal might |
| 133 | return content from any of the applications, be it web pages, mailing | 131 | return content from any of the applications, be it web pages, mailing |
| 134 | list posts, or source code. | 132 | list posts, or source code. |
| 135 | 133 |
opensym2017/content/06-features.tex
| @@ -48,12 +48,15 @@ such as filters (by type of software or category), sorting and score. | @@ -48,12 +48,15 @@ such as filters (by type of software or category), sorting and score. | ||
| 48 | 48 | ||
| 49 | In order to expand the searching scope and cover more types of content, the SPB team | 49 | In order to expand the searching scope and cover more types of content, the SPB team |
| 50 | developed the global search tool. This tool unifies search mechanisms | 50 | developed the global search tool. This tool unifies search mechanisms |
| 51 | -provided by the different collaborative software used in the SPB protal. Any user can | 51 | +provided by the different collaborative software used on the SPB portal. Any user can |
| 52 | find a public content in the context of social networking, mailing list and | 52 | find a public content in the context of social networking, mailing list and |
| 53 | software development. | 53 | software development. |
| 54 | 54 | ||
| 55 | \subsection{Software development tools} | 55 | \subsection{Software development tools} |
| 56 | 56 | ||
| 57 | +Usually, Collaborative Development Environments (CDE) demand a version control | ||
| 58 | +system, trackers, build tools, knowledge centers, and communication tools | ||
| 59 | +\cite{collaboration_tools}. | ||
| 57 | The new SPB also provides | 60 | The new SPB also provides |
| 58 | tools to encourage developers to keep source code and its | 61 | tools to encourage developers to keep source code and its |
| 59 | development activity within the platform. Any created software has, by default, a | 62 | development activity within the platform. Any created software has, by default, a |
opensym2017/content/08-process.tex
| @@ -31,7 +31,7 @@ Development, and Management (MP is the Brazilian acronym). All the project | @@ -31,7 +31,7 @@ Development, and Management (MP is the Brazilian acronym). All the project | ||
| 31 | decisions, validations, and scope definitions were made by them. In this way we | 31 | decisions, validations, and scope definitions were made by them. In this way we |
| 32 | developed software product incrementally, with releases aligned to business | 32 | developed software product incrementally, with releases aligned to business |
| 33 | strategic objectives. As one can see, the project had many different | 33 | strategic objectives. As one can see, the project had many different |
| 34 | -kinds of stakeholders that had to be organized and synchronized. | 34 | +sort of stakeholders that had to be organized and synchronized. |
| 35 | 35 | ||
| 36 | \subsection{Team organization} | 36 | \subsection{Team organization} |
| 37 | 37 | ||
| @@ -45,10 +45,10 @@ basic rules which guided the project organization: | @@ -45,10 +45,10 @@ basic rules which guided the project organization: | ||
| 45 | 45 | ||
| 46 | \begin{enumerate} | 46 | \begin{enumerate} |
| 47 | \item Classes have high priority for undergraduate students; | 47 | \item Classes have high priority for undergraduate students; |
| 48 | - \item Work in pairs whenever possible (locally or remotely). | 48 | + \item Work in pairs whenever possible (locally or remotely); |
| 49 | \item There must be one morning or afternoon per week when | 49 | \item There must be one morning or afternoon per week when |
| 50 | \emph{everyone} should be together physically in the laboratory | 50 | \emph{everyone} should be together physically in the laboratory |
| 51 | - (except of course the remote team members). | 51 | + (except of course the remote team members); |
| 52 | \item Every 3 to 4 months, the senior developers would fly in and work | 52 | \item Every 3 to 4 months, the senior developers would fly in and work |
| 53 | alongside the students for a few days. | 53 | alongside the students for a few days. |
| 54 | \end{enumerate} | 54 | \end{enumerate} |
| @@ -106,7 +106,10 @@ strategical, tactical, and operational views. In a practical point of view, one | @@ -106,7 +106,10 @@ strategical, tactical, and operational views. In a practical point of view, one | ||
| 106 | milestone per user history (feature), and one or more issues for addressing | 106 | milestone per user history (feature), and one or more issues for addressing |
| 107 | each feature. With this approach we achieved two important goals: keeping all | 107 | each feature. With this approach we achieved two important goals: keeping all |
| 108 | the management as close possible to to the source code, and tracking every | 108 | the management as close possible to to the source code, and tracking every |
| 109 | -feature developed during the project. | 109 | +feature developed during the project. Our decision to |
| 110 | +use Wiki initially was empirical, but later reinforced by a research conducted | ||
| 111 | +by Joseph Chao showing the advantage of using Wikis \cite{chao2007student, | ||
| 112 | +opensourcestyle}. | ||
| 110 | 113 | ||
| 111 | \subsection{High-level project management and reporting} | 114 | \subsection{High-level project management and reporting} |
| 112 | 115 | ||
| @@ -128,7 +131,7 @@ diagram that represents our meeting organization. | @@ -128,7 +131,7 @@ diagram that represents our meeting organization. | ||
| 128 | \begin{figure}[hbt] | 131 | \begin{figure}[hbt] |
| 129 | \centering | 132 | \centering |
| 130 | \includegraphics[width=\linewidth]{figures/meeting_flows.png} | 133 | \includegraphics[width=\linewidth]{figures/meeting_flows.png} |
| 131 | - \caption{Meetings cycles} | 134 | + \caption{Meetings cycles.} |
| 132 | \label{fig:meeting} | 135 | \label{fig:meeting} |
| 133 | \end{figure} | 136 | \end{figure} |
| 134 | 137 | ||
| @@ -160,15 +163,19 @@ To keep the track of all of those things we used the SPB itself, | @@ -160,15 +163,19 @@ To keep the track of all of those things we used the SPB itself, | ||
| 160 | especially Gitlab. Basically, we had: | 163 | especially Gitlab. Basically, we had: |
| 161 | 164 | ||
| 162 | \begin{enumerate} | 165 | \begin{enumerate} |
| 163 | - \item Project repository: We have one organization with many repositories | ||
| 164 | - \item Milestones: Each milestone was used to register a release | 166 | + \item Project repository: We have one organization with many repositories; |
| 167 | + \item Milestones: Each milestone was used to register a release; | ||
| 165 | \item Wiki: Each release has one page on wiki with the compilation of | 168 | \item Wiki: Each release has one page on wiki with the compilation of |
| 166 | - strategical meeting | 169 | + strategical meeting; |
| 167 | \item Issues: Each sprint planning generated issues, which we associated to | 170 | \item Issues: Each sprint planning generated issues, which we associated to |
| 168 | the specific milestone and updated the wiki with the issue number related | 171 | the specific milestone and updated the wiki with the issue number related |
| 169 | with them. Finally each developer assigned the issue to itself. | 172 | with them. Finally each developer assigned the issue to itself. |
| 170 | \end{enumerate} | 173 | \end{enumerate} |
| 171 | 174 | ||
| 172 | -Notice that this workflow gave us and the Brazilian government agents | ||
| 173 | -full traceability from a high level view of each feature to the lowest | ||
| 174 | -level (code). | 175 | +Notice that this workflow gave us and the Brazilian government agents full |
| 176 | +traceability from a high level view of each feature to the lowest level (code). | ||
| 177 | +It is important to highlight that we converge to this workflow after many | ||
| 178 | +experiments. For example, we used a tool named Redmine for organizing our tasks | ||
| 179 | +during the sprints, however, this tool revealed inefficient for our case since | ||
| 180 | +the government agents lost part of the project traceability. We realized that | ||
| 181 | +centralize all the work in the SPB portal is the best option for our case. |
opensym2017/content/10-lessons.tex
| @@ -12,7 +12,7 @@ UnB. | @@ -12,7 +12,7 @@ UnB. | ||
| 12 | % | 12 | % |
| 13 | They interacted with professionals that had diverse expertises, and were | 13 | They interacted with professionals that had diverse expertises, and were |
| 14 | able to participate in all levels of the software development process. | 14 | able to participate in all levels of the software development process. |
| 15 | -This contribted to a great learning opportunity, and for a majority of | 15 | +This contributed to a great learning opportunity, and for a majority of |
| 16 | them this was their first professional experience. | 16 | them this was their first professional experience. |
| 17 | 17 | ||
| 18 | \textbf{The participation of experienced professionals is crucial to | 18 | \textbf{The participation of experienced professionals is crucial to |
opensym2017/content/11-conclusion.tex
| @@ -11,7 +11,7 @@ platform - developed by an heterogenous team of professors, master and | @@ -11,7 +11,7 @@ platform - developed by an heterogenous team of professors, master and | ||
| 11 | undergraduate students, IT professionals and governmental managers - provides | 11 | undergraduate students, IT professionals and governmental managers - provides |
| 12 | several modern features from the integration of more than 10 FLOSS systems. | 12 | several modern features from the integration of more than 10 FLOSS systems. |
| 13 | 13 | ||
| 14 | -Second, the 30 months project which developed this platform, results in an | 14 | +Second, the 30 months project which developed this platform results in an |
| 15 | important case that it is possible to mitigate issues seen as conflicting to IT | 15 | important case that it is possible to mitigate issues seen as conflicting to IT |
| 16 | development environment and between industry and academy. We shown that, as | 16 | development environment and between industry and academy. We shown that, as |
| 17 | long as the institution can provide a healthy and challenging environment to | 17 | long as the institution can provide a healthy and challenging environment to |
| @@ -19,8 +19,17 @@ its students, its is possible to conciliate studies and professional training | @@ -19,8 +19,17 @@ its students, its is possible to conciliate studies and professional training | ||
| 19 | in universities. After the end of the project, some students successfully | 19 | in universities. After the end of the project, some students successfully |
| 20 | embraced opportunities in public and private sectos, within national borders | 20 | embraced opportunities in public and private sectos, within national borders |
| 21 | and abroad. Some others went further and started their own companies. | 21 | and abroad. Some others went further and started their own companies. |
| 22 | - | ||
| 23 | We also shown that, with some adaptations/"translation processes", was possible | 22 | We also shown that, with some adaptations/"translation processes", was possible |
| 24 | to conciliate agile methodologies and FOSS practices to develop software to | 23 | to conciliate agile methodologies and FOSS practices to develop software to |
| 25 | governmental organizations with functional hierarchical structures that use | 24 | governmental organizations with functional hierarchical structures that use |
| 26 | traditional development paradigm. | 25 | traditional development paradigm. |
| 26 | + | ||
| 27 | +The SPB project represented an opportunity for us to apply many of our belief | ||
| 28 | +related to FLOSS and Agile Method. We put an enormous effort to create a | ||
| 29 | +friendly environment for everybody involved in the project, and for showing to | ||
| 30 | +the government another way to interact with FLOSS community and university. Our | ||
| 31 | +work style was extremely open and we tried to be transparent for the entire | ||
| 32 | +society. As a consequence, we believe that we still need to investigate more | ||
| 33 | +all the data produced by the project and the impacts on the students. We | ||
| 34 | +expected to conduct a post-mortem analyze in the project since we have many | ||
| 35 | +open data and we applied many concepts that still extra validation. |
opensym2017/spb.bib
| @@ -197,22 +197,15 @@ | @@ -197,22 +197,15 @@ | ||
| 197 | year = {2003} | 197 | year = {2003} |
| 198 | } | 198 | } |
| 199 | 199 | ||
| 200 | -@inproceedings{chao2007, | ||
| 201 | - added-at = {2015-11-18T00:00:00.000+0100}, | ||
| 202 | - author = {Chao, Joseph}, | ||
| 203 | - biburl = {https://www.bibsonomy.org/bibtex/261af946a27913bd7eab12c1e6aa3db3a/dblp}, | ||
| 204 | - booktitle = {CSEET}, | ||
| 205 | - ee = {http://doi.ieeecomputersociety.org/10.1109/CSEET.2007.49}, | ||
| 206 | - interhash = {9d86cf791b047bb6d9484c32cfa0ee92}, | ||
| 207 | - intrahash = {61af946a27913bd7eab12c1e6aa3db3a}, | ||
| 208 | - isbn = {0-7695-2893-7}, | ||
| 209 | - keywords = {dblp}, | ||
| 210 | - pages = {255-261}, | ||
| 211 | - publisher = {IEEE Computer Society}, | ||
| 212 | - timestamp = {2015-11-19T11:37:24.000+0100}, | ||
| 213 | - title = {Student Project Collaboration Using Wikis.}, | 200 | +@inproceedings{chao2007student, |
| 201 | + title={Student project collaboration using Wikis}, | ||
| 202 | + author={Chao, Joseph}, | ||
| 203 | + booktitle={Software Engineering Education \& Training, 2007. CSEET'07. 20th Conference on}, | ||
| 204 | + pages={255--261}, | ||
| 205 | + year={2007}, | ||
| 214 | url = {http://dblp.uni-trier.de/db/conf/csee/csee2007.html}, | 206 | url = {http://dblp.uni-trier.de/db/conf/csee/csee2007.html}, |
| 215 | - year = {2007} | 207 | + publisher = {IEEE Computer Society}, |
| 208 | + organization={IEEE} | ||
| 216 | } | 209 | } |
| 217 | 210 | ||
| 218 | @inproceedings{tosi2015, | 211 | @inproceedings{tosi2015, |
| @@ -257,3 +250,50 @@ | @@ -257,3 +250,50 @@ | ||
| 257 | note = {In: 2020 FLOSS Roadmap}, | 250 | note = {In: 2020 FLOSS Roadmap}, |
| 258 | year = {2008} | 251 | year = {2008} |
| 259 | } | 252 | } |
| 253 | + | ||
| 254 | + | ||
| 255 | +@book{refactoring, | ||
| 256 | + title={Refactoring for software design smells: Managing technical debt}, | ||
| 257 | + author={Suryanarayana, Girish and Samarthyam, Ganesh and Sharma, Tushar}, | ||
| 258 | + year={2014}, | ||
| 259 | + publisher={Morgan Kaufmann} | ||
| 260 | +} | ||
| 261 | + | ||
| 262 | +@article{mezuro_oss, | ||
| 263 | + title={Mezuro: Understanding source code metrics}, | ||
| 264 | + author={Guedes and Meirelles and Manzo and Camarinha}, | ||
| 265 | + journal={International Conference on Open Source Systems}, | ||
| 266 | + volume={01}, | ||
| 267 | + year={2017}, | ||
| 268 | + publisher={OSS} | ||
| 269 | +} | ||
| 270 | + | ||
| 271 | +@article{collaboration_tools, | ||
| 272 | + title={Collaboration tools for global software engineering}, | ||
| 273 | + author={Lanubile, Filippo and Ebert, Christof and Prikladnicki, Rafael and Vizca{\'\i}no, Aurora}, | ||
| 274 | + journal={IEEE software}, | ||
| 275 | + volume={27}, | ||
| 276 | + number={2}, | ||
| 277 | + year={2010}, | ||
| 278 | + publisher={IEEE} | ||
| 279 | +} | ||
| 280 | + | ||
| 281 | +@article{parker2007wiki, | ||
| 282 | + title={Wiki as a teaching tool}, | ||
| 283 | + author={Parker, Kevin and Chao, Joseph}, | ||
| 284 | + journal={Interdisciplinary Journal of e-learning and Learning Objects}, | ||
| 285 | + volume={3}, | ||
| 286 | + number={1}, | ||
| 287 | + pages={57--72}, | ||
| 288 | + year={2007}, | ||
| 289 | + publisher={Informing Science Institute} | ||
| 290 | +} | ||
| 291 | + | ||
| 292 | +@inproceedings{opensourcestyle, | ||
| 293 | + title={Open source-style collaborative development practices in commercial projects using github}, | ||
| 294 | + author={Kalliamvakou, Eirini and Damian, Daniela and Blincoe, Kelly and Singer, Leif and German, Daniel M}, | ||
| 295 | + booktitle={Proceedings of the 37th International Conference on Software Engineering-Volume 1}, | ||
| 296 | + pages={574--585}, | ||
| 297 | + year={2015}, | ||
| 298 | + organization={IEEE Press} | ||
| 299 | +} |
