SlideShare uma empresa Scribd logo
1 de 18
Baixar para ler offline
1 
WAMPS 2011 - VII Workshop 
Anual do MPS 
Como Escrever um Relato de 
Experiência 
Gleison Santos 
gleison.santos@uniriotec.br 
2 
Agenda 
q Introdução 
q Estrutura do Texto de um Relato 
q Preparação do Texto 
q Ética e Plágio 
q Processo de Revisão de um Artigo 
q Apresentação de um Artigo 
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 O principal objetivo da engenharia de software é, sem 
dúvida, melhorar a qualidade do software. 
(ROCHA et al., 2001) 
q De forma geral, pesquisadores da Engenharia de Software 
procuram melhores formas de desenvolver e avaliar 
software. 
q Pesquisadores da Engenharia de Software são motivados 
por problemas práticos. 
q Objetivos chave da pesquisa geralmente são 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. 
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. 
Necessidades do Negócio 
Qualidade do produto 
Qualidade do processo 
4 
Processos, métodos, técnicas… e pessoas... 
q Como melhorar a codificação? (o que é uma boa codificação?) 
q Como melhorar o teste de software? (o que é um bom teste?) 
q Como fazer boas modelagens? (o que é uma boa modelagem?) 
q O que leva alguém a usar um processo / método / técnica? 
q Quais os problemas que afetam a indústria de software? 
q Qual o retorno de investimento da Qualidade de Software? 
q Que fatores culturais afetam o desenvolvimento de 
software? 
q Que fatores afetam a melhoria de processos de software? 
q O que as pessoas esperam de resultados da adoção de uma 
técnica / método / processo? 
q Quais os benefícios da adoção de uma técnica / método / 
processo? 
q ... 
5 
Em Otimização 
A 
gerência quantitativa) Gerenciado 
B 
Quantitativamente 
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 
Largamente 
Definido 
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) 
Parcialmente 
Medição / Gerência de Configuração / Aquisição / 
Garantia da Qualidade / Gerência de Portfólio de Projetos 
C 
D 
E 
F 
G 
Gerência de Requisitos 
Gerência de Projetos 
(sem processos adicionais) 
(inclui controle estatístico e 
Gerenciado 
Parcialmente 
Gerenciado 
Definido 
Definido 
Gerência de Projetos (evolução) 
(inclui controle estatístico e 
gerência quantitativa) 
~ CMMI 5 
~ CMMI 4 
~ CMMI 3 
~ CMMI 2 
Níveis de Maturidade MPS.BR
2 
Pesquisa x Ciência 
q Objetivos de Pesquisa 
– Fazer uma contribuição para a Ciência 
– Responder a uma pergunta 
» de interesse para a comunidade científica 
» ainda não respondida anteriormente 
» de relevância para o interesse social 
– A parte mais difícil é encontrar o problema 
q Objetivo da Ciência: resolver problemas 
– Qual o problema que você está resolvendo? 
– Comece de um desafio prático 
– Extraia daí um problema teórico 
– Certifique-se que o problema é 
» relevante 
» não-resolvido 
» resolvível 
7 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 
Pesquisa 
q Tipos de Pesquisa 
– Nem toda pesquisa é feita da mesma forma 
– Os métodos de pesquisa são bem diversos dependendo do 
campo de conhecimento 
q Mestre: Título de qualificação técnico-científica 
– domina as técnicas de investigação 
– produziu um resultado novo (ou relevante) 
– comunicou seus resultados de forma efetiva 
q Mestre X Doutor 
– tempo de investigação 
– profundidade da pesquisa 
– qualidade da formação 
8 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 
Divagações… 
q 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 Um trabalho para uma empresa não é um trabalho de 
pesquisa. 
– Gostaríamos que todo trabalho de pesquisa fosse aplicado a 
empresas. Nem sempre isso é possível por N fatores. 
– 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. 
O que dá para publicar? 
q Projeto Final de Graduação 
q Projeto Final de Pós-graduação 
q Dissertação de Mestrado 
q Tese de Doutorado 
q Experiências em Empresas e de Empresas 
q Cuidado com o foco, com a forma de descrição e na 
descrição das reais contribuições do trabalho 
10 
O que dá para publicar? 
q O que posso publicar? 
– A audiência do evento é importante para determinar o que é 
relevante em cada contexto 
q Onde publicar? 
– A chamada de trabalhos é importante para entender o tipo de 
trabalho que se espera dos autores 
q 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 
Relatos de Experiência 
q Devem contar uma história informativa e como ela se 
reflete em situações mais gerais 
q Não entre em detalhes irrelevantes sobre o experimento 
Fonte: Santoro, F., Notas de Aula – Apresentação do Metodologia da Pesquisa Científica 2010.2, 
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 
Programa de Pós-Graduação em Informática – UNIRIO.
3 
Um bom artigo de pesquisa 
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? 
– Que questões você respondeu? 
– Por que o leitor deveria se importar? 
– 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? 
– 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? 
q 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? 
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 21030 3. 
Estrutura do Texto 
q A estrutura de um artigo científicio segue um padrão pré-determinado 
– Em geral, não há uma regra, mas a estrutura abaixo segue o 
senso comum em uso 
– Não há muitas possibilidades de inovar nesta organização. 
q Estrutura Básica: 
– Introdução 
– Sessões Pertinentes 
– Conclusão 
– Referências 
14 
Estrutura do Texto 
q Itens comuns na estrutura do texto: 
– Título 
– Autores 
– Abstract / Resumo 
– Introdução 
– Revisão da Literatura 
– Trabalhos Similares 
– Proposta / Descrição da Experiência 
– Lições Aprendidas 
– Conclusões / Considerações Finais 
– Agradecimentos 
– Referências Bibliográficas 
– Anexos e Apêndices 
15 
Título 
q O título deve ser curto e indicativo do trabalho que será 
apresentado 
q Escolha um título que valorize o trabalho, mas cuidado para 
não ser arrogante ou presunçoso 
q Evite o uso de perguntas e termos em inglês 
– Vale para o texto como um todo 
– Ninguém garante que as perguntas vão ser respondidas (e, em 
geral, você não irá respondê-las. Acredite…) 
Implantação do Nível F do MR-MPS Combinando Características do Processo 
16 
Unificado com Práticas SCRUM 
Autores 
q Deve-se listar os envolvidos com o trabalho 
– 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 
» Isso não é uma regra, no entanto 
q Para cada autor, deve-se indicar a filiação 
– Pode haver múltipla filiação 
– Deve-se indicar o e-mail de contato dos autores 
17 
Tatiane Silva1, Rogério Magela1, Gleison Santos2, Natália Chaves Lessa Schots3, Ana Regina Rocha3 
1Athenas 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, gleison.santos@uniriotec.br, {natalia, 
darocha}@cos.ufrj.br 
Abstract 
q Não é o trailer de um filme (não deixe o espectador 
imaginando qual será o final) 
q “Venda” seu trabalho no abstract 
q Se você não conseguir resumir sua contribuição em meia 
página algo está muito errado no seu trabalho 
q Não entra revisão bibliográfica 
q Inclua sempre no abstract 
– O principal problema analisado 
– Um esboço da solução utilizada 
– As conclusões alcançadas 
q Fundamental 
– Dizer qual é o problema 
– Mostrar que vale a pena resolver o problema 
– Mostrar como você resolveu o problema 
Fonte: Santoro, F., Notas de Aula – Apresentação do MetodoloWgia adaz Pleasqwuisai cCiken,tí fi2ca0 200107.2 , 
Programa de Pós-Graduação em Informática – UNIRIO. apud Wazlawick, 2007
4 
Abstract e Resumo 
q Todo artigo deve ter um resumo 
– As vezes, é necessário ter versões em inglês e em português 
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 
Introdução 
q Contextualize rapidamente o tema de pesquisa (não inicie 
nos primórdios) 
q Apresente os objetivos, metodologia, justificativa, 
resultados esperados, limitações e estrutura da dissertação 
q 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 
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? 
• 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 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, e, se sim, como ele se parece? 
• É possível, realmente, realizar (accomplish) X? 
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 22010 3. 
Tipos de questões de pesquisa em Engenharia 
de Software 
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? 
• Como X se compara a Y? 
• Qual é o estado atual de X / prática de Y? 
Generalização ou 
caracterização 
Produzem métodos de 
desenvolvimento ou análise que 
os autores investigaram em uma 
situação (setting), mas que 
presumivelmente podem ser 
aplicados em outros contextos. 
• 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, e, se sim, como ele se parece? 
• É possível, realmente, realizar (accomplish) X? 
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 22020 3. 
Tipos de questões de pesquisa em Engenharia 
de Software 
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? 
• 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 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 
Lida explicitamente com um 
sistema, prática, design ou outro 
instância de um sistema ou 
método. Varia de narrativas sobre 
prática industrial a comparações 
analíticas de designs alternativos. 
• X realmente existe, e, se sim, como ele se parece? 
• É possível, realmente, realizar (accomplish) X? 
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 22030 3. 
Tipos de questões de pesquisa em Engenharia 
de Software 
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 
Generalizações e caracterizações 
surgem explicitamente dos 
exemplos apresentados nos 
artigos. 
• 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? 
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, e, se sim, como ele se parece? 
• É possível, realmente, realizar (accomplish) X? 
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 22040 3.
5 
Tipos de questões de pesquisa em Engenharia 
de Software 
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? 
• Como X se compara a Y? 
• Qual é o estado atual de X / prática de Y? 
Generalização ou 
caracterização 
Lidam com uma questão de uma 
maneira completamente nova. 
Em geral têm uma categoria 
diferente daqueles que melhoram 
algo previamente definido. 
• 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, e, se sim, como ele se parece? 
• É possível, realmente, realizar (accomplish) X? 
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 22050 3. 
Resultados do ICSE 2002 
q Importante: (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. 
q Ao longo da história da ES, os tipos de questões mudam 
quando a maturidade de um assunto aumenta. 
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 22060 3. 
Revisão da Literatura 
q Concentre-se em apresentar as definições e resultados da 
literatura que sejam relevantes para seu objetivo 
q 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 
q Organização do capítulo 
– 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 Cite: 
– periódicos e eventos relevantes 
– obras recentes 
– obras clássicas na área 
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 
Revisão da Literatura 
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. 
» Tudo deve ter referência 
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 
– 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 
28 
29 
Onde achar artigos? 
q Anais anteriores do SBES, SBQS e WAMPS 
q Portal de Periódicos Capes: http://periodicos.capes.gov.br/ 
– Verifique se sua universidade provê acesso de qualquer computador do campus 
– Verifique se há possibilidade de acesso remoto através de proxy 
q Maximizando resultados, minimizando esforço 
– 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? 
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... 
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 23000 3.
6 
Tipos de resultados em Engenharia de Software 
O que foi feito antes? Como seu trabalho é diferente ou 
melhor? 
q Compare: 
O problema de galopar tem atraído muita 
atenção [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 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. 
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 23010 3. 
Proposta / Descrição da Experiência 
q Coloque suas afirmações cuidadosamente 
q Garanta que todas as afirmações sejam fundamentadas 
q 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 
q Uma teoria não testada na prática não vale muito 
q Artigos sobre comparação entre métodos 
– 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, 
32 
Programa de Pós-Graduação em Informática - UNIRIO 
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)? 
– É 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 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 acurácia do 
detector padrão (ou provei, demonstrei, 
criei, estabeleci, encontrei, desenvolvi). 
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. 
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 23030 3. 
Tipos de resultados em Engenharia de Software 
“Try 
not. 
Do, 
or 
do 
not. 
There 
is 
no 
try.” 
Yoda 
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 23040 3. 
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 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 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. 
– 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. 
– Se uma ferramenta tem um papel importante no seu artigo, qual 
é este papel? 
– Se a implementação de um sistema tem um papel importante no 
seu artigo, qual é este papel? 
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 23050 3. 
Tipos de Validação em Engenharia de Software 
36 
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 é… 
Exemplo • Aqui há um exemplo de como funciona em... 
Persuasão • Eu pensei muito sobre isso e acredito apaixonadamente 
que… 
Afirmação forte • Nenhuma tentativa séria de avaliar o resultado. 
q Uma boa pesquisa requer não só um resultado, mas também uma 
evidência convincente que o resultado é adequado/bom. 
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 2003.
7 
Resultados do ICSE 2002 
q Importante: (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. 
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 23070 3. 
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 
Fonte: SCHOTS, N. C. L., Uma Abordagem para a Identificação de Causas de Problemas 38 
Utilizando Grounded Theory. Dissertação de Mestrado. COPPE/UFRJ, 2010. 
Estudos de Caso 
q Questão de pesquisa 
q Investiga um fenômeno contemporâneo 
q Contexto de vida real, em que as fronteiras não são 
claramente evidentes. 
q 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 
q Exploratórios 
– Usado em investigações iniciais de alguns fenômenos 
– Visam derivar novas ideias e hipóteses e formular teorias 
q Descritivos 
– Descrevem uma situação ou fenômeno 
q Explanatório 
– 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: 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 Requisitos 
– Questão de pesquisa bem definida 
– Interessada em como e porque um fenômeno ocorre 
» Deriva uma proposta de estudo que afirma 
Ø O que o estudo mostrará 
Ø Guiar seleção de casos 
Ø Tipos de dados a serem coletados 
q Escolhas 
– Escolha de casos é fundamental para a pesquisa 
– Amostra utilizada não é aleatória, sendo escolhida 
– Objetivo de escolher casos relevantes e representativos 
Fonte: EASTERBROOK et al., Selecting Empirical Methods for Software Engineering Research. 
Baseado em apresentação cedida por Rafael Cunha e Daniel Tadeu Castelo Branco. 
Estudos de Caso 
q Dados qualitativos 
– 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. 
q 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 
q 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.
8 
Validade dos Estudos 
q Convencimento dos leitores de que o estudo é válido 
q 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 
• 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 
Validade 
interna 
• 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 
Tipos de resultados em Engenharia de Software 
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. 
Inclui técnicas para implementação, 
representação, gerência e análise. 
A técnica deve ser operacional – 
não apenas conselho ou guia, mas 
um procedimento. 
Modelo analítico • Modelo estrutural que permite análise formal ou manipulação 
automática. 
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 
• 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. 
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 24040 3. 
Tipos de resultados em Engenharia de Software 
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. 
Análise não-formal de domínio, 
checklists bem embasados, 
generalizações informais bem 
construídas, guia para integração de 
outros resultados, observações 
interessantes bem organizadas. 
Modelo analítico • Modelo estrutural que permite análise formal ou manipulação 
automática. 
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 
• 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. 
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 24050 3. 
Tipos de resultados em Engenharia de Software 
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 formal ou manipulação 
automática. 
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 
• 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. 
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 24060 3. 
Resultados do ICSE 2002 
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. 
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 24070 3. 
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. 
– 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. 
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 24080 3.
9 
Lições Aprendidas 
q 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. 
q 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. 
49 
Lições Aprendidas 
Compare os exemplos abaixo: 
q Texto simples (simplório?): 
– ‘O projeto usou casos de uso genéricos.’ 
q Texto estruturado (simples?): 
50 
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. 
Conclusões / Considerações Finais 
q Sumário do que foi discutido no artigo 
q Discussão das principais lições aprendidas 
q Sumário das principais contribuições do artigo 
q Apresentação das lições aprendidas do trabalho 
q Discussão de limitações 
– Não é demérito ter limitações 
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 Conclusões ou Considerações Finais? Qual o foco da sessão? 
– Concluir alguma coisa 
– Sumarizar o que foi discutido no artigo 
51 
Conclusões / Considerações Finais 
q Explique como o desenvolvimento o ajudou a atingir cada 
um dos objetivos do trabalho 
q Apresente argumentos a favor e contra seu trabalho 
(limitações) 
q Seja o maior crítico do seu próprio trabalho 
q Cuidado com conclusões “fortes” 
q Procure apresentar as lições aprendidas e como elas podem 
ser aplicadas 
q Trabalhos futuros: 
– Aponte para pesquisa futura, não atividades futuras 
– O leitor terá pouco interesse em saber o que você pretende 
fazer no futuro 
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 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? 
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 25030 3. 
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? 
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 25040 3.
10 
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.) 
– 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 análise está 
relacionada com o objetivo de apoiar suas alegações sobre o 
resultado? 
» 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. 
Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 25050 3. 
Agradecimentos 
q Agradecimentos devem vir em uma sessão própria, após as 
conclusões e antes das referências bibliográficas 
q Que tipos de agradecimentos são comuns? 
– Apoio da empresa 
– Apoio de algum órgão de fomento 
– Pessoas que contribuíram de alguma forma no trabalho 
– Pessoas que participaram de alguma pesquisa ou estudo 
56 
Referências Bibliográficas 
q Referência bibliográfica não é sinônimo de bibliografia 
recomendada! 
– Todos os textos utilizados devem ser referenciados 
– Textos não utilizados não devem ser relatados 
q Evite o uso de referências muito antigas 
– O uso de referências antigas é mais aceitável quando se trata 
de um texto clássico ou precussor da área 
» 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 Se você não referenciar, é plágio. E plágios não são 
tolerados. 
q Leiam os artigos referenciados, não copie trechos de revisão 
da literatura de outros. 
57 
Referências Bibliográficas 
q As referências devem ser identificadas ao longo do texto do 
artigo e listadas ao final do texto. 
q Referências 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 ... 
q 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. 
– 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. 
58 
Referências Bibliográficas 
q Exemplo de formatação: 
– 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 
– Regras da COPPE (http://www.coppe.ufrj.br/ensino/cpgp.html) 
– Regras da ABNT 
q Revise cuidadosamente o texto para ver se toda a 
referência é citada e vice versa 
59 
Anexos e Apêndices 
q Anexo é um texto ou documento não elaborado pelo autor 
do Trabalho Científico (TC) (monografia, tese etc.). 
q Apêndice é um texto ou documento elaborado pelo autor 
do Trabalho Científico. 
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: 
– ANEXO A – Documento ou texto não elaborado pelo autor 
– APÊNDICE A – Documento ou texto elaborado pelo autor 
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.html 
60
11 
Televisão, Petróleo, Homens e Ilhas 
q Redação: 
– Clareza 
– Objetividade 
– Encadeamento 
– Resultados 
q Estrutura do parágrafo segue a estrutura do texto: 
– Introdução 
– Desenvolvimento 
– Conclusão 
61 
A forma do texto 
q A forma do texto influencia na qualidade geral do trabalho. 
– Se a forma não está adequada é difícil avaliar as reais 
contribuições dos autores. 
– Um artigo com a estrutura inadequada pode ser recusado. 
– Um artigo mal escrito tem mais chances ainda de ser recusado. 
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). 
62 
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 é: 
– Faça um resumo dessa mensagem em poucas palavras 
– Garanta que a mensagem está refletida em: 
» Título 
» 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 
Contribuição: 
q Não assuma que sua contribuição é óbvia. 
– 1. Diga o que você vai dizer 
– 2. Diga 
– 3. Diga o que você acabou de dizer 
q Não deixe para o leitor a tarefa de descobrir o que é 
importante, diga 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 
Compreensão / Avaliação 
q Facilite a compreensão/avaliação do seu trabalho, 
apresentando clara e explicitamente: 
– 1. Caracterização 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. Contribuição 
– 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 
65 
Redação 
Avaliação 
q O que a banca examinará: 
– Trabalho original compreendendo um grau satisfatório de 
atividades de pesquisa 
– Análise crítica dos tópicos e trabalhos relevantes 
– Competência no método de pesquisa e na área de pesquisa 
escolhida 
– Independência na abordagem do problema ou técnica 
apresentada 
– Texto bem elaborado e referências adequadas 
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? 
– A experiência e seus resultados são válidos? 
– As lições aprendidas são interessantes e trazem algo de novo? 66
12 
Escrevendo Textos 
q Texto: 
– A língua utilizada no MSN não é português 
– O dialeto do telemarketing não é português 
– Um artigo é um texto técnico 
– Começo, meio e fim, nesta ordem 
– Textos soltos não dizem nada 
– Modos verbais: Imperativo, Subjuntivo e Indicativo 
– A reforma ortográfica já está valendo! 
q Opiniões: 
– Se for da literatura, colocar referência. 
– Se não for, cuide-se! 
q Uso de termos pouco formais 
– saúde de empresas 
q Definir todos os termos 
q Cuidado ao usar o mesmo termo em diferentes acepções 
67 
Textos Ambíguos 
q Quantos meses do ano têm 28 dias? 
– (a) 1 (Fevereiro) 
– (b) 12 (Todos os meses do ano) 
– (c) Nenhum, pois fevereiro às vezes tem 29 dias 
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. 
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. 
– II. Preso vigia acusado de matar empresário. 
q 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. 
q 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 
Textos Ambíguos 
http://oglobo.globo.com/educacao/vestibular/arquivos/Fuvest2009_2afase_portugues.pdf 
69 
Figuras de Linguagem: Texto científico não é texto literário. 
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“ 
Em qual das duas classificações você acha que um texto científico 
deveria se encaixar? 
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. 
70 
Fonte: http://acd.ufrj.br/~pead/tema04/denotacaoeconotacao.html 
Uso de Palavras “fortes” 
q 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. 
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. 
71 
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. 
Sujeito preposicionado 
Uso incorreto de ponto-e-vírgula 
q 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 ... 
72 
As regras do português devem ser seguidas. 
Por mais que as estruturas possam parecer estranhas algumas vezes…
13 
Uso excessivo (incorreto) de vírgulas 
Verbo na 1ª pessoa 
q 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: 
73 
As regras do português devem ser seguidas. 
Deve-se procurar sempre que o texto seja fácil de ler. 
Uso excessivo de vírgulas 
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. 
74 
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. 
Uso insuficiente de vírgulas 
q Assim um novo desafio tem surgido para as organizações ... 
Compare: 
q Assim, um novo desafio tem surgido para as organizações ... 
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. 
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. 
75 
As regras do português devem ser seguidas. 
Deve-se procurar sempre que o texto seja fácil de ler. 
Crase 
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 
76 
Quando é que você vai comprar a sua gramática? 
Uso de Verbos na 1ª Pessoa 
Concordância 
q 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). 
77 
E, só para não perder o costume: 
As regras do português devem ser seguidas. 
Uso de Advérbios de Modo 
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. 
78 
O texto deve ser fácil e agradável de ler.
14 
Consistência entre Texto e Referências 
q 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... 
79 
Se são diversos, por que só há uma referência? 
Redundância 
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. 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. 
80 A coerência do texto deve ser mantida sempre. 
Uso de Referências no Abstract/Resumo 
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). 
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. 
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 
Relação entre Causa e Efeito 
q 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. 
82 
Citações com Diferentes Estilos 
q 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]. 
q 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. 
83 
Deve-se padronizar estilo do texto e também das referências. 
Verifique o padrão na chamada de trabalhos. 
Referência a Figuras 
q ... como mostra a Figura 1 – Realização dos objetivos e metas 
através de projetos e as restrições organizacionais . 
q ... como mostra a figura abaixo. 
Compare: 
q ... como mostra a Figura 1. 
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. 
Procure não misturar notações diferentes. 
84
15 
Traduções Incorretas / Não Recomendadas 
q comprehensive 
– abrangente 
– compreensivo 
q to support 
– apoiar 
– suportar 
q performance 
– desempenho 
– 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 
http://www.cintiabarreto.com.br/didatica/curiosidadesgraficas.shtml 
Informalidade da Fala na Escrita 
Uso de pronomes 
q 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 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. 
86 O texto científico é um texto formal. 
Frases Grandes 
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 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. 
87 
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… 
Uso de “o mesmo” 
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 
Termos a Serem Evitados 
q Advérbios 
q Brincadeiras, Ironia ou 
Piadas 
q “ruim” e “bom” (não 
julgue) 
q “perfeito” (nada é) 
q “uma solução ideal” 
q “hoje em dia”, 
“atualmente” 
q “em breve” 
q “Ficamos surpresos ao 
perceber que...” 
q “parece que...” 
q “parece mostrar que...” 
q “diferente” (de quê?) 
q “provavelmente” 
q “simples” 
q “obviamente”, 
“claramente” (para 
quem?) 
q “na verdade” 
q Segunda pessoa 
q Primeira pessoa 
q “um pesquisador 
famoso” 
q “poucos”, “muitos”, 
“todos”, 
“nenhum” (quem disse? 
Como foi provado?) 
q “deve” (quem disse?) 
Fonte: Santoro, F., Notas de Aula – Apresentação do MetodoloWgia adaz Pleasqwuisai cCiken,tí fi2ca0 200107.2 , 
Programa de Pós-Graduação em Informática – UNIRIO. apud Wazlawick, 2007 
Escrevendo Textos 
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
16 
Ética... 
q ... em Sala de Aula 
– Não colar ou dar cola em 
provas 
– Não plagiar o trabalho 
– Não trapacear nas leituras e 
listas de exercício 
– Não sobrecarregar os colegas 
do grupo 
– Não assinar presença por 
colegas 
– Dar crédito apropriado quando 
usar trabalhos de terceiros 
(ver nota de rodapé!) 
q 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 
q Necessidade de postura ética em relação à computação: 
– Profissionais de computação 
– Usuários e Clientes 
– Ser Humano 
q “Comportamento do cientista” (Merton, 1942) 
– Comunalismo: requer que o conhecimento científico seja 
público 
– Universalismo: requer que a ciência seja independente de raça, 
cor, credo... 
– Desinteresse: requer que os resultados da pesquisa não sejam 
manipulados 
– Ceticismo organizado: requer que afirmações não devam ser 
aceitas pela palavra da autoridade 
92 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 
Ética na Pesquisa 
q Algumas questões para reflexão (Wainer, 2007) 
– 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? 
– Pesquisas qualitativas 
» Que garantias de anonimato da organização na publicação 
final dos resultados são apropriadas? 
» A organização tem poder de veto na publicação dos 
resultados? 
» Se a organização já autorizou a pesquisa, é preciso pedir 
consentimento a cada um dos sujeitos estudados? 
93 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 
Plágio e Auto Plágio 
q Plágio x Pesquisa 
– Plágio não é pesquisa 
– 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. 
» Descubra como transformar a experiência em outro artigo J 
– Mesmo quando se copia um trecho de um trabalho anterior seu 
é preciso referenciá-lo! 
– Auto-plágio tem sido cada vez menos tolerado... 94 
Processo de Revisão 
q Os artigos submetidos a eventos científicos serão avaliados 
por revisores selecionados (em geral, 2 a 3) 
q Ajuste de foco do artigo com a chamada do evento 
– Deve ser feito antes da submissão. Se o foco estiver errado, 
aumentam as chances de o artigo ser recusado 
– Analise a lista de revisores para tentar inferir o possível foco 
que será dado nas revisões 
q Garanta uma boa revisão prévia do artigo. 
– Não é trabalho do revisor corrigir o seu trabalho, mas sim 
apontar os pontos fortes e fracos e a adequação ao evento. 
q Submissão do artigo. 
– Verifique o sistema de submissão (no Brasil, é comum o uso do 
JEMS, no exterior, do EasyChair. Também pode ser e-mail). 
– Verifique a data limite (não há garantias que ela seja alterada!) 
q É de bom tom corrigir os itens apontados pelos revisores 
(eles não foram escolhidos ao acaso), apesar de não haver 
uma segunda revisão... 95 
Processo de Seleção de Artigos 
q Pesquisadores selecionam coordenador do comitê de 
programa 
q Coordenador do comitê de programa seleciona membros do 
comitê de programa 
q Coordenador do comitê de programa apresenta Chamada de 
Trabalhos (Call for Papers) 
q Autores submetem artigos 
q Coordenador do comitê de programa distribui artigos para 
os membros do comitê 
q Membros do comitê redistribuem artigos para revisores (se 
for o caso) 
q Revisores apresentam revisão dos artigos 
q 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
17 
Comunicação da Revisão 
q Variam de acordo com a conferência/periódico 
q Avaliação numérica (notas em critérios) 
– Originalidade 
– Conteúdo técnico 
– Relevância 
– Contribuição 
– Referencial teórico 
– Clareza na escrita, organização do texto e apresentação 
q Avaliação qualitativa 
– Resumo da contribuição 
– 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 
q Originalidade e Contribuição: 
– 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 
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 
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 
Critérios de Avaliação de Artigos do SBQS 
q Qualidade técnica: 
– O artigo tem qualidade técnica? 
– 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 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. 
– 1: Apresentação péssima 2: Apresentação ruim 3: 
Apresentação boa 4: Apresentação ótima 5: Apresentação 
excelente 
99 
Critérios de Avaliação de Artigos do SBQS 
q 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: 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 
q Resumo (Summary): 
– (Uma breve descrição do artigo) 
q Pontos Fortes (Paper Strengths): 
q Pontos Fracos (Paper Weakness): 
q Comentários para os Autores (Comments to Authors): 
– (Comentários e sugestões para o autor melhorar a qualidade do 
artigo) 
q E ainda um campo que só os revisores veem… 
100 
Preparando a Apresentação 
q 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 
conteúdo dos slides 
q Evite colocar muito texto nos slides 
– O objetivo do texto é guiar a apresentação, e não ser lido 
– Não é para colocar o texto completo do artigo na apresentação 
q Estrutura dos slides 
– Baseie-se na estrutura do texto, mas não se prenda a ela 
– Nem sempre a estrutura do artigo é adequada em uma 
apresentação 
– Lembre-se que o filme baseado no livro é diferente do livro… 
101 
Preparando a Apresentação 
q Treinando a apresentação 
– Treine! 
– Ao falar em voz alta, conseguimos perceber se o texto flui de 
forma adequada 
– Elimine os textos supérfluos, reorganize a apresentação 
q A apresentação no dia 
– Fique calmo 
– Fale pausadamente 
– Demonstre segurança 
– Não leia, apresente 
– Vá bem vestido! J 
q Respondendo às perguntas 
– Prepare-se para as perguntas mais difíceis 
– Se não for uma pergunta, não responda 
– Você não estará participando de um debate, nada de réplicas e 
tréplicas 102
18 
Referências 
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. 
q 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. 
q ROCHA, A. R. C., MALDONADO, J. C., WEBER, K. C., 2001, “Qualidade de Software: 
Teoria e Prática”, Prentice Hall. 
q SCHOTS, N. C. L., Uma Abordagem para a Identificação de Causas de Problemas 
Utilizando Grounded Theory. Dissertação de Mestrado. COPPE/UFRJ, 2010. 
q 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. 
q SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 
2003. 
q WAZLAWICK, R. S., 2009, “Metodologia de Pesquisa para Ciência da Computação”, 
1a edição, Elsevier Editora, Rio de Janeiro. 
q Curiosidades Gráficas: Palavras e termos semelhantes, mas com significados 
diferentes: http://www.cintiabarreto.com.br/didatica/curiosidadesgraficas.shtml 
q 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 
q Alguns slides deste mini-curso foram baseados em material de outras pessoas, 
conforme citado em slides específicos. Meus agradecimentos ao auxílio prestado. 
103 
WAMPS 2011 - VII Workshop 
Anual do MPS 
Como Escrever um Relato de 
Experiência 
Gleison Santos 
gleison.santos@uniriotec.br

