[sbqs2017] adding reviews from SBQS reviewers

Paulo Meireles
1 parent 31705109
Showing 1 changed file with 100 additions and 0 deletions Show diff stats
sbqs2017/reviews.txt
@@ -0,0 +1,100 @@
+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.
...	...	@@ -0,0 +1,100 @@
	1	+Reviewer 1
	2	+---
	3	+
	4	+Resumo (Summary): Uma breve descrição do artigo
	5	+
	6	+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.
	7	+
	8	+Pontos Fortes (Paper Strengths): Quais os pontos positivos do artigo?
	9	++ desenvolvimento de uma plataforma computacional de uso geral em larga escala capaz de gerar um nicho de desenvolvimento de software nacional
	10	+
	11	+Pontos Fracos (Paper Weakness): Quais os aspectos negativos do artigo?
	12	+- falta de embasamento teórico mais detalhado (incluindo referências)
	13	+- falta de visões compartilhadas entre equipe desenvolvedora e equipe consumidora (o viés é da equipe desenvolvedora)
	14	+- questões de qualidade de escrita (informal e de Português)
	15	+- lições aprendidas mais específicas do processo de desenvolvimento
	16	+
	17	+Comentários para os Autores (Comments to Authors): Comentários e sugestões para o autor melhorar a qualidade do artigo
	18	+Alguns comentários gerais e específicos:
	19	+- nome do LAPPIS: "Sofware" -> Software
	20	+- "30 months work on the SPB project" -> revisar Inglês
	21	+- "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?
	22	+- 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.
	23	+- "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.
	24	+- "vários problemas técnicas." -> técnicos
	25	+- "nao estava mias sendo desenvolvido" -> mais
	26	+- 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.
	27	+- "lançamos uma plataforma sem precedentes para
	28	+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?
	29	+- "desde o início da computação, a maioria dos desenvolvedores trabalhavam da maneira que agora identificamos como software livre" -> sentença confusa.
	30	+- "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.
	31	+- "Haviam outros requisitos" -> Havia
	32	+- "funcionaria corretamente se houver" -> se houvesse
	33	+- "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?
	34	+- "Analisando todos esses requisitos, criamos o projeto de evolução do SPB baseado em ferramentas de software livre existentes. No entanto, a
	35	+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.
	36	+- "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?
	37	+- "sem confundí-lo" -> confundi-lo
	38	+- "Temos 3 grandes" -> Temos três grandes
	39	+- "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.
	40	+- "sua evolução pelos resultados métricas" -> ?
	41	+- "cada análise métrica sao públicos" -> ?
	42	+- "informação do no portal SPB" -> do portal
	43	+- "a arquitetura ... re-projetada para fornecer uma navegação
	44	+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?
	45	+- "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.
	46	+- "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.
	47	+- "dos ferramentas" -> das
	48	+- "Nós nos engajamos em seu desenvolvimento" -> ?
	49	+- A utilização de DevOps deveria ser melhor introduzida e explicada.
	50	+- "Como se pode ver, o projeto tinha muitos tipos diferentes de stakeholders que tinham de ser organizados e sincronizados." -> Quais? Por quê?
	51	+- "Essa dinâmica incentivamos aos demais alunos" -> Reescrever.
	52	+- "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?
	53	+- "... o mapeamento sistemático das ..." -> ?
	54	+- "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.
	55	+- 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?
	56	+- "No final do projeto, notamos que as habilidades desenvolvidas
	57	+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".
	58	+- "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).
	59	+- "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?
	60	+- "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.
	61	+- "da infra-estrutura plataforma" -> da infraestrutura da plataforma (?)
	62	+review
	63	+
	64	+Reviewer 2
	65	+---
	66	+
	67	+Resumo (Summary): Uma breve descrição do artigo
	68	+Apresentação da arquitetura, do processo de trabalho e das lições aprendidas no desenvolvimento de um portal de software público brasileiro.
	69	+
	70	+Pontos Fortes (Paper Strengths): Quais os pontos positivos do artigo?
	71	+Trata-se de uma experiência em um grande projeto de bastante relevância que envolveu equipes mistas.
	72	+
	73	+Pontos Fracos (Paper Weakness): Quais os aspectos negativos do artigo?
	74	+Não fica evidente a contribuição com a qualidade de software.
	75	+Algumas opiniões muito pessoais, há que ter uma certa impessoalidade em determinadas afirmações.
	76	+Algumas descobertas que já são de conhecimento comum.
	77	+
	78	+Comentários para os Autores (Comments to Authors): Comentários e sugestões para o autor melhorar a qualidade do artigo
	79	+Realizar uma revisão de gramática geral.
	80	+Reescrever determinadas opiniões que estão muito pessoais, como por exemplo, "tristemente"
	81	+Acho que faltou um survey para coletar as impressões dos envolvidos neste processo. Acredito que as constatações ficariam menos subjetivas.
	82	+
	83	+Reviewer 3
	84	+---
	85	+Resumo (Summary): Uma breve descrição do artigo
	86	+O artigo apresenta a "historia" do desenvolvimento da nova plataforma do Portal do Software Publico Brasileiro.
	87	+
	88	+Pontos Fortes (Paper Strengths): Quais os pontos positivos do artigo?
	89	+- artigo bem escrito e super agradável de ler
	90	+- lições aprendidas mostra o grande valor da parceria academia-industria
	91	+- a apresentação do portal dos requisitos definidos às grandes funcionalidades desenvolvidas
	92	+
	93	+Pontos Fracos (Paper Weakness): Quais os aspectos negativos do artigo?
	94	+- 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
	95	+- 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.
	96	+- ausência da discussão sobre manutenção evolutiva.
	97	+- não se explica como foi avaliado o sistema (seria interessante para a comunidade SBQS)
	98	+
	99	+Comentários para os Autores (Comments to Authors): Comentários e sugestões para o autor melhorar a qualidade do artigo
	100	+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.
...	...