re-organizing files and adding the introduction

Paulo Meireles
1 parent 18b9fba0
Showing 6 changed files with 160 additions and 174 deletions Show diff stats
OSS-2017/00-abstract.tex
OSS-2017/01-introduction.tex
OSS-2017/02-platform.tex
OSS-2017/03-architecture.tex
OSS-2017/04-finals.tex
OSS-2017/spb.tex
@@ -0,0 +1,6 @@
+\begin{abstract}
+  % Contexto
+  % Problema
+  % Soluções propostas
+  % Frase de impacto
+\end{abstract}
@@ -0,0 +1,8 @@
+\section{Introduction}
+\label{sec:intro}
+
+Since last few decades, the Brazilian Federal Government has been improving its software adoption and development processes. In 2003, the recommendation to adopt free software become a public policy. In this context, in 2007, the Brazilian Ministry of Planning, Budget, and Management had released a Portal to share projects like free software called Brazilian Public Software (\textit{Software Público Brasileiro} -- SPB). In short, a website to share softwares developed by and for the Brazilian Government.
+
+On the one hand, the Brazilian legal instrument (IN 04/2012) on software contracting indicates that the public managers must consult the SPB Portal to adopt a software solution, as well as, justifying the acquisition of proprietary softwares if there is no a similar project available in the SPB Portal. On the other hand, since 2009, the SPB Portal had several technical problems because there was no development activities to maintenance and evolute it. Thus, the initial SPB Portal version did not have another release.
+
+During 2014 and 2016, a platform for the Brazilian Public Software project was designed and developed by the University of Brasília and the University of São Paulo. This new Portal was designed to be an integrated platform of collaborative software development environments with social networking, mailing list, control version system, and source code quality monitoring. In this paper, we present this new generation of the SPB Portal.
@@ -0,0 +1,70 @@
+\section{Platform for collaborative software development}
+
+%TODO: Paulo e Melissa
+O conceito de software público se diferencia do de software livre em alguns
+aspectos, destacando-se a atribuição de bem público ao software. Isso significa
+que o Governo, especificamente o MP, assume algumas responsabilidades que
+garantem ao usuário do software, em especial os órgãos públicos, condições
+adequadas de uso. Embora haja diferenças entre o que é um software livre e um
+software público brasileiro, há princípios comuns como a tendência da
+descentralização na tomada de decisões, do compartilhamento de informações e da
+retroalimentação. Por isso, a nova plataforma para o SPB foi pensada para
+contemplar ferramentas que promovam a colaboração e a interação nas comunidades
+(por gestores, usuários e desenvolvedores) dos projetos, conforme as práticas
+usadas nas comunidades de software livre. Isso inclui listas de e-mail, fóruns
+de discussão, issue trackers, sistemas de controle de versão e ambientes de
+rede social.
+
+Para integrar as ferramentas e prover a autenticação única nos serviços da
+plataforma, um sistema web chamado Colab, que funcionada como proxy reverso
+para os ambientes, está sendo evoluído. Em resumo, o Colab oferece a integração
+de busca, autenticação e apresentação, provendo um único ambiente ao usuário
+que tem em seu perfil algumas métricas de contribuições (e-mails para listas,
+inserções em wikis, cadastros de issue e commits nos repositórios).
+
+O Colab foi desenvolvido para o Interlegis (programa do Senado Federal). Por
+padrão, funciona integrado com o servidor de listas de e-mail GNU Mailman e
+utiliza o Apache Lucene Solr para a indexação dos conteúdos para as buscas. A
+partir de 2014, as ferramentas GitLab e Noosfero foram integradas ao Colab para
+compor o novo SPB.
+
+O GitLab é uma plataforma de desenvolvimento colaborativo social integrada ao
+sistema de controle de versão Git. É o ambiente mais técnico: os repositórios
+dos projetos do SPB, com páginas wiki, issue tracker e mecanismos de controle
+de versão de código estão nele. O Noosfero é uma plataforma para rede social e
+de economia solidária que contém funcionalidades de gerenciamento de conteúdos
+(CMS), além de permitir a configuração das páginas de usuários e de comunidades
+de forma flexível. É o ambiente de maior interação com o usuário do SPB, desde
+os cadastros até o acesso às páginas dos projetos para download, leitura de
+documentação e contato com os responsáveis.
+
+A integração dessas ferramentas não está totalmente completa, pois demanda a
+solução de questões complexas de arquitetura de software. O que foi
+desenvolvido em 2014 está funcional e já supera o antigo portal do SPB em
+muitos aspectos. Em 2015, os perfis das diferentes ferramentas estão sendo
+integrados de modo que o usuário o gerencie em um único lugar. Os controles de
+acesso e a gestão de permissões também estão evoluindo. O mecanismo de coleta
+de dados e busca está sendo refatorado para acessar os conteúdos das novas
+ferramentas integradas ao Colab. Além disso, o Mezuro, um sistema para o
+monitoramento de métricas de código-fonte, está sendo acoplado ao Colab para
+fornecer acompanhamento da qualidade do código dos projetos.
+
+%TODO: Melissa
+A integração dos ambientes colaborativos vai além dos aspectos funcionais.
+Oferecer à população uma experiência unificada desses ambientes é fundamental
+para estimular o uso da plataforma, uma vez que reduz a percepção de
+complexidade.
+
+Assim, a arquitetura da informação do portal foi redesenhada para proporcionar uma
+navegação transparente e que atenda aos usuários de diversos perfis. Os modelos
+de interação de cada ferramenta passou por um processo de harmonização, reduzindo a curva de
+aprendizagem. Ao mesmo tempo, um novo estilo visual foi criado para unificar a navegação e atender as diretrizes de
+Identidade Padrão de Comunicação Digital do Governo Federal.
+
+Com o crescimento das funcionalidades e o acoplamento de novas ferramentas, o estilo visual foi constantemente evoluído para manter a navegação unificada. Com ferramentas de contextos distintos, que muitas vezes apresentavam funcionalidades de conceitos semelhantes, construir interfaces transparentes com a união dos diferentes contextos se tornou um desafio. Em diversos momentos, para cada funcionalidade requisitada pelo portal, nos deparamos com dados provenientes das ferramentas com padrões de estrutura e informação distintos que precisavam dançar juntos. A interface passou a ser o ponto de encontro dessas informações, um elo que precisava estar transparente ao usuário. Funcionalidades em comum entre as ferramentas como visualização e edição de perfil e busca, visualização e edição de conteúdo foram harmonizadas a estrutura e demais funcionalidades do portal.
+
+Outro ponto crítico está relacionado a responsividade. Provida e suportada em diversas maneiras por cada ferramenta e em alguns casos, não existente, a responsividade do portal precisou ser elaborada de acordo com o limite de cada ferramenta. No caso do Noosfero, que não provê um suporte a responsividade oficial, o projeto precisou se dedicar a expansão da ferramenta, com diversas contribuições e diálogos com a comunidade e mantenedores. Todos os integrantes do projeto se envolveram desde o estudo, desenho e codificação de uma nova interface com suporte a responsividade para o Noosfero e que ainda não foi concluída.
+
+Os usuários fazem parte do processo. Em 2014, foi aplicado um questionário para avaliar a satisfação das pessoas com o portal antigo e identificar problemas de experiência do usuário. 
+Em 2015 e 2016, realizamos atividades de validação da nova plataforma com usuários e cidadãos interessados. O retorno dessas atividades foi decisivo para o direcionamento dos esforços e determinação das principais áreas. Aproximar o usuário as funcionalidades que ele tem mais interesse e projetar uma navegação que se aprofunde junto com apronfudamento do conhecimento do usuário. 
+
@@ -0,0 +1,44 @@
+\section{Architecture}
+
+%TODO: Kanashiro
+Um proxy reverso trata requisições HTTP e as direciona para uma segunda
+máquina, onde são distribuidas para os serviços solicitados. Todos os bancos de
+dados relevantes estão concentrados em uma única máquina e todos os emails
+disparados pelo sistema partem de um mesmo relay.
+
+O ambiente é composto por 7 máquinas com funções distintas:
+
+\begin{itemize}
+
+\item Reverseproxy: Proxy reverso
+\item Integration: Segundo proxy reverso, Repositórios Git, Listas de email e Backend final de email
+\item Email: Relay de email
+\item Social: Servidor de rede social Noosfero
+\item Database: Servidor de banco de dados PostgreSQL
+\item Mezuro: Servidor de análise de código Mezuro
+\item Monitor: Monitoramento de informações dos outros serviços
+
+\end{itemize}
+
+As máquinas Reverseproxy, Email e Monitor possuem IP’s externos. Reverseproxy
+recebe requisições HTTP/HTTPS (portas 80 e 443) e possibilita que usuários
+utilizem os repositórios git (porta 22). Email recebe emails (porta 25) e
+enviar emails para fora da plataforma. Monitor recebe requisições HTTP/HTTPS
+(portas 80 e 443). Os IP’s variam de acordo com o ambiente.
+
+Conexões na porta 22 da máquina reverseproxy são redirecionadas para
+integration. Todas as máquinas aceitam conexões ssh originadas apenas da
+máquina integration, ou seja, não é possível realizar conexões ssh nas demais
+máquinas se a conexão não for originada da integration. As máquinas email,
+social, database e mezuro aceitam conexão ssh vindas da integration na porta 22
+e a reverseproxy em uma porta alternativa, especificada no arquivo de
+configuração do ambiente, config/\$SPB\_ENV/config.yaml pelo valor
+alt\_ssh\_port.
+
+Note que, como será demonstrado neste manual, existem atalhos definidos no
+repositório de gestão de configuração para simplificar o acesso por ssh às
+máquinas. Internamente, as máquinas integration e social também rodam web
+servers para servirem suas aplicações. Por fim, as máquinas integration e
+social conectam-se em database usando a porta 5432 para acesso aos bancos de
+dados.
+
@@ -0,0 +1,26 @@
+\section{Final remarks}
+
+%TODO: Hilmer
+A nova plataforma do SPB foi lançada para homologação em dezembro de 2014 e
+está em uso por algumas comunidades em beta.softwarepublico.gov.br. Todas as
+ferramentas são software livre e o que está sendo desenvolvido pelas equipes da
+UnB e USP é publicado em repositórios abertos, disponíveis na versão beta do
+próprio SPB. Mais importante do que isso, as melhorias necessárias nas
+ferramentas utilizadas estão sendo contribuídas de volta para as respectivas
+comunidades. Isso não só é o certo a se fazer do ponto de vista da comunidade
+de software livre, como vai possibilitar a redução de custos de manutenção no
+futuro para os cofres públicos e a evolução continuada da plataforma em
+sinergia com outras organizações que fazem uso das mesmas ferramentas.
+
+Disponibilizar um conjunto de ferramentas e melhorar a experiência do usuário
+no ambiente é parte desse processo de reformulação do SPB. Aspectos culturais
+da colaboração em rede para um efetivo uso do o que é fornecido na plataforma
+necessitam ser amadurecidos pelo MP junto às comunidades do SPB. Além disso, a
+demanda por maior impacto do software público na oferta de software, na adoção
+das soluções disponibilizadas e na atração de colaboradores e usuários requer
+intervenção. Um estudo para propostas de licenciamento e seus impactos para o
+SPB, bem como para sanar as contradições presentes na Instrução Normativa
+01/2011 (que dispõe sobre os procedimentos do SPB), também está sendo conduzido
+pela UnB para complementar o que está sendo desenvolvido do ponto de vista
+tecnológico.
+
@@ -34,184 +34,16 @@
 %  \texttt{terceiro@linaro.org}
 }
  