Mais conteúdo relacionado

Mais procurados

Um processo de inovação contínua de software baseado em prototipagem
Um processo de inovação contínua de software baseado em prototipagemUm processo de inovação contínua de software baseado em prototipagem
Um processo de inovação contínua de software baseado em prototipagemCarlos Carvalho
 
7. Variantes de testes de usabilidade
7. Variantes de testes de usabilidade7. Variantes de testes de usabilidade
7. Variantes de testes de usabilidadeLuiz Agner
 
Teste de Usabilidade - Expandindo a usabilidade na sua empresa
Teste de Usabilidade - Expandindo a usabilidade na sua empresaTeste de Usabilidade - Expandindo a usabilidade na sua empresa
Teste de Usabilidade - Expandindo a usabilidade na sua empresaLuiz Agner
 
Modelo pré-projeto de monografia
Modelo pré-projeto de monografiaModelo pré-projeto de monografia
Modelo pré-projeto de monografiaWagner Cipri
 

Mais procurados (7)

Ensiso day talks
Ensiso day   talksEnsiso day   talks
Ensiso day talks
 
Um processo de inovação contínua de software baseado em prototipagem
Um processo de inovação contínua de software baseado em prototipagemUm processo de inovação contínua de software baseado em prototipagem
Um processo de inovação contínua de software baseado em prototipagem
 
