Software Público Brasileiro

Reviewer 1
---

Resumo (Summary): Uma breve descrição do artigo

O artigo apresenta uma visao geral da experiência do desenvolvimento do novo Portal SPB, explicando algumas questões técnicas relacionadas e algumas lições aprendidas durante a execução do projeto.

Pontos Fortes (Paper Strengths): Quais os pontos positivos do artigo?
+ desenvolvimento de uma plataforma computacional de uso geral em larga escala capaz de gerar um nicho de desenvolvimento de software nacional

Pontos Fracos (Paper Weakness): Quais os aspectos negativos do artigo?
- falta de embasamento teórico mais detalhado (incluindo referências)
- falta de visões compartilhadas entre equipe desenvolvedora e equipe consumidora (o viés é da equipe desenvolvedora)
- questões de qualidade de escrita (informal e de Português)
- lições aprendidas mais específicas do processo de desenvolvimento

Comentários para os Autores (Comments to Authors): Comentários e sugestões para o autor melhorar a qualidade do artigo
Alguns comentários gerais e específicos:
- nome do LAPPIS: "Sofware" -> Software
- "30 months work on the SPB project" -> revisar Inglês
- "Nesse contexto, criamos uma plataforma baseada na integração e evolução de ferramentas livres existentes" -> este fragmento informa que os autores foram os desenvolvedores do Portal SPB. No entanto, o MP não participou do desenvolvimento com estudos, sobretudo considerando a visão ágil? E sobre a autoria da versão antiga, ou legado do SPB? Nada foi aproveitado de modo que a autoria do novo portal seja somente resultante deste projeto?
- A última frase do do primeiro parágrafo da introdução, que menciona sobre metodologias ágeis no governo, está desconexa do restante do parágrafo, que trata de software público. Sugiro revisar isso e melhor argumentar o contexto que os autores pretendem trazer para motivar o relato.
- "as metodologias de desenvolvimento de software livre ou ágeis, isto é, os métodos colaborativos e empíricos de desenvolvimento de software" -> esta equivalência não é adequada, pois assume-se que metodologias de desenvolvimento de software livre ou ágeis = métodos colaborativos e empíricos de desenvolvimento de software. Além disso, métodos empíricos, que acredito fazer alusão à aplicação da base de experimentação, parece não fazer sentido algum nesta sentença.
- "vários problemas técnicas." -> técnicos
- "nao estava mias sendo desenvolvido" -> mais
- Figura 1 é inserida antes de ser citada no texto e há um espaço em branco após a figura, fora do formato da SBC.
- "lançamos uma plataforma sem precedentes para
o governo brasileiro aplicar métodos colaborativos de desenvolvimento de software." -> qual a novidade em relação a outros conjuntos ou kits ou sets de ferramentas que podem ser utilizados para o desenvolvimento de software? Por que "sem precedente"? Qual o impacto prático do Portal SPB? Quais as estatísticas de uso? Qual é a sua motivação ou alvo?
- "desde o início da computação, a maioria dos desenvolvedores trabalhavam da maneira que agora identificamos como software livre" -> sentença confusa.
- "Essa forte concorrência entre os fornecedores traz benefícios para os usuários, porque dá melhores garantias em relação à evolução do sistema, levando a uma redução dos custos" -> isso se dá em um cenário de software livre ou FOSS? Existe esta concorrência tão significativa como no mercado de software tradicional/proprietário? Este trecho carece de melhores explicações.
- "Haviam outros requisitos" -> Havia
- "funcionaria corretamente se houver" -> se houvesse
- "Assim, no primeiro momento, desejamos disponibilizar uma versao inicial que poderia substituir o antigo portal SPB" -> mas já não foi disponibilizada? Ainda há módulos a serem construídos? E quanto aos estudos de usabilidade e ajustes pós-implantação?
- "Analisando todos esses requisitos, criamos o projeto de evolução do SPB baseado em ferramentas de software livre existentes. No entanto, a
integração de vários sistemas existentes que já foram implementados em diferentes linguagens de programação e arcabouços" ... "o portal SPB foi composto por mais de dez sistemas" -> como se deu a escolha destas ferramentas e/ou sistemas? Que estudos embasaram esta escolha? Foi realizado algum survey com a comunidade de desenvolvedores e usuários? Foi definido pelo cliente? Ou foi uma seleção por conveniência ou experiência da equipe? Isso não está claro.
- "Nós também estávamos convencidos de que seria impossível fornecer todas as funcionalidade com uma única ferramenta" -> como remediar este cenário? A comunidade de desenvolvedores não poderia participar da evolução do próprio portal? Uma vez que o portal tem por finalidade apoiar o desenvolvimento de software público e com foco em FOSS, por que não foi preparado para que a própria comunidade pudesse manter e evoluir a sua estrutura?
- "sem confundí-lo" -> confundi-lo
- "Temos 3 grandes" -> Temos três grandes
- "No novo portal SPB, cada software tem um conjunto padrao de páginas e ferramentas. Além de acessar as páginas de suporte (como FAQ e guia de instalação) dentro da plataforma" -> deve ser uma frase só que está quebrada em duas. Revisar.
- "sua evolução pelos resultados métricas" -> ?
- "cada análise métrica sao públicos" -> ?
- "informação do no portal SPB" -> do portal
- "a arquitetura ... re-projetada para fornecer uma navegação
transparente e alcançar usuários com perfis diferentes" -> o que se entende por navegação transparente? Isso não está claro. E que perfis de usuários são esses?
- "Um processo de harmonização foi empregado nos modelos de interação de cada ferramenta para reduzir a curva de aprendizado" -> o que se entende por estes modelos de interação? Novamente, não está claro e não permite ao leitor compreender como foi a avaliação com usuário.
- "Além disso, ferramentas de origens diferentes, que em muitos casos fornecem funcionalidades semelhantes, o que nos levou ao desenvolvimento de uma interface unificada." -> Reescrever.
- "dos ferramentas" -> das
- "Nós nos engajamos em seu desenvolvimento" -> ?
- A utilização de DevOps deveria ser melhor introduzida e explicada.
- "Como se pode ver, o projeto tinha muitos tipos diferentes de stakeholders que tinham de ser organizados e sincronizados." -> Quais? Por quê?
- "Essa dinâmica incentivamos aos demais alunos" -> Reescrever.
- "Entretanto, depois de meses de trabalho e mostrando resultados, eles deixaram de resistir aos métodos empíricos." -> que métodos são estes? O que os autores realmente entendem por este conceito?
- "... o mapeamento sistemático das ..." -> ?
- "Observe que este fluxo de trabalho proporcional a nós e aos envolvidos pelo governo brasileiro uma rastreabilidade completa de uma visao de alto nível de cada funcionalidade (requisito) até para o nível mais baixo (código)." -> Reescrever.
- A seção 8 não traz as conclusões frente ao objetivo do artigo, introduzindo diretamente apenas a listagem de lições aprendidas, sem de fato trazer um balanço sumarizado da experiência relatada. Além disso, muitas lições aprendidas não trazem novidade para a comunidade: quais são as lições específicas e que não foram reportadas até o momento?
- "No final do projeto, notamos que as habilidades desenvolvidas
pelos alunos estavam no estado da arte da prática de engenharia de software. Depois que o projeto terminou, tivemos membros da equipe que abraçaram com sucesso oportunidades em organizações públicas, privadas, nacionais e internacionais, além dos estudantes que entraram no empreendedorismo e abriram suas próprias empresas." -> este é um exemplo de trechos trazidos nas lições aprendidas com uma discussão rasa e informal, sem dados mais concretos sobre os pontos colocados. Qual o resultado concreto para os alunos envolvidos? Além disso, há diversos trabalhos sobre a relação academia-indústria e o relato não se preocupou em fazer menção. Para além de diversos trabalhos já publicados em toda a história do SBQS, sugiro este do SBES 2012: "Strategic Alignment between Academy and Industry: A Virtuous Cycle to Promote Innovation in Technology".
- "Nao aceitar más decisoes técnicas por questoes políticas." -> ao descrever essa "lição aprendida", os autores mencionam que o Colab foi reescrito para ser um "sistema de sistema". Acredito que este conceito deveria ser utilizado com mais atenção. Buscar trabalhos publicados pelo grupo da Elisa Nakagawa e José Maldonado (USP-SC). Ainda nesta lição, os autores apontam que "o MP os obrigou a aceitar uma questão técnica". Esta afirmação é forte. Uma vez que o relato é de autoria somente de um lado do projeto e se a lição é não aceitar, como proceder então com uma avaliação mais crítica? Acredito que o relato deveria envolver os dois lados do projeto (desenvolvedor e adquirente), especialmente neste caso (Portal SPB).
- "Considerar a sustentabilidade desde o início." -> o seguinte trecho desta lição precisa de mais explicações: "os técnicos MP constantemente evitavam essa responsabilidade". Outro ponto está no trecho "nós organizamos uma equipe de DevOps específica". Por que DevOps é colocado como uma bala de prata?
- "observamos que os técnicos MP sempre dependiam do nosso apoio para atualizar a plataforma, mesmo com toda a automaçao fornecida por nós. Ficamos tristemente com um sentimento de incerteza sobre o futuro da plataforma após o término do projeto." -> ajustar para "técnicos do MP". Além disso, este trecho não traz uma lição de caráter técnico (ver o uso de "tristemente"). Como se configurou este cenário? Qual o contexto? Por que a incerteza, se o projeto terminou? Quais os próximos passos? Novamente, a experiência carece de uma visão compartilhada entre as partes envolvidas.
- "da infra-estrutura plataforma" -> da infraestrutura da plataforma (?)
review

