Unidade 3 Estratégias de Estudos Primários

Prévia do material em texto

Engenharia de 
Software Experimental
Responsável pelo Conteúdo:
Prof. Me. Artur Marques
Revisão Textual:
Mariana Góis
Estratégias de Estudos Primários
Estratégias de Estudos Primários
 
 
• Fundamentar o aluno nas estratégias primárias em Engenharia de Software Experimental.
OBJETIVO DE APRENDIZADO 
• Estudos de Caso;
• Experimento Controlado;
• Etnografia;
• Pesquisa-Ação;
• Grounded Theory;
• Estudos Baseados em Simulação;
• Métodos Qualitativos.
UNIDADE Estratégias de Estudos Primários
Contextualização
Uma estratégia de pesquisa apresenta os principais componentes de um projeto de 
pesquisa, como a área e o foco do tópico, a perspectiva, o desenho e os métodos. Isso diz 
respeito a como você se propõe a responder ao conjunto de questões de pesquisa e como 
implementará a metodologia para seu projeto em Engenharia de Software Experimental.
Então, seguindo o método científico, replicável aos experimentos em Engenharia de 
Software, você começou a identificar o seu tema de pesquisa, a desenvolver seu enun-
ciado e a pensar sobre possíveis questões. Embora você já possa ter hipóteses, questões 
ou objetivos de pesquisa claros, é possível que, neste estágio, você não tenha certeza 
sobre a estratégia mais apropriada a ser implementada para responder a essas questões.
Vamos escrever e descrever a esse respeito.
8
9
Estudos de Caso
Concentra-se em uma investigação aprofundada de um único caso (por exemplo, 
uma organização, uma função, um trecho importante de código, um módulo, uma me-
todologia ou uma abordagem de problema arquitetônico em Engenharia de Software) 
ou ainda, de um pequeno número de casos.
Na pesquisa de estudo de caso em geral, as informações são buscadas em diferentes 
fontes e por meio do uso de diferentes tipos de dados, como observações, levantamen-
tos, entrevistas e análises de documentos.
Os dados podem ser qualitativos, quantitativos ou uma combinação de ambos. A pes-
quisa de estudo de caso permite uma investigação composta e multifacetada da questão 
ou problema.
Apesar disso, antes vamos a definições curtas de pesquisa quantitativa e qualitativa 
apenas para manter nosso conhecimento adquirido preservado.
Pesquisa Quantitativa: Este é um método amplamente utilizado em pesquisa de negó-
cios e em Engenharia de Software, e permite o acesso a um número significativamente 
alto de participantes.
Conforme escritos de Marconi e Lakatos (2005, p. 284, apud ANDRADE et al., 
2017, p. 9) a pesquisa quantitativa evidencia a observação e valorização dos fenôme-
nos; estabelece ideias; demonstra o grau de fundamentação; revisa ideias resultantes da 
análise; propõe novas observações e valorização para esclarecer, modificar e/ou funda-
mentar respostas e ideias.
A disponibilidade de sites permite a distribuição ampla e barata de pesquisas e a or-
ganização das respostas. Embora o desenvolvimento de perguntas possa parecer fácil, é 
complexo desenvolver um questionário significativo que permita responder a perguntas 
de pesquisa. 
Os questionários precisam atrair os respondentes, não podem ser muito longos, muito 
intrusivos ou muito difíceis de entender. Imagine que software e Engenharia de Software
são de natureza complexa e se você quer participação de usuários, por exemplo, deve 
deixar muito explicado, com uso de linguagem acessível a essa população do estudo, 
jamais usar linguagem rebuscada, perguntas com duplo sentido e outras alegorias. Ser 
claro, simples e direto faz parte da objetividade do pesquisador. 
Eles também precisam medir com precisão o problema sob investigação. Por esses 
motivos também é aconselhável, quando possível, a utilização de questionários já dis-
poníveis no mercado e devidamente validados. Infelizmente, na área de Engenharia de 
Software Experimental, muitas vezes é difícil contar com o reaproveitamento de ques-
tionários, cada caso é um caso e apesar dos aspectos padrão de respostas que possuam 
perguntas reaproveitáveis, prepare-se para criar outras.
Ao usar questionários, decisões devem ser tomadas sobre o tamanho da amostra e se e 
quando isso representar toda a população estudada. As pesquisas podem ser administradas 
a toda uma população, por exemplo: a todos os funcionários de uma organização específica 
ou a todos os usuários de um sistema, de um serviço web, de um app, entre outros.
9
UNIDADE Estratégias de Estudos Primários
Amostra representativa: trata-se de um subconjunto de uma população onde se bus-
ca refletir com alto grau de precisão as características do grupo maior ou da população 
toda. Por exemplo, uma classe de 60 indivíduos com 30 homens e 30 mulheres pode 
gerar uma amostra representativa que pode incluir 12 indivíduos: 6 homens e 6 mulhe-
res. Olhando assim parece um número mágico, mas na prática não é assim. Para eleger 
uma amostra representativa, como o próprio nome diz, precisamos “representar” esta-
tisticamente aquela população de estudo em uma amostra proporcionalmente menor, 
de forma a atingir em teses o mesmo resultado com um esforço menor. Isso reflete ob-
viamente em custos de pesquisa, pois obter respostas de uma população inteira é muito 
mais caro do que obter uma amostra representativa válida.
A falta de representatividade geralmente vem de erros de amostragem ou vieses. Um 
exemplo de erro de amostragem seria conduzir uma pesquisa de quantas pessoas co-
mem produtos de origem animal recrutando participantes de um clube de veganos. Pa-
rece óbvio, mas muitas vezes isso pode ser provocado sob a alcunha de dizer que certo 
benefício de um produto ou uma população na verdade foi criado de forma tendenciosa 
para influenciar aquela população sob uma falsa alcunha científica. Quantas vezes você 
já viu na internet o termo “cientificamente comprovado”?
Como podemos diminuir ou praticamente eliminar isso para que a amostra seja re-
presentativa e justa?
Em primeiro lugar, considere cuidadosamente sua estrutura de amostragem, seus 
possíveis participantes e procedimentos de recrutamento. Evite recrutar apenas mem-
bros de um determinado subconjunto de sua população. Em seguida, uma boa maneira 
de reduzir o viés (tendência induzida) na amostragem é amostrar aleatoriamente de seu 
quadro. Com isso, você minimiza qualquer viés de seleção que possa ocorrer, como o 
viés do voluntário. Você também pode implementar um protocolo de estratificação, 
como amostragem estratificada proporcional. Claro, converse com colegas, mostre a 
eles como você fará isso e colete também suas opiniões.
Pesquisa qualitativa: é um tipo de pesquisa usada em ciências sociais que coleta e tra-
balha com dados não numéricos e que busca interpretar o significado desses dados que 
ajudam a compreender a vida social por meio do estudo de populações ou locais-alvo. 
A Engenharia de Software Experimental utiliza isso para entender e justificar compor-
tamentos de usuários e outras características para melhorar os softwares, por exemplo.
Os pesquisadores que utilizam os métodos qualitativos buscam explicar o 
porquê das coisas, exprimindo o que convém ser feito, mas não quantifi-
cam os valores e as trocas simbólicas nem se submetem à prova de fatos, 
pois os dados analisados são não métricos (suscitados e de interação) e se 
valem de diferentes abordagens. Na pesquisa qualitativa, o cientista é ao 
mesmo tempo o sujeito e o objeto de suas pesquisas. O desenvolvimento 
da pesquisa é imprevisível. O conhecimento do pesquisador é parcial e 
limitado. O objetivo da amostra é de produzir informações aprofundadas 
e ilustrativas: seja ela pequena ou grande, o que importa é que ela seja 
capaz de produzir novas informações. A pesquisa qualitativa preocupa-
-se, portanto, com aspectos da realidade que não podem ser quantifica-
dos, centrando-se na compreensão e explicação da dinâmica das relações 
sociais. (GERHARDT; SILVEIRA, 2009, p. 32)
10
11
Muitas vezes as pessoas a enquadram em oposição à pesquisa quantitativa, que usa 
dados numéricos para identificar tendências em grande escala e emprega operaçõesestatísticas para determinar relações causais e correlativas entre variáveis.
A pesquisa qualitativa é projetada para revelar o significado que informa a ação ou 
os resultados normalmente medidos pela pesquisa quantitativa. Assim, os pesquisado-
res qualitativos investigam significados, interpretações e símbolos, além de processos e 
relações da vida social.
Esse tipo de pesquisa produz dados descritivos, que o pesquisador deve interpretar 
usando métodos rigorosos e sistemáticos de transcrição, codificação e análise de ten-
dências e temas.
Como seu foco é a vida cotidiana e as experiências das pessoas, a pesquisa qualitati-
va se presta bem à criação de novas teorias usando o método indutivo, que podem então 
ser testadas com pesquisas futuras.
Os métodos de pesquisa qualitativa incluem:
• observação e imersão;
• entrevistas;
• inquéritos abertos;
• grupos de foco;
• análise de conteúdo de materiais visuais e textuais;
• história oral.
Experimento Controlado
Um experimento controlado é aquele em que tudo é mantido constante, exceto por uma 
variável. Normalmente, um conjunto de dados é considerado um grupo de controle, que 
normalmente é o estado normal ou usual, e um ou mais outros grupos são examinados onde 
todas as condições são idênticas ao grupo de controle e entre si, exceto para uma variável.
Às vezes é necessário alterar mais de uma variável, mas todas as outras condições 
experimentais serão controladas de forma que apenas as variáveis examinadas mudem. 
E o que se mede é a quantidade das variáveis ou a forma como elas mudam.
Em linhas gerais, o experimento controlado:
• é simplesmente um experimento no qual todos os fatores são mantidos constantes, 
exceto um: a variável independente ;
• compara um grupo de controle a um grupo experimental – todas as variáveis são 
idênticas entre os dois grupos, exceto para o fator que está sendo testado ;
• tem a facilidade de eliminar a incerteza sobre a importância dos resultados.
A grande vantagem de um experimento controlado é que você pode eliminar grande 
parte da incerteza sobre os resultados. Se você não pudesse controlar cada variável, 
poderia acabar com um resultado confuso.
11
UNIDADE Estratégias de Estudos Primários
Em Engenharia de Software Experimental, o método clássico para identificar rela-
ções de causa e efeito é conduzir experimentos controlados.
Quanto à Engenharia de Software Experimental, estudos conduzidos por Daun, 
Hübscher e Weyer (2016) levando em consideração estudos em experimentos controla-
dos para a pesquisa em Engenharia de Software incluindo testes concluíram que:
Os relatórios do experimento sob investigação geralmente discutiram 
ameaças à validade externa e interna de um software, funcionalidade, 
método, módulo ou rotina. A validade externa foi discutida em 90,74% 
dos relatórios de experimentos de software e a validade interna foi dis-
cutida em 90,12% dos relatórios de experimentos de software. As ame-
aças à validade da construção foram discutidas em 73,46% de todos os 
relatórios de experimentos e as ameaças à validade da conclusão foram 
discutidas em 64,2% de todos os relatórios de experimentos de software. 
(DAUN; HÜBSCHER; WEYER, 2016, p. 9)
Experimentos controlados oferecem vários benefícios específicos. Eles nos permitem rea-
lizar estudos bem definidos e focados, com potencial para resultados estatisticamente signifi-
cativos. Eles nos permitem focar em variáveis específicas, medidas e nas relações entre elas.
Eles nos ajudam a formular hipóteses, forçando-nos a afirmar claramente a questão 
estudada e nos permitem maximizar o número de perguntas que estão sendo feitas. Tais 
estudos geralmente resultam em variáveis dependentes e independentes bem definidas 
e hipóteses bem definidas. Resultam na identificação de variáveis-chave e bons insights 
para essas variáveis. Também nos permitem medir as relações entre as variáveis.
Um estudo controlado fornece boas percepções sobre porque relacionamentos e 
resultados ocorrem e não ocorrem. Ela nos obriga a analisar as ameaças à validade, 
levando a insights na identificação de onde são necessárias replicações ou estudos alter-
nativos e onde as variações podem mostrar efeitos diferentes.
Cada estudo realizado dará sua contribuição para gerar conhecimento, porém, tam-
bém é importante integrar resultados negativos. Resultados negativos e experiências 
repetidas são importantes e valiosos em Engenharia de Software Experimental.
Para Pfleeger (1995), há conceitos importantes que não podem passar despercebidos 
pelo engenheiro de software: os experimentos/unidades e experimentos/erro. 
Um experimento/unidade é o experimento/objeto ao qual um único tra-
tamento é aplicado. Normalmente, você aplica o tratamento mais de uma 
vez. No mínimo, você aplica-o ao grupo controle, bem como a pelo me-
nos um outro grupo que difere do controle por uma variável de estado. 
Em muitos casos, você aplica o tratamento muitas vezes a muitos grupos. 
Em cada caso, você examina os resultados para ver quais são as diferen-
ças na aplicação dos tratamentos.
No entanto, mesmo quando você mantém as condições iguais de um tes-
te para outro, os resultados podem vir a ser ligeiramente diferentes. Por 
exemplo, você pode estar investigando o tempo que leva para um pro-
gramador reconhecer falhas em um programa. Você semeou uma cole-
ção de programas semelhantes com um conjunto de defeitos conhecidos 
12
13
representando certos tipos de falhas, e pede a um programador para en-
contrar o maior número de defeitos possível. Mas o programador pode 
levar mais tempo hoje para encontrar o mesmo conjunto de falhas que ele 
ou ela tomou ontem. A que essa variação é atribuível? O erro experimental 
no estudo controlado descreve a falha de duas unidades experimentais tra-
tadas de forma idêntica para produzir resultados idênticos. 
O erro pode refletir uma série de problemas: 
• erros de experimentação ;
• erros de observação ;
• erros de medição ;
• a variação dos recursos experimentais ;
• os efeitos combinados de todos os fatores estranhos que podem in-
fluenciar as características em estudo, mas que não foram apontados 
para atenção na investigação.
Assim, em nosso exemplo de cronometragem do programador enquanto 
ele ou ela encontra falhas, as diferenças podem ser devido a coisas como:
• a mente do programador vagou durante o experimento;
• o temporizador medido decorrido inexatamente;
• o programador estava distraído por ruídos altos de outra sala;
• o programador encontrou as falhas em uma sequência diferente hoje 
do que ontem. (PFLEEGER, 1995, p. 25) 
Agora que entendemos de forma mais adequada onde e o que ocorre em experimen-
tos controlados em Engenharia de Software Experimental, vamos ver alguns exemplos 
dados por BASILI (2007) levando em consideração o que ele escreveu relativo a um 
experimento ser usado por outros e serem complementares também:
Exemplo 1:
Estudar os efeitos da leitura: Este é um exemplo de estudar a escala de 
uma técnica para problemas maiores. 
Aqui começamos com um experimento fatorial fracionado para estu-
dar os efeitos de uma técnica de leitura específica (leitura por abstração 
stepwise) versus duas técnicas específicas de teste (testes estruturais com 
cobertura de declaração de 100% e teste de valor de limite). 
Com base nos resultados positivos para a leitura, fizemos um experi-
mento controlado por grupo controle para estudar o efeito da leitura por 
abstração passo a passo em um desenvolvimento de equipe com artefatos 
maiores (estudo Cleanroom).
Com base novamente em resultados positivos, aplicamos a técnica em 
um projeto real no Centro de Voo Goddard da NASA usando um design
quase experimental (estudo de caso) para estudar a escala dos efeitos da 
leitura pela abstração stepwise.
O próximo passo foi aplicar a técnica Cleanroom a uma série de projetos. 
Em cada etapa, conseguimos escalar até estudos maiores usando diferen-
tes métodos empíricos e aprender coisas diferentes sobre os efeitos dastéc-
nicas de leitura sobre os custos de detecção e desenvolvimento de defeitos. 
13
UNIDADE Estratégias de Estudos Primários
A cada etapa ganhamos a confiança necessária na abordagem para apli-
cá-la a projetos vivos maiores e maiores, perturbando os desenvolvimen-
tos reais em Goddard. (BASILI, 2007, p. 36)
Exemplo 2: 
Construindo conhecimento sobre o domínio de desenvolvimento de com-
putação high-end: O projeto Sistemas de Computação de Alta Produtivida-
de tem o objetivo de diminuir o tempo de solução para o desenvolvimento 
e execução de sistemas de computação high-end. Para entender melhor o 
desenvolvimento de software para sistemas HPC estamos desenvolvendo 
e evoluindo modelos, hipóteses e evidências empíricas sobre os limites e 
limites de vários modelos de programação (por exemplo, MPI, MP Aber-
to, UPC, CAF), os gargalos para o desenvolvimento, o custo de melhoria 
de desempenho e as melhores formas de identificar e minimizar defeitos. 
A ideia é dar alguma confiança no que funciona melhor em que condições 
e para quem. O projeto envolve o uso de inúmeros estudos empíricos com 
novatos e profissionais todos feitos em conjunto, e não sequencialmente.
Os tipos de estudo incluem: experimentos controlados, estudos obser-
vacionais, estudos de caso e pesquisas e entrevistas. Os resultados 
são armazenados em uma base de experiência com cadeias de evidências 
ligadas a hipóteses de um lado e implicações para várias partes interessa-
das na outra ponta. Esta mistura permite o uso precoce de resultados in-
completos em vez da confiança construída sobre um conjunto sequencial 
de estudos, cada um atacando uma questão particular.
Nenhum método empírico em particular está sozinho, mas experimentos 
controlados desempenham um papel importante na construção da disci-
plina da engenharia de software (BASILI, 2007, p. 36)
Etnografia
A etnografia é um método de pesquisa qualitativa usado para estudar pessoas e cul-
turas. É amplamente adotado em disciplinas da Engenharia de Software, incluindo dife-
rentes áreas da ciência da computação. A etnografia pode fornecer uma compreensão 
profunda das realidades sociotecnológicas que cercam a prática cotidiana de desenvolvi-
mento de software, ou seja, pode ajudar a descobrir não apenas o que os profissionais 
fazem, mas também porque o fazem.
Apesar de seu potencial, a etnografia não foi amplamente adotada por pesquisadores 
empíricos da Engenharia de Software e recebe pouca atenção na literatura relacionada. 
Isso pode ser melhorado e obtido conseguindo explicar os quatro papéis que a etnografia 
pode desempenhar na promoção dos objetivos da Engenharia de Software Experimental: 
• para fortalecer as investigações sobre os aspectos sociais e humanos da Engenharia 
de Software;
14
15
• para informar o projeto de ferramental de Engenharia de Software; 
• melhorar o desenvolvimento de métodos e processos em Engenharia de Software; 
• informar e formar programas de pesquisa. 
Um dos primeiros requisitos de uma abordagem etnográfica é focar em dados qua-
litativos ou descritivos. Embora os dados quantitativos ou numéricos possam fornecer 
um bom suplemento à pesquisa etnográfica, o foco aqui está na descrição. Para tanto, 
não basta uma simples descrição, uma descrição densa, além das ações procedimentais 
ou passo a passo que estão sendo observados, fornecer também o contexto em torno 
dessas ações. 
É necessário fornecer uma descrição detalhada ao estudar os usuários de seu software, 
ou seja, o objeto do estudo é tão importante quanto em qualquer outra pesquisa etnográfi-
ca. Se você apenas relatar que viu pessoas usarem muito a impressora, por exemplo, mas 
não der informações sobre o que estava acontecendo no momento ou o que eles estavam 
fazendo com as impressões, deixa pouco para trabalhar ao criar soluções. 
Ao pesquisar seus usuários e como eles interagem com seu software, você tem a 
responsabilidade de fornecer dados bons o suficiente para interpretar suas ações de 
forma significativa.
Intimamente relacionado à necessidade de se obter uma descrição densa na pesquisa 
etnográfica está o requisito absoluto de que a pesquisa seja conduzida no contexto, ou 
no ambiente, das pessoas que estão sendo estudadas. Isso geralmente é chamado de 
trabalho de campo.
Quero deixar claro que a exigência etnográfica de visitar o ambiente para entender 
seus usuários não proíbe o uso de uma configuração de laboratório para testar seu 
software posteriormente. Significa apenas que, enquanto você está descobrindo o que 
construir ou como melhorar algo que está funcionando mal, o contexto dos usuários é 
mais importante do que a atmosfera controlada da sala de teste.
Exemplo de um caso de estudo etnográfico em software:
Em um projeto recente de pesquisa sobre como tornar o software profis-
sional de contabilidade mais eficiente, os desenvolvedores relataram que 
os usuários frequentemente reclamavam que anexar arquivos exigia mui-
tos cliques. Isso foi confuso para os desenvolvedores, porque havia apenas 
alguns cliques envolvidos no processo. Ao visitar os contadores, minha 
equipe de pesquisa viu que os arquivos que eles precisavam anexar esta-
vam enterrados em camadas e camadas de pastas, o que era resultado do 
complexo trabalho organizacional que eles tinham que fazer. Além de ser 
complexo, seu trabalho também exigia um alto nível de precisão, já que 
envolvia milhões de dólares. Com complexidade e precisão no trabalho, 
os usuários queriam abrir e revisar um arquivo antes de anexá-lo, para ter 
certeza de que era o correto. Isso significava que primeiro eles clicariam 
em pasta após pasta para abrir e visualizar o arquivo, e, em seguida, no 
software, eles pesquisariam esse mesmo caminho para anexar o mesmo 
15
UNIDADE Estratégias de Estudos Primários
arquivo. Embora não pudéssemos eliminar o problema de complexida-
de dentro de cada departamento de contabilidade, poderíamos apoiar a 
necessidade de precisão e reduzir o número de vezes que os contadores 
precisaram fazer uma busca detalhada nos arquivos, deixando-os arrastar 
e soltar em vez de navegar e selecionar. Somente visitando os usuários 
no contexto e descrevendo suas ações e motivações poderíamos ajudar 
os desenvolvedores a fornecer uma solução para um problema que eles 
não podiam entender de suas mesas, poderíamos apoiar a necessidade 
de precisão e reduzir o número de vezes que os contadores precisavam 
fazer uma busca detalhada nos arquivos, deixando-os arrastar e soltar em 
vez de navegar e selecionar. Somente visitando os usuários no contexto 
e descrevendo suas ações e motivações poderíamos ajudar os desenvol-
vedores a fornecer uma solução para um problema que eles não podiam 
entender de suas mesas. poderíamos apoiar a necessidade de precisão e 
reduzir o número de vezes que os contadores precisavam fazer uma busca 
detalhada nos arquivos, deixando-os arrastar e soltar em vez de navegar 
e selecionar. Somente visitando os usuários no contexto e descrevendo 
suas ações e motivações poderíamos ajudar os desenvolvedores a forne-
cer uma solução para um problema que eles não podiam entender de 
suas mesas. (MORAN, 2015, p. 4)
Na pesquisa de design de software, incluindo tipos de usuários em várias funções, 
bem como especialistas no assunto, dentro ou fora da empresa de software e partes in-
teressadas internas, essa é a maneira recomendada de garantir que todas as perspectivas 
sejam consideradas. 
Ouvir os usuários não significa apenas dar o que eles pedem, significa fazer um 
esforço para entender seus desejos e necessidades e encontrar maneiras de atender de 
forma adequada.
Pesquisa-Ação
É um processo disciplinado de investigação conduzido por e para aqueles que estão 
realizando a ação. A principal razão para se engajar na pesquisa-ação é ajudar o indiví-
duo a melhorar e/ou refinar suas ações.
A pesquisa-ação cria conhecimento com base em pesquisas conduzidas em contextos 
específicos e frequentemente práticos. O propósito da pesquisa-ação é aprenderpor 
meio da ação que leva ao desenvolvimento pessoal ou profissional.
O processo permite vivenciar a solução de problemas e a modelar para os envolvidos. 
Isso ocorre mediante coleta rigorosa de dados para diagnosticar problemas, buscar so-
luções, agir sobre possibilidades promissoras e monitorar se e como a ação funcionou. 
A sua relevância está no fato de que o foco de cada projeto de pesquisa é determinado 
pelos pesquisadores, que também são os principais consumidores dos resultados.
16
17
Qualquer que seja o cenário, a pesquisa-ação sempre envolve o mesmo processo de 
sete etapas. Essas sete etapas, que se tornam um ciclo sem fim para o pesquisador, são 
as seguintes:
• selecionar um foco;
• esclarecer teorias;
• identificar questões de pesquisa;
• coletar os dados;
• analisar os dados;
• publicar os resultados de relatórios;
• tomar ações planejadas.
Embora a análise de dados frequentemente traga à mente o uso de cálculos estatís-
ticos complexos, raramente é a saída para o pesquisador-ação. Vários procedimentos 
relativamente fáceis de usar podem ajudar um profissional a identificar as tendências e 
padrões nos dados da pesquisa-ação. Durante esta parte do processo os pesquisadores 
irão classificar, filtrar, classificar e examinar metodicamente seus dados para responder 
a duas perguntas genéricas:
• Qual é a história contada por esses dados?
• Por que a história se desenrolou dessa maneira?
Ao responder a essas duas questões, o pesquisador pode adquirir uma melhor com-
preensão do fenômeno sob investigação e, como resultado, acabar produzindo uma 
teoria fundamentada sobre o que pode ser feito para melhorar a situação.
A pesquisa orientada para a ação não é exatamente pesquisa para a ação, embora 
ambas sejam baseadas nas mesmas suposições, por exemplo, para produzir mudanças. 
A pesquisa-ação é uma abordagem altamente complexa de pesquisa, reflexão e mudan-
ça, nem sempre alcançável na prática.
Grounded Theory
A Engenharia de Software (ES) é composta de fenômenos constituídos sociocultural-
mente e não tecnicamente.
A Grounded Theory ou Teoria Fundamentada nos Dados se refere a um conjunto de 
métodos indutivos sistemáticos para conduzir pesquisas qualitativas voltadas para o de-
senvolvimento de teorias. Cada vez mais os pesquisadores usam o termo para designar 
os métodos de investigação para coletar e, em particular, analisar dados.
A teoria fundamentada nos dados é uma metodologia bem conhecida, empregada em 
muitos estudos de pesquisa. Técnicas qualitativas e quantitativas de geração de dados 
podem ser usadas em um estudo de teoria fundamentada.
17
UNIDADE Estratégias de Estudos Primários
A teoria fundamentada tem como objetivo descobrir ou construir teorias a partir de 
dados sistematicamente obtidos e analisados por meio de análise comparativa.
Memorandos
Teoria Fundamentada
de Charmaz
tem como suporte pode serfases
feita por
realizadas por
etapas
pode ser
Entrevistas
Documentos
Codi�caçõesProdução de dados
Coleta de dados
Amostragem
Inicial
e/ou
Teórica
Inicial
Focalizada
Axial
Teórica
Figura 1 – Etapas da Teoria Fundamentada
Fonte: PRIGOL; BEHRENS, 2019, p. 3
Essa metodologia capta a diversidade de fatos, dados, informações, experiências 
da realidade, além da multidimensionalidade e a multicausalidade dos fenômenos. 
Além disso, preenche possíveis lacunas que podem surgir entre a teoria e a pesquisa 
empírica, pois propõe um conjunto de princípios e práticas/diretrizes básicas, como a 
codificação, a redação de memorandos e a amostragem, orientando o pesquisador nas 
etapas do processo de pesquisa, bem como o caminho a ser percorrido para a desco-
berta da teoria. Tem natureza exploratória, faz com que o pesquisador se familiarize 
com o problema, uma vez que trabalha diretamente com o fenômeno a ser estudado, 
com vistas a torná-lo mais explícito, aprimorar ideias e obter informações para uma 
investigação mais completa. Para isso, é necessário que o pesquisador seja receptivo 
às informações e aos dados, além de ter uma postura flexível.
Vimos que a teoria fundamentada nos dados utiliza um conjunto de procedimentos 
sistemáticos de coleta e análise dos dados para gerar, elaborar e validar teorias subs-
tantivas sobre fenômenos essencialmente sociais. De tal forma que em Engenharia de 
Software, particularmente em pesquisas que envolvam comportamentos humanos em 
projetos que usam métodos ágeis ou são desenvolvidos de maneira distribuída.
O processo de codificação segundo escritos de Halaweh (2012) advém de 3 etapas:
A codificação aberta: é “o processo de decompor, examinar, compa-
rar, conceituar e categorizar dados” (Strauss e Corbin, 1990, p. 61). Os 
conceitos e suas propriedades e dimensões são identificados a partir dos 
dados transcritos pelos pesquisadores. Isso pode ser alcançado linha por 
linha ou focalizando as ideias principais em frases ou parágrafos. Cada 
código representa uma palavra ou frase contendo uma ideia significativa, 
e um grupo de códigos (dois ou mais) forma um conceito. Um conceito é 
uma representação abstrata de um evento, objeto ou ação. Na codificação 
aberta, eventos, objetos e ações são comparados com outros em termos 
de semelhanças e diferenças para dar-lhes, quando semelhantes, o mesmo 
18
19
nome. O nome ou rótulo atribuído a uma categoria deve ser selecionado 
logicamente e geralmente representa os dados e está relacionado a eles.
A codificação axial: é o processo de remontagem de dados divididos 
por meio da codificação aberta. Essencialmente, é o processo de rela-
cionar categorias a subcategorias. As categorias são de nível mais alto e 
mais abstratas do que os conceitos, e são geradas por uma comparação 
constante das semelhanças e diferenças entre esses conceitos. Isso é feito 
usando o que é chamado de “modelo paradigmático”, que permite ao 
pesquisador pensar sistematicamente sobre os dados e relacioná-los entre 
si. Este modelo aborda as relações entre as categorias considerando os 
seguintes aspectos: condições causais, fenômeno, contexto, condições 
intervenientes, ação/interação e consequências.
A codificação seletiva: é o processo de integração e refinamento da 
teoria. O primeiro passo na integração é identificar a categoria central 
ou central que representa o tema principal da pesquisa/fenômeno. Deve 
aparecer repetidamente nos dados. A categoria central atua como um 
mestre que reúne as outras categorias para formar uma “imagem com-
pleta” explicativa usando o modelo paradigmático. Nesta etapa, as cate-
gorias são refinadas em um alto nível de abstração. A integração não é 
diferente da codificação axial, exceto que é feita em um nível de análise 
mais alto e abstrato, e as subcategorias estão vinculadas à categoria cen-
tral. (HALAWEH, 2012, p. 3) 
A teoria fundamentada é uma ótima metodologia para entender o “como” e o “por-
quê” de um problema de pesquisa. Tornar o processo de codificação explícito e analisar 
os dados linha por linha permite novos insights e também garante que nenhum tema 
importante seja esquecido. Embora a codificação e o relato dos resultados possam ser 
entediantes, a teoria fundamentada deve estar na caixa de ferramentas de todo pesqui-
sador em engenharia de software que tenta compreender os processos de desenvolvi-
mento de software entre outros.
Estudos Baseados em Simulação
Há várias décadas, inspirada em outras áreas do conhecimento, a simulação foi intro-
duzida como método de pesquisa na Engenharia de Software. Motivada por benefícios 
potenciais alcançados em outras áreas, a comunidade de Engenharia de Software tem 
usado estudos baseados em simulação para planejar, controlar e melhorar o desenvolvi-
mento de software.
A modelagem de simulação resolve problemas do mundo real com segurança e efici-
ência. Ele fornece um importante método de análise que é facilmente verificado, comu-
nicado e compreendido. Em todos os setores e disciplinas, a modelagem de simulação 
fornece soluções valiosas, fornecendo percepções claras sobre sistemascomplexos.
Para França e Travassos (2015), apesar da possível falta de validade quando compa-
rada com outras áreas da ciência, os estudos baseados em simulação em Engenharia de 
Software têm apoiado a obtenção de alguns resultados na área. Porém, como acontece 
19
UNIDADE Estratégias de Estudos Primários
com qualquer outro tipo de estudo experimental, é importante identificar e lidar com ame-
aças à validade com o objetivo de aumentar sua força e reforçar a confiança nos resultados.
Para entender um pouco mais sobre essa técnica, leia atentamente esse material de-
senvolvido por Pereira (2011), que além de explicar sobre a técnica de simulação em En-
genharia de Software Experimental, especifica uma série de experimentos. Dessa forma 
conseguimos materializar as aplicações no âmbito da Engenharia de Software para esse 
subcapítulo do material de nossa disciplina. Desejo a você uma excelente leitura.
PEREIRA, M. W. Abordagem para especificação de experimentos in silico em enge-
nharia de software e áreas afim. Dissertação (mestrado) – UFRJ/COPPE/Programa de 
Engenharia de Sistemas e Computação. Rio de Janeiro: RJ, UFRJ/COPPE, 2011. XIV, 236 p. 
Orientador: Guilherme Horta Travassos.
Disponível em: https://bit.ly/3yCXcxi
Quase sempre é muito caro e demorado determinar que um modelo é absolutamen-
te válido sobre o domínio completo de sua aplicabilidade pretendida. Em vez disso, os 
testes e avaliações são realizados até que haja confiança de que um modelo possa ser 
considerado válido para a aplicação pretendida. Se um teste determinar que um modelo 
não tem precisão suficiente para qualquer um dos conjuntos de ex-condições experimen-
tais, então o modelo é inválido. 
Existem quatro abordagens básicas de tomada de decisão para decidir se um modelo 
de simulação é válido.
Uma abordagem é a um para um, para a própria equipe de desenvolvimento do 
modelo tomar a decisão se um modelo de simulação é válido. Uma decisão subjetiva é 
feita com base nos resultados dos vários testes e avaliações realizadas como parte do 
processo de desenvolvimento do modelo. Geralmente é melhor, no entanto, usar uma 
das duas abordagens seguintes para determinar a validade do modelo.
Se a equipe de simulação desenvolvendo o modelo for pequena, uma abordagem 
melhor do que a anterior é ter os usuários do modelo fortemente envolvidos com a 
equipe de desenvolvimento do modelo na decisão da validade do modelo de simulação. 
Nesta abordagem, o foco de determinar a validade da simulação do modelo passa dos 
desenvolvedores para os usuários. Além disso, essa abordagem ajuda na credibilidade 
do experimento.
Outra abordagem, geralmente chamada de verificação e validação independente, é 
usada para decidir se o modelo de simulação é válido. Ela é independente de ambos: 
da equipe de desenvolvimento da simulação e do patrocinador do modelo. É útil na 
credibilidade do modelo, especialmente quando o problema do modelo de simulação é 
associado a um alto custo.
São técnicas de validação:
• Animação: o comportamento operacional do modelo é exibido graficamente con-
forme o modelo se move no tempo, por exemplo, os movimentos das peças através 
de um fato durante uma simulação são mostrados graficamente. Obviamente, quan-
20
21
do o tipo de função ou software permitir esse tipo de abordagem como em jogos 
ou sistema de roteirização logístico, por exemplo ; 
• Comparação com outros modelos: vários resultados, como saídas do modelo 
de simulação que estão sendo validados, são comparados aos resultados de outros 
modelos que já são considerados válidos. Por exemplo, um caso simples de modelo 
de simulação, como ele é em comparação aos resultados conhecidos de modelos 
analíticos, ou em outro caso, o modelo de simulação é comparado a outras simula-
ções de modelos de instalação que foram validados em outros tempos ;
• Degeneração de testes: a degenerescência do comportamento do modelo é tes-
tada pela seleção apropriada de valores dos parâmetros de entrada e parâmetros 
internos. Por exemplo, o número médio na fila de um único servidor de dados 
continua a aumentar ao longo do tempo quando a taxa de chegada é maior do que 
a taxa de serviço?
• Validade do evento: os “eventos” de ocorrências do modelo de simulação são 
comparados aos do sistema real para determinar se são semelhantes ; 
• Testes: a estrutura do modelo e os resultados devem ser plausíveis para qualquer ex-
tremo e combinação improvável de níveis de fatores no sistema. Por exemplo, se os 
estoques em processo forem zero, a saída da produção normalmente deve ser zero ;
• Pessoal para validade: indivíduos com conhecimento sobre o sistema são questio-
nados se o modelo e/ou seu comportamento são razoáveis. Por exemplo, a lógica 
do modelo conceitual está correta ;
• Métodos históricos: os três métodos históricos de validação são racionalismo, empi-
rismo e pós-economia ativa. O racionalismo requer que os pressupostos subjacentes a 
um modelo sejam claramente declarados e prontamente aceitos. As deduções lógicas 
são usadas a partir dessas suposições para desenvolver o modelo válido. O empiris-
mo requer que todas as suposições e resultados sejam validados empiricamente ; 
• Validade interna: várias replicações de um modelo estocástico são feitas para 
determinar a variabilidade estocástica no modelo. Uma grande quantidade de varia-
bilidade ou seja, falta de consistência, pode fazer com que os resultados do modelo 
sejam questionáveis. Isso é típico da entidade problemática, pode questionar a ade-
quação da política ou o sistema que está sendo investigado ;
• Validação em vários estágios: combinar os três métodos históricos de racionalis-
mo, empirismo e economia positiva em um processo de validação de vários está-
gios. Este método de validação consiste em desenvolver as suposições do modelo 
sobre a teoria, observações e conhecimento; validar os pressupostos do modelo, 
sempre que possível, testando-os empiricamente, e, por fim, comparar, ou seja, 
testar as relações de entrada-saída do modelo com o sistema real ;
• Gráficos operacionais: valores de várias medidas de desempenho, por exemplo, 
o número na fila e a porcentagem de servidores ocupados são mostrados grafica-
mente à medida que o modelo é executado no tempo; ou seja, o comportamento 
dinâmico de indicadores de desempenho são exibidos visualmente à medida que 
o modelo de simulação é executado ao longo do tempo para garantir que eles se 
comportam corretamente ;
21
UNIDADE Estratégias de Estudos Primários
• Variabilidade do parâmetro/Análise de sensibilidade: esta técnica consiste em al-
terar os valores e parâmetros internos de um modelo para determinar o efeito sobre o 
comportamento ou saída do modelo. As mesmas relações devem ocorrer no modelo 
e no sistema real. Esta técnica pode ser usada qualitativamente nas direções apenas 
das saídas, e quantitativamente em ambas as direções e em magnitudes das saídas; 
• Validação preditiva: o modelo é usado para prever o comportamento do sistema 
e, em seguida, as análises são feitas entre o comportamento do sistema e a previsão 
do modelo para determinar se eles são os mesmos. Os dados do sistema podem vir 
de um sistema operacional ou ser obtidos por meio de experimentos no sistema, 
por exemplo, testes de campo;
• Rastreios: os comportamentos de diferentes tipos de entidades específicas no mo-
delo são rastreados através do modelo para determinar se a lógica do modelo está 
correta e se a precisão necessária é obtida;
• Testes de Turing: Indivíduos que têm conhecimento sobre as operações do siste-
ma que está sendo modelado são questionados se eles podem discriminar entre as 
saídas do sistema e do modelo.
Métodos Qualitativos
Grosso modo, a pesquisa qualitativa é definida como um método de pesquisa que 
se concentra na obtenção de dados por meio de comunicação aberta e conversacional.
Este método não trata apenas de saber o que as pessoas pensam, mas também o 
seu por quê.
Por exemplo, considere um software de comércio eletrônico,procurando melhorar a 
sua experiencia do usuário, ou UX. Uma observação sistemática conclui que o número 
de homens que visitam o site é maior. Um bom método para determinar por que as 
mulheres não estão visitando o site de e-commerce, que possui itens para ambos os 
gêneros, é conduzir uma entrevista detalhada com clientes e clientes em potencial na 
categoria. Então, ao entrevistar clientes do sexo feminino, mandar webforms por e-mail 
e selecioná-los por meio de amostragem aleatória representativa, soube-se que a loja 
virtual não tinha itens suficientes para mulheres apesar de ser unissex e, portanto, havia 
menos mulheres visitando o e-commerce, o que foi entendido apenas interagindo pesso-
almente com a amostra e entendendo porque não iam ao site, pois havia mais produtos 
masculinos do que femininos em última instância.
A pesquisa qualitativa é baseada nas disciplinas das ciências sociais, como psicolo-
gia, sociologia e antropologia. Portanto, os métodos de pesquisa qualitativa permitem 
aprofundar as investigações e questionamentos dos entrevistados com base em suas 
respostas, nas quais o pesquisador também tenta compreender suas motivações e sen-
timentos. Entender como seu público toma decisões pode ajudar a tirar conclusões em 
pesquisas de mercado.
22
23
Estudo 
de
caso
Entrevista
um a um
Grupo
focal
Manutenção
de registros
Observações
de processos
Pesquisa
etnográ�ca
Métodos
de Pesquisa
Qualitativa
 Figura 2 – Métodos de pesquisa qualitativa usados em engenharia de software experimental
