Engenharia de Software Experimental_

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
Conceituação de Engenharia de Software Experimental
Conceituação de Engenharia 
de Software Experimental
 
 
• Conhecer os fundamentos da Engenharia de Software Experimental delimitada como área 
de estudo e evolução da qualidade.
OBJETIVO DE APRENDIZADO 
• Software, sua Natureza e Características;
• Conceituação de Engenharia de Software;
• Objetivos da Experimentação;
• Organização do Experimento;
• Experimentação e Engenharia de Software Experimental;
• Introdução à Engenharia de Software Experimental.
UNIDADE Conceituação de Engenharia de Software Experimental
Software, sua Natureza e Características
Conceitualmente, as disciplinas de engenharia surgem do artesanato à medida que 
suas bases de conhecimento evoluem para as ciências.
Se um artesanato está fabricando um produto utilitário, há uma demanda por maior 
funcionalidade do produto, maior qualidade do produto e maiores quantidades do produto. 
Atender a essas demandas resulta em mais complexidade no produto ou no processo de 
produção, ou ambos. Para lidar com o aumento das demandas e maior complexidade, um 
ofício deve mudar de três maneiras importantes.
• Em primeiro lugar, nos primeiros estágios de desenvolvimento de um ofício, entender 
como as coisas se comportam é de primordial importância; entender o porquê é de 
importância secundária. Com produtos e processos de produção mais complexos, 
apenas saber como as coisas se comportam não é suficiente. Há também uma neces­
sidade crescente de compreender as relações causais – as respostas às perguntas do 
tipo “por quê”. As respostas a essas perguntas costumam ter um poder preditivo 
essencial para o desenvolvimento de novas técnicas e metodologias de design e 
produção. Quando o conhecimento sobre o comportamento do produto e de seus 
constituintes é bem desenvolvido, torna­se uma ciência;
• Em segundo lugar, a fabricação de produtos com maior funcionalidade ou qualidade 
requer uma maior compreensão dos valores. Isso leva a uma teoria de valor que 
trata dos fatores envolvidos na qualidade de um produto, meios para quantificar os 
fatores, conceitos que identificam características controláveis de um produto que 
afetam sua qualidade e princípios que focam a atenção em importantes questões 
de design de produto relacionadas ao valor. A ética do trabalho lida com questões 
causais mais profundas: causas que afetam o valor. Quando a ética do trabalho do 
ofício é bem desenvolvida, ela também se torna uma ciência;
• Terceiro, a fabricação de produtos complexos, em grandes quantidades e mais fun­
cionais requer um planejamento significativo. Quando o produto é complexo ou 
tem maior funcionalidade, o planejamento se concentra no projeto do produto. 
Quando grandes quantidades de um produto são fabricadas, o planejamento se 
concentra no projeto de um processo de produção. Em alguns casos, um esforço 
significativo é necessário para projetar o produto e seu processo de produção. 
A magnitude desse esforço pode exigir que as pessoas envolvidas desenvolvam 
habilidades especializadas. Alguns continuam com a produção real, outros estão 
envolvidos na concepção de produtos e processos de produção. Aqueles envolvidos 
no projeto tornam­se parte de uma nova disciplina – uma disciplina de engenharia.
Parte da natureza da Engenharia de Software está implícita em sua classificação como 
disciplina de engenharia. Esta seção discute algumas de suas características e problemas 
exclusivos. A exclusividade aqui não significa que as características e problemas não pos­
sam ser encontrados em outras disciplinas de engenharia. Significa apenas que eles não 
são comuns a todas as disciplinas de engenharia ou são significativamente mais impor­
tantes na Engenharia de Software. A Engenharia de Software é caracterizada por seu 
produto principal, que é o software – programa que direciona um computador para exe­
cutar alguma tarefa. Na Engenharia de Software existe uma ciência bem desenvolvida, a 
8
9
ciência da computação, que cobre, entre outras coisas, conceitos de linguagens de progra­
mação, algoritmos, estruturas de dados e aspectos importantes de sistemas de hardware
e software de sistemas. Muitas das áreas de conhecimento da ciência da computação 
tratam de produtos de software. Por causa disso, a fronteira entre ciência da computação 
e engenharia de software é difícil de definir. Em particular, os valores da engenharia de 
software constituem um elemento importante da ciência da computação.
Uma vez que grande parte do esforço de desenvolvimento bem­sucedido está envol­
vido na manutenção, os interesses dos desenvolvedores pesam muito nos valores do 
software. Alguns dos efeitos estão listados a seguir.
É mais importante documentar o design do software além de seu uso. Com um 
projeto mal documentado, os mantenedores de software gastarão muito mais tempo 
estudando o software existente antes de fazer alterações. Trabalhar com aspectos de 
design não documentados também pode causar novos erros.
É mais importante despender esforço extra no desenvolvimento de software e pro­
cedimentos de teste e salvá­los para reutilização após a manutenção. Os engenheiros de 
software recentemente se concentraram em uma importante técnica chamada refatoração.
Refatoração refere­se a alterações no software que não alteram sua funcionalidade. As 
alterações são feitas com o objetivo de simplificar a manutenção futura. Após uma manu­
tenção de refatoração, o software de teste original pode ser reutilizado sem modificação.
É mais importante estruturar o design para que alterações futuras possam ser feitas 
com mais facilidade. A complexidade e a natureza das interações entre os componentes 
é a consideração mais importante aqui. Os conceitos de acoplamento e coesão desti­
nam­se a lidar com esse problema.
Como sabemos, software é qualquer programa de computador, mas também pode ser 
um ecossistema de softwares, que também pode ser definido como um conjunto de ins­
truções que são responsáveis por orientar o computador na realização de determinadas 
tarefas. A seguir estão as características do software:
• Durabilidade;
• Hibridez;
• Usabilidade;
• Reutilização de componentes;
• Flexibilidade;
• Manutenção;
• Portabilidade;
• Confiabilidade.
As metodologias de solução de problemas científicos e de Engenharia de Software
estão intimamente relacionadas, afinal, por que o processo deveria ser diferente?
Existe um processo científico bem definido para a resolução de problemas:
• Elaborar hipóteses;
9
UNIDADE Conceituação de Engenharia de Software Experimental
• Coletar evidências;
• Tirar conclusões.
Sim, pode haver mais etapas e escolas metodológicas diferentes, mas ao final, mini­
mamente tudo gira ao redor dessas três macroetapas. Se aplicarmos esse processo ao 
desenvolvimento de software, ele pode ser uma ferramenta muito poderosa em design 
e arquitetura.
Partindo dessas definições, você há de concordar que a Engenharia de Software 
precisa de mais experimentação, por exemplo:
• Para confirmar teorias e também a “sabedoria convencional”: limitar a medida 
ciclomática garante qualidade?
• Para explorar relacionamentos: como a complexidade do design afeta a produti­
vidade dos designers?
• Para avaliar a precisão dos modelos: A análise por pontos de função prevê o 
tamanho do código?
• Para validar medidas: O número de métodos é uma medida válida de complexi­
dade de classe?
Conceituação de Engenharia de Software
Engenharia de Software é um estudo detalhado da engenharia para o projeto, desen­
volvimento e manutenção de software. Foi introduzida para resolver os problemas de 
projetos de software de baixa qualidade que em meados da década de 1970 do século XX 
acabaram por gerar o que ficou conhecido como Crise do Software. Os problemas surgem 
quando um software geralmente excede prazos, orçamentos e níveis reduzidos de quali­
dade. Elagarante que o aplicativo seja construído de forma consistente, correta, dentro do 
prazo e do orçamento e dentro dos requisitos.
Um software deve estar em conformidade com especificações de qualidade, trata­se 
de uma meta essencial e básica da Engenharia de Software que mostra o caminho para 
obter a melhor qualidade de produtos e processos para atender ao cliente. Portanto, a 
Engenharia de Software objetiva diversas soluções que devem evidenciar a qualidade do 
produto final, que deverá atender ao cliente que o solicitou.
A demanda da Engenharia de Software também surgiu para atender à imensa 
taxa de mudança nos requisitos do usuário e no ambiente no qual o aplicativo deveria 
estar funcionando.
Você já deve ter percebido que no terço final do século XX já se pensava em bus­
car agilidade.
Um produto de software é avaliado pela facilidade com que pode ser usado pelo usu­
ário final e pelos recursos que oferece. Um aplicativo deve pontuar nas seguintes áreas:
• Operacional: isso diz o quão bom um software funciona em operações como orça­
mento, usabilidade, eficiência, correção, funcionalidade, confiabilidade, segurança 
e proteção;
10
11
• Transicional: a transição é importante quando um aplicativo é transferido de uma pla­
taforma a outra. Portanto, portabilidade, reutilização e adaptabilidade vêm dessa área;
• Manutenção: especifica o quão bom um software funciona num ambiente em mu­
dança. Modularidade, facilidade de manutenção, flexibilidade e escalabilidade vêm da 
parte de manutenção.
Ciclo de vida de desenvolvimento de software ou SDLC é uma série de estágios na 
engenharia de software para desenvolver o aplicativo de software proposto, como:
• Comunicação;
• Coleta de requisitos;
• Estudo de viabilidade;
• Análise de sistema;
• Design;
• Codificação;
• Teste;
• Integração;
• Implementação;
• Operações e manutenção;
• Disposição.
Todas essas etapas são importantes e ocorrem realmente em todos os ciclos de vida 
de software de formas diferentes em momentos distintos, em iterações ou linearmente, 
dependem do paradigma utilizado, como por exemplo: cascata, espiral, integrado, ágil 
ou enxuto. Todavia, podemos abstrair e ficar com as seguintes 5 etapas padrão:
• análise e definição de requisitos;
• planejamento do projeto de desenvolvimento;
• implementação das funcionalidades durante a codificação;
• execução dos testes de segurança, validação do usuário e rastreamento de bugs;
• integração da aplicação no ambiente de produção.
A Engenharia de Software geralmente começa com a primeira etapa como uma ini­
ciação de solicitação do usuário para uma tarefa ou saída específica. Ele submete seu 
requerimento a uma organização prestadora de serviços. A equipe de desenvolvimento 
de software separa os requisitos do usuário, os requisitos do sistema e os requisitos fun­
cionais. O requisito é coletado por meio de entrevistas com um usuário, referência a um 
banco de dados, estudo do sistema existente etc. Após a coleta de requisitos, a equipe ana­
lisa se o software pode ser feito para atender a todos os requisitos do usuário. O desen­
volvedor então decide um roteiro de seu plano. A análise do sistema também inclui uma 
compreensão das limitações do produto de software. De acordo com o requisito e análise, 
um design de software é feito. A implementação do design de software começa em ter­
mos de escrever o código do programa em uma linguagem de programação adequada.
11
UNIDADE Conceituação de Engenharia de Software Experimental
Objetivos da Experimentação 
Como outras ciências e disciplinas de engenharia, a Engenharia de Software requer 
um ciclo de construção de modelos, experimentação e aprendizado. Os experimentos 
são ferramentas valiosas para todos os engenheiros de software envolvidos na avaliação e 
escolha entre diferentes métodos, técnicas, linguagens e ferramentas. O objetivo da expe­
rimentação em Engenharia de Software é apresentar os estudos empíricos em Engenharia 
de Software, usando experimentos controlados.
Fornece­nos conhecimento do mundo físico e é a experiência que fornece as evidên­
cias que fundamentam esse conhecimento. A experiência desempenha muitos papéis 
na ciência. Um de seus papéis importantes é testar teorias e fornecer a base para o 
conhecimento científico.
Realizar um experimento quase sempre é uma tarefa complexa e demorada. Uma vez 
que a experimentação envolve muitas etapas, como definição de meta, planejamento, 
execução, análise e empacotamento, todas devem ser realizadas de forma sistemática e 
consistente para alcançar um experimento replicável e resultados válidos. Como a escala 
dos problemas científicos tem aumentado, isso se reflete não apenas no tamanho dos 
dados, mas também na complexidade das ferramentas baseadas em computador neces­
sárias para investigar esses problemas.
Organização do Experimento 
Para Travassos, Gurov e Amaral (2002), é verdade que nenhum experimento oferece 
prova com certeza; eles verificam a previsão teórica de encontro à realidade. A comu­
nidade aceita uma teoria se todos os fatos conhecidos dentro de seu domínio puderem 
ser deduzidos da teoria, possuírem uma verificação experimental extensa e predizerem 
o novo fenômeno corretamente.
Uma das coisas importantes na organização de um experimento, efetivamente saber 
por que você está fazendo um experimento. Portanto, precisamos da famosa “hipóteses”.
Uma hipótese é algo que você propõe ser verdadeiro como base para uma investi­
gação posterior. As pessoas costumam fazer suposições ao iniciar projetos de software, 
por exemplo, em que uma tecnologia atenderá a todos os requisitos necessários mas não 
definem ou registram totalmente essas suposições. Uma hipótese está, de certa forma, 
um nível acima de uma suposição. Uma hipótese é uma suposição que você não sabe se 
é verdadeira. Para continuar com o projeto sob esse pressuposto ele precisa ser provado 
e, para isso, requer evidências.
É importante neste ponto definir os critérios de prova. Se você está prestes a embarcar 
em uma prova de conceito, precisa definir os critérios de sucesso.
Por exemplo, se tivéssemos um sistema que precisa processar grandes quantidades de 
dados em tempo real, baseado na internet, então alguns critérios de sucesso podem ser:
• Podemos ter 1 000 000 de acessos simultâneos no site de compra;
• Podemos processar 10 000 mensagens em um segundo;
12
13
• Podemos fazer isso dentro das restrições de orçamento do software;
• Podemos recuperar o atraso se ficarmos para trás em nosso processamento.
E nossa hipótese para esse caso é, por exemplo:
• Seremos capazes de atender aos quatro critérios de sucesso acima usando Azure e 
Python com um front em HTML5 e CSS3?
Em seguida, precisamos coletar evidências para provar ou refutar nossa hipótese.
Mas, essencialmente, significa coletar evidências para provar/refutar um design. Neste 
estágio, construímos a versão mínima útil do sistema que podemos usar para validar nosso 
pensamento. Esse processo parece muito diferente, dependendo da hipótese que você 
está tentando provar.
O importante a lembrar neste ponto é que você deve fazer isso sem supor se a hipótese 
é verdadeira ou não. Uma prova de conceito é útil e fundamental, não importa o resultado. 
Provar que uma abordagem não atenderá aos critérios é tão útil quanto provar que sim.
Com isso em mente, é importante provar ou refutar rapidamente uma abordagem. 
Um loop de feedback rápido entre hipótese, experimento e conclusão é extremamente 
importante. Desta forma, você pode estabelecer rapidamente as abordagens que não 
vão funcionar e continuar com uma avaliação mais aprofundada e, posteriormente, o 
uso da solução comprovada.
É aí que entra a famosa “Prova de Conceito”. Mas espere aí! Antes, um pouco da 
história sobre as tais provas de conceito e como esse conceito tão puro, inteligente e 
bonito, foi distorcido aqui em nosso país.
Vamos primeiro, “pôr os pingos nos is”:
Prova de conceito ou POC, também conhecida como prova de princípio,é a rea­
lização de um determinado método ou ideia para demonstrar sua viabilidade, ou uma 
demonstração de princípio com o objetivo de verificar se algum conceito ou teoria tem 
potencial prático.
Normalmente, depois que um resultado confiável é alcançado no estágio de prova de 
conceito, em seguida vem o protótipo de aparência. Este modelo responde à pergunta: 
como será a aparência e a sensação de uso? Ele oferece uma amostra do design final. 
O protótipo de aparência é visualmente representativo, mas carece de funcionalidade 
real (pelo menos deveria carecer).
Se o seu cliente tiver uma intenção real, honesta e idônea, ele pagará pelo POC. 
Acho importante que o cliente se comprometa com o POC de alguma forma. Afinal, 
muitos jovens desenvolvedores e analistas se comprometem, de corpo e alma, com uma 
solução ou arquitetura e gastam seu tempo e possibilidades de ganhos fazendo “coisas 
para os outros”. E acabam resolvendo problemas de graça e depois são descartados por 
algum outro fornecedor, ou pior, ninguém levou nada mas viraram “trouxas” do cliente 
tomador do serviço. Se você for uma startup e quiser gerar dinheiro e eles forem um 
grande cliente, cobre, sem medo. Se não pagarem, esse cliente não era para ser seu e 
se fosse, geraria mais dor de cabeça que proventos e networking. Lembre­se, você é 
livre e independente.
13
UNIDADE Conceituação de Engenharia de Software Experimental
O desenvolvimento de uma prova de conceito geralmente requer algum 
investimento de tempo ou outros recursos, como tecnologias de suporte 
ou componentes físicos necessários para ser concluído. Passar por esse 
processo, no entanto, permite que as empresas determinem a viabilidade 
de uma ideia antes de colocar recursos de nível de produção por trás de 
uma ideia não testada.
Um plano de prova de conceito pode abordar como o produto ou serviço 
proposto apoiará as metas organizacionais , objetivos ou outros requisitos 
de negócios, embora essa etapa não seja o objetivo principal do POC. 
O processo de prova de conceito deve incluir:
• critérios claramente definidos para o sucesso;
• documentação de como a prova de conceito será realizada;
• um componente de avaliação; e
• uma proposta de como avançar caso o POC seja bem­sucedido.
O desenvolvimento de tal plano é uma etapa importante para determinar 
como um produto ou serviço imaginado será entregue aos usuários com 
o menor número de falhas.
Prova de conceito vs. protótipo
Embora os termos prova de conceito e protótipo sejam frequentemente 
usados de forma intercambiável, eles são processos diferentes destinados 
a produzir resultados diferentes e servir a propósitos diferentes.
Onde uma prova de conceito se destina a determinar se uma ideia pode 
ser transformada em realidade, um protótipo se destina a transformar 
essa ideia em uma versão simplificada do produto que pode ser testado e 
avaliado quanto à usabilidade, funcionalidade e design. Não se espera que 
um protótipo tenha todos os recursos e funções de um produto pronto 
para o mercado, nem que contenha toda a usabilidade ou estética de um 
produto. Ele fornece às partes interessadas, como gerentes e executivos 
de projeto, bem como investidores em potencial, um esboço de como será 
o produto. (PRATT, 2020, p. 2)
Bem, em suma, uma vez que uma hipótese foi provada ou refutada, você pode tirar 
suas conclusões.
Se a conclusão disser que uma abordagem funciona ou não, é importante escrevê­la 
e documentar totalmente todas as decisões tomadas. Isso não apenas o força a pensar e 
considerar totalmente essas decisões, mas também é fundamental para que as pessoas 
possam entender o design posteriormente.
Usando esse processo, podemos avaliar rapidamente as abordagens sugeridas e mini­
mizar o tempo perdido explorando becos sem saída.
A lição mais importante é que o processo experimental científico é igualmente apli­
cável ao desenvolvimento de software e deixa você não apenas com um design no qual 
você tem confiança, mas também com um raciocínio totalmente documentado por trás 
de cada decisão tomada.
Agora que você já entendeu, vamos brevemente voltar ao tema da POC, com um 
pequeno causo para sua aprendizagem:
14
15
Nos idos de 2013, quatro empresas bem-posicionadas em “data cleansing” ou lim-
peza de dados, foram chamadas para uma prova de conceito de uma grande insti-
tuição. Todos os concorrentes estavam eufóricos e queriam fazer o cliente potencial 
conhecer qual era o melhor e vencer a competição, afinal, era algo em torno de 
90.000.000 de CPFs que estavam em jogo para serem tratados. Então veio a ordem 
do potencial cliente:
• Senhores, precisamos que vocês façam uma prova de conceito para limpar, du-
plicar e enriquecer os nossos dados, para tanto propomos que vocês realizem 
uma POC com suas tecnologias como critério de seleção para um projeto espe-
cial que temos aqui. A POC ocorrerá com 5.000 registros como amostra para 
cada um dos fornecedores.
Ohhhhh, todos ficaram eufóricos e mandaram seus orçamentos para a sua POC. Porém, 
receberam uma ligação...
• Se vocês cobrarem a POC não faremos com vocês, pois são só 5.000 registros de 
90.000.000 milhões que temos, isso é uma ousadia.
Todavia é importante você saber que para esse experimento, houve horas de setup, 
escrita de código, preparação de interface, preparação de ambiente, horas homem, 
horas teste etc. Mas como eram 90 milhões de registros, todos os 4 abriram mão e 
rodaram as POCs livres de custos. A coisa não era tão simples assim, investiram-se 
40 horas de codificação para você ter uma ideia.
Bom, todos entregaram suas POCs e aguardaram o resultado, que como você já deve 
imaginar, não veio.
Bem, as empresas acharam estranho e começaram a conversar entre si. Duas delas 
haviam ligado e foram rispidamente tratadas.
• Infelizmente devido à crise “desculpa para qualquer intercorrência econômica 
temporária no país” não poderemos ir adiante com o projeto, agradecemos sua 
presteza em nos atender e esperamos poder contar com você para o próximo 
projeto em tempos melhores;
• Como assim, “cara pálida”?!
Todos ficaram com cara de interrogação após investirem tempo, e pensaram, bem, 
mas dos males o menor, eram só 5.000 registros.
5.000 de cada, portanto 20.000 registros foram processados.
Quase 2 anos depois, acabou-se descobrindo que na verdade o projeto era para 
20.000 registros que deveriam ser preparados para uma campanha de marketing
exclusiva para clientes “TOP” já selecionados e devidamente segmentados pelo time 
de DBA daquele potencial cliente.
Portanto, caro aluno, o projeto saiu: “de graça”.
Moral da história, POC é perigoso se você abrir mão de cobrar porque você ou a empre-
sa que você trabalha espera por um contrato mais à frente. Isso infelizmente não existe. 
A ordem no mercado e nos negócios é “cobre”, mesmo que o cliente vá para outro.
Imagino que você esteja curioso pelo fim da história... sim, vou contar.
O Superintendente da área do potencial cliente foi demitido por assédio moral, coisa 
que aconteceu quando ele assediou funcionários de outra área e o outro superinten-
dente tinha mais cacife político. Às vezes acontece.
15
UNIDADE Conceituação de Engenharia de Software Experimental
Bom, daí você pode imaginar que seus colaboradores e demais pessoas pressionadas 
se sentiram livres para abrirem processos, contarem histórias de terror, e por aí vai.
Ética nos negócios e ética em engenharia de software não se negocia, evite cair em 
armadilhas você que está no início de carreira ou que ainda não teve o azar de passar 
por isso.
Experimentação e Engenharia 
de Software Experimental
A Engenharia de Software Experimental é uma parte que se concentra na coleta 
de evidências, por meio de medições e experimentos envolvendo sistemas de software 
(produtos, processos e recursos de software).
O principal objetivo da realização de experimentos é provar ou refutar as hipóteses 
ou ideias dos cientistas.
Portanto é fundamental utilizar o uso da abordagem científica para o desenvolvimento, 
evolução e manutenção de software, principalmente métodos científicos para fazer pes­
quisa e para tomar decisões sobre mudanças na forma de desenvolver softwares. Normal­
mente começa com a observação e o registro do que é observado, e evolui para a mani­
pulação de variáveis controláveis e a observação de seu efeito em variáveis de interesse.
Para entender uma disciplina é necessário a construção de modelos, não 
só de produtos mas também de processos e domínios de aplicação. Para 
testar se a compreensão está correta é preciso testar esses modelos, isto 
implica em experimentação. Ao se analisar resultados experimentais, 
aprendemos e consolidamos esse conhecimento em modelos mais sofis­
ticados. (BRAGA; MASIERO, 2017, p. 10)
Portanto da mesma maneira que há paradigmas em Engenharia de Software, como vi­
mos anteriormente, temos paradigmas em Engenharia de Software Experimental, a saber:
• Paradigma Analítico:
 » Baseado em matemática;
 » Propõe uma teoria formal ou um conjunto de axiomas;
 » Deriva matematicamente um conjunto de resultados;
 » Está no cerne da ciência da computação e expõe a herança matemática de nossa 
