Dicas e Princípios Gerais

Use um exemplo, do começo ao fim, para ilustrar suas idéias.

Use como exemplo parte de um sistema real, não algo inventado. De preferência use algum software conhecido, aberto, parte da API de Java, algum exemplo clássico ou benchmark da área.

Considere usar, como exemplo, o bootstrap de sua ferramenta. Isso é elegante e ilustra a expressividade do método.

Além dos fatos, códigos, e modelos descrevendo e explicando o que você fez, é fundamental colocar discussões e reflexões sobre o que você fez, por exemplo justificando, avaliando, comparando, dizendo como se é possível ou como generalizar o que você fez.

Caracterize muito bem qual o problema que você está resolvendo (que domínios de aplicações, situações, contextos, linguagens, etc. são considerados por você e quais são deixados de fora) e qual o escopo da sua solução (o que ela resolve e o que ela não impacta).

Use bastante figuras para facilitar o entendimento das suas idéias.

Ao utilizar diagramas de classe como figuras, tente manter classes que são usadas em várias figuras numa mesma posição relativa (ex: a classe A deve estar sempre no canto superior esquerdo). Isso facilita a compreensão.

Quando num diagrama de classes houver herança, deixe sempre a super-classe (ou interface) em cima da classe que a implementa. Se estiver usando uma interface, preferir a notação "pirulito"(a bolinha) de UML.

Evitar ao máximo usar uma referência como se fosse uma palavra (Ex: "O trabalho descrito em [4] é muito interessante...").

Evite usar perguntas ao longo de seu texto.

Não é legal ir direto de uma seção a sua subseção, sem colocar texto.

Não se deve começar frases com "And".

Nos trabalhos relacionados, ao se referir aos trabalhos de outras pessoas, não utilize "works", mas sim "approaches".

Evite usar obviously ou coisas do tipo: é arriscado e arrogante. Se algo é obvio, isto não precisa ser apontado.

Ao se referir ao nome de uma classe durante o texto, não se esqueça de colocar o "the" antes (ex: "the MIDletController is important because...").

Cuidado com o uso excessivo do "However". Tente substituir por outras palavras como "Nevertheless".

Seguindo Mary Shaw, seu artigo deve responder claramente as seguintes perguntas:
- What, precisely, was your contribution?
  - What question did you answer?
  - Why should the reader care?
  - What larger question does this address?
- What is your new result?
  - What new knowledge have you contributed that the reader can use elsewhere?
  - What previous work (yours or someone else's) do you build on? What do you provide a superior alternative to?
  - How is your result different from and better than this prior work?
  - What, precisely and in detail, is your new result?
- Why should the reader believe your result?
  - What standard should be used to evaluate your claim?
  - What concrete evidence shows that your result satisfies your claim?

Veja também as perguntas que devem ser respondidas sobre sua tese.

Veja as seguintes dicas da Mary Shaw:
- The program committee looks for interesting, novel, exciting results that significantly enhance our ability to develop and maintain software, to know the quality of the software we develop, to recognize general principles about software, or to analyze properties of software.
- The program committee wants to know what is novel or exciting, and why. What, specifically, is the contribution? What is the increment over earlier work by the same authors? by other authors? Is this a sufficient increment, given the usual standards of subdiscipline?
- Define critical terms precisely. Use them consistently.
- Does your result fully satisfy your claims?
- Use verbs that show results and achievement, not just effort and activity.
- Program committees are very interested in your interpretation of prior work in the area. If you don't explain this, it's hard for the program committee to understand how you've added to our store of knowledge. You may also damage your credibility if the program committee can't tell whether you know about related work.
- Explain what your result is and how it works. Be concrete and specific. Use examples.
- A paper that simply reports on using numerous elements together is not enough, even if it's well-engineered. There must be an idea or lesson or model that the reader can take from the paper and apply to some other situation.
- The "slice of life" example is most likely to be convincing, especially if accompanied by an explanation of why the simplified example retains the essence of the problem being solved. Toy or textbook examples often fail to provide persuasive validation, (except for standard examples used as model problems by the field).
- Is the paper argued persuasively? What evidence is presented to support the claim? What kind of evidence is offered? Does it meet the usual standard of the subdiscipline? Is the validation related to the claim?
- If you performed a controlled experiment, explain the experimental design. What is the hypothesis? What is the treatment? What is being controlled? What data did you collect, and how did you analyze it? Are the results significant? What are the potentially confounding factors, and how are they handled? Do the conclusions follow rigorously from the experimental data?

Seguindo Mary Shaw, estruture o abstract da seguinte forma:
- Two or three sentences about the current state of the art, identifying a particular problem
- One or two sentences about what this paper contributes to improving the situation
- One or two sentences about the specific result of the paper and the main idea behind it
- A sentence about how the result is demonstrated or defended

Algumas padronizações úteis usadas em um livro editado por Ana Cavalcanti, Jim Woodcock e Augusto Sampaio:
- Displayed formulas can be used as part of text, unless they are a substantial unit like a law or a theorem.
- No punctuation is added to a displayed formula.
- No : is allowed to occur at the end of a line. We use :~
- Footnotes are to be used sparingly.
- Use active voice.
- For example, and the sort, should be used instead of i.e and e.g
- Similarly, we do not use etc.
- Titles of sections should not be capitalised, except for the first word.
- Sentences should not start with "but", identifiers, or citations.
- ( or --- do not start lines
- References in parenthesis to figures, tables, and so on, should be like (see Figure x).
- We typeset dashes using 3 hyphens, and no space to separate them from the surrounding words.
- Full stop is not used in captions

Para algumas conferência mais tradicionais não se utiliza contrações do tipo won't, doesn't e don't no lugar de will not, does not e do not, respectivamente. O recomendado é que se observe previamente publicações da conferência em que se pretende publicar e verificar se contrações são utilizadas.

-- PauloBorba - 14 Dec 2005 -- PauloBorba - 11 Mar 2004