-
 \maketitle
 %------------------------------------------------------------------------------
  
-\begin{abstract}
-  % Contexto
-  % Problema
-  % Soluções propostas
-  % Frase de impacto
-\end{abstract}
-
-\section{Introduction}
-\label{sec:intro}
-
-%TODO: Paulo
-Governo Federal vem nos últimos anos melhorando seus processos de
-desenvolvimento e adoção de software. Em 2003, a recomendação da adoção de
-software livre passou a ser uma política, incentivada com a criação do Guia
-Livre. Em 2007, a Secretaria de Logística e Tecnologia da Informação (SLTI) do
-Ministério do Planejamento, Orçamento e Gestão (MP) lançou o portal do Software
-Público Brasileiro (SPB) -- um sistema web para o compartilhamento de projetos
-de software no Governo.
-
-Por um lado, a Instrução Normativa 04/2012 indica que os gestores devem
-consultar as soluções existentes no portal do SPB antes de realizar uma
-contratação de software. Por outro, a evolução técnica do portal do SPB foi
-comprometida, desde 2009, ao não acompanhar a evolução do seu framework base, o
-OpenACS. Não houve o lançamento de novas versões do portal desde então.
-
-Uma nova plataforma para o SPB está sendo desenvolvida pela Universidade de
-Brasília, através dos seus Laboratórios LAPPIS e MídiaLab em parceria com o
-Centro de Competência em Software Livre da Universidade de São Paulo
-(CCSL-USP). A nova plataforma é baseada na integração de ambientes
-colaborativos, sistemas de controle de versão e de monitoramento da qualidade
-do código-fonte, e está sendo desenvolvida por uma equipe heterogênea composta
-por alunos, professores e profissionais, aplicando métodos ágeis e práticas de
-desenvolvimento distribuído de software.
-
-\section{Platform for collaborative software development}
-
-%TODO: Paulo e Melissa
-O conceito de software público se diferencia do de software livre em alguns
-aspectos, destacando-se a atribuição de bem público ao software. Isso significa
-que o Governo, especificamente o MP, assume algumas responsabilidades que
-garantem ao usuário do software, em especial os órgãos públicos, condições
-adequadas de uso. Embora haja diferenças entre o que é um software livre e um
-software público brasileiro, há princípios comuns como a tendência da
-descentralização na tomada de decisões, do compartilhamento de informações e da
-retroalimentação. Por isso, a nova plataforma para o SPB foi pensada para
-contemplar ferramentas que promovam a colaboração e a interação nas comunidades
-(por gestores, usuários e desenvolvedores) dos projetos, conforme as práticas
-usadas nas comunidades de software livre. Isso inclui listas de e-mail, fóruns
-de discussão, issue trackers, sistemas de controle de versão e ambientes de
-rede social.
-
-Para integrar as ferramentas e prover a autenticação única nos serviços da
-plataforma, um sistema web chamado Colab, que funcionada como proxy reverso
-para os ambientes, está sendo evoluído. Em resumo, o Colab oferece a integração
-de busca, autenticação e apresentação, provendo um único ambiente ao usuário
-que tem em seu perfil algumas métricas de contribuições (e-mails para listas,
-inserções em wikis, cadastros de issue e commits nos repositórios).
-
-O Colab foi desenvolvido para o Interlegis (programa do Senado Federal). Por
-padrão, funciona integrado com o servidor de listas de e-mail GNU Mailman e
-utiliza o Apache Lucene Solr para a indexação dos conteúdos para as buscas. A
-partir de 2014, as ferramentas GitLab e Noosfero foram integradas ao Colab para
-compor o novo SPB.
-
-O GitLab é uma plataforma de desenvolvimento colaborativo social integrada ao
-sistema de controle de versão Git. É o ambiente mais técnico: os repositórios
-dos projetos do SPB, com páginas wiki, issue tracker e mecanismos de controle
-de versão de código estão nele. O Noosfero é uma plataforma para rede social e
-de economia solidária que contém funcionalidades de gerenciamento de conteúdos
-(CMS), além de permitir a configuração das páginas de usuários e de comunidades
-de forma flexível. É o ambiente de maior interação com o usuário do SPB, desde
-os cadastros até o acesso às páginas dos projetos para download, leitura de
-documentação e contato com os responsáveis.
-
-A integração dessas ferramentas não está totalmente completa, pois demanda a
-solução de questões complexas de arquitetura de software. O que foi
-desenvolvido em 2014 está funcional e já supera o antigo portal do SPB em
-muitos aspectos. Em 2015, os perfis das diferentes ferramentas estão sendo
-integrados de modo que o usuário o gerencie em um único lugar. Os controles de
-acesso e a gestão de permissões também estão evoluindo. O mecanismo de coleta
-de dados e busca está sendo refatorado para acessar os conteúdos das novas
-ferramentas integradas ao Colab. Além disso, o Mezuro, um sistema para o
-monitoramento de métricas de código-fonte, está sendo acoplado ao Colab para
-fornecer acompanhamento da qualidade do código dos projetos.
-
-%TODO: Melissa
-A integração dos ambientes colaborativos vai além dos aspectos funcionais.
-Oferecer à população uma experiência unificada desses ambientes é fundamental
-para estimular o uso da plataforma, uma vez que reduz a percepção de
-complexidade.
-
-Assim, a arquitetura da informação do portal foi redesenhada para proporcionar uma
-navegação transparente e que atenda aos usuários de diversos perfis. Os modelos
-de interação de cada ferramenta passou por um processo de harmonização, reduzindo a curva de
-aprendizagem. Ao mesmo tempo, um novo estilo visual foi criado para unificar a navegação e atender as diretrizes de
-Identidade Padrão de Comunicação Digital do Governo Federal.
-
-Com o crescimento das funcionalidades e o acoplamento de novas ferramentas, o estilo visual foi constantemente evoluído para manter a navegação unificada. Com ferramentas de contextos distintos, que muitas vezes apresentavam funcionalidades de conceitos semelhantes, construir interfaces transparentes com a união dos diferentes contextos se tornou um desafio. Em diversos momentos, para cada funcionalidade requisitada pelo portal, nos deparamos com dados provenientes das ferramentas com padrões de estrutura e informação distintos que precisavam dançar juntos. A interface passou a ser o ponto de encontro dessas informações, um elo que precisava estar transparente ao usuário. Funcionalidades em comum entre as ferramentas como visualização e edição de perfil e busca, visualização e edição de conteúdo foram harmonizadas a estrutura e demais funcionalidades do portal.
-
-Outro ponto crítico está relacionado a responsividade. Provida e suportada em diversas maneiras por cada ferramenta e em alguns casos, não existente, a responsividade do portal precisou ser elaborada de acordo com o limite de cada ferramenta. No caso do Noosfero, que não provê um suporte a responsividade oficial, o projeto precisou se dedicar a expansão da ferramenta, com diversas contribuições e diálogos com a comunidade e mantenedores. Todos os integrantes do projeto se envolveram desde o estudo, desenho e codificação de uma nova interface com suporte a responsividade para o Noosfero e que ainda não foi concluída.
-
-Os usuários fazem parte do processo. Em 2014, foi aplicado um questionário para avaliar a satisfação das pessoas com o portal antigo e identificar problemas de experiência do usuário. 
-Em 2015 e 2016, realizamos atividades de validação da nova plataforma com usuários e cidadãos interessados. O retorno dessas atividades foi decisivo para o direcionamento dos esforços e determinação das principais áreas. Aproximar o usuário as funcionalidades que ele tem mais interesse e projetar uma navegação que se aprofunde junto com apronfudamento do conhecimento do usuário. 
-
-\section{Architecture}
-
-%TODO: Kanashiro
-Um proxy reverso trata requisições HTTP e as direciona para uma segunda
-máquina, onde são distribuidas para os serviços solicitados. Todos os bancos de
-dados relevantes estão concentrados em uma única máquina e todos os emails
-disparados pelo sistema partem de um mesmo relay.
-
-O ambiente é composto por 7 máquinas com funções distintas:
-
-\begin{itemize}
-
-\item Reverseproxy: Proxy reverso
-\item Integration: Segundo proxy reverso, Repositórios Git, Listas de email e Backend final de email
-\item Email: Relay de email
-\item Social: Servidor de rede social Noosfero
-\item Database: Servidor de banco de dados PostgreSQL
-\item Mezuro: Servidor de análise de código Mezuro
-\item Monitor: Monitoramento de informações dos outros serviços
-
-\end{itemize}
-
-As máquinas Reverseproxy, Email e Monitor possuem IP’s externos. Reverseproxy
-recebe requisições HTTP/HTTPS (portas 80 e 443) e possibilita que usuários
-utilizem os repositórios git (porta 22). Email recebe emails (porta 25) e
-enviar emails para fora da plataforma. Monitor recebe requisições HTTP/HTTPS
-(portas 80 e 443). Os IP’s variam de acordo com o ambiente.
-
-Conexões na porta 22 da máquina reverseproxy são redirecionadas para
-integration. Todas as máquinas aceitam conexões ssh originadas apenas da
-máquina integration, ou seja, não é possível realizar conexões ssh nas demais
-máquinas se a conexão não for originada da integration. As máquinas email,
-social, database e mezuro aceitam conexão ssh vindas da integration na porta 22
-e a reverseproxy em uma porta alternativa, especificada no arquivo de
-configuração do ambiente, config/\$SPB\_ENV/config.yaml pelo valor
-alt\_ssh\_port.
-
-Note que, como será demonstrado neste manual, existem atalhos definidos no
-repositório de gestão de configuração para simplificar o acesso por ssh às
-máquinas. Internamente, as máquinas integration e social também rodam web
-servers para servirem suas aplicações. Por fim, as máquinas integration e
-social conectam-se em database usando a porta 5432 para acesso aos bancos de
-dados.
-
-\section{Final remarks}
-
-%TODO: Hilmer
-A nova plataforma do SPB foi lançada para homologação em dezembro de 2014 e
-está em uso por algumas comunidades em beta.softwarepublico.gov.br. Todas as
-ferramentas são software livre e o que está sendo desenvolvido pelas equipes da
-UnB e USP é publicado em repositórios abertos, disponíveis na versão beta do
-próprio SPB. Mais importante do que isso, as melhorias necessárias nas
-ferramentas utilizadas estão sendo contribuídas de volta para as respectivas
-comunidades. Isso não só é o certo a se fazer do ponto de vista da comunidade
-de software livre, como vai possibilitar a redução de custos de manutenção no
-futuro para os cofres públicos e a evolução continuada da plataforma em
-sinergia com outras organizações que fazem uso das mesmas ferramentas.
-
-Disponibilizar um conjunto de ferramentas e melhorar a experiência do usuário
-no ambiente é parte desse processo de reformulação do SPB. Aspectos culturais
-da colaboração em rede para um efetivo uso do o que é fornecido na plataforma
-necessitam ser amadurecidos pelo MP junto às comunidades do SPB. Além disso, a
-demanda por maior impacto do software público na oferta de software, na adoção
-das soluções disponibilizadas e na atração de colaboradores e usuários requer
-intervenção. Um estudo para propostas de licenciamento e seus impactos para o
-SPB, bem como para sanar as contradições presentes na Instrução Normativa
-01/2011 (que dispõe sobre os procedimentos do SPB), também está sendo conduzido
-pela UnB para complementar o que está sendo desenvolvido do ponto de vista
-tecnológico.
+\input{00-abstract}
+\input{01-introduction}
+\input{02-platform}
+\input{03-architecture}
+\input{04-finals}
  