área (Engenharia de Software).
• Paradigma Experimental:
 » Observa o mundo ou soluções existentes;
 » Propõe um modelo de comportamento ou solução melhor;
 » Mede e analisa modelos experimentalmente;
 » Valida ou refuta hipóteses e modelos.
16
17
De�nição Interpretação
Coleta de dados empíricosPlanejamento
O 
Pl
an
o d
o p
ro
je
to
Coleta de dados
Objetivo
Questão
Métrica Medição
Resposta
Alcanço do
objetivo
Figura 1 – Relações entre a teoria versus observação e
o ciclo para a organização de um processo de solução
Fonte: Adaptada de BRAGA, R.; MASIERO, P.C., 2017. p.14
Um experimento deve ser tratado como um processo da formulação ou 
verificação de uma teoria. A fim de que o processo ofereça os resulta­
dos válidos, ele deve ser propriamente organizado e controlado ou, pelo 
menos, acompanhado. Com o propósito de atingir estes objetivos várias 
metodologias de organização dos experimentos foram elaboradas. Para se­
rem comparadas as metodologias da experimentação possuem diferentes 
características como, por exemplo, as fases do processo de experimenta­
ção, a maneira da transformação dos conceitos abstratos do domínio às 
métricas concretas, o objetivo principal da experimentação, as ferramentas 
do empacotamento etc.
Um bom exemplo da metodologia da experimentação avançada é o Para­
digma da Melhoria da Qualidade (Quality Improvement Paradigm – QIP). 
A essência dessa metodologia está na melhoria contínua do processo do 
desenvolvimento de software.
A metodologia define os seis passos que terminam resultando em um ci­
clo da melhoria do processo completo. O ciclo se inicia com a caracteriza­
ção do processo de negócio necessária para a compreensão do ambiente 
e a definição dos objetivos básicos. A seguir os objetivos quantitativos são 
estabelecidos com a propósito de demonstrar as expectativas razoáveis 
da experimentação. Baseado na caracterização e nos objetivos definidos 
o processo da melhoria apropriado é escolhido tomando em considera­
ção a consistência entre os objetivos. O processo do desenvolvimento de 
software oferece, além do próprio software, o feedback do projeto que 
representa a informação recolhida. Essa informação serve como a base 
para a análise, ou seja, a avaliação das práticas atuais, a determinação 
dos problemas, a proposição da melhoria futura. Finalmente, toda infor­
mação relevante está empacotada para utilização futura. (TRAVASSOS; 
GUROV; AMARAL, 2002, p. 19)
17
UNIDADE Conceituação de Engenharia de Software Experimental
Causa Efeito
ResultadoTratamento
Teoria
Variável
Independente
Execução do
Experimento
Variável
Dependente
Observação
Figura 2 – O processo principal da abordagem GQM
Fonte: Adaptada de TRAVASSOS; GUROV; AMARAL, 2002, p. 21
Quais tipos de pesquisa nos auxiliam e são complementares?
Temos dois tipos de paradigmas de pesquisa com abordagens diferentes para estudos 
empíricos nos quais devemos notar a complementaridade entre ambas para fins de pes­
quisa em engenharia de software experimental, a saber:
A pesquisa exploratória se preocupa em estudar objetos em seu ambiente natural e 
deixar os achados emergirem das observações.
Isso implica um desenho de pesquisa flexível para se adaptar às mudanças no fenô­
meno observado. A pesquisa de design flexível também é referida como pesquisa quali­
tativa, pois é principalmente informada por dados qualitativos. Pesquisas indutivas ten­
tam interpretar um fenômeno baseado em explicações que as pessoas trazem adiante. 
Preocupa­se em descobrir as causas notadas pelos sujeitos no estudo e entender sua 
visão do problema em questão. O sujeito é a pessoa, que está participando de um estudo 
empírico para avaliar um objeto.
A pesquisa explicativa preocupa­se principalmente em quantificar uma relação ou 
comparar dois ou mais grupos com o objetivo de identificar uma relação causa­efeito.
A pesquisa é frequentemente conduzida através da criação de experimentos contro­
lados. É um estudo de design fixo, implicando que os fatores são corrigidos antes do 
lançamento do estudo.
A pesquisa de design fixo também é referida como pesquisa quantitativa, pois é infor­
mada principalmente por dados quantitativos.
Investigações quantitativas são apropriadas ao testar o efeito de alguma manipulação 
ou atividade.
Os métodos de pesquisa quantitativa enfatizam medidas objetivas e a análise estatís­
tica, matemática ou numérica de dados coletados por meio de pesquisas, questionários 
e pesquisas ou pela manipulação de dados estatísticos pré­existentes usando técnicas 
computacionais.
A pesquisa quantitativa concentra­se em reunir dados numéricos e generalizá­los entre 
grupos de pessoas ou para explicar um fenômeno específico. O relatório final escrito tem 
uma estrutura definida que consiste em introdução, literatura e teoria, métodos, resulta­
dos e discussão.
18
19
Seu objetivo ao conduzir um estudo de pesquisa quantitativa é determinar a relação 
entre uma variável independente e outra, uma variável dependente ou de resultado den­
tro de uma população. Os projetos de pesquisa quantitativa são descritivos, geralmente 
medidos uma vez ou experimental medidos antes e depois de um tratamento.
Um estudo descritivo estabelece apenas associações entre variáveis; um estudo expe­
rimental estabelece causalidade.
Suas principais características são:
• Os dados são geralmente coletados por meio de instrumentos de pesquisa estruturados;
• Os resultados são baseados em tamanhos de amostra maiores que são representa­
tivos da população;
• O estudo de pesquisa geralmente pode ser replicado ou repetido, dada sua 
alta confiabilidade;
• O pesquisador tem uma questão de pesquisa claramente definida para a qual res­
postas objetivas são buscadas;
• Todos os aspectos do estudo são cuidadosamente planejados antes que os dados 
sejam coletados;
• Os dados estão na forma de números e estatísticas, geralmente organizados em 
tabelas, gráficos, figuras ou outras formas não textuais;
• O projeto pode ser usado para generalizar conceitos mais amplamente, prever 
resultados futuros ou investigar relações causais;
• O pesquisador utiliza ferramentas, como questionários ou softwares de computador, 
para coletar dados numéricos.
Uma vantagem é que os dados quantitativos promovem comparações e análi­
ses estatísticas.
Podemos utilizar métodos qualitativos também.
A definição de qualitativa refere­se a medidas das características de algo.
A pesquisa qualitativa envolve a coleta e análise de dados não numéricos (por exem­
plo, texto, vídeo ou áudio) para compreender conceitos, opiniões ou experiências. A pes­
quisa qualitativa é o oposto da pesquisa quantitativa , que envolve a coleta e análise de 
dados numéricos para análise estatística.
A pesquisa qualitativa visa obter uma compreensão profunda de uma organização 
ou evento específico, ao invés de uma descriçãosuperficial de uma grande amostra de 
uma população. Tem como objetivo fornecer uma representação explícita da estrutura, 
ordem e padrões gerais encontrados entre um grupo de participantes, por exemplo.
A pesquisa qualitativa não introduz tratamentos ou manipula variáveis, nem impõe 
aos participantes as definições operacionais de variáveis do pesquisador. Em vez disso, 
permite que o significado surja dos participantes. É mais flexível porque pode se ajustar 
à configuração. Conceitos, ferramentas de coleta de dados e métodos de coleta de dados 
podem ser ajustados à medida que a pesquisa avança.
19
UNIDADE Conceituação de Engenharia de Software Experimental
Tem como objetivo obter um melhor entendimento por meio de experiências em 
primeira mão, relatos verdadeiros e citações reais. Assim, compreender como os par­
ticipantes extraem significado de seu entorno e como seu significado influencia seu 
comportamento.
A pesquisa qualitativa usa a observação como método de coleta de dados. A observa­
ção é usada extensivamente em estudos e reduz a distorção entre o observador e objeto 
observado, que pode ser produzido por um instrumento.
O cenário do mundo real é a primeira característica da pesquisa qualitativa. Em mé­
todos de pesquisa qualitativa, como método de observação, pesquisa etnográfica, grupo 
focal, entrevistas individuais, o comportamento dos participantes do estudo é observado 
e a conclusão é tirada com base em suas respostas e seu comportamento, por exemplo, 
perante um sistema de informação ou protótipo.
É possível que pesquisas qualitativas e quantitativas investiguem os mesmos temas, 
mas cada um deles abordará um tipo diferente de questão.
Por exemplo, uma investigação quantitativa poderia ser iniciada para investigar o 
quanto um novo método de inspeção diminui o número de falhas encontradas no teste. 
Para responder a perguntas sobre as fontes de variações entre diferentes grupos de ins­
peção, uma investigação qualitativa poderia ser iniciada.
Estratégias de design fixo, como experimentos controlados, são apropriadas ao testar 
os efeitos de um tratamento, enquanto um estudo de design flexível é apropriado para 
descobrir por que os resultados de uma investigação quantitativa são como eles são.
As duas abordagens devem ser consideradas complementares e não competitivas 
entre si.
Introdução à Engenharia 
de Software Experimental
Engenharia de Software Experimental é um ramo da engenharia de software que 
visa avaliar os conceitos utilizados na produção de sistemas de software, como o desen­
volvimento de ciclos ou arquiteturas de software. É a aplicação de métodos empíricos à 
engenharia de software.
É o estudo dos artefatos de software, ou seja, os elementos envolvidos na criação de 
um software ou resultado, para fins de caracterização, compreensão, avaliação, previsão, 
controle, gestão ou melhoria por meio de análises qualitativas ou quantitativas.
Muitos critérios entram em jogo no projeto de software, como os métodos de desen­
volvimento a serem adotados, o número de desenvolvedores a serem empregados ou o 
tempo de produção a ser estimado.
Muitas vezes, com base na experiência dos desenvolvedores, as escolhas que decor­
rem desses critérios são influenciadas mais por opiniões e “achismos” do que por análises 
objetivas. Muitos artigos científicos publicados em periódicos de engenharia de software 
não apresentam qualquer validação experimental e isso descredencia boa parte das pes­
quisas relacionadas a performance e novas abordagens, mantendo os desenvolvedores 
20
21
e engenheiros de software em uma certa zona de conforto, por outro lado mantém as 
áreas financiadoras de projetos com os “pés atrás”.
A Engenharia de Software Experimental consiste na observação de al­
guns aspectos do desenvolvimento de software com foco no experimento . 
Esta observação pode ser feita através da aplicação de métodos ou técni­
cas, sejam eles novos ou já existentes. A Engenharia de Software Experi­
mental permite compreender melhor o funcionamento das coisas e saber 
se o que se acredita ser verdade realmente é. Existem vários contextos de 
aplicação dos experimentos em Engenharia de Software Experimental 
como in vitro, in vivo, in sílico e in virtuo. (JESUS, 2013, p. 6)
O objetivo do uso de métodos experimentais em engenharia de software é, então, 
provar ou refutar o valor de uma abordagem ou técnica particular. Para tanto, os da­
dos manipulados na engenharia de software empírica cobrem todo o ciclo de vida do 
software incluindo, entre outras coisas, o código­fonte (funcional ou de teste ), histórico, 
documentação ou mesmo vestígios de execução do software.
Mas Engenharia de Software também é uma disciplina de laboratório, portanto há 
necessidade da existência de profissionais cujo papel é construir cada vez “mais barato” 
e “mais rápido” sistemas cada vez “melhores”, utilizando o conhecimento disponível à 
época. Portanto, é fundamental que entendamos, ou ao menos tentemos entender, a 
natureza dos processos e produtos de software e da relação entre os dois no desenvolvi­
mento e manutenção de sistemas.
Mas se a Engenharia de Software Experimental trabalha basicamente com o entendi­
mento a partir do teste de hipóteses e comparações para saber o que é funcional e o que 
não é em construção de software ou em abordagem processuais em software, temos 
então os paradigmas, ou se preferir as formas de se fazer isso não é mesmo?!
Todavia, devemos refletir sobre a novidade da disciplina de Engenharia de Software
que despontou como a “salvação para a crise do software” e, que hoje, é terrivelmente 
dependente de teste e experimento para que seus produtos de software possam ser acei­
tos pelos seus usuários. Independentemente do método da moda ou do que as grandes 
consultorias e fabricantes determinem. Vejamos por exemplo esse pequeno excerto, 
retirado de um livro canônico sobre Engenharia de Software Experimental:
A experimentação refere­se à correspondência com fatos a suposições, 
especulações e crenças que abundam na construção de software. A cons­
trução de software é apoiada e usa uma série de ideias: aplicamos técni­
cas em que confiamos para produzir um determinado resultado; acredita­
mos que muitas pessoas serão capazes de concluir o projeto; esperamos 
que o tempo de desenvolvimento seja menor usando uma determinada 
ferramenta; assumimos que a qualidade do produto será melhor se usar­
mos um determinado processo de desenvolvimento etc.
Mas temos a certeza de que as nossas crenças são verdadeiras? Quais das 
alegações feitas pela comunidade de desenvolvimento de software são 
válidas? Em que circunstâncias são válidas?
Infelizmente, quase não há certezas sobre as ideias sobre as quais a 
Enge nharia de Software se funda. A engenharia de software atingiu um 
estágio mais parecido com a charlatanice do que a engenharia; uma si­
tuação em que um artigo de pesquisa após o outro exalta as virtudes de 
21
UNIDADE Conceituação de Engenharia de Software Experimental
um procedimento, estilo, técnica ou conjunto de regras específicos para 
domar o monstro do software e levar à terra prometida; uma situação em 
que as anedotas formam a maior parte das informações disponíveis sobre 
o quão bem um determinado esquema funciona, especialmente em com­
paração com modelos concorrentes; uma situação em que as opiniões 
são muitas vezes fortemente mantidas, vigorosamente defendidas e mais 
prevalentes do que dados objetivos reais.
Atualmente, as ideias válidas distinguem­se das falsas crenças em enge­
nharia de software, aplicando o teste do tempo. A certeza de uma ideia é 
julgada se as pessoas usam a ideia. Se muitas pessoas usam a ideia, pa­
recemos ter certeza. Se poucas pessoas usarem a ideia, ela é considerada 
falsa e será devastada pelo tempo. Este modus operandi é mais parecido 
com disciplinas “da moda” do que engenharia. (JURISTO; MORENO, 
2010, p. 3)
Por ser uma área relativamente nova, a Engenharia de Software Experimental enfrenta 
a opiniãodos céticos, todavia, as refutações são muito fortes, vejamos:
Quadro 1 – Resumo de falácias e refutações sobre experimentação em ciência da computação
O método científico 
tradicional não é aplicável.
Para entender o processo de informação, os cientistas da computação 
devem observar fenômenos e formular e testar explicações. Este é o 
método científico.
O nível atual de 
experimentação é 
bom o suficiente.
Em relação a outras ciências, os dados mostram que os cientistas da 
computação validam uma porcentagem menor de suas reivindicações.
Experimentos 
custam muito.
Experimentos significativos podem se encaixar em pequenos orça-
mentos; experimentos caros podem valer mais do que seu custo.
As manifestações 
serão suficientes.
Demos pode fornecer incentivos para estudar uma questão mais 
adiante. Muitas vezes, no entanto, essas demonstrações apenas ilus-
tram um potencial.
Há muito barulho 
no caminho.
Felizmente, técnicas podem ser usadas para simplificar variáveis e res-
ponder perguntas.
A experimentação 
atrasará o progresso.
Aumentar a proporção de papéis com validação significativa tem uma 
boa chance de acelerar o progresso.
A tecnologia muda 
muito rápido.
Se uma pergunta se torna irrelevante rapidamente, ela é muito estrei-
tamente definida e não vale a pena gastar muito esforço.
Você nunca 
vai publicá-lo.
Passos menores ainda valem a pena publicar porque melhoram nosso 
entendimento e levantam novas questões.
Fonte: Adaptado de JURISTO; MORENO, 2010, p. 7
Por outro lado, a obra canônica de Brooks (1986) descreve alguns desafios com 
a produção de software que reinam até hoje, dentre os argumentos, que ele acerta­
damente usa, não há um único desenvolvimento, seja em tecnologia ou técnica de 
 gerenciamento, que por si só promete 10 vezes melhoria em uma década em produtivi­
