10/10/2020 Escrevendo Bons Artigos de Pesquisa de Engenharia de Software Mary Shaw

Página 1

Escrevendo bons artigos de pesquisa de engenharia de software

Minitutorial

Mary Shaw
Universidade Carnegie Mellon
mary.shaw@cs.cmu.edu

Resumo • Que evidências concretas mostram que o seu resultado

Pesquisadores de engenharia de software resolvem problemas de
vários tipos diferentes. Para fazer isso, eles produzem vários
diferentes tipos de resultados, e eles devem desenvolver
evidências apropriadas para validar esses resultados. Eles frequentementerepresenta uma contribuição interessante, sólida e significativa
relatar suas pesquisas em artigos de conferências. Eu analisei o
resumos de trabalhos de pesquisa submetidos ao ICSE 2002 em
a fim de identificar os tipos de pesquisa relatados no
submeti e aceitei artigos, e observei o
discussões do comitê de programa sobre quais papéis
aceitar. Este relatório apresenta os paradigmas de pesquisa de
os papéis, preocupações comuns do comitê de programa,
e estatísticas sobre as taxas de sucesso. Esta informação deve
ajudar os pesquisadores a projetar melhores projetos de pesquisa e escrever
trabalhos que apresentam seus resultados da melhor forma.
Palavras-chave: design de pesquisa, paradigmas de pesquisa,
validação, profissão de software, redação técnica
I. Introdução
Na engenharia de software, trabalhos de pesquisa são habituais
veículos para relatar os resultados à comunidade de pesquisa.
Em um artigo de pesquisa, o autor explica a um interessado
leitor o que ele realizou e como o autor
conseguiu, e por que o leitor deve se preocupar. Um bem
papel de pesquisa deve responder a uma série de perguntas:
• Qual foi, precisamente, a sua contribuição?
• Que pergunta você respondeu?
• Por que o leitor deve se preocupar?
• A que questão mais ampla isso aborda?
• Qual é o seu novo resultado?
• Com que novos conhecimentos você contribuiu para
o leitor pode usar em outro lugar?
• Qual trabalho anterior (seu ou de outra pessoa)
você constrói? O que você fornece a um superior
alternativa para?
• Como o seu resultado é diferente e melhor do que
este trabalho anterior?
• Qual é, precisamente e em detalhes, o seu novo resultado?
• Por que o leitor deve acreditar no seu resultado?
• Qual padrão deve ser usado para avaliar seu
afirmação?
satisfaz sua reivindicação?
Se você responder a essas perguntas com clareza, provavelmente
comunique bem o seu resultado. Se além do seu resultado
de acordo com nosso conhecimento de engenharia de software, você
tem uma boa chance de ser aceito para publicação
em uma conferência ou jornal.
Outros campos da ciência e da engenharia têm
paradigmas de pesquisa estabelecidos. Por exemplo, o
modelo experimental de física e o duplo-cego
estudos de medicamentos são compreendidos, pelo menos em ampla
esboço, não só pela comunidade de pesquisa, mas também por
o público em geral. Além de fornecer orientações para
o desenho da pesquisa em uma disciplina, esses paradigmas
estabelecer o escopo das disciplinas científicas por meio de um
processo social e político de "estabelecimento de limites" [5].
A engenharia de software, no entanto, ainda não desenvolveu
este tipo de orientação bem compreendida. Eu anteriormente [19,
20] discutiu os primeiros passos para esse entendimento,
incluindo um modelo da forma como a engenharia de software
técnicas maduras [17, 18] e críticas à falta de
rigor em engenharia de software experimental [1, 22, 23, 24,
25]. Essas discussões criticam a engenharia de software
relatórios de pesquisa em relação aos padrões clássicos
paradigmas. A discussão aqui difere daquelas em que
esta discussão relata os tipos de artigos que são
aceitos nas práticas como bons relatórios de pesquisa. Outro
atividade atual, o Impact Project [7] busca rastrear a
influência da pesquisa de engenharia de software na prática.
A discussão aqui se concentra nos paradigmas ao invés de
o conteúdo da pesquisa
Este relatório examina como os engenheiros de software respondem
as questões acima, com ênfase no design do
projecto de investigação e organização do relatório. De outros
fontes (por exemplo, [4]) lidam com questões específicas de
escrita. Muito concretamente, os exemplos aqui vêm de
os documentos submetidos ao ICSE 2002 e o programa
comissão de revisão desses documentos. Esses exemplos relatam
resultados de pesquisas em engenharia de software. Conferências
frequentemente incluem outros tipos de documentos, incluindo experiência
relatórios, materiais sobre educação em engenharia de software e
ensaios de opinião.

https://translate.googleusercontent.com/translate_f 1/11
10/10/2020 Escrevendo Bons Artigos de Pesquisa de Engenharia de Software Mary Shaw

0-7695-1877-X / 03 $ 17,00 © 2003 IEEE 726

Página 2

2. Qual foi, exatamente, a sua contribuição? inclui todas as atividades analíticas associadas à previsão
criação, determinação e estimativa de propriedades do software
Antes de relatar o que você fez, explique qual problema sistemas, incluindo funcionalidade e extra-funcional
você se propôs a resolver ou a que pergunta se propôs a responder propriedades como desempenho ou confiabilidade.
--e por que isso é importante.
A pesquisa de engenharia de software responde a perguntas sobre
métodos de desenvolvimento ou análise, sobre detalhes de
2.1 Que tipo de perguntas o software faz
projetar ou avaliar uma instância particular, sobre gener-
engenheiros investigam?
alizações sobre classes inteiras de sistemas ou técnicas, ou
De modo geral, pesquisadores de engenharia de software sobre questões exploratórias relativas à existência ou viabilidade
busque melhores maneiras de desenvolver e avaliar software. Develop- ity. A Tabela 1 lista os tipos de perguntas de pesquisa que são
opção inclui todas as atividades sintéticas que envolvem perguntado por artigos de pesquisa de engenharia de software e
criar e modificar o software, incluindo o código, fornece modelos de perguntas específicos.
documentos de design, documentação, etc. Avaliação
Tabela 1. Tipos de questões de pesquisa de engenharia de software
Tipo de pergunta Exemplos
Método ou meio de Como podemos fazer / criar / modificar / evoluir (ou automatizar fazendo) X?
desenvolvimento Qual é a melhor maneira de fazer / criar / modificar / evoluir o X?
Método de análise Como posso avaliar a qualidade / correção de X?
ou avaliação Como faço para escolher entre X e Y?
Design, avaliação ou quão bom é Y? O que é a propriedade X do artefato / método Y?
análise de um O que é um (melhor) projeto, implementação, manutenção ou adaptação para o aplicativo X?
instância particular Como X se compara a Y?
Qual é o estado atual de X / prática de Y?
Generalização ou Dado X, o que Y (necessariamente) será?
caracterização O que, exatamente, queremos dizer com X? Quais são suas características importantes?
O que é um bom modelo formal / empírico para X?
Quais são as variedades de X, como estão relacionadas?
Estudo de viabilidade ou X existe mesmo, e se sim, como é?
exploração É possível realizar X em tudo?