+%------------------------------------------------------------------------------
 \bibliographystyle{splncs03}
 \bibliography{spb}
 \end{document}
...	...	@@ -0,0 +1,6 @@
	1	+\begin{abstract}
	2	+ % Contexto
	3	+ % Problema
	4	+ % Soluções propostas
	5	+ % Frase de impacto
	6	+\end{abstract}
...	...
...	...	@@ -0,0 +1,8 @@
	1	+\section{Introduction}
	2	+\label{sec:intro}
	3	+
	4	+Since last few decades, the Brazilian Federal Government has been improving its software adoption and development processes. In 2003, the recommendation to adopt free software become a public policy. In this context, in 2007, the Brazilian Ministry of Planning, Budget, and Management had released a Portal to share projects like free software called Brazilian Public Software (\textit{Software Público Brasileiro} -- SPB). In short, a website to share softwares developed by and for the Brazilian Government.
	5	+
	6	+On the one hand, the Brazilian legal instrument (IN 04/2012) on software contracting indicates that the public managers must consult the SPB Portal to adopt a software solution, as well as, justifying the acquisition of proprietary softwares if there is no a similar project available in the SPB Portal. On the other hand, since 2009, the SPB Portal had several technical problems because there was no development activities to maintenance and evolute it. Thus, the initial SPB Portal version did not have another release.
	7	+
	8	+During 2014 and 2016, a platform for the Brazilian Public Software project was designed and developed by the University of Brasília and the University of São Paulo. This new Portal was designed to be an integrated platform of collaborative software development environments with social networking, mailing list, control version system, and source code quality monitoring. In this paper, we present this new generation of the SPB Portal.