dade, confiabilidade e simplicidade no desenvolvimento de software. E vai além, dizendo 
22
23
que não podemos esperar ver ganhos de duas vezes a cada dois anos no desenvolvimen­
to de software, como ocorre no desenvolvimento de hardware citando a lei de Moore.
Aqui deixo um artigo para você poder ler esse divisor de águas na Engenharia de Software
escrita por Brooks, ganhador do prêmio Alan Turing.
Sim, o artigo está em inglês. É importante que você entenda que a língua pátria da Tecnolo-
gia da Informação é o inglês e por mais que a universidade se esmere em deixar o conteúdo 
de graduação em português, uma parte desse esforço dependerá de você para prosperar 
na área que escolheu ser profissional: o inglês. É aconselhável que você inicie os estudos 
imediatamente. A Universidade Cruzeiro do Sul possui cursos acessíveis e parceiros incríveis 
para que você possa evoluir e vir a ser um excelente profissional. Vale o esforço!
Artigo original: BROOKS, F. P. J. No silver bullet: essence and accident in Software Engineering. 
1986. Disponível em: https://bit.ly/3DxYOMc
Segundo Brooks (1986), existem dois tipos de dificuldades em desenvolvimento de 
software: essenciais e acidentais. As essenciais são da natureza da área e dificilmente 
serão superadas por qualquer nova tecnologia ou método que se invente.
As dificuldades essenciais são as seguintes:
1. Complexidade: dentre as construções que o homem se propõe a 
realizar, software é uma das mais desafiadoras e mais complexas 
que existe. Na verdade, como dissemos antes, mesmo construções de 
engenharia tradicional, como um satélite, uma usina nuclear ou um 
foguete, são cada vez mais dependentes de software;
2. Conformidade: pela sua natureza software tem que se adaptar ao seu 
ambiente, que muda a todo momento no mundo moderno. Por exem­
plo, se as leis para recolhimento de impostos mudam, normalmente es­
pera­se que os sistemas sejam rapidamente adaptados à nova legislação. 
Brooks comenta que isso não ocorre, por exemplo, na Física, pois as 
leis da natureza não mudam de acordo com os caprichos dos homens.
3. Facilidade de mudanças: que consiste na necessidade de evoluir 
sempre, incorporando novas funcionalidades. Na verdade, quanto 
mais bem sucedido for um sistema de software, mais demanda por 
mudanças ele recebe;
4. Invisibilidade: devido à sua natureza abstrata, é difícil visualizar o 
tamanho e consequentemente estimar o esforço de construir um sis­
tema de software.
As dificuldades (2), (3) e (4) são específicas de sistemas de software, isto 
é, elas não ocorrem em outros produtos de Engenharia, pelo menos na 
mesma intensidade. Por exemplo, quando a legislação ambiental muda, 
os fabricantes de automóveis têm anos para se conformar às novas leis. 
Adicionalmente, carros não são alterados, pelo menos de forma essencial, 
com novas funcionalidades, após serem vendidos. Por fim, um carro é 
um produto físico, com peso, altura, largura, assentos, forma geométrica 
etc., o que facilita sua avaliação e precificação por consumidores finais. 
(VALENTE, 2020, p. 4­5)
23
UNIDADE Conceituação de Engenharia de Software Experimental
A complexidade essencial é o quão difícil é algo de fazer, independentemente do quão 
experiente você seja, quais ferramentas usa ou qual novo padrão de arquitetura chama­
tivo você usou para resolver o problema.
Embora alguma complexidade seja inerente ao problema, também trazemos nossa 
própria complexidade ao escrever o programa. Trata­se da complexidade acidental.
E aí é que está toda a graça da coisa.
Pensemos numa analogia para descrevê­la: Você pode pensar na distância de sua 
casa até a universidade como sendo a complexidade essencial. Mas o caminho que 
você segue para conseguir chegar lá é uma complexidade acidental. E, pelo menos em 
teoria, você poderia reduzir a complexidade acidental a zero. Seria apenas você sair da 
sua casa e traçar uma linha reta até a universidade não é mesmo?! Infelizmente, é meio 
difícil andar reto numa cidade, mesmo se você tivesse um helicóptero, ou melhor ainda, 
mais rápido do que a velocidade da luz.
No entanto, o problema em si não era tão complexo. Às vezes, ao escolher a ferra­
menta certa, você poderá conseguir reduzir substancialmente a complexidade acidental. 
Mas para resolver isso, temos que dar um passo para trás e olhar o problema em ques­
tão de forma apurada.
Parece interessante ver como tudo isso aconteceu, todos esses problemas que ator­
mentaram os engenheiros de software na década de 1980 do século XX foram essen­
ciais para o início dessa nova área, a Engenharia de Software Experimental.
24
25
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Vídeos
Engenharia de Software Experimental
A Engenharia de Software Experimental é o estado da arte da tecnologia: a área entre a 
pesquisa científica e a Engenharia de Software.
https://youtu.be/s_Bp5n51YqM
O problema do milênio sobre intratabilidade computacional
Qual é a diferença entre responder uma pergunta e verificar uma resposta?
https://youtu.be/tpEUu7Rtgk8
Motivação para Engenharia de Software Experimental
https://youtu.be/qpHf9qEe9Hs
 Leitura
