Commit 60a3a4dd7781b354e03027f37e00179ca7e73be7

Authored by Paulo Meireles
1 parent 399cdeb4

fixing

sbqs2017/content/04-architecture.tex
... ... @@ -4,7 +4,7 @@
4 4 Com base na extensa lista de requisitos funcionais definidos pelo Governo
5 5 Federal do Brasil, selecionamos alguns sistemas livres compor a solução
6 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
  7 +maior sub-conjunto possível dos requisitos. Nós também estávamos convencidos de
8 8 que seria impossível fornecer todas as funcionalidade com uma única ferramenta.
9 9  
10 10 Do ponto de vista da arquitetura, dois requisitos eram importantes para a nova
... ... @@ -17,22 +17,22 @@ plataforma:
17 17  
18 18 A adoção de sistemas livres existentes e a minimização de mudanças feitas
19 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
  20 +recentes do software original, nos beneficiando pelas melhorias e manutenção feitas
21 21 pelas comunidades de projetos existentes. Proporcionar uma interface de usuário
22 22 consistente em cima dessas diferentes ferramentas era necessária para fazer a
23 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
  24 +usuários, ou seja, sem confundí-lo através de interfaces completamente
25 25 diferentes ao interagir com o portal.
26 26  
27 27 Para o primeiro requisito, identificamos quatro sistemas principais que exigiam
28 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
  29 +aprenderam a desenvolver para os sistemas designados e contribuíram para as
30 30 comunidades originais, de modo que a versão que usamos não era
31 31 significativamente diferente do original.
32 32  
33   -No final do projeto, o portal SPB foi composto por mais de dez sistemas, como
  33 +Ao final do projeto, o portal SPB foi composto por mais de dez sistemas, como
34 34 Colab, Noosfero, Mezuro, Gitlab, Mailman, Postfix e Munin. A seguir
35   -apresentamos os mais relevantes deles, bem como como eles foram integrados na
  35 +apresentamos os mais relevantes, bem como como eles foram integrados na