...	...
...	...	@@ -0,0 +1,70 @@
	1	+\section{Platform for collaborative software development}
	2	+
	3	+%TODO: Paulo e Melissa
	4	+O conceito de software público se diferencia do de software livre em alguns
	5	+aspectos, destacando-se a atribuição de bem público ao software. Isso significa
	6	+que o Governo, especificamente o MP, assume algumas responsabilidades que
	7	+garantem ao usuário do software, em especial os órgãos públicos, condições
	8	+adequadas de uso. Embora haja diferenças entre o que é um software livre e um
	9	+software público brasileiro, há princípios comuns como a tendência da
	10	+descentralização na tomada de decisões, do compartilhamento de informações e da
	11	+retroalimentação. Por isso, a nova plataforma para o SPB foi pensada para
	12	+contemplar ferramentas que promovam a colaboração e a interação nas comunidades
	13	+(por gestores, usuários e desenvolvedores) dos projetos, conforme as práticas
	14	+usadas nas comunidades de software livre. Isso inclui listas de e-mail, fóruns
	15	+de discussão, issue trackers, sistemas de controle de versão e ambientes de
	16	+rede social.
	17	+
	18	+Para integrar as ferramentas e prover a autenticação única nos serviços da
	19	+plataforma, um sistema web chamado Colab, que funcionada como proxy reverso
	20	+para os ambientes, está sendo evoluído. Em resumo, o Colab oferece a integração
	21	+de busca, autenticação e apresentação, provendo um único ambiente ao usuário
	22	+que tem em seu perfil algumas métricas de contribuições (e-mails para listas,
	23	+inserções em wikis, cadastros de issue e commits nos repositórios).
	24	+
	25	+O Colab foi desenvolvido para o Interlegis (programa do Senado Federal). Por
	26	+padrão, funciona integrado com o servidor de listas de e-mail GNU Mailman e
	27	+utiliza o Apache Lucene Solr para a indexação dos conteúdos para as buscas. A
	28	+partir de 2014, as ferramentas GitLab e Noosfero foram integradas ao Colab para
	29	+compor o novo SPB.
	30	+
	31	+O GitLab é uma plataforma de desenvolvimento colaborativo social integrada ao
	32	+sistema de controle de versão Git. É o ambiente mais técnico: os repositórios
	33	+dos projetos do SPB, com páginas wiki, issue tracker e mecanismos de controle
	34	+de versão de código estão nele. O Noosfero é uma plataforma para rede social e
	35	+de economia solidária que contém funcionalidades de gerenciamento de conteúdos
	36	+(CMS), além de permitir a configuração das páginas de usuários e de comunidades
	37	+de forma flexível. É o ambiente de maior interação com o usuário do SPB, desde
	38	+os cadastros até o acesso às páginas dos projetos para download, leitura de
	39	+documentação e contato com os responsáveis.
	40	+
	41	+A integração dessas ferramentas não está totalmente completa, pois demanda a
	42	+solução de questões complexas de arquitetura de software. O que foi
	43	+desenvolvido em 2014 está funcional e já supera o antigo portal do SPB em
	44	+muitos aspectos. Em 2015, os perfis das diferentes ferramentas estão sendo
	45	+integrados de modo que o usuário o gerencie em um único lugar. Os controles de
	46	+acesso e a gestão de permissões também estão evoluindo. O mecanismo de coleta
	47	+de dados e busca está sendo refatorado para acessar os conteúdos das novas
	48	+ferramentas integradas ao Colab. Além disso, o Mezuro, um sistema para o
	49	+monitoramento de métricas de código-fonte, está sendo acoplado ao Colab para
	50	+fornecer acompanhamento da qualidade do código dos projetos.
	51	+
	52	+%TODO: Melissa
	53	+A integração dos ambientes colaborativos vai além dos aspectos funcionais.
	54	+Oferecer à população uma experiência unificada desses ambientes é fundamental
	55	+para estimular o uso da plataforma, uma vez que reduz a percepção de
	56	+complexidade.
	57	+
	58	+Assim, a arquitetura da informação do portal foi redesenhada para proporcionar uma
	59	+navegação transparente e que atenda aos usuários de diversos perfis. Os modelos
	60	+de interação de cada ferramenta passou por um processo de harmonização, reduzindo a curva de
	61	+aprendizagem. Ao mesmo tempo, um novo estilo visual foi criado para unificar a navegação e atender as diretrizes de
	62	+Identidade Padrão de Comunicação Digital do Governo Federal.
	63	+
	64	+Com o crescimento das funcionalidades e o acoplamento de novas ferramentas, o estilo visual foi constantemente evoluído para manter a navegação unificada. Com ferramentas de contextos distintos, que muitas vezes apresentavam funcionalidades de conceitos semelhantes, construir interfaces transparentes com a união dos diferentes contextos se tornou um desafio. Em diversos momentos, para cada funcionalidade requisitada pelo portal, nos deparamos com dados provenientes das ferramentas com padrões de estrutura e informação distintos que precisavam dançar juntos. A interface passou a ser o ponto de encontro dessas informações, um elo que precisava estar transparente ao usuário. Funcionalidades em comum entre as ferramentas como visualização e edição de perfil e busca, visualização e edição de conteúdo foram harmonizadas a estrutura e demais funcionalidades do portal.
	65	+
	66	+Outro ponto crítico está relacionado a responsividade. Provida e suportada em diversas maneiras por cada ferramenta e em alguns casos, não existente, a responsividade do portal precisou ser elaborada de acordo com o limite de cada ferramenta. No caso do Noosfero, que não provê um suporte a responsividade oficial, o projeto precisou se dedicar a expansão da ferramenta, com diversas contribuições e diálogos com a comunidade e mantenedores. Todos os integrantes do projeto se envolveram desde o estudo, desenho e codificação de uma nova interface com suporte a responsividade para o Noosfero e que ainda não foi concluída.
	67	+
	68	+Os usuários fazem parte do processo. Em 2014, foi aplicado um questionário para avaliar a satisfação das pessoas com o portal antigo e identificar problemas de experiência do usuário.
	69	+Em 2015 e 2016, realizamos atividades de validação da nova plataforma com usuários e cidadãos interessados. O retorno dessas atividades foi decisivo para o direcionamento dos esforços e determinação das principais áreas. Aproximar o usuário as funcionalidades que ele tem mais interesse e projetar uma navegação que se aprofunde junto com apronfudamento do conhecimento do usuário.
	70	+