No Silver Bullet – Essence and Accidents of Software Engineering
Moldar construções conceituais complexas é a essência; tarefas acidentais surgem na re­
presentação de construções na linguagem. O progresso passado reduziu tanto as tarefas 
acidentais que o progresso futuro agora depende de abordar a essência.
https://bit.ly/2Yahul8
25
UNIDADE Conceituação de Engenharia de Software Experimental
Referências
BRAGA, R. B.; MASIERO, P. C. Introdução à Engenharia de Software Experimen-
tal. São Paulo: ICMC­USP, 2017. Disponível em: <https://edisciplinas.usp.br/pluginfile.
php/3024449/mod_resource/content/2/Aula_1_Introducao_ESExp_2017.pdf> Acesso 
em: 10/02/2021.
JESUS, H. A. Revisão sistemática de Engenharia de Software Experimental in 
vitro: uma análise preliminar. Universidade Federal de Lavras – UFLA, Lavras, MG. 
2013. Disponível em: <http://docplayer.com.br/5918687­Heider­alvarenga­de­jesus­re­
visao­sistematica­de­engenharia­de­software­experimental­in­vitro­uma­analise­prelimi­
nar.html>.Acesso em: 10/02/2021.
JURISTO, N.; MORENO, A. M. Basics of Software Engineering experimentation. 
2010. Disponível em: <https://www.cin.ufpe.br/~in1002/leituras/Basics_of_Software _
Engineering_Experimentation.pdf> Acesso em: 10/02/2021.
PRATT, M.K. prova de conceito (POC). 2020. Disponível em: <https://searchcio.
techtarget.com/definition/proof­of­concept­POC> Acesso em: 10/02/2021.
TRAVASSOS, G. H.; GUROV, D.; AMARAL, E. A. G. Introdução à Engenharia 
de Software Experimental. Universidade Federal do Rio de Janeiro – UFRJ, Rio de 
 Janeiro: RJ, 2002. 52 p. Disponível em: <https://www.cin.ufpe.br/~scbs/experimen­