36 36 plataforma.
37 37  
38 38 \begin{itemize}
... ... @@ -40,22 +40,21 @@ plataforma.
40 40 \item \textbf{Colab\footnote{\url{https://github.com/colab}}:} é uma plataforma
41 41 de integração de sistemas para aplicações web. Um de seus objetivos é permitir
42 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
  43 +a mudança entre as aplicações. Para isso, o Colab oferece autenticação
44 44 centralizada, consistência visual, retransmissão de eventos entre aplicações e
45   -mecanismo de pesquisa integrado.
  45 +mecanismo de busca integrado.
46 46  
47 47 \item \textbf{Noosfero\footnote{\url{http://noosfero.org}}:} é um software para
48 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
  49 +ele também fornece recursos de publicação de conteúdo, como blogs e CMS
50 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,
  51 +interações do usuário com o novo SPB são através do Noosfero: registro do usuário,
52 52 páginas do projeto e de documentação e formulários de contato.
53 53  
54 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.
  55 +de repositórios 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 para
  57 +desenvolvimento colaborativo em torno do repositório.
59 58  
60 59 \item \textbf{Mezuro\footnote{\url{http://mezuro.org/}}:} é uma plataforma para
61 60 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
75 74 virtuais com diferentes
76 75 funções\footnote{\url{https://softwarepublico.gov.br/doc/arquitetura.html}}. A
77 76 arquitetura conceitual da plataforma é apresentada na Figura
78   -\ref{fig:architecture}. O Colab inicialmente lida com toda a interação do
  77 +\ref{fig:architecture}. Em resumo, o Colab inicialmente lida com todas as requisições do
79 78 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.
  79 +processa as respostas das ferramentas abaixo dele, bem aplica uma aparência visual
  80 +consistente em cada uma, gerenciando também a autenticação e fornecendo uma busca
  81 +unificada entre elas.
86 82  
... ...
sbqs2017/content/05-features.tex
... ... @@ -3,8 +3,8 @@
3 3  
4 4 A nova geração do portal SPB combina recursos adaptados de plataformas
5 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.
  6 +Sempre que possível, novas funcionalidades (recém-desenvolvidas ou parcialmente
  7 +modificadas) foram enviadas de volta aos repositórios oficiais dos projetos usados.
8 8  
9 9 Como resultado, temos uma plataforma que integra e harmoniza diferentes
10 10 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
12 12 objetivo foi desenvolver funcionalidades reutilizando as ferramentas integradas
13 13 à plataforma. Além disso, tentamos manter essa integração transparente para os
14 14 usuários finais. Temos 3 grandes conjuntos de funcionalidades descritas nas
15   -próximas subseções.
  15 +próximas sub-seções.
16 16  
17 17 \subsection{Software e Comunidade de Software}
18 18  
19 19 No novo portal SPB, cada software tem um conjunto padrão de páginas e
20 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
  21 +instalação) dentro da plataforma. Com isso, os usuários são capazes de baixar diferentes
22 22 versões do software e encontrar vários mecanismos de gerenciamento de
23   -desenvolvimento de software.
  23 +desenvolvimento do projeto.
24 24  
25   -Focando no desenvolvimento colaborativo, Mailman foi integrado à plataforma
  25 +Focando no desenvolvimento colaborativo, o Mailman foi integrado à plataforma
26 26 para permitir o diálogo e a comunicação entre desenvolvedores, usuários e
27 27 entusiastas de um determinado software. O software tem sua própria lista de
28 28 discussão cuja privacidade pode ser configurada e definida pelos
... ... @@ -31,22 +31,22 @@ administradores.
31 31 O software possui uma área de interface social (``comunidade de software'')
32 32 onde os usuários podem encontrar outros usuários, blogs, resumo de atividades
33 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.
  34 +usuários registrados na plataforma podem solicitar a associação às comunidades
  35 +de software diferentes e cada membro da comunidade pode acessar e editar
  36 +conteúdos restritos. Para isso, muitos recursos do Noosfero, relacionados à rede
  37 +social e ao gerenciamento de conteúdo, foram integrados ao portal.
38 38  
39 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
  40 +avaliação e estatísticas. Agora, os usuários são capazes de avaliar o
  41 +software e fazer comentários, assim, todas as informações são disponibilizadas para outros
42 42 usuários. Além disso, o software possui uma seção contendo seus dados
43 43 estatísticos, onde os valores são calculados com base nos dados fornecidos
44   -pelos usuários e pelo sistema.
  44 +pelos usuários (como recursos economizados) e pelo próprio portal SPB (número de downloads).
45 45  
46   -O papel do administrador estará presente no software e na sua comunidade. O
  46 +O papel do administrador está presente no software e na sua comunidade. O
47 47 administrador é responsável por moderar o conteúdo, as associações e os
48 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.
  49 +alterações no conteúdo da página inicial do software e em outros conteúdos restritos.
50 50  
51 51 \subsection{Catálogo de Software e Busca Global}
52 52  
... ... @@ -65,7 +65,7 @@ software.
65 65  
66 66 \subsection{Ambiente de apoio ao desenvolvimento de software}
67 67  
68   -O novo SPB também fornece ferramentas para incentivar os desenvolvedores a
  68 +O novo portal SPB também fornece ferramentas para incentivar os desenvolvedores a
69 69 manter o código-fonte e sua atividade de desenvolvimento dentro da plataforma.
70 70 Qualquer software criado tem, por padrão, um repositório Git associado com
71 71 páginas wiki e \textit{issue tracker}. Essas ferramentas são fornecidas pela
... ...
sbqs2017/content/06-ux.tex
... ... @@ -4,23 +4,23 @@ A integração de ambientes colaborativos vai além dos aspectos funcionais.
4 4 Oferecer à população uma experiência unificada em todos esses ambientes tem
5 5 sido a chave para incentivar o uso da plataforma, pois reduz a percepção de
6 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
  7 +re-projetada para fornecer uma navegação transparente e alcançar usuários com
8 8 perfis diferentes. Um processo de harmonização foi empregado nos modelos de
9 9 interação de cada ferramenta para reduzir a curva de aprendizado. Ao mesmo
10 10 tempo, foi criado um novo estilo visual para unificar a experiência de
11 11 navegação e cumprir as diretrizes do padrão de identidade de comunicação
12 12 digital estabelecido pelo Governo Federal.
13 13  
14   -Com o aumento dos recursos do sistema e a adição de novas ferramentas, o estilo
  14 +Com o aumento das funcionalidades do sistema e a adição de novas ferramentas, o estilo
15 15 visual foi evoluído para manter a navegação unificada. Além disso, ferramentas
16 16 de origens diferentes, que em muitos casos fornecem funcionalidades
17   -semelhantes, nos levou ao desenvolvimento de uma interface unificada. Alguns
  17 +semelhantes, o que nos levou ao desenvolvimento de uma interface unificada. Alguns
18 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
  19 +ferramentas individuais e implementados centralmente para garantir uma
20 20 aparência consistente.
21 21  
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
  22 +Outro desafio foi a responsividade da interface. As aplicações integradas
  23 +tinham diferentes graus de suporte à resposividade e a interface comum
24 24 precisava se adaptar para cada cenário individual. Em particular, o Noosfero
25 25 ainda não tinha recursos de responsividade. Nós nos engajamos em seu
26 26 desenvolvimento e contribuímos para esse funcionalidade, contribuindo também
... ...
sbqs2017/content/07-process.tex
... ... @@ -5,32 +5,31 @@ A nossa equipe de desenvolvimento era composta por profissionais com diferentes
5 5 níveis e habilidades, sendo a maioria deles estudantes de graduação de
6 6 engenharia de software (a partir do 4º semestre de curso). Uma vez que os
7 7 alunos não podiam dedicar muitas horas por semana ao projeto, eles sempre
8   -tiveram a flexibilidade para negociar seu horário de trabalho durante o
9   -semestre, a fim de não prejudicar a sua formação. Sua rotina de trabalho diário
  8 +tiveram a flexibilidade para negociar seus horários de trabalho durante o
  9 +semestre, a fim de não prejudicar a sua formação. Sua rotina de trabalho diária
10 10 no projeto incluiu programação e tarefas de DevOps (contabilizando 16
11 11 horas-semanais).
12 12  
13 13 O desenvolvimento do projeto SPB exigiu uma vasta experiência, que os alunos de
14   -graduação geralmente ainda não têm. Por esta razão, alguns desenvolvedores
  14 +graduação geralmente ainda não têm. Por essa razão, alguns desenvolvedores
15 15 sênior se juntaram ao projeto para ajudar com as questões mais difíceis e
16 16 transferir conhecimento aos alunos. Sua principal tarefa era fornecer soluções
17 17 para problemas complexos. Como esses profissionais são muito hábeis e o projeto
18 18 não poderia financiar um trabalho de tempo integral, eles trabalharam
19 19 parcialmente no projeto (20 horas-semanais). Além disso, eles viviam em estados
20   -diferentes espalhados pelo Brasil, e outros países, o que levou muita da
  20 +diferentes espalhados pelo Brasil, ou até outros países, o que levou muita da
21 21 comunicação a ser on-line.
22 22  
23 23 Em resumo, nosso processo de trabalho foi baseado em práticas de
24   -desenvolvimento de software abertas e colaborativas. O processo de
25   -desenvolvimento foi definido com base na adaptação de diferentes práticas de
26   -comunidades ágeis e de software livre, destacando o alto grau de automação
  24 +desenvolvimento de software livre e colaborativo. O processo de
  25 +desenvolvimento foi definido com base na adaptação de diferentes práticas ágeis e de software livre, destacando o alto grau de automação
27 26 resultante das práticas de DevOps. Assim, o processo de trabalho foi executado
28   -de forma cadenciada e contínua.
  27 +de forma cadenciada e contínua.
29 28  
30   -Finalmente, o último grupo de atores deste projeto foi composto por
31   -funcionários formalmente trabalhando para o governo brasileiro, no Ministério
  29 +Finalmente, o último grupo de participantes desse projeto foi composto por
  30 +funcionários do Ministério
32 31 do Planejamento, Desenvolvimento e Gestão (MP). Todas as decisões do projeto,
33   -validações e definições de escopo foram feitas com eles. Desta forma,
  32 +validações e definições de escopo foram feitas com eles. Dessa forma,
34 33 desenvolvemos produtos de software de forma incremental, com lançamentos
35 34 alinhados aos objetivos estratégicos do negócio. Como se pode ver, o projeto
36 35 tinha muitos tipos diferentes de \textit{stakeholders} que tinham de ser
... ... @@ -39,10 +38,10 @@ organizados e sincronizados.
39 38 \subsection{Organização da equipe}
40 39  
41 40 Aproximadamente 70\% das equipes de desenvolvimento foram compostas por
42   -estudantes de engenharia de software da UnB e trabalharam fisicamente no mesmo
  41 +estudantes de engenharia de software da UnB e que trabalharam fisicamente no mesmo
43 42 laboratório. Cada aluno tinha seu próprio horário baseado em suas aulas, o que
44   -complicava a implementação da programação em pares. Os desenvolvedores sêniors
45   -tentaram sincronizar sua agenda com os alunos em sua sub-equipe. Para lidar com
  43 +complicava a implementação da programação em pares. Os desenvolvedores sênior
  44 +tentavam sincronizar sua agenda com os alunos em sua sub-equipe. Para lidar com
46 45 esse ambiente, tivemos algumas regras básicas que guiaram a organização do
47 46 projeto:
48 47  
... ... @@ -62,7 +61,7 @@ Colab, Noosfero, Design e DevOps. Cada equipe tinha um líder (\textit{coach})
62 61 responsável por reduzir o problema de comunicação com as outras equipes e
63 62 ajudar os membros a se organizar da melhor maneira para todos (sempre
64 63 respeitando seu tempo de trabalho). O \textit{coach} sempre foi um dos alunos
65   -que trabalha como desenvolvedor na equipe com o dever extra de registar as
  64 +que trabalhava como desenvolvedor na equipe com o dever extra de registar as
66 65 tarefas atuais desenvolvidas na iteração (\textit{sprint}) e com a
67 66 responsabilidade de conversar com outras equipes. Uma coisa importante a
68 67 observar é a mutabilidade da equipe e do \textit{coach}, pois durante o projeto
... ...