Os primeiros dois tipos de pesquisa produzem métodos de
desenvolvimento ou de análise que os autores investigaram em
uma configuração, mas isso pode provavelmente ser aplicado em outra
configurações. O terceiro tipo de pesquisa lida explicitamente com
algum sistema, prática, design ou outra instância particular
de um sistema ou método; estes podem variar de narrativas
sobre a prática industrial para comparações analíticas de
designs alternativos. Para este tipo de pesquisa a instância
em si deve ter algum apelo amplo - uma avaliação de
Java tem mais probabilidade de ser aceito do que uma simples avaliação
da linguagem de brinquedo que você desenvolveu no verão passado.
Generalizações ou caracterizações se elevam explicitamente acima
os exemplos apresentados no artigo. Finalmente, papéis que
lidar com um problema de uma maneira completamente nova, às vezes
tratado de forma diferente de papéis que melhoram a técnica anterior,
então, "viabilidade" é uma categoria separada (embora tal
documentos foram submetidos ao ICSE 2002).
Comparação crítica de Newman de HCI e tradicional
papéis de engenharia [12] descobriram que os papéis de engenharia
eram principalmente incrementais (modelo melhorado, melhorado
técnica), enquanto muitos dos artigos de HCI foram lançados
terreno (observações preliminares para um modelo, totalmente novo
técnica). Uma interpretação razoável é que o
disciplinas tradicionais de engenharia são muito mais maduras
do que HCI, e assim o caráter da pesquisa pode
razoavelmente diferem [17, 18]. Além disso, parece diferente
disciplinas têm expectativas diferentes sobre o "tamanho" de
um resultado de pesquisa - a medida em que se baseia em
conhecimento ou abre novas questões. Na facilidade do ICSE,
os tipos de perguntas que são de interesse e o mínimo
incremento interessante pode diferir de uma área para outra.
2.2 Quais destes são mais comuns?
O tipo mais comum de papel ICSE relata um
método melhorado ou meios de desenvolver software que
é projetar, implementar, evoluir, manter ou
caso contrário, operando no próprio sistema de software. Papéis
abordar essas questões domina tanto o submetido
e os artigos aceitos. Também bastante comuns são os papéis
sobre métodos de raciocínio sobre sistemas de software,
principalmente análise de correção (teste e
verificação). Os papéis de análise têm uma aceitação modesta
vantagem nesta conferência muito seletiva.

727

https://translate.googleusercontent.com/translate_f 2/11
10/10/2020 Escrevendo Bons Artigos de Pesquisa de Engenharia de Software Mary Shaw
Página 3

A Tabela 2 apresenta a distribuição das submissões ao ICSE a tabela dá o número de artigos submetidos e ac-
2002, com base na leitura dos resumos (não dos artigos completos --- cepted, a porcentagem do conjunto total de papel de cada tipo,
mas lembre-se de que o resumo diz ao leitor o que ex- e a taxa de aceitação dentro de cada tipo de pergunta.
pect do papel). Para cada tipo de questão de pesquisa, As Figuras 1 e 2 mostram essas contagens e distribuições.

Tabela 2. Tipos de questões de pesquisa representadas nas submissões e aceitações do ICSE 2002
Tipo de pergunta Submetido Aceitaram Razão Acc / Sub
Método ou meio de desenvolvimento 142 (48%) 18 (42%) (13%)
Método para análise ou avaliação 95 (32%) 19 (44%) (20%)
Projeto, avaliação ou análise de uma instância particular 43 (14%) 5 (12%) (12%)
Generalização ou caracterização 18 (6%) 1 (2%) (6%)
Estudo de viabilidade ou exploração 0 (0%) 0 (0%) (0%)
TOTAL 298 (100,0%) 43 (100,0%) (14%)

Questão Questão

300 --~ oOOio -i, i

250 80 * / 0

200 ~: ~ t
60%
150
40%
oo ~% ~;
~o ~ 20% -I

o Iii i: ii i i: G ,

Develop Analy Eval Gener Feas Total Dewl Analy Eval Gener Feas Total
• Aceito [] Rejeitado I • Aceito [] Rejeitado
Eu

Figura 1. Contagens de aceitações e rejeições Figura 2. Distribuição de aceitações e rejeições

por tipo de questão de pesquisa por tipo de questão de pesquisa

2.3 O que os comitês de programa procuram?
Atuando em nome de leitores em potencial, o programa
comitê procura uma declaração clara do específico
problema que você resolveu - a questão sobre o desenvolvimento de software-
resposta que você respondeu - e uma explicação de como o
resposta ajudará a resolver um importante software de engenharia
problema. Você vai dedicar a maior parte do seu papel para descrever
seu resultado, mas você deve começar explicando o que
pergunta que você está respondendo e por que a resposta é importante.
Se o comitê de programa tiver problemas para descobrir
se você desenvolveu uma nova técnica de avaliação e
demonstrou em um exemplo, ou aplicou uma técnica que você
relatado no ano passado para um novo exemplo do mundo real, ou
avaliou o uso de uma avaliação bem estabelecida
técnica, você não foi claro.
3. Qual é o seu novo resultado?
Explique precisamente com que você contribuiu para o
estoque de conhecimento de engenharia de software e como isso é
útil além do seu próprio projeto.
3.1 Que tipo de resultados os engenheiros de software
produzir?
As contribuições tangíveis da engenharia de software
pesquisa pode ser procedimentos ou técnicas para desenvolver
ment ou análise; eles podem ser modelos que generalizam de
exemplos específicos, ou podem ser ferramentas, soluções específicas,
ou resultados sobre sistemas específicos. A Tabela 3 lista os tipos
dos resultados da pesquisa que são relatados no engenheiro de software
documentos de pesquisa e fornece exemplos específicos.
3.2 Quais destes são mais comuns?
De longe, o tipo mais comum de papel ICSE relata um
novo procedimento ou técnica para desenvolvimento ou análise.
Modelos de vários graus de precisão e formalidade foram
também comum, com melhores taxas de sucesso para
do que para modelos qualitativos. Ferramentas e anotações estavam bem
representado, geralmente como resultados auxiliares em combinação
com um procedimento ou técnica. A Tabela 4 dá a distribuição
ção de submissões ao ICSE 2002, com base na leitura do
resumos (mas não os artigos), seguidos por gráficos do
contagens e distribuições nas Figuras 3 e 4.