tal/IntroducaoExperimentacao.pdf> Acesso em: 10/02/2021.
VALENTE, M. T. Engenharia de Software Moderna. Independente, 2020. 408p. 
Disponível em: <https://engsoftmoderna.info/>. Acesso em: 10/02/2021.
26
Engenharia de 
Software Experimental
Responsável pelo Conteúdo:
Prof. Me. Artur Marques
Revisão Textual:
Mariana Góis
Processos de Condução de Estudos Experimentais
Processos de Condução 
de Estudos Experimentais
 
 
• Perceber a existência de vários processos dentro da engenharia de software experimental;
• Saber onde aplicar cada tipo de processo.
OBJETIVOS DE APRENDIZADO 
• Princípios da Organização do Experimento;
• Pacotes de Laboratório;
• Experimentos;
• Experimentos Controlados em Engenharia de Software;
• Métodos Estatísticos e Análise de Dados em 
Engenharia de Software Experimental;
• A Lei dos Grandes Números.
UNIDADE Processos de Condução de Estudos Experimentais
Contextualização
Nas organizações de desenvolvimento de software atuais, são empregados métodos 
e ferramentas que frequentemente carecem de evidências suficientes sobre sua adequa-
ção, limites, qualidades, custos e riscos associados.
8
9
Princípios da Organização do Experimento
Em sua forma mais simples, um experimento visa prever o resultado introduzindo 
uma mudança nas pré-condições, que é representada por uma ou mais variáveis inde-
pendentes , também chamadas de “variáveis de entrada” ou “variáveis de previsão”. 
A mudança em uma ou mais variáveis independentes é geralmente hipotetizada para 
resultar em uma mudança em uma ou mais variáveis dependentes , também chamadas 
de “variáveis de saída” ou “variáveis de resposta”. 
O projeto experimental também pode identificar variáveis de controle que deve ser 
mantido constante para evitar que fatores externos afetem os resultados. 
O projeto experimental envolve não apenas a seleção de variáveis independentes, de-
pendentes e de controle adequadas, mas também o planejamento da entrega do experi-
mento sob condições estatisticamente ótimas, dadas as restrições dos recursos disponíveis. 
Existem várias abordagens para determinar o conjunto de pontos de design (combina-
ções únicas das conf igurações das variáveis independentes) a serem usados no experimento.
As principais preocupações no projeto experimental incluem o estabelecimento de 
validade, confiabilidade e replicabilidade. 
Por exemplo, essas preocupações podem ser parcialmente tratadas escolhendo cui-
dadosamente a variável independente, reduzindo o risco de erro de medição e garan-
tindo que a documentação do método seja suficientemente detalhada. As preocupações 
relacionadas incluem a obtenção de níveis apropriados de poder estatístico e sensibilida-
de. Experimentos corretamente projetados aumentam o conhecimento nas engenharias.
Os objetivos relacionados à execução de experimentos em Engenharia de 
Software são a caracterização, avaliação, previsão, controle e melhoria a 
respeito de produtos, processos, recursos, modelos, teorias entre outros. 
A importância e o esforço aumentam de um experimento com o objetivo 
“caracterização” a um experimento com o objetivo “melhoria”. Isso signi-
fica que é bastante simples conduzir um experimento com a finalidade de 
caracterização respondendo questões do tipo “o que está acontecendo?”. 
É mais difícil medir algo, por exemplo, um processo ou produto e defini-lo 
“quão bom é isto?”. Os experimentos com a finalidade de previsão além 
da medição precisam de meios de estimativa para mostrar a possibilidade 
de: “posso estimar algo no futuro?”. Para atender a finalidade de controle 
deve existir a possibilidade de gerenciar os atributos de um processo ou 
produto e dar a resposta a “posso manipular o evento?”. Finalmente, a 
finalidade da melhoria supõe que possamos caracterizar, avaliar, predizer 
e controlar, e há os objetivos da melhoria de um processo ou produto que 
possam ser atingidos respondendo a última questão “posso melhorar o 
evento?”. (TRAVASSOS; GUROV; AMARAL, 2002, p. 5)
Conforme escritos de Zeviani (2018) planejar um experimento envolve, observar e 
descrever fenômenos, otimizar o custo-benefício, isolar efeito e determinar as relações 
e causas., produzir resultados confiáveis, a a validade de um experimento é afetada pela 
9
UNIDADE Processos de Condução de Estudos Experimentais
sua construção e execução, portanto, a atenção investida no delineamento experimental 
é importante.
Tabela 1 – Características Observacionais X Características Experimentais
Controle sob as condições de contorno não sim
Controle sob efeito de fatores indesejáveis não sim
Controle dos fatores sob investigação não sim
Determinar relações causais não sim
É o mais comum sim não
É o mais barato sim não
Fonte: Adaptada de ZEVIANI, 2018
Quando falamos de experimentação, devemos recorrer canonicamente a uma me-
todologia para projetar experimentos, e temos Ronald Fisher que escreveu dois livros 
sobre o tema em 1926 e 1935 sobre o desenho de experimentos que teremos que es-
tudar com certeza.
Pode-se resumir esses princípios da seguinte forma:
• Comparação: Em alguns campos de estudo, não é possível ter medições indepen-
dentes para um padrão de metrologia rastreável. As comparações entre os tratamen-
tos são muito mais valiosas e geralmente preferíveis, e muitas vezes comparadas com 
um controle científico ou tratamento tradicional que atua como linha de base;
• Aleatoriedade: Atribuição aleatória é o processo de atribuir indivíduos aleatoria-
mente a grupos ou a grupos diferentes em um experimento, de modo que cada indi-
víduo da população tenha a mesma chance de se tornar um participante do estudo. 
A atribuição aleatória de indivíduos a grupos, ou condições dentro de um grupo distingue 
um experimento “verdadeiro” rigoroso de um estudo observacional ou “quase-experimento”. 
Atribuir unidades a tratamentos aleatoriamente tende a mitigar confusão, que faz com 
que os efeitos devido a outros fatores além do tratamento pareçam resultar do tratamento.
Os riscos associados à alocação aleatória, como por exemplo, ter um sério desequilí-
brio em uma característica-chave entre um grupo de tratamento e um grupo de control; 
são calculáveis e, portanto, podem ser gerenciados até um nível aceitável usando unida-
des experimentais suficientes. 
No entanto, se a população for dividida em várias subpopulações que de alguma forma 
diferem, e a pesquisa exigir que cada subpopulação seja igual em tamanho, a amostragem 
estratificada pode ser usada. 
Dessa forma, as unidades em cada subpopulação são randomizadas, mas não a 
amostra inteira. 
Os resultados de um experimento podem ser generalizados de forma confiável a par-
tir das unidades experimentais para uma população estatística maior de unidades ape-
nas se as unidades experimentais forem uma amostra aleatória da população maior; o 
erro provável de tal extrapolação depende do tamanho da amostra, entre outras coisas.
10
11
• Replicação estatística: As medições estão geralmente sujeitas a variação e incer-
teza de medição; assim, são repetidos e experimentos completos são replicados 
para ajudar a identificar as fontes de variação, para melhor estimar os verdadeiros 
efeitos dos tratamentos, para fortalecer ainda mais a confiabilidade e a validade do 
experimento e para aumentar o conhecimento existente sobre o tópico;
• No entanto, certas condições devemser atendidas antes que a replicação do 
experimento seja iniciada: a questão de pesquisa original foi publicada em uma 
publicação revisada por pares ou o pesquisador é independente do experimento 
original, o pesquisador deve primeiro tentar replicar as descobertas originais usan-
do os dados originais e o artigo deve declarar que o estudo conduzido é um estudo 
de replicação que tentou seguir o original estudar tão estritamente quanto possível; 
• Bloqueando: trata-se do arranjo não aleatório de unidades experimentais em gru-
pos consistindo em unidades que são semelhantes entre si. O bloqueio reduz as fon-
tes de variação conhecidas, mas irrelevantes, entre as unidades e, assim, permite 
maior precisão na estimativa da fonte de variação em estudo;
• Ortogonalidade: diz respeito às formas de comparação que podem ser realizadas 
de forma legítima e eficiente. Os contrastes podem ser representados por vetores e 
os conjuntos de contrastes ortogonais não estão correlacionados e são distribuídos 
independentemente se os dados forem normais. Um experimento planejado é or-
togonal se os efeitos de qualquer fator compensarem (soma a zero) entre os efeitos 
dos outros fatores. A ortogonalidade garante que o efeito de um fator ou interação 
possa ser estimado separadamente a partir do efeito de qualquer outro fator ou 
interação no modelo.
Por causa dessa independência, cada tratamento ortogonal fornece informações 
diferentes para os outros. 
» Experimentos fatoriais: Uso de experimentos fatoriais em vez do método de um 
fator de cada vez. Estes são eficientes na avaliação dos efeitos e possíveis intera-
ções de vários fatores ou se preferir, variáveis independentes. 
 A análise do projeto do experimento é construída com base na análise de variân-
