Minor adjustments

Paulo Meireles
1 parent 00023793
Showing 3 changed files with 106 additions and 80 deletions Show diff stats
cbsoft2017/content/04-architecture.tex
cbsoft2017/content/07-process.tex
cbsoft2017/content/10-finals.tex
 \section{Visão geral do novo Portal SPB}
 \label{sec:architecture}
-Com base em uma extensa lista de requisitos funcionais definidos pelo MP, selecionamos alguns sistemas livres candidatos \'a compor a solução
-proposta para o novo SPB e avaliamos os sistemas que juntos poderiam fornecer o maior sub-conjunto possível dos requisitos.
-
-Do ponto de vista da arquitetura, dois requisitos eram importantes para a nova
-plataforma:
+Com base em uma extensa lista de requisitos funcionais definidos pelo MP,
+selecionamos alguns sistemas livres candidatos à compor a solução proposta para
+o novo SPB e avaliamos os sistemas que juntos poderiam fornecer o maior
+sub-conjunto possível dos requisitos. Do ponto de vista da arquitetura, dois
+requisitos eram importantes para a nova plataforma:
 \begin{enumerate}
 \item \textit{Integrar sistemas livres existentes}, com diferenças mínimas de suas versões originais;
-\item \textit{Fornecer uma experi\^encia de usuário unificada} entre os diferentes sistemas, bem como a autenticação centralizada.
+\item \textit{Fornecer uma experiência de usuário unificada} entre os diferentes sistemas, bem como a autenticação centralizada.
 \end{enumerate}
 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, nos beneficiando pelas melhorias e manutenção feitas
-pelas comunidades de projetos existentes. Proporcionar uma experi\^encia 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 confundí-lo através de interfaces gráficas completamente
-distintas ao interagir com o portal.
+recentes do software original, nos beneficiando pelas melhorias e manutenção
+feitas pelas comunidades de projetos existentes. Proporcionar uma experiência
+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 confundí-lo através de interfaces gráficas
+completamente distintas 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
@@ -2,23 +2,23 @@
 \label{sec:process}
 A nossa equipe de desenvolvimento era composta por profissionais com diferentes
-níveis de experiência 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 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, testes e tarefas de DevOps (contabilizando 16
-horas-semanais).
+níveis de experiência 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 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, testes e tarefas de DevOps
+(contabilizando 16 horas-semanais).
 O desenvolvimento do projeto SPB exigiu experiência avançada, que os alunos de
 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, além de 
-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
+sênior se juntaram ao projeto para ajudar com as questões mais difíceis, além
+de 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, ou até em outros países, o que levou muito da
-comunicação a ser on-line.
+diferentes espalhados pelo Brasil, ou até em outros países, o que levou muito
+da comunicação a ser on-line.
 Em resumo, nosso processo de trabalho foi baseado em práticas de
 desenvolvimento de software livre e colaborativo. O processo de desenvolvimento
@@ -51,7 +51,8 @@ organização do projeto:
 \item Deve haver uma manhã ou uma tarde por semana quando \emph{todos} deverem
       estar juntos fisicamente no laboratório (exceto, é claro, os membros da
       equipe remota, mas que estarão on-line).
-\item A cada 2 ou 3 meses, os desenvolvedores sêniores (residentes no Brasil) trabalharia presencialmente ao lado dos alunos por uma semana.
+\item A cada 2 ou 3 meses, os desenvolvedores sêniores (residentes no Brasil)
+trabalharia presencialmente ao lado dos alunos por uma semana.
 \end{enumerate}
 Com as regras acima, dividimos todo o projeto em quatro equipes diferentes:
@@ -61,9 +62,11 @@ ajudar os membros a se organizarem da melhor maneira para todos (sempre
 respeitando seu tempo de trabalho). O \textit{coach} sempre foi um dos alunos
 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. É importante salientar sobre a alta rotatividade da equipe e do \textit{coach}, pois durante o projeto
+responsabilidade de conversar com outras equipes. É importante salientar sobre
+a alta rotatividade da equipe e do \textit{coach}, pois durante o projeto
 muitos alunos mudaram de equipe para tentar ter diferentes experiências em