728

Página 4

https://translate.googleusercontent.com/translate_f 3/11
10/10/2020 Escrevendo Bons Artigos de Pesquisa de Engenharia de Software Mary Shaw

Tabela 3. Tipos de resultados de pesquisa de engenharia de software

Tipo de resultado
Procedimento ou
técnica
Qualitativo ou
modelo descritivo
Modelo empírico
Modelo analítico
Ferramenta ou notação
Solução específica,
protótipo, resposta,
ou julgamento
Relatório
Exemplos
Uma maneira nova ou melhor de fazer alguma tarefa, como design, implementação, manutenção,
medição, avaliação, seleção de alternativas; inclui técnicas para
implementação, representação, gestão e análise; uma técnica deve ser
operacional - não conselhos ou diretrizes, mas um procedimento
Estrutura ou taxonomia para uma área problemática; estilo arquitetônico, estrutura ou padrão de design;
análise de domínio não formal, listas de verificação bem fundamentadas, informal bem argumentado
generalizações, orientação para integrar outros resultados, interessante bem organizado
observações
Modelo preditivo empírico baseado em dados observados
Modelo estrutural que permite análise formal ou manipulação automática
Ferramenta implementada que incorpora uma técnica; linguagem formal para apoiar uma técnica ou modelo
(deve ter um cálculo, semântica ou outra base para calcular ou fazer inferência)
Solução para o problema de aplicação que mostra a aplicação dos princípios SE - 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
Observações interessantes, regras de thnmb, mas não suficientemente gerais ou sistemáticas para chegar ao
nível de um modelo descritivo.

Tabela 4. Tipos de resultados de pesquisa representados nas submissões e aceitações do ICSE 2002
Tipo de resultado Submetido Aceitaram Razão Acc / Sub
Procedimento ou técnica 152 (44%) 28 (51%) 18%
Modelo qualitativo ou descritivo 50 (14%) 4 (7%) 8%
Modelo empírico 4 (1%) 1 (2%) 25%
Modelo analítico 48 (14%) 7 (13%) 15%
Ferramenta ou notação 49 (14%) 10 (18%) 20%
Solução, protótipo, resposta ou julgamento específico 34 (10%) 5 (9%) 15%
Relatório 11 (3%) 0 (0%) 0%
TOTAL 348 (100,0%) 55 (100,0%) 16%

Resultado Resultado

350 100%,
300
80% •

i li ~ ¸¸) ~ II
]
250
........
'E'?. I
200 60% -
; ii !! iiiiiiiiiiiiii
..............................::

150 •
100
iiiiiiiiii
, eu
50 '

0 iit) eu
200,0 I z 'i
/ .to, j .o.,
l "Aceep, ed [] Re, cted j • Aceito [3 Rejeitado

Figura 3. Contagens de aceitações e rejeições Figura 4. Distribuição de aceitações e rejeições

por tipo de resultado por tipo de resultado

729

Página 5

O número de resultados é maior do que o número de
documentos porque 50 artigos incluíram um resultado de apoio,
geralmente uma ferramenta ou um modelo qualitativo.
Projetos de pesquisa comumente produzem resultados de vários
tipos. No entanto, conferências, incluindo ICSE, geralmente
impor limites de página estritos. Na maioria dos casos, isso também fornece
usar em outras configurações. Se essa ideia for aumentada
confiança na ferramenta ou técnica, mostre como seu
experiência deve aumentar a confiança do leitor
para aplicações além do exemplo do papel.
Quais são as novidades aqui?

