diff --git a/sbqs2017/content/04-architecture.tex b/sbqs2017/content/04-architecture.tex index 8f39dc9..b72ba10 100644 --- a/sbqs2017/content/04-architecture.tex +++ b/sbqs2017/content/04-architecture.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. diff --git a/sbqs2017/content/05-features.tex b/sbqs2017/content/05-features.tex index 8772d1f..1643c0a 100644 --- a/sbqs2017/content/05-features.tex +++ b/sbqs2017/content/05-features.tex @@ -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 diff --git a/sbqs2017/content/06-ux.tex b/sbqs2017/content/06-ux.tex index 7aea218..61af827 100644 --- a/sbqs2017/content/06-ux.tex +++ b/sbqs2017/content/06-ux.tex @@ -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 diff --git a/sbqs2017/content/07-process.tex b/sbqs2017/content/07-process.tex index 37290ed..988afd8 100644 --- a/sbqs2017/content/07-process.tex +++ b/sbqs2017/content/07-process.tex @@ -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 -- libgit2 0.21.2