-diversas áreas/tecnologias, além daqueles alunos que naturalmente foram se formando.
+diversas áreas/tecnologias, além daqueles alunos que naturalmente foram se
+formando.
 Uma característica das equipes foi a presença de (pelo menos) um sênior por
 equipe. Isso era essencial, porque as decisões difíceis e os problemas
@@ -71,20 +74,22 @@ complexos, geralmente, foram resolvidos ao consultá-los. Essa dinâmica
 incentivou os demais alunos a terem o mesmo compartamento do \textit{coach}
 mesmo sem serem. Por fim, os desenvolvedores sêniores trabalharam diretamente
 com os alunos, e isso foi importante para dar ao graduando a oportunidade de
-interagir com profissionais experientes em sua área, além de manter o conhecimento no projeto compartilhado entre as equipes.
+interagir com profissionais experientes em sua área, além de manter o
+conhecimento no projeto compartilhado entre as equipes.
 Por fim, tivemos ainda dois últimos elementos da organização da equipe que
-foram essenciais para a harmonia do projeto: o \textit{meta-coach} e os 
-professores. O primeiro era um engenheiro de software recentemente graduado, egresso, e que queria continuar trabalhando no projeto; esses últimos
-eram professores que orquestraram todas as interações entre todos os membros do
-projeto, inclusive do MP. O \textit{meta-coach} normalmente
-trabalhava em uma equipe específica e tinha a tarefa extra de conhecer o estado
-atual de todas as equipes. Os professores e \textit{meta-coach} trabalharam
-juntos para reduzir o problema de comunicação entre todas as equipes (o que
-tornou-se mais complexo conforme a evolução do volume de trabalho). Por
-último, todas as tarefas burocráticas, como a elaboração de relatórios sobre o
-progresso do projeto para o Ministério, foi tratada pelos professores, mas com
-o envolvimento de toda a equipe.
+foram essenciais para a harmonia do projeto: o \textit{meta-coach} e os
+professores. O primeiro era um engenheiro de software recentemente graduado,
+egresso, e que queria continuar trabalhando no projeto; esses últimos eram
+professores que orquestraram todas as interações entre todos os membros do
+projeto, inclusive do MP. O \textit{meta-coach} normalmente trabalhava em uma
+equipe específica e tinha a tarefa extra de conhecer o estado atual de todas as
+equipes. Os professores e \textit{meta-coach} trabalharam juntos para reduzir o
+problema de comunicação entre todas as equipes (o que tornou-se mais complexo
+conforme a evolução do volume de trabalho). Por último, todas as tarefas
+burocráticas, como a elaboração de relatórios sobre o progresso do projeto para
+o Ministério, foi tratada pelos professores, mas com o envolvimento de toda a
+equipe.
 \subsection{Comunicação e gestão das tarefas}
@@ -115,34 +120,40 @@ plataforma).
 \subsection{Acompanhamento e gerenciamento de projeto de alto nível}
 O governo brasileiro costuma trabalhar com o desenvolvimento de software de uma
-forma mais tradicional, diferentemente de nós que utilizamos métodos ágeis e software
-livre. Essa dissonância nos causou um ruído de comunicação com o MP. Foi
-especialmente difícil convencê-los a aceitar a ideia de escopo aberto e
-desenvolvimento ágil. Entretanto, depois de meses de trabalho e na medida em que os resultados foram se concretizando, em especial a entrega e implantação frequente de releases, a resistência foi gradualmente diminuindo.
+forma mais tradicional, diferentemente de nós que utilizamos métodos ágeis e
+software livre. Essa dissonância nos causou um ruído de comunicação com o MP.
+Foi especialmente difícil convencê-los a aceitar a ideia de escopo aberto e
+desenvolvimento ágil. Entretanto, depois de meses de trabalho e na medida em
+que os resultados foram se concretizando, em especial a entrega e implantação
+frequente de \textit{releases}, a resistência foi gradualmente diminuindo.
 Definimos níveis de granularidade das reuniões para evitar gerar demasiada