...	...
...	...	@@ -0,0 +1,44 @@
	1	+\section{Architecture}
	2	+
	3	+%TODO: Kanashiro
	4	+Um proxy reverso trata requisições HTTP e as direciona para uma segunda
	5	+máquina, onde são distribuidas para os serviços solicitados. Todos os bancos de
	6	+dados relevantes estão concentrados em uma única máquina e todos os emails
	7	+disparados pelo sistema partem de um mesmo relay.
	8	+
	9	+O ambiente é composto por 7 máquinas com funções distintas:
	10	+
	11	+\begin{itemize}
	12	+
	13	+\item Reverseproxy: Proxy reverso
	14	+\item Integration: Segundo proxy reverso, Repositórios Git, Listas de email e Backend final de email
	15	+\item Email: Relay de email
	16	+\item Social: Servidor de rede social Noosfero
	17	+\item Database: Servidor de banco de dados PostgreSQL
	18	+\item Mezuro: Servidor de análise de código Mezuro
	19	+\item Monitor: Monitoramento de informações dos outros serviços
	20	+
	21	+\end{itemize}
	22	+
	23	+As máquinas Reverseproxy, Email e Monitor possuem IP’s externos. Reverseproxy
	24	+recebe requisições HTTP/HTTPS (portas 80 e 443) e possibilita que usuários
	25	+utilizem os repositórios git (porta 22). Email recebe emails (porta 25) e
	26	+enviar emails para fora da plataforma. Monitor recebe requisições HTTP/HTTPS
	27	+(portas 80 e 443). Os IP’s variam de acordo com o ambiente.
	28	+
	29	+Conexões na porta 22 da máquina reverseproxy são redirecionadas para
	30	+integration. Todas as máquinas aceitam conexões ssh originadas apenas da
	31	+máquina integration, ou seja, não é possível realizar conexões ssh nas demais
	32	+máquinas se a conexão não for originada da integration. As máquinas email,
	33	+social, database e mezuro aceitam conexão ssh vindas da integration na porta 22
	34	+e a reverseproxy em uma porta alternativa, especificada no arquivo de
	35	+configuração do ambiente, config/\$SPB\_ENV/config.yaml pelo valor
	36	+alt\_ssh\_port.
	37	+
	38	+Note que, como será demonstrado neste manual, existem atalhos definidos no
	39	+repositório de gestão de configuração para simplificar o acesso por ssh às
	40	+máquinas. Internamente, as máquinas integration e social também rodam web
	41	+servers para servirem suas aplicações. Por fim, as máquinas integration e
	42	+social conectam-se em database usando a porta 5432 para acesso aos bancos de
	43	+dados.
	44	+