2009 SBES - Developing Motivational Programs for Software Engineers through a...
2009 SBES - Developing Motivational Programs for Software Engineers through a...2009 SBES - Developing Motivational Programs for Software Engineers through a...
2009 SBES - Developing Motivational Programs for Software Engineers through a...
 
7. Variantes de testes de usabilidade
7. Variantes de testes de usabilidade7. Variantes de testes de usabilidade
7. Variantes de testes de usabilidade
 
TCC seminário I
TCC seminário ITCC seminário I
TCC seminário I
 
Teste de Usabilidade - Expandindo a usabilidade na sua empresa
Teste de Usabilidade - Expandindo a usabilidade na sua empresaTeste de Usabilidade - Expandindo a usabilidade na sua empresa
Teste de Usabilidade - Expandindo a usabilidade na sua empresa
 
Modelo pré-projeto de monografia
Modelo pré-projeto de monografiaModelo pré-projeto de monografia
Modelo pré-projeto de monografia
 

Semelhante a Implantação do Nível F do MR-MPS Combinando Características do Processo Unificado com Práticas SCRUM

Minicurso - Pré-projeto Descomplicado
Minicurso - Pré-projeto DescomplicadoMinicurso - Pré-projeto Descomplicado
Minicurso - Pré-projeto DescomplicadoDiogo Pereira
 
