You are on page 1of 18

1

Como Escrever um Relato de


Experincia
Gleison Santos
gleison.santos@uniriotec.br
WAMPS 2011 - VII Workshop
Anual do MPS
2
Agenda
! Introduo
! Estrutura do Texto de um Relato
! Preparao do Texto
! tica e Plgio
! Processo de Reviso de um Artigo
! Apresentao de um Artigo
Nota: caso copiem o contedo de algum slide, por favor,
mantenham a referncia fonte original ou a esta
apresentao (o que for pertinente).
Obrigado.
Engenharia de Software e Qualidade de Software
Software faz parte do nosso dia a dia.
! O principal objetivo da engenharia de software , sem
dvida, melhorar a qualidade do software.
(ROCHA et al., 2001)
! De forma geral, pesquisadores da Engenharia de Software
procuram melhores formas de desenvolver e avaliar
software.
! Pesquisadores da Engenharia de Software so motivados
por problemas prticos.
! Objetivos chave da pesquisa geralmente so qualidade,
custo e oportunidade dos produtos de software.
(SHAW, 2002)
3
Engenharia de Software e Qualidade de Software
Software faz parte do nosso dia a dia.
! H uma relao entre a qualidade dos produtos de software
e a qualidade dos processos de software utilizados para
constru-los [Fuggeta, 2000].
! A implantao de um Programa de Qualidade comea pela
definio e implantao de um processo de software.

Necessidades do Negcio



Qualidade do produto

Qualidade do processo

4
Processos, mtodos, tcnicas e pessoas...
! Como melhorar a codificao? (o que uma boa codificao?)
! Como melhorar o teste de software? (o que um bom teste?)
! Como fazer boas modelagens? (o que uma boa modelagem?)
! O que leva algum a usar um processo / mtodo / tcnica?
! Quais os problemas que afetam a indstria 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 adoo de uma
tcnica / mtodo / processo?
! Quais os benefcios da adoo de uma tcnica / mtodo /
processo?
! ...
5
Medio / Gerncia de Configurao / Aquisio /
Garantia da Qualidade / Gerncia de Portflio de Projetos
Avaliao e Melhoria do Processo Organizacional
Definio do Processo Organizacional
Gerncia de Reutilizao / Gerncia de Recursos
Humanos / Gerncia de Projetos (evoluo)
Desenvolvimento de Requisitos
Projeto e Construo do Produto
Integrao do Produto
Verificao / Validao
Gerncia de Decises
Desenvolvimento para Reutilizao
Gerncia de Riscos
G
F
E
D
C
Gerncia de Requisitos
Gerncia de Projetos
(sem processos adicionais)
(inclui controle estatstico e
gerncia quantitativa)
A
B
Parcialmente
Gerenciado
Gerenciado
Parcialmente
Definido
Largamente
Definido
Definido
Gerenciado
Quantitativamente
Em Otimizao
Gerncia de Projetos (evoluo)
(inclui controle estatstico e
gerncia quantitativa)
~
CMMI 2
~
CMMI 3
~
CMMI 4
~
CMMI 5
Nveis de Maturidade MPS.BR
2
Pesquisa x Cincia
! Objetivos de Pesquisa
Fazer uma contribuio para a Cincia
Responder a uma pergunta
de interesse para a comunidade cientfica
ainda no respondida anteriormente
de relevncia para o interesse social
A parte mais difcil encontrar o problema
! Objetivo da Cincia: resolver problemas
Qual o problema que voc est resolvendo?
Comece de um desafio prtico
Extraia da um problema terico
Certifique-se que o problema
relevante
no-resolvido
resolvvel
7
Fonte: Santoro, F., Notas de Aula Apresentao do Metodologia da Pesquisa Cientfica 2010.2,
Programa de Ps-Graduao em Informtica - UNIRIO
Pesquisa
! Tipos de Pesquisa
Nem toda pesquisa feita da mesma forma
Os mtodos de pesquisa so bem diversos dependendo do
campo de conhecimento
! Mestre: Ttulo de qualificao tcnico-cientfica
domina as tcnicas de investigao
produziu um resultado novo (ou relevante)
comunicou seus resultados de forma efetiva
! Mestre X Doutor
tempo de investigao
profundidade da pesquisa
qualidade da formao
8
Fonte: Santoro, F., Notas de Aula Apresentao do Metodologia da Pesquisa Cientfica 2010.2,
Programa de Ps-Graduao em Informtica - UNIRIO
Divagaes
! Uma tese de doutorado no uma dissertao de mestrado
que no uma monografia de ps-graduao que no um
projeto de final de curso de graduao.
O inverso tambm se aplica.
! Um trabalho para uma empresa no um trabalho de
pesquisa.
Gostaramos que todo trabalho de pesquisa fosse aplicado a
empresas. Nem sempre isso possvel por N fatores.
Infelizmente...
! No entanto, Relatos de Experincias so 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 experincia, maiores so
as chances de publicao.
O que d para publicar?
! Projeto Final de Graduao
! Projeto Final de Ps-graduao
! Dissertao de Mestrado
! Tese de Doutorado
! Experincias em Empresas e de Empresas
! Cuidado com o foco, com a forma de descrio e na
descrio das reais contribuies do trabalho
10
O que d para publicar?
! O que posso publicar?
A audincia do evento importante para determinar o que
relevante em cada contexto
! Onde publicar?
A chamada de trabalhos importante para entender o tipo de
trabalho que se espera dos autores
! Por que devo publicar?
Troca de experincias
Aprendizado em Engenharia de Software vem muitas vezes do
uso das tcnicas e observaes do estado da prtica
11
Relatos de Experincia
! Devem contar uma histria informativa e como ela se
reflete em situaes mais gerais
! No entre em detalhes irrelevantes sobre o experimento


Chamada de Trabalhos do SBQS
! Relatos de Experincia: Artigos de alta qualidade
descrevendo e analisando a aplicao de processos,
mtodos ou ferramentas de qualidade de software,
contextualizando a experincia e mostrando os resultados
obtidos e lies aprendidas, em uma experincia prtica
com contribuio para a indstria de software.
! Trabalhos tcnicos: artigos de alta qualidade descrevendo
resultados inditos sobre de pesquisa na rea de qualidade
de software com contribuio acadmica.

12
Fonte: Santoro, F., Notas de Aula Apresentao do Metodologia da Pesquisa Cientfica 2010.2,
Programa de Ps-Graduao em Informtica UNIRIO.
3
Um bom artigo de pesquisa
Um bom artigo de pesquisa deve responder a um nmero de
questes:
! O que, precisamente, voc alega ser a sua contribuio?
Que questes voc respondeu?
Por que o leitor deveria se importar?
De que questes maiores (larger questions) ele trata?
! Qual o seu novo resultado?
Qual novo conhecimento voc gerou que o leitor pode utilizar em outra
situao?
Em que trabalho anterior (seu ou de outros) voc se baseou? Em que
voc prov uma alternativa superior?
Como o seu resultado diferente ou melhor que este trabalho anterior?
Qual, precisamente e em detalhes, o seu novo resultado?
! Por que o leitor deve acreditar no seu resultado?
Que padro deve ser utilizado para avaliar sua afirmao?
Que evidncia concreta mostra que o seu resultado satisfaz sua
afirmao?
13
Fonte: SHAW, M., Writing Good Software Engineering Research Papers Minitutorial, ICSE 2003.
Estrutura do Texto
! A estrutura de um artigo cientficio segue um padro pr-
determinado
Em geral, no h uma regra, mas a estrutura abaixo segue o
senso comum em uso
No h muitas possibilidades de inovar nesta organizao.
! Estrutura Bsica:
Introduo
Sesses Pertinentes
Concluso
Referncias
14
Estrutura do Texto
! Itens comuns na estrutura do texto:
Ttulo
Autores
Abstract / Resumo
Introduo
Reviso da Literatura
Trabalhos Similares
Proposta / Descrio da Experincia
Lies Aprendidas
Concluses / Consideraes Finais
Agradecimentos
Referncias Bibliogrficas
Anexos e Apndices
15
Ttulo
! O ttulo deve ser curto e indicativo do trabalho que ser
apresentado
! Escolha um ttulo que valorize o trabalho, mas cuidado para
no ser arrogante ou presunoso
! Evite o uso de perguntas e termos em ingls
Vale para o texto como um todo
Ningum garante que as perguntas vo ser respondidas (e, em
geral, voc no ir respond-las. Acredite)
16
Implantao do Nvel F do MR-MPS Combinando Caractersticas do Processo
Unicado com Prticas SCRUM
Autores
! Deve-se listar os envolvidos com o trabalho
Em geral, a ordem dos autores indica o esforo para a
elaborao do artigo e/ou o envolvimento no trabalho relatado
Quando se descreve um relato de experincia em uma empresa
comum incluir as pessoas chave da empresa como autores
mesmo quando elas no participam da escrita do texto
Isso no uma regra, no entanto
! Para cada autor, deve-se indicar a filiao
Pode haver mltipla filiao
Deve-se indicar o e-mail de contato dos autores
17
Tatiane Silva
1
, Rogrio Magela
1
, Gleison Santos
2
, Natlia Chaves Lessa Schots
3
, Ana Regina Rocha
3