cia, uma coleção de modelos que particiona a variância observada em componen-
tes, de acordo com os fatores que o experimento deve estimar ou testar.
Os elementos principais do experimento são as variáveis, os objetos, os 
participantes, o contexto do experimento, hipóteses, e o tipo de projeto 
do experimento.
Há dois tipos de variáveis do experimento: dependentes e independentes. 
As variáveis independentes referem-se à entrada do processo de experi-
mentação. Essas variáveis também se chamam “fatores” e apresentam 
a causa que afeta o resultado do processo de experimentação. O pró-
prio valor de um fator se chama “tratamento”. As variáveis dependentes 
referem-se à saída do processo de experimentação. Essas variáveis apre-
sentam o efeito que é causado pelos fatores do experimento. O próprio 
valor de uma variável dependente se chama “resultado”. (TRAVASSOS; 
GUROV; AMARAL, 2002, p. 7)
11
UNIDADE Processos de Condução de Estudos Experimentais
Objetivos de experimento
Construção
causa-efeito
Construção
tratamento-resultado
Execução de experimento
Variável dependenteVariável independente
Observação
Teoria Causa Efeito
Tratamento Resultado
Figura 1 – Quadro conceitual de um experimento
Fonte: Adaptada de WOHLIN et al. 2012
Experimentos precisam de controle, como já vimos e são umas das principais necessidades.
Em engenharia de software devemos utilizar formas mais controladas de estudo, labo-
ratório, manipulação de variáveis, por exemplo:
O tempo gasto para desenvolver e testar algumas funções auxiliares usando:
• programação de pares vs. programação solo;
• realizar teste por último vs. testar primeiro.
Ambiente deve ser controlado, por exemplo:
• seleção de sujeitos (por exemplo, fundos semelhantes);
• curva de aprendizado;
• aplicação tanto para novatos (estudantes) quanto para programadores da indústria;
• randomização sobre os sujeitos.
Tudo deve ser reprodutível, por exemplo, funções e artefatos:
• Porque eles exigem menos tempo na execução;
• Os artefatos, principalmente, são produzidos apenas para o experimento;
• Porém, podem ser reutilizados em repetições de outros experimentos.
Validar reivindicações mais específicas, por exemplo:
• Avaliação do tempo gasto para alterar um pedaço de módulo usando mecanismos 
específicos de variabilidade;
• Medir a eficácia das métricas para detectar um problema determinado no design.
Para Oliveira; Leite; Cysneiros (2012), pesquisadores em Engenharia de Software 
afirmam que somente os experimentos, no centro do processo científico, podem verifi-
car novas teorias e, indicar as correções cabíveis e explorar os fatores críticos dessa nova 
teoria. Afirmam também que novos métodos, técnicas e ferramentas em Engenharia de 
Software não deveriam ser publicados sem antes serem experimentados, validados e 
comparados com os existentes.
Para a Engenharia de Software existem quatro métodos relevantes com a 
finalidade de condução de experimentos. São eles: (1) o método científico 
12
13
que retira do ambiente observado um modelo para definir o conjunto de 
propriedades que devem ser analisadas; (2) o método da engenharia que 
estuda as soluções já utilizadas e aplica alguma suposta evolução na ten-
tativa de achar uma vantagem adicional em relação às soluções iniciais; 
(3) o método analítico, ou matemático, que propõe uma teoria bem for-
malizada, obtém os resultados da aplicação da mesma e compara esses 
resultados com os resultados empíricos e (4) o método experimental que 
propõe e submete repetidamente o novo método a situações para observa-
ção do comportamento com o objetivo de comprovação e aprimoramento. 
O Processo de Experimentação possui dois subprocessos, o Processo de 
Execução e o Processo de Empacotamento. As finalidades das etapas do 
Processo de Experimentação são apresentadas a seguir. A etapa de defi-
nição vai expressar o experimento em termos de objetivos e problemas; a 
etapa de planejamento vai: determinar o projeto do experimento, definir a 
instrumentação a ser utilizada e analisar os aspectos de validação dos resul-
tados. A etapa de execução vai cuidar da coleta dos dados do experimento. 
E a etapa de análise e interpretação vai estudar detalhadamente os dados 
coletados. O processo possui dois pontos de controle, o primeiro existe 
para avaliar a necessidade de replanejar e o segundo existe para avaliar a 
efetividade da etapa de análise dos resultados. O Processo de Empacota-
mento faz a atividade de organizar e guardar as informações a respeito do 
Processo de Execução. (OLIVEIRA; LEITE; CYSNEIROS, 2012, p. 19-20)
Pacotes de Laboratório
As replicações de experimentos desempenham um papel central no método científi-
co. Embora a experimentação da engenharia de software tenha amadurecido muito, o 
número de replicações de experimentos ainda é relativamente pequeno. Os experimen-
tos de engenharia de software são compostos de conceitos, procedimentos e artefatos 
complexos. Os pacotes de laboratório são um meio de transferência de conhecimento 
entre pesquisadores para facilitar a replicação de experimentos.
Com um pacote de laboratório, um grupo externo de pesquisadores em engenharia 
de software pode reproduzir as configurações de uma linha de base. Características dos 
experimentos que podem estar impactando os resultados, como a linguagem de progra-
mação ou a duração da sessão experimental dos experimentos.
Talvez você esteja se perguntando, mas o que é linha de base? Será que é aquela que 
a gente utiliza em gestão de projetos?
Não, estamos falando de engenharia de software experimental, uma disciplina nova, 
tida como estado da arte em estudo de métodos e meios para se desenvolver software
melhor, vou te explicar.
Os dados da linha de base em pesquisa são um conjunto de informações frequente-
mente empregadas para comparar outros dados adquiridos posteriormente. Serve como 
base da maioria dos projetos de pesquisa. Daí, com certeza vem a sua próxima pergun-
ta; o que significa dados da linha de base? Bem, para estudar diferentes assuntos, os 
13
UNIDADE Processos de Condução de Estudos Experimentais
pesquisadores exigem um certo grau de informação prévia para estabelecer o escopo e 
o alcance de sua investigação.
Em um experimentocontrolado elabora-se um modelo similar a profissio-
nais construindo software. Os participantes, que os representam, aplicam 
a tecnologia sob investigação. Os dados produzidos pela execução permi-
tem que o desempenho seja avaliado, medido e comparado, considerando 
as condições sob as quais o experimento foi. A partir dos resultados de es-
tudos experimentais é construído um corpo de conhecimento, que além de 
prover um alicerce científico para a disciplina de Engenharia de Software, 
favorece a sua respectiva aplicação no mercado, apoiando em tomadas de 
decisão. Entretanto, apenas experimentos isolados não são suficientes para 
o estabelecimento desse corpo de conhecimento, por isso é preciso realizar 
replicações para fundamentar as conclusões obtidas com um nível maior 
de confiança. Quando outros pesquisadores replicam um experimento 
com sucesso, a confiança é construída nos procedimentos e nos resultados. 
Realizar uma replicação, que não seja de maneira completamente indepen-
dente do grupo de pesquisa responsável pelo experimento original, requer 
o acesso ao seu respectivo pacote de laboratório. O pacote de laboratório é 
um artefato que contém a descrição dos procedimentos adotados, o conhe-
cimento gerado, os resultados e as conclusões. Revisando essas informa-
ções, replicadores podem compreender como o experimento foi projetado, 
conduzido e analisado. Portanto, o pacote de laboratório consiste em um 
meio de transferência de conhecimento entre grupos de pesquisa de Enge-
nharia de Software. (SCATALON, 2013, p. 15)
As variáveis independentes influenciam na aplicação do objeto de estudo, pois como 
um experimento foca em entender o efeito da mudança em uma ou mais variáveis in-
dependentes. Assim, são chamados de tratamentos, os n valores que um fator possa vir 
a assumir. 
Caso venhamos a utilizar como fator uma forma de técnica, poderemos ter como tra-
tamento um teste estrutural e funcional, por exemplo, de tal forma que haverá variação 
no efeito desejado.
O efeito, nesse experimento dependerá da variável dependente (quantidade de de-
feitos), onde os valores dos resultados foram coletados, enquanto as variáveis indepen-
dentes são os inputs para rodar, assim com a variação desses valores a saída na variável 
dependente mudará.
Variável
dependente
Variáveis
independentes ..
.
Processo
Figura 2 – Esquema de blocos de um processo mostrando o fluxo das entradas através das variáveis 
independentes e o pós-processamento gerando a saída na variável dependente
 Fonte: Adaptada de WOHLIN et al. 2012