2 - PPT1_aula sincrona.pptx
2 - PPT1_aula sincrona.pptx2 - PPT1_aula sincrona.pptx
2 - PPT1_aula sincrona.pptxAntónio Godinho
 
Tópicos Especiais em Engenharia de Software
Tópicos Especiais em Engenharia de SoftwareTópicos Especiais em Engenharia de Software
Tópicos Especiais em Engenharia de SoftwareRogerio P C do Nascimento
 
PTI - gestão de risco associada a negócios.pdf
PTI - gestão de risco associada a negócios.pdfPTI - gestão de risco associada a negócios.pdf
PTI - gestão de risco associada a negócios.pdfHELENO FAVACHO
 
Workshop -Regras de Escrita de Trabalhos
Workshop -Regras de Escrita de TrabalhosWorkshop -Regras de Escrita de Trabalhos
Workshop -Regras de Escrita de TrabalhosPedro Valente
 
PTI - gestão de risco associada a negócios.docx
PTI - gestão de risco associada a negócios.docxPTI - gestão de risco associada a negócios.docx
PTI - gestão de risco associada a negócios.docxHELENO FAVACHO
 
Aula 1- ENGENHARIA DE SOFTWARE
Aula 1- ENGENHARIA DE SOFTWAREAula 1- ENGENHARIA DE SOFTWARE
Aula 1- ENGENHARIA DE SOFTWAREErnesto Bedrikow
 