...	...
...	...	@@ -0,0 +1,26 @@
	1	+\section{Final remarks}
	2	+
	3	+%TODO: Hilmer
	4	+A nova plataforma do SPB foi lançada para homologação em dezembro de 2014 e
	5	+está em uso por algumas comunidades em beta.softwarepublico.gov.br. Todas as
	6	+ferramentas são software livre e o que está sendo desenvolvido pelas equipes da
	7	+UnB e USP é publicado em repositórios abertos, disponíveis na versão beta do
	8	+próprio SPB. Mais importante do que isso, as melhorias necessárias nas
	9	+ferramentas utilizadas estão sendo contribuídas de volta para as respectivas
	10	+comunidades. Isso não só é o certo a se fazer do ponto de vista da comunidade
	11	+de software livre, como vai possibilitar a redução de custos de manutenção no
	12	+futuro para os cofres públicos e a evolução continuada da plataforma em
	13	+sinergia com outras organizações que fazem uso das mesmas ferramentas.
	14	+
	15	+Disponibilizar um conjunto de ferramentas e melhorar a experiência do usuário
	16	+no ambiente é parte desse processo de reformulação do SPB. Aspectos culturais
	17	+da colaboração em rede para um efetivo uso do o que é fornecido na plataforma
	18	+necessitam ser amadurecidos pelo MP junto às comunidades do SPB. Além disso, a
	19	+demanda por maior impacto do software público na oferta de software, na adoção
	20	+das soluções disponibilizadas e na atração de colaboradores e usuários requer
	21	+intervenção. Um estudo para propostas de licenciamento e seus impactos para o
	22	+SPB, bem como para sanar as contradições presentes na Instrução Normativa
	23	+01/2011 (que dispõe sobre os procedimentos do SPB), também está sendo conduzido
	24	+pela UnB para complementar o que está sendo desenvolvido do ponto de vista
	25	+tecnológico.
	26	+
