First pt-br version for SBQS

Paulo Meireles
1 parent a9aa399f
Showing 11 changed files with 636 additions and 633 deletions Show diff stats
sbqs2017/content/00-abstract.tex
sbqs2017/content/01-introduction.tex
sbqs2017/content/02-spb.tex
sbqs2017/content/03-requirements.tex
sbqs2017/content/04-architecture.tex
sbqs2017/content/05-features.tex
sbqs2017/content/06-ux.tex
sbqs2017/content/07-process.tex
sbqs2017/content/08-contributions.tex
sbqs2017/content/09-lessons.tex
sbqs2017/spb.tex
@@ -6,6 +6,6 @@ helping the Brazilian public administration to share its solutions. In this pape
 \begin{resumo}
-O Software Público Brasileiro (SPB) é um programa do Governo Federal Brasileiro para promover o compartilhamento e a colaboração em soluções de Software Livre para a administração pública. Um Software Público Brasileiro é considerado um bem público e o governo federal assume algumas responsabilidades relacionadas ao seu uso, mas tem os mesmos princípios de desenvolvimento de software livre como a tendência à descentralização na tomada de decisões, o compartilhamento de informações e do desenvolvimento (código), e a interação contínua com seus usuários. Nesse contexto, criamos uma plataforma baseada na integração e evolução de ferramentas FOSS existentes. Hoje em dia, o SPB Portal oferece diversas funcionalidades modernas para o desenvolvimento de software colaborativo, ajudando a administração pública brasileira a compartilhar suas soluções. Neste artigo, apresentamos a plataforma integrada de desenvolvimento de software desenvolvida para o programa por uma equipe heterogênea composta por professores, mestrandos, estudantes de graduação e profissionais das comunidades do software livre. Neste relato de experiência, juntamente com a arquitetura da plataforma, funcionalidades e os esforços na evolução da experiência do usuário, também discutimos nosso processo de trabalho, baseado em práticas de desenvolvimento de software ágil e livre, e as lições aprendidas em 30 meses de trabalho sobre o projeto SPB.
+O Software Público Brasileiro (SPB) é um programa do Governo Federal Brasileiro para promover o compartilhamento e a colaboração em soluções de Software Livre para a administração pública. Um Software Público Brasileiro é considerado um bem público e o governo federal assume algumas responsabilidades relacionadas ao seu uso, mas tem os mesmos princípios de desenvolvimento de software livre como a tendência à descentralização na tomada de decisões, o compartilhamento de informações e do desenvolvimento (código), e a interação contínua com seus usuários. Nesse contexto, criamos uma plataforma baseada na integração e evolução de ferramentas livres existentes. Hoje em dia, o SPB Portal oferece diversas funcionalidades modernas para o desenvolvimento de software colaborativo, ajudando a administração pública brasileira a compartilhar suas soluções. Neste artigo, apresentamos a plataforma integrada de desenvolvimento de software desenvolvida, para o programa SPB, por uma equipe heterogênea composta por professores, mestrandos, estudantes de graduação e profissionais das comunidades do software livre. Neste relato de experiência, juntamente com a arquitetura da plataforma, funcionalidades e os esforços na evolução da experiência do usuário, também discutimos nosso processo de trabalho, baseado em práticas de desenvolvimento de software ágil e livre e as lições aprendidas em 30 meses de trabalho sobre o projeto SPB.
 \end{resumo}
 \section{Introdução}
 \label{sec:intro}
