fixing

Paulo Meireles
1 parent 399cdeb4
Showing 4 changed files with 53 additions and 58 deletions Show diff stats
sbqs2017/content/04-architecture.tex
sbqs2017/content/05-features.tex
sbqs2017/content/06-ux.tex
sbqs2017/content/07-process.tex
@@ -4,7 +4,7 @@
 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
+maior sub-conjunto possível dos requisitos. Nós também estávamos convencidos de
 que seria impossível fornecer todas as funcionalidade com uma única ferramenta.
 Do ponto de vista da arquitetura, dois requisitos eram importantes para a nova
@@ -17,22 +17,22 @@ plataforma:
 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
+recentes do software original, nos beneficiando pelas 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
+usuários, ou seja, sem confundí-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
+aprenderam a desenvolver para os 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
+Ao 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
+apresentamos os mais relevantes, bem como como eles foram integrados na
 plataforma.
 \begin{itemize}
@@ -40,22 +40,21 @@ plataforma.
 \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
+a mudança entre as aplicações. Para isso, o Colab oferece autenticação
 centralizada, consistência visual, retransmissão de eventos entre aplicações e
-mecanismo de pesquisa integrado.
+mecanismo de busca 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
+ele também fornece recursos de publicação de conteúdo, como blogs e 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,
+interações do usuário com o novo SPB são 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.
+de repositórios Git com páginas wiki e recursos de \textit{issue tracker}. O
+Gitlab é uma plataforma livre e se concentra em oferecer uma solução para
+desenvolvimento colaborativo em torno do repositório.
 \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
@@ -75,12 +74,9 @@ 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
+\ref{fig:architecture}. Em resumo, o Colab inicialmente lida com todas as requisições 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.
+processa as respostas das ferramentas abaixo dele, bem aplica uma aparência visual
+consistente em cada uma, gerenciando também a autenticação e fornecendo uma busca
+unificada entre elas.
@@ -3,8 +3,8 @@
 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.
+Sempre que possível, novas funcionalidades (recém-desenvolvidas ou parcialmente
+modificadas) foram enviadas de volta aos repositórios oficiais dos projetos usados.
 Como resultado, temos uma plataforma que integra e harmoniza diferentes
 recursos, como redes sociais, lista de email, sistema de controle de versão,
@@ -12,17 +12,17 @@ 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.
+próximas sub-seções.
 \subsection{Software e Comunidade de Software}
 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
+instalação) dentro da plataforma. Com isso, os usuários são capazes de baixar diferentes
 versões do software e encontrar vários mecanismos de gerenciamento de
-desenvolvimento de software.
+desenvolvimento do projeto.
-Focando no desenvolvimento colaborativo, Mailman foi integrado à plataforma
+Focando no desenvolvimento colaborativo, o 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
@@ -31,22 +31,22 @@ administradores.
 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.
+usuários registrados na plataforma podem solicitar a associação às comunidades
+de software diferentes e cada membro da comunidade pode acessar e editar	
+conteúdos restritos. Para isso, muitos recursos do Noosfero, relacionados à rede
+social e ao gerenciamento de conteúdo, foram integrados ao portal.
 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
+avaliação e estatísticas. Agora, os usuários são capazes de avaliar o
+software e fazer comentários, assim, todas as informações são disponibilizadas 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.
+pelos usuários (como recursos economizados) e pelo próprio portal SPB (número de downloads).
-O papel do administrador estará presente no software e na sua comunidade. O
+O papel do administrador está 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.
+alterações no conteúdo da página inicial do software e em outros conteúdos restritos.
 \subsection{Catálogo de Software e Busca Global}
@@ -65,7 +65,7 @@ software.
 \subsection{Ambiente de apoio ao desenvolvimento de software}
-O novo SPB também fornece ferramentas para incentivar os desenvolvedores a
+O novo portal 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
@@ -4,23 +4,23 @@ 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
+re-projetada 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.
-Com o aumento dos recursos do sistema e a adição de novas ferramentas, o estilo
+Com o aumento das funcionalidades 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
+semelhantes, o que 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
+ferramentas individuais e implementados centralmente para garantir uma
 aparência consistente.
-Outro desafio foi o \textit{design web} responsivo. As aplicações integradas
-tinham diferentes graus de suporte para resposividade e a interface comum
+Outro desafio foi a responsividade da interface. As aplicações integradas
+tinham diferentes graus de suporte à 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
@@ -5,32 +5,31 @@ 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
+tiveram a flexibilidade para negociar seus horários de trabalho durante o
+semestre, a fim de não prejudicar a sua formação. Sua rotina de trabalho diária
 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
+graduação geralmente ainda não têm. Por essa 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
+diferentes espalhados pelo Brasil, ou até 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
+desenvolvimento de software livre e colaborativo. O processo de
+desenvolvimento foi definido com base na adaptação de diferentes práticas á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. 
+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
+Finalmente, o último grupo de participantes desse projeto foi composto por
+funcionários do 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,
+validações e definições de escopo foram feitas com eles. Dessa 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
@@ -39,10 +38,10 @@ 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
+estudantes de engenharia de software da UnB e que 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
+complicava a implementação da programação em pares. Os desenvolvedores sênior
+tentavam 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:
@@ -62,7 +61,7 @@ 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
+que trabalhava 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