...	...
...	...	@@ -34,184 +34,16 @@
34	34	% \texttt{terceiro@linaro.org}
35	35	}
36	36
37		-
38	37	\maketitle
39	38	%------------------------------------------------------------------------------
40	39
41		-\begin{abstract}
42		- % Contexto
43		- % Problema
44		- % Soluções propostas
45		- % Frase de impacto
46		-\end{abstract}
47		-
48		-\section{Introduction}
49		-\label{sec:intro}
50		-
51		-%TODO: Paulo
52		-Governo Federal vem nos últimos anos melhorando seus processos de
53		-desenvolvimento e adoção de software. Em 2003, a recomendação da adoção de
54		-software livre passou a ser uma política, incentivada com a criação do Guia
55		-Livre. Em 2007, a Secretaria de Logística e Tecnologia da Informação (SLTI) do
56		-Ministério do Planejamento, Orçamento e Gestão (MP) lançou o portal do Software
57		-Público Brasileiro (SPB) -- um sistema web para o compartilhamento de projetos
58		-de software no Governo.
59		-
60		-Por um lado, a Instrução Normativa 04/2012 indica que os gestores devem
61		-consultar as soluções existentes no portal do SPB antes de realizar uma
62		-contratação de software. Por outro, a evolução técnica do portal do SPB foi
63		-comprometida, desde 2009, ao não acompanhar a evolução do seu framework base, o
64		-OpenACS. Não houve o lançamento de novas versões do portal desde então.
65		-
66		-Uma nova plataforma para o SPB está sendo desenvolvida pela Universidade de
67		-Brasília, através dos seus Laboratórios LAPPIS e MídiaLab em parceria com o
68		-Centro de Competência em Software Livre da Universidade de São Paulo
69		-(CCSL-USP). A nova plataforma é baseada na integração de ambientes
70		-colaborativos, sistemas de controle de versão e de monitoramento da qualidade
71		-do código-fonte, e está sendo desenvolvida por uma equipe heterogênea composta
72		-por alunos, professores e profissionais, aplicando métodos ágeis e práticas de
73		-desenvolvimento distribuído de software.
74		-
75		-\section{Platform for collaborative software development}
76		-
77		-%TODO: Paulo e Melissa
78		-O conceito de software público se diferencia do de software livre em alguns
79		-aspectos, destacando-se a atribuição de bem público ao software. Isso significa
80		-que o Governo, especificamente o MP, assume algumas responsabilidades que
81		-garantem ao usuário do software, em especial os órgãos públicos, condições
82		-adequadas de uso. Embora haja diferenças entre o que é um software livre e um
83		-software público brasileiro, há princípios comuns como a tendência da
84		-descentralização na tomada de decisões, do compartilhamento de informações e da
85		-retroalimentação. Por isso, a nova plataforma para o SPB foi pensada para
86		-contemplar ferramentas que promovam a colaboração e a interação nas comunidades
87		-(por gestores, usuários e desenvolvedores) dos projetos, conforme as práticas
88		-usadas nas comunidades de software livre. Isso inclui listas de e-mail, fóruns
89		-de discussão, issue trackers, sistemas de controle de versão e ambientes de
90		-rede social.
91		-
92		-Para integrar as ferramentas e prover a autenticação única nos serviços da
93		-plataforma, um sistema web chamado Colab, que funcionada como proxy reverso
94		-para os ambientes, está sendo evoluído. Em resumo, o Colab oferece a integração
95		-de busca, autenticação e apresentação, provendo um único ambiente ao usuário
96		-que tem em seu perfil algumas métricas de contribuições (e-mails para listas,
97		-inserções em wikis, cadastros de issue e commits nos repositórios).
98		-
99		-O Colab foi desenvolvido para o Interlegis (programa do Senado Federal). Por
100		-padrão, funciona integrado com o servidor de listas de e-mail GNU Mailman e
101		-utiliza o Apache Lucene Solr para a indexação dos conteúdos para as buscas. A
102		-partir de 2014, as ferramentas GitLab e Noosfero foram integradas ao Colab para
103		-compor o novo SPB.
104		-
105		-O GitLab é uma plataforma de desenvolvimento colaborativo social integrada ao
106		-sistema de controle de versão Git. É o ambiente mais técnico: os repositórios
107		-dos projetos do SPB, com páginas wiki, issue tracker e mecanismos de controle
108		-de versão de código estão nele. O Noosfero é uma plataforma para rede social e
109		-de economia solidária que contém funcionalidades de gerenciamento de conteúdos
110		-(CMS), além de permitir a configuração das páginas de usuários e de comunidades
111		-de forma flexível. É o ambiente de maior interação com o usuário do SPB, desde
112		-os cadastros até o acesso às páginas dos projetos para download, leitura de
113		-documentação e contato com os responsáveis.
114		-
115		-A integração dessas ferramentas não está totalmente completa, pois demanda a
116		-solução de questões complexas de arquitetura de software. O que foi
117		-desenvolvido em 2014 está funcional e já supera o antigo portal do SPB em
118		-muitos aspectos. Em 2015, os perfis das diferentes ferramentas estão sendo
119		-integrados de modo que o usuário o gerencie em um único lugar. Os controles de
120		-acesso e a gestão de permissões também estão evoluindo. O mecanismo de coleta
121		-de dados e busca está sendo refatorado para acessar os conteúdos das novas
122		-ferramentas integradas ao Colab. Além disso, o Mezuro, um sistema para o
123		-monitoramento de métricas de código-fonte, está sendo acoplado ao Colab para
124		-fornecer acompanhamento da qualidade do código dos projetos.
125		-
126		-%TODO: Melissa
127		-A integração dos ambientes colaborativos vai além dos aspectos funcionais.
128		-Oferecer à população uma experiência unificada desses ambientes é fundamental
129		-para estimular o uso da plataforma, uma vez que reduz a percepção de
130		-complexidade.
131		-
132		-Assim, a arquitetura da informação do portal foi redesenhada para proporcionar uma
133		-navegação transparente e que atenda aos usuários de diversos perfis. Os modelos
134		-de interação de cada ferramenta passou por um processo de harmonização, reduzindo a curva de
135		-aprendizagem. Ao mesmo tempo, um novo estilo visual foi criado para unificar a navegação e atender as diretrizes de
136		-Identidade Padrão de Comunicação Digital do Governo Federal.
137		-
138		-Com o crescimento das funcionalidades e o acoplamento de novas ferramentas, o estilo visual foi constantemente evoluído para manter a navegação unificada. Com ferramentas de contextos distintos, que muitas vezes apresentavam funcionalidades de conceitos semelhantes, construir interfaces transparentes com a união dos diferentes contextos se tornou um desafio. Em diversos momentos, para cada funcionalidade requisitada pelo portal, nos deparamos com dados provenientes das ferramentas com padrões de estrutura e informação distintos que precisavam dançar juntos. A interface passou a ser o ponto de encontro dessas informações, um elo que precisava estar transparente ao usuário. Funcionalidades em comum entre as ferramentas como visualização e edição de perfil e busca, visualização e edição de conteúdo foram harmonizadas a estrutura e demais funcionalidades do portal.
139		-
140		-Outro ponto crítico está relacionado a responsividade. Provida e suportada em diversas maneiras por cada ferramenta e em alguns casos, não existente, a responsividade do portal precisou ser elaborada de acordo com o limite de cada ferramenta. No caso do Noosfero, que não provê um suporte a responsividade oficial, o projeto precisou se dedicar a expansão da ferramenta, com diversas contribuições e diálogos com a comunidade e mantenedores. Todos os integrantes do projeto se envolveram desde o estudo, desenho e codificação de uma nova interface com suporte a responsividade para o Noosfero e que ainda não foi concluída.
141		-
142		-Os usuários fazem parte do processo. Em 2014, foi aplicado um questionário para avaliar a satisfação das pessoas com o portal antigo e identificar problemas de experiência do usuário.
143		-Em 2015 e 2016, realizamos atividades de validação da nova plataforma com usuários e cidadãos interessados. O retorno dessas atividades foi decisivo para o direcionamento dos esforços e determinação das principais áreas. Aproximar o usuário as funcionalidades que ele tem mais interesse e projetar uma navegação que se aprofunde junto com apronfudamento do conhecimento do usuário.
144		-
145		-\section{Architecture}
146		-
147		-%TODO: Kanashiro
148		-Um proxy reverso trata requisições HTTP e as direciona para uma segunda
149		-máquina, onde são distribuidas para os serviços solicitados. Todos os bancos de
150		-dados relevantes estão concentrados em uma única máquina e todos os emails
151		-disparados pelo sistema partem de um mesmo relay.
152		-
153		-O ambiente é composto por 7 máquinas com funções distintas:
154		-
155		-\begin{itemize}
156		-
157		-\item Reverseproxy: Proxy reverso
158		-\item Integration: Segundo proxy reverso, Repositórios Git, Listas de email e Backend final de email
159		-\item Email: Relay de email
160		-\item Social: Servidor de rede social Noosfero
161		-\item Database: Servidor de banco de dados PostgreSQL
162		-\item Mezuro: Servidor de análise de código Mezuro
163		-\item Monitor: Monitoramento de informações dos outros serviços
164		-
165		-\end{itemize}
166		-
167		-As máquinas Reverseproxy, Email e Monitor possuem IP’s externos. Reverseproxy
168		-recebe requisições HTTP/HTTPS (portas 80 e 443) e possibilita que usuários
169		-utilizem os repositórios git (porta 22). Email recebe emails (porta 25) e
170		-enviar emails para fora da plataforma. Monitor recebe requisições HTTP/HTTPS
171		-(portas 80 e 443). Os IP’s variam de acordo com o ambiente.
172		-
173		-Conexões na porta 22 da máquina reverseproxy são redirecionadas para
174		-integration. Todas as máquinas aceitam conexões ssh originadas apenas da
175		-máquina integration, ou seja, não é possível realizar conexões ssh nas demais
176		-máquinas se a conexão não for originada da integration. As máquinas email,
177		-social, database e mezuro aceitam conexão ssh vindas da integration na porta 22
178		-e a reverseproxy em uma porta alternativa, especificada no arquivo de
179		-configuração do ambiente, config/\$SPB\_ENV/config.yaml pelo valor
180		-alt\_ssh\_port.
181		-
182		-Note que, como será demonstrado neste manual, existem atalhos definidos no
183		-repositório de gestão de configuração para simplificar o acesso por ssh às
184		-máquinas. Internamente, as máquinas integration e social também rodam web
185		-servers para servirem suas aplicações. Por fim, as máquinas integration e
186		-social conectam-se em database usando a porta 5432 para acesso aos bancos de
187		-dados.
188		-
189		-\section{Final remarks}
190		-
191		-%TODO: Hilmer
192		-A nova plataforma do SPB foi lançada para homologação em dezembro de 2014 e
193		-está em uso por algumas comunidades em beta.softwarepublico.gov.br. Todas as
194		-ferramentas são software livre e o que está sendo desenvolvido pelas equipes da
195		-UnB e USP é publicado em repositórios abertos, disponíveis na versão beta do
196		-próprio SPB. Mais importante do que isso, as melhorias necessárias nas
197		-ferramentas utilizadas estão sendo contribuídas de volta para as respectivas
198		-comunidades. Isso não só é o certo a se fazer do ponto de vista da comunidade
199		-de software livre, como vai possibilitar a redução de custos de manutenção no
200		-futuro para os cofres públicos e a evolução continuada da plataforma em
201		-sinergia com outras organizações que fazem uso das mesmas ferramentas.
202		-
203		-Disponibilizar um conjunto de ferramentas e melhorar a experiência do usuário
204		-no ambiente é parte desse processo de reformulação do SPB. Aspectos culturais
205		-da colaboração em rede para um efetivo uso do o que é fornecido na plataforma
206		-necessitam ser amadurecidos pelo MP junto às comunidades do SPB. Além disso, a
207		-demanda por maior impacto do software público na oferta de software, na adoção
208		-das soluções disponibilizadas e na atração de colaboradores e usuários requer
209		-intervenção. Um estudo para propostas de licenciamento e seus impactos para o
210		-SPB, bem como para sanar as contradições presentes na Instrução Normativa
211		-01/2011 (que dispõe sobre os procedimentos do SPB), também está sendo conduzido
212		-pela UnB para complementar o que está sendo desenvolvido do ponto de vista
213		-tecnológico.
	40	+\input{00-abstract}
	41	+\input{01-introduction}
	42	+\input{02-platform}
	43	+\input{03-architecture}
	44	+\input{04-finals}
214	45
	46	+%------------------------------------------------------------------------------
215	47	\bibliographystyle{splncs03}
216	48	\bibliography{spb}
217	49	\end{document}
...	...