-Durante as últimas décadas, o governo federal brasileiro vem tentando mudar seus processos de adoção e desenvolvimento de software. Por exemplo, em 2003, a recomendação de adotar software livre\footnote{Neste artigo, usamos o termo software livre como referente à Free and Open Source Software (FOSS).} tornou-se uma política pública. Em 2007, o governo brasileiro lançou um portal chamado Software Público Brasileiro (SPB), com o objetivo de compartilhar projetos de software livre desenvolvidos pelo governo brasileiro ou para o mesmo. Adicionalmente, o instrumento jurídico brasileiro de contratação de software (denominado IN 04/2012) determina que os agentes públicos devem priorizar as soluções disponíveis no Portal SPB. Em suma, a aquisição de uma solução proprietária deve ser explicitamente justificada ao demonstrar que não há alternativa adequada no Portal SPB. Em 2013, o Tribunal Federal emitiu o Acórdão 2314/2013 sobre o uso de metodologias ágeis em contratos de desenvolvimento de software com a administração pública.
+Durante as últimas décadas, o governo federal brasileiro vem tentando mudar
+seus processos de adoção e desenvolvimento de software. Por exemplo, em 2003, a
+recomendação de adotar software livre\footnote{Neste artigo, usamos o termo
+software livre como referente à Free and Open Source Software (FOSS).}
+tornou-se uma política pública. Em 2007, o governo brasileiro lançou um portal
+chamado Software Público Brasileiro (SPB), com o objetivo de compartilhar
+projetos de software livre desenvolvidos pelo governo brasileiro ou para o
+mesmo. Adicionalmente, o instrumento jurídico brasileiro de contratação de
+software (denominado IN 04/2012) determina que os agentes públicos devem
+priorizar as soluções disponíveis no Portal SPB. Em suma, a aquisição de uma
+solução proprietária deve ser explicitamente justificada ao demonstrar que não
+há alternativa adequada no Portal SPB. Em 2013, o Tribunal Federal emitiu o
+Acórdão 2314/2013 sobre o uso de metodologias ágeis em contratos de
+desenvolvimento de software com a administração pública.
-Apesar disso, na prática, as metodologias de desenvolvimento de software livre ou ágeis, isto é, os métodos colaborativos e empíricos de desenvolvimento de software, não são amplamente praticadas e entendidas pelos agentes do governo brasileiro. Dessa forma, os processos hierárquicos e tradicionais do governo e a falta de expertise no desenvolvimento de software real de seus agentes produzem uma situação de contratos de desenvolvimento de software ineficiente.
+Apesar disso, na prática, as metodologias de desenvolvimento de software livre
+ou ágeis, isto é, os métodos colaborativos e empíricos de desenvolvimento de
+software, não são amplamente praticadas e entendidas pelos agentes do governo
+brasileiro. Dessa forma, os processos hierárquicos e tradicionais do governo e
+a falta de expertise no desenvolvimento de software real de seus agentes
+produzem uma situação de contratos de desenvolvimento de software ineficiente.
-Desde 2009, o SPB Portal teve vários problemas técnicas. O código original da plataforma não estava mias sendo desenvolvido, e havia uma grande quantidade de dívidas técnicas para superar. O sistema era uma versão modificada de uma plataforma livre existente chamada OpenACS\footnote{\url{http://openacs.org}}, e o antigo portal SPB não estava sendo atualizado com os lançamentos oficiais do OpenACS. Nesse cenário, a manutenção do portal estava se tornando cada vez mais difícil.
+Desde 2009, o SPB Portal teve vários problemas técnicas. O código original da
+plataforma não estava mias sendo desenvolvido, e havia uma grande quantidade de
+dívidas técnicas para superar. O sistema era uma versão modificada de uma
+plataforma livre existente chamada OpenACS\footnote{\url{http://openacs.org}},
+e o antigo portal SPB não estava sendo atualizado com os lançamentos oficiais
+do OpenACS. Nesse cenário, a manutenção do portal estava se tornando cada vez
+mais difícil.
-Depois de alguns eventos e encontros para coletar os requisitos via os agentes do governo federal e da sociedade, foi desenvolvida, entre janeiro de 2014 e junho de 2016, uma nova plataforma para o Portal SPB, pelo Universidade de Brasília (UnB) e da Universidade de São Paulo (USP) em parceria com o Ministério de Orçamento, Planejamento e Gestão (MP). Ele foi projetado como uma plataforma integrada para desenvolvimento de software colaborativo, e inclui funcionalidade para redes sociais, listas de discussão, sistema de controle de versão e monitoramento de qualidade de código-fonte. Para coordenar e desenvolver esse projeto durante 30 meses, a UnB recebeu do Governo Federal Brasileiro um total de 2.619.965,00 reais.
+Depois de alguns eventos e encontros para coletar os requisitos via os agentes
+do governo federal e da sociedade, foi desenvolvida, entre janeiro de 2014 e
+junho de 2016, uma nova plataforma para o Portal SPB, pelo Universidade de
+Brasília (UnB) e da Universidade de São Paulo (USP) em parceria com o
+Ministério de Orçamento, Planejamento e Gestão (MP). Ele foi projetado como uma
+plataforma integrada para desenvolvimento de software colaborativo, e inclui
+funcionalidade para redes sociais, listas de discussão, sistema de controle de
+versão e monitoramento de qualidade de código-fonte. Para coordenar e
+desenvolver esse projeto durante 30 meses, a UnB recebeu do Governo Federal
+Brasileiro um total de 2.619.965,00 reais.
 \begin{figure*}[hbt]
   \centering
@@ -16,8 +49,38 @@ Depois de alguns eventos e encontros para coletar os requisitos via os agentes d
   \label{fig:spb}
 \end{figure*}
-O projeto foi desenvolvido por uma equipe de 3 professores, 2 estudantes de mestrado e cerca de 50 alunos de graduação (não todos ao mesmo tempo), juntamente com 2 designers profissionais e 6 desenvolvedores sêniors da comunidade software livre. Os professores e todos os estudantes de graduação eram da UnB e os mestrandos eram da USP. Quanto aos designers e desenvolvedores seniores, 7 dos 8 viviam fora de Brasília: Curitiba, São Paulo, Ribeirão Preto, Salvador, Punta Cana/República Dominicana e Montreal/Canadá. Em outras palavras, nós tínhamos uma equipe trabalhando em um ambiente virtual colaborativo e distribuído.
+O projeto foi desenvolvido por uma equipe de 3 professores, 2 estudantes de
+mestrado e cerca de 50 alunos de graduação (não todos ao mesmo tempo),
+juntamente com 2 designers profissionais e 6 desenvolvedores sêniors da
+comunidade software livre. Os professores e todos os estudantes de graduação
+eram da UnB e os mestrandos eram da USP. Quanto aos designers e desenvolvedores
+seniores, 7 dos 8 viviam fora de Brasília: Curitiba, São Paulo, Ribeirão Preto,
+Salvador, Punta Cana/República Dominicana e Montreal/Canadá. Em outras
+palavras, nós tínhamos uma equipe trabalhando em um ambiente virtual
+colaborativo e distribuído.
-Figura \ref{fig:spb} mostra a página inicial desta plataforma integrada, que acesso (1) lista de discussões (Mailmain), (2) ambiente de apoio ao desenvolvimento (GitLab e Mezuro) e (3) rede social (Noosfero) com as páginas dos projetos e soluções disponíveis. Todo o desenvolvimento foi feito de forma aberta, e as mudanças que precisávamos nas ferramentas foram devolvidas às suas respectivas comunidades. Nosso processo foi baseado em práticas ágeis e nos mecanismos empíricos das comunidades de software livre. Definimos ciclos de desenvolvimento e lançamos 5 versões do novo SPB Portal. A primeira versão (beta) foi disponibilizada em setembro de 2014, apenas 9 meses desde o início do projeto. O antigo portal foi desligado em setembro de 2015. Por fim, a última versão, ilustrada na Figura\ref{fig:spb}, foi entregue em junho de 2016.
+Figura \ref{fig:spb} mostra a página inicial desta plataforma integrada, que
+acesso (1) lista de discussões (Mailmain), (2) ambiente de apoio ao
+desenvolvimento (GitLab e Mezuro) e (3) rede social (Noosfero) com as páginas
+dos projetos e soluções disponíveis. Todo o desenvolvimento foi feito de forma
+aberta, e as mudanças que precisávamos nas ferramentas foram devolvidas às suas
+respectivas comunidades. Nosso processo foi baseado em práticas ágeis e nos
+mecanismos empíricos das comunidades de software livre. Definimos ciclos de
+desenvolvimento e lançamos 5 versões do novo SPB Portal. A primeira versão
+(beta) foi disponibilizada em setembro de 2014, apenas 9 meses desde o início
+do projeto. O antigo portal foi desligado em setembro de 2015. Por fim, a
+última versão, ilustrada na Figura \ref{fig:spb}, foi entregue em junho de 2016.
-Neste artigo, apresentamos uma visão geral dessa nova geração do Portal SPB. Este relato de experiência compartilha nossa metodologia e processo de desenvolvimento desse projeto, trabalhando com o governo federal brasileiro para cumprir suas exigências, ao mesmo tempo ser o mais fiel possível às comunidades de software livre envolvidas. Além disso, discutimos várias lições aprendidas para fornecer um ambiente virtual colaborativo e distribuído, envolvendo uma grande equipe de estudantes de graduação e desenvolvedores sêniors remotos. Por fim, lançamos uma plataforma sem precedentes para o governo brasileiro aplicar métodos colaborativos de desenvolvimento de software. Este caso pode ajudar outros projetos a superar desafios similares de engenharia de software no futuro, bem como demonstra como as universidades podem melhorar a experiência de mundo real de seus alunos por meio desse tipo de projeto.
+Neste artigo, apresentamos uma visão geral dessa nova geração do Portal SPB.
+Este relato de experiência compartilha nossa metodologia e processo de
+desenvolvimento desse projeto, trabalhando com o governo federal brasileiro
+para cumprir suas exigências, ao mesmo tempo ser o mais fiel possível às
+comunidades de software livre envolvidas. Além disso, discutimos várias lições
+aprendidas para fornecer um ambiente virtual colaborativo e distribuído,
+envolvendo uma grande equipe de estudantes de graduação e desenvolvedores
+sêniors remotos. Por fim, lançamos uma plataforma sem precedentes para o
+governo brasileiro aplicar métodos colaborativos de desenvolvimento de
+software. Este caso pode ajudar outros projetos a superar desafios similares de
+engenharia de software no futuro, bem como demonstra como as universidades
+podem melhorar a experiência de mundo real de seus alunos por meio desse tipo
+de projeto.
 \section{O Software Público Brasileiro}
 \label{sec:spb}
-Software livre é um fenômeno que ganhou notoriedade nos últimos anos e tem atraído o interesse da academia. No entanto, desde o início da computação, a maioria dos desenvolvedores trabalhou da maneira que agora identificamos como software livre, ou seja, compartilhando códigos abertamente. Essa abertura torna o código disponível para inspeção, modificação e uso por qualquer pessoa ou organização\cite{hippel2003, kon2012}.
+Software livre é um fenômeno que ganhou notoriedade nos últimos anos e tem
+atraído o interesse da academia. No entanto, desde o início da computação, a
+maioria dos desenvolvedores trabalhou da maneira que agora identificamos como
+software livre, ou seja, compartilhando códigos abertamente. Essa abertura
+torna o código disponível para inspeção, modificação e uso por qualquer pessoa
+ou organização\cite{hippel2003, kon2012}.
-Os elementos que distinguem o software livre de outros tipos de software são o pensamento sobre o processo de desenvolvimento, o contexto econômico, a relação entre desenvolvedores e usuários, bem como as características éticas e legais que se relacionam com o software. No contexto do software livre, a liberdade do usuário é promovida e seu desenvolvimento é baseado em práticas abertas de colaboração e desenvolvimento\cite{meirelles2013}.
+Os elementos que distinguem o software livre de outros tipos de software são o
+pensamento sobre o processo de desenvolvimento, o contexto econômico, a relação
+entre desenvolvedores e usuários, bem como as características éticas e legais
+que se relacionam com o software. No contexto do software livre, a liberdade do
+usuário é promovida e seu desenvolvimento é baseado em práticas abertas de
+colaboração e desenvolvimento\cite{meirelles2013}.
-Do ponto de vista econômico, ao contrário do que acontece com o software proprietário, o software livre promove o estabelecimento de vários fornecedores que podem competir uns com os outros com base no mesmo software. Essa forte concorrência entre os fornecedores traz benefícios para os usuários, porque dá melhores garantias em relação à evolução do sistema, levando a uma redução dos custos\cite{kon2012}. Essas liberdades e garantias sobre software são regidas no Brasil pela Lei 9610/98 (lei de direitos autorais). Na maioria das vezes, essa proteção da lei está em conformidade com os termos conferidos por um contrato relacionado a determinado software. Esse contrato é chamado de ``licença''. Uma licença de software determina uma lista de direitos que são concedidos, e deveres que são impostos a um usuário do software. Em particular, o que diferencia software livre de software proprietário é apenas a forma como eles são licenciados\cite{sabino2009}. As licenças de software livre garantem o direito de executar, estudar, adaptar e melhorar o software.
+Do ponto de vista econômico, ao contrário do que acontece com o software
+proprietário, o software livre promove o estabelecimento de vários fornecedores
+que podem competir uns com os outros com base no mesmo software. Essa forte
+concorrência entre os fornecedores traz benefícios para os usuários, porque dá
+melhores garantias em relação à evolução do sistema, levando a uma redução dos
+custos\cite{kon2012}. Essas liberdades e garantias sobre software são regidas
+no Brasil pela Lei 9610/98 (lei de direitos autorais). Na maioria das vezes,
+essa proteção da lei está em conformidade com os termos conferidos por um
+contrato relacionado a determinado software. Esse contrato é chamado de
+``licença''. Uma licença de software determina uma lista de direitos que são
+concedidos, e deveres que são impostos a um usuário do software. Em particular,
+o que diferencia software livre de software proprietário é apenas a forma como
+eles são licenciados\cite{sabino2009}. As licenças de software livre garantem o
+direito de executar, estudar, adaptar e melhorar o software.
-A versão original do portal SPB foi projetada em 2005 e lançada em 2007. O propósito do portal era apenas compartilhar o software desenvolvido no governo brasileiro, para reduzir os custos de contratação de software. No entanto, observou-se que quando os projetos de software foram lançados, suas comunidades foram formadas em torno desses sistemas com várias pessoas colaborando e compartilhando os resultados obtidos com o uso dessas soluções. Dessa forma, algumas cooperativas de desenvolvimento de software e empresas privadas demonstraram interesse em disponibilizar seus sistemas na plataforma SPB.
+A versão original do portal SPB foi projetada em 2005 e lançada em 2007. O
+propósito do portal era apenas compartilhar o software desenvolvido no governo
+brasileiro, para reduzir os custos de contratação de software. No entanto,
+observou-se que quando os projetos de software foram lançados, suas comunidades
+foram formadas em torno desses sistemas com várias pessoas colaborando e
+compartilhando os resultados obtidos com o uso dessas soluções. Dessa forma,
+algumas cooperativas de desenvolvimento de software e empresas privadas
+demonstraram interesse em disponibilizar seus sistemas na plataforma SPB.
-Em resumo, o conceito de Software Público Brasileiro vai além do software livre. Além de estar licenciado sob uma licença de software livre, um software público precisa ter garantias explícitas de que é um bem público, e esse projeto deve estar disponível no portal SPB. Ser um verdadeiro bem público pressupõe requisitos que não podem ser satisfeitos apenas por meio de licenciamento de software livre. Por exemplo, deve haver uma política de uso de marca menos rígida pelo fornecedor original que não impeça eventuais concorrentes de serviços de publicidade para esse mesmo software. A inclusão no SPB Portal também tem requisitos extras, como ter um sistema de controle de versão pública, manual de instalação e especificação de requisitos de hardware.
+Em resumo, o conceito de Software Público Brasileiro vai além do software
+livre. Além de estar licenciado sob uma licença de software livre, um software
+público precisa ter garantias explícitas de que é um bem público, e esse
+projeto deve estar disponível no portal SPB. Ser um verdadeiro bem público
+pressupõe requisitos que não podem ser satisfeitos apenas por meio de
+licenciamento de software livre. Por exemplo, deve haver uma política de uso de
+marca menos rígida pelo fornecedor original que não impeça eventuais
+concorrentes de serviços de publicidade para esse mesmo software. A inclusão no
+SPB Portal também tem requisitos extras, como ter um sistema de controle de
+versão pública, manual de instalação e especificação de requisitos de hardware.
 \section{Requisitos e projetos relacionados}
 \label{sec:requirements}
-Para conceber o novo portal SPB, o governo brasileiro organizou 3 eventos para coletar os requisitos, em particular do ponto de vista da sociedade. Após essas 3 rodadas de discussão sobre a nova plataforma SPB, o governo brasileiro listou cerca de 145 requisitos e desenvolveu um ``mapa mental''\footnote{\url{https://softwarepublico.gov.br/social/spb/gallery/mapaconceitual.png}} para guiar a evolução do portal SPB. Nesse cenário, os 10 requisitos mais votados foram, por exemplo:
+Para conceber o novo portal SPB, o governo brasileiro organizou 3 eventos para
+coletar os requisitos, em particular do ponto de vista da sociedade. Após essas
+3 rodadas de discussão sobre a nova plataforma SPB, o governo brasileiro listou
+cerca de 145 requisitos e desenvolveu um ``mapa
+mental''\footnote{\url{https://softwarepublico.gov.br/social/spb/gallery/mapaconceitual.png}}
+para guiar a evolução do portal SPB. Nesse cenário, os 10 requisitos mais
+votados foram, por exemplo:
 \begin{enumerate}
 \item Repositório de código-fonte com acesso público.
@@ -16,7 +22,14 @@ Para conceber o novo portal SPB, o governo brasileiro organizou 3 eventos para c
 \item Relatório da experiência sobre o uso de um software público.
 \end{enumerate}
-Haviam outros requisitos baseados na experiência dos analistas de TI do governo brasileiro e da comunidade software livre brasileira. Por exemplo, a nova plataforma só funcionaria corretamente se houver uma autenticação única para usar as ferramentas fornecidas. Além disso, uma interface unificada era um requisito não-funcional importante para ter uma melhor experiência de usuário na nova plataforma. Assim, no primeiro momento, desejamos disponibilizar uma versão inicial que poderia substituir o antigo portal SPB. Para isso, a primeira versão deve ter recursos como:
+Haviam outros requisitos baseados na experiência dos analistas de TI do governo
+brasileiro e da comunidade software livre brasileira. Por exemplo, a nova
+plataforma só funcionaria corretamente se houver uma autenticação única para
+usar as ferramentas fornecidas. Além disso, uma interface unificada era um
+requisito não-funcional importante para ter uma melhor experiência de usuário
+na nova plataforma. Assim, no primeiro momento, desejamos disponibilizar uma
+versão inicial que poderia substituir o antigo portal SPB. Para isso, a
+primeira versão deve ter recursos como:
 \begin{enumerate}
 \item Um catálogo de software público organizado.
@@ -26,22 +39,71 @@ Haviam outros requisitos baseados na experiência dos analistas de TI do governo
 \item Listas de discussão e fóruns de discussão.
 \end{enumerate}
-Outros requisitos também foram planejados durante a fase de concepção do projeto de evolução do SPB, como um mecanismo de busca integrado e um monitor de análise estática de código-fonte na web. Analisando todos esses requisitos, criamos o projeto de evolução do SPB baseado em ferramentas de software livre existentes. No entanto, a integração de vários sistemas existentes que já foram implementados em diferentes linguagens de programação e arcabouços, adicionando recursos como uma autenticação centralizada, interface unificada e um mecanismo de pesquisa, bem como, outros recursos de \textit{back-end}, requeriria grande quantidade de trabalho não-trivial.
+Outros requisitos também foram planejados durante a fase de concepção do
+projeto de evolução do SPB, como um mecanismo de busca integrado e um monitor
+de análise estática de código-fonte na web. Analisando todos esses requisitos,
+criamos o projeto de evolução do SPB baseado em ferramentas de software livre
+existentes. No entanto, a integração de vários sistemas existentes que já foram
+implementados em diferentes linguagens de programação e arcabouços, adicionando
+recursos como uma autenticação centralizada, interface unificada e um mecanismo
+de pesquisa, bem como, outros recursos de \textit{back-end}, requeriria grande
+quantidade de trabalho não-trivial.
-A nova plataforma SPB é um ambiente totalmente integrado, sendo muito avançada em comparação com projetos e iniciativas relacionados. Por exemplo, o governo dos EUA tem uma plataforma criada para melhorar o acesso ao software desenvolvido pelo governo federal\footnote{\url{https://code.gov}}. Code.gov é uma interface para organizar os projetos do governo dos EUA e, em suma, facilita aos usuários e desenvolvedores como obter informações e acessar repositórios de código-fonte dos projeto do governo no GitHub. No entanto, não há recursos de rede social e CMS, bem como outros recursos de comunicação fornecidos por essa plataforma.
+A nova plataforma SPB é um ambiente totalmente integrado, sendo muito avançada
+em comparação com projetos e iniciativas relacionados. Por exemplo, o governo
+dos EUA tem uma plataforma criada para melhorar o acesso ao software
+desenvolvido pelo governo federal\footnote{\url{https://code.gov}}. Code.gov é
+uma interface para organizar os projetos do governo dos EUA e, em suma,
+facilita aos usuários e desenvolvedores como obter informações e acessar
+repositórios de código-fonte dos projeto do governo no GitHub. No entanto, não
+há recursos de rede social e CMS, bem como outros recursos de comunicação
+fornecidos por essa plataforma.
-Além disso, existem duas iniciativas na Europa: OSOR\footnote{\url{https://joinup.ec.europa.eu/community/osor}} e OW2\footnote{\url{http://ow2.org}}. O Open Source Observatory (OSOR) é uma comunidade hospedada na plataforma JoinUp, patrocinada pela \textit{European Commission}. O OSOR tem como objetivo o intercâmbio de informações, experiências e melhores práticas sobre o uso de software livre na administração pública. Ajuda a encontrar um software livre disponibilizado por outras administrações públicas, proporcionando acesso a informações como notícias, eventos, estudos e soluções relacionadas à implementação de software livre. Ele também oferece fórum e listas de discussão da comunidade, mas não possui um gerenciador de repositório de código-fonte integrado e para cada projeto há um link para seu próprio repositório externo (ou seu arquivo tarball).
-%
-OW2 é uma espécie de consórcio de projetos de software livre para promover o desenvolvimento de \textit{middleware} livres, aplicativos de negócios, plataformas de computação em nuvem e promover um ecossistema de comunidade e negócios. Em resumo, ele visa apoiar o desenvolvimento, implantação e gerenciamento de soluções distribuídos com foco em middleware, não sendo uma plataforma em si.
-%
-Além disso, patrocinado pela \textit{European Commission} entre 2007 e 20011, havia o projeto QualiPSo que visava fornecer aos usuários, desenvolvedores e consumidores de software livre recursos e conhecimentos de qualidade sobre os vários tópicos relacionados ao software livre. O projeto QualiPSo também planejava desenvolver uma plataforma chamada QualiPSo Factory, que não foi totalmente concluída.
+Além disso, existem duas iniciativas na Europa:
+OSOR\footnote{\url{https://joinup.ec.europa.eu/community/osor}} e
+OW2\footnote{\url{http://ow2.org}}. O Open Source Observatory (OSOR) é uma
+comunidade hospedada na plataforma JoinUp, patrocinada pela \textit{European
+Commission}. O OSOR tem como objetivo o intercâmbio de informações,
+experiências e melhores práticas sobre o uso de software livre na administração
+pública. Ajuda a encontrar um software livre disponibilizado por outras
+administrações públicas, proporcionando acesso a informações como notícias,
+eventos, estudos e soluções relacionadas à implementação de software livre. Ele
+também oferece fórum e listas de discussão da comunidade, mas não possui um
+gerenciador de repositório de código-fonte integrado e para cada projeto há um
+link para seu próprio repositório externo (ou seu arquivo tarball). OW2 é
+uma espécie de consórcio de projetos de software livre para promover o
+desenvolvimento de \textit{middleware} livres, aplicativos de negócios,
+plataformas de computação em nuvem e promover um ecossistema de comunidade e
+negócios. Em resumo, ele visa apoiar o desenvolvimento, implantação e
+gerenciamento de soluções distribuídos com foco em middleware, não sendo uma
+plataforma em si. Além disso, patrocinado pela \textit{European Commission}
+entre 2007 e 20011, havia o projeto QualiPSo que visava fornecer aos usuários,
+desenvolvedores e consumidores de software livre recursos e conhecimentos de
+qualidade sobre os vários tópicos relacionados ao software livre. O projeto
+QualiPSo também planejava desenvolver uma plataforma chamada QualiPSo Factory,
+que não foi totalmente concluída.
-Na América Latina existe uma iniciativa baseada no projeto SPB chamado Software Publico Regional\footnote{\url{http://softwarepublicoregionalbeta.net}}. De um ponto de vista prático, ele fornece uma instância personalizada do Gitlab para compartilhar o código-fonte e a documentação dos projetos dos países envolvidos.
-%
-Tal como o Brasil, o Chile tem seu próprio portal também chamado Software Publico\footnote{\url{http://www.softwarepublico.gob.cl}}. Os usuários podem criar conteúdo nas comunidades (notícias, documentos, páginas wiki), mas os repositórios de código-fonte estão disponíveis na plataforma Bitbucket\footnote{\ url {https://bitbucket.org/softwarepublico}}.
-
-
-O governo brasileiro precisava evoluir o projeto SPB que existia desde 2005. Em 2013, quando iniciamos esse projeto, o Portal SPB contava com cerca de 200 mil usuários cadastrados. Não poderíamos apenas entrar em contato com esses usuários e pedir-lhes para registrar uma conta no Github também. Além disso, após o caso Edward Snowden, o governo brasileiro aprovou um decreto-lei específico (8.135/2013) para regulamentar seus serviços de comunicação, exigindo que a administração pública deva hospedar seus sistemas de informação a ser fornecido por si mesmo, o que exclui o uso de plataformas privadas, especialmente aqueles fornecidos por empresas estrangeiras. Assim, desenvolvemos nossa própria solução para cobrir todos os requisitos, produzindo uma completa e avançada plataforma integrada governamental para desenvolvimento de software colaborativo.
+Na América Latina existe uma iniciativa baseada no projeto SPB chamado Software
+Publico Regional\footnote{\url{http://softwarepublicoregionalbeta.net}}. De um
+ponto de vista prático, ele fornece uma instância personalizada do Gitlab para
+compartilhar o código-fonte e a documentação dos projetos dos países
+envolvidos. Tal como o Brasil, o Chile tem seu próprio portal também chamado
+Software Publico\footnote{\url{http://www.softwarepublico.gob.cl}}. Os usuários
+podem criar conteúdo nas comunidades (notícias, documentos, páginas wiki), mas
+os repositórios de código-fonte estão disponíveis na plataforma
+Bitbucket\footnote{\url{https://bitbucket.org/softwarepublico}}.
+O governo brasileiro precisava evoluir o projeto SPB que existia desde 2005. Em
+2013, quando iniciamos esse projeto, o Portal SPB contava com cerca de 200 mil
+usuários cadastrados. Não poderíamos apenas entrar em contato com esses
+usuários e pedir-lhes para registrar uma conta no Github também. Além disso,
+após o caso Edward Snowden, o governo brasileiro aprovou um decreto-lei
+específico (8.135/2013) para regulamentar seus serviços de comunicação,
+exigindo que a administração pública deva hospedar seus sistemas de informação
+a ser fornecido por si mesmo, o que exclui o uso de plataformas privadas,
+especialmente aqueles fornecidos por empresas estrangeiras. Assim,
+desenvolvemos nossa própria solução para cobrir todos os requisitos, produzindo
+uma completa e avançada plataforma integrada governamental para desenvolvimento
+de software colaborativo.
-\section{Architecture}
+\section{Arquitetura}
 \label{sec:architecture}
-Based on the extensive list of functional requirements defined by the
-Brazilian Federal Government, we selected some FOSS systems to form our
-solution. We looked for system that together could provide the largest
-subset possible of the requirements, and were fully aware that we would
-need to improve those systems in order to provide the rest. We were also
-convinced that it would be impossible to provide all of those
-requirements with a single tool.
+Com base na extensa lista de requisitos funcionais definidos pelo Governo
+Federal do Brasil, selecionamos alguns sistemas livres compor a solução
+proposta para o novo SPB.  Avaliamos os sistemas que juntos poderiam fornecer o
+maior subconjunto possível dos requisitos. Nós também estávmos convencidos de
+que seria impossível fornecer todas as funcionalidade com uma única ferramenta.
-From the point of view of the architecture, two main requirements was
-brought by the Brazilian Federal Government for the new platform:
+Do ponto de vista da arquitetura, dois requisitos eram importantes para a nova
+plataforma:
 \begin{enumerate}
-  \item \textit{Integrate existing FOSS systems}, with minimal differences from
-    their original versions;
-  \item \textit{Provide a consistent user interface} across the different
-    systems, as well as centralized authentication.
+\item \textit{Integrar sistemas livres existentes}, com diferenças mínimas de suas versões originais;
+\item \textit{Fornecer uma interface de usuário unificada} entre os diferentes sistemas, bem como a autenticação centralizada.
 \end{enumerate}
-Adopting existing FOSS systems and minimizing locally-made changes had
-the objective of being able to upgrade to newer versions of the original
-software, benefiting from improvements and maintenance done by the
-existing project communities. Providing a consistent user interface on
-top of those different tools was needed to make the transition between
-the different systems seamless from the point of view of users, which
-would be confused by jumping through completely different interfaces
-while interacting with the portal.
-
-For the first requirement, we identified four main systems that required
-specialized teams for work in the integration process. The teams learned
-how to develop for their assigned systems and contributed to the
-original communities, so that the version we used were not significantly
-different from the original.
-
-At the end of the project, the SPB portal was composed of more than ten
-systems, such as Colab, Noosfero, Mezuro, Gitlab, Mailman, Postfix, and
-Munin. The remainder of this section describes the most relevant of
-them, as well as how they were integrated into the platform.
-
-\subsection{Colab}
-
-Colab\footnote{\url{https://github.com/colab}} is a systems integration
-platform for web applications. One of its goals is allowing different
-applications to be combined in such a way that an user does not notice
-the change between applications. For that, Colab provides facilities
-for:
+A adoção de sistemas livres existentes e a minimização de mudanças feitas
+localmente tiveram como objetivo ser capazes de atualizar para versões mais
+recentes do software original, beneficiando de melhorias e manutenção feitas
+pelas comunidades de projetos existentes. Proporcionar uma interface de usuário
+consistente em cima dessas diferentes ferramentas era necessária para fazer a
+transição entre os diferentes sistemas sem a percepção do ponto de vista dos
+usuários, ou seja, sem confundi-lo através de interfaces completamente
+diferentes ao interagir com o portal.
+
+Para o primeiro requisito, identificamos quatro sistemas principais que exigiam
+equipes especializadas para o trabalho no processo de integração. As equipes
+aprenderam a desenvolver para seus sistemas designados e contribuíram para as
+comunidades originais, de modo que a versão que usamos não era
+significativamente diferente do original.
+
+No final do projeto, o portal SPB foi composto por mais de dez sistemas, como
+Colab, Noosfero, Mezuro, Gitlab, Mailman, Postfix e Munin. A seguir
+apresentamos os mais relevantes deles, bem como como eles foram integrados na
+plataforma.
 \begin{itemize}
-  \item Centralized authentication
-  \item Visual consistency
-  \item Relaying of events between applications
-  \item Integrated search engine
-\end{itemize}
-
-Colab implements this integration by working as a reverse proxy for the
-integration applications, that is, all external requests pass through
-Colab before reaching them.
-
-Centralized authentication is handled by letting users authenticate to
-Colab, which then sends a REMOTE\_USER HTTP header to applications,
-which are expected to be pre-configured to accept that as an indication
-of the current user (REMOTE\_USER is a standard authentication mechanism
-for web applications). This allows users to be automatically identified
-to each of the applications without having to enter credentials for each
-of them.
-%
-Of course, this requires that the integrated applications are not
-accessible on the public internet, otherwise malicious users could send
-their own crafted REMOTE\_USER headers and impersonate any user.
-
-For the visual consistency, Colab is able to make transformations to the
-HTML produced by the integrated applications, ir order to provide a
-unified interface. It allows one to define default templates to be used
-by all applications, as well as providing extra ones in a plugin. This
-approach allowed us to reuse common HTML pages, what facilitates
-maintenance.
-
-Colab also provides a publish-subscribe event system. This allows one of
-the applications, or Colab itself, to trigger an action in another
-application. For example, when a user registers with Colab, all
-applications need to be notified in order to create their own internal
-representation of that user account.
-
-Colab also provides an integrated search engine, which can be configured
-to specify exactly what data needs to be indexed for each of the
-applications, and how to direct the user to that piece of information on
-the specific application.
-
-Initially, Colab had support for a small set of applications (Trac, GNU
-Mailman, and Apache Lucene) and support for them was hard-coded. Our
-team evolved Colab so that it can now receive plugins that add support
-new applications without the need of changes to the Colab core. We also
-developed plugins to be used in the SPB platform: Noosfero, GitLab, and
-Mezuro.
-\subsection{Noosfero}
+\item \textbf{Colab\footnote{\url{https://github.com/colab}}:} é uma plataforma
+de integração de sistemas para aplicações web. Um de seus objetivos é permitir
+que diferentes aplicações sejam combinadas de tal forma que um usuário não note
+a mudança entre as aplicações. Para isso, a Colab oferece autenticação
+centralizada, consistência visual, retransmissão de eventos entre aplicações e
+mecanismo de pesquisa integrado.
+
+\item \textbf{Noosfero\footnote{\url{http://noosfero.org}}:} é um software para
+redes sociais e de colaboração. Além dos recursos clássicos de redes sociais,
+ele também fornece recursos de publicação de conteúdo, como blogs e um CMS
+(\textit{Content Management System}) de propósito geral. A maioria das
+interações do usuário com o SPB é através do Noosfero: registro do usuário,
+páginas do projeto e de documentação e formulários de contato.
+
+\item \textbf{Gitlab\footnote{\url{http://gitlab.com}}:} é um gerenciador web
+de repositório Git com páginas wiki e recursos de \textit{issue tracker}. O
+Gitlab é uma plataforma livre e se concentra em oferecer uma solução holística
+de desenvolvimento colaborativo em torno do repositório em uma única
+plataforma.
+
+\item \textbf{Mezuro\footnote{\url{http://mezuro.org/}}:} é uma plataforma para
+coletar métricas de código-fonte com o objetivo de monitorar a qualidade
+interna de projetos de software livre escrito em C, C ++, Java, Python, Ruby ou
+PHP.
-Noosfero\footnote{\url{http://noosfero.org}} is a software for building
-social and collaboration networks. Besides the classical social
-networking features, it also provides publication features such as blogs
-and a general-purpose CMS (Content Management System). Most of the user
-interactions with SPB is through Noosfero: user registration, project
-home pages and documentation, and contact forms.
-
-\subsection{Gitlab}
-
-GitLab\footnote{\url{http://gitlab.com}} is a web-based Git repository
-manager with wiki pages and issue tracking features. Gitlab is a FOSS
-platform and focuses on delivering a holistic solution that will see
-developers from idea to production seamlessly and on a single platform.
-
-Gitlab has several unique features, such as built-in continuous
-integration and continuous deployment, flexible permissions, tracking of
-Work-in-Progress work, moving issues between projects, group-level
-milestones, creating new branches from issues, issues board, and time
-tracking.
-
-\subsection{Mezuro}
-
-Mezuro\footnote{\url{http://mezuro.org/}} is a platform to collect source code
-metrics to monitor the internal quality of software written in C, C++,
-Java, Python, Ruby, and PHP.
-
-In general, source code metrics tools also do not present a friendly way
-to interpret its results and, even more, do not follow a standardization
-between them. Mezuro collects and presents these results to the end
-user, specially, by analyzing source code metric history during its life
-cycle.
-
-The Mezuro platform provides a single interface grouping available
-tools, allows selection and composition of metrics in a flexible manner,
-stores the metrics evolution history, presents results in a friendly
-way, as well as, allows users to customize the given interpretation
-accordingly to their own context.
-
-\subsection{System unification}
+\end{itemize}
 \begin{figure}[hbt]
   \centering
     \includegraphics[width=.5\linewidth]{figures/arch.png}
-  \caption{SPB architecture overview.}
+  \caption{Visão geral da arquitetura do novo portal SPB.}
   \label{fig:architecture}
 \end{figure}
-The conceptual architecture of the platform is presented in Figure
-\ref{fig:architecture}. Colab initially handles all user interaction,
-directing requests to one of the integrated applications. It
-post-processes responses from the applications to apply a consistent
-visual appearance, manages authentication, and provides a unified search
-functionality: instead of using the redundant restricted search
-functionality of each application, a search in the SPB portal might
-return content from any of the applications, be it web pages, mailing
-list posts, or source code.
-%
-The SPB platform was deployed in 7 virtual machines with different functions.
+Do ponto de vista prático, a plataforma SPB foi implantada em 7 máquinas
+virtuais com diferentes
+funções\footnote{\url{https://softwarepublico.gov.br/doc/arquitetura.html}}. A
+arquitetura conceitual da plataforma é apresentada na Figura
+\ref{fig:architecture}. O Colab inicialmente lida com toda a interação do
+usuário, redirecionando as solicitações para as ferramentas integradas. Ele
+processa as respostas das ferramentas e aplica uma aparência visual
+consistente, gerenciando também a autenticação e fornecendo uma busca
+unificada: em vez de usar a funcionalidade de busca restrita redundante de cada
+ferramenta, uma busca no portal SPB pode retornar conteúdo de qualquer uma
+delas, sejam páginas web, postagens da lista de discussão ou mesmo
+código-fonte.
+
-\section{Features}
+\section{Funcionalidades}
 \label{sec:spb}
-The new generation of the SPB portal combines features adapted from existing collaborative software
-and features developed by the SPB team. Whenever possible, new functions 
-(newly developed or partially modified) were contributed back to the official repositories.
+A nova geração do portal SPB combina recursos adaptados de plataformas
+colaborativas existentes com recursos desenvolvidos pelas equipes da UnB e USP.
+Sempre que possível, novas funcionalidades recém-desenvolvidas ou parcialmente
+modificadas) foram enviadas de volta aos repositórios oficiais.
-As a result, we have a platform that integrates and harmonizes different features such as
-social networking, mailing list, version control system, content management and
-source code quality monitoring. Our aim was to develop functionalities by reusing
-functionality of collaborative software already integrated to the platform. In
-addition, we tried to keep this integration transparent to end users.
+Como resultado, temos uma plataforma que integra e harmoniza diferentes
+recursos, como redes sociais, lista de email, sistema de controle de versão,
+gerenciamento de conteúdo e monitoramento de qualidade de código-fonte. Nosso
+objetivo foi desenvolver funcionalidades reutilizando as ferramentas integradas
+à plataforma. Além disso, tentamos manter essa integração transparente para os
+usuários finais. Temos 3 grandes conjuntos de funcionalidades descritas nas
+próximas subseções.
-\subsection{Software and Software Community}
+\subsection{Software e Comunidade de Software}
-In the new SPB portal, each software has a standard set of pages and tools.
-Besides accessing support pages (such as FAQ and installation guide) within the platform, users will be able to download
-different versions of the software and find several mechanisms of software development management.
+No novo portal SPB, cada software tem um conjunto padrão de páginas e
+ferramentas. Além de acessar as páginas de suporte (como FAQ e guia de
+instalação) dentro da plataforma, os usuários são capazes de baixar diferentes
+versões do software e encontrar vários mecanismos de gerenciamento de
+desenvolvimento de software.
-Focusing on the collaborative development, Mailman was integrated to the platform in order to allow
-the dialogue and communication between developers, users and
-enthusiasts of a determined software. The software has its own mailing list whose privacy
-can be configured/set by administrators. 
+Focando no desenvolvimento colaborativo, Mailman foi integrado à plataforma
+para permitir o diálogo e a comunicação entre desenvolvedores, usuários e
+entusiastas de um determinado software. O software tem sua própria lista de
+discussão cuja privacidade pode ser configurada e definida pelos
+administradores.
-The software has a social interface area ("software community") where users can find other users, blogs,
-summary of recent activities, or any other relevant community-produced content. 
-Users logged to the platform can request membership to different software communities 
-and each community member can access and edit restricted content. For this purpose, 
-many Noosfero features related to social networking and content management were integrated to the portal.
+O software possui uma área de interface social (``comunidade de software'')
+onde os usuários podem encontrar outros usuários, blogs, resumo de atividades
+recentes ou qualquer outro conteúdo relevante produzido pela comunidade. Os
+usuários registrados na plataforma podem solicitar a associação a comunidades
+de software diferentes e cada membro da comunidade pode acessar e editar
+conteúdo restrito. Para isso, muitos recursos do Noosfero relacionados a redes
+sociais e gerenciamento de conteúdo foram integrados ao portal.
-To assist decision-making, the new SPB has acquired assessment and statistical
-tools. Now, users will be able to rate the software and make comments and all
-information will be avaiable to other users. Moreover, the software has a section
-containing  its statistical data, where values are calculated based on data
-provided by users and the system.
+Para auxiliar na tomada de decisões, o novo SPB adquiriu ferramentas de
+avaliação e estatísticas. Agora, os usuários serão capazes de avaliar o
+software e fazer comentários e todas as informações serão avaiable para outros
+usuários. Além disso, o software possui uma seção contendo seus dados
+estatísticos, onde os valores são calculados com base nos dados fornecidos
+pelos usuários e pelo sistema.
-The role of the administrator will be present in the software and in its community. The
-administrator is responsible for moderating content, memberships and user
-comments. The administrator is also the one who can make changes in the software homepage
-content.
+O papel do administrador estará presente no software e na sua comunidade. O
+administrador é responsável por moderar o conteúdo, as associações e os
+comentários dos usuários. O administrador também é aquele que pode fazer
+alterações no conteúdo da página inicial do software.
-\subsection{Software Catalog and global search}
+\subsection{Catálogo de Software e Busca Global}
-The platform also provides a search tool called Software Catalog, 
-which allows users to find softwares available in the portal.
-In this catalog, some search options were developed to make the navigation easier,
-such as filters (by type of software or category), sorting and score.
+A plataforma também fornece uma ferramenta de pesquisa chamada ``Catálogo de
+Software'', que permite aos usuários encontrar softwares disponíveis no portal.
+Neste catálogo, algumas opções de busca foram desenvolvidas para facilitar a
+navegação, como filtros (por tipo de software ou categoria), classificação e
+pontuação.
-In order to expand the searching scope and cover more types of content, the SPB team
-developed the global search tool. This tool unifies search mechanisms
-provided by the different collaborative software used in the SPB protal. Any user can
-find a public content in the context of social networking, mailing list and
-software development.
+Para expandir o escopo de busca e cobrir mais tipos de conteúdos, as equipes da
+UnB e USP desenvolveram um mecanismo de busca global. Essa funcionalidade
+unifica os mecanismos de busca fornecidos pelas diferentes ferramentas
+integradas ao portal do SPB. Qualquer usuário pode encontrar um conteúdo
+público no contexto de redes sociais, lista de discussão e desenvolvimento de
+software.
-\subsection{Software development tools}
+\subsection{Ambiente de apoio ao desenvolvimento de software}
-The new SPB also provides
-tools to encourage developers to keep source code and its
-development activity within the platform. Any created software has, by default, a
-an associated git repository with wiki pages and issue tracking. These tools are
-supplied by the integration of Gitlab into the platform. 
+O novo SPB também fornece ferramentas para incentivar os desenvolvedores a
+manter o código-fonte e sua atividade de desenvolvimento dentro da plataforma.
+Qualquer software criado tem, por padrão, um repositório Git associado com
+páginas wiki e \textit{issue tracker}. Essas ferramentas são fornecidas pela
+integração do Gitlab na plataforma.
-Developers can also evaluate the software source code to measure software
-quality. With Mezuro, they can schedule the analysis of the source-code and follow its
-metric results evolution over time.  Results of each metric analysis are
-public, which allows greater transparency between the developer and the
-community that uses the software.  Thereby, the maintainers can decide if the
-given solution meets the source code quality requirements.
+Os desenvolvedores também podem avaliar o código-fonte do software para medir a
+qualidade interna do software. Com o Mezuro, eles podem configurar a análise do
+código-fonte e monitorar sua evolução pelos resultados métricas ao longo do
+tempo. Os resultados de cada análise métrica são públicos, o que permite maior
+transparência entre o desenvolvedor e a comunidade que usa o software. Desta
+forma, os mantenedores podem decidir se uma determinada solução atende aos
+requisitos de qualidade interna do código-fonte.
-Thus, the SPB became a platform to stimulate the openness of the source code;
-dialogue between users and the development team; and also
-maintenance and evolution of the software, which will provide more
-transparency in government investments.
+Assim, o SPB tornou-se uma plataforma para estimular a abertura do código
+fonte; o diálogo entre os usuários e a equipe de desenvolvimento; e também a
+manutenção e evolução do software, o que proporcionará maior transparência nos
+investimentos do governo.
-\section{User eXperience evolution}
+\section{Evolução da experiência do usuário}
-The integration of collaborative environments goes beyond functional aspects.
-Offering the population an unified experience across these environments has
-been the key to encourage the use of the platform as it reduces the perception
-of complexity. Thus, the SPB Portal information architecture was redesigned
-to provide a transparent navigation and to reach users with different profiles.
-A process of harmonization has been employed on the interaction models of each
-tool to reduce the learning curve. At the same time, a new visual style was
-created to unify the navigation experience and to comply with the guidelines of
-the digital communication identity standard established by the Federal
-Government.
+A integração de ambientes colaborativos vai além dos aspectos funcionais.
+Oferecer à população uma experiência unificada em todos esses ambientes tem
+sido a chave para incentivar o uso da plataforma, pois reduz a percepção de
+complexidade. Assim, a arquitetura de informação do no portal SPB foi
+re-desenhada para fornecer uma navegação transparente e alcançar usuários com
+perfis diferentes. Um processo de harmonização foi empregado nos modelos de
+interação de cada ferramenta para reduzir a curva de aprendizado. Ao mesmo
+tempo, foi criado um novo estilo visual para unificar a experiência de
+navegação e cumprir as diretrizes do padrão de identidade de comunicação
+digital estabelecido pelo Governo Federal.
-With the increase in system features and the addition of new tools, the
-visual style has steadily evolved to keep the navigation unified.  Moreover,
-tools from different backgrounds, which in many cases provide similar
-functionality, prompted the development of an unified interface. Some
-features, such as search and user profile editing were eliminated from
-the individual applications, and implemented centrally to ensure a
-consistent look and feel.
+Com o aumento dos recursos do sistema e a adição de novas ferramentas, o estilo
+visual foi evoluído para manter a navegação unificada. Além disso, ferramentas
+de origens diferentes, que em muitos casos fornecem funcionalidades
+semelhantes, nos levou ao desenvolvimento de uma interface unificada. Alguns
+recursos, como a busca e a edição de perfil de usuário, foram eliminados dos
+aplicativos individuais e implementados centralmente para garantir uma
+aparência consistente.
-Another challenge was responsive web design. The integrated applications
-had varying degrees of support for responsiveness, and the common
-interface had to adapt for each individual scenario. In particular
-Noosfero did not yet have a responsive design; we engaged in its
-development and contributed towards that goal.
+Outro desafio foi o \textit{design web} responsivo. As aplicações integradas
+tinham diferentes graus de suporte para resposividade e a interface comum
+precisava se adaptar para cada cenário individual. Em particular, o Noosfero
+ainda não tinha recursos de responsividade. Nós nos engajamos em seu
+desenvolvimento e contribuímos para esse funcionalidade, contribuindo também
+com sua comunidade de desenvolvedores.
-After the initial release of the new SPB Portal in 2014, several
-validations activities were implemented in 2015 and 2016. The aim was to
-provide the most wanted features by casual users (such as public
-servants interested in downloads and documentation) immediately, while
-allowing more experienced users (such as developers) to easily drill down
-to the details.
+Após o lançamento inicial do novo Portal SPB em 2014, foram implementadas
+várias atividades de validação com os usuários em 2015 e 2016. O objetivo era
+disponibilizar imediatamente os recursos mais procurados tanto pelos usuários
+mais recorrentes (como servidores públicos interessados em
+downloads e documentação), quanto pelos usuários mais técnicos (como
+desenvolvedores interessados em acessar o código-fonte dos projetos).
-\section{Development Organization and Process}
+\section{Processo e organização do desenvolvimento}
 \label{sec:process}
-The SPB team was composed of a variety of professionals with different levels
-and skills, where most of them were undergraduate students with major in
-software engineering (from 4th semester or upper).  Since the students could
-not dedicate many hours per week to the project, they always had the
-flexibility to negotiate their work schedule during the semester in
-order to not harm their classes and coursework. Their daily work routine
-in the project included programming and DevOps tasks.
-
-The development of SPB project required a vast experience and background that
-usually undergraduate students do not have yet. For this reason, a few senior
-developers have joined to the project to help with the more difficult issues
-and to transfer knowledge to the students. Their main task was to provide
-solutions for complex problems, in other words, they worked as developers. As
-these professionals are very skillful and the project could not fund a full
-time work for them, some of them worked partially on the project. In addition,
-they lived in a different states spread around Brazil which led much of the
-communication to be online.
-
-In short, our work process was based on open and collaborative software
-development practices. The development process was defined based on the
-adaptation of different agile and FOSS communities practices, highlighting the
-high degree of automation resulting from DevOps practices. Thus, the work
-process was executed in a cadenced and continuous way.
-
-Finally, the last group of actors of this project was composed of employees
-formally working for the Brazilian government, in the Ministry of Planning,
-Development, and Management (MP is the Brazilian acronym). All the project
-decisions, validations, and scope definitions were made by them. In this way we
-developed software product incrementally, with releases aligned to business
-strategic objectives. As one can see, the project had many different
-kinds of stakeholders that had to be organized and synchronized.
-
-\subsection{Team organization}
-
-Approximately 70\% of the development teams were composed of software
-engineering undergraduate students from UnB and they worked physically
-in the same laboratory. Each student had their own schedule based on
-their classes, what complicates the implementation of pair programming.
-The senior developers tried to synchronize their schedule with the
-students on their sub-team. To  cope with this environment, we had a few
-basic rules which guided the project organization:
+A nossa equipe de desenvolvimento era composta por profissionais com diferentes
+níveis e habilidades, sendo a maioria deles estudantes de graduação de
+engenharia de software (a partir do 4º semestre de curso). Uma vez que os
+alunos não podiam dedicar muitas horas por semana ao projeto, eles sempre
+tiveram a flexibilidade para negociar seu horário de trabalho durante o
+semestre, a fim de não prejudicar a sua formação. Sua rotina de trabalho diário
+no projeto incluiu programação e tarefas de DevOps (contabilizando 16
+horas-semanais).
+
+O desenvolvimento do projeto SPB exigiu uma vasta experiência, que os alunos de
+graduação geralmente ainda não têm. Por esta razão, alguns desenvolvedores
+sênior se juntaram ao projeto para ajudar com as questões mais difíceis e
+transferir conhecimento aos alunos. Sua principal tarefa era fornecer soluções
+para problemas complexos. Como esses profissionais são muito hábeis e o projeto
+não poderia financiar um trabalho de tempo integral, eles trabalharam
+parcialmente no projeto (20 horas-semanais). Além disso, eles viviam em estados
+diferentes espalhados pelo Brasil, e outros países, o que levou muita da
+comunicação a ser on-line.
+
+Em resumo, nosso processo de trabalho foi baseado em práticas de
+desenvolvimento de software abertas e colaborativas. O processo de
+desenvolvimento foi definido com base na adaptação de diferentes práticas de
+comunidades ágeis e de software livre, destacando o alto grau de automação
+resultante das práticas de DevOps. Assim, o processo de trabalho foi executado
+de forma cadenciada e contínua. 
+
+Finalmente, o último grupo de atores deste projeto foi composto por
+funcionários formalmente trabalhando para o governo brasileiro, no Ministério
+do Planejamento, Desenvolvimento e Gestão (MP). Todas as decisões do projeto,
+validações e definições de escopo foram feitas com eles. Desta forma,
+desenvolvemos produtos de software de forma incremental, com lançamentos
+alinhados aos objetivos estratégicos do negócio. Como se pode ver, o projeto
+tinha muitos tipos diferentes de \textit{stakeholders} que tinham de ser
+organizados e sincronizados.
+
+\subsection{Organização da equipe}
+
+Aproximadamente 70\% das equipes de desenvolvimento foram compostas por
+estudantes de engenharia de software da UnB e trabalharam fisicamente no mesmo
+laboratório. Cada aluno tinha seu próprio horário baseado em suas aulas, o que
+complicava a implementação da programação em pares. Os desenvolvedores sêniors
+tentaram sincronizar sua agenda com os alunos em sua sub-equipe. Para lidar com
+esse ambiente, tivemos algumas regras básicas que guiaram a organização do
+projeto:
 \begin{enumerate}
-  \item Classes have high priority for undergraduate students;
-  \item Work in pairs whenever possible (locally or remotely).
-  \item There must be one morning or afternoon per week when
-    \emph{everyone} should be together physically in the laboratory
-    (except of course the remote team members).
-  \item Every 3 to 4 months, the senior developers would fly in and work
-    alongside the students for a few days.
+\item As aulas têm alta prioridade para estudantes de graduação;
+\item Trabalhe em pares sempre que possível (local com os demais estudantes ou
+      remotamente com um sênior).
+\item Deve haver uma manhã ou uma tarde por semana quando \emph{todos} deverem
+      estar juntos fisicamente no laboratório (exceto, é claro, os membros da
+      equipe remota, mas que estarão on-line).
+\item A cada 2 ou 3 meses, os desenvolvedores sêniors (residentes no Brasil)
+      voaria e trabalharia ao lado dos alunos por uma semana.
 \end{enumerate}
-With the aforementioned rules we divided all the project into four
-different teams: Colab, Noosfero, Design, and DevOps. Each team had one
-coach responsible for reducing the communication problem with the other
-teams and help the members to organize themselves in the best way for
-everyone (always respecting their work time). The coach was one of the
-students working in some of the teams with the extra duty of registering
-the current tasks developed in the sprint and with the responsibility to
-talk with other teams. One important thing to notice is the mutability
-of the team and the coach, during the project many students changed
-between the teams to try different areas.
-
-One characteristic of the teams was the presence of (at least) one
-senior per team. This was essential, because hard decisions and complex
-problems were usually referred to them. This kept having to take
-complicated technical decisions from the coach tole, what encouraged
-students to be coaches. Lastly, the senior developers worked directly
-with the students, and this was important to give the undergraduate the
-opportunity to interact with a savvy professional in his area and to
-keep the knowledge flowing in the project.
-
-Finally, we had to add two last elements of the team organization, that
-was essential for the project harmony: the meta-coach and professors.
-The former was a software engineer recently graduated and which wanted
-to keep working on the project, the latter were professors that
-orchestrated all the interactions between all members of the project.
-The meta-coach usually worked in one specific team and had the extra
-task of knowing the current status of all teams. Professors and
-meta-coaches worked together to reduce the communication problem between
-all the teams. Lastly, all the paperwork tasks, such as reporting on the
-project progress to the Ministry, was handled by the professors.
-
-\subsection{Communication and management}
-
-Our team had many people working together, and most of the seniors worked in a
-different city remotely. Also, we tried to keep our work completely clear to
-the Brazilian government and citizens interested in following the project. To
-handle those cases, we used a set of tools to communication and other to manage
-the project.
-
-For communication between member in different places, we used: Google
-handouts with tmate tool, IRC, and mailing lists. When one student had to
-work in pair with a senior, normally, they used Google hangout for
-communication and they shared a terminal session with tmate which allow
-them to share the same terminal, with both typing and seeing the screen.
-For questions and fast discussion, we used IRC. For general
-notification, we used the mailing lists.
-
-For managing the project we used the SPB Portal itself; first to validate it by
-ourselves, and also because it had all the required tools. We basically created
-one wiki page per release in the SPB Gitlab instance with a mapping between
-strategical, tactical, and operational views. In a practical point of view, one
-milestone per user history (feature), and one or more issues for addressing
-each feature. With this approach we achieved two important goals: keeping all
-the management as close possible to to the source code, and tracking every
-feature developed during the project.
-
-\subsection{High-level project management and reporting}
-
-The Brazilian government used to work with software development in a
-very traditional way. They would frequently focus on documents and not
-on what was, in our opinion, what really matters: working software. This
-dissonance caused us a communication noise with MP, because they would
-often question our work style.  It was especially hard to convince them
-to accept the idea of open scope and agile development, but after months
-of labor and showing results they stopped resisting.
-
-We defined some level of meeting granularity to avoid generating too
-much overhead to the developers. We had a strategical and validating
-meeting with MP (the former once in a month and the latter each 15th
-day), release plaining with the entire team (one per month), and finally
-a sprint planning (one each 15th day).  Figure \ref{fig:meeting} is a
-diagram that represents our meeting organization.
-
-\begin{figure}[hbt]
-  \centering
-    \includegraphics[width=\linewidth]{figures/meeting_flows.png}
-  \caption{Meetings cycles}
-  \label{fig:meeting}
-\end{figure}
-
-In the strategical meeting we usually defined the priorities and new
-features with the Brazilian government. Normally the professors, the
-coach of each team, the meta-coach, and some employees of the MP would
-participate in this meeting. We usually discussed what the team already
-produced since our last meeting, and established the new features for
-the next release.  Notice that just part of the team would join this
-meeting to avoid generating unnecessary overhead to the developers, but
-all the students interested to participate were allowed to join (many
-students wanted this experience during the project).
-
-After the strategical meeting with Brazilian government agents, we had a
-planning turn with all teams together. In this part, each team worked together
-to convert the MP wishes into smaller parts which were represented by the epics of
-the release. Each coach was responsible for conducting the planning, and after
-that record it on the project wiki (the wiki provided by Gitlab). With this
-epic, each 14th day the team have generated their sprint scheduler (with small
-achievements mapped to issues).
-
-To keep the Brazilian government always updated, we invited them to work
-with us to validate the new features in progress. Normally we had a
-meeting each 15th day. Basically, this was our work flow, we always kept
-everything extremely open to the MP (our way of working, and the one
-often used by open source projects) and to the team.
-
-To keep the track of all of those things we used the SPB itself,
-especially Gitlab. Basically, we had:
+Com as regras acima, dividimos todo o projeto em quatro equipes diferentes:
+Colab, Noosfero, Design e DevOps. Cada equipe tinha um líder (\textit{coach})
+responsável por reduzir o problema de comunicação com as outras equipes e
+ajudar os membros a se organizar da melhor maneira para todos (sempre
+respeitando seu tempo de trabalho). O \textit{coach} sempre foi um dos alunos
+que trabalha como desenvolvedor na equipe com o dever extra de registar as
+tarefas atuais desenvolvidas na iteração (\textit{sprint}) e com a
+responsabilidade de conversar com outras equipes. Uma coisa importante a
+observar é a mutabilidade da equipe e do \textit{coach}, pois durante o projeto
+muitos alunos mudaram de equipes para tentar ter diferentes experiências em
+diversas áreas. 
+
+Uma característica das equipes foi a presença de (pelo menos) um sênior por
+equipe. Isso era essencial, porque as decisões difíceis e os problemas
+complexos, geralmente, foram resolvidos ao consultá-los. Essa dinâmica
+incentivamos aos demais alunos a terem o mesmo compartamento do \textit{coach}
+mesmo sem serem. Por fim, os desenvolvedores sêniors trabalharam diretamente
+com os alunos, e isso foi importante para dar ao graduando a oportunidade de
+interagir com profissionais experientes em sua área e manter o conhecimento
+fluindo no projeto.
+
+Por fim, tivemos ainda dois últimos elementos da organização da equipe que
+foram essenciais para a harmonia do projeto: o \textit{meta-coach} e
+professores. O primeiro era um engenheiro de software recentemente graduado
+(nossos ex-alunos) e que queria continuar trabalhando no projeto; estes últimos
+eram professores que orquestraram todas as interações entre todos os membros do
+projeto, inclusive do governo federal. O \textit{meta-coach} normalmente
+trabalhava em uma equipe específica e tinha a tarefa extra de conhecer o estado
+atual de todas as equipes. Os professores e \textit{meta-coach} trabalharam
+juntos para reduzir o problema de comunicação entre todas as equipes (o que
+tornava-se mais complexo conforme a evolução do volume de trabalho). Por
+último, todas as tarefas burocráticas, como a elaboração de relatórios sobre o
+progresso do projeto para o Ministério, foi tratada pelos professores, mas com
+o envolvimento de toda a equipe.
+
+\subsection{Comunicação e gestão das tarefas}
+
+Nossa equipe tinha muitas pessoas trabalhando em conjunto, e a maioria dos
+sêniors trabalhavam remotamente. Além disso, tentamos manter nosso trabalho
+completamente transparente para o governo brasileiro e os cidadãos interessados
+em seguir o projeto. Para lidar com esses casos, usamos um conjunto de
+ferramentas de comunicação e outras para gerenciar o projeto.
+
+Quando um aluno tinha que trabalhar em par com um sênior, normalmente, eles
+usavam o hangout do Google para a comunicação e eles compartilhavam uma sessão
+de terminal GNU/Linux com o tmate, o que lhes permitia compartilhar o mesmo
+editor, com ambos digitando e vendo a tela. Para perguntas e discussão rápida,
+usamos o IRC. Para a notificação geral, usamos as listas de discussão.
+
+Para a gestão do projeto utilizámos o próprio portal SPB; Primeiro para
+validá-lo por nós mesmos, e também porque ele tem todas as ferramentas
+necessárias para o nosso projeto. Basicamente, criamos uma página Wiki, no
+Gitlab integrado ao SPB, com um mapeamento entre as visões estratégica, tática
+e operacional. Do ponto de vista prático, um ``milestone'' no GitLab era uma
+``História de Usuário" (funcionalidade) e um ou mais ``issues'' no GitLab era
+as tarefas para o desenvolvimento da funcionalidade em questão. Com essa
+abordagem, conseguimos dois objetivos importantes: manter toda a gestão o mais
+próximo possível do código-fonte e acompanhar cada funcionalidade desenvolvida
+durante o projeto (uma vez que nós mesmo nos tornamos usuários reais da
+plataforma).
+
+\subsection{Acompanhamento e gerenciamento de projeto de alto nível}
+
+O governo brasileiro costuma trabalhar com o desenvolvimento de software de uma
+forma mais tradicional, diferentemente de nós com métodos ágeis e software
+livre. Essa dissonância nos causou um ruído de comunicação com o governo. Foi
+especialmente difícil convencê-los a aceitar a ideia de escopo aberto e
+desenvolvimento ágil. Entretanto, depois de meses de trabalho e mostrando
+resultados, eles deixaram de resistir aos métodos empíricos.
+
+Definimos algum nível de granularidade de reunião para evitar gerar demasiada
+sobrecarga para os desenvolvedores. Tínhamos reuniões estratégica mensal e
+reuniões planejamento e revisão a cada 15 dias. Na reunião estratégica,
+geralmente, definimos as prioridades e as funcionalidades importantes para o
+governo. Normalmente, os professores, os \textit{coaches} de cada equipe, os
+\textit{meta-coaches} e alguns analistas do Ministério do Planejamento
+participavam dessa reunião. Em geral, discutíamos o que a equipe já produziu
+desde nossa última reunião e definíamos as funcionalidades para a próxima
+versão. Observe que apenas parte da equipe participava dessas reuniões
+estratégicas, mas todos os estudantes interessados estavam convidados a
+participar (pois muitos estudantes quiseram essa experiência durante o
+projeto).
+
+Depois dos encontros estratégicos com os principais atores envolvidos do
+governo, tínhamos um turno de planejamento com todas as equipes juntas. Nessa
+parte, cada equipe trabalhava junto para converter os requisitos em partes
+menores (histórias de usuário) que era representadas como ``Épicos'' da
+``release'' em desenvolvimento. Cada \textit{coach} era responsável pela
+condução do planejamento, e depois a equipe toda a registrava na página wiki do
+projeto (wiki fornecido pelo Gitlab do SPB). Baseado nos ``épicos'', a cada 15
+dias a equipe gerava um o planejamento da iteração/ciclo de desenvolvimento
+(com os pequenos passos dos problemas mapeados). Para manter o governo
+brasileiro sempre atualizado, convidávamos-os a trabalhar conosco para validar
+as funcionalidades em desenvolvimento. Para isso, tínhamos uma reunião a cada
+15 dia. E para manter nosso fluxo de gestão de tarefas, usando a própria
+plataforma do SPB, especialmente o Gitlab, tínhamos:
 \begin{enumerate}
-  \item Project repository: We have one organization with many repositories
-  \item Milestones: Each milestone was used to register a release
-  \item Wiki: Each release has one page on wiki with the compilation of
-    strategical meeting
-  \item Issues: Each sprint planning generated issues, which we associated to
-    the specific milestone and updated the wiki with the issue number related
-    with them. Finally each developer assigned the issue to itself.
+
+\item Temos uma organização com muitos repositórios para cada ferramenta
+integrada e sub-sistema;
+
+\item Cada \textit{milestone} foi usado para registrar uma história de usuário;
+
+\item Cada \textit{release} tem uma página no wiki com a compilação da reunião
+estratégica e o mapeamento sistemático das funcionalidades planejadas;
+
+\item Para cada \textit{milestone} (história de usuário) tem um conjunto de
+\textit{issues} (tarefas) específicas, que também são mapeadas na  wiki da
+\textit{release}, indicando qual dupla de desenvolvedores está trabalhando na
+\textit{issue} em questão.
+
 \end{enumerate}
-Notice that this workflow gave us and the Brazilian government agents
-full traceability from a high level view of each feature to the lowest
-level (code).
+Observe que este fluxo de trabalho proporcional a nós e aos envolvidos pelo
+governo brasileiro uma rastreabilidade completa de uma visão de alto nível de
+cada funcionalidade (requisito) até para o nível mais baixo (código).
@@ -1,51 +0,0 @@
-\section{Contributions to the upstream communities}
-\label{sec:contributions}
-
-%- projeto feito do jeito certo com relação ao software livre (contribuições upstream etc)
-%* Colab -> RevProxy
-%* Colab, atualização do python/django
-%* Contribuições para o GitLab (autenticação)
-%* Noosfero, atualização do Rails, preparação para federação, nova interface ...
-%* Coper, empacotamentos (obs), omniauth
-
-
-During the execution of this project we made several contributions to
-the upstream communities we interacted with. This occurred due to our
-development process aligned with those of the respective communities.
-During development, we would explicitly discuss  the features and bug
-fixes that we were working on with the applicable upstream communities.
-This contributed to improve the developers technical solutions with
-expertise outside of our team, and make it easier for those changes to
-be accepted in the original projects. Having changes accepted upstream
-in turn makes our life easier as it minimizes the delta between our
-codebase and upstream's allowing us to upgrade and benefit from
-development work from others.
-
-In Colab, we helped upstream redesign the entirely architecture,
-enabling the development of plugins to integrate new tools. We also
-added a feature that allowed Colab to run asynchronous tasks, which was
-a major improvement for us since we were developing a complex system. A
-migration to the latest Django version was made (web framework used by
-Colab). Moreover, we worked on RevProxy (the more important dependency
-of Colab) to put it in a good shape, fixing many bugs.
-
-Gitlab was the tool that we made the least number of modifications. We
-contributed with some improvements related with configuration files and
-we developed a new plugin that enables user authentication in Gitlab
-through the REMOTE\_USER HTTP header. This plugin was needed because
-Colab uses this mechanism to manage the authentication.
-
-Noosfero was the tool that contemplated several functional requirements,
-therefore we made a large number of contributions with upstream. We helped to
-migrate to the latest Rails version (web framework used by Noosfero), enable
-the federation implementation (federation with other social networks), decouple
-the interface and the back-end, and so forth.
-
-We also made some contributions on the DevOps front. Some members of
-them team became maintainers of some python libraries that were used by
-our scripts to upload packages to OBS (Open Build Service). We developed
-a tool called copr-status to keep track of the different stages of the
-lifecycle of each of the individual packages we were working on.
-
-%TODO: Mezuro
-
-\section{Lessons Learned}
+\section{Conclusões e Lições Aprendidas}
 \label{sec:lessons}
-\textbf{How to involve students real-world projects, interacting with
-real customers.}
+\textbf{Envolver alunos de graduação em projetos do mundo real, interagindo com clientes reais.}
 %
-Our team was mainly composed of software engineering undergraduate
-student, who had the opportunity to interact with senior developers and
-designers inside the team, as well as with the team of technicians and
-managers from the Brazilian Government, and the management team from
-UnB.
+Nossa equipe foi composta principalmente de estudantes de graduação em
+engenharia de software, que tiveram a oportunidade de interagir com
+desenvolvedores sênior e designers dentro da equipe, bem como com a equipe de
+técnicos e gerentes do governo brasileiro.
 %
-They interacted with professionals that had diverse expertises, and were
-able to participate in all levels of the software development process.
-This contribted to a great learning opportunity, and for a majority of
-them this was their first professional experience.
+Eles interagiram com profissionais que possuíam diversos conhecimentos e foram
+capazes de participar em todos os níveis do processo de desenvolvimento de
+software. Isto contribuiu para uma grande oportunidade de aprendizagem, e para
+a maioria deles esta foi a sua primeira experiência profissional.
-\textbf{The participation of experienced professionals is crucial to
-success of the project.}
-One important factor for the students was the composition of the teams
-with the participation of experienced professionals.
+\textbf{A participação de profissionais experientes é crucial para o sucesso do projeto.}
 %
-On the technical side, the senior developers and designers would handle
-the more difficult technical decisions, creating a work environment
-where the students could develop their skills in a didactic way without
-pressure.
+Um fator importante para os alunos foi a composição das equipes com a
+participação de profissionais experientes. No lado técnico, os desenvolvedores
+sênior e designers lidavam com as decisões técnicas mais difíceis, criando
+um ambiente de trabalho onde os alunos poderiam desenvolver suas habilidades de
+forma didática e sem pressão. No lado gerencial, a participação ativa dos
+professores - que são, no final, os responsáveis pelo projeto - é
+crucial para garantir que a participação dos alunos seja conduzida de forma
+saudável e seja um exemplo de liderar pelo exemplo.
+
+\textbf{Uma relação equilibrada entre academia e indústria.}
 %
-On the management side, the active participation of professors -- who
-are, in the end, the ones responsible for the project -- is crucial to
-make sure student participation is conducted in a healthy way, and is an
-instance of leading by example.
-
-\textbf{A balanced relationship between academia and industry.}
-The experience of the SPB project led UnB to develop a work style which
-proved to be appropriate for an educational environment that brings
-academia and industry together.
-%
-The highest priority from the university's point of view is the
-students.  Considering this, the activities of the project were never
-prioritized to the detriment of classes and other pedagogical
-activities. In summary, we had students working at different times, part
-time, remotely or locally, always respecting their individual
-conditions, but doing the work in a collective, collaborative and open
-way.
-%
-And even under a potentially adverse environment, the project delivered
-the desired solution with success.
+A experiência do projeto SPB levou o LAPPIS/UnB a desenvolver um estilo de trabalho que
+provou ser apropriado para um ambiente educacional que reúne academia e
+indústria. A maior prioridade do ponto de vista da universidade são os alunos.
+Diante disso, as atividades do projeto nunca foram priorizadas em detrimento
+das aulas e outras atividades pedagógicas. Em resumo, tínhamos alunos
+trabalhando em horários diferentes, a tempo parcial, localmente,
+sempre respeitando suas condições individuais, mas fazendo o trabalho de
+maneira coletiva, colaborativa e aberta. E mesmo sob um ambiente potencialmente
+adverso, o projeto entregou a solução desejada com sucesso.
 %
-At the end of the project, we noted that the skills developed by the
-students were at the state of art of the software engineering practice.
-After the project ended, we had team members successfully embracing
-opportunities in public, private, national and international
-organizations, in addition to those students that went into
-entrepreneurship and opened their own companies.
-
-\textbf{Managing different organizational cultures.}
-In the beginning of the project, the Brazilian Government stakeholders
-had certain expectations about the development of project that, let's
-say, didn't exactly match our work based on agile and FOSS practices.
+No final do projeto, notamos que as habilidades desenvolvidas pelos alunos
+estavam no estado da arte da prática de engenharia de software. Depois que o
+projeto terminou, tivemos membros da equipe que abraçaram com sucesso
+oportunidades em organizações públicas, privadas, nacionais e internacionais,
+além dos estudantes que entraram no empreendedorismo e abriram suas próprias
+empresas. No início do projeto, as partes interessadas do governo brasileiro
+tinham certas expectativas sobre o desenvolvimento de projetos que, digamos,
+não correspondiam exatamente ao nosso trabalho baseado em práticas ágeis e de
+software livre. Tivemos que desenvolver estratégias que apoiassem diferentes
+culturas organizacionais. Conforme relatado na seção\ref{sec:process}, o Ministério do Planejamento é
+organizado em uma estrutura organizacional hierárquica funcional, tipicamente,
+um paradigma de desenvolvimento tradicional. Portanto, tivemos que criar um
+processo de ``tradução'' entre nossa equipe e os analistas do MP que gerenciaram o
+projeto do lado deles.
+
+\textbf{Gerenciar separadamente os objetivos de nível estratégico e de nível operacional.}
 %
-We had to develop strategies that would support different these
-organizational cultures. As reported in Section \ref{sec:process}, the
-MP is organized in a functional hierarchical organizational structure,
-typically, a  traditional development paradigm. Therefore, we had to
-create a translation process between our team and the MP managers who
-managed the project on their side assuming a traditional, waterfall
-process.
-
-\textbf{Manage higher-level and lower-level goals separately.}
-During the initial phase of the project the MP team would often bring
-strategic discussions to technical/operational meetings, where we were
-supposed to discuss practical, technical decisions.
+Durante a fase inicial do projeto, a equipe de MP costumava trazer discussões
+estratégicas para reuniões técnicas/operacionais, onde deveríamos discutir
+decisões práticas e técnicas.
 %
-This produced a highly complex communication and management environment,
-overloading the professors because they were supposed to be responsible
-for maintaining the strategic alignment of the MP synchronized with
-implementation plans of the development team, specially in light of the
-aforementioned culture mismatch. Mixing both concerns in the same
-discussions caused confusion on both sides.
+Isso resultou em um ambiente de comunicação e gerenciamento altamente complexo,
+sobrecarregando os professores, uma vez eles eram responsáveis por
+manter o alinhamento estratégico do MP sincronizado com os planejamentos de
+implementação da equipe de desenvolvimento, especialmente à luz do
+desmembramento cultural acima mencionado. A mistura de ambas as preocupações
+nas mesmas discussões causava confusão em ambos os lados. Para o meio e fim do
+projeto, conseguimos manter essas preocupações separadas, o que facilitou o
+trabalho de todos os envolvidos.
+
+\textbf{Não aceitar más decisões técnicas por questões políticas.}
 %
-Towards the middle and end of the project we were able to keep those
-concerns separated, what eased the work of everyone involved.
-
-\textbf{Living with ill-advised political decisions.}
-At the initial phases of the project, by political and personal
-motivation, the main stakeholders from the Brazilian government imposed
-the use of Colab to guide the development of the new SPB platform.  Our
-team was totally against the idea because we already knew that Colab was
-a very experimental project and its adoption could dramatically increase
-the project complexity.  Even though we provided technical reasons to
-not utilize Colab, MP was adamant and we had to manage this problem. As
-explained in section \ref{sec:architecture} we did massive changes to
-it, and at the end of the project we completely rewrote Colab and made
-it stable. It is important to notice that the MP compelled us to accept
-a technical issue based only on political interests, without considering
-all the resources that would be spent due to that decision. At the end
-of the project, we verified that Colab indeed consumed a vast amount of
-the budget and increased the project complexity. In the end of the
-project and after our analysis on the decision made by the MP, we
-understand that MP's managers are capable of ignoring technical reasons
-in favor to a political decision.
-
-\textbf{Consider sustainability from the beginning.}
-In the process of deploying the SPB platform in the MP structure, we had
-to interact with the MP technicians. We did several workshops, training
-and a meticulous documentation describing all the required procedures to
-update the platform, however, we realized that the MP technicians
-constantly avoid the responsibility. After noticing the aforementioned
-situation, we organized a specific DevOps that completely automated all
-the deployment procedure. We simplified all the platform deployment to a
-few steps: (1) initial configurations (just ssh configuration) and (2)
-the execution of simple commands to completely update the platform. By
-the end of the project, we observed that the MP technicians invariably
-still depended on our support to update the platform even with all the
-automation provided by us. We were sadly left with a feeling of
-uncertainty about the future of the platform after the project ended. In
-hindsight, we realize that the MP dedicated systems analysts and
-managers to the project, but not operations technicians. The later
-should have been more involved with the process so they could at least
-comfortable with managing the platform infrastructure.
-
-% * Gestão dos recursos: Fizemos mais por menos (2.6M de 3.2M) --- sem os dados
-%% (escopo, custo, tempo e qualidade) bem discutidos é difícil sustentar essa
-%% afirmação, embora eu e Paulo consigamos perceber isso.
-
-%===========
-% Conclusion
-%===========
-
-\section{Final remarks}
-
-The portal is available at \url{softwarepublico.gov.br}. All
-documentation, including detailed architecture and operation manuals are
-also available\footnote{\url{https://softwarepublico.gov.br/doc/}
-(in Portuguese only at the moment)}).
+Nas fases iniciais do projeto, por motivação política e pessoal, os principais
+atores do governo brasileiro, envolvidos na época, impuseram o uso da Colab
+para orientar o desenvolvimento da nova plataforma SPB. Nossa equipe estava
+totalmente contra a essa ideia, porque já sabíamos que o Colab era um projeto
+muito experimental e sua adoção poderia aumentar dramaticamente a complexidade
+do projeto. Mesmo nós fornecendo as razões técnicas para não utilizar Colab, MP
+foi inflexível e tivemos de gerir este problema. Fizemos mudanças maciças e, no
+final do projeto, reescrevemos completamente o Colab e o tornamos estável (o
+transformando em um Sistema de Sistema em camada de aplicação). É importante
+notar que o MP nos obrigou a aceitar uma questão técnica baseada apenas em
+interesses políticos, sem considerar todos os recursos que seriam gastos devido
+a essa decisão. No final do projeto, verificamos que a Colab de fato consumiu a
+maior quantidade do orçamento e aumentou a complexidade do projeto.
+
+\textbf{Considerar a sustentabilidade desde o início.}
 %
-All the integrated tools are FOSS and our contributions were published
-in open repositories, available on the SPB Portal itself. We also
-contributed these features back to the respective communities: that
-benefits those communities, as well as us since we can share future
-development and maintenance effort with other organizations that
-participate in their projects.
-
-More discussion ...
-
-...
-
-...
-
-%* utilização do projeto para formação de recursos humanos (alunos)
-
-%* dados da verificação dos repositório para a análise da qualidade dos código via Mezuro e CodeClimate
-
-%* o que achamos que irá acontecer com o SPB no futuro breve (acabar)
-
-%* 69 projetos marcados como SPB, de 81 no total na plataforma.
-
-%* 47\% é desenvolvido em PHP.
-
-% foi constatado que aproximadamente 75\% dos softwares \textbf{não} possuem seus códigos-fonte versionados nesta ferramenta. Realizado algumas pesquisas, foi encontrado o código-fonte em outros serviços (Github, Bitbucket).
-
-% Foram adicionados 31 softwares do SPB em ambas as ferramentas (Mezuro e Code Climate), desenvolvidos em PHP e Python. Estas adições resultaram na análise descrita nos próximos parágrafos. No Mezuro, dos 31 softwares adicionados, somente 4 obtiveram sucesso na avaliação. No Code Climate, 16 softwares realizaram a \textit{build} da avaliação com sucesso. Nos que falharam, alguns dos erros foram encontrados em três das \textit{engines}: ora em \textit{duplication}, ora na \textit{phpmd}, ora na \textit{eslint}.
-
-% também foram inseridos no Mezuro para avaliação, 5 projetos dos 17 desenvolvidos em Java, com o intuito de ser um contraponto ao Code Climatepor esta não compreender a análise de projetos em Java, C, ou C++. Infelizmente nenhuma das \textit{builds} resultou em resultados concretos.
-
-%* Debater economia de recursos em orgão públicos
+No processo de implantação da plataforma SPB na estrutura MP, tivemos que
+interagir com os técnicos MP. Fizemos vários workshops, treinamento e uma
+documentação meticulosa descrevendo todos os procedimentos necessários para
+atualizar a plataforma, no entanto, percebemos que os técnicos MP
+constantemente evitavam essa responsabilidade. Depois de notar essa situação,
+nós organizamos uma equipe de DevOps específica que automatizou completamente
+todo o procedimento de implantação. Nós simplificamos toda a implantação da
+plataforma para algumas etapas: (1) configurações iniciais (apenas configuração
+SSH) e (2) a execução de comandos simples para atualizar completamente a
+plataforma. Ao final do projeto, observamos que os técnicos MP sempre dependiam
+do nosso apoio para atualizar a plataforma, mesmo com toda a automação
+fornecida por nós.  Ficamos tristemente com um sentimento de incerteza sobre o
+futuro da plataforma após o término do projeto. Em retrospectiva, percebemos
+que o MP dedicou analistas de sistemas e gerentes para o projeto, mas não
+técnicos de operações e desenvolvedores, que deveria ter sido envolvido com o
+processo para que pudesse, pelo menos, de forma confortável fazer o manutenção
+da infra-estrutura plataforma.
+
+Por fim, o novo portal do Software Público Brasileiro está disponível em
+\url{https://softwarepublico.gov.br}. Toda a documentação, incluindo a
+arquitetura detalhada e os manuais de operação, também estão disponíveis em
+\url{https://softwarepublico.gov.br/doc}. Todas as ferramentas integradas são
+software livre e nossas contribuições foram publicadas em repositórios abertos,
+disponíveis no próprio portal SPB. Também contribuímos com funcionalidades e
+melhorias para as respectivas comunidades dos projetos integrados: que
+beneficiam essas comunidades, assim como nós, pois podemos compartilhar o
+desenvolvimento futuro e o esforço de manutenção com outras organizações que
+participam de seus projetos.
@@ -14,21 +14,21 @@
 \sloppy
 \title{Lições aprendidas no desenvolvimento do novo portal do Software Público Brasileiro}
-\author{Paulo Meirelles\inst{1,3}, Antonio Terceiro\inst{2}, Melissa Wen\inst{2},
-       \\Rodrigo Siqueira\inst{3}, Hilmer Neri\inst{1}}
+\author{Paulo Meirelles\inst{1,3}, Antonio Terceiro\inst{2}, Rodrigo Siqueira\inst{3},
+       \\Melissa Wen\inst{2}, Hilmer Neri\inst{1}}
 \address{Laboratório de Produção, Pesquisa e Inovação em Sofware(LAPPIS)\\
-	Faculdade UnB Gama (FGA) -- Universidade de Brasília (UnB)\\
-	Área Especial de Indústria Projeção A, Setor Leste -- Gama - DF -- Brasil
+	Faculdade UnB Gama (FGA) -- Universidade de Brasília (UnB)
+%	Área Especial de Indústria Projeção A, Setor Leste -- Gama - DF -- Brasil
   	\email{\{paulormm,hilmer\}@unb.br}
 \nextinstitute
-	Cooperativa de Trabalho em Tecnologias Livres -- Colivre\\
-	Rua Marechal Floriano, 28, Canela, Salvador - BA -- Brasil
+	Cooperativa de Trabalho em Tecnologias Livres -- Colivre
+%	\\Rua Marechal Floriano, 28, Canela, Salvador - BA -- Brasil
 	\email{\{terceiro,melissa\}@colivre.coop.br}
 \nextinstitute
 	Centro de Competência em Software Livre (CCSL)\\
-	Instituto de Matemática e Estatística (IME) -- Universidade de São Paulo (USP)\\
-	Rua do Matão, 1010, Cidade Universitária -- São Paulo - SP -- Brasil
+	Instituto de Matemática e Estatística (IME) -- Universidade de São Paulo (USP)
+%	\\Rua do Matão, 1010, Cidade Universitária -- São Paulo - SP -- Brasil
 	\email{\{paulormm,siqueira\}@ime.usp.br}
 }
@@ -42,9 +42,8 @@
 \input{content/03-requirements}
 \input{content/04-architecture}
 \input{content/05-features}
-%\input{content/06-ux}
+\input{content/06-ux}
 \input{content/07-process}
-%\input{content/08-contributions}
 \input{content/09-lessons}
 %------------------------------------------------------------------------------
	@@ -6,6 +6,6 @@ helping the Brazilian public administration to share its solutions. In this pape		@@ -6,6 +6,6 @@ helping the Brazilian public administration to share its solutions. In this pape
6		6
7	\begin{resumo}	7	\begin{resumo}
8		8
9	-O Software Público Brasileiro (SPB) é um programa do Governo Federal Brasileiro para promover o compartilhamento e a colaboração em soluções de Software Livre para a administração pública. Um Software Público Brasileiro é considerado um bem público e o governo federal assume algumas responsabilidades relacionadas ao seu uso, mas tem os mesmos princípios de desenvolvimento de software livre como a tendência à descentralização na tomada de decisões, o compartilhamento de informações e do desenvolvimento (código), e a interação contínua com seus usuários. Nesse contexto, criamos uma plataforma baseada na integração e evolução de ferramentas FOSS existentes. Hoje em dia, o SPB Portal oferece diversas funcionalidades modernas para o desenvolvimento de software colaborativo, ajudando a administração pública brasileira a compartilhar suas soluções. Neste artigo, apresentamos a plataforma integrada de desenvolvimento de software desenvolvida para o programa por uma equipe heterogênea composta por professores, mestrandos, estudantes de graduação e profissionais das comunidades do software livre. Neste relato de experiência, juntamente com a arquitetura da plataforma, funcionalidades e os esforços na evolução da experiência do usuário, também discutimos nosso processo de trabalho, baseado em práticas de desenvolvimento de software ágil e livre, e as lições aprendidas em 30 meses de trabalho sobre o projeto SPB.	9	+O Software Público Brasileiro (SPB) é um programa do Governo Federal Brasileiro para promover o compartilhamento e a colaboração em soluções de Software Livre para a administração pública. Um Software Público Brasileiro é considerado um bem público e o governo federal assume algumas responsabilidades relacionadas ao seu uso, mas tem os mesmos princípios de desenvolvimento de software livre como a tendência à descentralização na tomada de decisões, o compartilhamento de informações e do desenvolvimento (código), e a interação contínua com seus usuários. Nesse contexto, criamos uma plataforma baseada na integração e evolução de ferramentas livres existentes. Hoje em dia, o SPB Portal oferece diversas funcionalidades modernas para o desenvolvimento de software colaborativo, ajudando a administração pública brasileira a compartilhar suas soluções. Neste artigo, apresentamos a plataforma integrada de desenvolvimento de software desenvolvida, para o programa SPB, por uma equipe heterogênea composta por professores, mestrandos, estudantes de graduação e profissionais das comunidades do software livre. Neste relato de experiência, juntamente com a arquitetura da plataforma, funcionalidades e os esforços na evolução da experiência do usuário, também discutimos nosso processo de trabalho, baseado em práticas de desenvolvimento de software ágil e livre e as lições aprendidas em 30 meses de trabalho sobre o projeto SPB.
10		10
11	\end{resumo}	11	\end{resumo}
1	\section{Introdução}	1	\section{Introdução}
2	\label{sec:intro}	2	\label{sec:intro}
3		3
4	-Durante as últimas décadas, o governo federal brasileiro vem tentando mudar seus processos de adoção e desenvolvimento de software. Por exemplo, em 2003, a recomendação de adotar software livre\footnote{Neste artigo, usamos o termo software livre como referente à Free and Open Source Software (FOSS).} tornou-se uma política pública. Em 2007, o governo brasileiro lançou um portal chamado Software Público Brasileiro (SPB), com o objetivo de compartilhar projetos de software livre desenvolvidos pelo governo brasileiro ou para o mesmo. Adicionalmente, o instrumento jurídico brasileiro de contratação de software (denominado IN 04/2012) determina que os agentes públicos devem priorizar as soluções disponíveis no Portal SPB. Em suma, a aquisição de uma solução proprietária deve ser explicitamente justificada ao demonstrar que não há alternativa adequada no Portal SPB. Em 2013, o Tribunal Federal emitiu o Acórdão 2314/2013 sobre o uso de metodologias ágeis em contratos de desenvolvimento de software com a administração pública.	4	+Durante as últimas décadas, o governo federal brasileiro vem tentando mudar
		5	+seus processos de adoção e desenvolvimento de software. Por exemplo, em 2003, a
		6	+recomendação de adotar software livre\footnote{Neste artigo, usamos o termo
		7	+software livre como referente à Free and Open Source Software (FOSS).}
		8	+tornou-se uma política pública. Em 2007, o governo brasileiro lançou um portal
		9	+chamado Software Público Brasileiro (SPB), com o objetivo de compartilhar
		10	+projetos de software livre desenvolvidos pelo governo brasileiro ou para o
		11	+mesmo. Adicionalmente, o instrumento jurídico brasileiro de contratação de
		12	+software (denominado IN 04/2012) determina que os agentes públicos devem
		13	+priorizar as soluções disponíveis no Portal SPB. Em suma, a aquisição de uma
		14	+solução proprietária deve ser explicitamente justificada ao demonstrar que não
		15	+há alternativa adequada no Portal SPB. Em 2013, o Tribunal Federal emitiu o
		16	+Acórdão 2314/2013 sobre o uso de metodologias ágeis em contratos de
		17	+desenvolvimento de software com a administração pública.
5		18
6	-Apesar disso, na prática, as metodologias de desenvolvimento de software livre ou ágeis, isto é, os métodos colaborativos e empíricos de desenvolvimento de software, não são amplamente praticadas e entendidas pelos agentes do governo brasileiro. Dessa forma, os processos hierárquicos e tradicionais do governo e a falta de expertise no desenvolvimento de software real de seus agentes produzem uma situação de contratos de desenvolvimento de software ineficiente.	19	+Apesar disso, na prática, as metodologias de desenvolvimento de software livre
		20	+ou ágeis, isto é, os métodos colaborativos e empíricos de desenvolvimento de
		21	+software, não são amplamente praticadas e entendidas pelos agentes do governo
		22	+brasileiro. Dessa forma, os processos hierárquicos e tradicionais do governo e
		23	+a falta de expertise no desenvolvimento de software real de seus agentes
		24	+produzem uma situação de contratos de desenvolvimento de software ineficiente.
7		25
8	-Desde 2009, o SPB Portal teve vários problemas técnicas. O código original da plataforma não estava mias sendo desenvolvido, e havia uma grande quantidade de dívidas técnicas para superar. O sistema era uma versão modificada de uma plataforma livre existente chamada OpenACS\footnote{\url{http://openacs.org}}, e o antigo portal SPB não estava sendo atualizado com os lançamentos oficiais do OpenACS. Nesse cenário, a manutenção do portal estava se tornando cada vez mais difícil.	26	+Desde 2009, o SPB Portal teve vários problemas técnicas. O código original da
		27	+plataforma não estava mias sendo desenvolvido, e havia uma grande quantidade de
		28	+dívidas técnicas para superar. O sistema era uma versão modificada de uma
		29	+plataforma livre existente chamada OpenACS\footnote{\url{http://openacs.org}},
		30	+e o antigo portal SPB não estava sendo atualizado com os lançamentos oficiais
		31	+do OpenACS. Nesse cenário, a manutenção do portal estava se tornando cada vez
		32	+mais difícil.
9		33
10	-Depois de alguns eventos e encontros para coletar os requisitos via os agentes do governo federal e da sociedade, foi desenvolvida, entre janeiro de 2014 e junho de 2016, uma nova plataforma para o Portal SPB, pelo Universidade de Brasília (UnB) e da Universidade de São Paulo (USP) em parceria com o Ministério de Orçamento, Planejamento e Gestão (MP). Ele foi projetado como uma plataforma integrada para desenvolvimento de software colaborativo, e inclui funcionalidade para redes sociais, listas de discussão, sistema de controle de versão e monitoramento de qualidade de código-fonte. Para coordenar e desenvolver esse projeto durante 30 meses, a UnB recebeu do Governo Federal Brasileiro um total de 2.619.965,00 reais.	34	+Depois de alguns eventos e encontros para coletar os requisitos via os agentes
		35	+do governo federal e da sociedade, foi desenvolvida, entre janeiro de 2014 e
		36	+junho de 2016, uma nova plataforma para o Portal SPB, pelo Universidade de
		37	+Brasília (UnB) e da Universidade de São Paulo (USP) em parceria com o
		38	+Ministério de Orçamento, Planejamento e Gestão (MP). Ele foi projetado como uma
		39	+plataforma integrada para desenvolvimento de software colaborativo, e inclui
		40	+funcionalidade para redes sociais, listas de discussão, sistema de controle de
		41	+versão e monitoramento de qualidade de código-fonte. Para coordenar e
		42	+desenvolver esse projeto durante 30 meses, a UnB recebeu do Governo Federal
		43	+Brasileiro um total de 2.619.965,00 reais.
11		44
12	\begin{figure*}[hbt]	45	\begin{figure*}[hbt]
13	\centering	46	\centering
	@@ -16,8 +49,38 @@ Depois de alguns eventos e encontros para coletar os requisitos via os agentes d		@@ -16,8 +49,38 @@ Depois de alguns eventos e encontros para coletar os requisitos via os agentes d
16	\label{fig:spb}	49	\label{fig:spb}
17	\end{figure*}	50	\end{figure*}
18		51
19	-O projeto foi desenvolvido por uma equipe de 3 professores, 2 estudantes de mestrado e cerca de 50 alunos de graduação (não todos ao mesmo tempo), juntamente com 2 designers profissionais e 6 desenvolvedores sêniors da comunidade software livre. Os professores e todos os estudantes de graduação eram da UnB e os mestrandos eram da USP. Quanto aos designers e desenvolvedores seniores, 7 dos 8 viviam fora de Brasília: Curitiba, São Paulo, Ribeirão Preto, Salvador, Punta Cana/República Dominicana e Montreal/Canadá. Em outras palavras, nós tínhamos uma equipe trabalhando em um ambiente virtual colaborativo e distribuído.	52	+O projeto foi desenvolvido por uma equipe de 3 professores, 2 estudantes de
		53	+mestrado e cerca de 50 alunos de graduação (não todos ao mesmo tempo),
		54	+juntamente com 2 designers profissionais e 6 desenvolvedores sêniors da
		55	+comunidade software livre. Os professores e todos os estudantes de graduação
		56	+eram da UnB e os mestrandos eram da USP. Quanto aos designers e desenvolvedores
		57	+seniores, 7 dos 8 viviam fora de Brasília: Curitiba, São Paulo, Ribeirão Preto,
		58	+Salvador, Punta Cana/República Dominicana e Montreal/Canadá. Em outras
		59	+palavras, nós tínhamos uma equipe trabalhando em um ambiente virtual
		60	+colaborativo e distribuído.
20		61
21	-Figura \ref{fig:spb} mostra a página inicial desta plataforma integrada, que acesso (1) lista de discussões (Mailmain), (2) ambiente de apoio ao desenvolvimento (GitLab e Mezuro) e (3) rede social (Noosfero) com as páginas dos projetos e soluções disponíveis. Todo o desenvolvimento foi feito de forma aberta, e as mudanças que precisávamos nas ferramentas foram devolvidas às suas respectivas comunidades. Nosso processo foi baseado em práticas ágeis e nos mecanismos empíricos das comunidades de software livre. Definimos ciclos de desenvolvimento e lançamos 5 versões do novo SPB Portal. A primeira versão (beta) foi disponibilizada em setembro de 2014, apenas 9 meses desde o início do projeto. O antigo portal foi desligado em setembro de 2015. Por fim, a última versão, ilustrada na Figura\ref{fig:spb}, foi entregue em junho de 2016.	62	+Figura \ref{fig:spb} mostra a página inicial desta plataforma integrada, que
		63	+acesso (1) lista de discussões (Mailmain), (2) ambiente de apoio ao
		64	+desenvolvimento (GitLab e Mezuro) e (3) rede social (Noosfero) com as páginas
		65	+dos projetos e soluções disponíveis. Todo o desenvolvimento foi feito de forma
		66	+aberta, e as mudanças que precisávamos nas ferramentas foram devolvidas às suas
		67	+respectivas comunidades. Nosso processo foi baseado em práticas ágeis e nos
		68	+mecanismos empíricos das comunidades de software livre. Definimos ciclos de
		69	+desenvolvimento e lançamos 5 versões do novo SPB Portal. A primeira versão
		70	+(beta) foi disponibilizada em setembro de 2014, apenas 9 meses desde o início
		71	+do projeto. O antigo portal foi desligado em setembro de 2015. Por fim, a
		72	+última versão, ilustrada na Figura \ref{fig:spb}, foi entregue em junho de 2016.
22		73
23	-Neste artigo, apresentamos uma visão geral dessa nova geração do Portal SPB. Este relato de experiência compartilha nossa metodologia e processo de desenvolvimento desse projeto, trabalhando com o governo federal brasileiro para cumprir suas exigências, ao mesmo tempo ser o mais fiel possível às comunidades de software livre envolvidas. Além disso, discutimos várias lições aprendidas para fornecer um ambiente virtual colaborativo e distribuído, envolvendo uma grande equipe de estudantes de graduação e desenvolvedores sêniors remotos. Por fim, lançamos uma plataforma sem precedentes para o governo brasileiro aplicar métodos colaborativos de desenvolvimento de software. Este caso pode ajudar outros projetos a superar desafios similares de engenharia de software no futuro, bem como demonstra como as universidades podem melhorar a experiência de mundo real de seus alunos por meio desse tipo de projeto.	74	+Neste artigo, apresentamos uma visão geral dessa nova geração do Portal SPB.
		75	+Este relato de experiência compartilha nossa metodologia e processo de
		76	+desenvolvimento desse projeto, trabalhando com o governo federal brasileiro
		77	+para cumprir suas exigências, ao mesmo tempo ser o mais fiel possível às
		78	+comunidades de software livre envolvidas. Além disso, discutimos várias lições
		79	+aprendidas para fornecer um ambiente virtual colaborativo e distribuído,
		80	+envolvendo uma grande equipe de estudantes de graduação e desenvolvedores
		81	+sêniors remotos. Por fim, lançamos uma plataforma sem precedentes para o
		82	+governo brasileiro aplicar métodos colaborativos de desenvolvimento de
		83	+software. Este caso pode ajudar outros projetos a superar desafios similares de
		84	+engenharia de software no futuro, bem como demonstra como as universidades
		85	+podem melhorar a experiência de mundo real de seus alunos por meio desse tipo
		86	+de projeto.
1	\section{O Software Público Brasileiro}	1	\section{O Software Público Brasileiro}
2	\label{sec:spb}	2	\label{sec:spb}
3		3
4	-Software livre é um fenômeno que ganhou notoriedade nos últimos anos e tem atraído o interesse da academia. No entanto, desde o início da computação, a maioria dos desenvolvedores trabalhou da maneira que agora identificamos como software livre, ou seja, compartilhando códigos abertamente. Essa abertura torna o código disponível para inspeção, modificação e uso por qualquer pessoa ou organização\cite{hippel2003, kon2012}.	4	+Software livre é um fenômeno que ganhou notoriedade nos últimos anos e tem
		5	+atraído o interesse da academia. No entanto, desde o início da computação, a
		6	+maioria dos desenvolvedores trabalhou da maneira que agora identificamos como
		7	+software livre, ou seja, compartilhando códigos abertamente. Essa abertura
		8	+torna o código disponível para inspeção, modificação e uso por qualquer pessoa
		9	+ou organização\cite{hippel2003, kon2012}.
5		10
6	-Os elementos que distinguem o software livre de outros tipos de software são o pensamento sobre o processo de desenvolvimento, o contexto econômico, a relação entre desenvolvedores e usuários, bem como as características éticas e legais que se relacionam com o software. No contexto do software livre, a liberdade do usuário é promovida e seu desenvolvimento é baseado em práticas abertas de colaboração e desenvolvimento\cite{meirelles2013}.	11	+Os elementos que distinguem o software livre de outros tipos de software são o
		12	+pensamento sobre o processo de desenvolvimento, o contexto econômico, a relação
		13	+entre desenvolvedores e usuários, bem como as características éticas e legais
		14	+que se relacionam com o software. No contexto do software livre, a liberdade do
		15	+usuário é promovida e seu desenvolvimento é baseado em práticas abertas de
		16	+colaboração e desenvolvimento\cite{meirelles2013}.
7		17
8	-Do ponto de vista econômico, ao contrário do que acontece com o software proprietário, o software livre promove o estabelecimento de vários fornecedores que podem competir uns com os outros com base no mesmo software. Essa forte concorrência entre os fornecedores traz benefícios para os usuários, porque dá melhores garantias em relação à evolução do sistema, levando a uma redução dos custos\cite{kon2012}. Essas liberdades e garantias sobre software são regidas no Brasil pela Lei 9610/98 (lei de direitos autorais). Na maioria das vezes, essa proteção da lei está em conformidade com os termos conferidos por um contrato relacionado a determinado software. Esse contrato é chamado de ``licença''. Uma licença de software determina uma lista de direitos que são concedidos, e deveres que são impostos a um usuário do software. Em particular, o que diferencia software livre de software proprietário é apenas a forma como eles são licenciados\cite{sabino2009}. As licenças de software livre garantem o direito de executar, estudar, adaptar e melhorar o software.	18	+Do ponto de vista econômico, ao contrário do que acontece com o software
		19	+proprietário, o software livre promove o estabelecimento de vários fornecedores
		20	+que podem competir uns com os outros com base no mesmo software. Essa forte
		21	+concorrência entre os fornecedores traz benefícios para os usuários, porque dá
		22	+melhores garantias em relação à evolução do sistema, levando a uma redução dos
		23	+custos\cite{kon2012}. Essas liberdades e garantias sobre software são regidas
		24	+no Brasil pela Lei 9610/98 (lei de direitos autorais). Na maioria das vezes,
		25	+essa proteção da lei está em conformidade com os termos conferidos por um
		26	+contrato relacionado a determinado software. Esse contrato é chamado de
		27	+``licença''. Uma licença de software determina uma lista de direitos que são
		28	+concedidos, e deveres que são impostos a um usuário do software. Em particular,
		29	+o que diferencia software livre de software proprietário é apenas a forma como
		30	+eles são licenciados\cite{sabino2009}. As licenças de software livre garantem o
		31	+direito de executar, estudar, adaptar e melhorar o software.
9		32
10	-A versão original do portal SPB foi projetada em 2005 e lançada em 2007. O propósito do portal era apenas compartilhar o software desenvolvido no governo brasileiro, para reduzir os custos de contratação de software. No entanto, observou-se que quando os projetos de software foram lançados, suas comunidades foram formadas em torno desses sistemas com várias pessoas colaborando e compartilhando os resultados obtidos com o uso dessas soluções. Dessa forma, algumas cooperativas de desenvolvimento de software e empresas privadas demonstraram interesse em disponibilizar seus sistemas na plataforma SPB.	33	+A versão original do portal SPB foi projetada em 2005 e lançada em 2007. O
		34	+propósito do portal era apenas compartilhar o software desenvolvido no governo
		35	+brasileiro, para reduzir os custos de contratação de software. No entanto,
		36	+observou-se que quando os projetos de software foram lançados, suas comunidades
		37	+foram formadas em torno desses sistemas com várias pessoas colaborando e
		38	+compartilhando os resultados obtidos com o uso dessas soluções. Dessa forma,
		39	+algumas cooperativas de desenvolvimento de software e empresas privadas
		40	+demonstraram interesse em disponibilizar seus sistemas na plataforma SPB.
11		41
12	-Em resumo, o conceito de Software Público Brasileiro vai além do software livre. Além de estar licenciado sob uma licença de software livre, um software público precisa ter garantias explícitas de que é um bem público, e esse projeto deve estar disponível no portal SPB. Ser um verdadeiro bem público pressupõe requisitos que não podem ser satisfeitos apenas por meio de licenciamento de software livre. Por exemplo, deve haver uma política de uso de marca menos rígida pelo fornecedor original que não impeça eventuais concorrentes de serviços de publicidade para esse mesmo software. A inclusão no SPB Portal também tem requisitos extras, como ter um sistema de controle de versão pública, manual de instalação e especificação de requisitos de hardware.	42	+Em resumo, o conceito de Software Público Brasileiro vai além do software
		43	+livre. Além de estar licenciado sob uma licença de software livre, um software
		44	+público precisa ter garantias explícitas de que é um bem público, e esse
		45	+projeto deve estar disponível no portal SPB. Ser um verdadeiro bem público
		46	+pressupõe requisitos que não podem ser satisfeitos apenas por meio de
		47	+licenciamento de software livre. Por exemplo, deve haver uma política de uso de
		48	+marca menos rígida pelo fornecedor original que não impeça eventuais
		49	+concorrentes de serviços de publicidade para esse mesmo software. A inclusão no
		50	+SPB Portal também tem requisitos extras, como ter um sistema de controle de
		51	+versão pública, manual de instalação e especificação de requisitos de hardware.
13		52
1	\section{Requisitos e projetos relacionados}	1	\section{Requisitos e projetos relacionados}
2	\label{sec:requirements}	2	\label{sec:requirements}
3		3
4	-Para conceber o novo portal SPB, o governo brasileiro organizou 3 eventos para coletar os requisitos, em particular do ponto de vista da sociedade. Após essas 3 rodadas de discussão sobre a nova plataforma SPB, o governo brasileiro listou cerca de 145 requisitos e desenvolveu um ``mapa mental''\footnote{\url{https://softwarepublico.gov.br/social/spb/gallery/mapaconceitual.png}} para guiar a evolução do portal SPB. Nesse cenário, os 10 requisitos mais votados foram, por exemplo:	4	+Para conceber o novo portal SPB, o governo brasileiro organizou 3 eventos para
		5	+coletar os requisitos, em particular do ponto de vista da sociedade. Após essas
		6	+3 rodadas de discussão sobre a nova plataforma SPB, o governo brasileiro listou
		7	+cerca de 145 requisitos e desenvolveu um ``mapa
		8	+mental''\footnote{\url{https://softwarepublico.gov.br/social/spb/gallery/mapaconceitual.png}}
		9	+para guiar a evolução do portal SPB. Nesse cenário, os 10 requisitos mais
		10	+votados foram, por exemplo:
5		11
6	\begin{enumerate}	12	\begin{enumerate}
7	\item Repositório de código-fonte com acesso público.	13	\item Repositório de código-fonte com acesso público.
	@@ -16,7 +22,14 @@ Para conceber o novo portal SPB, o governo brasileiro organizou 3 eventos para c		@@ -16,7 +22,14 @@ Para conceber o novo portal SPB, o governo brasileiro organizou 3 eventos para c
16	\item Relatório da experiência sobre o uso de um software público.	22	\item Relatório da experiência sobre o uso de um software público.
17	\end{enumerate}	23	\end{enumerate}
18		24
19	-Haviam outros requisitos baseados na experiência dos analistas de TI do governo brasileiro e da comunidade software livre brasileira. Por exemplo, a nova plataforma só funcionaria corretamente se houver uma autenticação única para usar as ferramentas fornecidas. Além disso, uma interface unificada era um requisito não-funcional importante para ter uma melhor experiência de usuário na nova plataforma. Assim, no primeiro momento, desejamos disponibilizar uma versão inicial que poderia substituir o antigo portal SPB. Para isso, a primeira versão deve ter recursos como:	25	+Haviam outros requisitos baseados na experiência dos analistas de TI do governo
		26	+brasileiro e da comunidade software livre brasileira. Por exemplo, a nova
		27	+plataforma só funcionaria corretamente se houver uma autenticação única para
		28	+usar as ferramentas fornecidas. Além disso, uma interface unificada era um
		29	+requisito não-funcional importante para ter uma melhor experiência de usuário
		30	+na nova plataforma. Assim, no primeiro momento, desejamos disponibilizar uma
		31	+versão inicial que poderia substituir o antigo portal SPB. Para isso, a
		32	+primeira versão deve ter recursos como:
20		33
21	\begin{enumerate}	34	\begin{enumerate}
22	\item Um catálogo de software público organizado.	35	\item Um catálogo de software público organizado.
	@@ -26,22 +39,71 @@ Haviam outros requisitos baseados na experiência dos analistas de TI do governo		@@ -26,22 +39,71 @@ Haviam outros requisitos baseados na experiência dos analistas de TI do governo
26	\item Listas de discussão e fóruns de discussão.	39	\item Listas de discussão e fóruns de discussão.
27	\end{enumerate}	40	\end{enumerate}
28		41
29	-Outros requisitos também foram planejados durante a fase de concepção do projeto de evolução do SPB, como um mecanismo de busca integrado e um monitor de análise estática de código-fonte na web. Analisando todos esses requisitos, criamos o projeto de evolução do SPB baseado em ferramentas de software livre existentes. No entanto, a integração de vários sistemas existentes que já foram implementados em diferentes linguagens de programação e arcabouços, adicionando recursos como uma autenticação centralizada, interface unificada e um mecanismo de pesquisa, bem como, outros recursos de \textit{back-end}, requeriria grande quantidade de trabalho não-trivial.	42	+Outros requisitos também foram planejados durante a fase de concepção do
		43	+projeto de evolução do SPB, como um mecanismo de busca integrado e um monitor
		44	+de análise estática de código-fonte na web. Analisando todos esses requisitos,
		45	+criamos o projeto de evolução do SPB baseado em ferramentas de software livre
		46	+existentes. No entanto, a integração de vários sistemas existentes que já foram
		47	+implementados em diferentes linguagens de programação e arcabouços, adicionando
		48	+recursos como uma autenticação centralizada, interface unificada e um mecanismo
		49	+de pesquisa, bem como, outros recursos de \textit{back-end}, requeriria grande
		50	+quantidade de trabalho não-trivial.
30		51
31	-A nova plataforma SPB é um ambiente totalmente integrado, sendo muito avançada em comparação com projetos e iniciativas relacionados. Por exemplo, o governo dos EUA tem uma plataforma criada para melhorar o acesso ao software desenvolvido pelo governo federal\footnote{\url{https://code.gov}}. Code.gov é uma interface para organizar os projetos do governo dos EUA e, em suma, facilita aos usuários e desenvolvedores como obter informações e acessar repositórios de código-fonte dos projeto do governo no GitHub. No entanto, não há recursos de rede social e CMS, bem como outros recursos de comunicação fornecidos por essa plataforma.	52	+A nova plataforma SPB é um ambiente totalmente integrado, sendo muito avançada
		53	+em comparação com projetos e iniciativas relacionados. Por exemplo, o governo
		54	+dos EUA tem uma plataforma criada para melhorar o acesso ao software
		55	+desenvolvido pelo governo federal\footnote{\url{https://code.gov}}. Code.gov é
		56	+uma interface para organizar os projetos do governo dos EUA e, em suma,
		57	+facilita aos usuários e desenvolvedores como obter informações e acessar
		58	+repositórios de código-fonte dos projeto do governo no GitHub. No entanto, não
		59	+há recursos de rede social e CMS, bem como outros recursos de comunicação
		60	+fornecidos por essa plataforma.
32		61
33	-Além disso, existem duas iniciativas na Europa: OSOR\footnote{\url{https://joinup.ec.europa.eu/community/osor}} e OW2\footnote{\url{http://ow2.org}}. O Open Source Observatory (OSOR) é uma comunidade hospedada na plataforma JoinUp, patrocinada pela \textit{European Commission}. O OSOR tem como objetivo o intercâmbio de informações, experiências e melhores práticas sobre o uso de software livre na administração pública. Ajuda a encontrar um software livre disponibilizado por outras administrações públicas, proporcionando acesso a informações como notícias, eventos, estudos e soluções relacionadas à implementação de software livre. Ele também oferece fórum e listas de discussão da comunidade, mas não possui um gerenciador de repositório de código-fonte integrado e para cada projeto há um link para seu próprio repositório externo (ou seu arquivo tarball).
34	-%
35	-OW2 é uma espécie de consórcio de projetos de software livre para promover o desenvolvimento de \textit{middleware} livres, aplicativos de negócios, plataformas de computação em nuvem e promover um ecossistema de comunidade e negócios. Em resumo, ele visa apoiar o desenvolvimento, implantação e gerenciamento de soluções distribuídos com foco em middleware, não sendo uma plataforma em si.
36	-%
37	-Além disso, patrocinado pela \textit{European Commission} entre 2007 e 20011, havia o projeto QualiPSo que visava fornecer aos usuários, desenvolvedores e consumidores de software livre recursos e conhecimentos de qualidade sobre os vários tópicos relacionados ao software livre. O projeto QualiPSo também planejava desenvolver uma plataforma chamada QualiPSo Factory, que não foi totalmente concluída.	62	+Além disso, existem duas iniciativas na Europa:
		63	+OSOR\footnote{\url{https://joinup.ec.europa.eu/community/osor}} e
		64	+OW2\footnote{\url{http://ow2.org}}. O Open Source Observatory (OSOR) é uma
		65	+comunidade hospedada na plataforma JoinUp, patrocinada pela \textit{European
		66	+Commission}. O OSOR tem como objetivo o intercâmbio de informações,
		67	+experiências e melhores práticas sobre o uso de software livre na administração
		68	+pública. Ajuda a encontrar um software livre disponibilizado por outras
		69	+administrações públicas, proporcionando acesso a informações como notícias,
		70	+eventos, estudos e soluções relacionadas à implementação de software livre. Ele
		71	+também oferece fórum e listas de discussão da comunidade, mas não possui um
		72	+gerenciador de repositório de código-fonte integrado e para cada projeto há um
		73	+link para seu próprio repositório externo (ou seu arquivo tarball). OW2 é
		74	+uma espécie de consórcio de projetos de software livre para promover o
		75	+desenvolvimento de \textit{middleware} livres, aplicativos de negócios,
		76	+plataformas de computação em nuvem e promover um ecossistema de comunidade e
		77	+negócios. Em resumo, ele visa apoiar o desenvolvimento, implantação e
		78	+gerenciamento de soluções distribuídos com foco em middleware, não sendo uma
		79	+plataforma em si. Além disso, patrocinado pela \textit{European Commission}
		80	+entre 2007 e 20011, havia o projeto QualiPSo que visava fornecer aos usuários,
		81	+desenvolvedores e consumidores de software livre recursos e conhecimentos de
		82	+qualidade sobre os vários tópicos relacionados ao software livre. O projeto
		83	+QualiPSo também planejava desenvolver uma plataforma chamada QualiPSo Factory,
		84	+que não foi totalmente concluída.
38		85
39	-Na América Latina existe uma iniciativa baseada no projeto SPB chamado Software Publico Regional\footnote{\url{http://softwarepublicoregionalbeta.net}}. De um ponto de vista prático, ele fornece uma instância personalizada do Gitlab para compartilhar o código-fonte e a documentação dos projetos dos países envolvidos.
40	-%
41	-Tal como o Brasil, o Chile tem seu próprio portal também chamado Software Publico\footnote{\url{http://www.softwarepublico.gob.cl}}. Os usuários podem criar conteúdo nas comunidades (notícias, documentos, páginas wiki), mas os repositórios de código-fonte estão disponíveis na plataforma Bitbucket\footnote{\ url {https://bitbucket.org/softwarepublico}}.
42	-
43	-
44	-O governo brasileiro precisava evoluir o projeto SPB que existia desde 2005. Em 2013, quando iniciamos esse projeto, o Portal SPB contava com cerca de 200 mil usuários cadastrados. Não poderíamos apenas entrar em contato com esses usuários e pedir-lhes para registrar uma conta no Github também. Além disso, após o caso Edward Snowden, o governo brasileiro aprovou um decreto-lei específico (8.135/2013) para regulamentar seus serviços de comunicação, exigindo que a administração pública deva hospedar seus sistemas de informação a ser fornecido por si mesmo, o que exclui o uso de plataformas privadas, especialmente aqueles fornecidos por empresas estrangeiras. Assim, desenvolvemos nossa própria solução para cobrir todos os requisitos, produzindo uma completa e avançada plataforma integrada governamental para desenvolvimento de software colaborativo.	86	+Na América Latina existe uma iniciativa baseada no projeto SPB chamado Software
		87	+Publico Regional\footnote{\url{http://softwarepublicoregionalbeta.net}}. De um
		88	+ponto de vista prático, ele fornece uma instância personalizada do Gitlab para
		89	+compartilhar o código-fonte e a documentação dos projetos dos países
		90	+envolvidos. Tal como o Brasil, o Chile tem seu próprio portal também chamado
		91	+Software Publico\footnote{\url{http://www.softwarepublico.gob.cl}}. Os usuários
		92	+podem criar conteúdo nas comunidades (notícias, documentos, páginas wiki), mas
		93	+os repositórios de código-fonte estão disponíveis na plataforma
		94	+Bitbucket\footnote{\url{https://bitbucket.org/softwarepublico}}.
45		95
46		96
		97	+O governo brasileiro precisava evoluir o projeto SPB que existia desde 2005. Em
		98	+2013, quando iniciamos esse projeto, o Portal SPB contava com cerca de 200 mil
		99	+usuários cadastrados. Não poderíamos apenas entrar em contato com esses
		100	+usuários e pedir-lhes para registrar uma conta no Github também. Além disso,
		101	+após o caso Edward Snowden, o governo brasileiro aprovou um decreto-lei
		102	+específico (8.135/2013) para regulamentar seus serviços de comunicação,
		103	+exigindo que a administração pública deva hospedar seus sistemas de informação
		104	+a ser fornecido por si mesmo, o que exclui o uso de plataformas privadas,
		105	+especialmente aqueles fornecidos por empresas estrangeiras. Assim,
		106	+desenvolvemos nossa própria solução para cobrir todos os requisitos, produzindo
		107	+uma completa e avançada plataforma integrada governamental para desenvolvimento
		108	+de software colaborativo.
47		109
1	-\section{Architecture}	1	+\section{Arquitetura}
2	\label{sec:architecture}	2	\label{sec:architecture}
3		3
4	-Based on the extensive list of functional requirements defined by the
5	-Brazilian Federal Government, we selected some FOSS systems to form our
6	-solution. We looked for system that together could provide the largest
7	-subset possible of the requirements, and were fully aware that we would
8	-need to improve those systems in order to provide the rest. We were also
9	-convinced that it would be impossible to provide all of those
10	-requirements with a single tool.	4	+Com base na extensa lista de requisitos funcionais definidos pelo Governo
		5	+Federal do Brasil, selecionamos alguns sistemas livres compor a solução
		6	+proposta para o novo SPB. Avaliamos os sistemas que juntos poderiam fornecer o
		7	+maior subconjunto possível dos requisitos. Nós também estávmos convencidos de
		8	+que seria impossível fornecer todas as funcionalidade com uma única ferramenta.
11		9
12	-From the point of view of the architecture, two main requirements was
13	-brought by the Brazilian Federal Government for the new platform:	10	+Do ponto de vista da arquitetura, dois requisitos eram importantes para a nova
		11	+plataforma:
14		12
15	\begin{enumerate}	13	\begin{enumerate}
16	- \item \textit{Integrate existing FOSS systems}, with minimal differences from
17	- their original versions;
18	- \item \textit{Provide a consistent user interface} across the different
19	- systems, as well as centralized authentication.	14	+\item \textit{Integrar sistemas livres existentes}, com diferenças mínimas de suas versões originais;
		15	+\item \textit{Fornecer uma interface de usuário unificada} entre os diferentes sistemas, bem como a autenticação centralizada.
20	\end{enumerate}	16	\end{enumerate}
21		17
22	-Adopting existing FOSS systems and minimizing locally-made changes had
23	-the objective of being able to upgrade to newer versions of the original
24	-software, benefiting from improvements and maintenance done by the
25	-existing project communities. Providing a consistent user interface on
26	-top of those different tools was needed to make the transition between
27	-the different systems seamless from the point of view of users, which
28	-would be confused by jumping through completely different interfaces
29	-while interacting with the portal.
30	-
31	-For the first requirement, we identified four main systems that required
32	-specialized teams for work in the integration process. The teams learned
33	-how to develop for their assigned systems and contributed to the
34	-original communities, so that the version we used were not significantly
35	-different from the original.
36	-
37	-At the end of the project, the SPB portal was composed of more than ten
38	-systems, such as Colab, Noosfero, Mezuro, Gitlab, Mailman, Postfix, and
39	-Munin. The remainder of this section describes the most relevant of
40	-them, as well as how they were integrated into the platform.
41	-
42	-\subsection{Colab}
43	-
44	-Colab\footnote{\url{https://github.com/colab}} is a systems integration
45	-platform for web applications. One of its goals is allowing different
46	-applications to be combined in such a way that an user does not notice
47	-the change between applications. For that, Colab provides facilities
48	-for:	18	+A adoção de sistemas livres existentes e a minimização de mudanças feitas
		19	+localmente tiveram como objetivo ser capazes de atualizar para versões mais
		20	+recentes do software original, beneficiando de melhorias e manutenção feitas
		21	+pelas comunidades de projetos existentes. Proporcionar uma interface de usuário
		22	+consistente em cima dessas diferentes ferramentas era necessária para fazer a
		23	+transição entre os diferentes sistemas sem a percepção do ponto de vista dos
		24	+usuários, ou seja, sem confundi-lo através de interfaces completamente
		25	+diferentes ao interagir com o portal.
		26	+
		27	+Para o primeiro requisito, identificamos quatro sistemas principais que exigiam
		28	+equipes especializadas para o trabalho no processo de integração. As equipes
		29	+aprenderam a desenvolver para seus sistemas designados e contribuíram para as
		30	+comunidades originais, de modo que a versão que usamos não era
		31	+significativamente diferente do original.
		32	+
		33	+No final do projeto, o portal SPB foi composto por mais de dez sistemas, como
		34	+Colab, Noosfero, Mezuro, Gitlab, Mailman, Postfix e Munin. A seguir
		35	+apresentamos os mais relevantes deles, bem como como eles foram integrados na
		36	+plataforma.
49		37
50	\begin{itemize}	38	\begin{itemize}
51	- \item Centralized authentication
52	- \item Visual consistency
53	- \item Relaying of events between applications
54	- \item Integrated search engine
55	-\end{itemize}
56	-
57	-Colab implements this integration by working as a reverse proxy for the
58	-integration applications, that is, all external requests pass through
59	-Colab before reaching them.
60	-
61	-Centralized authentication is handled by letting users authenticate to
62	-Colab, which then sends a REMOTE\_USER HTTP header to applications,
63	-which are expected to be pre-configured to accept that as an indication
64	-of the current user (REMOTE\_USER is a standard authentication mechanism
65	-for web applications). This allows users to be automatically identified
66	-to each of the applications without having to enter credentials for each
67	-of them.
68	-%
69	-Of course, this requires that the integrated applications are not
70	-accessible on the public internet, otherwise malicious users could send
71	-their own crafted REMOTE\_USER headers and impersonate any user.
72	-
73	-For the visual consistency, Colab is able to make transformations to the
74	-HTML produced by the integrated applications, ir order to provide a
75	-unified interface. It allows one to define default templates to be used
76	-by all applications, as well as providing extra ones in a plugin. This
77	-approach allowed us to reuse common HTML pages, what facilitates
78	-maintenance.
79	-
80	-Colab also provides a publish-subscribe event system. This allows one of
81	-the applications, or Colab itself, to trigger an action in another
82	-application. For example, when a user registers with Colab, all
83	-applications need to be notified in order to create their own internal
84	-representation of that user account.
85	-
86	-Colab also provides an integrated search engine, which can be configured
87	-to specify exactly what data needs to be indexed for each of the
88	-applications, and how to direct the user to that piece of information on
89	-the specific application.
90	-
91	-Initially, Colab had support for a small set of applications (Trac, GNU
92	-Mailman, and Apache Lucene) and support for them was hard-coded. Our
93	-team evolved Colab so that it can now receive plugins that add support
94	-new applications without the need of changes to the Colab core. We also
95	-developed plugins to be used in the SPB platform: Noosfero, GitLab, and
96	-Mezuro.
97		39
98	-\subsection{Noosfero}	40	+\item \textbf{Colab\footnote{\url{https://github.com/colab}}:} é uma plataforma
		41	+de integração de sistemas para aplicações web. Um de seus objetivos é permitir
		42	+que diferentes aplicações sejam combinadas de tal forma que um usuário não note
		43	+a mudança entre as aplicações. Para isso, a Colab oferece autenticação
		44	+centralizada, consistência visual, retransmissão de eventos entre aplicações e
		45	+mecanismo de pesquisa integrado.
		46	+
		47	+\item \textbf{Noosfero\footnote{\url{http://noosfero.org}}:} é um software para
		48	+redes sociais e de colaboração. Além dos recursos clássicos de redes sociais,
		49	+ele também fornece recursos de publicação de conteúdo, como blogs e um CMS
		50	+(\textit{Content Management System}) de propósito geral. A maioria das
		51	+interações do usuário com o SPB é através do Noosfero: registro do usuário,
		52	+páginas do projeto e de documentação e formulários de contato.
		53	+
		54	+\item \textbf{Gitlab\footnote{\url{http://gitlab.com}}:} é um gerenciador web
		55	+de repositório Git com páginas wiki e recursos de \textit{issue tracker}. O
		56	+Gitlab é uma plataforma livre e se concentra em oferecer uma solução holística
		57	+de desenvolvimento colaborativo em torno do repositório em uma única
		58	+plataforma.
		59	+
		60	+\item \textbf{Mezuro\footnote{\url{http://mezuro.org/}}:} é uma plataforma para
		61	+coletar métricas de código-fonte com o objetivo de monitorar a qualidade
		62	+interna de projetos de software livre escrito em C, C ++, Java, Python, Ruby ou
		63	+PHP.
99		64
100	-Noosfero\footnote{\url{http://noosfero.org}} is a software for building
101	-social and collaboration networks. Besides the classical social
102	-networking features, it also provides publication features such as blogs
103	-and a general-purpose CMS (Content Management System). Most of the user
104	-interactions with SPB is through Noosfero: user registration, project
105	-home pages and documentation, and contact forms.
106	-
107	-\subsection{Gitlab}
108	-
109	-GitLab\footnote{\url{http://gitlab.com}} is a web-based Git repository
110	-manager with wiki pages and issue tracking features. Gitlab is a FOSS
111	-platform and focuses on delivering a holistic solution that will see
112	-developers from idea to production seamlessly and on a single platform.
113	-
114	-Gitlab has several unique features, such as built-in continuous
115	-integration and continuous deployment, flexible permissions, tracking of
116	-Work-in-Progress work, moving issues between projects, group-level
117	-milestones, creating new branches from issues, issues board, and time
118	-tracking.
119	-
120	-\subsection{Mezuro}
121	-
122	-Mezuro\footnote{\url{http://mezuro.org/}} is a platform to collect source code
123	-metrics to monitor the internal quality of software written in C, C++,
124	-Java, Python, Ruby, and PHP.
125	-
126	-In general, source code metrics tools also do not present a friendly way
127	-to interpret its results and, even more, do not follow a standardization
128	-between them. Mezuro collects and presents these results to the end
129	-user, specially, by analyzing source code metric history during its life
130	-cycle.
131	-
132	-The Mezuro platform provides a single interface grouping available
133	-tools, allows selection and composition of metrics in a flexible manner,
134	-stores the metrics evolution history, presents results in a friendly
135	-way, as well as, allows users to customize the given interpretation
136	-accordingly to their own context.
137	-
138	-\subsection{System unification}	65	+\end{itemize}
139		66
140	\begin{figure}[hbt]	67	\begin{figure}[hbt]
141	\centering	68	\centering
142	\includegraphics[width=.5\linewidth]{figures/arch.png}	69	\includegraphics[width=.5\linewidth]{figures/arch.png}
143	- \caption{SPB architecture overview.}	70	+ \caption{Visão geral da arquitetura do novo portal SPB.}
144	\label{fig:architecture}	71	\label{fig:architecture}
145	\end{figure}	72	\end{figure}
146		73
147	-The conceptual architecture of the platform is presented in Figure
148	-\ref{fig:architecture}. Colab initially handles all user interaction,
149	-directing requests to one of the integrated applications. It
150	-post-processes responses from the applications to apply a consistent
151	-visual appearance, manages authentication, and provides a unified search
152	-functionality: instead of using the redundant restricted search
153	-functionality of each application, a search in the SPB portal might
154	-return content from any of the applications, be it web pages, mailing
155	-list posts, or source code.
156	-%
157	-The SPB platform was deployed in 7 virtual machines with different functions.	74	+Do ponto de vista prático, a plataforma SPB foi implantada em 7 máquinas
		75	+virtuais com diferentes
		76	+funções\footnote{\url{https://softwarepublico.gov.br/doc/arquitetura.html}}. A
		77	+arquitetura conceitual da plataforma é apresentada na Figura
		78	+\ref{fig:architecture}. O Colab inicialmente lida com toda a interação do
		79	+usuário, redirecionando as solicitações para as ferramentas integradas. Ele
		80	+processa as respostas das ferramentas e aplica uma aparência visual
		81	+consistente, gerenciando também a autenticação e fornecendo uma busca
		82	+unificada: em vez de usar a funcionalidade de busca restrita redundante de cada
		83	+ferramenta, uma busca no portal SPB pode retornar conteúdo de qualquer uma
		84	+delas, sejam páginas web, postagens da lista de discussão ou mesmo
		85	+código-fonte.
		86	+
1	-\section{Features}	1	+\section{Funcionalidades}
2	\label{sec:spb}	2	\label{sec:spb}
3		3
4	-The new generation of the SPB portal combines features adapted from existing collaborative software
5	-and features developed by the SPB team. Whenever possible, new functions
6	-(newly developed or partially modified) were contributed back to the official repositories.	4	+A nova geração do portal SPB combina recursos adaptados de plataformas
		5	+colaborativas existentes com recursos desenvolvidos pelas equipes da UnB e USP.
		6	+Sempre que possível, novas funcionalidades recém-desenvolvidas ou parcialmente
		7	+modificadas) foram enviadas de volta aos repositórios oficiais.
7		8
8	-As a result, we have a platform that integrates and harmonizes different features such as
9	-social networking, mailing list, version control system, content management and
10	-source code quality monitoring. Our aim was to develop functionalities by reusing
11	-functionality of collaborative software already integrated to the platform. In
12	-addition, we tried to keep this integration transparent to end users.	9	+Como resultado, temos uma plataforma que integra e harmoniza diferentes
		10	+recursos, como redes sociais, lista de email, sistema de controle de versão,
		11	+gerenciamento de conteúdo e monitoramento de qualidade de código-fonte. Nosso
		12	+objetivo foi desenvolver funcionalidades reutilizando as ferramentas integradas
		13	+à plataforma. Além disso, tentamos manter essa integração transparente para os
		14	+usuários finais. Temos 3 grandes conjuntos de funcionalidades descritas nas
		15	+próximas subseções.
13		16
14	-\subsection{Software and Software Community}	17	+\subsection{Software e Comunidade de Software}
15		18
16	-In the new SPB portal, each software has a standard set of pages and tools.
17	-Besides accessing support pages (such as FAQ and installation guide) within the platform, users will be able to download
18	-different versions of the software and find several mechanisms of software development management.	19	+No novo portal SPB, cada software tem um conjunto padrão de páginas e
		20	+ferramentas. Além de acessar as páginas de suporte (como FAQ e guia de
		21	+instalação) dentro da plataforma, os usuários são capazes de baixar diferentes
		22	+versões do software e encontrar vários mecanismos de gerenciamento de
		23	+desenvolvimento de software.
19		24
20	-Focusing on the collaborative development, Mailman was integrated to the platform in order to allow
21	-the dialogue and communication between developers, users and
22	-enthusiasts of a determined software. The software has its own mailing list whose privacy
23	-can be configured/set by administrators.	25	+Focando no desenvolvimento colaborativo, Mailman foi integrado à plataforma
		26	+para permitir o diálogo e a comunicação entre desenvolvedores, usuários e
		27	+entusiastas de um determinado software. O software tem sua própria lista de
		28	+discussão cuja privacidade pode ser configurada e definida pelos
		29	+administradores.
24		30
25	-The software has a social interface area ("software community") where users can find other users, blogs,
26	-summary of recent activities, or any other relevant community-produced content.
27	-Users logged to the platform can request membership to different software communities
28	-and each community member can access and edit restricted content. For this purpose,
29	-many Noosfero features related to social networking and content management were integrated to the portal.	31	+O software possui uma área de interface social (``comunidade de software'')
		32	+onde os usuários podem encontrar outros usuários, blogs, resumo de atividades
		33	+recentes ou qualquer outro conteúdo relevante produzido pela comunidade. Os
		34	+usuários registrados na plataforma podem solicitar a associação a comunidades
		35	+de software diferentes e cada membro da comunidade pode acessar e editar
		36	+conteúdo restrito. Para isso, muitos recursos do Noosfero relacionados a redes
		37	+sociais e gerenciamento de conteúdo foram integrados ao portal.
30		38
31	-To assist decision-making, the new SPB has acquired assessment and statistical
32	-tools. Now, users will be able to rate the software and make comments and all
33	-information will be avaiable to other users. Moreover, the software has a section
34	-containing its statistical data, where values are calculated based on data
35	-provided by users and the system.	39	+Para auxiliar na tomada de decisões, o novo SPB adquiriu ferramentas de
		40	+avaliação e estatísticas. Agora, os usuários serão capazes de avaliar o
		41	+software e fazer comentários e todas as informações serão avaiable para outros
		42	+usuários. Além disso, o software possui uma seção contendo seus dados
		43	+estatísticos, onde os valores são calculados com base nos dados fornecidos
		44	+pelos usuários e pelo sistema.
36		45
37	-The role of the administrator will be present in the software and in its community. The
38	-administrator is responsible for moderating content, memberships and user
39	-comments. The administrator is also the one who can make changes in the software homepage
40	-content.	46	+O papel do administrador estará presente no software e na sua comunidade. O
		47	+administrador é responsável por moderar o conteúdo, as associações e os
		48	+comentários dos usuários. O administrador também é aquele que pode fazer
		49	+alterações no conteúdo da página inicial do software.
41		50
42	-\subsection{Software Catalog and global search}	51	+\subsection{Catálogo de Software e Busca Global}
43		52
44	-The platform also provides a search tool called Software Catalog,
45	-which allows users to find softwares available in the portal.
46	-In this catalog, some search options were developed to make the navigation easier,
47	-such as filters (by type of software or category), sorting and score.	53	+A plataforma também fornece uma ferramenta de pesquisa chamada ``Catálogo de
		54	+Software'', que permite aos usuários encontrar softwares disponíveis no portal.
		55	+Neste catálogo, algumas opções de busca foram desenvolvidas para facilitar a
		56	+navegação, como filtros (por tipo de software ou categoria), classificação e
		57	+pontuação.
48		58
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
51	-provided by the different collaborative software used in the SPB protal. Any user can
52	-find a public content in the context of social networking, mailing list and
53	-software development.	59	+Para expandir o escopo de busca e cobrir mais tipos de conteúdos, as equipes da
		60	+UnB e USP desenvolveram um mecanismo de busca global. Essa funcionalidade
		61	+unifica os mecanismos de busca fornecidos pelas diferentes ferramentas
		62	+integradas ao portal do SPB. Qualquer usuário pode encontrar um conteúdo
		63	+público no contexto de redes sociais, lista de discussão e desenvolvimento de
		64	+software.
54		65
55	-\subsection{Software development tools}	66	+\subsection{Ambiente de apoio ao desenvolvimento de software}
56		67
57	-The new SPB also provides
58	-tools to encourage developers to keep source code and its
59	-development activity within the platform. Any created software has, by default, a
60	-an associated git repository with wiki pages and issue tracking. These tools are
61	-supplied by the integration of Gitlab into the platform.	68	+O novo SPB também fornece ferramentas para incentivar os desenvolvedores a
		69	+manter o código-fonte e sua atividade de desenvolvimento dentro da plataforma.
		70	+Qualquer software criado tem, por padrão, um repositório Git associado com
		71	+páginas wiki e \textit{issue tracker}. Essas ferramentas são fornecidas pela
		72	+integração do Gitlab na plataforma.
62		73
63	-Developers can also evaluate the software source code to measure software
64	-quality. With Mezuro, they can schedule the analysis of the source-code and follow its
65	-metric results evolution over time. Results of each metric analysis are
66	-public, which allows greater transparency between the developer and the
67	-community that uses the software. Thereby, the maintainers can decide if the
68	-given solution meets the source code quality requirements.	74	+Os desenvolvedores também podem avaliar o código-fonte do software para medir a
		75	+qualidade interna do software. Com o Mezuro, eles podem configurar a análise do
		76	+código-fonte e monitorar sua evolução pelos resultados métricas ao longo do
		77	+tempo. Os resultados de cada análise métrica são públicos, o que permite maior
		78	+transparência entre o desenvolvedor e a comunidade que usa o software. Desta
		79	+forma, os mantenedores podem decidir se uma determinada solução atende aos
		80	+requisitos de qualidade interna do código-fonte.
69		81
70	-Thus, the SPB became a platform to stimulate the openness of the source code;
71	-dialogue between users and the development team; and also
72	-maintenance and evolution of the software, which will provide more
73	-transparency in government investments.	82	+Assim, o SPB tornou-se uma plataforma para estimular a abertura do código
		83	+fonte; o diálogo entre os usuários e a equipe de desenvolvimento; e também a
		84	+manutenção e evolução do software, o que proporcionará maior transparência nos
		85	+investimentos do governo.
1	-\section{User eXperience evolution}	1	+\section{Evolução da experiência do usuário}
2		2
3	-The integration of collaborative environments goes beyond functional aspects.
4	-Offering the population an unified experience across these environments has
5	-been the key to encourage the use of the platform as it reduces the perception
6	-of complexity. Thus, the SPB Portal information architecture was redesigned
7	-to provide a transparent navigation and to reach users with different profiles.
8	-A process of harmonization has been employed on the interaction models of each
9	-tool to reduce the learning curve. At the same time, a new visual style was
10	-created to unify the navigation experience and to comply with the guidelines of
11	-the digital communication identity standard established by the Federal
12	-Government.	3	+A integração de ambientes colaborativos vai além dos aspectos funcionais.
		4	+Oferecer à população uma experiência unificada em todos esses ambientes tem
		5	+sido a chave para incentivar o uso da plataforma, pois reduz a percepção de
		6	+complexidade. Assim, a arquitetura de informação do no portal SPB foi
		7	+re-desenhada para fornecer uma navegação transparente e alcançar usuários com
		8	+perfis diferentes. Um processo de harmonização foi empregado nos modelos de
		9	+interação de cada ferramenta para reduzir a curva de aprendizado. Ao mesmo
		10	+tempo, foi criado um novo estilo visual para unificar a experiência de
		11	+navegação e cumprir as diretrizes do padrão de identidade de comunicação
		12	+digital estabelecido pelo Governo Federal.
13		13
14	-With the increase in system features and the addition of new tools, the
15	-visual style has steadily evolved to keep the navigation unified. Moreover,
16	-tools from different backgrounds, which in many cases provide similar
17	-functionality, prompted the development of an unified interface. Some
18	-features, such as search and user profile editing were eliminated from
19	-the individual applications, and implemented centrally to ensure a
20	-consistent look and feel.	14	+Com o aumento dos recursos do sistema e a adição de novas ferramentas, o estilo
		15	+visual foi evoluído para manter a navegação unificada. Além disso, ferramentas
		16	+de origens diferentes, que em muitos casos fornecem funcionalidades
		17	+semelhantes, nos levou ao desenvolvimento de uma interface unificada. Alguns
		18	+recursos, como a busca e a edição de perfil de usuário, foram eliminados dos
		19	+aplicativos individuais e implementados centralmente para garantir uma
		20	+aparência consistente.
21		21
22	-Another challenge was responsive web design. The integrated applications
23	-had varying degrees of support for responsiveness, and the common
24	-interface had to adapt for each individual scenario. In particular
25	-Noosfero did not yet have a responsive design; we engaged in its
26	-development and contributed towards that goal.	22	+Outro desafio foi o \textit{design web} responsivo. As aplicações integradas
		23	+tinham diferentes graus de suporte para resposividade e a interface comum
		24	+precisava se adaptar para cada cenário individual. Em particular, o Noosfero
		25	+ainda não tinha recursos de responsividade. Nós nos engajamos em seu
		26	+desenvolvimento e contribuímos para esse funcionalidade, contribuindo também
		27	+com sua comunidade de desenvolvedores.
27		28
28	-After the initial release of the new SPB Portal in 2014, several
29	-validations activities were implemented in 2015 and 2016. The aim was to
30	-provide the most wanted features by casual users (such as public
31	-servants interested in downloads and documentation) immediately, while
32	-allowing more experienced users (such as developers) to easily drill down
33	-to the details.	29	+Após o lançamento inicial do novo Portal SPB em 2014, foram implementadas
		30	+várias atividades de validação com os usuários em 2015 e 2016. O objetivo era
		31	+disponibilizar imediatamente os recursos mais procurados tanto pelos usuários
		32	+mais recorrentes (como servidores públicos interessados em
		33	+downloads e documentação), quanto pelos usuários mais técnicos (como
		34	+desenvolvedores interessados em acessar o código-fonte dos projetos).
	@@ -1,51 +0,0 @@	@@ -1,51 +0,0 @@
1	-\section{Contributions to the upstream communities}
2	-\label{sec:contributions}
3	-
4	-%- projeto feito do jeito certo com relação ao software livre (contribuições upstream etc)
5	-%* Colab -> RevProxy
6	-%* Colab, atualização do python/django
7	-%* Contribuições para o GitLab (autenticação)
8	-%* Noosfero, atualização do Rails, preparação para federação, nova interface ...
9	-%* Coper, empacotamentos (obs), omniauth
10	-
11	-
12	-During the execution of this project we made several contributions to
13	-the upstream communities we interacted with. This occurred due to our
14	-development process aligned with those of the respective communities.
15	-During development, we would explicitly discuss the features and bug
16	-fixes that we were working on with the applicable upstream communities.
17	-This contributed to improve the developers technical solutions with
18	-expertise outside of our team, and make it easier for those changes to
19	-be accepted in the original projects. Having changes accepted upstream
20	-in turn makes our life easier as it minimizes the delta between our
21	-codebase and upstream's allowing us to upgrade and benefit from
22	-development work from others.
23	-
24	-In Colab, we helped upstream redesign the entirely architecture,
25	-enabling the development of plugins to integrate new tools. We also
26	-added a feature that allowed Colab to run asynchronous tasks, which was
27	-a major improvement for us since we were developing a complex system. A
28	-migration to the latest Django version was made (web framework used by
29	-Colab). Moreover, we worked on RevProxy (the more important dependency
30	-of Colab) to put it in a good shape, fixing many bugs.
31	-
32	-Gitlab was the tool that we made the least number of modifications. We
33	-contributed with some improvements related with configuration files and
34	-we developed a new plugin that enables user authentication in Gitlab
35	-through the REMOTE\_USER HTTP header. This plugin was needed because
36	-Colab uses this mechanism to manage the authentication.
37	-
38	-Noosfero was the tool that contemplated several functional requirements,
39	-therefore we made a large number of contributions with upstream. We helped to
40	-migrate to the latest Rails version (web framework used by Noosfero), enable
41	-the federation implementation (federation with other social networks), decouple
42	-the interface and the back-end, and so forth.
43	-
44	-We also made some contributions on the DevOps front. Some members of
45	-them team became maintainers of some python libraries that were used by
46	-our scripts to upload packages to OBS (Open Build Service). We developed
47	-a tool called copr-status to keep track of the different stages of the
48	-lifecycle of each of the individual packages we were working on.
49	-
50	-%TODO: Mezuro
51	-
1	-\section{Lessons Learned}	1	+\section{Conclusões e Lições Aprendidas}
2	\label{sec:lessons}	2	\label{sec:lessons}
3		3
4	-\textbf{How to involve students real-world projects, interacting with
5	-real customers.}	4	+\textbf{Envolver alunos de graduação em projetos do mundo real, interagindo com clientes reais.}
6	%	5	%
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
10	-managers from the Brazilian Government, and the management team from
11	-UnB.	6	+Nossa equipe foi composta principalmente de estudantes de graduação em
		7	+engenharia de software, que tiveram a oportunidade de interagir com
		8	+desenvolvedores sênior e designers dentro da equipe, bem como com a equipe de
		9	+técnicos e gerentes do governo brasileiro.
12	%	10	%
13	-They interacted with professionals that had diverse expertises, and were
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
16	-them this was their first professional experience.	11	+Eles interagiram com profissionais que possuíam diversos conhecimentos e foram
		12	+capazes de participar em todos os níveis do processo de desenvolvimento de
		13	+software. Isto contribuiu para uma grande oportunidade de aprendizagem, e para
		14	+a maioria deles esta foi a sua primeira experiência profissional.
17		15
18	-\textbf{The participation of experienced professionals is crucial to
19	-success of the project.}
20	-One important factor for the students was the composition of the teams
21	-with the participation of experienced professionals.	16	+\textbf{A participação de profissionais experientes é crucial para o sucesso do projeto.}
22	%	17	%
23	-On the technical side, the senior developers and designers would handle
24	-the more difficult technical decisions, creating a work environment
25	-where the students could develop their skills in a didactic way without
26	-pressure.	18	+Um fator importante para os alunos foi a composição das equipes com a
		19	+participação de profissionais experientes. No lado técnico, os desenvolvedores
		20	+sênior e designers lidavam com as decisões técnicas mais difíceis, criando
		21	+um ambiente de trabalho onde os alunos poderiam desenvolver suas habilidades de
		22	+forma didática e sem pressão. No lado gerencial, a participação ativa dos
		23	+professores - que são, no final, os responsáveis pelo projeto - é
		24	+crucial para garantir que a participação dos alunos seja conduzida de forma
		25	+saudável e seja um exemplo de liderar pelo exemplo.
		26	+
		27	+\textbf{Uma relação equilibrada entre academia e indústria.}
27	%	28	%
28	-On the management side, the active participation of professors -- who
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
31	-instance of leading by example.
32	-
33	-\textbf{A balanced relationship between academia and industry.}
34	-The experience of the SPB project led UnB to develop a work style which
35	-proved to be appropriate for an educational environment that brings
36	-academia and industry together.
37	-%
38	-The highest priority from the university's point of view is the
39	-students. Considering this, the activities of the project were never
40	-prioritized to the detriment of classes and other pedagogical
41	-activities. In summary, we had students working at different times, part
42	-time, remotely or locally, always respecting their individual
43	-conditions, but doing the work in a collective, collaborative and open
44	-way.
45	-%
46	-And even under a potentially adverse environment, the project delivered
47	-the desired solution with success.	29	+A experiência do projeto SPB levou o LAPPIS/UnB a desenvolver um estilo de trabalho que
		30	+provou ser apropriado para um ambiente educacional que reúne academia e
		31	+indústria. A maior prioridade do ponto de vista da universidade são os alunos.
		32	+Diante disso, as atividades do projeto nunca foram priorizadas em detrimento
		33	+das aulas e outras atividades pedagógicas. Em resumo, tínhamos alunos
		34	+trabalhando em horários diferentes, a tempo parcial, localmente,
		35	+sempre respeitando suas condições individuais, mas fazendo o trabalho de
		36	+maneira coletiva, colaborativa e aberta. E mesmo sob um ambiente potencialmente
		37	+adverso, o projeto entregou a solução desejada com sucesso.
48	%	38	%
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.
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.
55	-
56	-\textbf{Managing different organizational cultures.}
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.	39	+No final do projeto, notamos que as habilidades desenvolvidas pelos alunos
		40	+estavam no estado da arte da prática de engenharia de software. Depois que o
		41	+projeto terminou, tivemos membros da equipe que abraçaram com sucesso
		42	+oportunidades em organizações públicas, privadas, nacionais e internacionais,
		43	+além dos estudantes que entraram no empreendedorismo e abriram suas próprias
		44	+empresas. No início do projeto, as partes interessadas do governo brasileiro
		45	+tinham certas expectativas sobre o desenvolvimento de projetos que, digamos,
		46	+não correspondiam exatamente ao nosso trabalho baseado em práticas ágeis e de
		47	+software livre. Tivemos que desenvolver estratégias que apoiassem diferentes
		48	+culturas organizacionais. Conforme relatado na seção\ref{sec:process}, o Ministério do Planejamento é
		49	+organizado em uma estrutura organizacional hierárquica funcional, tipicamente,
		50	+um paradigma de desenvolvimento tradicional. Portanto, tivemos que criar um
		51	+processo de ``tradução'' entre nossa equipe e os analistas do MP que gerenciaram o
		52	+projeto do lado deles.
		53	+
		54	+\textbf{Gerenciar separadamente os objetivos de nível estratégico e de nível operacional.}
60	%	55	%
61	-We had to develop strategies that would support different these
62	-organizational cultures. As reported in Section \ref{sec:process}, the
63	-MP is organized in a functional hierarchical organizational structure,
64	-typically, a traditional development paradigm. Therefore, we had to
65	-create a translation process between our team and the MP managers who
66	-managed the project on their side assuming a traditional, waterfall
67	-process.
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.	56	+Durante a fase inicial do projeto, a equipe de MP costumava trazer discussões
		57	+estratégicas para reuniões técnicas/operacionais, onde deveríamos discutir
		58	+decisões práticas e técnicas.
73	%	59	%
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
79	-discussions caused confusion on both sides.	60	+Isso resultou em um ambiente de comunicação e gerenciamento altamente complexo,
		61	+sobrecarregando os professores, uma vez eles eram responsáveis por
		62	+manter o alinhamento estratégico do MP sincronizado com os planejamentos de
		63	+implementação da equipe de desenvolvimento, especialmente à luz do
		64	+desmembramento cultural acima mencionado. A mistura de ambas as preocupações
		65	+nas mesmas discussões causava confusão em ambos os lados. Para o meio e fim do
		66	+projeto, conseguimos manter essas preocupações separadas, o que facilitou o
		67	+trabalho de todos os envolvidos.
		68	+
		69	+\textbf{Não aceitar más decisões técnicas por questões políticas.}
80	%	70	%
81	-Towards the middle and end of the project we were able to keep those
82	-concerns separated, what eased the work of everyone involved.
83	-
84	-\textbf{Living with ill-advised political decisions.}
85	-At the initial phases of the project, by political and personal
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
88	-team was totally against the idea because we already knew that Colab was
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
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
96	-all the resources that would be spent due to that decision. At the end
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
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.
102	-
103	-\textbf{Consider sustainability from the beginning.}
104	-In the process of deploying the SPB platform in the MP structure, we had
105	-to interact with the MP technicians. We did several workshops, training
106	-and a meticulous documentation describing all the required procedures to
107	-update the platform, however, we realized that the MP technicians
108	-constantly avoid the responsibility. After noticing the aforementioned
109	-situation, we organized a specific DevOps that completely automated all
110	-the deployment procedure. We simplified all the platform deployment to a
111	-few steps: (1) initial configurations (just ssh configuration) and (2)
112	-the execution of simple commands to completely update the platform. By
113	-the end of the project, we observed that the MP technicians invariably
114	-still depended on our support to update the platform even with all the
115	-automation provided by us. We were sadly left with a feeling of
116	-uncertainty about the future of the platform after the project ended. In
117	-hindsight, we realize that the MP dedicated systems analysts and
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.
121	-
122	-% * Gestão dos recursos: Fizemos mais por menos (2.6M de 3.2M) --- sem os dados
123	-%% (escopo, custo, tempo e qualidade) bem discutidos é difícil sustentar essa
124	-%% afirmação, embora eu e Paulo consigamos perceber isso.
125	-
126	-%===========
127	-% Conclusion
128	-%===========
129	-
130	-\section{Final remarks}
131	-
132	-The portal is available at \url{softwarepublico.gov.br}. All
133	-documentation, including detailed architecture and operation manuals are
134	-also available\footnote{\url{https://softwarepublico.gov.br/doc/}
135	-(in Portuguese only at the moment)}).	71	+Nas fases iniciais do projeto, por motivação política e pessoal, os principais
		72	+atores do governo brasileiro, envolvidos na época, impuseram o uso da Colab
		73	+para orientar o desenvolvimento da nova plataforma SPB. Nossa equipe estava
		74	+totalmente contra a essa ideia, porque já sabíamos que o Colab era um projeto
		75	+muito experimental e sua adoção poderia aumentar dramaticamente a complexidade
		76	+do projeto. Mesmo nós fornecendo as razões técnicas para não utilizar Colab, MP
		77	+foi inflexível e tivemos de gerir este problema. Fizemos mudanças maciças e, no
		78	+final do projeto, reescrevemos completamente o Colab e o tornamos estável (o
		79	+transformando em um Sistema de Sistema em camada de aplicação). É importante
		80	+notar que o MP nos obrigou a aceitar uma questão técnica baseada apenas em
		81	+interesses políticos, sem considerar todos os recursos que seriam gastos devido
		82	+a essa decisão. No final do projeto, verificamos que a Colab de fato consumiu a
		83	+maior quantidade do orçamento e aumentou a complexidade do projeto.
		84	+
		85	+\textbf{Considerar a sustentabilidade desde o início.}
136	%	86	%
137	-All the integrated tools are FOSS and our contributions were published
138	-in open repositories, available on the SPB Portal itself. We also
139	-contributed these features back to the respective communities: that
140	-benefits those communities, as well as us since we can share future
141	-development and maintenance effort with other organizations that
142	-participate in their projects.
143	-
144	-More discussion ...
145	-
146	-...
147	-
148	-...
149	-
150	-%* utilização do projeto para formação de recursos humanos (alunos)
151	-
152	-%* dados da verificação dos repositório para a análise da qualidade dos código via Mezuro e CodeClimate
153	-
154	-%* o que achamos que irá acontecer com o SPB no futuro breve (acabar)
155	-
156	-%* 69 projetos marcados como SPB, de 81 no total na plataforma.
157	-
158	-%* 47\% é desenvolvido em PHP.
159	-
160	-% foi constatado que aproximadamente 75\% dos softwares \textbf{não} possuem seus códigos-fonte versionados nesta ferramenta. Realizado algumas pesquisas, foi encontrado o código-fonte em outros serviços (Github, Bitbucket).
161	-
162	-% Foram adicionados 31 softwares do SPB em ambas as ferramentas (Mezuro e Code Climate), desenvolvidos em PHP e Python. Estas adições resultaram na análise descrita nos próximos parágrafos. No Mezuro, dos 31 softwares adicionados, somente 4 obtiveram sucesso na avaliação. No Code Climate, 16 softwares realizaram a \textit{build} da avaliação com sucesso. Nos que falharam, alguns dos erros foram encontrados em três das \textit{engines}: ora em \textit{duplication}, ora na \textit{phpmd}, ora na \textit{eslint}.
163	-
164	-% também foram inseridos no Mezuro para avaliação, 5 projetos dos 17 desenvolvidos em Java, com o intuito de ser um contraponto ao Code Climatepor esta não compreender a análise de projetos em Java, C, ou C++. Infelizmente nenhuma das \textit{builds} resultou em resultados concretos.
165	-
166	-%* Debater economia de recursos em orgão públicos	87	+No processo de implantação da plataforma SPB na estrutura MP, tivemos que
		88	+interagir com os técnicos MP. Fizemos vários workshops, treinamento e uma
		89	+documentação meticulosa descrevendo todos os procedimentos necessários para
		90	+atualizar a plataforma, no entanto, percebemos que os técnicos MP
		91	+constantemente evitavam essa responsabilidade. Depois de notar essa situação,
		92	+nós organizamos uma equipe de DevOps específica que automatizou completamente
		93	+todo o procedimento de implantação. Nós simplificamos toda a implantação da
		94	+plataforma para algumas etapas: (1) configurações iniciais (apenas configuração
		95	+SSH) e (2) a execução de comandos simples para atualizar completamente a
		96	+plataforma. Ao final do projeto, observamos que os técnicos MP sempre dependiam
		97	+do nosso apoio para atualizar a plataforma, mesmo com toda a automação
		98	+fornecida por nós. Ficamos tristemente com um sentimento de incerteza sobre o
		99	+futuro da plataforma após o término do projeto. Em retrospectiva, percebemos
		100	+que o MP dedicou analistas de sistemas e gerentes para o projeto, mas não
		101	+técnicos de operações e desenvolvedores, que deveria ter sido envolvido com o
		102	+processo para que pudesse, pelo menos, de forma confortável fazer o manutenção
		103	+da infra-estrutura plataforma.
		104	+
		105	+Por fim, o novo portal do Software Público Brasileiro está disponível em
		106	+\url{https://softwarepublico.gov.br}. Toda a documentação, incluindo a
		107	+arquitetura detalhada e os manuais de operação, também estão disponíveis em
		108	+\url{https://softwarepublico.gov.br/doc}. Todas as ferramentas integradas são
		109	+software livre e nossas contribuições foram publicadas em repositórios abertos,
		110	+disponíveis no próprio portal SPB. Também contribuímos com funcionalidades e
		111	+melhorias para as respectivas comunidades dos projetos integrados: que
		112	+beneficiam essas comunidades, assim como nós, pois podemos compartilhar o
		113	+desenvolvimento futuro e o esforço de manutenção com outras organizações que
		114	+participam de seus projetos.
167		115