-sobrecarga para os membros das equipes, em especial para os alunos. Tínhamos reuniões de caráter estratégico, com periodicidade mensal, e
-reuniões planejamento e revisão de sprints a cada 15 dias. Na reunião estratégica,
-geralmente, eram definidas as prioridades estratégicas do MP, e com isso o conjunto de funcionalidades importantes para atender àquelas prioridades estratégicas. Normalmente, os professores, os \textit{coaches} de cada equipe, os
-\textit{meta-coaches} e alguns analistas do MP
-participavam dessa reunião. Em geral, discutíamos o que a equipe já produziu
-desde nossa última reunião e priorizámos as funcionalidades para a próxima
-versão. Observe que apenas parte da equipe participava dessas reuniões
-estratégicas, mas todos os estudantes interessados estavam convidados a
-participar (pois muitos estudantes quiseram passar por essa experiência durante o
-projeto).
-
-Depois dos encontros estratégicos com os principais atores envolvidos do
-MP, tínhamos um turno de planejamento com todas as equipes juntas. Nessa
-parte, cada equipe trabalhava junto para converter a representação dos requisitos em ``Épicos'' da ``release'' em desenvolvimento,  em requisitos 
-menores (histórias de usuário). Cada \textit{coach} era responsável pela
-condução do planejamento, e depois a equipe toda a registrava na página wiki do
-projeto (wiki fornecido pelo Gitlab do SPB). Baseado nos ``épicos'', a cada 15
-dias a equipe gerava um o planejamento da sprint/ciclo de desenvolvimento
-(com os pequenos passos dos problemas mapeados). Para manter o MP sempre atualizado, convidávamos-os a trabalhar conosco para validar
-as funcionalidades em desenvolvimento. Para isso, tínhamos uma reunião a cada
-15 dia. E para manter nosso fluxo de gestão de tarefas, usando a própria
-plataforma do SPB, especialmente o Gitlab, tínhamos:
+sobrecarga para os membros das equipes, em especial para os alunos. Tínhamos
+reuniões de caráter estratégico, com periodicidade mensal, e reuniões
+planejamento e revisão de sprints a cada 15 dias. Na reunião estratégica,
+geralmente, eram definidas as prioridades estratégicas do MP, e com isso o
+conjunto de funcionalidades importantes para atender àquelas prioridades
+estratégicas. Normalmente, os professores, os \textit{coaches} de cada equipe,
+os \textit{meta-coaches} e alguns analistas do MP participavam dessa reunião.
+Em geral, discutíamos o que a equipe já produziu desde nossa última reunião e
+priorizámos as funcionalidades para a próxima versão. Observe que apenas parte
+da equipe participava dessas reuniões estratégicas, mas todos os estudantes
+interessados estavam convidados a participar (pois muitos estudantes quiseram
+passar por essa experiência durante o projeto).
+
+Depois dos encontros estratégicos com os principais atores envolvidos do MP,
+tínhamos um turno de planejamento com todas as equipes juntas. Nessa parte,
+cada equipe trabalhava junto para converter a representação dos requisitos em
+``épicos da \textit{release}'' em desenvolvimento,  em requisitos menores
+(histórias de usuário). Cada \textit{coach} era responsável pela condução do
+planejamento, e depois a equipe toda a registrava na página wiki do projeto
+(wiki fornecido pelo Gitlab do SPB). Baseado nos ``épicos'', a cada 15 dias a
+equipe gerava um o planejamento da iteração/ciclo de desenvolvimento (com os
+pequenos passos dos problemas mapeados). Para manter o MP sempre atualizado,
+convidávamos-os a trabalhar conosco para validar as funcionalidades em
+desenvolvimento. Para isso, tínhamos uma reunião a cada 15 dia. E para manter
+nosso fluxo de gestão de tarefas, usando a própria plataforma do SPB,
+especialmente o Gitlab, tínhamos:
 \begin{enumerate}
@@ -151,7 +162,7 @@ integrada e sub-sistema;
 \item cada \textit{milestone} foi usado para registrar uma história de usuário;
-\item cada \textit{release} tevw uma página na wiki com a compilação da reunião
+\item cada \textit{release} teve uma página na wiki com a compilação da reunião
 estratégica e o mapeamento das funcionalidades planejadas;
 \item para cada \textit{milestone} (história de usuário) tem um conjunto de
@@ -161,4 +172,7 @@ estratégica e o mapeamento das funcionalidades planejadas;
 \end{enumerate}
