O Simon Peyton Jones dá muitas dicas boas na sua apresentação (que tem um vídeo também) no
link
Veja algumas dicas para escrever artigos de qualidade:
- Leia muitos artigos de excelentes autores e conferências de alta qualidade; observe os estilos e imite!
- A clareza e elegância da escrita são essenciais para a aceitação do seu artigo. As frases abaixo refletem bem isso:
- "A man who has the knowledge but lacks the power to express it is no better off than if he never had any ideas at all." (Thucydides)
- "A computer scientist is equally a scientist and a writer -- expend the effort to learn the other half of your profession." (Dick Gabriel)
- Tenha muito cuidado com o foco do seu artigo:
- "Resist the temptation to describe every great idea you had while working on your project. Pick a primary message and communicate it well."
- "Give your paper a clear focus. It is far better to have a single idea that has been thoroughly discussed than a set of interesting but unfocused ideas."
- Dê grande importância à seção de trabalhos relacionados.
- Os trabalhos relacionados podem vir na introdução, nas conclusões, ou em uma seção em separado. Tal decisão depende do tipo de documento sendo escrito (artigo em conferencia, artigo em jornal, tese, etc.), e no caso de artigo pode sofrer influência do estilo dos demais artigos da conferência ou jornal. Mas o mais adequado é normalmente ter uma visão bem geral dos trabalhos relacionados no começo do documento, para estabelecer o estado da arte na área em foco, e uma seção antes das conclusões com as comparações mais detalhadas.
- Veja o exemplo de uma revisão minha (PauloBorba) que reforça o ponto acima: "The comparison is already broad enough, but it would be nice to have more details about each related work, not only mentioning what is achieved by the other works, but also effectively comparing their results with your results, explicitly saying and justifying (1) how your results go beyond the others, and (2) how your results are more (or less) adequate or useful than the others, in differente situations. In general, saying not only how the related work differs from yours, but also exploring and justifying the consequences of those differences. Having the related work section at the beginning of the paper, in fact, prevents this more detailed comparison, since the paper's approach is not so clear yet at the beginning. So it would be better to move this section to the end of the paper, and, if necessary, have only a brief overview of the main related approaches somewhere at the introduction.
- Responda as seguintes perguntas antes de escrever o seu artigo:
- que problemas reais os meus resultados resolvem?
- quais são os benefícios dos meus resultados?
- para quem?
- os resultados são inovadores, significativos e corretos?
- os benefícios são comprovados?
- os resultados têm alguma desvantagem?
- os resultados têm alguma limitação?
- quais são as justificativas e alternativas tentadas para os resultados?
- Dê preferência ao presente. O futuro só é adequado na parte de trabalhos futuros, mas normalmente dá para evitar e fica melhor no presente. Nunca use o futuro para se referir a uma seção posterior do artigo. O passado só é adequado para descrever como um experimento ou estudo foi realizado. Mas pode ser evitado também se o foco for descrever o procedimento do experimento.
- Antes de escrever o artigo, apresente suas idéias no GENTeS.
- Depois de apresentar e escrever pegue feedback de pelo menos dois colegas do grupo, do seu orientador (entregue o artigo a ele com pelo menos duas semanas de antecedência), e de alguém de fora do grupo (consegue-se isso entrando em contato, enviando artigos, e lendo e comentando os artigos de autores que trabalham em tópicos relacionados ao seu).
- Envie algumas das comparacoes no related work para um dos autores do artigo relacionado perguntando se a comporacao esta sendo feita corretamente. Desta forma podemos evitar fazer uma comparacao erronea.
- Dicas do Kent Beck:
- Deixar contribuição clara em "One startling sentence".
- Estruturação: introduction, problem, solution, defense, related work, conclusions.
- "I try to have four sentences in my abstract. The first states the problem. The second states why the problem is a problem. The third is my startling sentence. The fourth states the implication of my startling sentence."
Várias destas foram tirada de
"How to get your paper accepted at OOPSLA" (veja também
este outro texto sobre OOPSLA, mas muito útil para outros eventos também) e artigos similares discutidos no
GENTeS.
Writing Technical Articles - Dicas e VÁRIAS referencias sobre como escrever artigos. VÁRIOS guias de estilo, dicionários on-line, e outros artigos. VALE A PENA CONFERIR.
How to Write a Good Report - Dicas um tanto mais gerais que o último link (Writing Technical Articles). Contém também dicas de como avaliar trabalhos de outros.
- Dicas gerais para escrita de artigos e da própria tese:
- O título do trabalho não deve estar incompleto. Ele deve retratar o trabalho como um todo. Por exemplo:
- "Reporting problems when dealing with different binding times in Product Lines" (este título só fala sobre reportar problemas. No entanto, se este trabalho apresenta algum tipo de solução, o título deveria retratar algo sobre tal solução)
- Deixar claro o escopo do trabalho na introdução. Por exemplo:
- "… some variabilities found in Motorola mobile phone test cases …" (que tipo de variabilidades foram estudadas? E quais os tipos de testes estudados? O leitor pode criar uma expectativa grande sobre isso)
- "… some variabilities implemented by using if-else statements found in Motorola mobile phone integration test cases …" (aqui o leitor sabe o escopo do trabalho: variabilidades implementadas com if-else. Também sabe que tais variabilidades estão presentes em testes de integração. Assim, o leitor não criará expectativas sobre outras técnicas e outros tipos de testes)
- Nas conclusões, o escopo pode ser aberto!
- "Although we have discussed throughout the work that our approach targets if-else statements encountered in automated integration test cases, applying our work may also be useful in other domains and scenarios.". (Essa frase poderia estar nas conclusões do trabalho. Ela faz referência a outros domínios e cenários que o trabalho poderia também atacar, tais como outros tipos de testes - feature test - e outros mecanismos para implementar variabilidades, tais como compilação condicional)
- Manter a consistência durante todo o texto sobre os problemas, soluções e a avaliação de cada solução (fazer uma espécie de checklist). Por exemplo:
- Problema 1: escolha de mecanismos errados podem acarretar problemas de manutenção em linhas de produtos de software
- Solução 1: definição de um modelo que sugere mecanismos para o desenvolvedor
- Avaliação da Solução 1: avaliar a completude do modelo, sua abrangência de técnicas e critérios utilizados etc
- Problema 2: a falta de automatização na escolha dos mecanismos pode diminuir a produtividade do desenvolvedor
- Solução 2: ferramenta para automatizar o processo de recomendação de mecanismos
- Avaliação da Solução 2: cenários de uso da ferramenta, quais casos ela é útil e quais casos ela não é tão necessária
- Deixar claro porque utilizou-se as técnicas X, Y e Z. Não basta citar as técnicas. É importante deixar claro porque utilizou-se tais técnicas, por que outras não foram utilizadas, quais as vantagens e desvantagens de cada uma dessas técnicas e quais as implicações delas no trabalho. Por exemplo, em um trabalho onde a modularidade está sendo observada, poderíamos ter algo como: "Não utilizamos compilação condicional pois esta técnica causa sérios problemas de modularidade já bem conhecidos pela comunidade científica da área."
- Procurar desvantagens do seu trabalho
- Utilizar exemplos concretos. Por exemplo, em vez de utilizar passos de um caso de teste como...
- a -> b -> c, utilize passos reais, tais como
- Go to MMS menu -> Send Message -> Add attachment
- Ao descrever um trabalho relacionado, não utilizar a terminologia dele, mas sim, a terminologia que já vem sendo utilizada no seu trabalho. Por exemplo: no seu trabalho a solução trata-se de "mechanisms to implement product line variabilities". Um trabalho relacionado chama estes mecanismos de "solution domain analysis". Assim sendo, ao descrever este trabalho relacionado, não utilize a terminologia dele (solution domain analysis), mas sim a terminologia que você já vem utilizando durante todo o seu trabalho (mechanisms to implement product line variabilities). Em suma, não fazer um simples abstract do trabalho relacionado utilizando a terminologia dele!
- Sugestões adicionais:
- disponibilizar os fontes do artigo, as imagens e os resultados intermediários no SVN (seguir roteiro).
- Criar uma área no TWiki. Essa área pode ser usada tanto para colaborar durante a escrita quanto para disponibilizar detalhes adicionais do trabalho (e que podem ser consultados no processo de revisão).
- Dicas compiladas por Leopoldo Teixeira em 21/09/2010, baseadas em sua experiência com as revisões de Paulo.
--
LeopoldoTeixeira - 21 Sep 2010 --
MarcioRibeiro - 27 Apr 2009 --
RodrigoBonifacio - 25 Feb 2009 --
PauloBorba - 05 Jun 2007 --
PauloBorba - 01 Mar 2007 --
RohitGheyi - 29 Jul 2006 --
PauloBorba - 14 Jul 2006 --
PauloBorba - 13 Nov 2005 --
SergioSoares - 15 Set 2005 --
PauloBorba - 22 Mar 2004

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