Scatalon (2012), reforça que, os tratamentos são aplicados a uma combinação de 
objetos e participantes, sendo que um objeto pode ser, os programas em que devem ser 
14
15
aplicadas as técnicas de teste, e os participantes são as pessoas que aplicam os trata-
mentos, ou seja, alimentam durante suas operações as variáveis independentes.
Experimentos
Agora que você já está adquirindo conhecimento e sabe a importância da engenharia 
de software experimental, talvez comece a perceber o poder de um pergunta bem-feita, 
cuja resposta nos impele a pesquisa para buscar a razão das coisas e acima de tudo a 
verdade imposta aquela situação.
Já deve ter percebido também que, afinal das contas, que os estudos experimentais 
tentam responder a perguntas experimentais. Por exemplo:
• Os “estereótipos” melhoram a compreensão dos diagramas UML?
• Os ‘padrões de design’ melhoram a manutenção do código?
• RUP é melhor que SCRUMBAN para ser usado em uma fábrica de software?
• O uso de ‘JUnit’ reduz o número de defeitos no código da indústria XPTO?
Ideia
De�nição
Planejamento
Operação
Análise e
Interpretação
Apresentação e
Empacotamento
Conclusão
Ex. Processo de um Experimento
Figura 3 – Exemplo de fases para um processo de experimento
Vamos a algumas decisões para dirimir qualquer dúvida futura, já que logo mais 
utilizaremos esse tipo de linguagem para nos referir a experimentos em engenharia 
de software.
• Objeto do estudo: é a entidade que é estudada no experimento. Por exemplo, códi-
go, processo, documentos de design etc. ;
• Propósito: Qual é a intenção do experimento? Por exemplo, avaliar o impacto de 
duas técnicas diferentes;
• Foco de qualidade: O efeito no estudo no experimento. Por exemplo, custo, con-
fiabilidade, correção etc.
15
UNIDADE Processos de Condução de Estudos Experimentais
Perspectiva: Ponto de vista a partir do qual os resultados do experimento são 
interpretados.
Contexto: O “ambiente” em que o experimento é executado.
Vejamos o exemplo no Quadro abaixo para materializar melhor o que queremos dizer:
Quadro 1 – Dados elementares sobre o que será estudado no experimento
Objeto do estudo • Código (C e C++) de aplicações tradicionais.
Propósito
• Avaliando se C++ é melhor que C (benefício de OO?), ou seja, se o 
número de defeitos em programas C++ for menor do que o número 
de defeitos no código C.
Foco de qualidade • (Qual efeito é estudado?): Correção do código.
Perspectiva
Múltipla.
• Pesquisador: avaliando qual linguagem é melhor;
• Gerente de projetos: escolha entre C e C++ em sua organização.
Contexto
• Disciplinas: Estudantes de Ciência da Computação;
• Objeto: uma aplicação simples;
• Encontre os primeiros números ‘n’ na sequência de Fibonacci
Precisamos em seguida planejar:
• A definição determina: “Por que o experimento é conduzido”;
• O planejamento determina: “Como o experimento será conduzido”.
Devemos afirmar claramente:
• Perguntas de pesquisa;
• Contexto (sujeitos e objetos);
• Variáveis;
• Métricas;
• Projeto do Experimento.
O resultado do experimento pode ser perturbado ou até mesmo destruído se não for 
planejado corretamente. 
Como atividades referentes ao planejamento, temos por exemplo:
• Seleção de contexto. Temos quatro dimensões a considerar:
 » off-line vs. on-line;
 » aluno vs. profissional;
 » modelos hipotéticos vs. problemas reais;
 » contexto específico, ou seja, apenas uma determinada indústria vs contexto geral.