-Em suma, esse fluxo de trabalho proporcionou a nós e aos envolvidos do MP uma rastreabilidade completa do alinhamento estratégico do negócio, a uma visão de alto nível de cada funcionalidade (requisito/\'epico), a uma visão de grão menor dos requisitos(história de usuário) até o código-fonte.
+Em suma, esse fluxo de trabalho proporcionou a nós e aos envolvidos do MP uma
+rastreabilidade completa do alinhamento estratégico do negócio, a uma visão de
+alto nível de cada funcionalidade (requisito/épico), a uma visão de grão
+menor dos requisitos(história de usuário) até o código-fonte.
@@ -19,18 +19,30 @@ Ciência da Computação no IME-USP, na área de Sistemas de Software. Foi
 pesquisador visitante na Southern Illinois University Carbondale, Estados
 Unidos, em 2011. Tem um amplo histórico de colaboração com a comunidade
 software livre brasileira, entre outras, ministrando dezenas de palestras e
-parcipando como painelista em vários eventos nacionais e internacionais nas últimas
-duas décadas. Mais recentemente, coordenou a Evolução do Portal do Software
-Público Brasileiro. Também, foi consultor do projeto Participa.Br, na Secretaria-Geral
-da Presidência da República, para o desenvolvimento de uma plataforma de
-participação social baseada em projetos de software livre.
+parcipando como painelista em vários eventos nacionais e internacionais nas
+últimas duas décadas. Mais recentemente, coordenou a Evolução do Portal do
+Software Público Brasileiro. Também, foi consultor do projeto Participa.Br, na
+Secretaria-Geral da Presidência da República, para o desenvolvimento de uma
+plataforma de participação social baseada em projetos de software livre.
 \\
 \\
 {\it Hilmer Neri} é professor do Bacharelado em Engenharia de Software da
-Universidade de Brasília. Está cursando o doutorado no programa de Engenharia de Sistemas e
-Computação na COPPE-UFRJ. Em 2002, concluiu seu mestrado em Ciência da
-Computação pela Universidade Federal de Campina Grande. Acumula 20 anos de
-experiência profissional na indústria de software, tendo atuado em empresas nas
-esferas pública e privada. Nos últimos anos tem se dedicado a pesquisar e
-praticar aspectos da Produção de Software com foco na Qualidade do Produto de Software.
-Tem colaborado com o desenvolvimento de softwares livres e também com dados abertos do governo. Entusiasta da área de Engenharia de Software, é fundador do laboratório LAPPIS, que possui como foco, a pesquisa e a produção de software, destacando a utilização de métodos de desenvolvimento colaborativo e aberto. Áreas de interesse: métodos ágeis/lean; engenharia de software contínua; engenharia de produto; qualidade de produto de software; análise de dados; mineraç\~ao de repostórios de software; dados abertos do governo; software livre; inovação; empreendedorismo e experimentação aplicada \`a engenharia de software.
+Universidade de Brasília. Está cursando o doutorado no programa de Engenharia
+de Sistemas e Computação na COPPE-UFRJ. Em 2002, concluiu seu mestrado em
+Ciência da Computação pela Universidade Federal de Campina Grande. Acumula 20
+anos de experiência profissional na indústria de software, tendo atuado em
+empresas nas esferas pública e privada. Nos últimos anos tem se dedicado a
+pesquisar e praticar aspectos da Produção de Software com foco na Qualidade do
+Produto de Software.  Tem colaborado com o desenvolvimento de softwares livres
+e também com dados abertos do governo. Entusiasta da área de Engenharia de
+Software, é fundador do laboratório LAPPIS, que possui como foco, a pesquisa e
+a produção de software, destacando a utilização de métodos de desenvolvimento
+colaborativo e aberto.
+
+\section*{Agradecimentos}
+
+Agracemos à Melissa Wen, Rodrigo Siqueira, Antonio Terceiro e Lucas Kanashiro
+pela co-autoria neste texto. Um agradecimento especial a todos os demais
+professores, profissionais e alunos que participaram do projeto. Por fim,
+agradecemos ao Prof. Leonardo Lazarte, do CDTC/UnB, e ao Prof. Fabio Kon, do
+CCSL-IME-USP, pelas parcerias estratégicas e apoio constante.
	@@ -19,18 +19,30 @@ Ciência da Computação no IME-USP, na área de Sistemas de Software. Foi		@@ -19,18 +19,30 @@ Ciência da Computação no IME-USP, na área de Sistemas de Software. Foi
19	pesquisador visitante na Southern Illinois University Carbondale, Estados	19	pesquisador visitante na Southern Illinois University Carbondale, Estados
20	Unidos, em 2011. Tem um amplo histórico de colaboração com a comunidade	20	Unidos, em 2011. Tem um amplo histórico de colaboração com a comunidade
21	software livre brasileira, entre outras, ministrando dezenas de palestras e	21	software livre brasileira, entre outras, ministrando dezenas de palestras e
22	-parcipando como painelista em vários eventos nacionais e internacionais nas últimas
23	-duas décadas. Mais recentemente, coordenou a Evolução do Portal do Software
24	-Público Brasileiro. Também, foi consultor do projeto Participa.Br, na Secretaria-Geral
25	-da Presidência da República, para o desenvolvimento de uma plataforma de
26	-participação social baseada em projetos de software livre.	22	+parcipando como painelista em vários eventos nacionais e internacionais nas
		23	+últimas duas décadas. Mais recentemente, coordenou a Evolução do Portal do
		24	+Software Público Brasileiro. Também, foi consultor do projeto Participa.Br, na
		25	+Secretaria-Geral da Presidência da República, para o desenvolvimento de uma
		26	+plataforma de participação social baseada em projetos de software livre.
27	\\	27	\\
28	\\	28	\\
29	{\it Hilmer Neri} é professor do Bacharelado em Engenharia de Software da	29	{\it Hilmer Neri} é professor do Bacharelado em Engenharia de Software da
30	-Universidade de Brasília. Está cursando o doutorado no programa de Engenharia de Sistemas e
31	-Computação na COPPE-UFRJ. Em 2002, concluiu seu mestrado em Ciência da
32	-Computação pela Universidade Federal de Campina Grande. Acumula 20 anos de
33	-experiência profissional na indústria de software, tendo atuado em empresas nas
34	-esferas pública e privada. Nos últimos anos tem se dedicado a pesquisar e
35	-praticar aspectos da Produção de Software com foco na Qualidade do Produto de Software.
36	-Tem colaborado com o desenvolvimento de softwares livres e também com dados abertos do governo. Entusiasta da área de Engenharia de Software, é fundador do laboratório LAPPIS, que possui como foco, a pesquisa e a produção de software, destacando a utilização de métodos de desenvolvimento colaborativo e aberto. Áreas de interesse: métodos ágeis/lean; engenharia de software contínua; engenharia de produto; qualidade de produto de software; análise de dados; mineraç\~ao de repostórios de software; dados abertos do governo; software livre; inovação; empreendedorismo e experimentação aplicada \`a engenharia de software.	30	+Universidade de Brasília. Está cursando o doutorado no programa de Engenharia
		31	+de Sistemas e Computação na COPPE-UFRJ. Em 2002, concluiu seu mestrado em
		32	+Ciência da Computação pela Universidade Federal de Campina Grande. Acumula 20
		33	+anos de experiência profissional na indústria de software, tendo atuado em
		34	+empresas nas esferas pública e privada. Nos últimos anos tem se dedicado a
		35	+pesquisar e praticar aspectos da Produção de Software com foco na Qualidade do
		36	+Produto de Software. Tem colaborado com o desenvolvimento de softwares livres
		37	+e também com dados abertos do governo. Entusiasta da área de Engenharia de
		38	+Software, é fundador do laboratório LAPPIS, que possui como foco, a pesquisa e
		39	+a produção de software, destacando a utilização de métodos de desenvolvimento
		40	+colaborativo e aberto.
		41	+
		42	+\section*{Agradecimentos}
		43	+
		44	+Agracemos à Melissa Wen, Rodrigo Siqueira, Antonio Terceiro e Lucas Kanashiro
		45	+pela co-autoria neste texto. Um agradecimento especial a todos os demais
		46	+professores, profissionais e alunos que participaram do projeto. Por fim,
		47	+agradecemos ao Prof. Leonardo Lazarte, do CDTC/UnB, e ao Prof. Fabio Kon, do
		48	+CCSL-IME-USP, pelas parcerias estratégicas e apoio constante.