Metodologias da Engenharia do Conhecimento - Aula 2/3
Metodologias da Engenharia do Conhecimento - Aula 2/3Metodologias da Engenharia do Conhecimento - Aula 2/3
Metodologias da Engenharia do Conhecimento - Aula 2/3Roberto C. S. Pacheco
 
Revisão Sistemática de Literatura
Revisão Sistemática de LiteraturaRevisão Sistemática de Literatura
Revisão Sistemática de LiteraturaJean Hauck
 
ANÁLISE ESTRATÉGICA DE TERCEIRIZAÇÃO: UM ESTUDO DE CASO EM UMA OPERADORA DE T...
ANÁLISE ESTRATÉGICA DE TERCEIRIZAÇÃO: UM ESTUDO DE CASO EM UMA OPERADORA DE T...ANÁLISE ESTRATÉGICA DE TERCEIRIZAÇÃO: UM ESTUDO DE CASO EM UMA OPERADORA DE T...
ANÁLISE ESTRATÉGICA DE TERCEIRIZAÇÃO: UM ESTUDO DE CASO EM UMA OPERADORA DE T...Defacio Padroni
 
6. Testes de usabilidade apresentando as conclusoes
6. Testes de usabilidade   apresentando as conclusoes6. Testes de usabilidade   apresentando as conclusoes
6. Testes de usabilidade apresentando as conclusoesLuiz Agner
 
Aula 1 automação de processos
Aula 1   automação de processosAula 1   automação de processos
Aula 1 automação de processosMaurício Botelho
 
Aula 1 Analise e Projeto
Aula 1   Analise e ProjetoAula 1   Analise e Projeto
Aula 1 Analise e ProjetoSergio Silva
 
TDC2016POA | Trilha Education - Aprendizagem baseada em projetos: Uma experi...
TDC2016POA | Trilha Education -  Aprendizagem baseada em projetos: Uma experi...TDC2016POA | Trilha Education -  Aprendizagem baseada em projetos: Uma experi...
TDC2016POA | Trilha Education - Aprendizagem baseada em projetos: Uma experi...tdc-globalcode
 
Apresentação da disciplina de Introdução à Informática
Apresentação da disciplina de Introdução à InformáticaApresentação da disciplina de Introdução à Informática
Apresentação da disciplina de Introdução à InformáticaKéssia Marchi
 

Semelhante a Implantação do Nível F do MR-MPS Combinando Características do Processo Unificado com Práticas SCRUM (20)

Minicurso - Pré-projeto Descomplicado
Minicurso - Pré-projeto DescomplicadoMinicurso - Pré-projeto Descomplicado
Minicurso - Pré-projeto Descomplicado
 
Estágio I aula 1
Estágio I aula 1Estágio I aula 1
Estágio I aula 1
 
2 - PPT1_aula sincrona.pptx
2 - PPT1_aula sincrona.pptx2 - PPT1_aula sincrona.pptx
2 - PPT1_aula sincrona.pptx
 
Tópicos Especiais em Engenharia de Software
Tópicos Especiais em Engenharia de SoftwareTópicos Especiais em Engenharia de Software
Tópicos Especiais em Engenharia de Software
 
PTI - gestão de risco associada a negócios.pdf
PTI - gestão de risco associada a negócios.pdfPTI - gestão de risco associada a negócios.pdf
PTI - gestão de risco associada a negócios.pdf
 
Workshop -Regras de Escrita de Trabalhos
Workshop -Regras de Escrita de TrabalhosWorkshop -Regras de Escrita de Trabalhos
Workshop -Regras de Escrita de Trabalhos
 
PTI - gestão de risco associada a negócios.docx
PTI - gestão de risco associada a negócios.docxPTI - gestão de risco associada a negócios.docx
PTI - gestão de risco associada a negócios.docx
 
Aula 1- ENGENHARIA DE SOFTWARE
Aula 1- ENGENHARIA DE SOFTWAREAula 1- ENGENHARIA DE SOFTWARE
Aula 1- ENGENHARIA DE SOFTWARE
 
Aula4 TEES UFS: Orientação a Objetos
Aula4 TEES UFS: Orientação a ObjetosAula4 TEES UFS: Orientação a Objetos
Aula4 TEES UFS: Orientação a Objetos
 
Metodologias da Engenharia do Conhecimento - Aula 2/3
Metodologias da Engenharia do Conhecimento - Aula 2/3Metodologias da Engenharia do Conhecimento - Aula 2/3
Metodologias da Engenharia do Conhecimento - Aula 2/3
 
At1
At1At1
At1
 
Revisão Sistemática de Literatura
Revisão Sistemática de LiteraturaRevisão Sistemática de Literatura
Revisão Sistemática de Literatura
 
ANÁLISE ESTRATÉGICA DE TERCEIRIZAÇÃO: UM ESTUDO DE CASO EM UMA OPERADORA DE T...
ANÁLISE ESTRATÉGICA DE TERCEIRIZAÇÃO: UM ESTUDO DE CASO EM UMA OPERADORA DE T...ANÁLISE ESTRATÉGICA DE TERCEIRIZAÇÃO: UM ESTUDO DE CASO EM UMA OPERADORA DE T...
ANÁLISE ESTRATÉGICA DE TERCEIRIZAÇÃO: UM ESTUDO DE CASO EM UMA OPERADORA DE T...
 
6. Testes de usabilidade apresentando as conclusoes
6. Testes de usabilidade   apresentando as conclusoes6. Testes de usabilidade   apresentando as conclusoes
6. Testes de usabilidade apresentando as conclusoes
 
Aula 1 automação de processos
Aula 1   automação de processosAula 1   automação de processos
Aula 1 automação de processos
 
Aula 1 Analise e Projeto
Aula 1   Analise e ProjetoAula 1   Analise e Projeto
Aula 1 Analise e Projeto
 
Aula 1 analise e projeto
Aula 1   analise e projetoAula 1   analise e projeto
Aula 1 analise e projeto
 
TDC2016POA | Trilha Education - Aprendizagem baseada em projetos: Uma experi...
TDC2016POA | Trilha Education -  Aprendizagem baseada em projetos: Uma experi...TDC2016POA | Trilha Education -  Aprendizagem baseada em projetos: Uma experi...
TDC2016POA | Trilha Education - Aprendizagem baseada em projetos: Uma experi...
 
Apresentação da disciplina de Introdução à Informática
Apresentação da disciplina de Introdução à InformáticaApresentação da disciplina de Introdução à Informática
Apresentação da disciplina de Introdução à Informática
 
Aula1 Apresentacao TEES
Aula1 Apresentacao TEESAula1 Apresentacao TEES
Aula1 Apresentacao TEES
 