• Formulação de hipóteses: A hipótese do experimento é declarada formalmente, 
incluindo uma hipótese nula ou hipótese alternativa;
16
17
• Seleção de variáveis: Determinar variáveis independentes (entradas) e variáveis depen-
dentes (saídas). O efeito dos tratamentos é medido por meio das variáveis dependentes ;
• Seleção de disciplinas: Para generalizar os resultados para a população desejada, 
a seleção deve ser representativa para essa população ;
O tamanho da amostra também impacta os resultados na generalização.
• Projeto de experimento: Como agrupar assuntos e como aplicar tratamentos a 
eles. Os métodos de análise estatística dependem do desenho escolhido:
» um fator com dois tratamentos;
» um fator com mais de dois tratamentos.
• Instrumentação: Nesta atividade são decididas orientações para orientar os partici-
pantes do experimento. O material é preparado e as métricas decididas, por exemplo:
» Treinamento;
» Questionários;
» Diagramas.
• Avaliação de validação, uma pergunta fundamental: quão válidos são os resul-
tados obtidos?
• Validação externa: o resultado do estudo pode ser generalizado fora do escopo 
do nosso estudo?
Aqui devemos tomar cuidado porque há várias armadilhas que podemos cair quanto 
a validade do experimento em engenharia de software, por exemplo:
• Experimento mal designado (materiais e equipamentos) ;
• Sujeitos não preparados para enfrentar o experimento (por exemplo, diretrizes ou 
instruções insuficientes) ;
• Ansiedade dos sujeitos (medo da avaliação, medo do resultado do experimento ser 
diferente do esperado na empresa, as vezes por causa do valor já investido) ;
• Os pesquisadores podem influenciar os resultados procurando um resultado espe-
cífico, ou seja, um problema clássico de viés de experimento ;
• Se o grupo é muito heterogêneo, há o risco de que a variação devido às dife-
renças individuais seja maior do que devido ao tratamento. Podemos inclusive 
termos algo relacionado ao que chamamos de: fatoresde confusão, por exemplo, 
variáveis não controladas ou consideradas desprezíveis erroneamente frente ao 
fenômeno. São situações geradas por:
» Tamanho amostral pequeno;
» Baixo poder estatístico.
Já definimos anteriormente hipótese, mas vamos trabalhar com um exemplo, levan-
do em consideração que 2 hipóteses ao menos devem ser formuladas em um experi-
mento em engenharia de software.
Duas hipóteses devem ser formuladas:
• A hipótese nula, deverá afirmar que não há tendências subjacentes reais no experi-
mento as únicas razões para diferenças em nossas observações são coincidência. Esta 
é a hipótese que o experimentador quer rejeitar com o maior significado possível ;
17
UNIDADE Processos de Condução de Estudos Experimentais
• A hipótese alternativa. Esta é a hipótese a favor da qual a hipótese nula é rejeitada.
No caso de nosso experimento sobre a comparação da linguagem C vs. C++, poderia 
ficar assim:
• hipótese nula: Os programas C++ contêm, em média, o mesmo número de defei-
tos dos programas C;
• hipótese alternativa: Os programas C contêm, em média, mais defeitos do que os 
programas C++.
As variáveis independentes (entradas) são aquelas variáveis que podemos controlar e 
mudar no experimento.
• Descrevem os tratamentos;
• Descrevem as variáveis para as quais os efeitos devem ser avaliados.
As variáveis dependentes (saídas) são as variáveis de resposta que descrevem os efei-
tos dos tratamentos descritos pelas variáveis independentes. Muitas vezes há apenas 
uma variável dependente e, portanto, deve ser derivada diretamente da hipótese.
Preste atenção aos fatores de confusão!
Não podemos esquecer das variáveis de confusão, que também são chamadas de 
confundidores ou fatores de confusão; elas estão intimamente relacionadas às variáveis 
independentes e dependentes de um estudo. Uma variável deve atender a duas condi-
ções para ser um fator de confusão: Deve ser correlacionada com a variável independen-
te. Pode ser uma relação causal, mas não precisa ser.
• Um fator de confusão: uma variável que pode esconder uma associação genuína 
entre fatores, pode confundir as conclusões do experimento. Por exemplo, pode 
ser difícil dizer se um resultado melhor depende da ferramenta ou da experiência 
do usuário da ferramenta.
Experimentos Controlados 
em Engenharia de Software
Precisamos para nos aprofundar um pouco mais nesse tema entender mais adequa-
damente os fatores de confusão.
Veja o exemplo na Figura abaixo:
Teste de Perfomance
Grupo de Controle
20 Devs JAVA 20 Devs PYTHON
Grupo Experimental
Figura 4 – Exemplo de um experimento totalmente confuso
Como diferentes linguagens foram utilizadas em cada grupo, há uma terceira variável 
que confunde o experimento e torna impossível atribuir causalidade.
18
19
Como regra geral, quando você está projetando um experimento, você quer ter um 
grupo experimental e um grupo de controle. Esses dois grupos devem ser idênticos, 
exceto que o grupo experimental deve receber algum formulário ou tratamento, o que 
chamamos de fator experimental ou variável experimental, enquanto o outro não deve 
receber nada.
Em outras palavras, os dois grupos devem ser totalmente idênticos, exceto para a 
variável experimental. 
Quando essa condição é atendida, você pode então inferir que as diferenças entre os 
dois grupos estão sendo causadas pela variável experimental. Em outras palavras, se os 
dois grupos são completamente e totalmente idênticos em todos os sentidos, exceto para 
variável experimental, então quaisquer diferenças na sua variável de resposta, sua variável 
dependente ou seja, a coisa que você está medindo deve estar sendo causada pela variável 
experimental, porque é a única coisa que difere entre os dois grupos. Mas você também 
pode ter vários grupos experimentais testando coisas diferentes simultaneamente, mas 
seria aumentar a complexidade a toa, portanto focaremos nesses dois grupos.
O problema é que, na realidade, ter dois grupos idênticos quase nunca é possível. 
É aí que entra o tema dos fatores de confusão.
Lembre-se: Um fator de confusão é simplesmente uma terceira variável que pode 
ter um efeito causal, impedindo assim que você seja capaz de atribuir causalidade.
Então em nosso exemplo logo acima, por causa de usar um grupo com JAVA e ou-
tro com PYTHON, teremos problemas certo?! Vê como isso funciona? Por causa dessa 
terceira variável (por exemplo em nosso grupo de controle, ou seja, JAVA), não há como 
atribuir com confiança a causalidade. Afinal não saberemos se Python performa melhor 
porque é uma linguagem relativamente mais nova ou se porque JAVA é muito formal, ou 
porque os Devs não foram bem escolhidos, veja quantas portas abertas para saírem “es-
queletos”. Ao menos os dois grupos deveriam utilizar a mesma linguagem, por exemplo.
Esse é obviamente um exemplo extremo, mas esse tipo de coisa acontece o tempo 
todo em experimentos reais, e pode ocorrer de maneiras muito sutis.
E mesmo que algo sutil mesmo, faça o pesquisador relevar ou ficar mais confiante do 
que devia, realmente pode fazer grandes diferenças em seus resultados, e quando você 
tem um experimento totalmente confuso como esse que usei para exemplificar, você 
simplesmente não pode atribuir causalidade. E aí... já era.
Então, como os engenheiros de software realmente lidam com isso? Afinal, fatores 
de confusão estão por toda parte, e ter dois grupos totalmente idênticos é virtualmente 
impossível. Felizmente, existem várias estratégias importantes para lidar com elas: elimi-
nando, randomizando, bloqueando e medindo.
Bom, seguindo o nosso exemplo lá em cima sobre performance entre JAVA e 
PYTHON, o negócio é o seguinte para eliminar fatores de confusão; poderíamos usar 
apenas uma linguagem para ambos os grupos, isso já retira a linguagem como fator de 
19
UNIDADE Processos de Condução de Estudos Experimentais
confusão. Mas não é o suficiente, gostaríamos de controlar a versão da linguagem que 
utilizaremos, qual o Sistema Operacional que utilizaremos e para qual versão, indo mais 
longe, que computadores, de qual marca, qual processador, com quais especificações, 
se usamos rede local, qual o cabeamento, quais os switchs e routers, quais as distâncias 
entre os pontos e o switch ou hub, a rede elétrica é estabilizada, há ruídos, o ambiente 
tem luz adequada, condicionamento de ar, há conforto ergonômico, e por ai vai.
Parece absurdo, muito pelo contrário, basicamente, a ideia é que se você pode remo-
ver uma variável do seu experimento, então você deve fazê-lo. Lembre-se, idealmente 
você quer que seus grupos sejam totalmente, 100% idênticos. Então, para fazer isso, 
você precisa eliminar o máximo de fatores de confusão que puder.
Então, mesmo depois de controlar todos os fatores de confusão que você pode pen-
sar, quase certamente ainda haverá alguma pequena variação que você não está ciente. 
Por exemplo, pode haver pequenas inconsistências nas habilidades de codificação dos 
Devs do experimento, mesmo que todos sejam Sêniores com 30 anos de experiência 
comprovada etc. Como você não sabe quais são essas diferenças, você não pode elimi-
ná-las, mas pode compensá-las aleatoriamente. Fazendo o que? 
Selecionando aleatoriamente quais vão para cada grupo. Assim, qualquer variação é 
dispersada aleatoriamente em seus dois grupos, em vez de cair desproporcionalmente 
em um grupo. Esta é uma ferramenta extremamente poderosa e importante que deve 
ser usada sempre que possível. Em qualquer experimento, você deve randomizar com-
pletamente sempre que possível.
Métodos Estatísticos e Análise de Dados 
em Engenharia de Software Experimental
Bem vamos para o próximo passo, lembremos que o objetivo de um estudo expe-
rimental é coletar dados em um ambiente controlado, a fim de confirmar ou descartar 
a hipótese. A hipótese refere-se a uma teoria que busca explicar um certo comporta-
mento de interesse, para a pesquisa, e leva à definição de variáveis independentes ou 
dependentes. As variáveis independentes representam