Elder Cirilo
Pontifícia Universidade Católica do Rio de Janeiro
Laboratório de Engenharia de Software
Projeto de Experimento Controlado com Quadrado Latino by Example
Conteúdo baseado na apresentação de Eduardo Aranha, 1º Encontro de Engenharia de Software Experimental 2011 - Natal
Objetivos
• Apresentar e motivar o uso de experimentos controlados baseados em engenharia de software baseados na técnica do quadrado latino.
• Ilustrar projetos de experimentos que utilizaram o quadrado latino como técnica de controle de fatores
• Ilustrar o processo de análise estatística em experimentos controlados baseados no quadrado latino.
Agenda
1. Exemplo ilustrativo
2. Experimentos controlados
3. Projetos estatísticos de experimento
– Plano completamente aleatorizado
– Plano aleatorizado em blocos completos
– Plano de quadrado latinos
4. Exemplos de experimentos baseados no quadrado latino
5. Análise estatística em projetos baseados no quadrado latino, utilizando a ferramenta R.
Exemplo Ilustrativo
• Como avaliar diferentes tecnologias de Model-based Testing (MBT)?
A B C
Contexto do Experimento
• Escolha a melhor tecnologia de MBT: A, B ou C
– Eficiência
– Efetividade
– Facilidade de Uso
– Facilidade de Manutenção
• Industria de Software
– Profissionais variado
– Projetos diferentes
– Recursos limitados
Requer resultados cientificamente embasados
• Avaliar MBT no uso de três projetos em andamento
– Escopo: projeto de testes – Visando minimizar os custos.
Projeto de Experimento Ilustrativo
Requisitos
Desenvolvedor
Abordagem A B C
Possíveis Resultados
• Tecnologia de MBT foi realmente a responsável pelos resultados?
• Se rodar o estudo em novos projetos, o resultado será o mesmo?
Projeto 1
10 15 20 25 30 40h
Projeto 2
10 15 20 25 30 40h
Projeto 3
10 15 20 25 30 40h
Como obter resultados mais relevantes?
• Controlar os elementos existentes no ambiente de execução do experimento.
– Elminar, reduzir ou diluir o efeito desses elementos
• Podemos controlar:
– ambiente de desenvolvimento
– experiência dos participantes
– complexidade do projeto
Projeto 1 – Controle do Ambiente
• Controle
– Um único projeto
– Um único desenvolvedor
• Uso de todas as técnicas
• Ordem no uso das técnicas
A B C1o 2o 3o
Considerações Sobre a Proposta
• Fixar projeto e desenvolver elimina alguns efeitos indesejáveis
– Complexidade do projeto
– Expertise e experiência dos diferentes desenvolvedores
– ...
• Existem algum efeito de aprendizado por parte do desenvolvedor?
• Treinamentos podem amenizar esse tipo de efeito, mas existem alguma outra ameaça associada ao projeto do experimento?
Projeto 2 – Controlando Aprendizagem
• Controle
– Mesmo perfil de desenvolvedor
– Interesse pessoal determina técnica
– Treinamento na abordagem escolhida
A B C
Considerações Sobre a Proposta
• Efeito dos requisitos continua eliminado
• Efeito do desenvolvedor voltou a existir
– Porém, foi reduzido ao se fixar perfil do participante
• Escolha de quem usa a técnica pode estar tendenciosa?
Projeto 3 – Evitando Viés
• Controle
– Mesmo perfil de desenvolvedor
– Sorteio determina técnica
– Treinamento na técnica sorteada
AB C
Considerações Sobre a Proposta
• Baixa probabilidade de ocorrer resultado tendencioso para o sorteio.
• É suficiente ter apenas uma observação para cada abordagem?
Projeto 4 – Aumentando Observações
• Número maior de desenvolvedores com mesmo perfil
• Sorteio da técnica a ser utilizada acompanhado de treinamento
AB CAB C
Experimento Controlado
• Procedimento que mudam de forma proposital as variáveis de um processo/sistema
• Observam mudanças na saída e identificar as causas
Processo/SistemaProcesso/SistemaEntradas Saída
Variáveis controladas
Variáveis não controladas(e possivelmente desconhecidas)
x1 x2 xn
…
z1 z2 zn
…
Coletam evidências contra hipótese
formulada
Coletam evidências contra hipótese
formulada
Princípios Fundamentais dos Experimentos Controlados
• Controle Local
– Eliminar, reduzir, diluir ou isolar o efeito de fatores de ruído
– Fixar certos níveis para variáveis não investigadas
• Ex.: experiência dos participantes, complexidade do projeto
• Replicação
– Aplicação de um tratamento em mais de uma unidade experimental
– Dilui efeito da variabilidade existente entre pessoas, projetos e artefatos similares
– Diminui chances de se obter resultados ao acaso
• Aleatorização
– Com réplicas, dilui o efeito de diferenças de motivação, experiência
– Elimina possível viés do pesquisador e reduz efeito de aprendizado
Análise de Causa-Efeito
• Possível apenas quando utilizado os princípios de réplica com aleatorização
• Estudos observaicionais ou quase-experimentos
– Ausência de aleatorização e/ou controle local
Como Analisar os Dados
• Como avaliar situações onde análise visual não mostra claramente se houve ou não melhora significativa?
• Será que com mais observações as conclusões mudariam?
Análise Estatísticas
Plano Aleatorizado em Blocos Completos
• Aplicado quando:
– Existem um fator não investigado com influência significante na variável de saída
– Não é possível ou interessante fixar um único nível para esse fator
• Bloco
– Grupo homogêno de unidades experimentais
– Aleatorização feita dentro dos blocos
Exemplo de Blocos em ES
• Nível de experiência em desenvolvimento
Baixo
Médio
Alto
Blocos(6 desenvolvedores)
18 participantes
…
…
…
Até que Ponto Poderemos Generalizar os Resultados?
• Resultado do experimento limitado a um único tipo de projeto
– Simples ou complexos
• Tamanho e complexidade de projetos na prática
Quadrados Latinos
• Aplicado quando:
– Existem dois fatores de ruído com influência significante na variável de saída
• Bloco
– Combinação de níveis dos dois fatores de ruído (linha, coluna)
• Número de participantes cresce significamente neste cenário.
Cruzamento Entre Experiência e Tamanho
AB
C
B
B
C
C
A
ARéplicas mudando-seDesenvolvedores e/ouprojetos
Tamanho do Projeto
Nível deExperiência
Limitações do Quadrado Latino
• Requer mesma quantidade de tratamento, linha e colunas
• Alguns quadrados precisam de mais de 2 réplicas
– Ex: quadrado de tamanho 2
Exemplo 1Cirilo, E. et al.
Quadrado Latino by Example
Empirical Evaluation
• Our main goal is to investigate whether different techniques for product line implementation influence the correct comprehension of the configuration knowledge.
• Similar to related efforts two dimensions were evaluated in the empirical evaluation:
– Correctness
– Time
Research Questions
• We distinguish the following research questions.
– RQ1: Does the availability of domain-specific models increase the correct comprehension of the configuration knowledge?
– RQ2: Does the availability of domain-specific models reduce the time that is needed to correctly comprehend the configuration knowledge?
– RQ3: Does the individual differences among the expertise of product line engineers impact on the correct comprehension of the configuration knowledge?
– RQ4: Which types of configuration knowledge comprehension task benefit most from the use of domain-specific and from other code-oriented techniques?
Hypotheses
• Associated to the first two research questions are two null hypotheses– H10: The correct comprehension of the configuration knowledge does
not depend on the different specification techniques.
– H20: The time to correctly comprehend the configuration knowledge does not depend on the different specification techniques.
• The alternative hypotheses are the following:
– H11: The correct comprehension of the configuration knowledge depends on the different specification techniques.
– H21: The time to correctly comprehend the configuration knowledge depends on the different specification techniques.
Empirical Evaluation
• Correct Answers and Time Analysis
– The correspondence between participant’s number of correct answers and tools/product lines
– The influence of each approach in the time that each participant spend answering the questionnaire.
• Expertise Analysis
– The influence of participant’s expertise in the number of correct answers
First Evaluation
• The study involved six post-graduate answering three questionnaires, one for each product line following the Latin Square Design
Participants E-Shop OLIS Buyer
P1 and P4 G+ PV C
P2 and P5 C G+ PV
P3 and P6 PV C G+
Which abstraction(s)/code
asset(s) is(are) related to the feature X?
Which abstraction(s)/code
asset(s) is(are) related to the feature X?
How many abstraction(s)/code
asset(s) is(are) mapped to the feature
Y?
How many abstraction(s)/code
asset(s) is(are) mapped to the feature
Y?
Product Lines vs. Correct Answers
Buyer - highest number of correct answersLowest number of feature and no diversity of frameworks
Buyer - highest number of correct answersLowest number of feature and no diversity of frameworks
Product Lines vs. Correct Answers
OLIS - intermediate number of correct answersWell modularized features
OLIS - intermediate number of correct answersWell modularized features
Product Lines vs. Correct Answers
E-Shop - lowest number of correct answersFeatures no-well modularized
E-Shop - lowest number of correct answersFeatures no-well modularized
Techniques vs. Correct Answers
CIDE - lowest number of correct answers in the E-Shop product line
CIDE - lowest number of correct answers in the E-Shop product line
Techniques vs. Correct Answers
pure::variants – better number of hits for the E-Shop product line than CIDE
pure::variants – better number of hits for the E-Shop product line than CIDE
Techniques vs. Correct Answers
CIDE – better number of hits for the OLIS product line than pure::variants
CIDE – better number of hits for the OLIS product line than pure::variants
Techniques vs. Correct Answers
✓
✓✗ ±
±
±
Techniques vs. Time
G+ PV C
e-Shop 1:35:47 1:43:29 1:33:45
OLIS 1:27:51 1:45:42 1:31:09
Buyer 0:43:05 1:17:42 1:14:42
• Time demanded to answer the questionnaire.
• Average time to correct answer a question.
G+ PV C
0:02:57 0:04:39 0:03:10
Participant’s Expertise
P1 P2 P3 P4 P5 P6
Spring 4 4 4 2 1 3
Struts 2 2 1 4 2 2
Spring MVC 4 4 4 5 3 5
Hibernate 1 1 1 1 4 1
iBatis 2 2 2 3 1 3
Spring-DM 1 1 1 1 1 1
Jadex 2 1 1 3 1 1
e-Shop 1.5 1.25 1 2.25 2 1
OLIS 3 3 2.75 3.5 1.75 3.25
Buyer 2 1 1 3 1 1
Expertise Results
Expertise Analysis
Statistical Results – Answers
11/04/23 43Nome do Autor © LES/PUC-Rio
chi-squared df p-value
Kruskal-Wallis 17.6812 14 0.2217
• Kruskal-Wallis
Statistical Results - Time
11/04/23 44Nome do Autor © LES/PUC-Rio
ANOVA DF Sum Sq Mean Sq F Value Pr(>F)
Tool 2 45259 22629.4 2.6310 0.1324
• ANOVA
Second Evaluation
• Our study involved fifteen post-graduate answering three questionnaires, one for each product line following the Latin Square Design
• Questions were devised into four different comprehensibility tasks:
– Identifying all files in which source code of a feature occurs
– Identifying all features that occurs in a certain file
– Identifying all framework-concept instances that are implementing a certain feature
– Investigating dependencies between framework-concept instances
Statistical Results – Answers
DF Sum Sq F Value Pr(>F)
Tools 2 24.808 18.3421 1.075e-05
• ANOVA
~26.28%
GenArch+
~34.53%
Statistical Results – Answers
diff lwr upr p adj
G,-C 1.526667 0.7805027 2.2728306 0.0000777
P,-C -0.48000 -1.2261640 0.2661640 0.2641892
P,-G -2.00666 -2.7528306 -1.2605027 0.0000013
• Tukey
~26.28%
GenArch+
~34.53%
Statistical Results – Time
chi-squared df p-value
Kruskal-Wallis 4.0495 2 0.1320
• Kruskal-Wallis
~19.41%
GenArch+
~62.65%
Individual Task Performance - Anwsers
50% 87%
Individual Task Performance - Time
5x
Exemplo 2Ribeiro, M. et al.
Quadrado Latino by Example
Empirical Evaluation
• To better understand the use of Emergent Interfaces in preprocessor-based software product lines in maintenance activity.
• Hypotheses
– H1: With and without Emergent Interfaces, developers spend on average the same time to complete a maintenance task involving feature dependences.
– H2: With and without Emergent Interfaces, developers commit on average the same number of errors when performing a maintenance task involving feature dependencies.
Design
• The study involved 24 under/post-graduate one for each product line following the Latin Square Design
Participants Bestlap Mobile Media
P1 … n EI Wout IE
P2 … n Wout IE EI
Collecting the metrics
• Eclipse plug-in that consists of two buttons
– Play/Pause
– Finish
Maintenance Tasks
• Implementation of a New requirement
– In the Best Lap, the game score be not only positive, but also negative.
– In the Mobile Media, subjects should replace the actual web images server for another one that is able to provide more and different image formats.
• Fixing of Unused-variable
Experiment Execution
• To make subjects ware of preprocessor, VSoC, Feature Dependencies, Emergent Interfaces, and Emergo, a one hour training was provided before running the experiment.
• One toy example, Jcacl, was used to explain these concepts and exemplify the task New requirement and Unused-variable
• They performed the experiment with 10 MSc/PhD students at Federal University of Pernambuco, Brazil (Round 2) and replicated the experiment with 14 undergraduate students at Federal University of Alagoas, Brazil (Round 3).
Data Interpretation
• New requirement task – Round 2
Data Interpretation
• New requirement task – Round 2
Data Interpretation
• New requirement task – Round 3
Data Interpretation
• New requirement task – Round 3
Data Interpretation
• Unused Variable – Time Penalty
Data Interpretation
• Unused Variable – Round 2
Data Interpretation
• Unused Variable – Round 2
Data Interpretation
• Unused Variable – Round 3
Data Interpretation
• Unused Variable – Round 3
Conclusions
• Question 1: Do Emergent Interfaces reduce effort during maintenance tasks involving feature code dependencies in preprocessor-based systems?
– We conclude that Emergent Interfaces reduce the time spent to accomplish the New- requirement task. Without them, subjects are 3 and 3.1 times slower.
– When considering the Unused-variable task, the time difference with and with- out Emergent Interfaces is smaller when compared to the New-requirement task. On average, subjects are 1.5 and 1.68 times slower without Emergent Inter- faces.
Conclusions
• Question 2: Do Emergent Interfaces reduce the number of errors during maintenance tasks involving feature code dependencies in preprocessor-based systems?
– The results show that, with Emergent Interfaces, subjects might be aware of feature dependencies. Hence, the probability of changing the impacted features increases, leading them to press the Finish button not rashly.
– Without Emergent Interfaces, subjects committed 84% and 81% of the errors.
– without Emergent Interfaces tend to write more feature expressions wrongly when compared to with Emergent Interfaces: 75% and 78%
Ferramenta R
Análise estatística em projetos baseados no quadrado latino
Ferramenta R
• Ferramenta para análise estatística gratuita
• Baseada na Linguagem R
– Utilização é realizada através de comando em um console
– Comandos realizados sobre dados ou resultados de função
– Dados podem ser dispostos em um vetor, matriz ou data frame.
• http://cran.r-project.org/
Ferramenta R
Repesentando Quadrado Latino
Replica, Estudante, EstudoDeCaso, Tecnica, Resposta
1, 1, bY, G, 6.60
1, 1, oL, C, 1.80
1, 1, eS, P, 4.10
1, 2, bY, P, 4.50
1, 2, oL, G, 6.10
1, 2, eS, C, 4.65
1, 3, bY, C, 8.00
1, 3, oL, P, 5.10
1, 3, eS, G, 6.90
2, 4, bY, G, 8.00
2, 4, oL, C, 2.10
2, 4, eS, P, 4.00
2, 5, bY, P, 4.60
2, 5, oL, G, 6.15
2, 5, eS, C, 5.15
2, 6, bY, C, 6.00
2, 6, oL, P, 4.90
2, 6, eS, G, 7.20
…
Comandos
• Carregando os dados
data.ql = read.table(file=”dados-resposta.txt",header = T)
attach(data.ql)
• Definindo elementos do quadrado latino
Replica <- factor(Replica.)
Estudante <- factor(Estudante.)
EstudoDeCaso <- factor(EstudoDeCaso.)
Tecnica <- factor(Tecnica.)
• Plotando os resultados
plot(Resposta~Tecnica,col="gray",
xlab="SPL Tool",ylab="Answers")
Comando – Teste de Variança
anova.ql = aov(Resposta~Replica+Estudante:Replica
+EstudoDeCaso+Tecnica)
summary(anova.ql)
kw <- kruskal.test(Resposta~Estudante+EstudoDeCaso
+Tecnica,data.ql)
•Verificar se amostra possui distribuição normal e mesma variança.
– Distribuição Normal: Shapiro-Wik
shapiro.test(Resposta)
•Se p-value > 0.05 = OK, a amostra é normal
– Mesma viriança: Levene
levene.teste(Resposta)
•Se p-value > 0.05 = OK, a amostra possui mesma variança
Comando – Comparações Multíplas
• ANOVA
– Método Tukey
fmTukey=TukeyHSD(anova.ql,"Tecnica")
fmTukey
• Kruskal
– Método Nemenyi-Damico-Wolfe-Dunn
oneway_test(Dificuldade ~ Tecnica, data = data.ql)
Elder Cirilo
Pontifícia Universidade Católica do Rio de Janeiro
Laboratório de Engenharia de Software
Projeto de Experimento Controlado com Quadrado Latino by Example
Conteúdo baseado na apresentação de Eduardo Aranha, 1º Encontro de Engenharia de Software Experimental 2011 - Natal