Implantação do Nível F do MR-MPS Combinando Características do Processo Unificado com Práticas SCRUM

  • 1. 1 WAMPS 2011 - VII Workshop Anual do MPS Como Escrever um Relato de Experiência Gleison Santos gleison.santos@uniriotec.br 2 Agenda q Introdução q Estrutura do Texto de um Relato q Preparação do Texto q Ética e Plágio q Processo de Revisão de um Artigo q Apresentação de um Artigo 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 O principal objetivo da engenharia de software é, sem dúvida, melhorar a qualidade do software. (ROCHA et al., 2001) q De forma geral, pesquisadores da Engenharia de Software procuram melhores formas de desenvolver e avaliar software. q Pesquisadores da Engenharia de Software são motivados por problemas práticos. q Objetivos chave da pesquisa geralmente são 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. 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. Necessidades do Negócio Qualidade do produto Qualidade do processo 4 Processos, métodos, técnicas… e pessoas... q Como melhorar a codificação? (o que é uma boa codificação?) q Como melhorar o teste de software? (o que é um bom teste?) q Como fazer boas modelagens? (o que é uma boa modelagem?) q O que leva alguém a usar um processo / método / técnica? q Quais os problemas que afetam a indústria de software? q Qual o retorno de investimento da Qualidade de Software? q Que fatores culturais afetam o desenvolvimento de software? q Que fatores afetam a melhoria de processos de software? q O que as pessoas esperam de resultados da adoção de uma técnica / método / processo? q Quais os benefícios da adoção de uma técnica / método / processo? q ... 5 Em Otimização A gerência quantitativa) Gerenciado B Quantitativamente 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 Largamente Definido 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) Parcialmente Medição / Gerência de Configuração / Aquisição / Garantia da Qualidade / Gerência de Portfólio de Projetos C D E F G Gerência de Requisitos Gerência de Projetos (sem processos adicionais) (inclui controle estatístico e Gerenciado Parcialmente Gerenciado Definido Definido Gerência de Projetos (evolução) (inclui controle estatístico e gerência quantitativa) ~ CMMI 5 ~ CMMI 4 ~ CMMI 3 ~ CMMI 2 Níveis de Maturidade MPS.BR
  • 2. 2 Pesquisa x Ciência q Objetivos de Pesquisa – Fazer uma contribuição para a Ciência – Responder a uma pergunta » de interesse para a comunidade científica » ainda não respondida anteriormente » de relevância para o interesse social – A parte mais difícil é encontrar o problema q Objetivo da Ciência: resolver problemas – Qual o problema que você está resolvendo? – Comece de um desafio prático – Extraia daí um problema teórico – Certifique-se que o problema é » relevante » não-resolvido » resolvível 7 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 Pesquisa q Tipos de Pesquisa – Nem toda pesquisa é feita da mesma forma – Os métodos de pesquisa são bem diversos dependendo do campo de conhecimento q Mestre: Título de qualificação técnico-científica – domina as técnicas de investigação – produziu um resultado novo (ou relevante) – comunicou seus resultados de forma efetiva q Mestre X Doutor – tempo de investigação – profundidade da pesquisa – qualidade da formação 8 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 Divagações… q 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 Um trabalho para uma empresa não é um trabalho de pesquisa. – Gostaríamos que todo trabalho de pesquisa fosse aplicado a empresas. Nem sempre isso é possível por N fatores. – 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. O que dá para publicar? q Projeto Final de Graduação q Projeto Final de Pós-graduação q Dissertação de Mestrado q Tese de Doutorado q Experiências em Empresas e de Empresas q Cuidado com o foco, com a forma de descrição e na descrição das reais contribuições do trabalho 10 O que dá para publicar? q O que posso publicar? – A audiência do evento é importante para determinar o que é relevante em cada contexto q Onde publicar? – A chamada de trabalhos é importante para entender o tipo de trabalho que se espera dos autores q 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 Relatos de Experiência q Devem contar uma história informativa e como ela se reflete em situações mais gerais q Não entre em detalhes irrelevantes sobre o experimento Fonte: Santoro, F., Notas de Aula – Apresentação do Metodologia da Pesquisa Científica 2010.2, 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 Programa de Pós-Graduação em Informática – UNIRIO.
  • 3. 3 Um bom artigo de pesquisa 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? – Que questões você respondeu? – Por que o leitor deveria se importar? – 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? – 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? q 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? Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 21030 3. Estrutura do Texto q A estrutura de um artigo científicio segue um padrão pré-determinado – Em geral, não há uma regra, mas a estrutura abaixo segue o senso comum em uso – Não há muitas possibilidades de inovar nesta organização. q Estrutura Básica: – Introdução – Sessões Pertinentes – Conclusão – Referências 14 Estrutura do Texto q Itens comuns na estrutura do texto: – Título – Autores – Abstract / Resumo – Introdução – Revisão da Literatura – Trabalhos Similares – Proposta / Descrição da Experiência – Lições Aprendidas – Conclusões / Considerações Finais – Agradecimentos – Referências Bibliográficas – Anexos e Apêndices 15 Título q O título deve ser curto e indicativo do trabalho que será apresentado q Escolha um título que valorize o trabalho, mas cuidado para não ser arrogante ou presunçoso q Evite o uso de perguntas e termos em inglês – Vale para o texto como um todo – Ninguém garante que as perguntas vão ser respondidas (e, em geral, você não irá respondê-las. Acredite…) Implantação do Nível F do MR-MPS Combinando Características do Processo 16 Unificado com Práticas SCRUM Autores q Deve-se listar os envolvidos com o trabalho – 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 » Isso não é uma regra, no entanto q Para cada autor, deve-se indicar a filiação – Pode haver múltipla filiação – Deve-se indicar o e-mail de contato dos autores 17 Tatiane Silva1, Rogério Magela1, Gleison Santos2, Natália Chaves Lessa Schots3, Ana Regina Rocha3 1Athenas 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, gleison.santos@uniriotec.br, {natalia, darocha}@cos.ufrj.br Abstract q Não é o trailer de um filme (não deixe o espectador imaginando qual será o final) q “Venda” seu trabalho no abstract q Se você não conseguir resumir sua contribuição em meia página algo está muito errado no seu trabalho q Não entra revisão bibliográfica q Inclua sempre no abstract – O principal problema analisado – Um esboço da solução utilizada – As conclusões alcançadas q Fundamental – Dizer qual é o problema – Mostrar que vale a pena resolver o problema – Mostrar como você resolveu o problema Fonte: Santoro, F., Notas de Aula – Apresentação do MetodoloWgia adaz Pleasqwuisai cCiken,tí fi2ca0 200107.2 , Programa de Pós-Graduação em Informática – UNIRIO. apud Wazlawick, 2007
  • 4. 4 Abstract e Resumo q Todo artigo deve ter um resumo – As vezes, é necessário ter versões em inglês e em português 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 Introdução q Contextualize rapidamente o tema de pesquisa (não inicie nos primórdios) q Apresente os objetivos, metodologia, justificativa, resultados esperados, limitações e estrutura da dissertação q 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 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? • 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 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, e, se sim, como ele se parece? • É possível, realmente, realizar (accomplish) X? Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 22010 3. Tipos de questões de pesquisa em Engenharia de Software 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? • Como X se compara a Y? • Qual é o estado atual de X / prática de Y? Generalização ou caracterização Produzem métodos de desenvolvimento ou análise que os autores investigaram em uma situação (setting), mas que presumivelmente podem ser aplicados em outros contextos. • 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, e, se sim, como ele se parece? • É possível, realmente, realizar (accomplish) X? Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 22020 3. Tipos de questões de pesquisa em Engenharia de Software 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? • 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 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 Lida explicitamente com um sistema, prática, design ou outro instância de um sistema ou método. Varia de narrativas sobre prática industrial a comparações analíticas de designs alternativos. • X realmente existe, e, se sim, como ele se parece? • É possível, realmente, realizar (accomplish) X? Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 22030 3. Tipos de questões de pesquisa em Engenharia de Software 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 Generalizações e caracterizações surgem explicitamente dos exemplos apresentados nos artigos. • 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? 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, e, se sim, como ele se parece? • É possível, realmente, realizar (accomplish) X? Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 22040 3.
  • 5. 5 Tipos de questões de pesquisa em Engenharia de Software 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? • Como X se compara a Y? • Qual é o estado atual de X / prática de Y? Generalização ou caracterização Lidam com uma questão de uma maneira completamente nova. Em geral têm uma categoria diferente daqueles que melhoram algo previamente definido. • 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, e, se sim, como ele se parece? • É possível, realmente, realizar (accomplish) X? Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 22050 3. Resultados do ICSE 2002 q Importante: (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. q Ao longo da história da ES, os tipos de questões mudam quando a maturidade de um assunto aumenta. Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 22060 3. Revisão da Literatura q Concentre-se em apresentar as definições e resultados da literatura que sejam relevantes para seu objetivo q 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 q Organização do capítulo – 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 Cite: – periódicos e eventos relevantes – obras recentes – obras clássicas na área 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 Revisão da Literatura 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. » Tudo deve ter referência 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 – 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 28 29 Onde achar artigos? q Anais anteriores do SBES, SBQS e WAMPS q Portal de Periódicos Capes: http://periodicos.capes.gov.br/ – Verifique se sua universidade provê acesso de qualquer computador do campus – Verifique se há possibilidade de acesso remoto através de proxy q Maximizando resultados, minimizando esforço – 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? 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... Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 23000 3.
  • 6. 6 Tipos de resultados em Engenharia de Software O que foi feito antes? Como seu trabalho é diferente ou melhor? q Compare: O problema de galopar tem atraído muita atenção [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 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. Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 23010 3. Proposta / Descrição da Experiência q Coloque suas afirmações cuidadosamente q Garanta que todas as afirmações sejam fundamentadas q 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 q Uma teoria não testada na prática não vale muito q Artigos sobre comparação entre métodos – 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, 32 Programa de Pós-Graduação em Informática - UNIRIO 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)? – É 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 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 acurácia do detector padrão (ou provei, demonstrei, criei, estabeleci, encontrei, desenvolvi). 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. Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 23030 3. Tipos de resultados em Engenharia de Software “Try not. Do, or do not. There is no try.” Yoda Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 23040 3. 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 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 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. – 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. – Se uma ferramenta tem um papel importante no seu artigo, qual é este papel? – Se a implementação de um sistema tem um papel importante no seu artigo, qual é este papel? Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 23050 3. Tipos de Validação em Engenharia de Software 36 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 é… Exemplo • Aqui há um exemplo de como funciona em... Persuasão • Eu pensei muito sobre isso e acredito apaixonadamente que… Afirmação forte • Nenhuma tentativa séria de avaliar o resultado. q Uma boa pesquisa requer não só um resultado, mas também uma evidência convincente que o resultado é adequado/bom. Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 2003.
  • 7. 7 Resultados do ICSE 2002 q Importante: (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. Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 23070 3. 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 Fonte: SCHOTS, N. C. L., Uma Abordagem para a Identificação de Causas de Problemas 38 Utilizando Grounded Theory. Dissertação de Mestrado. COPPE/UFRJ, 2010. Estudos de Caso q Questão de pesquisa q Investiga um fenômeno contemporâneo q Contexto de vida real, em que as fronteiras não são claramente evidentes. q 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 q Exploratórios – Usado em investigações iniciais de alguns fenômenos – Visam derivar novas ideias e hipóteses e formular teorias q Descritivos – Descrevem uma situação ou fenômeno q Explanatório – 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: 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 Requisitos – Questão de pesquisa bem definida – Interessada em como e porque um fenômeno ocorre » Deriva uma proposta de estudo que afirma Ø O que o estudo mostrará Ø Guiar seleção de casos Ø Tipos de dados a serem coletados q Escolhas – Escolha de casos é fundamental para a pesquisa – Amostra utilizada não é aleatória, sendo escolhida – Objetivo de escolher casos relevantes e representativos Fonte: EASTERBROOK et al., Selecting Empirical Methods for Software Engineering Research. Baseado em apresentação cedida por Rafael Cunha e Daniel Tadeu Castelo Branco. Estudos de Caso q Dados qualitativos – 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. q 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 q 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.
  • 8. 8 Validade dos Estudos q Convencimento dos leitores de que o estudo é válido q 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 • 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 Validade interna • 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 Tipos de resultados em Engenharia de Software 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. Inclui técnicas para implementação, representação, gerência e análise. A técnica deve ser operacional – não apenas conselho ou guia, mas um procedimento. Modelo analítico • Modelo estrutural que permite análise formal ou manipulação automática. 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 • 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. Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 24040 3. Tipos de resultados em Engenharia de Software 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. Análise não-formal de domínio, checklists bem embasados, generalizações informais bem construídas, guia para integração de outros resultados, observações interessantes bem organizadas. Modelo analítico • Modelo estrutural que permite análise formal ou manipulação automática. 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 • 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. Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 24050 3. Tipos de resultados em Engenharia de Software 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 formal ou manipulação automática. 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 • 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. Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 24060 3. Resultados do ICSE 2002 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. Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 24070 3. 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. – 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. Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 24080 3.
  • 9. 9 Lições Aprendidas q 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. q 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. 49 Lições Aprendidas Compare os exemplos abaixo: q Texto simples (simplório?): – ‘O projeto usou casos de uso genéricos.’ q Texto estruturado (simples?): 50 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. Conclusões / Considerações Finais q Sumário do que foi discutido no artigo q Discussão das principais lições aprendidas q Sumário das principais contribuições do artigo q Apresentação das lições aprendidas do trabalho q Discussão de limitações – Não é demérito ter limitações 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 Conclusões ou Considerações Finais? Qual o foco da sessão? – Concluir alguma coisa – Sumarizar o que foi discutido no artigo 51 Conclusões / Considerações Finais q Explique como o desenvolvimento o ajudou a atingir cada um dos objetivos do trabalho q Apresente argumentos a favor e contra seu trabalho (limitações) q Seja o maior crítico do seu próprio trabalho q Cuidado com conclusões “fortes” q Procure apresentar as lições aprendidas e como elas podem ser aplicadas q Trabalhos futuros: – Aponte para pesquisa futura, não atividades futuras – O leitor terá pouco interesse em saber o que você pretende fazer no futuro 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 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? Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 25030 3. 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? Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 25040 3.
  • 10. 10 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.) – 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 análise está relacionada com o objetivo de apoiar suas alegações sobre o resultado? » 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. Fonte: SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 25050 3. Agradecimentos q Agradecimentos devem vir em uma sessão própria, após as conclusões e antes das referências bibliográficas q Que tipos de agradecimentos são comuns? – Apoio da empresa – Apoio de algum órgão de fomento – Pessoas que contribuíram de alguma forma no trabalho – Pessoas que participaram de alguma pesquisa ou estudo 56 Referências Bibliográficas q Referência bibliográfica não é sinônimo de bibliografia recomendada! – Todos os textos utilizados devem ser referenciados – Textos não utilizados não devem ser relatados q Evite o uso de referências muito antigas – O uso de referências antigas é mais aceitável quando se trata de um texto clássico ou precussor da área » 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 Se você não referenciar, é plágio. E plágios não são tolerados. q Leiam os artigos referenciados, não copie trechos de revisão da literatura de outros. 57 Referências Bibliográficas q As referências devem ser identificadas ao longo do texto do artigo e listadas ao final do texto. q Referências 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 ... q 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. – 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. 58 Referências Bibliográficas q Exemplo de formatação: – 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 – Regras da COPPE (http://www.coppe.ufrj.br/ensino/cpgp.html) – Regras da ABNT q Revise cuidadosamente o texto para ver se toda a referência é citada e vice versa 59 Anexos e Apêndices q Anexo é um texto ou documento não elaborado pelo autor do Trabalho Científico (TC) (monografia, tese etc.). q Apêndice é um texto ou documento elaborado pelo autor do Trabalho Científico. 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: – ANEXO A – Documento ou texto não elaborado pelo autor – APÊNDICE A – Documento ou texto elaborado pelo autor 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.html 60
  • 11. 11 Televisão, Petróleo, Homens e Ilhas q Redação: – Clareza – Objetividade – Encadeamento – Resultados q Estrutura do parágrafo segue a estrutura do texto: – Introdução – Desenvolvimento – Conclusão 61 A forma do texto q A forma do texto influencia na qualidade geral do trabalho. – Se a forma não está adequada é difícil avaliar as reais contribuições dos autores. – Um artigo com a estrutura inadequada pode ser recusado. – Um artigo mal escrito tem mais chances ainda de ser recusado. 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). 62 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 é: – Faça um resumo dessa mensagem em poucas palavras – Garanta que a mensagem está refletida em: » Título » 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 Contribuição: q Não assuma que sua contribuição é óbvia. – 1. Diga o que você vai dizer – 2. Diga – 3. Diga o que você acabou de dizer q Não deixe para o leitor a tarefa de descobrir o que é importante, diga 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 Compreensão / Avaliação q Facilite a compreensão/avaliação do seu trabalho, apresentando clara e explicitamente: – 1. Caracterização 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. Contribuição – 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 65 Redação Avaliação q O que a banca examinará: – Trabalho original compreendendo um grau satisfatório de atividades de pesquisa – Análise crítica dos tópicos e trabalhos relevantes – Competência no método de pesquisa e na área de pesquisa escolhida – Independência na abordagem do problema ou técnica apresentada – Texto bem elaborado e referências adequadas 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? – A experiência e seus resultados são válidos? – As lições aprendidas são interessantes e trazem algo de novo? 66
  • 12. 12 Escrevendo Textos q Texto: – A língua utilizada no MSN não é português – O dialeto do telemarketing não é português – Um artigo é um texto técnico – Começo, meio e fim, nesta ordem – Textos soltos não dizem nada – Modos verbais: Imperativo, Subjuntivo e Indicativo – A reforma ortográfica já está valendo! q Opiniões: – Se for da literatura, colocar referência. – Se não for, cuide-se! q Uso de termos pouco formais – saúde de empresas q Definir todos os termos q Cuidado ao usar o mesmo termo em diferentes acepções 67 Textos Ambíguos q Quantos meses do ano têm 28 dias? – (a) 1 (Fevereiro) – (b) 12 (Todos os meses do ano) – (c) Nenhum, pois fevereiro às vezes tem 29 dias 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. 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. – II. Preso vigia acusado de matar empresário. q 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. q 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 Textos Ambíguos http://oglobo.globo.com/educacao/vestibular/arquivos/Fuvest2009_2afase_portugues.pdf 69 Figuras de Linguagem: Texto científico não é texto literário. 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“ Em qual das duas classificações você acha que um texto científico deveria se encaixar? 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. 70 Fonte: http://acd.ufrj.br/~pead/tema04/denotacaoeconotacao.html Uso de Palavras “fortes” q 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. 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. 71 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. Sujeito preposicionado Uso incorreto de ponto-e-vírgula q 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 ... 72 As regras do português devem ser seguidas. Por mais que as estruturas possam parecer estranhas algumas vezes…
  • 13. 13 Uso excessivo (incorreto) de vírgulas Verbo na 1ª pessoa q 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: 73 As regras do português devem ser seguidas. Deve-se procurar sempre que o texto seja fácil de ler. Uso excessivo de vírgulas 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. 74 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. Uso insuficiente de vírgulas q Assim um novo desafio tem surgido para as organizações ... Compare: q Assim, um novo desafio tem surgido para as organizações ... 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. 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. 75 As regras do português devem ser seguidas. Deve-se procurar sempre que o texto seja fácil de ler. Crase 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 76 Quando é que você vai comprar a sua gramática? Uso de Verbos na 1ª Pessoa Concordância q 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). 77 E, só para não perder o costume: As regras do português devem ser seguidas. Uso de Advérbios de Modo 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. 78 O texto deve ser fácil e agradável de ler.
  • 14. 14 Consistência entre Texto e Referências q 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... 79 Se são diversos, por que só há uma referência? Redundância 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. 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. 80 A coerência do texto deve ser mantida sempre. Uso de Referências no Abstract/Resumo 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). 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. 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 Relação entre Causa e Efeito q 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. 82 Citações com Diferentes Estilos q 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]. q 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. 83 Deve-se padronizar estilo do texto e também das referências. Verifique o padrão na chamada de trabalhos. Referência a Figuras q ... como mostra a Figura 1 – Realização dos objetivos e metas através de projetos e as restrições organizacionais . q ... como mostra a figura abaixo. Compare: q ... como mostra a Figura 1. 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. Procure não misturar notações diferentes. 84
  • 15. 15 Traduções Incorretas / Não Recomendadas q comprehensive – abrangente – compreensivo q to support – apoiar – suportar q performance – desempenho – 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 http://www.cintiabarreto.com.br/didatica/curiosidadesgraficas.shtml Informalidade da Fala na Escrita Uso de pronomes q 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 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. 86 O texto científico é um texto formal. Frases Grandes 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 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. 87 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… Uso de “o mesmo” 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 Termos a Serem Evitados q Advérbios q Brincadeiras, Ironia ou Piadas q “ruim” e “bom” (não julgue) q “perfeito” (nada é) q “uma solução ideal” q “hoje em dia”, “atualmente” q “em breve” q “Ficamos surpresos ao perceber que...” q “parece que...” q “parece mostrar que...” q “diferente” (de quê?) q “provavelmente” q “simples” q “obviamente”, “claramente” (para quem?) q “na verdade” q Segunda pessoa q Primeira pessoa q “um pesquisador famoso” q “poucos”, “muitos”, “todos”, “nenhum” (quem disse? Como foi provado?) q “deve” (quem disse?) Fonte: Santoro, F., Notas de Aula – Apresentação do MetodoloWgia adaz Pleasqwuisai cCiken,tí fi2ca0 200107.2 , Programa de Pós-Graduação em Informática – UNIRIO. apud Wazlawick, 2007 Escrevendo Textos 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
  • 16. 16 Ética... q ... em Sala de Aula – Não colar ou dar cola em provas – Não plagiar o trabalho – Não trapacear nas leituras e listas de exercício – Não sobrecarregar os colegas do grupo – Não assinar presença por colegas – Dar crédito apropriado quando usar trabalhos de terceiros (ver nota de rodapé!) q 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 q Necessidade de postura ética em relação à computação: – Profissionais de computação – Usuários e Clientes – Ser Humano q “Comportamento do cientista” (Merton, 1942) – Comunalismo: requer que o conhecimento científico seja público – Universalismo: requer que a ciência seja independente de raça, cor, credo... – Desinteresse: requer que os resultados da pesquisa não sejam manipulados – Ceticismo organizado: requer que afirmações não devam ser aceitas pela palavra da autoridade 92 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 Ética na Pesquisa q Algumas questões para reflexão (Wainer, 2007) – 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? – Pesquisas qualitativas » Que garantias de anonimato da organização na publicação final dos resultados são apropriadas? » A organização tem poder de veto na publicação dos resultados? » Se a organização já autorizou a pesquisa, é preciso pedir consentimento a cada um dos sujeitos estudados? 93 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 Plágio e Auto Plágio q Plágio x Pesquisa – Plágio não é pesquisa – 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. » Descubra como transformar a experiência em outro artigo J – Mesmo quando se copia um trecho de um trabalho anterior seu é preciso referenciá-lo! – Auto-plágio tem sido cada vez menos tolerado... 94 Processo de Revisão q Os artigos submetidos a eventos científicos serão avaliados por revisores selecionados (em geral, 2 a 3) q Ajuste de foco do artigo com a chamada do evento – Deve ser feito antes da submissão. Se o foco estiver errado, aumentam as chances de o artigo ser recusado – Analise a lista de revisores para tentar inferir o possível foco que será dado nas revisões q Garanta uma boa revisão prévia do artigo. – Não é trabalho do revisor corrigir o seu trabalho, mas sim apontar os pontos fortes e fracos e a adequação ao evento. q Submissão do artigo. – Verifique o sistema de submissão (no Brasil, é comum o uso do JEMS, no exterior, do EasyChair. Também pode ser e-mail). – Verifique a data limite (não há garantias que ela seja alterada!) q É de bom tom corrigir os itens apontados pelos revisores (eles não foram escolhidos ao acaso), apesar de não haver uma segunda revisão... 95 Processo de Seleção de Artigos q Pesquisadores selecionam coordenador do comitê de programa q Coordenador do comitê de programa seleciona membros do comitê de programa q Coordenador do comitê de programa apresenta Chamada de Trabalhos (Call for Papers) q Autores submetem artigos q Coordenador do comitê de programa distribui artigos para os membros do comitê q Membros do comitê redistribuem artigos para revisores (se for o caso) q Revisores apresentam revisão dos artigos q 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
  • 17. 17 Comunicação da Revisão q Variam de acordo com a conferência/periódico q Avaliação numérica (notas em critérios) – Originalidade – Conteúdo técnico – Relevância – Contribuição – Referencial teórico – Clareza na escrita, organização do texto e apresentação q Avaliação qualitativa – Resumo da contribuição – 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 q Originalidade e Contribuição: – 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 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 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 Critérios de Avaliação de Artigos do SBQS q Qualidade técnica: – O artigo tem qualidade técnica? – 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 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. – 1: Apresentação péssima 2: Apresentação ruim 3: Apresentação boa 4: Apresentação ótima 5: Apresentação excelente 99 Critérios de Avaliação de Artigos do SBQS q 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: 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 q Resumo (Summary): – (Uma breve descrição do artigo) q Pontos Fortes (Paper Strengths): q Pontos Fracos (Paper Weakness): q Comentários para os Autores (Comments to Authors): – (Comentários e sugestões para o autor melhorar a qualidade do artigo) q E ainda um campo que só os revisores veem… 100 Preparando a Apresentação q 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 conteúdo dos slides q Evite colocar muito texto nos slides – O objetivo do texto é guiar a apresentação, e não ser lido – Não é para colocar o texto completo do artigo na apresentação q Estrutura dos slides – Baseie-se na estrutura do texto, mas não se prenda a ela – Nem sempre a estrutura do artigo é adequada em uma apresentação – Lembre-se que o filme baseado no livro é diferente do livro… 101 Preparando a Apresentação q Treinando a apresentação – Treine! – Ao falar em voz alta, conseguimos perceber se o texto flui de forma adequada – Elimine os textos supérfluos, reorganize a apresentação q A apresentação no dia – Fique calmo – Fale pausadamente – Demonstre segurança – Não leia, apresente – Vá bem vestido! J q Respondendo às perguntas – Prepare-se para as perguntas mais difíceis – Se não for uma pergunta, não responda – Você não estará participando de um debate, nada de réplicas e tréplicas 102
  • 18. 18 Referências 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. q 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. q ROCHA, A. R. C., MALDONADO, J. C., WEBER, K. C., 2001, “Qualidade de Software: Teoria e Prática”, Prentice Hall. q SCHOTS, N. C. L., Uma Abordagem para a Identificação de Causas de Problemas Utilizando Grounded Theory. Dissertação de Mestrado. COPPE/UFRJ, 2010. q 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. q SHAW, M., Writing Good Software Engineering Research Papers – Minitutorial, ICSE 2003. q WAZLAWICK, R. S., 2009, “Metodologia de Pesquisa para Ciência da Computação”, 1a edição, Elsevier Editora, Rio de Janeiro. q Curiosidades Gráficas: Palavras e termos semelhantes, mas com significados diferentes: http://www.cintiabarreto.com.br/didatica/curiosidadesgraficas.shtml q 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 q Alguns slides deste mini-curso foram baseados em material de outras pessoas, conforme citado em slides específicos. Meus agradecimentos ao auxílio prestado. 103 WAMPS 2011 - VII Workshop Anual do MPS Como Escrever um Relato de Experiência Gleison Santos gleison.santos@uniriotec.br