1
Athenas Engenharia de Software Av. Rio Branco, 12, 14 andar, Centro
CEP 20090-000 Rio de Janeiro RJ Brasil
2
Programa de Ps-Graduao em Informtica 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, gleison.santos@uniriotec.br, {natalia,
darocha}@cos.ufrj.br
Abstract
! No o trailer de um filme (no deixe o espectador
imaginando qual ser o final)
! Venda seu trabalho no abstract
! Se voc no conseguir resumir sua contribuio em meia
pgina algo est muito errado no seu trabalho
! No entra reviso bibliogrfica
! Inclua sempre no abstract
O principal problema analisado
Um esboo da soluo utilizada
As concluses alcanadas
! 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 Apresentao do Metodologia da Pesquisa Cientfica 2010.2,
Programa de Ps-Graduao em Informtica UNIRIO. apud Wazlawick, 2007
4
Abstract e Resumo
! Todo artigo deve ter um resumo
As vezes, necessrio ter verses em ingls e em portugus
! O contedo do abstract deve ser o mesmo do resumo
Note que s vezes a estrutura da frase em portugus e em
ingls no igual e adaptaes tem que ser feitas
No use o tradutor automtico para gerar a verso do abstract
19
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 rst
version was based on what would become the Unied Process and now it has evolved to support SCRUM
agile practices and the MPS.BR Reference Model Level F practices.

Resumo. No 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 evoluo do processo de desenvolvimento de software da
Athenas Software desde a sua primeira verso baseada no que viria se tornar o Processo Unicado at o
momento atual onde se alinham, tambm, prticas geis do SCRUM e as prticas associadas ao Nvel F do
Modelo de Referncia do MPS.BR.
Introduo
! Contextualize rapidamente o tema de pesquisa (no inicie
nos primrdios)
! Apresente os objetivos, metodologia, justificativa,
resultados esperados, limitaes e estrutura da dissertao
! Caracterize o problema que voc descrever e a questo
que deseja discutir.

! Termine sempre apresentando a estrutura do artigo.
Fonte: Santoro, F., Notas de Aula Apresentao do Metodologia da Pesquisa Cientfica 2010.2,
Programa de Ps-Graduao em Informtica UNIRIO. apud Wazlawick, 2007
Este artigo possui o objetivo de apresentar como o processo da Athenas evoluiu ao longo do tempo e
as melhorias e lies aprendidas identicadas pela empresa durante esta evoluo. Na Seo 2, um breve
histrico da evoluo do processo de desenvolvi#mento apresentado, bem como algumas caractersticas
peculiares da empresa. As ca#ractersticas do atual processo e as ferramentas utilizadas so discutidas nas
Sees 3 e 4, respectivamente. Por m, na Seo 5 so apresentadas as consideraes nais junta#mente
com resultados obtidos com a melhoria do processo e algumas lies aprendidas.
Tipos de questes de pesquisa em Engenharia
de Software
21
Fonte: SHAW, M., Writing Good Software Engineering Research Papers Minitutorial, ICSE 2003.
Tipo de Questo Exemplos
Mtodo ou meio de
desenvolvimento
Como podemos fazer / criar / modificar / evoluir (ou
automatizar fazendo) X?
Qual a melhor maneira de fazer/criar/modificar/evoluir X?
Mtodo para anlise
ou avaliao
Como posso avaliar a qualidade / corretude de X?
Como eu escolho entre X e Y?
Design, avaliao ou
anlise de uma
instncia particular
O quo bom Y? Qual a propriedade X do artefato/
mtodo Y?
O que um (melhor) design, implementao, manuteno
ou adaptao para a aplicao X?
Como X se compara a Y?
Qual o estado atual de X / prtica de Y?
Generalizao ou
caracterizao
Dado X, qual ser Y (necessariamente)?
O que, exatamente, ns entendemos por X? Quais so suas
caractersticas importantes?
Qual um bom modelo formal/experimental para X?
Quais so as variedades de X, como esto relacionadas?
Estudo de viabilidade
ou exploratrio
X realmente existe, e, se sim, como ele se parece?
possvel, realmente, realizar (accomplish) X?
Tipos de questes de pesquisa em Engenharia
de Software
22
Fonte: SHAW, M., Writing Good Software Engineering Research Papers Minitutorial, ICSE 2003.
Tipo de Questo Exemplos
Mtodo ou meio de
desenvolvimento
Como podemos fazer / criar / modificar / evoluir (ou
automatizar fazendo) X?
Qual a melhor maneira de fazer/criar/modificar/evoluir X?
Mtodo para anlise
ou avaliao
Como posso avaliar a qualidade / corretude de X?
Como eu escolho entre X e Y?
Design, avaliao ou
anlise de uma
instncia particular
O quo bom Y? Qual a propriedade X do artefato/
mtodo Y?
O que um (melhor) design, implementao, manuteno
ou adaptao para a aplicao X?
Como X se compara a Y?
Qual o estado atual de X / prtica de Y?
Generalizao ou
caracterizao
Dado X, qual ser Y (necessariamente)?
O que, exatamente, ns entendemos por X? Quais so suas
caractersticas importantes?
Qual um bom modelo formal/experimental para X?
Quais so as variedades de X, como esto relacionadas?
Estudo de viabilidade
ou exploratrio
X realmente existe, e, se sim, como ele se parece?
possvel, realmente, realizar (accomplish) X?
Produzem mtodos de
desenvolvimento ou anlise que
os autores investigaram em uma
situao (setting), mas que
presumivelmente podem ser
aplicados em outros contextos.
Tipos de questes de pesquisa em Engenharia
de Software
23
Fonte: SHAW, M., Writing Good Software Engineering Research Papers Minitutorial, ICSE 2003.
Tipo de Questo Exemplos
Mtodo ou meio de
desenvolvimento
Como podemos fazer / criar / modificar / evoluir (ou
automatizar fazendo) X?
Qual a melhor maneira de fazer/criar/modificar/evoluir X?
Mtodo para anlise
ou avaliao
Como posso avaliar a qualidade / corretude de X?
Como eu escolho entre X e Y?
Design, avaliao ou
anlise de uma
instncia particular
O quo bom Y? Qual a propriedade X do artefato/
mtodo Y?
O que um (melhor) design, implementao, manuteno
ou adaptao para a aplicao X?
Como X se compara a Y?
Qual o estado atual de X / prtica de Y?
Generalizao ou
caracterizao
Dado X, qual ser Y (necessariamente)?
O que, exatamente, ns entendemos por X? Quais so suas
caractersticas importantes?
Qual um bom modelo formal/experimental para X?
Quais so as variedades de X, como esto relacionadas?
Estudo de viabilidade
ou exploratrio
X realmente existe, e, se sim, como ele se parece?
possvel, realmente, realizar (accomplish) X?
Lida explicitamente com um
sistema, prtica, design ou outro
instncia de um sistema ou
mtodo. Varia de narrativas sobre
prtica industrial a comparaes
analticas de designs alternativos.
Tipos de questes de pesquisa em Engenharia
de Software
24
Fonte: SHAW, M., Writing Good Software Engineering Research Papers Minitutorial, ICSE 2003.
Tipo de Questo Exemplos
Mtodo ou meio de
desenvolvimento
Como podemos fazer / criar / modificar / evoluir (ou
automatizar fazendo) X?
Qual a melhor maneira de fazer/criar/modificar/evoluir X?
Mtodo para anlise
ou avaliao
Como posso avaliar a qualidade / corretude de X?
Como eu escolho entre X e Y?
Design, avaliao ou
anlise de uma
instncia particular
O quo bom Y? Qual a propriedade X do artefato/
mtodo Y?
O que um (melhor) design, implementao, manuteno
ou adaptao para a aplicao X?
Como X se compara a Y?
Qual o estado atual de X / prtica de Y?
Generalizao ou
caracterizao
Dado X, qual ser Y (necessariamente)?
O que, exatamente, ns entendemos por X? Quais so suas
caractersticas importantes?
Qual um bom modelo formal/experimental para X?
Quais so as variedades de X, como esto relacionadas?
Estudo de viabilidade
ou exploratrio
X realmente existe, e, se sim, como ele se parece?
possvel, realmente, realizar (accomplish) X?
Generalizaes e caracterizaes
surgem explicitamente dos
exemplos apresentados nos
artigos.
5
Tipos de questes de pesquisa em Engenharia
de Software
25
Fonte: SHAW, M., Writing Good Software Engineering Research Papers Minitutorial, ICSE 2003.
Tipo de Questo Exemplos
Mtodo ou meio de
desenvolvimento
Como podemos fazer / criar / modificar / evoluir (ou
automatizar fazendo) X?
Qual a melhor maneira de fazer/criar/modificar/evoluir X?
Mtodo para anlise
ou avaliao
Como posso avaliar a qualidade / corretude de X?
Como eu escolho entre X e Y?
Design, avaliao ou
anlise de uma
instncia particular
O quo bom Y? Qual a propriedade X do artefato/
mtodo Y?
O que um (melhor) design, implementao, manuteno
ou adaptao para a aplicao X?
Como X se compara a Y?
Qual o estado atual de X / prtica de Y?
Generalizao ou
caracterizao
Dado X, qual ser Y (necessariamente)?
O que, exatamente, ns entendemos por X? Quais so suas
caractersticas importantes?
Qual um bom modelo formal/experimental para X?
Quais so as variedades de X, como esto relacionadas?
Estudo de viabilidade
ou exploratrio
X realmente existe, e, se sim, como ele se parece?
possvel, realmente, realizar (accomplish) X?
Lidam com uma questo de uma
maneira completamente nova.
Em geral tm uma categoria
diferente daqueles que melhoram
algo previamente definido.
Resultados do ICSE 2002
26
Fonte: SHAW, M., Writing Good Software Engineering Research Papers Minitutorial, ICSE 2003.
! Importante: (resultados baseados nos abstracts)
Definio clara do problema resolvido.
Explicao de como a resposta ajudar a resolver um problema
importante em engenharia de software.
! Ao longo da histria da ES, os tipos de questes mudam
quando a maturidade de um assunto aumenta.
Reviso da Literatura
! Concentre-se em apresentar as definies e resultados da
literatura que sejam relevantes para seu objetivo
! Lembre: no um tratado sobre a histria da rea de
pesquisa e no um inventrio de tudo o que voc leu
! Organizao do captulo
Reviso dos principais conceitos bsicos
Reviso do estado da arte
Organize o texto por idias e no por autores
! Cite:
peridicos e eventos relevantes
obras recentes
obras clssicas na rea
27
Fonte: Santoro, F., Notas de Aula Apresentao do Metodologia da Pesquisa Cientfica 2010.2,
Programa de Ps-Graduao em Informtica UNIRIO. apud Wazlawick, 2007
Reviso da Literatura
! Opinio x Fatos
Uma reviso da literatura apresenta fatos sobre o assunto.
No possvel incluir opinies pessoais no texto.
Se quiser, utilize outros autores para defender o seu ponto
de vista.
Tudo deve ter referncia
! Em um relato de experincia, nem sempre a reviso da
literatura necessita ser ser muito abrangente ou complexa,
mas sempre bom ter uma seo especfica
! s vezes possvel incluir uma breve reviso da literatura
na introduo do artigo
Principalmente quando o espao curto
Ou quando o assunto de pleno conhecimento da audincia
Por exemplo, a estrutura do MPS.BR em artigos para o
WAMPS

