Agenda
WAMPS 2011 - VII Workshop
Anual do MPS
q 
q 
q 
q 
Como Escrever um Relato de
Experiência
q 
q 
Introdução
Estrutura do Texto de um Relato
Preparação do Texto
Ética e Plágio
Processo de Revisão de um Artigo
Apresentação de um Artigo
Gleison Santos
[email protected]
Nota: caso copiem o conteúdo de algum slide, por favor,
mantenham a referência à fonte original ou a esta
apresentação (o que for pertinente).
Obrigado.
Engenharia de Software e Qualidade de Software
Software faz parte do nosso dia a dia.
q 
q 
q 
Engenharia de Software e Qualidade de Software
Software faz parte do nosso dia a dia.
q  Há uma relação entre a qualidade dos produtos de software
e a qualidade dos processos de software utilizados para
construí-los [Fuggeta, 2000].
q  A implantação de um Programa de Qualidade começa pela
definição e implantação de um processo de software.
O principal objetivo da engenharia de software é, sem
dúvida, melhorar a qualidade do software.
(ROCHA et al., 2001)
q 
2
De forma geral, pesquisadores da Engenharia de Software
procuram melhores formas de desenvolver e avaliar
software.
Pesquisadores da Engenharia de Software são motivados
por problemas práticos.
Objetivos chave da pesquisa geralmente são qualidade,
custo e oportunidade dos produtos de software.
Necessidades do Negócio
Qualidade do produto
(SHAW, 2002)
Qualidade do processo
3
Processos, métodos, técnicas… e pessoas...
q 
q 
q 
q 
q 
q 
q 
q 
q 
q 
q 
4
Níveis de Maturidade MPS.BR
Em Otimização
A
Como melhorar a codificação? (o que é uma boa codificação?)
Como melhorar o teste de software? (o que é um bom teste?)
Como fazer boas modelagens? (o que é uma boa modelagem?)
O que leva alguém a usar um processo / método / técnica?
Quais os problemas que afetam a indústria de software?
Qual o retorno de investimento da Qualidade de Software?
Que fatores culturais afetam o desenvolvimento de
software?
Que fatores afetam a melhoria de processos de software?
O que as pessoas esperam de resultados da adoção de uma
técnica / método / processo?
Quais os benefícios da adoção de uma técnica / método /
processo?
...
gerência quantitativa)
Definido
C
Largamente
Definido
D
F
5
G
(inclui controle estatístico e
gerência quantitativa)
Gerenciado Gerência de Projetos (evolução)
(inclui controle estatístico e
Quantitativamente
B
E
(sem processos adicionais)
Parcialmente
Definido
Gerenciado
Parcialmente
Gerenciado
~
CMMI 5
~
CMMI 4
~
CMMI 3
~
CMMI 2
Gerência de Decisões
Desenvolvimento para Reutilização
Gerência de Riscos
Desenvolvimento de Requisitos
Projeto e Construção do Produto
Integração do Produto
Verificação / Validação
Avaliação e Melhoria do Processo Organizacional
Definição do Processo Organizacional
Gerência de Reutilização / Gerência de Recursos
Humanos / Gerência de Projetos (evolução)
Medição / Gerência de Configuração / Aquisição /
Garantia da Qualidade / Gerência de Portfólio de Projetos
Gerência de Requisitos
Gerência de Projetos
1
Pesquisa x Ciência
q 
Pesquisa
Objetivos de Pesquisa
q 
Tipos de Pesquisa
–  Fazer uma contribuição para a Ciência
–  Nem toda pesquisa é feita da mesma forma
–  Responder a uma pergunta
–  Os métodos de pesquisa são bem diversos dependendo do
campo de conhecimento
»  de interesse para a comunidade científica
»  ainda não respondida anteriormente
»  de relevância para o interesse social
q 
q 
Mestre: Título de qualificação técnico-científica
–  domina as técnicas de investigação
–  A parte mais difícil é encontrar o problema
–  produziu um resultado novo (ou relevante)
Objetivo da Ciência: resolver problemas
–  comunicou seus resultados de forma efetiva
–  Qual o problema que você está resolvendo?
–  Comece de um desafio prático
–  Extraia daí um problema teórico
q 
Mestre X Doutor
–  tempo de investigação
–  Certifique-se que o problema é
»  relevante
–  profundidade da pesquisa
»  não-resolvido
–  qualidade da formação
»  resolvível
Fonte: Santoro, F., Notas de Aula – Apresentação do Metodologia da Pesquisa Científica 2010.2,
7
Programa de Pós-Graduação em Informática - UNIRIO
Divagações…
q 
O que dá para publicar?
Uma tese de doutorado não é uma dissertação de mestrado
que não é uma monografia de pós-graduação que não é um
projeto de final de curso de graduação.
–  O inverso também se aplica.
q 
Fonte: Santoro, F., Notas de Aula – Apresentação do Metodologia da Pesquisa Científica 2010.2,
8
Programa de Pós-Graduação em Informática - UNIRIO
q 
q 
q 
q 
q 
Um trabalho para uma empresa não é um trabalho de
pesquisa.
q 
–  Gostaríamos que todo trabalho de pesquisa fosse aplicado a
empresas. Nem sempre isso é possível por N fatores.
Projeto Final de Graduação
Projeto Final de Pós-graduação
Dissertação de Mestrado
Tese de Doutorado
Experiências em Empresas e de Empresas
Cuidado com o foco, com a forma de descrição e na
descrição das reais contribuições do trabalho
–  Infelizmente...
q 
No entanto, Relatos de Experiências são úteis para
demonstrar como a teoria de Engenharia de Software ‘se
comporta’ em um ambiente real.
–  Aprendemos com os erros e acertos nossos e de outros!
–  Quanto mais rica e mais diferente a experiência, maiores são
as chances de publicação.
10
O que dá para publicar?
q 
Relatos de Experiência
O que posso publicar?
q 
–  A audiência do evento é importante para determinar o que é
relevante em cada contexto
q 
q 
Fonte: Santoro, F., Notas de Aula – Apresentação do Metodologia da Pesquisa Científica 2010.2,
Programa de Pós-Graduação em Informática – UNIRIO.
Onde publicar?
–  A chamada de trabalhos é importante para entender o tipo de
trabalho que se espera dos autores
q 
Devem contar uma história informativa e como ela se
reflete em situações mais gerais
Não entre em detalhes irrelevantes sobre o experimento
Por que devo publicar?
–  Troca de experiências
–  Aprendizado em Engenharia de Software vem muitas vezes do
uso das técnicas e observações do estado da prática
11
Chamada de Trabalhos do SBQS
q  Relatos de Experiência: Artigos de alta qualidade
descrevendo e analisando a aplicação de processos,
métodos ou ferramentas de qualidade de software,
contextualizando a experiência e mostrando os resultados
obtidos e lições aprendidas, em uma experiência prática
com contribuição para a indústria de software.
q  Trabalhos técnicos: artigos de alta qualidade descrevendo
resultados inéditos sobre de pesquisa na área de qualidade
de software com contribuição acadêmica.
12
2
Um bom artigo de pesquisa
Estrutura do Texto
Um bom artigo de pesquisa deve responder a um número de
questões:
q  O que, precisamente, você alega ser a sua contribuição?
q 
–  Em geral, não há uma regra, mas a estrutura abaixo segue o
senso comum em uso
–  Que questões você respondeu?
–  Por que o leitor deveria se importar?
–  Não há muitas possibilidades de inovar nesta organização.
–  De que questões maiores (larger questions) ele trata?
q 
Qual é o seu novo resultado?
–  Qual novo conhecimento você gerou que o leitor pode utilizar em outra
situação?
q 
Estrutura Básica:
–  Introdução
–  Em que trabalho anterior (seu ou de outros) você se baseou? Em que
você provê uma alternativa superior?
–  Sessões Pertinentes
–  Como o seu resultado é diferente ou melhor que este trabalho anterior?
–  Referências
–  Conclusão
–  Qual, precisamente e em detalhes, é o seu novo resultado?
q 
A estrutura de um artigo científicio segue um padrão prédeterminado
Por que o leitor deve acreditar no seu resultado?
–  Que padrão deve ser utilizado para avaliar sua afirmação?
–  Que evidência concreta mostra que o seu resultado satisfaz sua
afirmação?
13
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 2003.
Estrutura do Texto
q 
14
Título
Itens comuns na estrutura do texto:
q 
–  Título
–  Autores
q 
–  Abstract / Resumo
q 
–  Introdução
O título deve ser curto e indicativo do trabalho que será
apresentado
Escolha um título que valorize o trabalho, mas cuidado para
não ser arrogante ou presunçoso
Evite o uso de perguntas e termos em inglês
–  Vale para o texto como um todo
–  Revisão da Literatura
–  Ninguém garante que as perguntas vão ser respondidas (e, em
geral, você não irá respondê-las. Acredite…)
–  Trabalhos Similares
–  Proposta / Descrição da Experiência
–  Lições Aprendidas
–  Conclusões / Considerações Finais
–  Agradecimentos
Implantação do Nível F do MR-MPS Combinando Características do Processo
Unificado com Práticas SCRUM
–  Referências Bibliográficas
–  Anexos e Apêndices
15
Autores
q 
Abstract
Deve-se listar os envolvidos com o trabalho
q 
–  Em geral, a ordem dos autores indica o esforço para a
elaboração do artigo e/ou o envolvimento no trabalho relatado
–  Quando se descreve um relato de experiência em uma empresa
é comum incluir as pessoas chave da empresa como autores
mesmo quando elas não participam da escrita do texto
q 
q 
q 
q 
»  Isso não é uma regra, no entanto
q 
16
–  O principal problema analisado
Para cada autor, deve-se indicar a filiação
–  Um esboço da solução utilizada
–  Pode haver múltipla filiação
–  As conclusões alcançadas
–  Deve-se indicar o e-mail de contato dos autores
q 
Tatiane
Silva1,
Rogério
Magela1,
1Athenas
Gleison
Santos2,
Natália Chaves Lessa
Não é o trailer de um filme (não deixe o espectador
imaginando qual será o final)
“Venda” seu trabalho no abstract
Se você não conseguir resumir sua contribuição em meia
página algo está muito errado no seu trabalho
Não entra revisão bibliográfica
Inclua sempre no abstract
Schots3, Ana
Regina
Rocha3
Engenharia de Software – Av. Rio Branco, 12, 14º andar, Centro
CEP 20090-000 – Rio de Janeiro – RJ – Brasil
2
Programa de Pós-Graduação em Informática – Universidade Federal do Estado do Rio de Janeiro (UNIRIO) - Av. Pasteur
458, Urca, CEP 22290-240 – Rio de Janeiro, RJ
3
COPPE/UFRJ – Universidade Federal do Rio de Janeiro – Caixa Postal 68511 – CEP 21945-970 – Rio de Janeiro, Brasil
{tatiane, magela}@athenassoftware.com.br, [email protected], {natalia,
17
darocha}@cos.ufrj.br
Fundamental
–  Dizer qual é o problema
–  Mostrar que vale a pena resolver o problema
–  Mostrar como você resolveu o problema
Wazlawick, 2007
Fonte: Santoro, F., Notas de Aula – Apresentação do Metodologia da Pesquisa Científica 2010.2,
Programa de Pós-Graduação em Informática – UNIRIO. apud Wazlawick, 2007
3
Abstract e Resumo
q 
Todo artigo deve ter um resumo
Introdução
q 
–  As vezes, é necessário ter versões em inglês e em português
q 
q 
O conteúdo do abstract deve ser o mesmo do resumo
–  Note que às vezes a estrutura da frase em português e em
inglês não é igual e adaptações tem que ser feitas
–  Não use o tradutor automático para gerar a versão do abstract
Abstract. There is no software process model adequate to any organization and during all the time. This
paper presents the evolution of the software development process of Athenas Software. This process first
version was based on what would become the Unified Process and now it has evolved to support SCRUM
agile practices and the MPS.BR Reference Model Level F practices.
Resumo. Não existe um único modelo de processo de software que seja adequado a todo o tipo de empresa
nem por todo o tempo. Este artigo apresenta a evolução do processo de desenvolvimento de software da
Athenas Software desde a sua primeira versão baseada no que viria se tornar o Processo Unificado até o
momento atual onde se alinham, também, práticas ágeis do SCRUM e as práticas associadas ao Nível F do
Modelo de Referência do MPS.BR.
19
Tipos de questões de pesquisa em Engenharia
de Software
q 
Contextualize rapidamente o tema de pesquisa (não inicie
nos primórdios)
Apresente os objetivos, metodologia, justificativa,
resultados esperados, limitações e estrutura da dissertação
Caracterize o problema que você descreverá e a questão
que deseja discutir.
Fonte: Santoro, F., Notas de Aula – Apresentação do Metodologia da Pesquisa Científica 2010.2,
Programa de Pós-Graduação em Informática – UNIRIO. apud Wazlawick, 2007
q 
Termine sempre apresentando a estrutura do artigo.
Este artigo possui o objetivo de apresentar como o processo da Athenas evoluiu ao longo do tempo e
as melhorias e lições aprendidas identificadas pela empresa durante esta evolução. Na Seção 2, um breve
histórico da evolução do processo de desenvolvi­mento é apresentado, bem como algumas características
peculiares da empresa. As ca­racterísticas do atual processo e as ferramentas utilizadas são discutidas nas
Seções 3 e 4, respectivamente. Por fim, na Seção 5 são apresentadas as considerações finais junta­mente
com resultados obtidos com a melhoria do processo e algumas lições aprendidas.
Tipos de questões de pesquisa em Engenharia
de Software
Tipo de Questão
Exemplos
Tipo de Questão
Exemplos
Método ou meio de
desenvolvimento
•  Como podemos fazer / criar / modificar / evoluir (ou
automatizar fazendo) X?
•  Qual é a melhor maneira de fazer/criar/modificar/evoluir X?
Método ou meio de
desenvolvimento
•  Como podemos fazer / criar / modificar / evoluir (ou
automatizar fazendo) X?
•  Qual é a melhor maneira de fazer/criar/modificar/evoluir X?
Método para análise
ou avaliação
•  Como posso avaliar a qualidade / corretude de X?
•  Como eu escolho entre X e Y?
Método para análise
ou avaliação
•  Como posso avaliar a qualidade / corretude de X?
•  Como eu escolho entre X e Y?
Design, avaliação ou
análise de uma
instância particular
•  O quão bom é Y? Qual é a propriedade X do artefato/
método Y?
•  O que é um (melhor) design, implementação, manutenção
ou adaptação para a aplicação X?
•  Como X se compara a Y?
•  Qual é o estado atual de X / prática de Y?
Design, avaliação ou
análise de uma
instância particular
•  O quão bom é Y? Qual é a propriedade X do artefato/
método Y?
Produzem
métodos
de
•  O que é um (melhor)
design,
implementação,
manutenção
ou adaptação desenvolvimento
para a aplicação X? ou análise que
•  Como X se compara
a
Y?
os autores investigaram em uma
•  Qual é o estado
atual de
X / prática
de que
Y?
situação
(setting),
mas
Generalização ou
caracterização
•  Dado X, qual será Y (necessariamente)?
•  O que, exatamente, nós entendemos por X? Quais são suas
características importantes?
•  Qual é um bom modelo formal/experimental para X?
•  Quais são as variedades de X, como estão relacionadas?
Generalização ou
caracterização
podem ser
•  Dado X, qualpresumivelmente
será Y (necessariamente)?
•  O que, exatamente,
nósem
entendemos
por X? Quais são suas
aplicados
outros contextos.
características importantes?
•  Qual é um bom modelo formal/experimental para X?
•  Quais são as variedades de X, como estão relacionadas?
Estudo de viabilidade
ou exploratório
•  X realmente existe, e, se sim, como ele se parece?
•  É possível, realmente, realizar (accomplish) X?
Estudo de viabilidade
ou exploratório
•  X realmente existe, e, se sim, como ele se parece?
•  É possível, realmente, realizar (accomplish) X?
21
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 2003.
Tipos de questões de pesquisa em Engenharia
de Software
22
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 2003.
Tipos de questões de pesquisa em Engenharia
de Software
Tipo de Questão
Exemplos
Tipo de Questão
Exemplos
Método ou meio de
desenvolvimento
•  Como podemos fazer / criar / modificar / evoluir (ou
automatizar fazendo) X?
•  Qual é a melhor maneira de fazer/criar/modificar/evoluir X?
Método ou meio de
desenvolvimento
•  Como podemos fazer / criar / modificar / evoluir (ou
automatizar fazendo) X?
•  Qual é a melhor maneira de fazer/criar/modificar/evoluir X?
Método para análise
ou avaliação
•  Como posso avaliar a qualidade / corretude de X?
•  Como eu escolho entre X e Y?
Método para análise
ou avaliação
•  Como posso avaliar a qualidade / corretude de X?
•  Como eu escolho entre X e Y?
Design, avaliação ou
análise de uma
instância particular
•  O quão bom é Y? Qual é a propriedade X do artefato/
método Y?
•  O que é um (melhor) design, implementação, manutenção
ou adaptação para a aplicação X?
•  Como X se compara a Y?
•  Qual é o estado atual de X / prática de Y?
Design, avaliação ou
análise de uma
instância particular
•  O quão bom é Y? Qual é a propriedade X do artefato/
surgem explicitamente dos
método Y?
exemplos
apresentados
nos
•  O que é um
(melhor) design,
implementação,
manutenção
artigos.
ou adaptação
para a aplicação X?
•  Como X se compara a Y?
•  Qual é o estado atual de X / prática de Y?
Generalização ou
caracterização
•  Dado X, qual será Y (necessariamente)?
•  O que, exatamente,
nós entendemos
Lida explicitamente
compor
umX? Quais são suas
características
importantes?
sistema,
prática, design ou outro
•  Qual é um bom
modelo
formal/experimental
instância de um sistema ou para X?
•  Quais são as variedades de X, como estão relacionadas?
Generalização ou
caracterização
•  Dado X, qual será Y (necessariamente)?
•  O que, exatamente, nós entendemos por X? Quais são suas
características importantes?
•  Qual é um bom modelo formal/experimental para X?
•  Quais são as variedades de X, como estão relacionadas?
Estudo de viabilidade
ou exploratório
•  X realmente
existe, industrial
e, se sim, como
ele se parece?
prática
a comparações
•  É possível, analíticas
realmente, de
realizar
(accomplish)
X?
designs
alternativos.
Estudo de viabilidade
ou exploratório
•  X realmente existe, e, se sim, como ele se parece?
•  É possível, realmente, realizar (accomplish) X?
método. Varia de narrativas sobre
23
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 2003.
Generalizações e caracterizações
24
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 2003.
4
Tipos de questões de pesquisa em Engenharia
de Software
Resultados do ICSE 2002
Tipo de Questão
Exemplos
Método ou meio de
desenvolvimento
•  Como podemos fazer / criar / modificar / evoluir (ou
automatizar fazendo) X?
•  Qual é a melhor maneira de fazer/criar/modificar/evoluir X?
Método para análise
ou avaliação
•  Como posso avaliar a qualidade / corretude de X?
•  Como eu escolho entre X e Y?
Design, avaliação ou
análise de uma
instância particular
•  O quão bom é Y? Qual é a propriedade X do artefato/
método Y?
•  O que é um (melhor) design, implementação, manutenção
ou adaptação para a aplicação X?
Lidam com uma questão de uma
•  Como X se compara a Y?
maneira
•  Qual é o estado
atual decompletamente
X / prática de Y? nova.
Generalização ou
caracterização
•  Dado X, qual será
Y (necessariamente)?
diferente
daqueles que melhoram
•  O que, exatamente, nós entendemos por X? Quais são suas
algo previamente definido.
características importantes?
•  Qual é um bom modelo formal/experimental para X?
•  Quais são as variedades de X, como estão relacionadas?
q 
•  X realmente existe, e, se sim, como ele se parece?
•  É possível, realmente, realizar (accomplish) X?
q 
Estudo de viabilidade
ou exploratório
Em geral têm uma categoria
25
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 2003.
Revisão da Literatura
q 
q 
q 
(resultados baseados nos abstracts)
–  Definição clara do problema resolvido.
–  Explicação de como a resposta ajudará a resolver um problema
importante em engenharia de software.
Ao longo da história da ES, os tipos de questões mudam
quando a maturidade de um assunto aumenta.
26
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 2003.
Revisão da Literatura
Concentre-se em apresentar as definições e resultados da
literatura que sejam relevantes para seu objetivo
Lembre: não é um tratado sobre a história da área de
pesquisa e não é um inventário de tudo o que você leu
Organização do capítulo
q 
Opinião x Fatos
–  Uma revisão da literatura apresenta ‘fatos’ sobre o assunto.
–  Não é possível incluir opiniões pessoais no texto.
»  Se quiser, utilize outros autores para defender o seu ponto
de vista.
–  Revisão dos principais conceitos básicos
–  Revisão do estado da arte
–  Organize o texto por idéias e não por autores
q 
Importante:
»  Tudo deve ter referência
Cite:
q 
Em um relato de experiência, nem sempre a revisão da
literatura necessita ser ser muito abrangente ou complexa,
mas sempre é bom ter uma seção específica
q 
Às vezes é possível incluir uma breve revisão da literatura
na introdução do artigo
–  periódicos e eventos relevantes
–  obras recentes
–  obras clássicas na área
–  Principalmente quando o espaço é curto
–  Ou quando o assunto é de pleno conhecimento da audiência
»  Por exemplo, a estrutura do MPS.BR em artigos para o
WAMPS
Fonte: Santoro, F., Notas de Aula – Apresentação do Metodologia da Pesquisa Científica 2010.2,
27
Programa de Pós-Graduação em Informática – UNIRIO. apud Wazlawick, 2007
Onde achar artigos?
q 
q 
Trabalhos Similares
Anais anteriores do SBES, SBQS e WAMPS
Portal de Periódicos Capes: http://periodicos.capes.gov.br/
O que foi feito antes? Como seu trabalho é diferente ou
melhor?
–  Verifique se sua universidade provê acesso de qualquer computador do campus
–  Em que tecnologia já existente o seu trabalho se basea?
–  Verifique se há possibilidade de acesso remoto através de proxy
q 
28
–  Compendex (http://www.engineeringvillage.com/)
–  A que tecnologia existente ou pesquisa anterior sua pesquisa
provê uma alternativa superior?
–  IEEE Explore (http://ieeexplore.ieee.org/)
–  O que é novo comparado ao seu trabalho anterior?
–  Scopus (http://www.scopus.com/)
–  Que alternativas outros pesquisadores perseguiram e como o
seu trabalho é diferente ou melhor?
Maximizando resultados, minimizando esforço
q 
Conhecimento cresce incrementalmente.
–  Se você não explicar como seu trabalho está relacionado com
outros fica complicado saber o que você adicionou de novo.
–  Não dizer se você tem conhecimento de trabalhos relacionados
pode afetar a sua credibilidade...
29
30
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 2003.
5
Tipos de resultados em Engenharia de Software
O que foi feito antes? Como seu trabalho é diferente ou
melhor?
q 
Smith [36] e Jones [27] trabalharam na
galopagem.
Smith [36] tratou da galopagem usando
‘blitzing’, enquanto Jones [27] adotou
uma abordagem ‘flitzing’.
A abordagem ‘blitzing’ de Smith para a
galopagem [36] atingiu 60% de
cobertura [39]. Jones [27] atingiu 80%
com o uso de ‘flitzing, mas apenas para
casos livres de ponteiros [16].
q 
Coloque suas afirmações cuidadosamente
Garanta que todas as afirmações sejam fundamentadas
Não adianta apenas fazer uma análise teórica de uma
questão. É necessário mostrar o que esta análise melhora
em relação às anteriores
Uma teoria não testada na prática não vale muito
q 
Artigos sobre comparação entre métodos
q 
q 
q 
Compare:
O problema de galopar tem atraído muita
atenção [3,8,10,18,26,32,37].
Proposta / Descrição da Experiência
A abordagem ‘blitzing’ de Smith para
a galopagem [36] atingiu 60%
de cobertura [39]. Jones [27]
atingiu 80% com o uso de
‘flitzing, mas apenas para casos
livres de ponteiros [16].
Este trabalho modificou a
abordagem ‘blitzing’ para utilizar
a representação de kernel do
‘flitzing’ e obteve uma cobertura
de 90% ao relaxar a restrição de
forma que apenas estruturas
cíclicas de dados fossem
proibidas.
–  Já foram feitos MUITAS vezes
–  As vezes são MUITO MAL feitos
–  Um artigo deste tipo deve colocar muito bem as métricas para
que os resultados possam ser repetidos por experiências
independentes
Fonte: Santoro, F., Notas de Aula – Apresentação do Metodologia da Pesquisa Científica 2010.2,
Programa de Pós-Graduação em Informática - UNIRIO
31
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 2003.
Tipos de resultados em Engenharia de Software
32
Tipos de resultados em Engenharia de Software
O que é novo aqui?
q  Os avaliadores sabem o que é novo, excitante e porquê.
–  Qual é a sua contribuição? O que foi feito além de trabalhos
anteriores seus e de outros? O que foi feito além é suficiente
(dado os padrões habituais da subdisciplina)?
“Try not. Do, or do not. There is no try.” Yoda –  É melhor você explicar do que deixar o revisor advinhar...
–  Use verbos que mostrem resultados, não só esforço e atividade.
q 
Compare:
Eu resolvi complementamente e genericamente...
Eu trabalhei em melhorar a galopagem (ou
contribuí para, participei em, ajudei com).
Eu mostrei a viabilidade de compor ‘blitzing’
com ‘flitzing’.
Eu melhorei significativamente a acurácia do
detector padrão (ou provei, demonstrei,
criei, estabeleci, encontrei, desenvolvi).
Eu trabalhei em galopagem (ou
estudei, investiguei,
procurei, explorei).
Eu automatizei a produção de
tabelas ‘flitz’ a partir das
especificações.
Com uma aplicação inovadora da
transformação ‘blivet’, eu
melhorei 10% da velocidade e
15% na cobertura em relação ao
método padrão.
33
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 2003.
Tipos de resultados em Engenharia de Software
34
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 2003.
Tipos de Validação em Engenharia de Software
Tipo de Validação
Exemplos
Análise
•  Eu analisei meu resultado e, através de uma análise
rigorosa, achei satisfatório, por exemplo, ...
Avaliação
•  Dado um critério estabelecido, meu resultado…
Experiência
•  Meu resultado foi utilizado em exemplos reais por alguém
além de mim, e as evidências de sua corretude/utilidade/
efetividade é…
–  Se sua contribuição é principalmente a síntese ou integração de
outros resultados ou componentes, seja claro sobre porque a
síntese em si é uma contribuição.
Exemplo
•  Aqui há um exemplo de como funciona em...
Persuasão
•  Eu pensei muito sobre isso e acredito apaixonadamente
que…
–  Se seu artigo é principalmente um relato de experiência aplicando
resultados de pesquisa a um problema prático, diga o que o leitor
pode aprender com a experiência.
Afirmação forte
•  Nenhuma tentativa séria de avaliar o resultado.
O que, precisamente, é o resultado?
–  Se você introduzir um novo modelo, seja claro sobre o seu poder.
–  Se você introduzir uma nova métrica, defina-a precisamente.
–  Se você introduzir um novo estilo arquitetural, padrão de projeto
(ou similar), trate-o como se fosse uma nova generalização ou
modelo.
–  Se uma ferramenta tem um papel importante no seu artigo, qual
é este papel?
q  Uma boa pesquisa requer não só um resultado, mas também uma
evidência convincente que o resultado é adequado/bom.
–  Se a implementação de um sistema tem um papel importante no
seu artigo, qual é este papel?
35
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 2003.
36
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 2003.
6
Resultados do ICSE 2002
q 
Importante:
Métodos
Tipo
Descrição
Objetivo
Característica
Etnografia
Estudo descritivo e
interpretativo de um
grupo ou comunidade
Fazer com que outros
entendam como o
grupo produz suas
teorias e culturas
Pesquisador deve
possuir grande
interação com os
participantes
Pesquisa-ação
Estratégia de condução de
pesquisa aplicada de
natureza participativa
Promover melhorias
para a situação
Contribuir para o
conhecimento
científico
Pesquisador interfere
no objeto de estudo
com o propósito de
melhorá-lo
Estudo de Caso
Investigação empírica que
observa um fenômeno
dentro de um contexto
real
Investigar uma
entidade ou um
fenômeno dentro de
um espaço de tempo
específico
Há vários tipos:
descritivo,
interpretativo,
avaliativo etc.
Grounded Theory
Conjunto de
procedimentos
sistemáticos de coleta e
análise de dados para
gerar e validar teorias
Entender
profundamente os
dados
Gerar teorias a partir
dos dados
A fundamentação
dos dados empíricos
faz com que a
pesquisa fique
próxima da realidade
(resultados baseados nos abstracts)
–  Os tipos mais bem sucedidos de validação foram baseados em
análise e em experiências ‘do mundo real’.
–  Exemplos bem escolhidos também foram um sucesso
–  Persuasão não foi persuasiva.
–  Revisores de artigo procuram por evidências sólidas para apoiar
seus resultados, não basta você achar que suas idéias funcionam.
37
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 2003.
Estudos de Caso
q 
q 
q 
q 
Questão de pesquisa
Investiga um fenômeno contemporâneo
Contexto de vida real, em que as fronteiras não são
claramente evidentes.
Oferece entendimento
Fonte: SCHOTS, N. C. L., Uma Abordagem para a Identificação de Causas de Problemas
Utilizando Grounded Theory. Dissertação de Mestrado. COPPE/UFRJ, 2010.
Estudos de Caso
Tipos de Estudos de Caso
q  Exploratórios
–  Usado em investigações iniciais de alguns fenômenos
–  Visam derivar novas ideias e hipóteses e formular teorias
q 
Descritivos
q 
Explanatório
–  Profundo (como e por que)
–  Revelador (demonstrar causas-efeito)
38
–  Descrevem uma situação ou fenômeno
–  Procuram uma explanação de uma situação ou problema
–  Na maior parte, mas não necessariamente, na forma de uma
relação causal
q 
Confirmatórios
–  Utilizados para testar/refutar teorias
–  Usado na escolha entre teorias concorrentes
Fonte: Yin, R. K. (2002) Case Study Research: Design and Methods. Sage, Thousand Oaks, CA.
Estudos de Caso
q 
Requisitos
Fonte: RUNENSON, P. e HÖST, M., Guidelines for conduction and reporting case study research in
software engineering, Empirical Software Engineering (2009) 14:131-164.
Estudos de Caso
q 
–  Interessada em como e porque um fenômeno ocorre
»  Deriva uma proposta de estudo que afirma
q 
Ø 
O que o estudo mostrará
Ø 
Guiar seleção de casos
Ø 
Tipos de dados a serem coletados
Escolhas
q 
–  Escolha de casos é fundamental para a pesquisa
Diferentes fontes de dados são usadas
Possuem um papel central para análises dentro de um caso
Entrevistas e observação
Coleta de dados alinhada a uma unidade de análise bem
definida
»  Escolha adequada garante que o fenômeno será focado
»  Empresa, projeto, equipe, desenvolvedor, produto
específico, etc.
Tipo de estudo mais adequado quando o reducionismo de
experimentos controlados é inadequado
–  O contexto possui um papel no fenômeno
–  São esperados amplos efeitos
–  Levam tempo para aparecer
–  Amostra utilizada não é aleatória, sendo escolhida
–  Objetivo de escolher casos relevantes e representativos
q 
Fonte: EASTERBROOK et al., Selecting Empirical Methods for Software Engineering Research.
Baseado em apresentação cedida por Rafael Cunha e Daniel Tadeu Castelo Branco.
Dados qualitativos
– 
– 
– 
– 
–  Questão de pesquisa bem definida
Sua maior fraqueza é que a coleta de dados e análise são
abertas a interpretações e propiciam a formação de viés do
pesquisador.
Fonte: EASTERBROOK et al., Selecting Empirical Methods for Software Engineering Research.
Baseado em apresentação cedida por Rafael Cunha e Daniel Tadeu Castelo Branco.
7
Validade dos Estudos
q 
q 
Tipos de resultados em Engenharia de Software
Convencimento dos leitores de que o estudo é válido
Nenhum estudo é perfeito e totalmente generalizável em
todos os contextos:
–  O leitor deve ficar ciente disso
–  O levantamento das ameaças à validade aumenta a confiança
do leitor nos resultados (ou não…)
Validade de
construção
Validade
interna
• Verifica ser as
construções
teóricas foram
interpretadas e
medidas
corretamente
• Ocorre quando
variáveis coletadas
não correspondem
com o significado
dos termos
teóricos
• Exemplo:
Eficiência
• Concentra-se
em verificar se
o resultado está
de acordo com
os dados
• Exemplo: Uso
errado de
análises
estatísticas
Validade externa
• Concentra-se na
generalização do
resultado
• Depende da
natureza da
amostragem
Confiabilidade
• Verifica se o
experimento é
replicável
• Viés
Tipo Resultado
Exemplos
Procedimento ou
técnica
•  Jeito novo ou melhor de fazer alguma tarefa, como design,
implementação, manutenção, medidas, avaliação, seleção de
alternativas.
Modelo qualitativo
ou descritivo
•  Estrutura ou taxinomia para uma área de problema; estilo
arquitetural, framework ou padrão de projeto.
Modelo
experimental
•  Modelo preditivo experimental baseado em dados observados.
Modelo analítico
•  Modelo estrutural
que permite
análise
ou manipulação
Inclui
técnicas
para formal
implementação,
automática.
representação, gerência e análise.
Ferramenta ou
notação
•  Ferramenta implementada que engloba uma técnica;
linguagem formal Apara
apoiardeve
a técnica
ou modelo. –
técnica
ser operacional
Solução específica,
protótipo, resposta
ou julgamento
não apenas
conselho
ou guia,
mas
•  Solução para problema
que mostra
aplicações
de princípios
de
um protótipo
procedimento.
ES (pode ser design,
ou implementação completa),
análise cuidadosa de um sistema ou seu desenvolvimento,
resultado de uma análise, avaliação ou comparação específica.
Relatório
•  Observações interessantes, regras de ouro (rules of thumb),
mas não suficientemente gerais ou sistemáticas para se
tornarem um modelo descritivo.
44
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 2003.
Tipos de resultados em Engenharia de Software
Tipos de resultados em Engenharia de Software
Tipo Resultado
Exemplos
Tipo Resultado
Exemplos
Procedimento ou
técnica
•  Jeito novo ou melhor de fazer alguma tarefa, como design,
implementação, manutenção, medidas, avaliação, seleção de
alternativas.
Procedimento ou
técnica
•  Jeito novo ou melhor de fazer alguma tarefa, como design,
implementação, manutenção, medidas, avaliação, seleção de
alternativas.
Modelo qualitativo
ou descritivo
•  Estrutura ou taxinomia para uma área de problema; estilo
arquitetural, framework ou padrão de projeto.
Modelo qualitativo
ou descritivo
•  Estrutura ou taxinomia para uma área de problema; estilo
arquitetural, framework ou padrão de projeto.
Modelo
experimental
•  Modelo preditivo experimental baseado em dados observados.
Modelo
experimental
•  Modelo preditivo experimental baseado em dados observados.
Modelo analítico
•  Modelo estrutural
que permite
análise de
formal
ou manipulação
Análise
não-formal
domínio,
automática.
checklists bem embasados,
Modelo analítico
•  Modelo estrutural que permite análise formal ou manipulação
automática.
Ferramenta ou
notação
generalizações
informais
•  Ferramenta implementada
que engloba
uma bem
técnica;
linguagem formal construídas,
para apoiar a guia
técnica
ou modelo.
para
integração de
Ferramenta ou
notação
•  Ferramenta implementada que engloba uma técnica;
linguagem formal para apoiar a técnica ou modelo.
Solução específica,
protótipo, resposta
ou julgamento
outros que
resultados,
observações
•  Solução para problema
mostra aplicações
de princípios de
interessantes
organizadas.
ES (pode ser design,
protótipo oubem
implementação
completa),
análise cuidadosa de um sistema ou seu desenvolvimento,
resultado de uma análise, avaliação ou comparação específica.
Solução específica,
protótipo, resposta
ou julgamento
•  Solução para problema que mostra aplicações de princípios de
ES (pode ser design, protótipo ou implementação completa),
análise cuidadosa de um sistema ou seu desenvolvimento,
resultado de uma análise, avaliação ou comparação específica.
Relatório
•  Observações interessantes, regras de ouro (rules of thumb),
mas não suficientemente gerais ou sistemáticas para se
tornarem um modelo descritivo.
Relatório
•  Observações interessantes, regras de ouro (rules of thumb),
mas não suficientemente gerais ou sistemáticas para se
tornarem um modelo descritivo.
45
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 2003.
Resultados do ICSE 2002
46
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 2003.
Tipos de resultados em Engenharia de Software
O que, precisamente, você alega ser a sua contribuição?
q  Os resultados satisfazem completamente suas alegações?
As definições são precisas e os termos são utilizados
consistentemente?
–  Se os resultados deveriam ser utilizados em sistemas grandes,
explique porque você acha que ele é escalável.
–  Se o seu método é ‘automático’, não deveria necessitar de
humanos. Explique as excessões ou configurações manuais.
q 
Importante:
(resultados baseados nos abstracts)
–  Muitos projetos de pesquisa produzem resultados de vários
tipos. Muitos autores apresentam ideias individuais em
conferências e sintetizam os resultados em revistas.
–  Explique seus resultados de forma a permitir que outros
utilizem os seus resultados. O que foi obtido de novo?
–  Defina precisamente os termos críticos.
47
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 2003.
–  Se os resultados são ‘distribuídos’, não deveria haver um
controlador/servidor central. Explique qual parte é distribuída.
–  Se está propondo uma nova notação para um problema antigo
explique claramente porque ela é superior às anteriores.
–  Se o artigo é um relato de experiência, explique que ideia o
leitor pode tirar do artigo em outras situações ou como o leitor
pode aumentar sua confiança em aplicações além do exemplo
apresentado.
48
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 2003.
8
Lições Aprendidas
q 
q 
q 
Lições Aprendidas
Uma lição aprendida deve indicar a quem se aplica, qual o
contexto associado e dar detalhes que permitam ao leitor se
beneficar dela e, possivelmente, utilizá-la no futuro.
Compare os exemplos abaixo:
q 
Texto simples (simplório?):
–  ‘O projeto usou casos de uso genéricos.’
Tenha trabalho e cuidado em descrever extamente quais
são as contribuições da sua experiência para a audiência.
q 
Se o leitor não se convencer da pertinência e aplicabilidade
das suas lições aprendidas, elas não serão consideradas
válidas por ele e o seu artigo terá menos chances de ser
lido/aprovado.
Texto estruturado (simples?):
Título:
Utilização de casos de uso genéricos
Problema:
Alto esforço para gerar casos de uso.
Consequência do Aumento do prazo e custo do projeto.
problema:
Causa do
problema:
Falta de mecanismos para fazer reutilização de casos de uso.
Solução para o
problema:
Utilizar casos de uso genéricos para funções similares nos projetos
(por exemplo, funções de incluir, alterar e excluir dados).
Resultado da
solução:
Diminuição do esforço e, consequentemente, do prazo e custo para
construir casos de uso.
49
Conclusões / Considerações Finais
q 
q 
q 
q 
q 
Conclusões / Considerações Finais
Sumário do que foi discutido no artigo
Discussão das principais lições aprendidas
Sumário das principais contribuições do artigo
Apresentação das lições aprendidas do trabalho
Discussão de limitações
q 
q 
q 
q 
–  Não é demérito ter limitações
q 
q 
Discussão de trabalhos futuros
–  Não significa que você irá desenvolvê-los, apenas que há
possíveis desdobramentos/evoluções do seu trabalho.
q 
50
q 
Explique como o desenvolvimento o ajudou a atingir cada
um dos objetivos do trabalho
Apresente argumentos a favor e contra seu trabalho
(limitações)
Seja o maior crítico do seu próprio trabalho
Cuidado com conclusões “fortes”
Procure apresentar as lições aprendidas e como elas podem
ser aplicadas
Trabalhos futuros:
–  Aponte para pesquisa futura, não atividades futuras
Conclusões ou Considerações Finais? Qual o foco da sessão?
–  Concluir alguma coisa
–  O leitor terá pouco interesse em saber o que você pretende
fazer no futuro
–  Sumarizar o que foi discutido no artigo
51
Tipos de Validação em Engenharia de Software
Por que um leitor deveria acreditar no seu resultado?
q  Os argumentos apresentados no artigo são persuasivos?
q  Que evidências são apresentadas para apoiar suas alegações?
q  Que tipo de evidência é oferecida? Este tipo é habitual?
q  O tipo de avaliação é descrita de forma clara e correta?
–  Experimentos controlados requerem mais que coleta de dados
–  Estudos de caso requerem mais que discussão de situações
q 
A validação está relacionada a suas alegações?
–  Se você alega melhora de desempenho, a validação tem que ser
feita sobre o desempenho não facilidade de uso…
q 
A sua ideia é tão interessante e potencialmente poderosa que
deve ser exposta apesar da pouca evidência concreta?
53
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 2003.
Fonte: Santoro, F., Notas de Aula – Apresentação do Metodologia da Pesquisa Científica 2010.2,
52
Programa de Pós-Graduação em Informática – UNIRIO. apud Wazlawick, 2007
Tipos de Validação em Engenharia de Software
Por que um leitor deveria acreditar no seu resultado?
q  Autores tendem a ter problemas em determinadas situações:
–  Se você alega melhoria em uma arte anterior, compare seu
resultado objetivamente em relação àquela arte anterior.
–  Se você usou uma técnica de análise, siga suas regras.
»  Se o uso da técnica não é habitual na Engenharia de
Software, explique a técnica, explique seu uso, estrutura e
regras, seja claro sobre sua aderência à técnica.
–  Se você oferece experiência prática como evidência de seu
resultado, estabeleça o efeito que a sua pesquisa teve.
–  Se você executou um experimento controlado, explique o projeto
do experimento.
»  Hipóteses? Tratamento? O que está sendo controlado? Dados
coletados? Como analisou? Os resultados são significativos?
Quais os fatores de confusão? Suas conclusões vêm dos dados
experimentais?
54
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 2003.
9
Tipos de Validação em Engenharia de Software
Por que um leitor deveria acreditar no seu resultado?
q  Autores tendem a ter problemas em determinadas situações:
(cont.)
Agradecimentos
q 
q 
–  Se você executou um estudo experimental, explique como você
mediu, como você analisou e o que concluiu.
Agradecimentos devem vir em uma sessão própria, após as
conclusões e antes das referências bibliográficas
Que tipos de agradecimentos são comuns?
–  Apoio da empresa
–  Apoio de algum órgão de fomento
»  Que dados foram coletados e como? Como a análise está
relacionada com o objetivo de apoiar suas alegações sobre o
resultado?
–  Pessoas que contribuíram de alguma forma no trabalho
–  Pessoas que participaram de alguma pesquisa ou estudo
»  Não confunda correlação com causalidade.
–  Se você usou um pequeno exemplo para explicar o resultado,
proveja evidência adicional do seu uso prático e escalabilidade.
55
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 2003.
Referências Bibliográficas
q 
56
Referências Bibliográficas
Referência bibliográfica não é sinônimo de bibliografia
recomendada!
q 
–  Todos os textos utilizados devem ser referenciados
q 
–  Textos não utilizados não devem ser relatados
q 
–  Blá blá blá (FULANO, 2008)
Evite o uso de referências muito antigas
–  Blá blá blá (SICRANO et al., 2008)
–  O uso de referências antigas é mais aceitável quando se trata
de um texto clássico ou precussor da área
–  Segundo FULANO (2008)
–  Segundo SICRANO et al. (2008)
»  Por exemplo, citações ao ‘mito do homem-mês’ ou ao ‘GQM’
–  O uso de muitas referências antigas pode indicar que a revisão
da literatura é tendenciosa e/ou ultrapassada
–  O quanto é muito antigo? Use o bom senso… J
q 
q 
–  FULANO (2008) afima que ...
–  SICRANO et al. (2008) afirmam que ...
q 
Referências Bibliográficas
Referências no final do texto
–  PMI – Project Management Institute (2008) “A Guide to the Project Management
Body of Knowledge (PMBOK Guide)”, 4ª ed., Newton Square: PMI Publications.
Se você não referenciar, é plágio. E plágios não são
tolerados.
Leiam os artigos referenciados, não copie trechos de revisão
da literatura de outros.
–  Softex (2011) “MPS.BR - Melhoria de Processo do Software Brasileiro, Guia Geral”.
Disponível em http://www.softex.br/mpsbr. Acessado em: setembro/2011.
–  Santos, G., Montoni, M., Figueiredo, S., Rocha, A. R. (2007) “SPI-KM – Lessons
Learned from Applying a Software Process Improvement Strategy Supported by
Knowledge Management”, 8th International Conference on Product Focused
Software Process Improvement (PROFES’2007), Latvia.
57
q 
As referências devem ser identificadas ao longo do texto do
artigo e listadas ao final do texto.
Referências ao longo do texto
58
Anexos e Apêndices
Exemplo de formatação:
q 
–  Ver template de artigo da conferência
»  Em artigos nacionais, muitas vezes (como no WAMPS ou no
SBQS) utiliza-se o padrão da SBC
q 
Anexo é um texto ou documento não elaborado pelo autor
do Trabalho Científico (TC) (monografia, tese etc.).
Apêndice é um texto ou documento elaborado pelo autor
do Trabalho Científico.
–  Regras da COPPE (http://www.coppe.ufrj.br/ensino/cpgp.html)
–  Regras da ABNT
q 
q 
Ou seja, se foi necessário você criar uma entrevista, um
relatório, ou qualquer documento com o escopo de
complementar sua argumentação, deve-se utilizar o termo
Apêndice e não Anexo.
q 
Exemplos:
Revise cuidadosamente o texto para ver se toda a
referência é citada e vice versa
–  ANEXO A – Documento ou texto não elaborado pelo autor
–  APÊNDICE A – Documento ou texto elaborado pelo autor
59
Fonte: TÉCNICAS, Associação Brasileira de Normas. NBR 14724 - Informação e documentação —
trabalhos acadêmicos — apresentação. Rio de Janeiro: Impresso no Brasil, 2010. apud
http://www.tudosobremonografia.com/2011/01/diferenca-entre-anexo-e-apendice.html60
10
Televisão, Petróleo, Homens e Ilhas
q 
A forma do texto
Redação:
q 
–  Clareza
q 
A forma do texto influencia na qualidade geral do trabalho.
–  Objetividade
–  Se a forma não está adequada é difícil avaliar as reais
contribuições dos autores.
–  Encadeamento
–  Um artigo com a estrutura inadequada pode ser recusado.
–  Resultados
–  Um artigo mal escrito tem mais chances ainda de ser recusado.
Estrutura do parágrafo segue a estrutura do texto:
q 
Garanta sempre que o português do texto esteja impecável.
–  Um texto mal escrito não vai conseguir passar a mensagem
que os autores querem (e acham que conseguiram escrever).
–  Introdução
–  Desenvolvimento
–  Conclusão
61
Redação
Mensagem:
q  O texto tem que ter uma mensagem, a idéia principal
que se quer mostrar.
q  Ter certeza que você sabe o que é:
62
Redação
Contribuição:
q  Não assuma que sua contribuição é óbvia.
–  1. Diga o que você vai dizer
–  2. Diga
–  Faça um resumo dessa mensagem em poucas palavras
–  Garanta que a mensagem está refletida em:
–  3. Diga o que você acabou de dizer
q 
»  Título
Não deixe para o leitor a tarefa de descobrir o que é
importante, diga explicitamente
»  Resumo
»  Introdução; Estrutura e Conclusão
Fonte: Orientações para orientandos - Uma experiência em BD, Marta Mattoso, III Workshop de
Teses e Dissertações em Bancos de Dados - 19º. Simpósio Brasileiro de Bancos de Dados 63
Redação
Compreensão / Avaliação
q  Facilite a compreensão/avaliação do seu trabalho,
apresentando clara e explicitamente:
Fonte: Orientações para orientandos - Uma experiência em BD, Marta Mattoso, III Workshop de
Teses e Dissertações em Bancos de Dados - 19º. Simpósio Brasileiro de Bancos de Dados 64
Redação
Avaliação
q  O que a banca examinará:
–  Trabalho original compreendendo um grau satisfatório de
atividades de pesquisa
–  1. Caracterização do problema
–  2. Objetivo da tese (garanta que o objetivo será o MESMO ao
longo de toda a tese)
–  Análise crítica dos tópicos e trabalhos relevantes
–  Competência no método de pesquisa e na área de pesquisa
escolhida
–  3. Como o objetivo foi atendido
–  4. Porque o objetivo foi atendido
–  Independência na abordagem do problema ou técnica
apresentada
–  5. Contribuição
–  Texto bem elaborado e referências adequadas
–  6. Originalidade
Fonte: Orientações para orientandos - Uma experiência em BD, Marta Mattoso, III Workshop de
Teses e Dissertações em Bancos de Dados - 19º. Simpósio Brasileiro de Bancos de Dados
q 
E para relatos de experiências?
–  A descrição do contexto onde a experiência é relatada é
adequada?
Fonte: Orientações para orientandos - Uma experiência em BD, Marta Mattoso, III Workshop de
Teses e Dissertações em Bancos de Dados - 19º. Simpósio Brasileiro de Bancos de Dados 65
–  A experiência e seus resultados são válidos?
66
–  As lições aprendidas são interessantes e trazem algo de novo?
11
Escrevendo Textos
q 
Textos Ambíguos
Texto:
q 
–  (a) 1 (Fevereiro)
–  O dialeto do telemarketing não é português
–  (b) 12 (Todos os meses do ano)
–  Um artigo é um texto técnico
–  (c) Nenhum, pois fevereiro às vezes tem 29 dias
–  Começo, meio e fim, nesta ordem
Um texto acadêmico não pode levar a duplas interpretações.
A interpretação não pode depender do leitor, deve ser explícita e única.
–  Textos soltos não dizem nada
–  Modos verbais: Imperativo, Subjuntivo e Indicativo
–  A reforma ortográfica já está valendo!
q 
q 
Opiniões:
–  Se não for, cuide-se!
Uso de termos pouco formais
q 
–  "saúde" de empresas
q 
q 
Considere as seguintes frases, extraídas de diferentes
matérias jornalísticas, e responda ao que se pede.
–  I. Nos últimos meses, o debate sobre o aquecimento global
vem, com perdão do trocadilho, esquentando.
–  Se for da literatura, colocar referência.
q 
Quantos meses do ano têm 28 dias?
–  A língua utilizada no MSN não é português
Definir todos os termos
Cuidado ao usar o mesmo termo em diferentes acepções
q 
67
Textos Ambíguos
–  II. Preso vigia acusado de matar empresário.
a) Identifique, na frase I, o trocadilho a que se refere o redator e
explique por que ele pede perdão por tê-lo produzido.
b) É correto afirmar que na frase II ocorre ambigüidade? Justifique
sua resposta.
http://oglobo.globo.com/educacao/vestibular/arquivos/Fuvest2009_2afase_portugues.pdf
68
Conotação e Donotação
q 
Texto Conotativo:
–  Conotação é a significação subjetiva da palavra; ocorre quando
a palavra evoca outras realidades por associações que ela
provoca
q 
Texto Denotativo:
–  Denotação é a significação objetiva da palavra; é a palavra em
"estado de dicionário“
http://oglobo.globo.com/educacao/vestibular/arquivos/Fuvest2009_2afase_portugues.pdf
Compare:
q  Quem está na chuva é para se molhar.
q  Quando alguém opta por uma determinada experiência,
deve assumir todas as regras e conseqüências decorrentes
dessa experiência.
Figuras de Linguagem: Texto científico não é texto literário.
69
Um ativo reutilizável possui valor imensurável tendo em
vista seu potencial para reduzir o esforço de execução do
processo e/ou pelo conhecimento explícito que contém.
q 
Compare:
q  Um ativo reutilizável possui grande valor tendo em vista
seu potencial para reduzir o esforço de execução do
processo e/ou pelo conhecimento explícito que contém.
Não use palvras fortes, o artigo não é para causar espécie...
Exemplos de possíveis palavras fortes:
q  Sempre
q  Nunca
q  Imprescindível
q  Imensurável
As palavras dependem do contexto em que estão inseridas.
Fonte: http://acd.ufrj.br/~pead/tema04/denotacaoeconotacao.html
70
Sujeito preposicionado
Uso incorreto de ponto-e-vírgula
Uso de Palavras “fortes”
q 
Em qual das duas classificações você acha que um texto científico
deveria se encaixar?
Tendo em vista as dificuldades enfrentadas no
gerenciamento do Projeto de Melhoria de Processos de
Software, multiplicadas pela complexidade do ambiente das
corporações; e da necessidade cada vez mais crescente das
empresas alcançarem suas metas e objetivos diretamente
entrelaçados ao planejamento estratégico, pode-se
relacionar a estes projetos as mesmas ondas definidas pelo
PMI.
Compare:
q  ... da necessidade cada vez mais crescente de as empresas
alcançarem suas metas ...
q  ... ambiente das corporações e da necessidade ...
As regras do português devem ser seguidas.
Por mais que as estruturas possam parecer estranhas algumas vezes…
71
72
12
Uso excessivo (incorreto) de vírgulas
Verbo na 1ª pessoa
q 
Uso excessivo de vírgulas
Várias são as definições de projetos que podem ser
encontradas na literatura e, a seguir destacamos algumas
delas:
Compare:
q  Várias são as definições de projetos que podem ser
encontradas na literatura e a seguir são destacadas
algumas delas:
q  Várias são as definições de projetos que podem ser
encontradas na literatura e, a seguir, são destacadas
algumas delas:
q  Várias são as definições de projetos que podem ser
encontradas na literatura:
q 
Projetos que possuem alto valor para os benefícios padrão e
alto risco de insucesso, devendo, ter os riscos de insucesso
tratados, para que se desloquem para o quadrante da
esquerda e possam, com isso prosseguir para os próximos
subprocessos.
Compare:
q  Projetos que possuem alto valor para os benefícios padrão e
alto risco de insucesso devendo ter os riscos de insucesso
tratados para que se desloquem para o quadrante da
esquerda e possam, com isso, prosseguir com a execução
dos subprocessos seguintes.
As regras do português devem ser seguidas.
Vírgula não é para pausa.
Não se separa o sujeito do verbo por vírgula.
As regras do português devem ser seguidas.
Deve-se procurar sempre que o texto seja fácil de ler.
73
Uso insuficiente de vírgulas
74
Crase
Assim um novo desafio tem surgido para as organizações ...
Compare:
q  Assim, um novo desafio tem surgido para as organizações ...
q 
As regras do português devem ser seguidas.
Deve-se procurar sempre que o texto seja fácil de ler.
Algumas organizações se destacam por possuírem algum tipo
de programa de melhorias, baseado em um dos modelos de
melhoria de processos existentes como, por exemplo, CMMI,
MPS.BR, ISO 9000, ISO/IEC 12207 ou ISO/IEC 15504.
Compare:
q  Algumas organizações se destacam por possuírem algum tipo
de programa de melhorias baseado em um dos modelos de
melhoria de processos existentes, como, por exemplo, CMMI,
MPS.BR, ISO 9000, ISO/IEC 12207 ou ISO/IEC 15504.
q 
q 
E desta forma prover a alta gerência, patrocinadores,
interessados e gerente, uma visão consolidada de todos os
projetos que compõem o programa.
Compare:
q  E desta forma, prover à alta gerência, patrocinadores,
interessados e gerentes, uma visão consolidada de todos
os projetos que compõem o programa.
As regras do português devem ser seguidas.
Atenção à regência dos verbos.
Por exemplo, o verbo visar é transitivo indireto, mas no Brasil costumamos
suprimir a preposição antes de infinitivo
Quando é que você vai comprar a sua gramática?
75
Uso de Verbos na 1ª Pessoa
Concordância
q 
76
Uso de Advérbios de Modo
Por isso, definiremos primeiramente o conceito de
projetos, gerência de projetos e posteriormente os conceitos
de portfólio e gerência de portfólio.
Compare:
q  Por isso, serão definidos primeiramente os conceitos de
projetos e gerência de projetos e, posteriormente, os
conceitos de portfólio e gerência de portfólio.
Evite utilizar verbos na 1a pessoa. Altere a frase para deixar o texto
impessoal. Pode-se utilizar a voz passiva.
Essa regra não se aplica totalmente a textos em inglês (onde voz passiva
nem sempre é indicada e pode deixar a estrutura da frase confusa).
E, só para não perder o costume:
As regras do português devem ser seguidas.
q 
Por isso, serão definidos primeiramente o conceito de
projetos, gerência de projetos e posteriormente os
conceitos de portfólio e gerência de portfólio.
Compare:
q  Por isso, serão definidos a princípio o conceito de projetos,
gerência de projetos e, depois, os conceitos de portfólio e
gerência de portfólio.
q  Por isso, serão definidos o conceito de projetos, gerência de
projetos e os conceitos de portfólio e gerência de portfólio.
O texto deve ser fácil e agradável de ler.
77
78
13
Consistência entre Texto e Referências
q 
Redundância
Diversos estudos indicam que a estratégia de negócio pode
ser alcançada ou ligada à gerência de portfólio através da
seleção e execução dos projetos adequados dentro do
processo de alinhamento estratégico (SRIVANNABOON,
2006).
Compare:
q  Estudos indicam que a...
O principal objetivo dessa atividade é decidir se o projeto
deve ser aprovado ou postergado baseando-se no critério
de balanceamento através da sobreposição do mapa de
investimento estratégico desejado e o mapa de
investimento estratégico atual. Assim, um objetivo
importante dessa atividade é balancear os investimentos
entre as áreas e subáreas de investimento.
Compare:
q  O principal objetivo dessa atividade é decidir se o projeto
deve ser aprovado ou postergado baseando-se no critério
de balanceamento através da sobreposição do mapa de
investimento estratégico desejado e o mapa de
investimento estratégico atual. Com isso, serão
balanceados os investimentos entre as áreas e
subáreas de investimento.
Se são diversos, por que só há uma referência?
79
Uso de Referências no Abstract/Resumo
q 
q 
O processo foi construído com base nas melhores práticas
de gerência de projetos PMBOK:2004 (PMBOK, 2004),
programa (PMI, 2006b) e portfólio (PMI, 2006a),
encontradas na literatura, e está aderente ao processo de
gerência de portfólio de projetos da norma ISO/IEC
12207:2008 (ISO/IEC12207, 2008).
A coerência do texto deve ser mantida sempre.
Relação entre Causa e Efeito
q 
Compare:
q  O processo foi construído com base nas melhores práticas
de gerência de projetos, programa e portfólio encontradas
na literatura e está aderente ao processo de gerência de
portfólio de projetos da norma ISO/IEC 12207:2008.
Estudos indicam que a estratégia de negócio pode ser
alcançada ou ligada à gerência de portfólio através da
seleção e execução dos projetos adequados dentro do
processo de alinhamento estratégico. Por isso, definiremos
primeiramente o conceito de projetos, gerência de projetos
e posteriormente os conceitos de portfólio e gerência de
portfólio.
Compare:
q  Para melhor entendimento, faz-se necessário definir termos
como...
q  A seguir, serão definidos os conceitos de projetos, gerência
de projetos, portfólio e gerência de portfólio.
Tecnicamente o artigo só começa após o abstract/resumo, então
não deveria ter referências bibliográficas ainda.
O abstract deve ser curto e fácil de ler.
Não se esqueça que é o resumo do artigo, não o artigo.
81
Citações com Diferentes Estilos
q 
q 
80
82
Referência a Figuras
Gerência de projetos é o planejamento, programação e
controle de uma série de tarefas integradas de forma a
atingir, com êxito, os objetivos do projeto, para benefício
dos envolvidos [Kerzner, 2002].
O PMI (Project Management Institute) [1] define
gerência de projetos como sendo a aplicação de
conhecimentos, habilidades, ferramentas e técnicas nas
atividades do projeto com o objetivo de atender as suas
necessidades.
q 
q 
... como mostra a Figura 1 – Realização dos objetivos e metas
através de projetos e as restrições organizacionais .
... como mostra a figura abaixo.
Compare:
q  ... como mostra a Figura 1.
Deve-se padronizar estilo do texto e também das referências.
Verifique o padrão na chamada de trabalhos.
83
Todas as figuras devem ser referenciadas no texto.
Deve-se referenciá-las antes de aparecerem no texto.
Deve-se sempre referenciar as figuras por um número sequencial.
A referência à figura não deve repetir a sua legenda.
Cuidado com o uso excessivo de figuras.
Deve haver uma explicação para cada figura.
O leitor não deve (nem tem condições de) advinhar o que a figura quer
dizer e porque ela foi inserida no texto.
A semântica das figuras é importante.
Se for usar uma notação específica, justifique/saiba por que ela foi
utilizada.
84
Procure não misturar notações diferentes.
14
Informalidade da Fala na Escrita
Uso de pronomes
Traduções Incorretas / Não Recomendadas
q 
comprehensive
A organização irá utilizar a baseline estabelecida através
da caracterização como base de comparação com um
desempenho futuro.
Compare:
q  A organização utilizará a baseline estabelecida através da
caracterização como base de comparação com um
desempenho futuro.
q 
–  abrangente
–  compreensivo
q 
to support
–  apoiar
–  suportar
q 
performance
–  desempenho
No benchmarking interno a busca pelas melhores práticas
ocorre dentro da própria organização. Ele utiliza medidas
básicas da organização.
Compare:
q  No benchmarking interno a busca pelas melhores práticas
ocorre dentro da própria organização. São utilizadas
medidas básicas da organização.
q 
–  performance
http://www.ime.usp.br/~kon/ResearchStudents/traducao.html
Verifique a tradução correta para os termos que quer utilizar.
Nem sempre a tradução mais utilizada é a correta…
Mas tenham cuidado também com o português, utilizem a
expressão correta... Por exemplo:
- de encontro / ao encontro
- tão pouco / tampouco
O texto científico é um texto formal.
http://www.cintiabarreto.com.br/didatica/curiosidadesgraficas.shtml
Frases Grandes
Uso de “o mesmo”
A idéia básica por trás do benchmarking aplicado aos projetos de
melhoria de processos de software é que, para cada novo projeto,
há outros projetos que se assemelham àquele e que já foram
realizados ou ainda estão sendo realizados de forma que muitas
das informações derivadas destes projetos podem servir de base
para o planejamento ou para a análise do desempenho de outros
projetos que estão em fase de iniciação ou em execução.
Compare:
q  A idéia básica por trás do benchmarking aplicado aos projetos de
melhoria de processos de software é que, para cada novo projeto,
há outros projetos que se assemelham àquele e que já foram
realizados ou ainda estão sendo realizados. Assim, muitas das
informações derivadas destes projetos podem servir de base para
o planejamento ou para a análise do desempenho de outros
projetos que estão em fase de iniciação ou em execução.
q 
Deve-se procurar sempre que o texto seja fácil de ler.
Evite o uso de ‘que’ nas frases.
Procure fazer as frases não maiores que 3 ou 4 linhas.
Só não exagere e crie textos telegráficos…
87
Termos a Serem Evitados
q 
q 
q 
q 
q 
q 
q 
q 
q 
q 
q 
Advérbios
Brincadeiras, Ironia ou
Piadas
“ruim” e “bom” (não
julgue)
“perfeito” (nada é)
“uma solução ideal”
“hoje em dia”,
“atualmente”
“em breve”
“Ficamos surpresos ao
perceber que...”
“parece que...”
“parece mostrar que...”
“diferente” (de quê?)
86
q 
q 
q 
q 
q 
q 
q 
q 
q 
q 
Testes têm como objetivo verificar dinamicamente o
comportamento de um programa, usando um conjunto de
casos de teste adequadamente selecionados, em relação ao
comportamento esperado para o mesmo [SWEBOK, 2004].
q 
Testes têm como objetivo verificar dinamicamente o
comportamento de um programa, usando um conjunto de
casos de teste adequadamente selecionados, em relação ao
comportamento esperado [SWEBOK, 2004].
O uso de ‘o mesmo’ tecnicamente não fere regras gramáticais, mas
interefere no estilo do texto.
Em geral, pode-se retirar ‘o mesmo’ do frase sem perda do significado.
Menos é mais...
Outros vícios de linguagem:
a nível de, através de, numa/num, uso de numerais (3) no texto, não-uso
de pronomes pessoais
88
Escrevendo Textos
“provavelmente”
“simples”
“obviamente”,
“claramente” (para
quem?)
“na verdade”
Segunda pessoa
Primeira pessoa
“um pesquisador
famoso”
“poucos”, “muitos”,
“todos”,
“nenhum” (quem disse?
Como foi provado?)
“deve” (quem disse?)
Wazlawick, 2007
Fonte: Santoro, F., Notas de Aula – Apresentação do Metodologia da Pesquisa Científica 2010.2,
Programa de Pós-Graduação em Informática – UNIRIO. apud Wazlawick, 2007
q 
Regra de ouro para escrever textos:
–  Defina
–  Leia
–  Pense
–  Estruture
–  Escreva, imprima, leia
–  Escreva, imprima, leia
–  Escreva, imprima, leia
–  Escreva, imprima, leia
–  Escreva, imprima, leia
–  Escreva, imprima, leia
–  Escreva, imprima, leia
–  Escreva, imprima, leia
–  Escreva, imprima, leia
–  Escreva, imprima, leia
–  Escreva, imprima, leia
90
15
Ética...
q 
Ética na Pesquisa
... em Sala de Aula
q 
–  Profissionais de computação
–  Não plagiar o trabalho
–  Ser Humano
–  Usuários e Clientes
–  Não trapacear nas leituras e
listas de exercício
q 
–  Não sobrecarregar os colegas
do grupo
–  Desinteresse: requer que os resultados da pesquisa não sejam
manipulados
(ver nota de rodapé!)
–  Ceticismo organizado: requer que afirmações não devam ser
aceitas pela palavra da autoridade
E na Pesquisa?
Fonte: Murta, L., Notas de Aula – Apresentação do Curso de Engenharia de Software 1 2009/1,
91
Instituto de Computação - UFF
Ética na Pesquisa
Algumas questões para reflexão
Fonte: Santoro, F., Notas de Aula – Apresentação do Metodologia da Pesquisa Científica 2010.2,
92
Programa de Pós-Graduação em Informática - UNIRIO
Plágio e Auto Plágio
(Wainer, 2007)
q 
–  Participação em experimentos
»  O sujeito de um experimento em ciência da computação deve
ser informado que ele participa de um experimento ou isso
não é necessário?
»  Se ele tiver que ser informado, é preciso que ele o seja antes
e concorde em participar, ou só e preciso que ele concorde,
após o experimento, que os dados sejam utilizados na
pesquisa, desde que certas salvaguardas sejam tomadas?
»  Que garantias de anonimato da organização na publicação
final dos resultados são apropriadas?
–  Pesquisa não é plágio
q 
Sempre referencie os autores de quem você cita um texto
q 
Não copie um trecho completo de um trabalho alheio,
mesmo referenciando. Isso pode ser considerado plágio.
q 
Auto-plágio
–  Posso publicar um mesmo artigo em vários lugares diferentes?
»  Infelizmente não.
»  A organização tem poder de veto na publicação dos
resultados?
»  Descubra como transformar a experiência em outro artigo J
»  Se a organização já autorizou a pesquisa, é preciso pedir
consentimento a cada um dos sujeitos estudados?
–  Mesmo quando se copia um trecho de um trabalho anterior seu
é preciso referenciá-lo!
Fonte: Santoro, F., Notas de Aula – Apresentação do Metodologia da Pesquisa Científica 2010.2,
93
Programa de Pós-Graduação em Informática - UNIRIO
Processo de Revisão
q 
q 
Os artigos submetidos a eventos científicos serão avaliados
por revisores selecionados (em geral, 2 a 3)
Ajuste de foco do artigo com a chamada do evento
q 
q 
q 
q 
Submissão do artigo.
–  Verifique a data limite (não há garantias que ela seja alterada!)
q 
q 
q 
–  Verifique o sistema de submissão (no Brasil, é comum o uso do
JEMS, no exterior, do EasyChair. Também pode ser e-mail).
É de bom tom corrigir os itens apontados pelos revisores
(eles não foram escolhidos ao acaso), apesar de não haver
95
uma segunda revisão...
94
Processo de Seleção de Artigos
–  Analise a lista de revisores para tentar inferir o possível foco
que será dado nas revisões
–  Não é trabalho do revisor corrigir o seu trabalho, mas sim
apontar os pontos fortes e fracos e a adequação ao evento.
q 
–  Auto-plágio tem sido cada vez menos tolerado...
–  Deve ser feito antes da submissão. Se o foco estiver errado,
aumentam as chances de o artigo ser recusado
Garanta uma boa revisão prévia do artigo.
Plágio x Pesquisa
–  Plágio não é pesquisa
–  Pesquisas qualitativas
q 
(Merton, 1942)
–  Universalismo: requer que a ciência seja independente de raça,
cor, credo...
–  Dar crédito apropriado quando
usar trabalhos de terceiros
q 
“Comportamento do cientista”
–  Comunalismo: requer que o conhecimento científico seja
público
–  Não assinar presença por
colegas
q 
Necessidade de postura ética em relação à computação:
–  Não colar ou dar cola em
provas
q 
q 
Pesquisadores selecionam coordenador do comitê de
programa
Coordenador do comitê de programa seleciona membros do
comitê de programa
Coordenador do comitê de programa apresenta Chamada de
Trabalhos (Call for Papers)
Autores submetem artigos
Coordenador do comitê de programa distribui artigos para
os membros do comitê
Membros do comitê redistribuem artigos para revisores (se
for o caso)
Revisores apresentam revisão dos artigos
Membros do comitê e coordenador decidem quais artigos
serão aceitos
Fonte: Santoro, F., Notas de Aula – Apresentação do Metodologia da Pesquisa Científica 2010.2,
Programa de Pós-Graduação em Informática - UNIRIO
16
Comunicação da Revisão
q 
Variam de acordo com a conferência/periódico
q 
Avaliação numérica (notas em critérios)
Critérios de Avaliação de Artigos do SBQS
q 
–  O artigo apresentado é original dentro da área do evento,
apresentando contribuição relevante? O conteúdo apresentado
no artigo não foi ainda publicado em outro evento ou journal?
–  1: Nada original 2: Fracamente original 3: Um pouco original 4:
Bem original 5: Extremamente original
–  Originalidade
–  Conteúdo técnico
–  Relevância
q 
–  Contribuição
–  Clareza na escrita, organização do texto e apresentação
Avaliação qualitativa
q 
–  Pontos positivos
–  Pontos negativos
Fonte: Santoro, F., Notas de Aula – Apresentação do Metodologia da Pesquisa Científica 2010.2,
Programa de Pós-Graduação em Informática - UNIRIO
Critérios de Avaliação de Artigos do SBQS
Critérios de Avaliação de Artigos do SBQS
Qualidade técnica:
q 
–  O artigo tem qualidade técnica?
–  1: Avaliação/experiência na prática ausente 2: Avaliação/
experiência na prática fraca 3: Avaliação/experiência na prática
boa 4: Avaliação/experiência na prática ótima 5: Avaliação/
experiência na prática excelente
Apresentação:
–  O artigo está bem organizado, é fácil de ler e foi bem
apresentado? Considere o enquadramento dentro da
formatação do evento e a facilidade para compreensão.
Experiência na prática:
–  O artigo apresenta uma experiência concreta na prática? (obs:
para relatos de experiência, é obrigatório que eles demonstrem
uma experiência na prática)
–  1: Totalmente sem qualidade técnica 2: Qualidade técnica fraca
3: Qualidade técnica boa 4: Qualidade técnica ótima 5:
Qualidade técnica excelente
q 
Caracterização do contexto:
–  O artigo apresenta e caracteriza o contexto em que a
experiência foi realizada?
–  1: Embasamento/caracterização ausente 2: Embasamento/
caracterização fraca 3: Embasamento/caracterização boa
4: Embasamento/ caracterização ótima 5: Embasamento/
caracterização excelente
–  Resumo da contribuição
q 
Relevância para a Chamada de Trabalhos:
–  O tema do artigo é relevante para o evento, levando-se em
conta sua chamada de trabalhos?
–  1: Totalmente irrelevante 2: Fracamente relevante 3: Um
pouco relevante 4: Bem relevante 5: Extremamente relevante
–  Referencial teórico
q 
Originalidade e Contribuição:
q 
Resumo (Summary):
q 
Pontos Fortes (Paper Strengths):
Pontos Fracos (Paper Weakness):
Comentários para os Autores (Comments to Authors):
–  (Uma breve descrição do artigo)
–  1: Apresentação péssima 2: Apresentação ruim 3:
Apresentação boa 4: Apresentação ótima 5: Apresentação
excelente
q 
q 
–  (Comentários e sugestões para o autor melhorar a qualidade do
artigo)
q 
E ainda um campo que só os revisores veem…
99
Preparando a Apresentação
q 
100
Preparando a Apresentação
Escolhendo o Modelo de Slides
q 
–  Treine!
–  Escolha um modelo bonito e simples
–  Ao falar em voz alta, conseguimos perceber se o texto flui de
forma adequada
»  Contraste de cores e letras de tamanho adequado
–  Elimine os textos supérfluos, reorganize a apresentação
–  Evite figuras de fundo e letras rebuscadas
–  Lembre-se que as pessoas do fundo da sala devem poder ler o
conteúdo dos slides
q 
q 
Treinando a apresentação
–  Pode parecer besteira, mas é importante…
q 
A apresentação no dia
–  Fique calmo
Evite colocar muito texto nos slides
–  Fale pausadamente
–  O objetivo do texto é guiar a apresentação, e não ser lido
–  Demonstre segurança
–  Não é para colocar o texto completo do artigo na apresentação
–  Não leia, apresente
Estrutura dos slides
–  Vá bem vestido! J
–  Baseie-se na estrutura do texto, mas não se prenda a ela
q 
Respondendo às perguntas
–  Prepare-se para as perguntas mais difíceis
–  Nem sempre a estrutura do artigo é adequada em uma
apresentação
–  Se não for uma pergunta, não responda
–  Lembre-se que o filme baseado no livro é diferente do livro…
101
–  Você não estará participando de um debate, nada de réplicas e
tréplicas
102
17
Referências
q 
q 
q 
q 
q 
q 
q 
q 
q 
q 
EASTERBROOK, S., SINGER, J., STOREY, M., DAMIAN, D., Selecting Empirical Methods
for Software Engineering Research. In F. Shull, J. Singer and D. Sjøberg(eds) Guide to
Advanced Empirical Software Engineering, Springer, 2007.
FUGGETTA, A., 2000, "Software Process: a roadmap". In: Proceedings of the
Conference on the Future of Software engineering - International Conference on
Software Engineering, pp. 25-34, Limerick, Ireland.
ROCHA, A. R. C., MALDONADO, J. C., WEBER, K. C., 2001, “Qualidade de Software:
Teoria e Prática”, Prentice Hall.
SCHOTS, N. C. L., Uma Abordagem para a Identificação de Causas de Problemas
Utilizando Grounded Theory. Dissertação de Mestrado. COPPE/UFRJ, 2010.
SHAW, M., What Makes Good Research in Software Engineering, International Journal
of Software Tools for Technology Transfer, 2002, vol. 4, no. 1, pp 1-7.
SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE
2003.
WAZLAWICK, R. S., 2009, “Metodologia de Pesquisa para Ciência da Computação”,
1a edição, Elsevier Editora, Rio de Janeiro.
Curiosidades Gráficas: Palavras e termos semelhantes, mas com significados
diferentes: http://www.cintiabarreto.com.br/didatica/curiosidadesgraficas.shtml
Notas sobre escrita de textos na área de Sistemas de Computação na língua de
Camões: http://www.ime.usp.br/~kon/ResearchStudents/traducao.html
Alguns slides deste mini-curso foram baseados em material de outras pessoas,
conforme citado em slides específicos. Meus agradecimentos ao auxílio prestado.
WAMPS 2011 - VII Workshop
Anual do MPS
Como Escrever um Relato de
Experiência
Gleison Santos
[email protected]
103
18