A pesquisa qualitativa trabalha com o universo de significados, moti-
vos, aspirações, crenças, valores e atitudes, o que corresponde a um 
espaço mais profundo das relações, dos processos e dos fenômenos 
que não podem ser reduzidos à operacionalização de variáveis. As ca-
racterísticas da pesquisa qualitativa são: objetivação do fenômeno; hie-
rarquização das ações de descrever, compreender, explicar, precisão 
das relações entre o global e o local em determinado fenômeno; obser-
vância das diferenças entre o mundo social e o mundo natural; respeito 
ao caráter interativo entre os objetivos buscados pelos investigadores, 
suas orientações teóricas e seus dados empíricos; busca de resultados 
os mais fidedignos possíveis; oposição ao pressuposto que defende um 
modelo único de pesquisa para todas as ciências. Entretanto, o pesqui-
sador deve estar atento para alguns limites e riscos da pesquisa qualita-
tiva, tais como: excessiva confiança no investigador como instrumento 
de coleta de dados; risco de que a reflexão exaustiva acerca das notas 
de campo possa representar uma tentativa de dar conta da totalidade 
do objeto estudado, além de controlar a influência do observador sobre 
o objeto de estudo; falta de detalhes sobre os processos através dos 
quais as conclusões foram alcançadas; falta de observância de aspectos 
diferentes sob enfoques diferentes; certeza do próprio pesquisador com 
relação a seus dados; sensação de dominar profundamente seu objeto 
de estudo; envolvimento do pesquisador na situação pesquisada, ou 
com os sujeitos pesquisados. (GERHARDT; SILVEIRA, 2009, p. 32) 
23
UNIDADE Estratégias de Estudos Primários
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Vídeos
Estatística – Aula 1 – Fases do Método Estatístico
Vamos conhecer as fases do método estatístico assistindo a esse vídeo introdutório. 
https://youtu.be/MbrKzniazv4
Empirical Methods in Software Engineering
É muito dificil encontrar aulas em Engenharia de Software Experimental em nosso país. 
Por isso, para dar uma referência de qualidade, sugiro os exemplos dos métodos empíricos 
em Engenharia de Software pelo Prof. Alessio Ferrari, ISTI-CNR, Pisa, Itália. Inclui os 
conceitos básicos de variável dependente, independente e controlada, tratamento, hipótese 
e exemplos de experimentos de Engenharia de Software. Use a transcrição do YouTube, 
fica fácil de entender por que ele transcreve o inglês para português e caso você não saiba 
inglês não perderá nada. 
https://youtu.be/vmNXZEDgwv4
 Leitura