28
29 29
Onde achar artigos?
! Anais anteriores do SBES, SBQS e WAMPS
! Portal de Peridicos Capes: http://periodicos.capes.gov.br/
Verifique se sua universidade prov acesso de qualquer computador do campus
Verifique se h possibilidade de acesso remoto atravs de proxy
! Maximizando resultados, minimizando esforo
Compendex (http://www.engineeringvillage.com/)
IEEE Explore (http://ieeexplore.ieee.org/)
Scopus (http://www.scopus.com/)
Trabalhos Similares
O que foi feito antes? Como seu trabalho diferente ou
melhor?
Em que tecnologia j existente o seu trabalho se basea?
A que tecnologia existente ou pesquisa anterior sua pesquisa
prov uma alternativa superior?
O que novo comparado ao seu trabalho anterior?
Que alternativas outros pesquisadores perseguiram e como o
seu trabalho diferente ou melhor?
! Conhecimento cresce incrementalmente.
Se voc no explicar como seu trabalho est relacionado com
outros fica complicado saber o que voc adicionou de novo.
No dizer se voc tem conhecimento de trabalhos relacionados
pode afetar a sua credibilidade...
30
Fonte: SHAW, M., Writing Good Software Engineering Research Papers Minitutorial, ICSE 2003.
6
Tipos de resultados em Engenharia de Software
O que foi feito antes? Como seu trabalho diferente ou
melhor?
! Compare:
31
Fonte: SHAW, M., Writing Good Software Engineering Research Papers Minitutorial, ICSE 2003.
O problema de galopar tem atrado muita
ateno [3,8,10,18,26,32,37].
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].
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 representao de kernel do
flitzing e obteve uma cobertura
de 90% ao relaxar a restrio de
forma que apenas estruturas
cclicas de dados fossem
proibidas.
Proposta / Descrio da Experincia
! Coloque suas afirmaes cuidadosamente
! Garanta que todas as afirmaes sejam fundamentadas
! No adianta apenas fazer uma anlise terica de uma
questo. necessrio mostrar o que esta anlise melhora
em relao s anteriores
! Uma teoria no testada na prtica no vale muito
! Artigos sobre comparao entre mtodos
J foram feitos MUITAS vezes
As vezes so MUITO MAL feitos
Um artigo deste tipo deve colocar muito bem as mtricas para
que os resultados possam ser repetidos por experincias
independentes
32
Fonte: Santoro, F., Notas de Aula Apresentao do Metodologia da Pesquisa Cientfica 2010.2,
Programa de Ps-Graduao em Informtica - UNIRIO
Tipos de resultados em Engenharia de Software
O que novo aqui?
! Os avaliadores sabem o que novo, excitante e porqu.
Qual a sua contribuio? O que foi feito alm de trabalhos
anteriores seus e de outros? O que foi feito alm suficiente
(dado os padres habituais da subdisciplina)?
melhor voc explicar do que deixar o revisor advinhar...
Use verbos que mostrem resultados, no s esforo e atividade.
! Compare:
33
Fonte: SHAW, M., Writing Good Software Engineering Research Papers Minitutorial, ICSE 2003.
Eu resolvi complementamente e genericamente...
Eu trabalhei em galopagem (ou
estudei, investiguei,
procurei, explorei).
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 acurcia do
detector padro (ou provei, demonstrei,
criei, estabeleci, encontrei, desenvolvi).
Eu automatizei a produo de
tabelas flitz a partir das
especificaes.
Com uma aplicao inovadora da
transformao blivet, eu
melhorei 10% da velocidade e
15% na cobertura em relao ao
mtodo padro.
Tipos de resultados em Engenharia de Software
34
Fonte: SHAW, M., Writing Good Software Engineering Research Papers Minitutorial, ICSE 2003.
!"#$ !"#&
$"' (# %" )(*&
"+,#, -. )( #&'&/

!"#$
Tipos de resultados em Engenharia de Software
O que, precisamente, o resultado?
Se voc introduzir um novo modelo, seja claro sobre o seu poder.
Se voc introduzir uma nova mtrica, defina-a precisamente.
Se voc introduzir um novo estilo arquitetural, padro de projeto
(ou similar), trate-o como se fosse uma nova generalizao ou
modelo.
Se sua contribuio principalmente a sntese ou integrao de
outros resultados ou componentes, seja claro sobre porque a
sntese em si uma contribuio.
Se seu artigo principalmente um relato de experincia aplicando
resultados de pesquisa a um problema prtico, diga o que o leitor
pode aprender com a experincia.
Se uma ferramenta tem um papel importante no seu artigo, qual
este papel?
Se a implementao 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.
Tipos de Validao em Engenharia de Software
36
Tipo de Validao Exemplos
Anlise Eu analisei meu resultado e, atravs de uma anlise
rigorosa, achei satisfatrio, por exemplo, ...
Avaliao Dado um critrio estabelecido, meu resultado
Experincia Meu resultado foi utilizado em exemplos reais por algum
alm de mim, e as evidncias de sua corretude/utilidade/
efetividade
Exemplo Aqui h um exemplo de como funciona em...
Persuaso Eu pensei muito sobre isso e acredito apaixonadamente
que
Afirmao forte Nenhuma tentativa sria de avaliar o resultado.
Fonte: SHAW, M., Writing Good Software Engineering Research Papers Minitutorial, ICSE 2003.
! Uma boa pesquisa requer no s um resultado, mas tambm uma
evidncia convincente que o resultado adequado/bom.
7
Resultados do ICSE 2002
37
Fonte: SHAW, M., Writing Good Software Engineering Research Papers Minitutorial, ICSE 2003.
! Importante: (resultados baseados nos abstracts)
Os tipos mais bem sucedidos de validao foram baseados em
anlise e em experincias do mundo real.
Exemplos bem escolhidos tambm foram um sucesso
Persuaso no foi persuasiva.
Revisores de artigo procuram por evidncias slidas para apoiar
seus resultados, no basta voc achar que suas idias funcionam.
Mtodos
Tipo Descrio Objetivo Caracterstica
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
interao com os
participantes
Pesquisa-ao Estratgia de conduo de
pesquisa aplicada de
natureza participativa
Promover melhorias
para a situao
Contribuir para o
conhecimento
cientfico
Pesquisador interfere
no objeto de estudo
com o propsito de
melhor-lo
Estudo de Caso Investigao emprica que
observa um fenmeno
dentro de um contexto
real
Investigar uma
entidade ou um
fenmeno dentro de
um espao de tempo
especfico
H vrios tipos:
descritivo,
interpretativo,
avaliativo etc.
Grounded Theory Conjunto de
procedimentos
sistemticos de coleta e
anlise de dados para
gerar e validar teorias
Entender
profundamente os
dados
Gerar teorias a partir
dos dados
A fundamentao
dos dados empricos
faz com que a
pesquisa fique
prxima da realidade
38 Fonte: SCHOTS, N. C. L., Uma Abordagem para a Identificao de Causas de Problemas
Utilizando Grounded Theory. Dissertao de Mestrado. COPPE/UFRJ, 2010.
Estudos de Caso
! Questo de pesquisa
! Investiga um fenmeno contemporneo
! Contexto de vida real, em que as fronteiras no so
claramente evidentes.
! Oferece entendimento
Profundo (como e por que)
Revelador (demonstrar causas-efeito)
Fonte: Yin, R. K. (2002) Case Study Research: Design and Methods. Sage, Thousand Oaks, CA.
Estudos de Caso
Tipos de Estudos de Caso
! Exploratrios
Usado em investigaes iniciais de alguns fenmenos
Visam derivar novas ideias e hipteses e formular teorias
! Descritivos
Descrevem uma situao ou fenmeno
! Explanatrio
Procuram uma explanao de uma situao ou problema
Na maior parte, mas no necessariamente, na forma de uma
relao causal
! Confirmatrios
Utilizados para testar/refutar teorias
Usado na escolha entre teorias concorrentes
Fonte: RUNENSON, P. e HST, M., Guidelines for conduction and reporting case study research in
software engineering, Empirical Software Engineering (2009) 14:131-164.
Estudos de Caso
! Requisitos
Questo de pesquisa bem definida
Interessada em como e porque um fenmeno ocorre
Deriva uma proposta de estudo que afirma
" O que o estudo mostrar
" Guiar seleo de casos
" Tipos de dados a serem coletados
! Escolhas
Escolha de casos fundamental para a pesquisa
Amostra utilizada no aleatria, sendo escolhida
Objetivo de escolher casos relevantes e representativos
Fonte: EASTERBROOK et al., Selecting Empirical Methods for Software Engineering Research.
Baseado em apresentao cedida por Rafael Cunha e Daniel Tadeu Castelo Branco.
Estudos de Caso
! Dados qualitativos
Diferentes fontes de dados so usadas
Possuem um papel central para anlises dentro de um caso
Entrevistas e observao
Coleta de dados alinhada a uma unidade de anlise bem
definida
Escolha adequada garante que o fenmeno ser focado
Empresa, projeto, equipe, desenvolvedor, produto
especfico, etc.
! Tipo de estudo mais adequado quando o reducionismo de
experimentos controlados inadequado
O contexto possui um papel no fenmeno
So esperados amplos efeitos
Levam tempo para aparecer
! Sua maior fraqueza que a coleta de dados e anlise so
abertas a interpretaes e propiciam a formao de vis do
pesquisador.
Fonte: EASTERBROOK et al., Selecting Empirical Methods for Software Engineering Research.
Baseado em apresentao cedida por Rafael Cunha e Daniel Tadeu Castelo Branco.
8
Validade dos Estudos
! Convencimento dos leitores de que o estudo vlido
! Nenhum estudo perfeito e totalmente generalizvel em
todos os contextos:
O leitor deve ficar ciente disso
O levantamento das ameaas validade aumenta a confiana
do leitor nos resultados (ou no)
Validade de
construo
Verifica ser as
construes
tericas foram
interpretadas e
medidas
corretamente
Ocorre quando
variveis coletadas
no correspondem
com o significado
dos termos
tericos
Exemplo:
Eficincia
Validade
interna
Concentra-se
em verificar se
o resultado est
de acordo com
os dados
Exemplo: Uso
errado de
anlises
estatsticas
Validade externa
Concentra-se na
generalizao do
resultado
Depende da
natureza da
amostragem
Confiabilidade
Verifica se o
experimento
replicvel
Vis
Tipos de resultados em Engenharia de Software
44
Fonte: SHAW, M., Writing Good Software Engineering Research Papers Minitutorial, ICSE 2003.
Tipo Resultado Exemplos
Procedimento ou
tcnica
Jeito novo ou melhor de fazer alguma tarefa, como design,
implementao, manuteno, medidas, avaliao, seleo de
alternativas.
Modelo qualitativo
ou descritivo
Estrutura ou taxinomia para uma rea de problema; estilo
arquitetural, framework ou padro de projeto.
Modelo
experimental
Modelo preditivo experimental baseado em dados observados.
Modelo analtico Modelo estrutural que permite anlise formal ou manipulao
automtica.
Ferramenta ou
notao
Ferramenta implementada que engloba uma tcnica;
linguagem formal para apoiar a tcnica ou modelo.
Soluo especfica,
prottipo, resposta
ou julgamento
Soluo para problema que mostra aplicaes de princpios de
ES (pode ser design, prottipo ou implementao completa),
anlise cuidadosa de um sistema ou seu desenvolvimento,
resultado de uma anlise, avaliao ou comparao especfica.
Relatrio Observaes interessantes, regras de ouro (rules of thumb),
mas no suficientemente gerais ou sistemticas para se
tornarem um modelo descritivo.
Inclui tcnicas para implementao,
representao, gerncia e anlise.

A tcnica deve ser operacional
no apenas conselho ou guia, mas
um procedimento.
Tipos de resultados em Engenharia de Software
45
Fonte: SHAW, M., Writing Good Software Engineering Research Papers Minitutorial, ICSE 2003.
Tipo Resultado Exemplos
Procedimento ou
tcnica
Jeito novo ou melhor de fazer alguma tarefa, como design,
implementao, manuteno, medidas, avaliao, seleo de
alternativas.
Modelo qualitativo
ou descritivo
Estrutura ou taxinomia para uma rea de problema; estilo
arquitetural, framework ou padro de projeto.
Modelo
experimental
Modelo preditivo experimental baseado em dados observados.
Modelo analtico Modelo estrutural que permite anlise formal ou manipulao
automtica.
Ferramenta ou
notao
Ferramenta implementada que engloba uma tcnica;
linguagem formal para apoiar a tcnica ou modelo.
Soluo especfica,
prottipo, resposta
ou julgamento
Soluo para problema que mostra aplicaes de princpios de
ES (pode ser design, prottipo ou implementao completa),
anlise cuidadosa de um sistema ou seu desenvolvimento,
resultado de uma anlise, avaliao ou comparao especfica.
Relatrio Observaes interessantes, regras de ouro (rules of thumb),
mas no suficientemente gerais ou sistemticas para se
tornarem um modelo descritivo.
Anlise no-formal de domnio,
checklists bem embasados,
generalizaes informais bem
construdas, guia para integrao de
outros resultados, observaes
interessantes bem organizadas.
Tipos de resultados em Engenharia de Software
46
Fonte: SHAW, M., Writing Good Software Engineering Research Papers Minitutorial, ICSE 2003.
Tipo Resultado Exemplos
Procedimento ou
tcnica
Jeito novo ou melhor de fazer alguma tarefa, como design,
implementao, manuteno, medidas, avaliao, seleo de
alternativas.
Modelo qualitativo
ou descritivo
Estrutura ou taxinomia para uma rea de problema; estilo
arquitetural, framework ou padro de projeto.
Modelo
experimental
Modelo preditivo experimental baseado em dados observados.
Modelo analtico Modelo estrutural que permite anlise formal ou manipulao
automtica.
Ferramenta ou
notao
Ferramenta implementada que engloba uma tcnica;
linguagem formal para apoiar a tcnica ou modelo.
Soluo especfica,
prottipo, resposta
ou julgamento
Soluo para problema que mostra aplicaes de princpios de
ES (pode ser design, prottipo ou implementao completa),
anlise cuidadosa de um sistema ou seu desenvolvimento,
resultado de uma anlise, avaliao ou comparao especfica.
Relatrio Observaes interessantes, regras de ouro (rules of thumb),
mas no suficientemente gerais ou sistemticas para se
tornarem um modelo descritivo.
Resultados do ICSE 2002
47
Fonte: SHAW, M., Writing Good Software Engineering Research Papers Minitutorial, ICSE 2003.
! Importante: (resultados baseados nos abstracts)
Muitos projetos de pesquisa produzem resultados de vrios
tipos. Muitos autores apresentam ideias individuais em
conferncias 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 crticos.
Tipos de resultados em Engenharia de Software
O que, precisamente, voc alega ser a sua contribuio?
! Os resultados satisfazem completamente suas alegaes?
As definies so precisas e os termos so utilizados
consistentemente?
Se os resultados deveriam ser utilizados em sistemas grandes,
explique porque voc acha que ele escalvel.
Se o seu mtodo automtico, no deveria necessitar de
humanos. Explique as excesses ou configuraes manuais.
Se os resultados so distribudos, no deveria haver um
controlador/servidor central. Explique qual parte distribuda.
Se est propondo uma nova notao para um problema antigo
explique claramente porque ela superior s anteriores.
Se o artigo um relato de experincia, explique que ideia o
leitor pode tirar do artigo em outras situaes ou como o leitor
pode aumentar sua confiana em aplicaes alm do exemplo
apresentado.
48
Fonte: SHAW, M., Writing Good Software Engineering Research Papers Minitutorial, ICSE 2003.
9
Lies Aprendidas
! Uma lio 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.
! Tenha trabalho e cuidado em descrever extamente quais
so as contribuies da sua experincia para a audincia.
! Se o leitor no se convencer da pertinncia e aplicabilidade
das suas lies aprendidas, elas no sero consideradas
vlidas por ele e o seu artigo ter menos chances de ser
lido/aprovado.
49
Lies Aprendidas
Compare os exemplos abaixo:
! Texto simples (simplrio?):
O projeto usou casos de uso genricos.
! Texto estruturado (simples?):
50
Ttulo: Utilizao de casos de uso genricos
Problema: Alto esforo para gerar casos de uso.
Consequncia do
problema:
Aumento do prazo e custo do projeto.
Causa do
problema:
Falta de mecanismos para fazer reutilizao de casos de uso.
Soluo para o
problema:
Utilizar casos de uso genricos para funes similares nos projetos
(por exemplo, funes de incluir, alterar e excluir dados).
Resultado da
soluo:
Diminuio do esforo e, consequentemente, do prazo e custo para
construir casos de uso.
Concluses / Consideraes Finais
! Sumrio do que foi discutido no artigo
! Discusso das principais lies aprendidas
! Sumrio das principais contribuies do artigo
! Apresentao das lies aprendidas do trabalho
! Discusso de limitaes
No demrito ter limitaes
! Discusso de trabalhos futuros
No significa que voc ir desenvolv-los, apenas que h
possveis desdobramentos/evolues do seu trabalho.
! Concluses ou Consideraes Finais? Qual o foco da sesso?
Concluir alguma coisa
Sumarizar o que foi discutido no artigo
51
Concluses / Consideraes Finais
! Explique como o desenvolvimento o ajudou a atingir cada
um dos objetivos do trabalho
! Apresente argumentos a favor e contra seu trabalho
(limitaes)
! Seja o maior crtico do seu prprio trabalho
! Cuidado com concluses fortes
! Procure apresentar as lies aprendidas e como elas podem
ser aplicadas
! Trabalhos futuros:
Aponte para pesquisa futura, no atividades futuras
O leitor ter pouco interesse em saber o que voc pretende
fazer no futuro
52
Fonte: Santoro, F., Notas de Aula Apresentao do Metodologia da Pesquisa Cientfica 2010.2,
Programa de Ps-Graduao em Informtica UNIRIO. apud Wazlawick, 2007
Tipos de Validao em Engenharia de Software
Por que um leitor deveria acreditar no seu resultado?
! Os argumentos apresentados no artigo so persuasivos?
! Que evidncias so apresentadas para apoiar suas alegaes?
! Que tipo de evidncia oferecida? Este tipo habitual?
! O tipo de avaliao descrita de forma clara e correta?
Experimentos controlados requerem mais que coleta de dados
Estudos de caso requerem mais que discusso de situaes
! A validao est relacionada a suas alegaes?
Se voc alega melhora de desempenho, a validao tem que ser
feita sobre o desempenho no facilidade de uso
! A sua ideia to interessante e potencialmente poderosa que
deve ser exposta apesar da pouca evidncia concreta?
53
Fonte: SHAW, M., Writing Good Software Engineering Research Papers Minitutorial, ICSE 2003.
Tipos de Validao em Engenharia de Software
Por que um leitor deveria acreditar no seu resultado?
! Autores tendem a ter problemas em determinadas situaes:
Se voc alega melhoria em uma arte anterior, compare seu
resultado objetivamente em relao quela arte anterior.
Se voc usou uma tcnica de anlise, siga suas regras.
Se o uso da tcnica no habitual na Engenharia de
Software, explique a tcnica, explique seu uso, estrutura e
regras, seja claro sobre sua aderncia tcnica.
Se voc oferece experincia prtica como evidncia de seu
resultado, estabelea o efeito que a sua pesquisa teve.
Se voc executou um experimento controlado, explique o projeto
do experimento.
Hipteses? Tratamento? O que est sendo controlado? Dados
coletados? Como analisou? Os resultados so significativos?
Quais os fatores de confuso? Suas concluses vm dos dados
experimentais?
54
Fonte: SHAW, M., Writing Good Software Engineering Research Papers Minitutorial, ICSE 2003.
10
Tipos de Validao em Engenharia de Software
Por que um leitor deveria acreditar no seu resultado?
! Autores tendem a ter problemas em determinadas situaes:
(cont.)
Se voc executou um estudo experimental, explique como voc
mediu, como voc analisou e o que concluiu.
Que dados foram coletados e como? Como a anlise est
relacionada com o objetivo de apoiar suas alegaes sobre o
resultado?
No confunda correlao com causalidade.
Se voc usou um pequeno exemplo para explicar o resultado,
proveja evidncia adicional do seu uso prtico e escalabilidade.
55
Fonte: SHAW, M., Writing Good Software Engineering Research Papers Minitutorial, ICSE 2003.
Agradecimentos
! Agradecimentos devem vir em uma sesso prpria, aps as
concluses e antes das referncias bibliogrficas
! Que tipos de agradecimentos so comuns?
Apoio da empresa
Apoio de algum rgo de fomento
Pessoas que contriburam de alguma forma no trabalho
Pessoas que participaram de alguma pesquisa ou estudo
56
Referncias Bibliogrficas
! Referncia bibliogrfica no sinnimo de bibliografia
recomendada!
Todos os textos utilizados devem ser referenciados
Textos no utilizados no devem ser relatados
! Evite o uso de referncias muito antigas
O uso de referncias antigas mais aceitvel quando se trata
de um texto clssico ou precussor da rea
Por exemplo, citaes ao mito do homem-ms ou ao GQM
O uso de muitas referncias antigas pode indicar que a reviso
da literatura tendenciosa e/ou ultrapassada
O quanto muito antigo? Use o bom senso #
! Se voc no referenciar, plgio. E plgios no so
tolerados.
! Leiam os artigos referenciados, no copie trechos de reviso
da literatura de outros.
57
Referncias Bibliogrficas
! As referncias devem ser identificadas ao longo do texto do
artigo e listadas ao final do texto.
! Referncias ao longo do texto
Bl bl bl (FULANO, 2008)
Bl bl bl (SICRANO et al., 2008)
Segundo FULANO (2008)
Segundo SICRANO et al. (2008)
FULANO (2008) afima que ...
SICRANO et al. (2008) afirmam que ...
! Referncias 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.
Softex (2011) MPS.BR - Melhoria de Processo do Software Brasileiro, Guia Geral.
Disponvel 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 (PROFES2007), Latvia.
58
Referncias Bibliogrficas
! Exemplo de formatao:
Ver template de artigo da conferncia
Em artigos nacionais, muitas vezes (como no WAMPS ou no
SBQS) utiliza-se o padro da SBC
Regras da COPPE (http://www.coppe.ufrj.br/ensino/cpgp.html)
Regras da ABNT
! Revise cuidadosamente o texto para ver se toda a
referncia citada e vice versa
59
Anexos e Apndices
! Anexo um texto ou documento no elaborado pelo autor
do Trabalho Cientfico (TC) (monografia, tese etc.).
! Apndice um texto ou documento elaborado pelo autor
do Trabalho Cientfico.
! Ou seja, se foi necessrio voc criar uma entrevista, um
relatrio, ou qualquer documento com o escopo de
complementar sua argumentao, deve-se utilizar o termo
Apndice e no Anexo.
! Exemplos:
ANEXO A Documento ou texto no elaborado pelo autor
APNDICE A Documento ou texto elaborado pelo autor
60
Fonte: TCNICAS, Associao Brasileira de Normas. NBR 14724 - Informao e documentao
trabalhos acadmicos apresentao. Rio de Janeiro: Impresso no Brasil, 2010. apud
http://www.tudosobremonografia.com/2011/01/diferenca-entre-anexo-e-apendice.html
11
Televiso, Petrleo, Homens e Ilhas
! Redao:
Clareza
Objetividade
Encadeamento
Resultados
! Estrutura do pargrafo segue a estrutura do texto:
Introduo
Desenvolvimento
Concluso
61
A forma do texto
! A forma do texto influencia na qualidade geral do trabalho.
Se a forma no est adequada difcil avaliar as reais
contribuies dos autores.
Um artigo com a estrutura inadequada pode ser recusado.
Um artigo mal escrito tem mais chances ainda de ser recusado.
! Garanta sempre que o portugus do texto esteja impecvel.
Um texto mal escrito no vai conseguir passar a mensagem
que os autores querem (e acham que conseguiram escrever).
62
Redao
Mensagem:
! O texto tem que ter uma mensagem, a idia principal
que se quer mostrar.
! Ter certeza que voc sabe o que :
Faa um resumo dessa mensagem em poucas palavras
Garanta que a mensagem est refletida em:
Ttulo
Resumo
Introduo; Estrutura e Concluso
63
Fonte: Orientaes para orientandos - Uma experincia em BD, Marta Mattoso, III Workshop de
Teses e Dissertaes em Bancos de Dados - 19. Simpsio Brasileiro de Bancos de Dados
Redao
Contribuio:
! No assuma que sua contribuio bvia.
1. Diga o que voc vai dizer
2. Diga
3. Diga o que voc acabou de dizer
! No deixe para o leitor a tarefa de descobrir o que
importante, diga explicitamente
64
Fonte: Orientaes para orientandos - Uma experincia em BD, Marta Mattoso, III Workshop de
Teses e Dissertaes em Bancos de Dados - 19. Simpsio Brasileiro de Bancos de Dados
Redao
Compreenso / Avaliao
! Facilite a compreenso/avaliao do seu trabalho,
apresentando clara e explicitamente:
1. Caracterizao do problema
2. Objetivo da tese (garanta que o objetivo ser o MESMO ao
longo de toda a tese)
3. Como o objetivo foi atendido
4. Porque o objetivo foi atendido
5. Contribuio
6. Originalidade
65
Fonte: Orientaes para orientandos - Uma experincia em BD, Marta Mattoso, III Workshop de
Teses e Dissertaes em Bancos de Dados - 19. Simpsio Brasileiro de Bancos de Dados
Redao
Avaliao
! O que a banca examinar:
Trabalho original compreendendo um grau satisfatrio de
atividades de pesquisa
Anlise crtica dos tpicos e trabalhos relevantes
Competncia no mtodo de pesquisa e na rea de pesquisa
escolhida
Independncia na abordagem do problema ou tcnica
apresentada
Texto bem elaborado e referncias adequadas
! E para relatos de experincias?
A descrio do contexto onde a experincia relatada
adequada?
A experincia e seus resultados so vlidos?
As lies aprendidas so interessantes e trazem algo de novo?
66
Fonte: Orientaes para orientandos - Uma experincia em BD, Marta Mattoso, III Workshop de
Teses e Dissertaes em Bancos de Dados - 19. Simpsio Brasileiro de Bancos de Dados
12
Escrevendo Textos
! Texto:
A lngua utilizada no MSN no portugus
O dialeto do telemarketing no portugus
Um artigo um texto tcnico
Comeo, meio e fim, nesta ordem
Textos soltos no dizem nada
Modos verbais: Imperativo, Subjuntivo e Indicativo
A reforma ortogrfica j est valendo!
! Opinies:
Se for da literatura, colocar referncia.
Se no for, cuide-se!
! Uso de termos pouco formais
"sade" de empresas
! Definir todos os termos
! Cuidado ao usar o mesmo termo em diferentes acepes
67
Textos Ambguos
! Quantos meses do ano tm 28 dias?
(a) 1 (Fevereiro)
(b) 12 (Todos os meses do ano)
(c) Nenhum, pois fevereiro s vezes tem 29 dias
! Considere as seguintes frases, extradas de diferentes
matrias jornalsticas, e responda ao que se pede.
I. Nos ltimos meses, o debate sobre o aquecimento global
vem, com perdo do trocadilho, esquentando.
II. Preso vigia acusado de matar empresrio.
! a) Identifique, na frase I, o trocadilho a que se refere o redator e
explique por que ele pede perdo por t-lo produzido.
! b) correto afirmar que na frase II ocorre ambigidade? Justifique
sua resposta.
http://oglobo.globo.com/educacao/vestibular/arquivos/Fuvest2009_2afase_portugues.pdf

68
Um texto acadmico no pode levar a duplas interpretaes.
A interpretao no pode depender do leitor, deve ser explcita e nica.
Textos Ambguos

http://oglobo.globo.com/educacao/vestibular/arquivos/Fuvest2009_2afase_portugues.pdf
69
Figuras de Linguagem: Texto cientfico no texto literrio.
Conotao e Donotao
! Texto Conotativo:
Conotao a significao subjetiva da palavra; ocorre quando
a palavra evoca outras realidades por associaes que ela
provoca
! Texto Denotativo:
Denotao a significao objetiva da palavra; a palavra em
"estado de dicionrio


Compare:
! Quem est na chuva para se molhar.
! Quando algum opta por uma determinada experincia,
deve assumir todas as regras e conseqncias decorrentes
dessa experincia.
70
Em qual das duas classificaes voc acha que um texto cientfico
deveria se encaixar?
Fonte: http://acd.ufrj.br/~pead/tema04/denotacaoeconotacao.html
Uso de Palavras fortes
! Um ativo reutilizvel possui valor imensurvel tendo em
vista seu potencial para reduzir o esforo de execuo do
processo e/ou pelo conhecimento explcito que contm.
Compare:
! Um ativo reutilizvel possui grande valor tendo em vista
seu potencial para reduzir o esforo de execuo do
processo e/ou pelo conhecimento explcito que contm.

71
No use palvras fortes, o artigo no para causar espcie...
Exemplos de possveis palavras fortes:
! Sempre
! Nunca
! Imprescindvel
! Imensurvel
As palavras dependem do contexto em que esto inseridas.

Sujeito preposicionado
Uso incorreto de ponto-e-vrgula
! Tendo em vista as dificuldades enfrentadas no
gerenciamento do Projeto de Melhoria de Processos de
Software, multiplicadas pela complexidade do ambiente das
corporaes; e da necessidade cada vez mais crescente das
empresas alcanarem suas metas e objetivos diretamente
entrelaados ao planejamento estratgico, pode-se
relacionar a estes projetos as mesmas ondas definidas pelo
PMI.

Compare:
! ... da necessidade cada vez mais crescente de as empresas
alcanarem suas metas ...
! ... ambiente das corporaes e da necessidade ...
72
As regras do portugus devem ser seguidas.
Por mais que as estruturas possam parecer estranhas algumas vezes
13
Uso excessivo (incorreto) de vrgulas
Verbo na 1 pessoa
! Vrias so as definies de projetos que podem ser
encontradas na literatura e, a seguir destacamos algumas
delas:

Compare:
! Vrias so as definies de projetos que podem ser
encontradas na literatura e a seguir so destacadas
algumas delas:
! Vrias so as definies de projetos que podem ser
encontradas na literatura e, a seguir, so destacadas
algumas delas:
! Vrias so as definies de projetos que podem ser
encontradas na literatura:
73
As regras do portugus devem ser seguidas.
Deve-se procurar sempre que o texto seja fcil de ler.
Uso excessivo de vrgulas
! Projetos que possuem alto valor para os benefcios padro 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 prximos
subprocessos.
Compare:
! Projetos que possuem alto valor para os benefcios padro 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 execuo
dos subprocessos seguintes.
74
As regras do portugus devem ser seguidas.
Vrgula no para pausa.
No se separa o sujeito do verbo por vrgula.
Uso insuficiente de vrgulas
! Assim um novo desafio tem surgido para as organizaes ...
Compare:
! Assim, um novo desafio tem surgido para as organizaes ...
! Algumas organizaes se destacam por possurem 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:
! Algumas organizaes se destacam por possurem 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.
75
As regras do portugus devem ser seguidas.
Deve-se procurar sempre que o texto seja fcil de ler.
Crase
! E desta forma prover a alta gerncia, patrocinadores,
interessados e gerente, uma viso consolidada de todos os
projetos que compem o programa.

Compare:
! E desta forma, prover alta gerncia, patrocinadores,
interessados e gerentes, uma viso consolidada de todos
os projetos que compem o programa.
76
As regras do portugus devem ser seguidas.
Ateno regncia dos verbos.
Por exemplo, o verbo visar transitivo indireto, mas no Brasil costumamos
suprimir a preposio antes de infinitivo

Quando que voc vai comprar a sua gramtica?
Uso de Verbos na 1 Pessoa
Concordncia
! Por isso, definiremos primeiramente o conceito de
projetos, gerncia de projetos e posteriormente os conceitos
de portflio e gerncia de portflio.

Compare:
! Por isso, sero definidos primeiramente os conceitos de
projetos e gerncia de projetos e, posteriormente, os
conceitos de portflio e gerncia de portflio.
77
Evite utilizar verbos na 1a pessoa. Altere a frase para deixar o texto
impessoal. Pode-se utilizar a voz passiva.
Essa regra no se aplica totalmente a textos em ingls (onde voz passiva
nem sempre indicada e pode deixar a estrutura da frase confusa).

E, s para no perder o costume:
As regras do portugus devem ser seguidas.
Uso de Advrbios de Modo
! Por isso, sero definidos primeiramente o conceito de
projetos, gerncia de projetos e posteriormente os
conceitos de portflio e gerncia de portflio.

Compare:
! Por isso, sero definidos a princpio o conceito de projetos,
gerncia de projetos e, depois, os conceitos de portflio e
gerncia de portflio.
! Por isso, sero definidos o conceito de projetos, gerncia de
projetos e os conceitos de portflio e gerncia de portflio.

78
O texto deve ser fcil e agradvel de ler.
14
Consistncia entre Texto e Referncias
! Diversos estudos indicam que a estratgia de negcio pode
ser alcanada ou ligada gerncia de portflio atravs da
seleo e execuo dos projetos adequados dentro do
processo de alinhamento estratgico (SRIVANNABOON,
2006).
Compare:
! Estudos indicam que a...
79
Se so diversos, por que s h uma referncia?
Redundncia
! O principal objetivo dessa atividade decidir se o projeto
deve ser aprovado ou postergado baseando-se no critrio
de balanceamento atravs da sobreposio do mapa de
investimento estratgico desejado e o mapa de
investimento estratgico atual. Assim, um objetivo
importante dessa atividade balancear os investimentos
entre as reas e subreas de investimento.
Compare:
! O principal objetivo dessa atividade decidir se o projeto
deve ser aprovado ou postergado baseando-se no critrio
de balanceamento atravs da sobreposio do mapa de
investimento estratgico desejado e o mapa de
investimento estratgico atual. Com isso, sero
balanceados os investimentos entre as reas e
subreas de investimento.
80
A coerncia do texto deve ser mantida sempre.
Uso de Referncias no Abstract/Resumo
! O processo foi construdo com base nas melhores prticas
de gerncia de projetos PMBOK:2004 (PMBOK, 2004),
programa (PMI, 2006b) e portflio (PMI, 2006a),
encontradas na literatura, e est aderente ao processo de
gerncia de portflio de projetos da norma ISO/IEC
12207:2008 (ISO/IEC12207, 2008).

Compare:
! O processo foi construdo com base nas melhores prticas
de gerncia de projetos, programa e portflio encontradas
na literatura e est aderente ao processo de gerncia de
portflio de projetos da norma ISO/IEC 12207:2008.
81
Tecnicamente o artigo s comea aps o abstract/resumo, ento
no deveria ter referncias bibliogrficas ainda.
O abstract deve ser curto e fcil de ler.
No se esquea que o resumo do artigo, no o artigo.
Relao entre Causa e Efeito
! Estudos indicam que a estratgia de negcio pode ser
alcanada ou ligada gerncia de portflio atravs da
seleo e execuo dos projetos adequados dentro do
processo de alinhamento estratgico. Por isso, definiremos
primeiramente o conceito de projetos, gerncia de projetos
e posteriormente os conceitos de portflio e gerncia de
portflio.

Compare:
! Para melhor entendimento, faz-se necessrio definir termos
como...
! A seguir, sero definidos os conceitos de projetos, gerncia
de projetos, portflio e gerncia de portflio.
82
Citaes com Diferentes Estilos
! Gerncia de projetos o planejamento, programao e
controle de uma srie de tarefas integradas de forma a
atingir, com xito, os objetivos do projeto, para benefcio
dos envolvidos [Kerzner, 2002].
! O PMI (Project Management Institute) [1] define
gerncia de projetos como sendo a aplicao de
conhecimentos, habilidades, ferramentas e tcnicas nas
atividades do projeto com o objetivo de atender as suas
necessidades.
83
Deve-se padronizar estilo do texto e tambm das referncias.
Verifique o padro na chamada de trabalhos.
Referncia a Figuras
! ... como mostra a Figura 1 Realizao dos objetivos e metas
atravs de projetos e as restries organizacionais .
! ... como mostra a figura abaixo.

Compare:
! ... como mostra a Figura 1.
84
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 nmero sequencial.
A referncia figura no deve repetir a sua legenda.
Cuidado com o uso excessivo de figuras.
Deve haver uma explicao para cada figura.
O leitor no deve (nem tem condies de) advinhar o que a figura quer
dizer e porque ela foi inserida no texto.
A semntica das figuras importante.
Se for usar uma notao especfica, justifique/saiba por que ela foi
utilizada.
Procure no misturar notaes diferentes.


15
Tradues Incorretas / No Recomendadas
! comprehensive
abrangente
compreensivo
! to support
apoiar
suportar
! performance
desempenho
performance
http://www.ime.usp.br/~kon/ResearchStudents/traducao.html
Verifique a traduo correta para os termos que quer utilizar.
Nem sempre a traduo mais utilizada a correta
Mas tenham cuidado tambm com o portugus, utilizem a
expresso correta... Por exemplo:
- de encontro / ao encontro
- to pouco / tampouco
http://www.cintiabarreto.com.br/didatica/curiosidadesgraficas.shtml
Informalidade da Fala na Escrita
Uso de pronomes
! A organizao ir utilizar a baseline estabelecida atravs
da caracterizao como base de comparao com um
desempenho futuro.
Compare:
! A organizao utilizar a baseline estabelecida atravs da
caracterizao como base de comparao com um
desempenho futuro.
! No benchmarking interno a busca pelas melhores prticas
ocorre dentro da prpria organizao. Ele utiliza medidas
bsicas da organizao.
Compare:
! No benchmarking interno a busca pelas melhores prticas
ocorre dentro da prpria organizao. So utilizadas
medidas bsicas da organizao.
86
O texto cientfico um texto formal.
Frases Grandes
! A idia bsica por trs 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 esto sendo realizados de forma que muitas
das informaes derivadas destes projetos podem servir de base
para o planejamento ou para a anlise do desempenho de outros
projetos que esto em fase de iniciao ou em execuo.
Compare:
! A idia bsica por trs 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 esto sendo realizados. Assim, muitas das
informaes derivadas destes projetos podem servir de base para
o planejamento ou para a anlise do desempenho de outros
projetos que esto em fase de iniciao ou em execuo.
87
Deve-se procurar sempre que o texto seja fcil de ler.
Evite o uso de que nas frases.
Procure fazer as frases no maiores que 3 ou 4 linhas.
S no exagere e crie textos telegrficos
Uso de o mesmo
! Testes tm como objetivo verificar dinamicamente o
comportamento de um programa, usando um conjunto de
casos de teste adequadamente selecionados, em relao ao
comportamento esperado para o mesmo [SWEBOK, 2004].
! Testes tm como objetivo verificar dinamicamente o
comportamento de um programa, usando um conjunto de
casos de teste adequadamente selecionados, em relao ao
comportamento esperado [SWEBOK, 2004].
88
O uso de o mesmo tecnicamente no fere regras gramticais, mas
interefere no estilo do texto.
Em geral, pode-se retirar o mesmo do frase sem perda do significado.
Menos mais...

Outros vcios de linguagem:
a nvel de, atravs de, numa/num, uso de numerais (3) no texto, no-uso
de pronomes pessoais

Termos a Serem Evitados
! Advrbios
! Brincadeiras, Ironia ou
Piadas
! ruim e bom (no
julgue)
! perfeito (nada )
! uma soluo ideal
! hoje em dia,
atualmente
! em breve
! Ficamos surpresos ao
perceber que...
! parece que...
! parece mostrar que...
! diferente (de qu?)
! 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 Apresentao do Metodologia da Pesquisa Cientfica 2010.2,
Programa de Ps-Graduao em Informtica UNIRIO. apud Wazlawick, 2007
Escrevendo Textos
! 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
16
tica...
! ... em Sala de Aula
No colar ou dar cola em
provas
No plagiar o trabalho
No trapacear nas leituras e
listas de exerccio
No sobrecarregar os colegas
do grupo
No assinar presena por
colegas
Dar crdito apropriado quando
usar trabalhos de terceiros
(ver nota de rodap!)
! E na Pesquisa?
91
Fonte: Murta, L., Notas de Aula Apresentao do Curso de Engenharia de Software 1 2009/1,
Instituto de Computao - UFF
tica na Pesquisa
! Necessidade de postura tica em relao computao:
Profissionais de computao
Usurios e Clientes
Ser Humano
! Comportamento do cientista (Merton, 1942)
Comunalismo: requer que o conhecimento cientfico seja
pblico
Universalismo: requer que a cincia seja independente de raa,
cor, credo...
Desinteresse: requer que os resultados da pesquisa no sejam
manipulados
Ceticismo organizado: requer que afirmaes no devam ser
aceitas pela palavra da autoridade
92
Fonte: Santoro, F., Notas de Aula Apresentao do Metodologia da Pesquisa Cientfica 2010.2,
Programa de Ps-Graduao em Informtica - UNIRIO
tica na Pesquisa
! Algumas questes para reflexo (Wainer, 2007)
Participao em experimentos
O sujeito de um experimento em cincia da computao deve
ser informado que ele participa de um experimento ou isso
no necessrio?
Se ele tiver que ser informado, preciso que ele o seja antes
e concorde em participar, ou s e preciso que ele concorde,
aps o experimento, que os dados sejam utilizados na
pesquisa, desde que certas salvaguardas sejam tomadas?
Pesquisas qualitativas
Que garantias de anonimato da organizao na publicao
final dos resultados so apropriadas?
A organizao tem poder de veto na publicao dos
resultados?
Se a organizao j autorizou a pesquisa, preciso pedir
consentimento a cada um dos sujeitos estudados?
93
Fonte: Santoro, F., Notas de Aula Apresentao do Metodologia da Pesquisa Cientfica 2010.2,
Programa de Ps-Graduao em Informtica - UNIRIO
Plgio e Auto Plgio
! Plgio x Pesquisa
Plgio no pesquisa
Pesquisa no plgio
! Sempre referencie os autores de quem voc cita um texto
! No copie um trecho completo de um trabalho alheio,
mesmo referenciando. Isso pode ser considerado plgio.
! Auto-plgio
Posso publicar um mesmo artigo em vrios lugares diferentes?
Infelizmente no.
Descubra como transformar a experincia em outro artigo #
Mesmo quando se copia um trecho de um trabalho anterior seu
preciso referenci-lo!
Auto-plgio tem sido cada vez menos tolerado...
94
Processo de Reviso
! Os artigos submetidos a eventos cientficos sero avaliados
por revisores selecionados (em geral, 2 a 3)
! Ajuste de foco do artigo com a chamada do evento
Deve ser feito antes da submisso. Se o foco estiver errado,
aumentam as chances de o artigo ser recusado
Analise a lista de revisores para tentar inferir o possvel foco
que ser dado nas revises
! Garanta uma boa reviso prvia do artigo.
No trabalho do revisor corrigir o seu trabalho, mas sim
apontar os pontos fortes e fracos e a adequao ao evento.
! Submisso do artigo.
Verifique o sistema de submisso (no Brasil, comum o uso do
JEMS, no exterior, do EasyChair. Tambm pode ser e-mail).
Verifique a data limite (no h garantias que ela seja alterada!)
! de bom tom corrigir os itens apontados pelos revisores
(eles no foram escolhidos ao acaso), apesar de no haver
uma segunda reviso... 95
Processo de Seleo de Artigos
! 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 reviso dos artigos
! Membros do comit e coordenador decidem quais artigos
sero aceitos
Fonte: Santoro, F., Notas de Aula Apresentao do Metodologia da Pesquisa Cientfica 2010.2,
Programa de Ps-Graduao em Informtica - UNIRIO
17
Comunicao da Reviso
! Variam de acordo com a conferncia/peridico
! Avaliao numrica (notas em critrios)
Originalidade
Contedo tcnico
Relevncia
Contribuio
Referencial terico
Clareza na escrita, organizao do texto e apresentao
! Avaliao qualitativa
Resumo da contribuio
Pontos positivos
Pontos negativos
Fonte: Santoro, F., Notas de Aula Apresentao do Metodologia da Pesquisa Cientfica 2010.2,
Programa de Ps-Graduao em Informtica - UNIRIO
Critrios de Avaliao de Artigos do SBQS
! Originalidade e Contribuio:
O artigo apresentado original dentro da rea do evento,
apresentando contribuio relevante? O contedo apresentado
no artigo no foi ainda publicado em outro evento ou journal?
1: Nada original 2: Fracamente original 3: Um pouco original 4:
Bem original 5: Extremamente original
! Relevncia 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
! Caracterizao do contexto:
O artigo apresenta e caracteriza o contexto em que a
experincia foi realizada?
1: Embasamento/caracterizao ausente 2: Embasamento/
caracterizao fraca 3: Embasamento/caracterizao boa
4: Embasamento/ caracterizao tima 5: Embasamento/
caracterizao excelente
Critrios de Avaliao de Artigos do SBQS
! Qualidade tcnica:
O artigo tem qualidade tcnica?
1: Totalmente sem qualidade tcnica 2: Qualidade tcnica fraca
3: Qualidade tcnica boa 4: Qualidade tcnica tima 5:
Qualidade tcnica excelente
! Apresentao:
O artigo est bem organizado, fcil de ler e foi bem
apresentado? Considere o enquadramento dentro da
formatao do evento e a facilidade para compreenso.
1: Apresentao pssima 2: Apresentao ruim 3:
Apresentao boa 4: Apresentao tima 5: Apresentao
excelente
99
Critrios de Avaliao de Artigos do SBQS
! Experincia na prtica:
O artigo apresenta uma experincia concreta na prtica? (obs:
para relatos de experincia, obrigatrio que eles demonstrem
uma experincia na prtica)
1: Avaliao/experincia na prtica ausente 2: Avaliao/
experincia na prtica fraca 3: Avaliao/experincia na prtica
boa 4: Avaliao/experincia na prtica tima 5: Avaliao/
experincia na prtica excelente
! Resumo (Summary):
(Uma breve descrio do artigo)
! Pontos Fortes (Paper Strengths):
! Pontos Fracos (Paper Weakness):
! Comentrios para os Autores (Comments to Authors):
(Comentrios e sugestes para o autor melhorar a qualidade do
artigo)
! E ainda um campo que s os revisores veem
100
Preparando a Apresentao
! Escolhendo o Modelo de Slides
Pode parecer besteira, mas importante
Escolha um modelo bonito e simples
Contraste de cores e letras de tamanho adequado
Evite figuras de fundo e letras rebuscadas
Lembre-se que as pessoas do fundo da sala devem poder ler o
contedo dos slides
! Evite colocar muito texto nos slides
O objetivo do texto guiar a apresentao, e no ser lido
No para colocar o texto completo do artigo na apresentao
! Estrutura dos slides
Baseie-se na estrutura do texto, mas no se prenda a ela
Nem sempre a estrutura do artigo adequada em uma
apresentao
Lembre-se que o filme baseado no livro diferente do livro
101
Preparando a Apresentao
! Treinando a apresentao
Treine!
Ao falar em voz alta, conseguimos perceber se o texto flui de
forma adequada
Elimine os textos suprfluos, reorganize a apresentao
! A apresentao no dia
Fique calmo
Fale pausadamente
Demonstre segurana
No leia, apresente
V bem vestido! #
! Respondendo s perguntas
Prepare-se para as perguntas mais difceis
Se no for uma pergunta, no responda
Voc no estar participando de um debate, nada de rplicas e
trplicas
102
18
Referncias
! EASTERBROOK, S., SINGER, J., STOREY, M., DAMIAN, D., Selecting Empirical Methods
for Software Engineering Research. In F. Shull, J. Singer and D. Sjberg(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 Prtica, Prentice Hall.
! SCHOTS, N. C. L., Uma Abordagem para a Identificao de Causas de Problemas
Utilizando Grounded Theory. Dissertao 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 Cincia da Computao,
1a edio, Elsevier Editora, Rio de Janeiro.
! Curiosidades Grficas: 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 Computao na lngua de
Cames: 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 especficos. Meus agradecimentos ao auxlio prestado.
103
Como Escrever um Relato de
Experincia
Gleison Santos
gleison.santos@uniriotec.br
WAMPS 2011 - VII Workshop
Anual do MPS