confundir o leitor. Leia a introdução de artigos recentes de bons eventos. Em particular, note que normalmente é feita referências a trabalhos
científicos que trazem evidência do problema e tentativas de solução do mesmo.
- O artigo deve trazer evidência ou referenciar artigos que tragam evidência sobre as afirmações feitas. Por exemplo,
veja as seguintes afirmações da introdução:
“Existem técnicas de dimensionamento de software que podem ajudar no processo de estimativas,
dentre essas estão: Análise de Pontos de Função, Linha de Código e PCU Pontos de Caso de Uso.”
“Análise de Pontos de Função (APF) é uma técnica de medição de software que pode auxiliar no
processo de estimativas de software desde as fases iniciais do projeto quando ainda não se tem muitos
artefatos do mesmo, como código das funcionalidades e ou telas do sistema.”
Que artigos trazem evidência sobre o que é dito acima? Não há artigos que indicam problemas ou limitações
destas técnicas? Tudo isso tem que ser discutido.
- Falta também referências para conceitos básicos como “Feature Driven Development (FDD)”.
- Para tornar o artigo mais atrativo, seria interessante apresentar o problema de forma mais concreta. Vocês
conhecem a história de algum sistema desenvolvido com FDD, sem APF, que tenha atrasado, sido cancelado,
ou custado mais do que o previsto? Como eram feitas as estimativas nesse caso? O que sugere que o uso de
APF poderia ter evitado os problemas? Falar em detalhe sobre um projeto concreto onde o problema foi
observado aumenta bastante as chances do artigo ser aceito. Falar sobre dois projetos trazendo evidência de
que o problema foi observado também em outros projetos aumentaria mais ainda.
- “Partindo da premissa que é possível utilizar APF para realizar estimativas de softwares desenvolvidos com
FDD esse trabalho apresenta uma proposta de utilização conjunta das duas técnicas.” Isso não pode ser uma
premissa do trabalho. O artigo tem que argumentar e trazer evidência de que isso é possível.
- Pelo que eu entendi, há quase três páginas sobre introdução a pontos de função. Isso deveria ser menor.
Observe artigos recentes para ver normalmente quanto do artigo é dedicado a material de background.
Em particular, teria como introduzir os principais conceitos de APF usando um exemplo? Ajudaria bastante.
E só precisa discutir os conceitos de APF que vão ser úteis para o entendimento da solução que você vai
propor. Não precisa, e não deve, ser um tutorial sobre APF.
- O detalhamento dos componentes do processo parece bastante descritivo, agregando pouco valor. Isso é
útil para quem vai seguir o novo método, e deveria estar documentado em um apêndice online, um site do
método. No artigo, deve-se focar no que é essencialmente novo da solução apresentada, e porque você acha
que isso ajuda a resolver o problema, e é melhor do que possíveis alternativas. Não basta apresentar o que
é novo na solução apresentada, tem também que justificar porque você tomou cada uma das principais
decisões de projeto na elaboração do novo método. Usar exemplos para ilustrar as principais novidades
da solução proposta também ajuda bastante.
- O artigo também deve ter uma seção de trabalhos relacionados e outra de avaliação, trazendo alguma evidência
dos benefícios, limitações e problemas da solução apresentada. Leia e observe artigos recentes do SBES para
entender melhor o que o comitê de avaliação espera de um artigo.
- Revisar bem o texto. Erros repetidos como “Standishi Group” (o certo é Standish Group), principalmente
em uma referência básica para o artigo, podem gerar uma má impressão. -- PauloBorba - 2014-03-25
Edit | Attach | Print version | History: %REVISIONS% | Backlinks | Raw View | Raw edit | More topic actions
Copyright © 2008-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding TWiki? Send feedback