Usando a Teoria Fundamentada como Método de Análise de Requisitos do Sistema
Vamos entender a aplicação da Teoria Fundamentada aplicada em requisitos de software. 
https://bit.ly/3BrM6N9
Estudos Baseados em Simulação em Engenharia de Software: Uma Questão de Validade
O Método de Comparação Constante é representado por muitos procedimentos intercalan-
do tanto a coleta de dados quanto a análise para gerar uma teoria emergente de tais dados 
coletados e analisados, ela ajuda na validade dos estudos de simulação. 
https://bit.ly/3zzcpR1
24
25
Referências
ANDRADE, S. M.; STEFANO, S. R.; ZAMPIER, M. Metodologia de Pesquisa. 2017. 
Disponível em: <http://www2.unicentro.br/lmqqa/files/2017/03/ANDRADE2c-
STEFANO-ZAMPIER-Metodologia-de-Pesquisa-1-1.pdf>. Acesso em: 20/02/2021.
BASILI, V. R. Empirical Software Engineering issues. Springer-Verlag Berlin 
Heidelberg, 2007. Disponível em: <https://www.cs.umd.edu/users/basili/publications/
chapters/C26.pdf>. Acesso em: 22/02/2021.
DAUN, M.; HUBSCHER, C.; WEYER, T. Controlled experiments with 
student participants in Software Engineering preliminary results from a 
systematic mapping study. 2017. Disponível em: <https://arxiv.org/ftp/arxiv/
papers/1708/1708.04662.pdf>. Acesso em: 22/02/2021.
FRANCA, B. B. N.; TRAVASSOS, G. H. Estudos baseados em simulação em Engenharia 
de Software: uma questão de validade. CLEIej, Montevidéu, v. 18, n. 1, p. 5, abr. 2015. 
Disponível em: <http://www.scielo.edu.uy/scielo.php?script=sci_arttext&pid=S0717-
50002015000100005&lng=es&nrm=iso>. Acesso em: 03/03/2021.
GERHARDT, T. E.; SILVEIRA, D. T. Métodos de Pesquisa. Universidade Federal do 
Rio Grande do Sul – UFRGS. Porto Alegre: RS, Editora da UFRGS, 2009. Disponível 
em: <http://www.ufrgs.br/cursopgdr/downloadsSerie/derad005.pdf>. Acesso em: 
 20/02/2021.