Reviewer 2
---

Resumo (Summary): Uma breve descrição do artigo
Apresentação da arquitetura, do processo de trabalho e das lições aprendidas no desenvolvimento de um portal de software público brasileiro.

Pontos Fortes (Paper Strengths): Quais os pontos positivos do artigo?
Trata-se de uma experiência em um grande projeto de bastante relevância que envolveu equipes mistas.

Pontos Fracos (Paper Weakness): Quais os aspectos negativos do artigo?
Não fica evidente a contribuição com a qualidade de software.
Algumas opiniões muito pessoais, há que ter uma certa impessoalidade em determinadas afirmações.
Algumas descobertas que já são de conhecimento comum.

Comentários para os Autores (Comments to Authors): Comentários e sugestões para o autor melhorar a qualidade do artigo
Realizar uma revisão de gramática geral.
Reescrever determinadas opiniões que estão muito pessoais, como por exemplo, "tristemente"
Acho que faltou um survey para coletar as impressões dos envolvidos neste processo. Acredito que as constatações ficariam menos subjetivas.

Reviewer 3
---
Resumo (Summary): Uma breve descrição do artigo
O artigo apresenta a "historia" do desenvolvimento da nova plataforma do Portal do Software Publico Brasileiro.

Pontos Fortes (Paper Strengths): Quais os pontos positivos do artigo?
- artigo bem escrito e super agradável de ler
- lições aprendidas mostra o grande valor da parceria academia-industria
- a apresentação do portal dos requisitos definidos às grandes funcionalidades desenvolvidas

Pontos Fracos (Paper Weakness): Quais os aspectos negativos do artigo?
- no resumo na introdução é comentado que foi utilizado práticas ageis. No entanto. nada é apresentado durante o artigo. Por exemplo, nenhuma lição aprendida sobre a aplicação da metodologia ágil é apresentada
- a ausência de uma parte mais técnica do ponto de vista de desenvolvimento e avaliação da qualidade do sistema. O artigo se limita a descriçãod das funcionaldiades.
- ausência da discussão sobre manutenção evolutiva.
- não se explica como foi avaliado o sistema (seria interessante para a comunidade SBQS)

Comentários para os Autores (Comments to Authors): Comentários e sugestões para o autor melhorar a qualidade do artigo
Trabalho muito bonito e muito interessante. Parabenizo toda a equipe pela realização. Como artigo científico sugiro que coloquem em valor as dificuldades técnicas de manutenção evolutiva de um software livre e o uso de metodologias ágeis na pratica. Terminei a leitura sem saber exatamente quais as práticas foram realmente aplicadas.