https://translate.googleusercontent.com/translate_f 4/11
10/10/2020 Escrevendo Bons Artigos de Pesquisa de Engenharia de Software Mary Shaw
pouco espaço para permitir o desenvolvimento completo de mais de um
ideia, talvez com uma ou duas ideias de apoio. Muitos
autores apresentam as ideias individuais em documentos de conferências,
e, em seguida, sintetizá-los em um artigo de jornal que permite
espaço para desenvolver relações mais complexas entre resultados.
3.3 O que os comitês de programa procuram?
O comitê do programa procura por novidades interessantes,
resultados empolgantes que aumentam significativamente nossa capacidade de tentei. Mas foi sua contribuição a técnica que é
desenvolver e manter software, para saber a qualidade do
software que desenvolvemos, para reconhecer os princípios gerais
sobre software ou para analisar propriedades de software.
Você deve explicar o seu resultado de tal forma que
outra pessoa poderia usar suas idéias. Certifique-se de explicar
o que é novo ou original - é a ideia, a aplicação de
a ideia, a implementação, a análise ou o quê?
Defina os termos críticos com precisão. Use-os de forma consistente.
Quanto mais formal ou analítico for o artigo, mais importante
isto é.
Aqui estão algumas perguntas que o comitê de programa
pode perguntar sobre o seu trabalho:
O que, exatamente, você afirma contribuir?
Seu resultado satisfaz plenamente suas afirmações? São as
as definições são precisas e os termos são usados de forma consistente?
Os autores tendem a ter problemas em algumas
situações. Aqui estão alguns exemplos, com conselhos para
ficar longe de problemas: "
• Se o seu resultado deve funcionar em sistemas grandes, explique
por que você acredita que isso aumenta.
• Se você afirma que seu método é "automático", use-o
não deve exigir intervenção humana. Se é
automático quando está operando, mas requer manual
assistência para configurar, diga-o. Se for automático
exceto para certas facilidades, diga-o e diga com que frequência
as exceções ocorrem.
• Se você afirma que seu resultado é "distribuído", provavelmente
não deve ter um único controlador ou servidor central.
Em caso afirmativo, explique que parte dele é distribuída e
que parte não é.
• Se você está propondo uma nova notação para um antigo
problema, explique por que sua notação é claramente
superior ao antigo.
• Se o seu trabalho é um "relato de experiência", relacionando o
uso de uma ferramenta ou técnica relatada anteriormente em um
projeto de software prático, certifique-se de explicar
que ideia o leitor pode tirar do papel para
Página 6
Como em outras áreas da ciência e engenharia, software
o conhecimento de engenharia cresce gradativamente. Programa
comitês estão muito interessados em sua interpretação de
trabalhos anteriores na área. Eles querem saber como você trabalha
está relacionado ao trabalho anterior, seja por construção nele ou por
fornecendo uma alternativa. Se você não explicar isso, é
difícil para o comitê de programa entender como você
adicionado ao nosso estoque de conhecimento. Você também pode danificar
sua credibilidade se o comitê de programa não puder dizer
se você sabe sobre trabalhos relacionados.
https://translate.googleusercontent.com/translate_f
O comitê do programa quer saber o que é novo
ou emocionante, e por quê. O que, especificamente, é o
contribuição? Qual é o incremento em relação ao trabalho anterior de
os mesmos autores? por outros autores? Isso é suficiente
incremento, dados os padrões usuais da subdisciplina?
Acima de tudo, o comitê do programa também quer saber
o que você realmente contribuiu para nosso estoque de conhecimento
sobre engenharia de software. Claro, você escreveu esta ferramenta e
incorporado na ferramenta, ou estava fazendo uma ferramenta que é mais
eficazes do que outras ferramentas que implementam a técnica, ou
foi mostrando que a ferramenta que você descreveu em um
o papel realmente funcionou em um problema prático de grande escala?
É melhor para você, como autor, explicar do que para o
comitê de programa para adivinhar. Seja claro sobre sua reivindicação ...
Horrível • • Resolvi completamente e de forma geral ...
Eu (a menos que você realmente tenha!)
Mau • • Trabalhei em galumphing.
(ou estudou, investigou, procurou,
explorado)
Pobre • • Trabalhei para melhorar a galopagem.
(ou contribuiu para, participou,
ajudou com)
Bom • • Mostrei a viabilidade de compor
blitzing com flitzing.
Eu • Eu melhorei significativamente a precisão de
o detector padrão.
(ou provado, demonstrado, criado,
estabelecido, encontrado, desenvolvido)
Melhor • • Automatizei a produção de Ritz
tabelas de especificações.
• Com uma nova aplicação do blivet
transformar, consegui um aumento de 10%
em velocidade e uma melhoria de 15% em
cobertura sobre o método padrão.
Use verbos que mostram resultados e conquistas, não apenas
esforço e atividade.
["T 0 'não. Faça ou não faça . Não há tO ,." - Yoda. [
O que foi feito antes? Como o seu trabalho é diferente
ou melhor?
Em que tecnologia existente sua pesquisa se baseia?
Qual tecnologia existente ou pesquisa anterior faz seu
a pesquisa fornece uma alternativa superior para? O que há de novo
aqui em comparação com seu próprio trabalho anterior? o que
alternativas têm outros pesquisadores buscado, e como é
seu trabalho é diferente ou melhor?
730
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. O que é novo,
emocionante ou não óbvio sobre a integração? Você fez
generalizar resultados anteriores? Você achou um melhor
representação? Sua pesquisa melhorou o indivíduo
resultados ou componentes, bem como integrá-los? UMA
papel que simplesmente relata o uso de vários elementos
juntos não é suficiente, mesmo se for bem projetado. Lá
deve ser uma ideia ou lição ou modelo que o leitor pode tirar
5/11
10/10/2020 Escrevendo Bons Artigos de Pesquisa de Engenharia de Software Mary Shaw
Explique a relação com outro trabalho claramente ...
Horrível • O problema de galumphing atraiu
muita atenção [3,8,10,18,26,32,37]
Mau • Smith [36] e Jones [27] trabalharam em
galumphing.
Pobre • Smith [36] abordou galumphing por
blitzing, enquanto Jones [27] tomou um
abordagem esvoaçante.
Bom • Abordagem explosiva de Smith para galumphing
[36] alcançou 60% de cobertura [39].
Jones [27] alcançou 80% por flitz,
mas apenas para casos sem ponteiro [16].
Melhor • A abordagem veloz de Smith para galumphing
[36] alcançou 60% de cobertura [39].
Jones [27] alcançou 80% por flitz,
mas apenas para casos sem ponteiro [16].
Modificamos a abordagem de blitz para
use a representação do kernel de flitzing
e alcançou 90% de cobertura enquanto
relaxando a restrição para que apenas
estruturas de dados cíclicas são proibidas.
Qual, precisamente, é o resultado?
Explique qual é o seu resultado e como funciona. Estar
concreto e específico. Use exemplos.
Se você apresentar um novo modelo, seja claro sobre seu poder.
Quão geral é? É baseado em dados empíricos, em um
semântica formal, em princípios matemáticos? Como
formal é - um modelo qualitativo que fornece design
orientação pode ser tão valiosa quanto um modelo matemático de
algum aspecto de correção, mas eles terão que satisfazer
diferentes padrões de prova. O modelo será dimensionado para
problemas de tamanho adequado ao seu domínio?
Se você introduzir uma nova métrica, defina-a com precisão. Faz
mede o que pretende medir e faz melhor
do que as alternativas? Por quê?
Se você introduzir um novo estilo arquitetônico, design
padrão ou elemento de design semelhante, trate-o como se fosse um
nova generalização ou modelo. Como isso difere do
alternativas? De que maneira é melhor? Que problema real
isso resolve? Isso escala?
Página 7
4. Por que o leitor deve acreditar no seu resultado?
Mostre evidências de que seu resultado é válido - que ele realmente
ajuda a resolver o problema que você se propôs a resolver.
4.1. Que tipos de validação de software
engenheiros fazem?
Engenheiros de software oferecem vários tipos de evidências em
suporte de seus resultados de pesquisa. É essencial selecionar um
forma de validação que é apropriada para o tipo de
Tabela 5. Tipos de validação de pesquisa de engenharia de software
Exemplos de tipo de validação
Análise Eu analisei meu resultado e o considero satisfatório por meio de uma análise rigorosa, por exemplo ....
Para um modelo formal
Para um modelo empírico
Para um experimento controlado
https://translate.googleusercontent.com/translate_f
do papel e se aplicam a alguma outra situação.
Se o seu artigo é principalmente um relato de experiência
aplicando os resultados da pesquisa a um problema prático, diga o que
o leitor pode aprender com a experiência. São seus
conclusões fortes e bem fundamentadas? Você mostra
dados e / ou estatísticas comparativas? Um relatório anedótico sobre
um único projeto geralmente não é suficiente. Além disso, se o seu relatório
combina inovação adicional com validação por meio de
experiência, evite confundir sua discussão sobre o
inovação com seu relato de experiência. Afinal, se
você mudou o resultado antes de aplicá-lo, você está
avaliar o resultado alterado. E se você mudou o
resultado enquanto o estava aplicando, você pode ter
confundiu as experiências com as duas versões.
Se uma ferramenta desempenha um papel destacado em seu artigo, o que é
o papel da ferramenta? Ele simplesmente suporta o principal
contribuição, ou é a própria ferramenta uma contribuição principal,
ou algum aspecto do uso ou implementação da ferramenta é o
ponto principal? Um leitor pode aplicar a ideia sem a ferramenta?
Se a ferramenta é uma parte central do resultado, o que é a técnica
inovação embutida na ferramenta ou sua implementação?
Se uma implementação de sistema desempenha um papel destacado em
seu papel, qual é o papel da implementação? É o
som do sistema? Ele faz o que você afirma que faz? o que
ideias que o sistema demonstra?
• Se a implementação ilustra uma arquitetura ou
estratégia de design, o que ela revela sobre o
arquitetura? Qual foi a lógica do design? o que
foram as compensações de design? O que o leitor pode aplicar
para uma implementação diferente?
• Se o implementação demonstra a
técnica de implementação, como isso ajuda o
leitor usa a técnica em outro ambiente?
• Se a implementação demonstrar uma capacidade ou
melhoria de desempenho, que evidências concretas
oferece para apoiar a reivindicação?
• Se o próprio sistema é o resultado, de que forma é um
contribuição para o conhecimento? Será, por exemplo,
mostre que você pode fazer algo que ninguém fez
antes (especialmente se as pessoas duvidavam que isso poderia
ser feito)?
731
resultado da pesquisa e o método utilizado para obtê-lo.
Como um exemplo óbvio, um modelo formal deve ser
apoiado por derivação e prova rigorosas, não por um ou
dois exemplos simples. Por outro lado, um simples
exemplo derivado de um sistema prático pode desempenhar um importante
papel na validação de um novo tipo de método de desenvolvimento.
A Tabela 5 lista os tipos de validação de pesquisa que são usados
em artigos de pesquisa de engenharia de software e fornece
exemplos específicos. Nesta tabela, os exemplos são relacionados a
o tipo de resultado ao qual se aplicam.
... derivação e prova rigorosas
... dados sobre o uso em situação controlada
... experimento cuidadosamente projetado com estatisticamente significativo
6/11
10/10/2020 Escrevendo Bons Artigos de Pesquisa de Engenharia de Software Mary Shaw
resultados
Avaliação Dados os critérios declarados, meu resultado ...
Para um modelo descritivo ... descreve adequadamente fenômenos de interesse ...
Para um modelo qualitativo ... explica os fenômenos de interesse ...
Para um modelo empírico ... é capaz de prever ... porque ..., ou
... gera resultados que se ajustam aos dados reais ...
Inclui estudos de viabilidade, projetos-piloto
Experiência Meu resultado foi usado em exemplos reais por outra pessoa além de mim, e as evidências de sua
correção / utilidade / eficácia é ...
Para um modelo qualitativo ... narrativa
Para um modelo empírico ou ferramenta ... dados, geralmente estatísticos, na prática
Para uma notação ou técnica ... comparação de sistemas em uso real
Exemplo Aqui está um exemplo de como funciona
Para uma técnica ou procedimento ... um exemplo de "fatia da vida" baseado em um sistema real ...
Para uma técnica ou procedimento ... um sistema que venho desenvolvendo ...
Para uma técnica ou procedimento ... um exemplo de brinquedo, talvez motivado pela realidade
O exemplo da "fatia da vida" tem mais probabilidade de ser convincente, especialmente se acompanhado por um
explicação de por que o exemplo simplificado retém a essência do problema que está sendo resolvido.
Exemplos de brinquedos ou livros didáticos muitas vezes falham em fornecer validação persuasiva, (exceto para
exemplos usados como problemas modelo pelo campo).
Persuasão Eu pensei muito sobre isso, e acredito apaixonadamente que ...
Para uma técnica ... se você fizer da seguinte forma, então ...
Para um sistema ... um sistema construído assim iria ...
Para um modelo ... este exemplo mostra como minha ideia funciona
A validação puramente por persuasão raramente é suficiente para um artigo de pesquisa. Observe, porém, que se o
a questão original era sobre a viabilidade, um sistema em funcionamento, mesmo sem análise, pode ser suficiente
Afirmação flagrante Nenhuma tentativa séria de avaliar o resultado. Isto é altamente improvável que seja aceitável
Os tipos de validação de maior sucesso foram baseados em
4.2 Quais são os mais comuns? análise e experiência do mundo real. Exemplos bem escolhidos
Infelizmente, bem mais de um quarto dos resumos ICSE 2002 também tiveram sucesso. A persuasão não foi persuasiva e
não dão nenhuma indicação de como os resultados do artigo são validados, a avaliação narrativa teve apenas um pouco mais de sucesso.
se em tudo. Mesmo quando o resumo menciona que o resultado A Tabela 6 apresenta a distribuição das submissões ao ICSE
foi aplicado a um exemplo, nem sempre foi claro 2002, com base na leitura dos resumos (mas não dos artigos),
se o exemplo era um exemplo de livro ou um relatório seguido por gráficos das contagens e distribuições.
sobre o uso em campo ou algo intermediário. As Figuras 5 e 6 mostram essas contagens e distribuições.

732

Página 8

Tabela 6. Tipos de validação de pesquisa representados nas submissões e aceitações do ICSE 2002
Tipo de validação Submetido Aceitaram Razão Acc / Sub
Análise 48 (16%) 11 (26%) 23%
Avaliação 21 (7%) 1 (2%) 5%
Experiência 34 (11%) 8 (19%) 24%
Exemplo 82 (27%) 16 (37%) 20%
Alguns exemplos, não podem dizer se é um brinquedo ou uso real 6 (2%) 1 (2%) 17%
Persuasão 25 (8%) 0 (0,0%) 0%
Sem menção de validação no resumo 84 (28%) 6 (14%) 7%
TOTAL 300 (100,0%) 43 (100,0%) 14%

Validação Validação

300 - 100% - _ _ ,,
250 80%. . . . . . . . . . . . . . . . ~: eu ~ ~
200 Eu
iiiiiiiiiii!
100
50 20%. ~

https://translate.googleusercontent.com/translate_f 7/11
10/10/2020 Escrevendo Bons Artigos de Pesquisa de Engenharia de Software Mary Shaw
o 0% -
-" ),Aceitar. t U " Aceito [] Rejeitado-]
Figura 5. Contagens de aceitações e rejeições
por tipo de validação
4.3 O que os comitês de programa procuram?
O comitê do programa procura evidências sólidas para
apoie o seu resultado. Não é suficiente que sua ideia funcione
para você, deve haver também evidência de que a ideia ou o
a técnica também ajudará outra pessoa.
As estatísticas acima mostram que a análise,
experiência no campo e bom uso de exemplos realistas
tendem a ser as maneiras mais eficazes de mostrar por que seu
resultado deve ser acreditado. Narrativa despreocupada, qualitativa
a análise também pode funcionar se o raciocínio for sólido.
Por que o leitor deve acreditar no seu resultado?
O artigo é argumentado de forma persuasiva? Que evidência é
apresentado para apoiar a reivindicação? Que tipo de evidência é
oferecido? Atende ao padrão usual do
subdisciplina?
O tipo de avaliação que você está fazendo é descrito claramente
e com precisão? "Experiência controlada" requer mais
do que a coleta de dados, e "estudo de caso" requer mais do que
discussão anedótica. Estudos piloto que estabelecem as bases
para experimentos controlados muitas vezes não são publicáveis por
si mesmos.
733
Página 9
• Se você realizou um experimento controlado, explique o
design experimental. Qual é a hipótese? O que é
o tratamento? O que está sendo controlado? Quais dados
você coletou e como você analisou isso? São as
resultados significativos? Quais são os potencialmente
fatores de confusão, e como eles são tratados? Faz
as conclusões seguem rigorosamente do
dados experimentais?
• Se você realizou um estudo empírico, explique o que
você mediu, como você analisou, e o que você
concluído. Que dados você coletou e como? Como
é a análise relacionada ao objetivo de apoiar o seu
reclamar sobre o resultado? Não confunda correlação
com causalidade.
• Se você usar um pequeno exemplo para explicar o resultado,
fornecer evidências adicionais de seu uso prático e
escalabilidade.
5. Como você combina os elementos em um
estratégia de pesquisa?
É claro que nem todas as combinações de uma pesquisa
pergunta, um resultado e uma estratégia de validação levam a um bom
pesquisa. A engenharia de software não se desenvolveu bem
orientação geral sobre esta questão.
As tabelas 1, 3 e 5 definem um espaço tridimensional. Alguns
partes desse espaço são densamente povoadas: Um
paradigma comum é encontrar uma maneira melhor de realizar alguns
https://translate.googleusercontent.com/translate_f
n
~ '!! eu fll .
~,. + ~ ~ <,. + "~ oe .o "
Figura 6. Distribuição de aceitações e rejeições
por tipo de validação
A validação está relacionada à reclamação? Se você está reivindicando
melhoria de desempenho, a validação deve analisar
desempenho, não facilidade de uso ou generalidade. E
inversamente.
Esta é uma ideia tão interessante e potencialmente poderosa
que deve obter exposição, apesar da falta de concreto
evidências?
Os autores tendem a ter problemas em algumas
situações. Aqui estão alguns exemplos, com conselhos para
ficar longe de problemas:
• Se você afirma melhorar a técnica anterior, compare o seu
resultar objetivamente ao estado da técnica.
• Se você usou uma técnica de análise, siga as regras de
essa técnica de análise. Se a técnica não for um
comum na engenharia de software (por exemplo, meta-
análise, teoria da decisão, estudos do usuário ° ou outros
análises comportamentais), explicar a técnica e
padrões de prova e seja claro sobre seu
adesão à técnica.
• Se você oferece experiência prática como evidência para o seu
resultado, estabeleça o efeito de sua pesquisa. Se em tudo
possível, compare situações semelhantes com e sem
seu resultado.
Quando aconselho alunos de doutorado na seção de validação
de suas teses, eu ofereço a seguinte heurística: Olhe
cuidadosamente na breve declaração do resultado - o principal
reivindicação da tese. Isso geralmente tem duas ou três cláusulas
(por exemplo, encontrei um método eficiente e completo ... "); em caso afirmativo,
cada um apresenta um problema de validação separado. Pergunte a cada
cláusula se é uma declaração global ("sempre", "totalmente"),
uma declaração qualificada ("uma melhoria de 25%", "para
estruturas não cíclicas ... "), ou uma afirmação existencial {" nós
encontrou uma instância de '). Declarações globais geralmente exigem
validação analítica, declarações qualificadas podem muitas vezes ser
validado por avaliação ou exame cuidadoso de
experiência, e declarações existenciais às vezes podem ser
validado por um único exemplo positivo. Um resultado frequente
desta discussão é que os alunos reafirmam as afirmações da tese
para refletir com mais precisão o que as teses realmente alcançam.
Se tivermos essa discussão no início da tese
processo, os alunos pensam em planejar a pesquisa com
reivindicações demonstráveis em mente.
Concretamente, a Tabela 7 mostra as combinações que foram
representada entre os artigos aceitos no ICSE 2002,
omitindo os 7 para os quais os resumos não eram claros sobre
validação:
Tabela 7. Paradigmas de aceitações ICSE2002
#
Questão Resultado Validação
2
Método Devel Procedimento Análise
Método Devel Procedimento Experiência 3
8/11
10/10/2020 Escrevendo Bons Artigos de Pesquisa de Engenharia de Software Mary Shaw
desenvolvimento de software ou tarefa de manutenção, perceba isso em Método Devel Procedimento Exemplo 3
Método Devel Modelo qual Experiência 2
um procedimento concreto apoiado por uma ferramenta, e avaliar o
eficácia deste procedimento e ferramenta, determinando Método Devel Modelo analítico Experiência 2
como seu uso afeta alguma medida (por exemplo, taxas de erro) de Método Devel Notação ou ferramenta Experiência 1
qualidade. Outro paradigma comum é criar uma maneira melhor Método de análise Procedimento Análise 5
para avaliar uma propriedade formalizável de um sistema de software, Método de análise Procedimento Avaliação 1
desenvolver um modelo formal que suporte a inferência, e para Método de análise Procedimento Experiência 2
mostrar que o novo modelo permite análise formal ou prova Método de análise Procedimento Exemplo 6
das propriedades de interesse. Modelo analítico Experiência 1
Método de análise
Claramente, o pesquisador não tem livre escolha para Modelo analítico Exemplo 2
Método de análise
misture e combine as técnicas - validando a correção
Método de análise Ferramenta Análise 1
de um modelo formal por meio de estudo de campo é tão inapropriado
Avaliação de instância Análise específica Análise 3
como tentativa de verificação formal de um método baseado em
Avaliação de instância Análise específica Exemplo 2
boa organização das regras práticas.
Selecionando um tipo de resultado que responderá a um determinado
6. O resumo importa?
questão geralmente não parece apresentar muita dificuldade,
pelo menos para pesquisadores que pensam cuidadosamente sobre o Os resumos de artigos submetidos ao ICSE transmitem um
escolha. Adotando cegamente o paradigma de pesquisa, alguém sentido dos tipos de pesquisa submetidos à conferência.
usado no ano passado para um problema completamente diferente é um Alguns resumos eram mais fáceis de ler e (aparentemente) mais
caso diferente, é claro, e pode levar a desajustes graves. informativo do que outros. Muitos dos mais queridos resumos tinham
Escolher uma boa forma de validação é muito mais difícil, uma estrutura comum:
e isso costuma ser uma fonte de dificuldade para completar um • Duas ou três frases sobre o estado atual do
papel de sucesso. A Tabela 6 mostra alguns bens comuns arte, identificando um problema particular
partidas. Isso, infelizmente, não fornece • Uma ou duas frases sobre o que este artigo
orientação. contribui para melhorar a situação

734

Página 10

• Uma ou duas frases sobre o resultado específico do
papel e a ideia principal por trás dele
• Uma frase sobre como o resultado é demonstrado ou
defendeu
Resumos em aproximadamente este formato, muitas vezes explicados claramente SIGCHI oferece um "Guia para artigos de sucesso
o que os leitores poderiam esperar do jornal.
As taxas de aceitação foram mais altas para papéis cujo
resumos indicam que a análise ou experiência fornece
evidências que apóiam o trabalho. As decisões sobre os papéis eram
feito com base em artigos completos, é claro, não apenas
os resumos - mas é razoável supor que o
os resumos refletem o que está nos papéis.
Quer você goste ou não, as pessoas julgam os papéis por seus
resumos e ler o resumo para decidir se
para ler o jornal inteiro. É importante para o resumo
conte a história. Não presuma, porém, que simplesmente adicionar um
frase sobre análise ou experiência para o seu resumo é
suficiente; o papel deve entregar o que o resumo
promessas
7. Perguntas que você pode fazer sobre este relatório
7.1. Esta é uma receita infalível?
Não, de forma alguma. Primeiro, não é uma receita. Segundo, nem todos
engenheiros de software compartilham as mesmas visões de interessantes e
pesquisa significativa. Mesmo que o seu artigo seja claro sobre
o que você fez e o que pode concluir, membros da
um comitê de programa pode não concordar sobre como
interpretar o seu resultado. Geralmente são técnicas honestas
desentendimentos, e os membros do comitê farão o possível para
entenda o que você fez. Você pode ajudar por
explicando seu trabalho com clareza; este relatório deve ajudá-lo
escrever um bom artigo sobre sistemas [11]. USENIX agora fornece
este conselho aos seus autores. Também na veia do sistema,
Partridge oferece conselhos sobre "Como aumentar as chances
Seu trabalho é aceito na ACM SIGCOMM "[15].
Submissão "que inclui critérios de avaliação e
discussão de tipos comuns de resultados de CHI, juntamente com
como diferentes critérios de avaliação se aplicam a diferentes tipos
de resultados [13]. Um estudo [8] de fatores regionais que afetam
aceitação encontrou diferenças regionais em problemas com
novidade, significado, foco e qualidade de redação.
Em 1993, o presidente do programa da conferência SIGGRAPH
escreveu uma discussão sobre o processo de seleção, "How to Get
Seu artigo SIGGRAPH rejeitado "[10]. 2003
SIGGR.APH call for papers [21] tem uma descrição do
processo de revisão e uma seção de perguntas frequentes
com um amplo conjunto de perguntas sobre "Como obter um artigo
Aceitaram".
7.3. E o próprio relatório?
As pessoas me perguntam: "o que aconteceria se você
submetido ao ICSE? "Sem se aventurar a prever
o que qualquer comitê de programa ICSE faria, observo
que como resultado de pesquisa ou artigo técnico (uma "descoberta" em
O sentido de Brooks [3]) fica aquém de várias maneiras:
• Não há tentativa de mostrar que outra pessoa pode
aplicar o modelo. Ou seja, não há demonstração de
confiabilidade entre avaliadores, ou até mesmo
repetibilidade pelo mesmo avaliador.
• O modelo não é justificado por nenhuma análise de princípio,
embora fragmentos, como os tipos de modelos que
podem servir como resultados, são baseados em princípios. Em defesa do

https://translate.googleusercontent.com/translate_f 9/11
10/10/2020 Escrevendo Bons Artigos de Pesquisa de Engenharia de Software Mary Shaw
faça isso.
7.2 O ICSE é diferente de outras conferências?
ICSE reconhece vários tipos distintos de técnicas
papéis [6]. Para 2002, eles foram publicados separadamente em
os procedimentos
Várias outras conferências oferecem "como escrever um artigo"
adendo:
Em 1993, vários veteranos do comitê do programa OOPSLA
deu um painel sobre "Como obter um artigo aceito em
OOPSLA "[9]. Isso atualizou o conselho de 1991 para o mesmo
conferência [14]
SIGSOFT oferece dois ensaios sobre como obter artigos
aceito, embora nenhum tenha sido realmente escrito para um
público de engenharia de software. Eles são "Como Ter
Your Abstract Rejected "[26] (que se concentra em
artigos teóricos) e "Conselhos aos Autores da Extensão
Abstracts ", que foi escrito para PLDI. [16].
Um pouco mais velho, Levin e Reddell, o SOSP de 1983
(sistemas operacionais) co-presidentes do programa ofereceram conselhos sobre
735
Página 11
o que não teria sido possível sem o
cooperação e incentivo do ICSE 2002
comitê de programa. O desenvolvimento dessas ideias tem
também se beneficiou da discussão com o ICSE 2002
comitê de programa, com colegas da Carnegie Mellon,
e em sessões de discussão aberta em Conferências FSE. o
o trabalho foi apoiado pelo Presidente AJ Perlis em
Universidade Carnegie Mellon.
9. Referências
1. Victor R. Basili. O paradigma experimental em software
Engenharia. Em Engenharia de Software Experimental ~
Questões: Avaliação crítica e diretrizes futuras. Proc
of Dagstuhl-Workshop, H. Dieter Rombach, Victor R.
Basili e Richard Selby (eds), publicado como Palestra
Notes in Computer Science # 706, Springer-Verlag 1993.
2. Geoffrey Bowker e Susan Leigh Star: Classificando as Coisas
Fora: Classificação e suas consequências. MIT Press,
1999
3. Frederick P. Brooks, Jr. Entendendo a realidade por meio
Ilusão - Ciência de Serviço de Gráficos Interativos. Proc
1988 A CM SIGCHI Fatores humanos em computador
Systems Conf (CHI '88) pp. 1-11.
4. Rebecca Bumett. Comunicação Técnica. Thomson
Heinle 2001.
5. Thomas F. Gieryn. Limites culturais da ciência:
Credibilidade em jogo. Univ of Chicago Press, 1999.
6. Comitê do Programa ICSE 2002. Tipos de papéis ICSE.
http: // icse-con ferences.org/2002/in fo / paperTypes.html
7. Projeto de impacto. "Determinando o impacto do software
pesquisa de engenharia na prática. Resumo do painel,
Proc. 23ª Conferência Internacional de Software
Engenharia (ICSE 2001), 2001
8. Ellen Isaacs e John Tang. Por que não mais
Jornais americanos são aceitos no CHI?
http://aem.org/sigchi/bulletin/1996.1/isaacs.htrnl
9. Ralph E. Johnson e painel. Como fazer um trabalho ser aceito
em OOPSLA. Proc OOPSLA'93, pp. 429-436,
https://translate.googleusercontent.com/translate_f
modelo, Bowker e Start [2] mostram que úteis
classificações combinam princípio e pragmático
poder descritivo.
• Apenas uma conferência e um comitê de programa são
refletido aqui.
• O uso de resumos como representantes para artigos completos é
suspeito.
• Há pouca discussão sobre trabalhos relacionados, exceto
os ensaios sobre como escrever artigos para outros
conferências. Embora a discussão de trabalhos relacionados
aparece em dois artigos complementares [19, 20],
este relatório não está sozinho.
Por outro lado, acredito que este relatório atende
O padrão de Brooks para "regras práticas" (generalizações,
assinado pelo autor, mas talvez com suporte incompleto
pelos dados, julgados pela utilidade e atualização), e eu ofereço
nesse sentido.
8. Agradecimentos
Este trabalho dependia criticamente do acesso a todo o
conjunto de artigos submetidos para a conferência ICSE 2002,
ACM SIGCHI Fatores humanos em sistemas de computador Conf
(CHI '94), páginas 278-284.
13. William Newman et al. Guia para artigos de sucesso
Envio em CH12001. http://aem.org/sigs/sigehi/
chi200 i / eall / submissions / guide-papers.html
14. Comitê do Programa OOPSLA '91. Como conseguir seu jornal
aceito no OOPSLA. Proc OOPSLA'91, pp.359-363.
http://acm.org/sigplan/oopsla/oopsla96/how91 .html
15. Craig Partridge. Como aumentar as chances de seu trabalho
é aceito na ACM SIGCOMM.
http://www.acm.org/sigcomrn/conference-misc/author-guide.html
16. William Pugh e Comitê do Programa PDLI 1991.
Conselhos aos autores de resumos estendidos.
http: // acre. org / sigsoft / con ferenees / pughadvice .html
17. Samuel Redwine, et al. Software Relacionado a DoD
Requisitos de tecnologia, práticas e perspectivas para
o futuro. Documento IDA P-1788, junho de 1984.
18. S. Redwine & W. Riddle. Tecnologia de software
maturação. Anais da Oitava Internacional
Conference on Software Engineering, maio de 1985, pp.
189-200.
19. Mary Shaw. A chegada da idade da arquitetura de software
pesquisa. Proc. 23ª Conferência Internacional sobre Engenharia de Software
(ICSE 2001), pp. 656-664a.
20. Mary Shaw. O que faz uma boa pesquisa em software
Engenharia? Apresentado na ETAPS 02, apareceu em
Departamento de Opinion Comer, Int'l Jour on Software Tools
para Tech Transfer, vol 4, DOI 10.1007 / s10009-002-0083-
4 de junho de 2002.
21. SigGraph 2003 Call for Papers.
http://www.siggraph.org/s2003/c fp / papers / index.html
22. WF Tichy, P. Lukowicz, L. Prechelt e EA Heinz.
"Avaliação experimental em ciência da computação: A
estudo quantitativo. " Journal of Systems Software, Vol.
28, No. I, 1995, pp. 9-18.
23. Walter F. Tichy. "Os cientistas da computação deveriam experimentar
Mais? 16 razões para evitar experimentação. " 1EEE
Computer, vol. 31, No. 5, maio de 1998
24. Marvin V. Zelkowitz e Delores Wallace. Experimental
10/11
10/10/2020 Escrevendo Bons Artigos de Pesquisa de Engenharia de Software Mary Shaw
http://aem.org/sigplan/oopsla/oopsla96/how93.html validação em engenharia de software. Informação e
10. Jim Kajiya. Como obter o seu papel SIGGRAPH Software Technology, Vol 39, no 11, 1997, pp. 735-744.
Rejeitado. Espelhado em
25. Marvin V. Zelkowitz e Delores Wallace. Experimental
http: //www.ee.gateeh.edu/student.services/phd/phd-advice/kajiya
modelos de validação de tecnologia. IEEE Computer, vol.
11. Roy Levin e David D. Redell. Como (e como não) 31, No. 5, 1998, pp.23-31.
Escreva um Good Systems Paper. ACM SIGOPS Operando
26. Mary-Claire van Leunen e Richard Lipton. Como
Systems Review, vol. 17, No. 3 (julho, 1983), páginas 35-
ter seu resumo rejeitado.
40. http://fip.digital.com/pub/DEC/SRC/other/SOSPadvice.txt
http: // acm '° rg / sigs ° fdc ° n ferences / vanLeunenLipt ° n'html
12. William Newman. Uma análise preliminar dos produtos
de pesquisa de IHC, usando resumos pro forma. Proc 1994

736

https://translate.googleusercontent.com/translate_f 11/11