HALAWEH, M. Usando a teoria fundamentada como método de análise de requisitos 
do sistema. JISTEM J. Inf. Syst. Technol. Manag., São Paulo, v. 9, n. 1, p. 23-38, abr. 
2012. Disponível em: <http://www.scielo.br/scielo.php?script=sci_arttext&pid=S1807-
17752012000100003&lng=en&nrm=iso>. Acesso em: 02/03/2021.
MORAN, K. An Ethnographic Approach to Software. 2015. Disponível em: 
<http://www.methodsandtools.com/archive/softwareethnography.php>. Acesso em: 
 22/02/2021.
PFLEEGER, S. L. Experimental design and analysis in Software Engineering:
Part 2 – How to set up an experiment. Software Engineering Notes v. 20, n. 1, 
jan. 1995. p. 22-26. Disponível em: <http://robertfeldt.net/advice/pfleeger_1995_
experimental_design_and_analysis_in_se_part2.pdf>. Acesso em: 22/02/2021.
 PRIGOL, E. L.; BEHRENS, M. A. Teoria fundamentada: metodologia aplicada 
na pesquisa em educação. Educ. Real., Porto Alegre, v. 44, n. 3, e84611, 2019. 
Disponível em <http://www.scielo.br/scielo.php?script=sci_arttext&pid=S2175-623620-
19000300607&lng=en&nrm=iso>. Acesso em: 02/03/2021.
25