expvvt: uma ferramenta de apoio à condução de experimentos ... · sobrinha (e aﬁlhada) luana,...

ExpVVT: uma ferramenta de apoio àcondução de experimentos baseados em

documentos de requisitos.

Ubirajara Pacheco Maltez Junior

SERVIÇO DE PÓS-GRADUAÇÃO DO ICMC-USP

Data de Depósito: 23 de junho de 2006

Assinatura:

ExpVVT: uma ferramenta de apoio à condução de experimentosbaseados em documentos de requisitos

Ubirajara Pacheco Maltez Junior

Orientador: Prof. Dr. José Carlos Maldonado

Dissertação apresentada ao Instituto de Ciências Matemá-ticas e de Computação — ICMC/USP, como parte dos re-quisitos para obtenção do título de Mestre em Ciências –Ciências de Computação e Matemática Computacional.

USP - São CarlosJunho/2006

Agradecimentos

Inicialmente aos meus pais, Ubirajara e Marinalva pelo exemplo de vida que são. Pelocarinho, apoio, atenção e educação. Obrigado por tudo! À minha vó, Maria de Lourdes (inmemorian) pelo apoio à minha formação e educação. Ao meu irmão Márcio e à minha futurasobrinha (e afilhada) Luana, pelos momentos de distração, brincadeira e muita amizade. Aosmeus parentes que sempre estiveram presentes, mesmo à distância.

Ao meu orientador, Prof. Dr. José Carlos Maldonado, pela orientação, paciência e confiançadurante esse trabalho.

À minha namorada Erika pelo apoio, incentivo e compreensão durante esse período. Suapresença e apoio foram fundamentais.

Aos Prof. Dra. Sandra Fabbri, Prof. Dra. Ellen Barbosa e Prof. Msc. Rogério Garcia pelaajuda e sugestões.

À Simone pelo apoio na elaboração da interface gráfica. Ao André Rocha, grande amigoque sempre esteve presente motivando a elaboração deste trabalho.

Aos grandes amigos que fazem parte (ou estão agregados) ao LABES: Adenilso, Andrea,André Luís, André Rocha, Antonielly (Tonton), Alessandra, Auri, Camilinha, Darley, Débora,Edilson, Ellen, Elisa, Erika, Fabiano, Kicho, Luciana e Richard, Marcella, Marcelo Eler, Marco,Maris, Osnete, Otávio, Paula, Reginaldo, Rogério, Rosana, Sandra, Sandro (KLB), Stanley,Simone, Thaise, Tânia, Tati (AMIGA!) e Valter. Além dos outros amigos aqui em São Carlos,listando alguns: Claudião, Márcio e Alba, Pinho e Viviane, Cássio, Daniel, Marinho e o pessoaldo Judô.

Ao OBA, pelos e-mails de diversão durante esse período!Aos meus amigos de Salvador.À FAPESP pelo apoio financeiro.

i

Pois eu bem sei os planos que estouprojetando para vós, diz o Senhor;

planos de paz, e não de mal,para vos dar um futuro e uma esperança.

Jeremias 29:11

iii

Resumo

A criação e atualização de bases de conhecimentos com dados que com-provem, ou não, a eficácia de métodos, técnicas ou produtos de softwarepodem ser facilitadas por meio de estudos experimentais e suas replica-ções em diferentes contextos, para que a base de conhecimento possaser ampliada e consolidada. Porém, a condução dessas replicações gerauma grande quantidade de dados que devem ser coletados e armaze-nados, e posteriormente analisados, sendo que a gestão dessas infor-mações de forma manual é propensa a erros. Nesse contexto, o ProjetoReaders - um projeto de pesquisa colaborativa formado por pesquisado-res brasileiros e norte-americanos - no qual este trabalho está inserido,teve como objetivos principais desenvolver, validar, empacotar e con-solidar uma base de conhecimento sobre algumas técnicas, como porexemplo a PBR (Perspective Based Reading), que é uma técnica de lei-tura para detecção de defeitos em artefatos de software. Com as váriasreplicações de estudos experimentais que foram conduzidas no âmbitodesse projeto, em particular replicações do Experimento PBR (Basiliet al., 1996), ficou evidenciada a necessidade de apoio computacionalem diversas etapas do processo de experimentação. Sendo assim, nestetrabalho foi definida, modelada e implementada a ferramenta ExpVVTcom a finalidade de automatizar as atividades de Planejamento e Ope-ração do Experimento PBR. A ferramenta foi implementada com baseem uma estrutura de meta-tabelas, o que facilita possíveis alterações noâmbito desse experimento. Salienta-se que o Pacote de Laboratório, oqual contém todos os artefatos necessários para que um estudo experi-mental possa ser replicado, também fica armazenado eletronicamente,com o apoio da ferramenta, o que facilita o registro de sua evolução. Ouso da ferramenta foi explorado simulando-a com os dados de uma dasreplicações do Experimento PBR que foi conduzida no contexto do Pro-jeto Readers. Embora tenha sido apenas uma simulação, pode-se per-ceber o auxílio que essa ferramenta pode trazer para futuras replicaçõesdesse experimento, reduzindo os custos associados com todo materialnecessário para uma replicação e também guiando os participantes doexperimento, para que as atividades sejam feitas de forma mais contro-lada.

v

Abstract

The creation and update of knowledge bases with data that provide evi-dences of the efficacy, or non-efficacy, of software methods, techniquesor products can be facilitated by experimental studies and their repli-cations in diverse contexts, so that the knowledge base can grow andbe consolidated. However, replications generate great amount of datawhich must be collected, stored, and on later, analyzed, making thenon-automated management of such information very error-prone. Inthis context, the Readers Project – a collaborative research project for-med by Brazilian and North-American researchers – which this workis part of, has had as main goals the development, validation, packa-ging and consolidation of a knowledge base on some techniques, suchas PBR (Perspective Based Reading), which is a reading technique usedto defect detection in software artifacts. With the several replications ofexperimental studies that were conducted along this project, in particu-lar the replications of the PBR Experiment (Basili et al., 1996), it hasbecome evident the need of computational support in several activitiesof the experimentation process. Therefore, in this work, the ExpVVTtool was defined, designed and implemented with the goal to automatethe Planning and Operation activities of the PBR Experiment. The toolwas implemented based on a meta-table structure, which facilitates pos-sible evolutions in this experiment context. It is emphasized that the LabPackage, which contains all the necessary artifacts needed to replicatean experimental study, is also stored electronically, with the tool sup-port, which facilitates the tracing of its evolution. The tool’s use wasexplored simulating with data of some of the PBR Experiment replica-tions which were conducted at the Readers Project context. Althoughjust a single simulation took place, it can already be noticed the supportthat the tool can provide to future replications of this experiment, redu-cing the costs associated with every necessary material in a replicationand also guiding the experiment participants, so that the activities aremade in a more controlled way.

vii

Lista de Figuras

2.1 Princípios básicos de experimentação (adaptado de Wohlin et al. (2000)). . . . 92.2 Processo de experimentação adaptado de Wohlin et al. (2000) (Amaral, 2003). . 102.3 Processo de experimentação adaptado de Amaral (2003) (Garcia, 2003). . . . . 102.4 Visão geral da fase de definição (adaptado de Wohlin et al. (2000)). . . . . . . . 112.5 Visão geral da fase de planejamento (adaptado de Wohlin et al. (2000)). . . . . 122.6 Visão geral da fase de operação (adaptado de Wohlin et al. (2000)). . . . . . . . 142.7 Visão geral da fase de análise e interpretação (adaptado de Wohlin et al. (2000)). 152.8 Visão geral da fase de apresentação e empacotamento (adaptado de Wohlin et

al. (2000)). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.9 Replicações de um experimento: pacote de laboratório (Garcia, 2003). . . . . . 162.10 Arquitetura de apoio computacional ao processo de experimentação ((Projeto

Readers, 2004)). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.11 Visão geral da operação do SESE (Arisholm et al., 2002; Sjøberg et al., 2002). . 24

3.1 Resultados obtidos pelos grupos (Basili et al., 1996). . . . . . . . . . . . . . . 313.2 Resultados obtidos pelos participantes individualmente (Basili et al., 1996). . . 313.3 Cobertura obtida nas duas execuções pelas perspectivas no documento genérico

ATM (Basili et al., 1996). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.4 Cobertura obtida nas duas execuções pelas perspectivas no documento especí-

fico NASA_A (Basili et al., 1996). . . . . . . . . . . . . . . . . . . . . . . . . 323.5 Performance obtida por cada técnica e pelos pares combinados de técnicas (Dó-

ria, 2001). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.6 Comparativo das quatro replicações. . . . . . . . . . . . . . . . . . . . . . . . 43

4.1 Fases do processo experimental que há apoio da ferramenta ExpVVT. . . . . . 504.2 Arquitetura da ferramenta ExpVVT. . . . . . . . . . . . . . . . . . . . . . . . 524.3 Diagrama conceitual. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.4 Modelos físico e lógico da base de dados. . . . . . . . . . . . . . . . . . . . . 544.5 Diagrama de caso de uso do sistema. . . . . . . . . . . . . . . . . . . . . . . . 574.6 Diagrama de atividades referente ao workflow da condução de experimentos. . . 584.7 Diagrama de atividades referente ao planejamento do experimento. . . . . . . . 594.8 Diagrama de atividades referente à execução do experimento. . . . . . . . . . . 594.9 Mapa do caminho de navegação. . . . . . . . . . . . . . . . . . . . . . . . . . 604.10 Mapa do caminho de navegação de criação de experimento. . . . . . . . . . . . 614.11 Tela de autenticação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

ix

4.12 Tela de cadastro de usuário. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.13 Tela de cadastro de instituição. . . . . . . . . . . . . . . . . . . . . . . . . . . 644.14 Tela principal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.15 Tela de identificação do experimento. . . . . . . . . . . . . . . . . . . . . . . 664.16 Tela de definicao do experimento. . . . . . . . . . . . . . . . . . . . . . . . . 664.17 Tela de registro das hipóteses. . . . . . . . . . . . . . . . . . . . . . . . . . . 674.18 Tela de registro das variáveis e riscos à validade. . . . . . . . . . . . . . . . . . 684.19 Tela de seleção de participantes. . . . . . . . . . . . . . . . . . . . . . . . . . 694.20 Tela de upload do documento de requisito. . . . . . . . . . . . . . . . . . . . . 704.21 Tela na qual define-se a lista inicial de defeitos. . . . . . . . . . . . . . . . . . 704.22 Tela na qual adiciona defeito a lista inicial de defeitos. . . . . . . . . . . . . . 714.23 Tela na qual define-se a técnica utilizada em contra-partida com a PBR. . . . . 714.24 Tela na qual definem-se as perspectivas PBR. . . . . . . . . . . . . . . . . . . 724.25 Tela de upload do treinamento. . . . . . . . . . . . . . . . . . . . . . . . . . . 724.26 Tela de definição do projeto experimental. . . . . . . . . . . . . . . . . . . . . 734.27 Tela com a lista de defeitos reportados. . . . . . . . . . . . . . . . . . . . . . . 744.28 Tela com a lista de defeitos reportados. . . . . . . . . . . . . . . . . . . . . . . 744.29 Tela com a visualização de um experimento. . . . . . . . . . . . . . . . . . . . 754.30 Tela com a importação de documentos XML. . . . . . . . . . . . . . . . . . . 75

x

Lista de Quadros

2.1 Quadro comparativo dos tipos de estudos experimentais (Wohlin et al., 2000). . 72.2 Quadro comparativo das ferramentas apresentadas. . . . . . . . . . . . . . . . 19

3.1 Quantidade de páginas e de defeitos nos documentos utilizados no ExperimentoPBR (Basili et al., 1996). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2 Projeto experimental do Experimento PBR (Basili et al., 1996). . . . . . . . . . 293.3 Projeto experimental do Experimento PBR (Basili et al., 1996). . . . . . . . . . 353.4 Projeto experimental aplicado por Dória (2001). . . . . . . . . . . . . . . . . . 373.5 Projeto experimental - R2 (Höhn, 2003). . . . . . . . . . . . . . . . . . . . . . 393.6 Projeto experimental - R3 (Höhn, 2003). . . . . . . . . . . . . . . . . . . . . . 413.7 Projeto experimental - R4 (Höhn, 2003). . . . . . . . . . . . . . . . . . . . . . 423.8 Projeto experimental - P1 (Höhn, 2003). . . . . . . . . . . . . . . . . . . . . . 453.9 Projeto experimental - P2 (Höhn, 2003). . . . . . . . . . . . . . . . . . . . . . 463.10 Evolução do pacote de laboratório PBR . . . . . . . . . . . . . . . . . . . . . 47

xi

Sumário

1 Introdução 11.1 Contexto e motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Organização do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Estudos experimentais 52.1 Considerações iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Estudos experimentais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Processo de experimentação . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.1 Definição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.2 Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.3 Operação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3.4 Análise e interpretação . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3.5 Apresentação e empacotamento . . . . . . . . . . . . . . . . . . . . . 152.3.6 Replicação de experimentos . . . . . . . . . . . . . . . . . . . . . . . 15

2.4 Ferramentas de apoio a estudos experimentais . . . . . . . . . . . . . . . . . . 182.5 Considerações finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3 O Experimento PBR 273.1 Considerações iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2 Experimento original PBR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.1 Pacote de laboratório original do Experimento PBR . . . . . . . . . . . 333.3 Replicações do Experimento PBR . . . . . . . . . . . . . . . . . . . . . . . . 35

3.3.1 Primeira replicação (R1) . . . . . . . . . . . . . . . . . . . . . . . . . 363.3.2 Segunda replicação (R2) . . . . . . . . . . . . . . . . . . . . . . . . . 383.3.3 Terceira replicação (R3) . . . . . . . . . . . . . . . . . . . . . . . . . 403.3.4 Quarta replicação (R4) . . . . . . . . . . . . . . . . . . . . . . . . . . 423.3.5 Aplicação do Experimento PBR na indústria . . . . . . . . . . . . . . 443.3.6 Síntese das mudanças e vantagens do apoio computacional . . . . . . . 47

3.4 Considerações finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4 A ferramenta ExpVVT 494.1 Considerações iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.2 Objetivos da ferramenta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

xiii

xiv

4.3 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.4 Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.4.1 Modelo conceitual . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.4.2 Base de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.4.3 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.4.4 Diagrama de caso de uso . . . . . . . . . . . . . . . . . . . . . . . . . 564.4.5 Diagrama de atividades . . . . . . . . . . . . . . . . . . . . . . . . . . 584.4.6 Mapa do caminho de navegação . . . . . . . . . . . . . . . . . . . . . 59

4.5 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.6 Aspectos operacionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624.7 Considerações finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5 Conclusão 795.1 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805.2 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Referência Bibliográfica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

A Script SQL de criação da base de dados 91

B Document Type Definition dos documentos XML 111

CAPÍTULO

1Introdução

Estudos experimentais em Engenharia de Software, como em outras áreas, viabilizam a co-leta de dados, análise e melhoria das técnicas e processos estudados, visando a fornecer o graude credibilidade necessário para validar esses dados, a conhecer os custos e benefícios associ-ados e a consolidar uma base de conhecimento. Essa base de conhecimento pode ser facilitadapor meio de estudos experimentais coordenados com os idealizadores do experimento original,pois além de propiciar a redução de custos, aumentar a qualidade das replicações e possibilitara generalização dos resultados, um estudo coordenado propicia também a transmissão do co-nhecimento tácito e explícito. No entanto, apesar das vantagens dessas ações coordenadas, seusbenefícios devem ser balanceados com os possíveis viéses que podem ser introduzidos comesse tipo de estudo, como por exemplo, se não houver uma independência que permita umaavaliação crítica do experimento e sua possível evolução (Mendonça et al., 2006).

Assim, a elaboração de experimentos que sirvam como base para a coleta de tais dados esua respectiva replicação em condições controladas são necessárias. A replicação e os estudoscomplementares são encorajados pela disponibilidade de pacotes de laboratório que documen-tam um experimento (Amaral e Travassos, 2002). O apoio automatizado ao planejamento e àcondução de replicações são pontos fundamentais nesse contexto.

Com o intuito de ampliar e consolidar a base de conhecimento gerada a partir das replica-ções de experimentos, algumas iniciativas têm sido tomadas. O Center for Empirically-Based

Software Engineering (CeBASE) (CeBASE, 2005) foi organizado para dar apoio às organiza-ções de software reunindo modelos experimentais para fornecer guias validados de seleção detécnicas e modelos, para recomendar áreas de pesquisa e para dar apoio ao ensino de Engenhariade Software.

1

2 CAPÍTULO 1. INTRODUÇÃO

A International Software Engineering Research Network (ISERN) (ISERN, 2005) é umarede que agrega pesquisadores que acreditam que a pesquisa em Engenharia de Software pre-cisa ser executada em um contexto experimental. Assim, é possível observar e experimentar astecnologias em uso, e compreender seus pontos fortes e fracos, podendo adaptar essas tecno-logias às características particulares dos projetos e empacotá-las juntamente com a experiênciaobtida para aumentar o reúso em projetos futuros.

Salienta-se que a gestão do conhecimento associada a estudos experimentais pode impactaro processo de experimentação no que diz respeito à interação dos replicadores com os idealiza-dores do estudo original, determinando algumas alternativas diferenciadas na execução de umareplicação, como será mencionado posteriormente neste trabalho.

1.1 Contexto e motivação

Várias iniciativas de estudos experimentais nas mais diversas áreas da computação são iden-tificadas (Basili et al., 1996; Belgamo, 2004; Belgamo et al., 2005; Dória, 2001; Höhn, 2003;Pfahl et al., 2003; Sjøberg e Rekdal, 2005; Thelin, 2003; Thelin et al., 2004; Travassos et al.,1999). Na área de Verificação, Validação e Teste (VV&T), mais especificamente, existe umsignificativo esforço no desenvolvimento de estudos experimentais objetivando investigar quaistécnicas são mais adequadas e efetivas, em determinadas circunstâncias, para descobrir erros ecomo essas técnicas podem ser utilizadas de forma complementar (Basili e Selby, 1987; Dória,2001; Myers, 1978).

Entre essas iniciativas está o Projeto Readers, um projeto de pesquisa colaborativa formadopor pesquisadores brasileiros (Universidade de São Paulo - USP/ICMC, Universidade Federalde São Carlos - UFSCar, Universidade Federal do Rio de Janeiro - UFRJ/COPPE, UniversidadeSalvador e ParqTec São Carlos) e norte-americanos (University of Maryland) com o apoio doConselho Nacional de Desenvolvimento Científico e Tecnológico (CNPq) e National Science

Foundation (NSF). O projeto teve como objetivos principais desenvolver, validar, empacotare consolidar uma base de conhecimento de famílias de técnicas de leitura para detecção dedefeitos em artefatos de software. As principais metas desse projeto foram:

1. Criar tecnologias para apoiar a detecção de defeitos em diferentes tipos de documentosde software e desenvolver métodos empíricos que possam contribuir para melhorar essastecnologias para diferentes ambientes e contextos culturais;

2. Desenvolver métodos de avaliação que possam comparar diversas tecnologias de detecçãode defeitos em contextos industriais e acadêmicos;

3. Expandir a base tecnológica de análise de software criando novos pacotes de laboratóriosque possam ser reutilizados e adaptados por outros pesquisadores baseando-se em seusambientes e necessidades culturais.

1.1. CONTEXTO E MOTIVAÇÃO 3

No contexto do Projeto Readers foram conduzidos experimentos para explorar técnicas paradetecção de defeitos no nível de código (Dória, 2001; Felizardo, 2003), no nível de projetoorientado a objetos (Belgamo, 2004; Belgamo et al., 2005; Travassos et al., 2002b) e no nível deespecificação (Dória, 2001; Höhn, 2003). Neste último caso, que mais interessa a este trabalho,foram exploradas as técnicas PBR (Perspective Based Reading) que auxiliam o inspetor a lero documento sob um determinado ponto de vista (do usuário, do projetista ou do testador) eo Checklist. Para integrar um volume significativo de resultados foram necessárias replicaçõesdos experimentos, utilizando pacotes de laboratório.

A condução de replicações implica um extenso trabalho manual, tanto da parte dos pesqui-sadores, principalmente na preparação do material para o experimento e na análise dos dados,quanto dos participantes, durante a fase de operação do experimento. Todo esse trabalho ma-nual com grande volume de informações consome muito tempo, o que dificulta a execução deuma grande quantidade de replicações, além de poder levar à ocorrência de erros, o que podecomprometer os resultados.

Algumas ferramentas de apoio computacional a estudos empíricos (com destaque à experi-mentação) foram propostas (Arisholm et al., 2002; Felizardo, 2003) com o intuito de facilitaro planejamento, coleta e análise dos dados obtidos de experimentos. Porém, essas ferramentassão específicas para um experimento ou não apóiam todas as etapas do processo experimen-tal definido por Wohlin et al. (2000), auxiliando muitas vezes somente a instrumentação dosartefatos utilizados e execução do experimento.

No âmbito do Projeto Readers, iniciativas de automação foram realizadas. A ferramentaCOTEST (COde Testing Experiment Support Tool) foi desenvolvida com o objetivo de apoiar areplicação de experimentos baseados em código fonte (Felizardo, 2003; Felizardo et al., 2003).Também foram desenvolvidas: (1) uma ferramenta de apoio à aplicação das Técnicas de Lei-tura Baseadas em Perspectiva (PBR) (Silva, 2004); (2) uma ferramenta de construção de casosde uso para utilização na técnica de leitura PBR; e (3) uma infra-estrutura de suporte ao pro-cesso de inspeção de software (ISPIS) (Kalinowski, 2004). Para integração dessas e de outrasferramentas foi projetada uma arquitetura utilizando XML (Spínola et al., 2004). Também foidesenvolvida uma ferramenta propondo apoio automatizado à configuração e aplicação de téc-nicas de leitura de projetos orientados a objetos (OORTs) (Reis, 2003).

Nesse contexto, motiva-se o suporte ao processo de experimentação com um ambiente au-tomatizado, facilitando o planejamento do experimento e a coleta e análise dos dados, viabili-zando assim maior número de replicações e maior confiabilidade nos dados obtidos. Nessa pers-pectiva, o presente trabalho está em consonância com os objetivos gerais do Projeto Readers,pois objetiva apoiar a realização de experimentos por meio de um ambiente computacional au-tomatizado.

4 CAPÍTULO 1. INTRODUÇÃO

1.2 Objetivos

O objetivo deste trabalho é a definição e implementação de uma ferramenta de apoio à con-dução de experimentos baseados em documentos de especificação de requisitos em linguagemnatural, fornecendo apoio computacional às etapas de planejamento e operação do processo deexperimentação. Objetiva-se também que a ferramenta forneça apoio à formação de uma basede conhecimento. Em específico, aborda-se o Experimento PBR (Basili et al., 1996).

1.3 Organização do trabalho

Neste capítulo foi apresentado o contexto em que o trabalho está inserido, a motivação parao desenvolvimento do mesmo e o objetivo a ser atingindo. No Capítulo 2 contextualizam-se estudos experimentais em Engenharia de Software, detalhando o processo experimental, anecessidade de replicação de experimentos e apresentando algumas ferramentas de apoio exis-tentes. No Capítulo 3 é exemplificado o processo experimental apresentando o experimentobaseado em documentos de especificação de requisitos em linguagem natural, e as replicaçõesrealizados pelo ICMC/USP e UFSCar no contexto do Projeto Readers, além da replicação doexperimento no âmbito industrial. No Capítulo 4 é apresentada a ferramenta ExpVVT, desen-volvida no escopo deste trabalho, as decisões relativas à sua modelagem, implementação e as-pectos operacionais. No Capítulo 5 são apresentadas as contribuições desta pesquisa e trabalhosfuturos.

CAPÍTULO

2

Processo de experimentação emEngenharia de Software

2.1 Considerações iniciais

Considerando-se o objetivo deste trabalho, que envolve a construção de uma ferramentaque apóie a condução e replicação de experimentos controlados, introduz-se neste capítulo osconceitos básicos e a importância da condução de estudos experimentais em Engenharia deSoftware. Inicialmente, na Seção 2.2, são apresentados os tipos de estudos experimentais. Emseguida, na Seção 2.3, é detalhado o processo de condução de experimentos controlados, alémde descrever os tipos de replicação. Algumas ferramentas de apoio à condução de experimentossão apresentadas na Seção 2.4.

2.2 Estudos experimentais

Estudos experimentais são importantes em Engenharia de Software quando se busca obterresultados objetivos e significativos em relação à compreensão, controle, prognóstico e melhorianos processos de desenvolvimento de software (Wohlin et al., 2000).

Conforme Wohlin et al. (2000), existem três tipos de estudos em Engenharia de Software:pesquisa de opinião, estudo de caso e condução de experimentos controlados. A seguir sãoexplicados cada tipo de estudo.

5

6 CAPÍTULO 2. ESTUDOS EXPERIMENTAIS

• Pesquisa de Opinião (Survey): Pesquisas de opinião são geralmente investigações realiza-das em retrospecto, quando, por exemplo, uma técnica ou ferramenta já está em uso. Es-sas são feitas por meio de amostragem, representando a população a ser estudada, sendoque os resultados são analisados e generalizados para a população da qual se extraiu aamostra.

As pesquisas de opinião são realizadas quando se tem por objetivo estar apto a afirmaralgo sobre uma população – nesse caso é uma pesquisa descritiva; ou quando se pretendesustentar explicações sobre uma população – pesquisa explicativa; ou ainda como pré-estudo para uma investigação mais completa – pesquisa explorativa.

Os meios básicos para coleta de dados são:

� Questionários: Podem ser realizados por meio eletrônico (e-mail, páginas Web) oupor meio tradicional utilizando papel. Os participantes da pesquisa devem receber,junto com o questionário, as instruções de como preenchê-lo;

� Entrevistas: Entrevistadores realizam a pesquisa aplicando os questionários elabora-dos. Entrevistas oferecem algumas vantagens como diminuir o número de questõessem resposta, pois o entrevistador pode vir a esclarecer dúvidas sobre o questionárioque está sendo aplicado. Uma desvantagem deste meio de coleta é o custo e o tempogasto na pesquisa.

Pesquisa de opinião é um tipo de estudo utilizado com freqüência em ciências sociais.Ela não oferece nenhum controle sobre a execução ou medição, entretanto é possívelcompará-la com outras pesquisas similares, mas não é possível manipular variáveis comoem outros tipos de estudos.

• Estudos de caso: Usados para monitorar projetos, atividades ou tarefas, geralmente obje-tivando rastrear um atributo específico ou estabelecer relações entre atributos diferentes.Bastante utilizado em ciências como sociologia, medicina e psicologia.

O investigador coleciona informações detalhadas durante um período contínuo de tempo.Durante a realização de um estudo de caso, pode ser aplicada uma variedade de proce-dimentos de coleta de dados diferentes e, após a coleta, os dados podem ser analisadosestatisticamente.

O nível de controle é mais baixo em um estudo de caso do que em um experimento, porser um estudo observacional. Além disso os resultados de um estudo de caso são maisdifíceis de interpretar e generalizar, ou seja, é possível mostrar os resultados em umasituação previsível, mas eles não podem ser generalizados para todas as situações.

• Experimentos Controlados: São investigações formais, conduzidas de forma rigorosa econtrolada.

2.2. ESTUDOS EXPERIMENTAIS 7

Em um experimento controlado selecionam-se objetos representando uma variedade decaracterísticas (que serão as variáveis do experimento) e projeta-se a pesquisa para medirmais de um valor para cada característica, os quais serão comparados depois.

O objetivo de um experimento é manipular uma ou mais variáveis e controlar as outrasvariáveis em valores fixos. O efeito desta manipulação é medido e analisado estatistica-mente e com técnicas de visualização (Garcia, 2003).

Experimentos são apropriados para investigar diferentes aspectos, como: (i) confirmarteorias; (ii) testar concepções de pessoas; (iii) explorar relações; e (iv) avaliar a precisãode modelos e validar medidas.

Supõe-se que a abordagem mais apropriada para a experimentação em Engenharia deSoftware seja o método experimental que considera a proposição e avaliação do modelocom os estudos experimentais. Entretanto, às vezes é necessário a aplicação de outrosmétodos de pesquisa para a resolução de problemas de Engenharia de Software (Travas-sos et al., 2002a). Por exemplo, o método científico pode ser utilizado para compreendera maneira como um software está sendo desenvolvido; o método de engenharia ajuda ademonstrar que uma ferramenta possui um desempenho melhor do que outra; e o mé-todo analítico pode provar modelos matemáticos para conceitos, como o crescimento daconfiabilidade e a complexidade do software.

Uma comparação dos tipos de estudos experimentais pode ser vista no Quadro 2.1.

Quadro 2.1: Quadro comparativo dos tipos de estudos experimentais (Wohlin et al., 2000).

Característica Pesquisa Estudo de Caso ExperimentoControle da execução Não Não SimControle da medição Não Sim SimControle da investigação Baixo Médio AltoFacilidade de replicação Alta Baixa AltaCusto Baixo Médio Alto

Há diversos fatores que ajudam a decidir entre executar um estudo de caso ou um experi-mento controlado. O fator central é o nível de controle necessário para o estudo. Quando se temum controle alto sobre as variáveis, que podem afetar a veracidade das hipóteses, então deve-seconsiderar a execução de um experimento. Se não existe esse controle é preferível a execuçãode um estudo de caso.

Mesmo sendo possível controlar as variáveis, na escolha do tipo de estudo experimental a serutilizado deve-se levar em consideração o nível de dificuldade, custo e risco para efetuá-lo. Umoutro aspecto a ser considerado é a viabilidade de replicar a situação básica sob investigação.Se a replicação não é possível, ou se seu custo é proibitivo, então um experimento controladopode não ser recomendado (DESMET, 1994).


Muitos grupos vêm adotando experimentos controlados em Engenharia de Software e algunsexemplos de experimentos conduzidos são:

• Técnicas de leitura para inspeção de projetos orientado a objeto (Conradi, 2000; Marucci,2002; Travassos et al., 2002b, 1999).

• Padrões de projeto (Prechelt, 1997; Prechelt et al., 2001; Vokác et al., 2004).

• Programação orientada a aspectos (Avdicausevic et al., 2001; Coady et al., 2000).

• Reengenharia (Cagnin et al., 2003a,b).

• Baseado em código fonte (Basili e Selby, 1987; Dória, 2001; Hetzel, 1976; Kamsties eLott, 1995; Myers, 1978).

• Baseado em documentos de especificação de requisitos em linguagem natural (Basili etal., 1996; Dória, 2001; Höhn, 2003).

No Capítulo 3 será detalhado o experimento Baseado em Documentos de Especificação deRequisitos em Linguagem Natural de Basili et al. (1996), denominado Experimento PBR, e asreplicações desse experimento realizadas pelo ICMC/USP e UFSCar no contexto do ProjetoReaders, pois a ferramenta desenvolvida neste trabalho apóia a condução desse experimento.

2.3 Processo de experimentação

Quando há uma relação de causa e efeito que se quer analisar, tem-se uma teoria ou pode-seformular uma hipótese. Um experimento controlado pode ser elaborado com a finalidade deavaliar essa teoria ou hipótese (Wohlin et al., 2000). Os princípios básicos de um experimentocontrolados são ilustrados na Figura 2.1.

Quando o projeto do experimento está sendo desenvolvido, deve-se determinar as variáveisdo experimento. Há dois tipos de variáveis: independentes e dependentes. Todas as variáveisque são manipuladas e controladas são chamadas variáveis independentes (ou de entrada, ouainda, variáveis de estado). As variáveis nas quais se observa o efeito das mudanças das va-riáveis independentes são chamadas variáveis dependentes (ou variáveis de resposta, ou ainda,variáveis de saída).

Um experimento estuda o efeito de mudar uma ou mais variáveis independentes, as quaispassam a ser chamadas fatores. As outras variáveis independentes são controladas em um nívelfixo durante o experimento, para que não interfiram no efeito dos fatores.

Um valor particular de um fator é conhecido como tratamento. Os tratamentos podem sermétodos, técnicas, ferramentas ou outras condições para os quais o efeito está sendo estudado.

2.3. PROCESSO DE EXPERIMENTAÇÃO 9

Teoria

Tratamento

Causa

Resultado

Efeito

Objetivos doexperimento

Construçãocausa-efeito

Construçãotratamento-resultado

Observação

Execução de experimento

Variável independente Variável dependente

Figura 2.1: Princípios básicos de experimentação (adaptado de Wohlin et al. (2000)).

Os tratamentos são aplicados à combinação de objetos (artefatos utilizados) e participantes(pessoas que aplicam o tratamento).

Um experimento consiste em um conjunto de testes, no qual cada teste é uma combinaçãode tratamento, participante e objeto. Após a execução do experimento, testes estatísticos são re-alizados entre a relação tratamento e resultado. Se o experimento foi bem elaborado, é possívelinferir a relação de causa e efeito para a qual foi declarada a teoria ou hipótese.

O processo de experimentação é dividido em cinco fases, conforme Wohlin et al. (2000).

• Definição ⇒ Apresenta o experimento em termos de problemas e objetivos;

• Planejamento ⇒ Ocorre a preparação do experimento, sendo elaborado nesta fase o pro-jeto experimental, além da avaliação dos riscos à validade do mesmo;

• Operação⇒ Fase na qual ocorre a execução do que foi planejado, coletando-se os dados;

• Análise e interpretação⇒ Os dados coletados na fase anterior são analisados e avaliados;e

• Apresentação e empacotamento ⇒ Divulgação dos resultados obtidos e disponibilizaçãodo material utilizado para futuras replicações.

Amaral (2003) propôs uma alteração do processo definido por Wohlin et al. (2000), suge-rindo que a atividade de empacotamento ocorresse paralelamente a todas as fases e não somenteno final do processo, como é ilustrado na Figura 2.2 (Amaral, 2003). Como pode ser observado,


Definição Planejamento OperaçãoAnálise e

Interpretação

Apresentação e Empacotamento

? ?

Base de Experimento

Figura 2.2: Processo de experimentação adaptado de Wohlin et al. (2000) (Amaral, 2003).

depois de coletados, todas as informações são armazenadas em um repositório (Amaral e Tra-vassos, 2003).

Está em estudo, no escopo de um trabalho de doutorado (Garcia, 2003), uma modificaçãonesse processo, com a finalidade de atender às necessidades impostas pela inserção da AnáliseExploratória nesse processo. É proposto que uma atividade colocada inicialmente como parteda Análise Estatística tradicional deva ser tratada à parte, como mostrado na Figura 2.3.

Definição Planejamento Operação Análise e Interpretação


? ?

Base de Experimento

Pré-Análise

Figura 2.3: Processo de experimentação adaptado de Amaral (2003) (Garcia, 2003).

2.3.1 Definição

Na fase de definição são enunciados os objetivos do experimento, apresentando com clarezaas hipóteses para o experimento. Esta delineação dos objetivos é ilustrada na Figura 2.4.

Para facilitar a captura das informações necessárias na definição de experimento um modelode metas foi sugerido (Briand et al. (1997) apud Wohlin et al. (2000)):


Idéia doexperimento

Fase de definição

Define oexperimento

Definição doexperimento

Figura 2.4: Visão geral da fase de definição (adaptado de Wohlin et al. (2000)).

• Analisar <objeto de estudo>

• Para o propósito de <propósito>

• Com respeito a <enfoque>

• Do ponto de vista da <perspectiva>

• No contexto <contexto>

O objeto do estudo é a entidade que é analisada. Podem ser produtos, processos, teorias,modelos etc. O propósito consiste na intenção do experimento, por exemplo, analisar o impactode duas técnicas diferentes. O enfoque é o efeito estudado, podendo ser custo, eficácia etc. Aperspectiva determina sob qual ponto de vista os resultados serão interpretados. E, por fim, ocontexto mostra o ambiente no qual o experimento está sendo conduzido, definindo o perfil dosparticipantes e caracterizando os artefatos de software usados.

2.3.2 Planejamento

Enquanto a fase de definição determina o porquê de se executar o experimento, a fase deplanejamento determina como ele é conduzido. Nessa fase ocorre a elaboração das atividadesdo experimento, na qual o contexto do experimento é determinado em detalhes. Os passos dessafase, de um modo geral, são ilustrados na Figura 2.5.

• Seleção do contexto⇒ Seleciona o ambiente em que o experimento será executado. Con-forme Sjøberg et al. (2002) e Arisholm e Sjøberg (2003), é um desafio executar experi-mentos em ambientes realistas, pois é necessário utilizar uma infra-estrutura profissional,aumentando o custo para a realização do experimento.

• Formulação das hipóteses ⇒ A base da análise estatística de um experimento é o teste dehipóteses. Na fase de planejamento, a definição do experimento é formalizada em hipóte-ses: a hipótese do experimento (ou hipótese alternativa) e a hipótese nula. A hipótese nulaé a que assume que não há diferença entre os dois tratamentos, com respeito a variável deresposta. A hipótese alternativa apresenta uma posição que há uma diferença significativaentre os dois tratamentos (DESMET, 1994).


Fase de planejamento

Definição do

experimento

Seleção do

contexto

Formulaçãodas hipóteses

Seleção dasvariáveis

Seleção dosparticipantes

Projeto doexperimento

Instrumentação

Avaliação davalidade

Projeto doexperimento

Figura 2.5: Visão geral da fase de planejamento (adaptado de Wohlin et al. (2000)).

• Seleção das variáveis ⇒ Na execução de experimento controlado, estuda-se o resultadoda alteração das variáveis do processo. Há dois tipos de variáveis em um experimento,como visto anteriormente: variáveis independentes e dependentes. A escolha das variá-veis apropriadas nem sempre é fácil e usualmente requer domínio de conhecimento. Asvariáveis independentes devem ter algum efeito nas variáveis dependentes e devem sercontroláveis, devendo ser escolhidas também as escalas de medida que deverão ter. Jáas variáveis dependentes, na maioria das vezes, não possuem medida direta e a medidaindireta deve ser validada cuidadosamente, porque afeta o resultado do experimento. Asvariáveis independente e as dependentes são escolhidas geralmente simultaneamente ouem ordem reversa.

• Seleção dos participantes⇒ Os participantes devem ser selecionados de forma criteriosa,pois esta seleção está interligada com a generalização dos resultados do experimento.Para que essa generalização ocorra, essa seleção deve ser representativa para a populaçãotrabalhada. Segundo Sjøberg et al. (2002) e Arisholm e Sjøberg (2003), é importanteutilizar profissionais como participantes de experimentos, para poder aumentar o realismodo mesmo. Porém, é um desafio selecionar profissionais por problemas de disponibilidadee custo (Benestad et al., 2005).

• Projeto do experimento ⇒ O projeto do experimento descreve como o experimento seráexecutado. O experimento é projetado com base nas hipóteses e variáveis selecionadasanteriormente.


Esse projeto e a análise do experimento estão correlacionados. A definição do projetoexperimental afeta a análise e vice-versa. O projeto pode ser aleatório, em blocos, balan-ceado ou alguma combinação desses.

� Aleatório: A distribuição de objetos, participantes e a ordem de execução dos testesestatísticos podem ser aleatórias (Wohlin et al., 2000) com o intuito de impedir quefatores indesejáveis, mas que não se tem conhecimento, sejam obrigatoriamenteassociados a determinadas combinações e possam influenciar o resultado (BarrosNeto et al., 2001);

� Em blocos: Utilizam-se blocos quando um fator pode afetar o resultado, porém nãose deseja estudar esse fator. Os blocos são usados para eliminar o efeito do fatorindesejável (Wohlin et al., 2000). No planejamento, distribuem-se os fatores deforma a evitar ou minimizar os efeitos indesejáveis (Barros Neto et al., 2001);

� Balanceado: Quando os tratamentos são determinados com igual número de partici-pantes tem-se um projeto balanceado. Balanceamento é desejável porque ele tantosimplifica quanto fortalece as análises estatísticas dos dados, porém essa caracterís-tica não é extremamente necessária (Wohlin et al., 2000).

• Instrumentação ⇒ Os instrumentos para a realização do experimento são escolhidos eelaborados nesse passo do planejamento. Os instrumentos são de três tipos: objetos(especificação de sistemas, código fonte, etc.), diretrizes (descrição de técnica, lista deverificação, etc.) e de medição (questionários).

• Avaliação da validade ⇒ Um ponto muito importante sobre os resultados de um expe-rimento é a validade dos mesmos. Nesse passo a validade do experimento é analisada,levando em consideração os fatores que podem afetá-la. É importante pensar na validadedos resultados desde o planejamento, para que assim possa diminuir os riscos à validaçãodos mesmos.

Riscos à validade são fatores além do controle dos experimentadores que podem afetaras variáveis dependentes. Um passo crucial em um experimento é minimizar o impactodesses riscos (Basili et al., 1996). Cook e Campbell classificaram os tipos de risco àvalidade em (Cook e Campbell (1979) apud Wohlin et al. (2000)):

� Validade de conclusão → Refere-se à relação entre o tratamento e o resultado doexperimento;

� Validade interna → Se houver uma relação entre o tratamento e o resultado deve-secertificar que esta é uma relação causal, e não resultado de um fator que não tenhasido controlado ou medido;


� Validade de construção → Refere-se à relação entre teoria e observação. Se a re-lação entre causa e efeito é causal, tem-se que assegurar que o tratamento reflete aconstrução da causa e que o resultado reflete a construção do efeito;

� Validade externa → Relacionada com a generalização dos resultados para toda apopulação.

2.3.3 Operação

Após o planejamento de um experimento, esse deve ser executado para que os dados possamser coletados e posteriormente analisados. A fase de operação é, praticamente, a única em queos participantes têm contato direto com o experimento. Outras ocasiões podem ser duranteinstruções passadas antes do comprometimento do participante ou no final do experimento, paraapresentação dos resultados ou entrevistas. Mesmo que o experimento tenha sido bem delineadoe planejado, será invalidado se esses participantes não executarem seriamente o experimento.Como pode ser visto na Figura 2.6, a fase de operação consiste de três passos: preparação,execução e validação de dados.

Fase de operação

Projeto do

experimentoPreparação

Execução

Validaçãodos dados

Dados doexperimento

Figura 2.6: Visão geral da fase de operação (adaptado de Wohlin et al. (2000)).

No passo de preparação, o material necessário é elaborado e separado (formulários, soft-ware, equipamentos etc.) e os participantes são escolhidos. Estes devem ser informados sobre aintenção do experimento e, então, deve-se obter o consentimento deles em participar. A execu-ção ocorre quando os participantes executam as tarefas e os dados são coletados. Na validaçãodos dados, o experimentador deve verificar se os dados são aceitáveis e se foram coletadoscorretamente.

2.3.4 Análise e interpretação

Os dados coletados na fase anterior devem ser analisados e interpretados. Os três passos quedevem ser executados nesta fase são ilustrados na Figura 2.7.

O primeiro passo na análise é tentar entender os dados usando estatísticas descritivas, quefornecem uma interpretação dos mesmos. O segundo passo é reduzir o conjunto de dados para


Fase de análise e interpretação

Dados do

experimento

Estatísticas

descritivas

Redução doconjunto de dados

Teste dehipóteses

Conclusões

Figura 2.7: Visão geral da fase de análise e interpretação (adaptado de Wohlin et al. (2000)).

um conjunto válido, ou seja, excluir os dados anormais ou dados falsos. No terceiro passo osdados são analisados pelo teste de hipótese, no qual as hipóteses do experimento são avaliadasestatisticamente, verificando se é possível rejeitar hipóteses nulas.

2.3.5 Apresentação e empacotamento

Na fase de apresentação e empacotamento, o experimento é documentado além de divulgadojunto com seus resultados perante a comunidade (Figura 2.8).

Fase de apresentaçãoe empacotamento

Preparaçãode relatóriose pacote doexperimento

Relatórios epacotes do

experimento

Experimento

Figura 2.8: Visão geral da fase de apresentação e empacotamento (adaptado de Wohlin et al.(2000)).

Essa documentação pode ser feita por meio de artigos de pesquisa para publicação, relatóriostécnicos, pacotes de laboratório (que descrevem o experimento em termos específicos e forneceinfra-estrutura experimental para replicação) e como parte de uma base de conhecimento (Basiliet al., 1994).

Os pacotes de laboratório especificam as técnicas aplicadas e o material de treinamentodas técnicas. Também especifica os artefatos de software utilizados no treinamento e os queserão testados. É essencial que durante essa documentação todos os aspectos ou informaçõesnecessárias sejam descritos, possibilitando a replicação desse experimento.

2.3.6 Replicação de experimentos

Com todas as informações de todas as fases de um experimento armazenadas em um pacotede laboratório (Figura 2.2) é possível replicar esse experimento em outra população.


Replicações de experimentos têm como objetivo principal verificar se os resultados obti-dos de um experimento são válidos para uma população maior (generalização dos resultados)(Wohlin et al., 2000). Com a replicação os pesquisadores adquirem conhecimento adicionala respeito dos conceitos estudados, gerando um corpo de conhecimento sobre os resultados,confirmando-os sob outras condições ou mesmo formulando outros questionamentos.

Um experimento pode ser replicado seguindo o mesmo planejamento e condução registradosno pacote de laboratório, permitindo maior fidelidade na replicação e possibilitando assim acomparação direta dos dados obtidos. Replicações de experimentos assim formam um corpo deconhecimento com dados obtidos em diferentes ambientes, como representado pela Figura 2.9.

Pacote de Laboratório

Artefato de Software

Regras

Documentos

Técn

icas

Replicações

R1

R2R3

R4

Rn

Treinamento

.

.

.

Figura 2.9: Replicações de um experimento: pacote de laboratório (Garcia, 2003).

Considerando os objetivos de uma replicação, esta pode ser classificada da seguinte forma(Basili et al., 1999):

• Replicações em que nenhuma hipótese de pesquisa varia ⇒ Nesse tipo de replicaçãonenhuma das variáveis (dependentes ou independentes) variam conforme o experimentooriginal. Essas replicações podem ser:

� Replicações estritas: Repetem o experimento o mais fielmente possível e são ne-cessárias para aumentar a confiança na validade de conclusão. Com esse tipo dereplicação é possível mostrar que os resultados obtidos no experimento original po-dem ser repetidos;

� Replicações que variam a execução: Aumentam a confiança em resultados expe-rimentais testando as mesmas hipóteses de experimentos anteriores, mas alteramdetalhes quanto à maneira em que o experimento é executado para direcionar deter-minadas ameaças internas à validade.


• Replicações que variam as hipóteses de pesquisa ⇒ Replicações desse tipo variam atri-butos do processo, produto e modelos de contexto, mas permanecem no mesmo nível deespecificidade do experimento original. São de três tipos:

� Replicações que variam as variáveis independentes → Importantes para verificarquais aspectos do processo são importantes, variando de maneira ponderada as pro-priedades peculiares do processo e examinando os resultados obtidos;

� Replicações que variam as variáveis dependentes → Variam os modos pelos quaisa efetividade é medida, para entender para quais dimensões de tarefas os resultadosde um processo possuem um ganho melhor; e

� Replicações que variam as variáveis de contexto → São replicações que ocorremcom a variação de contexto no ambiente no qual a solução é avaliada. Podem iden-tificar fatores ambientais que afetam os resultados do processo em investigação,auxiliando o entendimento dos riscos à validade externa.

• Replicações que estendem a teoria ⇒ Ajudam a determinar os limites da efetividadede um processo, fazendo alterações significativas no processo, produto ou modelos decontexto, verificando assim se os princípios básicos continuam válidos.

Considerando a interação entre os replicadores e os idealizadores do experimento original,a replicação pode ser classificada da seguinte forma (Mendonça et al., 2006):

• Tipo I: conduzida pelos mesmos pesquisadores que conduziram OO experimento original.Neste caso não existem problemas relacionados ao conhecimento tácito, mas por outrolado, é provável que erros sejam também repetidos.

• Tipo II: conduzida por replicadores que estão em locais geográficos diferentes dos idea-lizadores do experimento original. Neste caso, existe uma ação coordenada entre ambasas partes, mas os replicadores conduzem o experimento de forma independente. Há a ne-cessidade de que seja coletado o conhecimento tácito e há também a oportunidade de seavaliar o pacote de forma crítica levando, possivelmente a evolução e melhorias do pacoteoriginal.

• Tipo III: conduzida por replicadores que estão em locais geográficos diferentes dos ide-alizadores do experimento original. Neste caso, não existe uma ação coordenada entreambas as partes. Embora o viés da não evolução do pacote original deixe de existir, poroutro lado, existe o risco dos replicadores não capturarem o conhecimento tácito. Aindaque isso aconteça, existe a possibilidade dos replicadores obterem resultados úteis.

• Tipo IV: não existe contato entre os replicadores e os idealizadores do experimento origi-nal, e nem mesmo o uso do pacote de laboratório. Os replicadores utilizam as hipóteses


ou objetivos gerais do experimento original e então projetam seu próprio estudo para tra-balhar com as hipóteses originais. Da mesma forma que no Tipo III, não existe o viés dopacote não evoluir, não existe a transferência do conhecimento tácito e não há a avaliaçãodo projeto experimental por parte de outros pesquisadores.

2.4 Ferramentas de apoio a estudos experimentais

A construção de infra-estrutura necessária para apoiar estudos experimentais é difícil e cus-tosa (Do et al., 2005). Apesar disso, é essencial principalmente para a condução de replicaçõesdos estudos em questão. A automatização de partes dessa infra-estrutura, por meio de ferra-mentas, pode viabilizar a condução de estudos e replicações, facilitando, entre outros fatores,o armazenamento dos dados, a precisão na aplicação das atividades e técnicas e a conduçãode estudos experimentais geograficamente distribuídos. Kitchenham et al. (2004) ressalta queem atividades como a alocação aleatória dos participantes de um experimento para cada técnicae a distribuição dos materiais para os participantes podem ser usados métodos computadori-zados. Sistemas automatizados podem ser usados na obtenção de informações requeridas dosparticipantes, o que pode aumentar a precisão desses dados.

Algumas ferramentas que apóiam estudos experimentais são: Psych Experiments1, S-Ware

WWW Survey Assistant2, Wextor3, SESE e COTEST4. As três primeiras ferramentas citadas dãoapoio à Pesquisa de Opinião, enquanto as outras duas dão apoio à Experimentos Controlados.As ferramentas de apoio à Pesquisa basicamente distribuem questionários (por e-mail ou pá-ginas Web) para que possam ser respondidos virtualmente. É apresentada no Quadro 2.2 umacomparação entre essas ferramentas.

MacDonald e Miller (1998) apresentam algumas vantagens e desvantagens do apoio com-putacional na atividade de inspeção, sendo que as considerações feitas podem ser relevantespara ferramentas de apoio computacional à experimentação. Algumas vantagens apresentadassão:

• Permite o uso dos documentos a serem revisados de maneira eletrônica, evitando a im-pressão de várias cópias do documento, uma para cada revisor, reduzindo assim os custosdo processo;

• Legibilidade das listas e comentários digitados.

Por outro lado, algumas desvantagens são:

• Necessidade de treinamento no uso da ferramenta;1http://psychexps.olemiss.edu/2http://or.psychology.dal.ca/~wcs/3http://genpsylab-serv2.unizh.ch/wextor/en/4http://www.labes.icmc.usp.br/~katiarf/

2.4. FERRAMENTAS DE APOIO A ESTUDOS EXPERIMENTAIS 19

Quadro 2.2: Quadro comparativo das ferramentas apresentadas.

Ferramenta Tipo de EstudoExperimental

Monitoramentodas atividades

Flexibilidadena elabora-ção de novasquestões

Base de dados Transparênciana interaçãocom outrasferramentas

Psych Experiments Pesquisa de opi-nião

Não Sim Automatizada —–

S-Ware WWWSurvey Assistant

Pesquisa de opi-nião

Não Sim Automatizada —–

Wextor Pesquisa de opi-nião

Não Não Manual —–

SESE Experimentocontrolado

Sim Sim Automatizada Não

COTEST Experimentocontrolado

Sim Não Automatizada Não

• Leitura de documentos na tela do monitor é mais cansativa;

• A habilidade do participante digitar a lista de defeitos pode influenciar no número finalde defeitos detectados.

No escopo do Projeto Readers foi apresentada uma arquitetura de apoio computacional aoprocesso de experimentação composta de diversas ferramentas que apóiam etapas ou atividadesespecíficas realizadas durante um experimento controlado (Figura 2.10).



? ?

Base de Experimento

PBR ToolISPISxMapper

Análise de dados

COTESTExpVVT

Análise visual

Figura 2.10: Arquitetura de apoio computacional ao processo de experimentação ((ProjetoReaders, 2004)).


Também está em desenvolvimento uma infra-estrutura capaz de instanciar ambientes deapoio à gestão de conhecimento durante o processo de experimentação (Chapetta et al., 2005;Mian et al., 2005).

A seguir, serão apresentados os objetivos gerais de algumas dessas ferramentas desenvolvi-das e serão detalhadas duas ferramentas de apoio à experimentação: COTEST e SESE, tendoem vista que estão relacionadas mais diretamente ao tema deste trabalho.

PBR Tool

A PBR Tool (Silva, 2004) é uma ferramenta que apóia a aplicação da técnica PBR, for-necendo um guia para a execução das tarefas especificadas pela técnica para a perspectiva dousuário e facilitando o relato das discrepâncias identificadas.

Este apoio ferramental para a identificação de discrepâncias pode trazer uma série de benefí-cios para a inspeção de requisitos de software. A ferramenta provê uma série de funcionalidadespara auxiliá-los no entendimento da técnica, diminuindo a necessidade de se consultar materi-ais de referência e reduzindo assim o tempo total de inspeção. Além disso, a experiência naaplicação manual da técnica tem mostrado que, muitas vezes, os inspetores identificam pontosno documento onde existem defeitos, mas não são capazes de expressar claramente o defeitoexistente.

xMapper

Para garantir a interoperabilidade entre ferramentas independentes é preciso que haja ummecanismo para transformações estruturais e semânticas nos dados e uma tecnologia de ar-mazenamento comum. A ferramenta de integração xMapper (Spínola, 2004) utiliza esquemase ontologias para efetuar as transformações estruturais e semânticas, respectivamente. Ela as-sume como premissa que o intercâmbio dos dados seja feito utilizando o padrão XML. De formasimplificada, a idéia é mapear na ontologia os esquemas dos documentos a serem integrados.Isto centraliza informações semânticas e estruturais tornando possível a geração automatizadade drivers de transformação entre os artefatos.

ISPIS

ISPIS (Kalinowski, 2004) é uma infra-estrutura computacional de apoio ao processo de ins-peção de software que pode ser utilizada para inspecionar diferentes artefatos produzidos aolongo do processo de desenvolvimento de software; objetivando que revisões sejam realizadasna prática de forma mais sistemática e explorando melhor o seu potencial, utilizando dados his-tóricos e informações experimentalmente avaliadas sobre inspeções de software. Para fornecerum apoio customizado à inspeção de tipos de artefatos específicos ISPIS utiliza a integração aoutras ferramentas na atividade de detecção de defeitos.


COde Testing Experiment Support Tool (COTEST)

A COTEST (Felizardo, 2003; Felizardo et al., 2003) é uma ferramenta de apoio à experi-mentação desenvolvida para apoiar um experimento em particular denominado Experimento

de Verificação, Validação e Teste (VV&T) em nível de código fonte, o qual foi conduzido nocontexto do Projeto Readers.

O Experimento de VV&T citado baseia-se nos experimentos conduzidos anteriormente porBasili e Selby (1987) e Kamsties e Lott (1995), com a diferença que o Teste Estrutural aplicadonesses dois foi substituído pelo Teste Incremental, que utiliza a Técnica Estrutural (apoiada pelaferramenta Poke-Tool (Chaim, 1991)) e a Técnica Baseada em Erros (apoiada pela ferramentaProteum (Delamaro, 1993)) em um processo evolutivo de teste, assim como no experimentoreplicado pelo Projeto Readers (Dória, 2001).

A COTEST foi desenvolvida utilizando a linguagem PHP5, sob a plataforma Solaris, tendoo Apache6 como servidor de páginas WWW e o MySQL7 como servidor de banco de dados.Por ser uma ferramenta desenvolvida para a Web, permite que o experimento seja conduzidoremotamente.

Uma característica implementada na COTEST, e que corresponde a uma das vantagensdo apoio computacional no processo de replicação, é o fato da ferramenta permitir o uso dosdocumentos a serem revisados, de maneira eletrônica, evitando a impressão de várias cópias dodocumento, reduzindo assim os custos do processo.

A ferramenta dá suporte às fases de planejamento, de operação e de análise e interpreta-ção do Experimento de VV&T, etapas distribuídas entre os papéis do replicador (responsávelpela organização e condução do experimento e seleção e treinamento dos participantes) e doparticipante (aquele que aplica as técnicas na fase de operação).

O primeiro passo na condução de um experimento deve ser a criação de uma nova replica-ção. Feito isso, os participantes que pretendem participar do experimento devem se cadastrarpreenchendo um questionário que tem como objetivo coletar dados referentes à experiênciae ao perfil do participante, e um questionário com questões específicas referentes aos temas:teste de software, linguagem C e sistema operacional UNIX. No momento da submissão dessesquestionários é automaticamente enviado ao replicador um e-mail comunicando que um novoparticipante deseja participar do experimento.

Na fase de planejamento, a ferramenta dá apoio à etapa "projeto do experimento", na qualé organizada a execução do experimento. Nessa etapa, a ferramenta escolhe aleatoriamente aordem de aplicação das técnicas entre os participantes e a ordem em que os artefatos (códigofonte) serão utilizados, sendo que o replicador tem permissão para alterar essa ordem.

5http://www.php.net/6http://jakarta.apache.org/7http://www.mysql.com/


Com o término da elaboração do projeto experimental, os participantes aplicam as técnicasnos artefatos, conforme foi definido no projeto do experimento. Todo o material de apoionecessário para conduzir a aplicação das técnicas - código fonte, especificação, formulário dedefeitos e de falhas, taxonomia de defeitos - é disponibilizado no momento adequado. Depois definalizadas as três técnicas, é exigido o preenchimento do formulário final que tem por objetivocoletar dados sobre a qualidade da replicação do experimento.

Todos os dados coletados são analisados pelo replicador com o apoio da COTEST, a qualgera gráficos de barras, que essencialmente retratam o desempenho dos participantes, e queauxiliam a análise do experimento.

Quanto às limitações da ferramenta, podem ser citadas:

• Um participante cadastrado pode participar apenas de uma replicação. Para que ele par-ticipe de uma outra replicação, é necessário cadastrá-lo novamente, tendo que preenchertodos os questionários;

• A COTEST permite que seja executada apenas uma replicação por vez;

• Para que um novo experimento seja definido, é necessário uma reestruturação na ferra-menta;

• Não ocorre interação com ferramentas estatísticas, sendo que a análise realizada pela fer-ramenta consiste basicamente da geração de alguns gráficos, não sendo elaborado nenhumoutro tipo de relatório ou análise.

Estudo de caso utilizando a ferramenta COde Testing Experiment Support Tool(COTEST)

Um experimento controlado utilizando o pacote de laboratório do Experimento de VV&Tfoi conduzido com apoio da ferramenta COTEST, tendo como participantes dez alunos do cursode pós-graduação da Universidade Técnica Frederico Santa Maria, do Chile. Esse experimentofoi executado em duas etapas, sendo que a primeira etapa foi monitorada e acompanhada e asegunda, realizada remotamente.

A primeira etapa consistiu de uma aplicação do Experimento de VV&T na qual foram utili-zados os mesmos artefatos de software do pacote de laboratório, tanto para a fase de treinamentocomo para a fase de execução do experimento.

Na segunda etapa todos os participantes aplicaram as três técnicas em um mesmo programa,sendo este o programa no qual cada um deles havia aplicado a técnica Leitura de Código naprimeira etapa. A fase de execução do experimento foi realizada ao longo de uma semana,sendo que cada participante estabeleceu seu próprio horário, tendo como objetivo cumprir trêshoras para cada uma das técnicas.


Felizardo (2003) relata que quanto ao uso da ferramenta e do ponto de vista dos participan-tes, foi relatado que o uso da ferramenta facilitou a realização das atividades, principalmentepor ela conter as instruções e guiar, passo a passo, as tarefas que deviam ser executadas. Doponto de vista do replicador, o uso da ferramenta facilitou muito a análise da lista dos defeitosrelatados pelos participantes e também a elaboração do projeto experimental.

Felizardo (2003) ressalta que, por facilitar a execução do Experimento de VV&T, a ferra-menta COTEST permite que um maior número de replicações sejam conduzidas, contribuindo,portanto, para o aumento do grau de confiabilidade nos resultados desse experimento.

Após o término da primeira etapa, os participantes foram questionados, informalmente, arespeito do uso da ferramenta, sendo que na maioria eles consideraram que a ferramenta haviasido útil para a realização do experimento e que era fácil de ser utilizada. Durante a primeiraetapa, monitorada, surgiram várias dúvidas, principalmente em relação às ferramentas Proteume Poke-Tool e à criação dos casos de testes. Em relação à COTEST, a dificuldade encontradafoi quanto ao preenchimento dos formulários.

Durante a segunda etapa, por ela ter sido executada remotamente, pôde-se constatar umaredução nos custos da replicação, pela eliminação de papel, de impressão ou xerox dos docu-mentos necessários. Além disso, existe a vantagem da total legibilidade de todos os formuláriospreenchidos.

Simula Experiment Support Environment (SESE)

Com o intuito de conduzir experimentos utilizando uma grande quantidade de participantes(Arisholm e Sjøberg, 2003; Arisholm et al., 2001; Sjøberg et al., 2002), os pesquisadores doSimula Research Laboratory8 sentiram a necessidade de uma ferramenta para apoiar a condu-ção desses experimentos. Em parceria com a KompetanseWeb AS foi desenvolvido o SESE,ferramenta de código proprietário que provê funcionalidades tais como:

• Monitoramento do experimento em tempo real;

• Flexibilidade na definição de novos questionários;

• Recuperação automática das sessões do experimento;

• Cópia dos dados do experimento;

• Suporte para enviar e receber os arquivos utilizados no experimento (artefatos).

Um requisito importante para a ferramenta é que ela seja portável, para que os experimentospossam ser executados remotamente. Sendo assim, o SESE foi desenvolvido utilizando arquite-tura cliente-servidor voltada para a Internet. Esse requisito era considerado fundamental pelos

8http://www.simula.no/


pesquisadores do Simula Research Laboratory porque os participantes dos experimentos con-duzidos por eles são normalmente profissionais, e esses executam os mesmos a partir de suasáreas de trabalho.

O SESE oferece, parcialmente, suporte para o processo experimental apresentado na Seção2.3. As fases de definição e planejamento são tratadas como uma só. No SESE não são definidasas hipóteses e nem o modelo de metas proposto por Briand et al. (1997). Nessa fase ocorrea definição dos participantes e elaboração dos artefatos que serão utilizados. É ilustrada, naFigura 2.11, as etapas de condução de um experimento pelo SESE:

Administrador Pesquisador

SESE

Participantes

1: Definição doexperimento

2: Definiçãodos usuários 5: Análise dos

resultados

3: QuestionáriosDescrição das tarefasCódigo fonte

4: Respostas das questõesSoluções das tarefasCódigo fonte

Figura 2.11: Visão geral da operação do SESE (Arisholm et al., 2002; Sjøberg et al., 2002).

1: O pesquisador define um novo experimento, desenvolvendo os artefatos que serão utilizados;

2: O administrador cria as contas para os participantes, informando-os por e-mail;

3: Os participantes recebem os artefatos que serão utilizados;

4: Os participantes executam o experimento;

5: O pesquisador faz a análise do experimento com os dados armazenados no SESE.

Algumas limitações do SESE são:

• Na fase de operação a ferramenta disponibiliza para download os artefatos que serãoutilizados, porém não propicia um ambiente de execução do experimento;

• Não ocorre interação com ferramentas estatísticas, sendo assim, a análise dos dados éfeita manualmente.

2.5. CONSIDERAÇÕES FINAIS 25

2.5 Considerações finais

Neste capítulo foi abordada a necessidade de condução de estudos experimentais em En-genharia de Software quando se busca obter resultados objetivos e significativos em relação àcompreensão, controle, prognóstico e melhoria nos processos de desenvolvimento de software.Também foram detalhados o processo experimental e algumas ferramentas de apoio à conduçãode experimentos controlados.

No próximo capítulo exemplifica-se o processo de experimentação com o detalhamento doExperimento PBR, além das replicações conduzidas pelo ICMC/USP e UFSCar e uma experi-ência de transferência tecnológica para indústria ocorridas no contexto do Projeto Readers.

CAPÍTULO

3

O Experimento PBR


Neste capítulo apresenta-se o Experimento PBR (Basili et al., 1996), dando uma visão ge-ral de todo o processo experimental e do pacote de laboratório associado a esse experimento,o qual foi o ponto de referência para que fossem conduzidas as replicações no contento doProjeto Readers. Em seguida, uma síntese dessas replicações é apresentada, ressaltando as mo-dificações ocorridas no pacote de laboratório original e evidenciando-se a importância do apoiocomputacional na condução de estudos experimentais.

3.2 Experimento original PBR

Basili et al. (1996) conduziram um experimento controlado objetivando avaliar a efetividadeda técnica Leitura Baseada em Perspectiva (Perspective Based Reading - PBR), a qual foi ob-jeto de estudo na tese de Shull (1998), na detecção de defeitos quando aplicada em documentosde especificação de requisitos em linguagem natural, comparando-a com técnicas convencionaisde revisão. Foi utilizado o seguinte modelo de metas nesse experimento:

• Objeto de estudo: Técnica Leitura Baseada em Perspectiva (PBR);

• Propósito: Avaliar a técnica;

• Enfoque: Efetividade em revelar defeitos;

27

28 CAPÍTULO 3. O EXPERIMENTO PBR

• Perspectiva: Revisores de software;

• Contexto: Profissionais de desenvolvimento de software do Laboratório de Engenhariade Software (Software Engineering Laboratory - SEL) da NASA/GSFC (National Aero-

nautics and Space Administration/Goddard Space Flight Center)

A técnica de Leitura Baseada em Perspectiva (PBR) é utilizada para detectar defeitos emdocumentos de especificação de requisitos, fornecendo um conjunto de procedimentos que au-xiliam os revisores a encontrarem defeitos nesses documentos (Shull et al., 2000). As perspec-tivas definidas para essa técnica são do Usuário, do Projetista e do Testador. Para cada umadessas perspectivas constrói-se um cenário, o qual é composto de um modelo de referência,um conjunto de questões que auxiliam na detecção dos defeitos e uma taxonomia de defeitosque se deseja encontrar durante o processo de inspeção. Dessa forma, cada revisor assume umdesses papéis ao fazer a revisão do documento e, com base na abstração elaborada, responde asquestões associadas à perspectiva que está assumindo.

A hipótese desse experimento foi que "a união dos defeitos detectados pelos grupos de par-ticipantes que utilizariam perspectivas diferentes forneceria uma maior cobertura do documentodo que a união dos defeitos detectados pelos grupos que usariam a técnica da NASA."

Para a realização do experimento foram desenvolvidos documentos de especificação de re-quisitos e introduzidos defeitos em cada um deles, relacionados ao seu contexto. Foram pre-parados dois documentos de domínio específico no contexto da NASA, NASA_A e NASA_B,os quais foram derivados de um conjunto de documentos já existentes. Foram também desen-volvidos dois documentos de domínio genérico, denominados PG (Parking Garage) e ATM(Automated Teller Machine). No Quadro 3.1 apresentam-se a quantidade de páginas e de defei-tos em cada documento.

As variáveis independentes selecionadas para esse experimento foram as técnicas aplicadas(PBR e técnica usual da NASA), as perspectivas (projetista, testador e usuário) e os documentosde especificação de requisitos. Já a variável dependente foi a experiência prática nas perspecti-vas adotadas.

Quadro 3.1: Quantidade de páginas e de defeitos nos documentos utilizados no ExperimentoPBR (Basili et al., 1996).

Documentos Quantidade de páginas Quantidade de defeitosATM 17 29PG 16 27NASA_A 27 15NASA_B 27 15

Uma das limitações desse experimento foi o tempo, pois por serem desenvolvedores profis-sionais, não dispunham de grande disponibilidade de tempo. O projeto experimental aplicado

3.2. EXPERIMENTO ORIGINAL PBR 29

pode ser visto no Quadro 3.2. Em linhas gerais, o projeto foi aplicado com tratamento em blocona técnica, na perspectiva, no documento e na seqüência de leitura. Dois grupos de partici-pantes foram estabelecidos, cada um com 6 participantes, e em que cada grupo continham trêssubgrupos (cada subgrupo com dois participantes), um para cada perspectiva.

Quadro 3.2: Projeto experimental do Experimento PBR (Basili et al., 1996).

TécnicaGrupo 1 Grupo 2

Projetista Testador Usuário Projetista Testador Usuário

Usual daNASA

Treinamento TreinamentoPrimeiroDia

NASA_A NASA_BTreinamento Treinamento

ATM PG

PBR

Teoria PBR

SegundoDia

Treinamento TreinamentoPG ATM

Treinamento TreinamentoNASA_B NASA_A

Os defeitos dos documentos foram classificados em duas categorias: classe e tipo. Asclasses de defeito são criação, que são defeitos causados por informações erradas presentes naespecificação de requisitos, e omissão, que são defeitos causados por falta de informações naespecificação de requisitos. Os tipos de defeitos são classificados em:

• Ambigüidade ⇒ Um termo importante, frase ou sentença essencial para o entendimentodo problema não foi definido ou foi definido de maneira que pode causar confusão ouengano;

• Informação estranha ⇒ Alguma informação é dada, porém ela não é necessária ou nãoé utilizada;

• Inconsistência ⇒ Informações entre partes do documento estão inconsistentes entre si;

• Fato incorreto ⇒ Alguma informação contida no documento de requisitos afirma umfato que pode não ser verdade sobre as condições especificadas nos requisitos gerais ouno conhecimento de domínio geral;

• Omissão⇒ Informação necessária sobre o sistema foi omitida da especificação de requi-sitos.

Durante a execução do experimento, em novembro de 1994, foram observados os seguintesaspectos:


• Os documentos de domínio específico da NASA eram muito longos para a análise notempo proposto. Foi decidido por uma revisão e redução dos mesmos para replicaçõesposteriores do experimento;

• A tentativa de distribuir os participantes de acordo com sua experiência e as perspectivastrabalhadas não foi possível, pois havia mais projetistas do que testadores e usuários.Sendo assim, decidiu-se distribuir aleatoriamente os participantes nas replicações futuras;

• O tempo previsto para as sessões de revisão era de três horas, porém foi observado queapenas um participante levou mais de duas horas. Sendo assim, o tempo foi reduzido paraduas horas para as replicações posteriores;

• Percebeu-se que era necessário o isolamento do participante durante a execução, evitandointerrupções e garantindo uma maior validade de conclusão dos resultados.

Devido a essas observações, esse experimento ficou conhecido como "Estudo Piloto". Umoutro experimento utilizando o mesmo projeto experimental foi conduzido em junho de 1995,porém com 14 participantes. Como um desse participantes não era familiarizado com aplicaçõesde dinâmica de vôo da NASA, ele foi desconsiderado na análise dos documentos NASA_A eNASA_B.

Como as perspectivas da técnica PBR são específicas e nenhuma delas fornece coberturado documento inteiro, assume-se que a combinação delas, em grupos, irá oferecer coberturacompleta do documento. É apresentada na Figura 3.1 a análise por grupos, e na Figura 3.2 aanálise por participante. Pode ser observado que na primeira execução (Estudo Piloto), a técnicaPBR obteve resultado significativo somente nos documentos de domínio genérico. Na segundaexecução pode ser observado uma melhora nos resultados em ambas as classes de documentos.Esse melhora pode ser atribuída às modificações nos documentos de domínio específico e àssessões de treinamento antes de cada sessão de revisão.

Nas Figuras 3.3 e 3.4 são apresentadas as coberturas obtidas pelas perspectivas da PBR nodocumento genérico ATM e no específico NASA_A, respectivamente. Pode ser observado que,por exemplo, na perspectiva de Testador foram encontrados um total de 17 defeitos na segundaexecução com o documento ATM, são eles: 3 que não foram detectados por nenhuma outraperspectiva; 3 que também foram detectados pela perspectiva do Projetista; 6 que também fo-ram detectados pela perspectiva do Usuário; e 5 que foram detectados por todas as perspectivas.

Pode ser observado também nessas figuras que em documentos de domínio genérico houveum número significativo de defeitos que foram descobertos apenas por uma das perspectivas,enquanto que nos documentos específicos foram observados graus maiores de sobreposiçãoentre as perspectivas em relação ao conjunto de defeitos.

Finalmente, foi observado com a análise dos dados coletados que a relação entre a taxa dedetecção de falhas obtida pelos participantes que aplicaram PBR e a experiência dos mesmos


Figura 3.1: Resultados obtidos pelos grupos (Basili et al., 1996).

Figura 3.2: Resultados obtidos pelos participantes individualmente (Basili et al., 1996).


ATM

1ª Execução(1994)

Projetista

Testador

Usuário

25

5

4

5

2

3


Projetista

Testador

Usuário

23

1

5

3

6

3

Figura 3.3: Cobertura obtida nas duas execuções pelas perspectivas no documento genéricoATM (Basili et al., 1996).

NASA_A


Projetista

Testador

Usuário

10

0

2

2

3

2


Projetista

Testador

Usuário

01

0

8

1

4

1

Figura 3.4: Cobertura obtida nas duas execuções pelas perspectivas no documento específicoNASA_A (Basili et al., 1996).


é fraca, ou seja, participantes com mais experiência não executam melhor a revisão em relaçãoaos com menos experiência. Em alguns casos, participantes com menor experiência aplicarammelhor a técnica.

3.2.1 Pacote de laboratório original do Experimento PBR

Nesta subseção, apresenta-se a lista dos itens que compunham o pacote de laboratório origi-nal formado para viabilizar replicações do Experimento PBR. No contexto do Projeto Readers

esse pacote evoluiu com as quatro replicações e a experiência de transferência da técnica PBRpara indústria por meio de experimentação, apresentadas na Seção 3.3.

• Taxonomia de defeitos: utilizada pelos participantes para classificar os defeitos encon-trados. Cada defeito deve ser classificado em uma classe e em um tipo. No pacote vemapresentada no formulário E2: Defect Classification Scheme.

– Classes de Defeitos:

∗ Omission (O) - São defeitos causados por falta de informações na especificaçãode requisitos;

∗ Comission (C) - São defeitos causados por informações presentes na especifi-cação de requisitos.

– Tipos de Defeitos:

∗ Ambiguous information (A) - Um termo importante, frase ou sentença essen-cial para o entendimento do comportamento do sistema não foi definido ou foidefinido de maneira que pode causar confusão ou engano;

∗ Incorrect fact (I) - Alguma sentença contida na especificação de requisitosafirma um fato que não pode ser verdade sobre as condições especificadas naespecificação de requisitos;

∗ Extraneous information (E) - Informação que é fornecida não é necessária ouutilizada;

∗ Miscellaneous (M)

• Artefatos:

– Técnicas de Leitura:

∗ PBR (Perspective-Based Reading)

∗ Checklist

– Documentos: Documentos de domínio genérico utilizados no experimento, sendoque dois são utilizados com o propósito de aplicação das técnicas e um com o pro-pósito de treinamento.


∗ ATM (Automated Teller Machine)

∗ PG (Parking Garage)

∗ ABC Video - utilizado para treinamento

∗ Listas de defeitos - contém os defeitos de cada um dos documentos.

– Formulários:

∗ Lista de participantes;

∗ Consent Form - para ser assinado por cada participante aceitando participar doexperimento;

∗ E1: Reviewer Background Questionaire - formulário para coleta de informaçõessobre o perfil do participante;

∗ E2: Defect Classification Scheme - taxonomia de defeitos;

∗ E3: Review Summary for usual technique reviewers - formulário utilizado peloparticipante para registrar horário de início e fim da revisão e documento revi-sado com a técnica checklist;

∗ E4: Review Summary for PBR-technique reviewers - formulário utilizado peloparticipante para registrar horário de início e fim da revisão, documento revi-sado com a técnica PBR e perspectiva utilizada;

∗ E5: Defect Report Form - Formulário para registro dos defeitos encontrados.

∗ E6D: Reading Scenario for Designer Perspective - Questões utilizadas paraapoiar revisão sob a perspectiva do projetista;

∗ E6T: Reading Scenario for Tester Perspective - Questões utilizadas para apoiarrevisão sob a perspectiva do testador;

∗ E6U: Reading Scenario for User Perspective - Questões utilizadas para apoiarrevisão sob a perspectiva do usuário;

∗ E7: Feedback Questionaire - Formulário para coleta de opiniões dos partici-pantes sobre a aplicação do experimento.

• Treinamento:

– Slides para o primeiro dia - Apresentação para os partipantes, contendo motivação,objetivos, projeto experimental e seqüência de aplicação.

– Slides para o segundo dia - Apresentação para os partipantes, contendo projeto ex-perimental, introdução à técnica PBR e seqüência de aplicação.

• Exemplos:

– Exemplo genérico - Um exemplo de como alguns defeitos que podem ser encontra-dos no documento de treinamento podem ser registrados no formulário defect report

form.

3.3. REPLICAÇÕES DO EXPERIMENTO PBR 35

– Perspectiva do projetista - Exemplos de defeitos que podem ser encontrados uti-lizando as questões da perspectiva do projetista e exemplo de preenchimento doformulário defect report form.

– Perspectiva do testador - Exemplos de defeitos que podem ser encontrados utili-zando as questões da perspectiva do testador e exemplo de preenchimento do for-mulário defect report form.

– Perspectiva do usuário - Exemplos de defeitos que podem ser encontrados utilizandoas questões da perspectiva do usuário e exemplo de preenchimento do formuláriodefect report form.

• Projeto experimental :

Como pode ser observado no (Quadro 3.3), o projeto desse experimento consistiu dedois grupos de participantes, Grupo 1 e Grupo 2 e a aplicação das técnicas ocorreu emdois dias. No primeiro dia, os dois grupos foram treinados na técnica usual da NASAe cada grupo aplicou essa técnica em um documento do domínio específico da NASA eem um documento de domínio genérico (diferentes para cada grupo). No segundo dia,os participantes de cada grupo foram distribuídos em três subgrupos, correspondentes acada uma das três perspectivas da técnica PBR, e foram treinados nas mesmas. Para aaplicação das perspectivas, os documentos foram trocados, ou seja, o Grupo 1 usou osdocumentos utilizados pelo Grupo 2 e vice-versa.

Quadro 3.3: Projeto experimental do Experimento PBR (Basili et al., 1996).

TécnicaGrupo 1 Grupo 2

Projetista Testador Usuário Projetista Testador Usuário

Usual daNASA

Treinamento TreinamentoPrimeiroDia

NASA_A NASA_BTreinamento Treinamento

ATM PG

PBR

Teoria PBR

SegundoDia


Treinamento TreinamentoNASA_B NASA_A

3.3 Replicações do Experimento PBR

No contexto do Projeto Readers várias replicações do Experimento PBR foram conduzidasnas diversas instituições envolvidas no projeto. No entanto, nesta seção, apresentam-se as sín-teses de 4 replicações desse experimento, as quais foram realizadas pelo ICMC/USP e UFSCar,


dado que a estas, tinha-se acesso facilitado a todos os dados e à equipe envolvida nessas quatroreplicações. Além dessas replicações, comenta-se também uma experiência de TransferênciaTecnológica para a indústria, no caso, transferência da técnica PBR, a qual foi realizada pormeio de um estudo experimental.

No início da síntese de cada replicação são relatados os itens que foram alterados no pacotede laboratório, para a condução daquela replicação e, ao final de cada replicação, são relatadasas diferenças que ocorreram durante a condução do estudo, mas que não estão relacionadasdiretamente com o pacote de laboratório.

Considerando-se os diferentes tipos de replicações, como foi mencionado no Capítulo 2,em relação às possíveis modificações no pacote de laboratório, as replicações aqui descritassão do tipo em que nenhuma hipótese de pesquisa varia, mas variam detalhes na execução e,em relação à interação entre os grupos de pesquisadores, elas são do Tipo II, uma vez que osreplicadores e os idealizadores do estudo original estão em locais geográficos diferentes, mashouve uma ação coordenada entre eles e a condução da replicação foi independente.

3.3.1 Primeira replicação (R1)

Dentro do contexto do Projeto Readers, foi conduzida a primeira replicação (R1) (Dória,2001) do experimento realizado por Basili et al. (1996).

• Técnicas utilizadas: As técnicas aplicadas nessa replicação foram basicamente as mes-mas do estudo original (PBR e uma técnica convencional), sendo que a técnica perten-cente à NASA foi substituída pela técnica Checklist, que é uma técnica freqüentementeusada para detecção de defeitos em especificações de requisitos.

Na técnica Checklist cada revisor recebe uma lista de conferência, no qual os itens dessalista capturam importantes lições apreendidas em revisões anteriores. Itens individuaisde uma lista de conferência podem enumerar defeitos característicos, priorizar diferentesdefeitos ou propor questões para ajudar o revisor a descobrir defeitos.

• Artefatos de software: Quanto aos documentos de especificação de requisitos, os docu-mentos de domínio genérico foram os mesmos do experimento original (ATM e PG), masnão foram utilizados os documentos de domínio específico da NASA. Os defeitos presen-tes nos documentos foram classificados de acordo com os esquemas de classificação doExperimento PBR. O documento utilizado para treinamento foi o ABC Video.

• Principais objetivos: Os objetivos da R1 foram os mesmos do estudo original, somando-se o propósito de obter mais dados para reforçar ou contestar os resultados do estudooriginal.

– Objeto de estudo: Técnica de Leitura Baseada em Perspectiva (PBR);


– Propósito: Avaliar a técnica;

– Enfoque: Efetividade em revelar defeitos;

– Perspectiva: Revisores de software;

– Contexto: Alunos de graduação da disciplina de Engenharia de Software do Cursode Bacharelado em Ciência da Computação do ICMC/USP.

• Caracterização dos participantes: Essa replicação contou com 18 participantes, sendoesses alunos de graduação da disciplina de Engenharia de Software do Curso de Bacha-relado em Ciência da Computação do ICMC/USP.

• Projeto experimental: Os 18 participantes foram divididos em 2 grupos de 9 partici-pantes, e em cada grupo houve uma subdivisão por perspectiva (Projetista, Testador eUsuário). É apresentado no Quadro 3.4 o projeto experimental da replicação conduzida.Esse projeto experimental garante que cada participante aplique cada técnica somenteuma vez e que todas as combinações de documentos de especificação de requisitos etécnicas ocorram.

Quadro 3.4: Projeto experimental aplicado por Dória (2001).

TécnicaGrupo 1 - 9 participantes Grupo 2 - 9 participantes

Projetista Testador Usuário Projetista Testador Usuário3 part. 3 part. 3 part. 3 part. 3 part. 3 part.

ChecklistTreinamento Treinamento Primeiro

DiaATM PG

PBRTeoria sobre a técnica PBR

SegundoDia


• Forma de utilização das técnicas: No primeiro dia, todos participantes foram treinadosna técnica Checklist, utilizando durante 1 hora o documento de especificação de requisi-tos de domínio genérico ABC Video System, que foi utilizado na fase de treinamento doestudo original. Na aplicação propriamente dita, os participantes do Grupo 1 revisaram odocumento de especificação de requisitos ATM e os participantes do Grupo 2 revisaramo documento de especificação de requisitos PG, a sessão de inspeção teve duração de 4horas. No segundo dia, cada participante foi treinado em uma das três perspectivas PBR.Os participantes revisaram, também durante 4 horas, o documento de requisitos que aindanão tinham trabalhado, ou seja, Grupo 1 revisou PG e Grupo 2 revisou ATM.

• Principais resultados obtidos: Os principais resultados obtidos são apresentados a se-guir (Dória, 2001; Shull et al., 2004):


– Como pode ser visto a partir da Figura 3.5, a técnica PBR obteve melhor perfor-mance que a técnica convencional no documento ATM. Com o objetivo de exploraros aspectos complementares das técnicas foi realizada uma combinação, por meiode simulação, dos resultados obtidos por ambas as técnicas. O resultado combinadofoi 10.81% maior que o melhor resultado alcançado individualmente pela técnicaPBR;

Figura 3.5: Performance obtida por cada técnica e pelos pares combinados de técnicas(Dória, 2001).

– Cada grupo de participantes que aplicou a mesma perspectiva PBR encontrou umconjunto de defeitos que as outras perspectivas não encontraram, o que salienta oaspecto complementar entre elas;

– Participantes que aplicaram a técnica PBR tiveram um desempenho melhor queaqueles que aplicaram Checklist.

Como o estudo original não foi conduzido pelos mesmos pesquisadores das replicaçõesaqui descritas, não serão relatadas possíveis diferenças que possam ter ocorrido entre aR1 e a aplicação do estudo original.

3.3.2 Segunda replicação (R2)

• Modificações ocorridas no pacote de laboratório utilizado na R1, para condução da R2:

– Inserção dos seguintes campos no formulário de Coleta de Defeitos: "tempo", paraque se pudesse definir melhor o tempo da atividade de inspeção, uma vez que apartir de algum momento, a efetividade para detectar defeitos começa a decrescer;e o número do requisito no qual se encontra o defeito, para facilitar a análise dosdefeitos relatados.


– Criação de uma lista de falsos positivos, que são defeitos reportados com freqüênciapelos revisores, mas que não são defeitos reais.

– Atualização da lista de defeitos dos documentos de especificação de requisitos comsete novos defeitos para o documento ATM e dois novos defeitos para o documentoPG, encontrados pelos participantes de R1.

• Técnicas utilizadas: As técnicas aplicadas nessa replicação foram as mesmas da R2 -PBR e Checklist.

• Artefatos de software: Foram utilizados os mesmos documentos de especificação derequisitos da R1.

• Principais objetivos: Os objetivos da R2 foram os mesmos da R1.

– Objeto de estudo: Técnica Leitura Baseada em Perspectiva (PBR);




– Contexto: Alunos de graduação do curso de Bacharelado em Ciência da Computa-ção da UFSCar.

• Caracterização dos participantes: A R2 teve participantes de perfil semelhante à pri-meira. Ela foi realizada com 18 estudantes de graduação do curso de Bacharelado emCiência da Computação da UFSCar.

• Projeto experimental: O projeto experimental diferenciou da R1 apenas na quantidadede dias para aplicação do experimento. Em R1 foram dois dias inteiros, enquanto que emR2 foram 4 dias, durante meio turno cada, como está apresentado no Quadro 3.5.

Quadro 3.5: Projeto experimental - R2 (Höhn, 2003).

TécnicaGrupo 1 - 9 participantes Grupo 2 - 9 participantes

Projetista Testador Usuário Projetista Testador Usuário3 part. 3 part. 3 part. 3 part. 3 part. 3 part.

ChecklistTreinamento Treinamento 1o Dia

ATM PG 2o Dia

PBRTeoria sobre a técnica PBR

Treinamento Treinamento 3o DiaPG ATM 4o Dia


• Forma de utilização das técnicas: No primeiro dia (meio turno), foi fornecida a todosos participantes uma visão geral de técnicas de inspeção e então eles foram treinadosna técnica Checklist (com treinamento de 1 hora no ABC Video). No segundo dia, osparticipantes do Grupo 1 revisaram o documento de requisitos ATM e os participantes doGrupo 2 revisaram o documento de requisitos PG. No terceiro dia, cada participante foitreinado em uma das 3 perspectivas da PBR. E, finalmente, no quarto dia, os participantesrevisaram o documento de requisitos que ainda não tinham trabalhado, ou seja, Grupo 1revisou PG e Grupo 2 revisou ATM.

• Principais resultados obtidos: PBR mais efetiva na detecção de defeitos do que Chec-

klist para ambos os documentos, sendo que para o documento ATM a efetividade foiligeiramente melhor.

• Diferenças ocorridas na replicação R2, não relacionadas ao pacote de laboratório:

– Períodos de execução: 4 meio turnos durante 4 dias, em vez de 2 turnos por dia,durante 2 dias consecutivos.

3.3.3 Terceira replicação (R3)

• Modificações ocorridas no pacote de laboratório utilizado na R2, para condução da R3:

– O tempo de aplicação das técnicas durante a fase de treinamento foi reduzido para30 minutos.

– O documento de especificação de requisitos ABC Video utilizado no treinamento foisubstituído pelo documento Gas Station, por este ter um tamanho menor em relaçãoao anterior.

– O formulário de caracterização do perfil do participante foi modificado nas questõesde experiência. A questão sobre tempo de experiência nas funções Manager/Deve-

loper/Tester/Analyst foi retirada, enquanto que diversas questões sobre experiênciacom requisitos, projeto e teste foram acrescentadas.

– O formulário de coleta de defeitos foi alterado desmembrando a coluna para registrartipo de defeito e classe de defeito e as colunas para página e número do requisitoforam unificadas.

• Técnicas utilizadas: As técnicas aplicadas nessa replicação foram as mesmas utilizadasem R1 e R2 - PBR e Checklist.

• Artefatos de software: Para a fase de aplicação das técnicas foram utilizados os mesmosdocumentos de especificação de R1 e R2. Mas para a fase de treinamento foi utilizado odocumento Gas Station no lugar do ABC Video, pois precisava-se de um documento detamanho menor, pois o tempo também foi reduzido.


• Principais objetivos:





– Contexto: Alunos de pós-graduação em Engenharia de Software do ICMC/USP eUFSCar.

• Caracterização dos participantes: 18 estudantes do curso de pós- graduação em Enge-nharia de Software do ICMC-USP e da UFSCar.

• Projeto experimental: O projeto experimental de R3 diferenciou de R1 e R2 devidoa quantidade de dias para execução do experimento. Foram 3 dias, sendo que nos doisprimeiros foi utilizado apenas o turno noturno, devido à disponibilidade de horário dosparticipantes. O projeto experimental está apresentado no Quadro 3.6.


Grupo 1 Grupo 2Projetista Testador Usuário Projetista Testador Usuário

Técnica 3 partic. 3 partic. 3 partic. 3 partic. 3 partic. 3 partic.Checklist Treinamento Treinamento 1o Dia

Aplicação no documento PG Aplicação no documento ATM 2o DiaPBR Treinamento Treinamento 3o Dia

Aplicação no documento ATM Aplicação no documento PG

• Forma de utilização das técnicas: No primeiro dia, os participantes receberam trei-namento no Checklist (com treinamento de 30 minutos no documento de requisitos dedomínio genérico Gas Station). A aplicação do Checklist nos documentos ATM e PGocorreu no segundo dia, com um tempo de 1h45min, onde os participantes do Grupo 1aplicaram no documento de requisitos PG e os do Grupo 2 aplicaram no documento derequisitos ATM. No terceiro dia houve treinamento nas técnicas PBR no período da ma-nhã (com treinamento de 30 minutos no documento de requisitos Gas Station) e aplicaçãonos documentos no período da tarde. Tendo 1h45min para aplicação, os participantes doGrupo 1 utilizaram o ATM e os do Grupo 2, o PG.

• Principais resultados obtidos: Essa replicação produziu resultados diferentes de R1 eR2 para o documento ATM: o desempenho da técnica Checklist foi melhor que da PBR.E para o documento PG, o desempenho da técnica PBR foi melhor que o da técnicaChecklist, como ocorreu em R2 (Höhn, 2003).



– Perfil dos participantes: alunos de pós graduação.

– Períodos de execução: 3 dias consecutivos, sendo que no primeiro e segundo dias assessões foram noturnas e, no terceiro dia diurnas.

3.3.4 Quarta replicação (R4)

Não houve modificações ocorridas no pacote de laboratório utilizado na R3, para conduçãoda R4.

• Técnicas utilizadas: As técnicas aplicadas nessa replicação foram as mesmas utilizadasem R1, R2 e R3 - PBR e Checklist.

• Artefatos de software: Os documentos de especificação de requisitos utilizados foramos mesmos da R3 (treinamento: Gas Station; aplicação: ATM e PG).






– Contexto: profissionais de desenvolvimento de software.

• Caracterização dos participantes: A R4 foi conduzida em contexto industrial, proje-tada para 18 participantes, sendo 12 profissionais de software de uma empresa de te-lecomunicações de Campinas, 3 profissionais de software de uma empresa de pesquisaagropecuária e 3 alunos de pós-graduação da UNICAMP.

• Projeto experimental: O projeto experimental de R4 está apresentado no Quadro 3.7


Grupo 1 Grupo 2Projetista Testador Usuário Projetista Testador Usuário

Técnica 3 partic. 3 partic. 3 partic. 3 partic. 3 partic. 3 partic.Checklist Treinamento Treinamento 1o Dia

Aplicação no documento PG Aplicação no documento ATMPBR Treinamento Treinamento 2o Dia

Aplicação no documento ATM Aplicação no documento PG


• Forma de utilização das técnicas: O experimento foi conduzido durante dois dias, noauditório da empresa. No primeiro dia, os participantes receberam treinamento no Chec-

klist e aplicaram nos documentos, com um tempo de 1h45min, onde os participantesdo Grupo 1 aplicaram no documento de requisitos PG e os do Grupo 2 aplicaram nodocumento de requisitos ATM. No segundo dia houve treinamento nas técnicas PBR eaplicação nos documentos. Tendo 1h45min para aplicação, os participantes do Grupo 1utilizaram o ATM e os do Grupo 2, o PG. O Grupo 1, composto de funcionários da em-presa de telecomunicações, ficou com apenas 6 participantes devido a problemas de trocade material e ausência de dois participantes durante a aplicação das técnicas. Na aplicaçãoda PBR, o grupo contou com 2 participantes utilizando a visão do Projetista, 3 utilizandoTestador e 1 Usuário. O Grupo 2 era composto por 3 funcionários da empresa de teleco-municações, 3 da empresa de pesquisa agropecuária e 3 estudantes de pós-graduação daUNICAMP.

• Principais resultados obtidos: Devido aos problemas ocorridos durante a execução dareplicação, os resultados analisados foram baseados nos dados de 15 participantes (12profissionais de software das empresas e 3 alunos de pós-graduação). Tanto para o docu-mento ATM como para o PG, os resultados da R4 foram inversos aos de R2, sendo quena R4 a técnica Checklist foi mais efetiva que a PBR.

Na Figura 3.6 são apresentados alguns resultados comparativos das quatro replicações emconjunto, tanto para o documento ATM quanto para o documento PG.

Figura 3.6: Comparativo das quatro replicações.


– Perfil dos participantes: profissionais da indústria.

– Períodos de execução: a execução do experimento foi em dois dias consecutivos.

– Um dos grupos teve um número reduzido de participantes.


3.3.5 Aplicação do Experimento PBR na indústria

Foi realizado um trabalho de transferência tecnológica no CPqD (Centro de Pesquisa e De-senvolvimento em Telecomunicações) com o propósito de adaptar as técnicas de leitura PBRe de promover sua implantação de acordo com os objetivos e tarefas específicos ao desenvol-vimento de software e tipos específicos de documentos de requisitos do domínio de aplicaçãoda empresa (Höhn et al., 2004; Höhn, 2003). Esse trabalho foi realizado dentro do contexto doprojeto Readers, sendo a transferência tecnológica feita por meio do Experimento PBR, apósas evoluções do pacote de laboratório ocorridas em decorrência das replicações sintetizadasanteriormente. Como o intuito desse estudo não foi o mesmo das replicações mencionadasanteriormente, vários pontos foram alterados tanto no pacote de laboratório, como no próprioprojeto experimental. O estudo foi composto de dois projetos piloto, P1 e P2; P1 visando àfamiliarização com o domínio de aplicação da empresa, por parte da equipe acadêmica e o co-nhecimento de um pacote de laboratório e do processo de experimentação, por parte da equipeda empresa; e P2 visando à validação das alterações efetuadas nos artefatos de domínio especí-fico da empresa e a apresentação das técnicas para profissionais de desenvolvimento de softwareda empresa.

• Técnica utilizada: PBR.

• Artefatos de software: Os documentos de especificação de requisitos utilizados paratreinamento foram Gas Station e ABC Video e para aplicação foram ATM e OPER - umdocumento de domínio específico da empresa.



– Propósito: Adaptar a técnica;



– Contexto: profissionais de desenvolvimento de software.

• Caracterização dos participantes: Os participantes do projeto piloto 1 (P1) estavamligados ao processo de transferência das técnicas, sendo 3 profissionais do grupo de pes-quisa aplicada em qualidade de software e do lado acadêmico eram 2 alunos de mestradodo laboratório de engenharia de software do ICMC/USP. No projeto piloto 2 (P2) partici-param profissionais das áreas de desenvolvimento de software e de requisitos de softwareda empresa.

• Projeto experimental: Os projetos experimentais de P1 e de P2 são apresentados nosQuadros 3.8 e 3.9


Quadro 3.8: Projeto experimental - P1 (Höhn, 2003).

Treinamento da equipe acadêmica no domínio da empresa

1o. DiaConceitos básicos de rede externa - Rede metálica

Visão geral do SAGRE

GAT: conceitos e demonstração

2o. Dia

SAGRE/Cad: projeto de uma rede metálica (demonstração)

SAGRE/OPER: movimentação de facilidades (demonstração)

SAGRE/OPER-FCT (Folha de Corte):

alterações no projeto de uma rede ocupada (demonstração)

Treinamento da equipe da empresa no Pacote de Laboratório

1o. Dia

Modelo subjacente Error Guessing

Taxonomia de defeitos

Domínio do doc. req. Gas Station

PBR - Parte geral

PBR - Testador

Aplicação no doc. req. Gas Station - Testador

2o. Dia

Modelo subjacente Caso de uso (UML)

PBR - Usuário

Aplicação no doc. req. Gas Station - Usuário

Feedback dos defeitos

3o. Dia

Domínio do doc. req. ABC Video

Aplicação no doc. req. ABC Video - Usuário

Aplicação no doc. req. ABC Video - Testador


Aplicação

4o. Dia

Domínio no doc. req. ATM

Aplicação no doc. req. ATM - Usuário

Aplicação no doc. req. ATM - Testador

5o. Dia

Domínio do doc. req. PG

Domínio do doc. req. OPER

Aplicação no doc. req. OPER/PG - Usuário

Aplicação no doc. req. OPER/PG - Testador

• Forma de utilização das técnicas: Devido ao caráter de treinamento de P1, todos os par-ticipantes aplicaram as duas perspectivas utilizadas (Usuário e Testador) nos documentosABC Video e ATM. No último documento a ser aplicado, os 2 participantes da empresaque trabalharam na preparação do documento de domínio específico, aplicaram PG e osdemais aplicaram no documento de domínio específico OPER. Em P2, devido à dificul-dade em conseguir tempo disponível dos profissionais, as atividades ocorreram com certointervalo entre os dias de treinamento e aplicações das técnicas.

• Principais resultados obtidos: O projeto piloto P1 atingiu seu objetivo, pois propiciou afamiliarização da equipe da empresa com o processo de experimentação e a equipe acadê-mica com o domínio de aplicação da empresa. Além desse resultado, durante a execução


Quadro 3.9: Projeto experimental - P2 (Höhn, 2003).

Grupo 1 - Usuário Grupo 2 - Testador

(3 revisores) (3 revisores)

Treinamento

1o Dia

Taxonomia

Modelo subjacente Modelo Subjacente

Caso de Uso Error Guessing

Domínio Doc. Req. domínio genérico Gas Station

PBR - Parte geral

PBR - Usuário PBR - Testador

2o DiaDomínio Doc. Req. domínio genérico ABC Video

Aplicação Doc. Req. ABC Video


Aplicação

3o DiaTreinamento domínio Doc. Req. domínio genérico ATM

Aplicação Doc. Req. ATM

4o DiaAplicação Doc. Req. específico OPER

Preenchimento do Questionário de opiniões

de P1 foram identificados novos defeitos no documento OPER, pela equipe acadêmica,sendo que esse documento já havia sido inspecionado em algumas atividades de inspeçãoconduzidas pela própria equipe da empresa, quando do desenvolvimento dessa funcio-nalidade. No projeto piloto P2 outros defeitos foram detectados e a lista de defeitos dodocumento OPER foi novamente atualizada. Com relação ao documento ATM, no en-tanto, nenhum novo defeito foi identificado durante o estudo. Além disso, durante essaatividade conduzida junto à empresa, percebeu-se a necessidade de várias outras infor-mações que seriam muito relevantes para se poder fazer uma análise da efetividade datécnica na detecção de defeitos. Tais informações são: a classificação dos defeitos emrelação à dificuldade de detecção por pessoas conhecedoras do domínio da aplicação ounão; a classificação dos defeitos em relação à sua dependência ao domínio de aplicação; ea probabilidade das questões levarem à detecção dos defeitos. Além disso, um novo tipode defeito foi acrescentado à taxonomia, relativo ao uso de informação em local erradodo documento.

Salienta-se que em todas essas replicações, inclusive no estudo na empresa, a coleta,armazenamento e análise dos dados foi toda realizada de forma manual. Isso provocouuma demanda de tempo muito grande, pois o entendimento da caligrafia dos participantesdemandava muito esforço. Além disso, essa atividade era muito propensa a erros, tantono entendimento, como na passagem dos dados para as planilhas nas quais eles eramarmazenados. A forma de armazenamento também dificultou a análise dos dados, poisuma meta-análise ou análise visual necessitaria dos dados estruturados em uma base dedados que permitisse uma fácil manipulação e relacionamento entre eles.


3.3.6 Síntese das mudanças e vantagens do apoio computacional

Ao longo da realização das 4 replicações e de um trabalho de transferência tecnológica, opacote de laboratório foi evoluindo por meio de mudanças de formulários, acréscimo de do-cumentos de especificação de requisitos, alterações no treinamento das técnicas e ajustes noprojeto experimental. No Quadro 3.10 são apresentadas as mudanças ocorridas ao longo dessasreplicações e da experiência de transferência tecnológica, na qual foi necessária a instanciaçãodo pacote de laboratório para a empresa (Höhn, 2003).

Quadro 3.10: Evolução do pacote de laboratório PBR

Evento TécnicasModelosadjacentes

Treinamento ProcedimentoDoc.Requisito.

Formulários

OriginalPBR;Usual daNASA

Designer; User:Diagrama Casosde Uso; Tester:Análise ValorLimite

Doc. Req.ABC Video

2 dias

NASA A,NASA B,ATM ePG

Formulárioslistados naSubseção 3.2.1

R1PBR;Checklist

Designer: DFD;User: DiagramaCasos de Uso;Tester: AnáliseValor Limite

Adaptação doForm. Feedback;Criação doForm.Caracterizaçãodo Perfil

R2- - -

4 dias- Alteração no

Form. de Coletade Defeitos

R3

- -Alteração notempo;Alteração nomaterial;Doc. Req.Gas Station

3 dias

- Alteração noForm.Caracterizaçãodo Perfil;Alteração noForm. Coleta deDefeitos

R4- - -

2 dias (igualR1)

- -

Instanciaçãoparaempresa

-Tester: ErrorGuessing

Alteração dotreinamentopara Tester

Novoprocedimento

DomínioespecíficoOPER

-

Uma ferramenta pode proporcionar apoio computacional em diversas etapas do processo ex-perimental, apresentando vantagens em relação ao processo manual, como: (i) armazenamentodurante a coleta dos dados do experimento; (ii) validação das informações dos participantesdurante a execução do experimento; (iii) uso de documentos de maneira eletrônica, evitandogrande volume de papéis; (iv) execução de experimentos remotos ou distribuídos (no caso de


ferramentas Web); (v) manutenção de histórico dos materiais utilizados e suas alterações; e (vi)controle da execução do experimento, liberando para os participantes o material necessário àcada etapa.


Neste capítulo foi abordado o Experimento PBR baseado em documentos de requisitos parao qual a ferramenta desenvolvida neste trabalho fornece apoio automatizado. Esse experimentoavalia a técnica de leitura PBR (Perspective Based Reading) com relação à efetividade e eficáciaem revelar defeitos. Sendo a PBR uma das técnicas possíveis para se fazer inspeção do docu-mento de requisitos, o estudo e a caracterização dessa técnica em relação a outras alternativas,como o Checklist, é de fundamental importância para fornecer aos desenvolvedores subsídiosque os permitam fazer uma escolha adequada de qual técnica utilizar. Essa caracterização éconseguida por meio da replicação de estudos experimentais, como foi comentado no Capí-tulo 2. Quanto maior o número de replicações e maior o volume de dados que confirme umresultado, maior confiança se pode ter na caracterização da técnica. As replicações do Expe-rimento PBR realizadas no contexto do Projeto Readers pelo ICMC/USP e UFSCar tambémforam comentadas neste capítulo. Essas replicações auxiliaram a obtenção de mais dados, arespeito das técnicas utilizadas bom como um maior conhecimento do próprio processo de ex-perimentação adotado na realização desse experimento. Com isso, percebeu-se a necessidadede várias adaptações do pacote de laboratório, o que levou a uma evolução dos mesmos, sendoque muitas dessas adaptações, como alterações de formulários, por exemplo, teriam sido maisfacilmente gerenciadas com o apoio de uma ferramenta. Além disso, todos os dados relativos aessas replicações foram coletados e analisados manualmente, sendo esta uma atividade demo-rada e trabalhosa. Se houvesse o apoio de uma ferramenta, muito do trabalho manual poderia tersido evitado. No próximo capítulo será apresentada a ferramenta ExpVVT, desenvolvida nestetrabalho, cujo objetivo é dar apoio à condução do Experimento PBR e de suas replicações.

CAPÍTULO

4A ferramenta ExpVVT


Como visto nos capítulos anteriores, a condução de experimentos e replicações gera umagrande quantidade de dados. Além disso, essa atividade implica um extenso trabalho manual,tanto da parte dos pesquisadores, quanto dos participantes, gerando um grande volume de in-formações, o que consome muito tempo e dificulta a execução de replicações com o objetivode validar e generalizar os resultados. A condução manual pode levar também à ocorrênciade erros, o que pode comprometer os resultados. Sendo assim, como já foi mencionado noCapítulo 1, o objetivo deste trabalho foi o desenvolvimento de uma ferramenta Web que apoi-asse a condução do Experimento PBR e suas replicações, a qual é denominada ExpVVT e seráapresentada neste capítulo. Para desenvolvimento desta ferramenta foi utilizada a metodologiaWeb Application Extension for UML (WAE) (Conallen, 2003). Ressalta-se que a ExpVVT éuma ferramenta desenvolvida dentro do escopo do Projeto Readers, fazendo parte, portanto, daarquitetura de apoio computacional apresentada anteriormente.

Este capítulo está organizado da seguinte maneira: inicialmente, na Seção 4.2, é apresen-tada uma breve descrição da ferramenta e de suas principais funcionalidades. Na Seção 4.3aborda-se a arquitetura da ferramenta e na Seção 4.4 sua modelagem, na qual são apresentadosos diagramas que foram construídos para auxiliar o seu desenvolvimento. Na Seção 4.5 sãodescritos alguns detalhes referentes à implementação da ferramenta e na Seção 4.6 apresenta-seum exemplo de uso da mesma, com base nos dados referentes à replicação R1 sintetizada nocapítulo 3, mencionando ainda como pode ser feita a integração com outras ferramentas, comopor exemplo ferramentas de análise estatística e de análise visual.

49

50 CAPÍTULO 4. A FERRAMENTA EXPVVT

4.2 Objetivos da ferramenta

A ExpVVT tem por objetivo apoiar as fases de Planejamento e Operação do processo ex-perimental definido por Wohlin et al. (2000) (Figura 4.1), especificamente para o ExperimentoPBR, guiando os usuários nos passos necessários para a realização desse experimento, desdesua criação até a coleta dos dados resultantes da fase de operação do experimento propriamentedita, realizada pelos participantes. A ExpVVT também auxilia o registro das demais informa-ções que compõem o pacote de laboratório, formando assim uma base de dados histórica comas informações referentes ao experimento e às replicações do mesmo.



? ?

Base de Experimento

ExpVVT

Figura 4.1: Fases do processo experimental que há apoio da ferramenta ExpVVT.

Considerando a fase de Planejamento do processo experimental, a ExpVVT apóia as se-guintes atividades:

• Registro das hipóteses, variáveis e restrições à validade;

• Seleção da técnica que será utilizada em contrapartida com a PBR;

• Seleção das perspectivas PBR que serão utilizadas;

• Seleção dos documentos que serão inspecionados;

• Registro da lista inicial de defeitos para cada documento.

• Seleção de participantes;

4.3. ARQUITETURA 51

• Definição do projeto experimental.

Na fase de Operação, a ExpVVT guia os participantes do experimento, disponibilizandoos formulários que devem ser preenchidos no momento correto. Os formulários utilizados naExpVVT são:

• Formulário de consentimento;

• Formulário de perfil; e

• Formulário de coleta de defeitos:

Após a finalização da fase de Operação, ou seja, depois que os participantes já aplicaramas técnicas e relataram os possíveis defeitos do documento de requisitos, cabe ao responsávelpelo experimento (projetista ou replicador) classificar os defeitos reportados, identificando sesão defeitos reais, falsos positivos ou não defeitos.

Outra característica da ExpVVT é permitir a importação de dados gerados por outras ferra-mentas que apóiem as mesmas fases do processo de experimentação ou que auxiliem algumadas etapas da execução do experimento pelos participantes, como por exemplo a PBR Tool,mencionada no Capítulo 2, que apóia especificamente a aplicação da técnica de leitura PBR. Aspróximas seções são dedicadas à descrição dos artefatos gerados durante o desenvolvimento.

4.3 Arquitetura

A arquitetura da ExpVVT é apresentada na Figura 4.2, na qual observa-se a comunicaçãoentre os vários módulos que compõem a ferramenta. Como pode ser observado nessa figura,a ExpVVT foi projetada utilizando o padrão de projeto MVC (Model View Controller) quesepara a lógica de negócio da interface. No projeto da ferramenta buscou-se a segmentação emcamadas que refletissem as principais funcionalidades da ExpVVT.

Na camada superior está a Interface Web, responsável pela interação entre os usuários e osistema. Abaixo da camada de interface está o módulo de controle de usuários, responsável pelacriação de usuários, autenticação (identificação dos usuários do sistema) e autorização (controledos recursos e operações que um usuário autenticado terá permissão de acesso). A autorizaçãoé realizada a partir de grupos de usuários, conforme os papéis que eles podem assumir, os quaisestão descritos na Subseção 4.4.3.

Logo abaixo está a camada responsável pelo fluxo de condução de um experimento. Esseworkflow está baseado no processo de experimentação apresentado por Wohlin et al. (2000) eadaptado por Amaral (2003). Essa camada é responsável pela criação de um experimento como registro das informações necessárias à condução do mesmo e à geração do pacote de labora-tório. Além disso, é por meio dessa camada que se controla a replicação de um experimento,utilizando o pacote de laboratório armazenado na base de dados.


Workflow do experimento

Interface Web

Módulo de controle de usuário

Módulo de definição

Módulo de planejamento

Módulo de operação

Módulo de análise

Módulo de visualização de

experimento

Base de dados

XML de definição

XML de planejamento

XML de operação

XML do experimento

Figura 4.2: Arquitetura da ferramenta ExpVVT.

O Módulo de visualização de experimento é responsável por coletar as informações referen-tes a um experimento do modelo lógico, montando a estrutura desse experimento, para que essepossa ser visualizado pelos usuários do sistema.

As informações coletadas são registradas na base de dados (Subseção 4.4.2) e em docu-mento XML. Documentos XML também são utilizados como entrada de dados para os módulosdo workflow do experimento, servindo como interface para integração com outras ferramentasque auxiliem as fases do processo de experimentação. Os dados armazenados na base de da-dos podem ser exportados para documentos XML a utilizado por ferramentas estatísticas e deanálise visual, como por exemplo as ferramentas Spotfire1 e Minitab2, auxiliando a análise dosdados coletados.

4.4 Modelagem

Como já foi dito anteriormente, a modelagem da ExpVVT foi elaborada com a metodolo-gia Web Application Extension for UML (WAE), que foi escolhida pelo fato dessa metodologiautilizar uma extensão da UML para modelar as aplicações Web. Nessa metodologia, a nota-ção UML é estendida com semânticas e restrições adicionais para permitir a modelagem deelementos da arquitetura específica da Web como parte do modelo do sistema.

1http://www.spotfire.com2http://www.minitab.com

4.4. MODELAGEM 53

4.4.1 Modelo conceitual

O modelo conceitual da ExpVVT é apresentado na Figura 4.3. Esse modelo captura asinformações essenciais para o planejamento e condução de um experimento, sendo definido apartir da experiência obtida pelo grupo na condução de experimentos e replicações. De acordocom a figura, um Experimento é composto pela Definição e Planejamento. Na Definição doexperimento, deve-se definir quais as Questões o experimento pretende responder. Para cadaQuestão, deve-se registrar a hipótese nula (h0) e as hipóteses alternativas. No Planejamento édefinido o conjunto de Documentos que serão inspecionados, a Técnica que serão utilizada emcontrapartida com a PBR, as Perspectivas da PBR e os Participantes, responsáveis pela coletade dados. Para cada documento, deve-se montar uma lista inicial de Defeitos. Cada defeitodeve ser classificado conforme seu tipo. No Projeto Experimental é definido qual Técnica ouPerspectiva PBR o Participante irá aplicar na inspeção de Documento. Na fase de operaçãoo Participante irá Reportar os Defeitos encontrados nos Documentos inspecionados. A partirdesses dados coletados, análises estatísticas e visuais são realizadas.

Perfil

questão : Questãoresposta : String

Questões do experimento

descrição : Stringh0 : Stringha : List <String>

Definição

objetivo global : Stringobjeto de estudo : Stringpropósito : Stringfoco de qualidade : Stringperspectiva : Stringcontexto : Stringquestão : Questões do experimentometrica : List <String>

Instituição

nome : Stringsigla : String

Usuário

nome : Stringemail : Stringinstituição : Instituiçãotelefone : Stringpapel : Papel

Experimento

atividade : booleandata : Datedefinição : Definiçãodescrição : Stringdomínio : Stringidioma : Stringplanejamento : Planejamentoreplicação : Experimentopesquisador : Usuárioárea técnica : Stringtema : Stringnome : Stringtipo : Stringparceiro : List <Instituição>

Questionário

questão : Lista <Questão>

Artefato

nome : Stringdescrição : Stringarquivo : String

Perspectiva

nome : Stringdescrição : Stringapoio ferramental : booleannome da ferramenta : String

Planejamento

variável independente : List <String>variável dependente : List <String>validade interna : List <String>validade externa : List <String>validade de conclusão : List <String>validade de construção : List <String>procedimento de execução : Stringmecanismo de análise : Stringrestrição : List <String>configuração : Configuraçãoquestionário : List <Questionário>

Técnica

nome : Stringdescrição : Stringapoio ferramental : booleannome da ferramenta : String

Treinamento

instrutor : Stringprocedimento : Stringartefatos : List <Artefato>

Questão

descrição : String

Configuração

primeiro documento : Documentosegundo documento : Documentoordem de execução : EnumerationPBR : Técnicaoutra técnica : Técnicatreinamento : Treinamentoparticipante : Participante

Projeto experimental

documento : Documentoperspectiva : Perspectivaparticipante : Participantetécnica : Técnica

Defeito Reportado

comentário : Stringstatus : Enumeration

Participante

apelidogrupodefeito reportado : Defeito Reportado

Documento

nome : Stringarquivo : String

Taxonomia

nome : Stringdescrição : String

Defeito

descrição : Stringpage : intrequisito : Stringtipo : Taxonomia

File: C:\Documents and Settings\Bira\Desktop\diagramas\diagramas expvvt.mdl 22:07:30 domingo, 18 de junho de 2006 Class Diagram: Logical View/ Diagrama conceitual Page 1

Figura 4.3: Diagrama conceitual.

4.4.2 Base de dados

Na Figura 4.4 é apresentada a base de dados da ferramenta, a qual está dividida em duaspartes: modelo físico e modelo lógico.


experiment

PK title

dateFK1 researcher

descriptionthemetechinicalAreatypedomainlanguageglobalObjectiveobjectOfStudypurposequalityFocusperspectivecontextexecutionProcedureanalysisMechanismsrestrictionstatus

FK2 replication

partner

PK,FK1 experimentTitlePK,FK2 partnerId

TBInstitution

PK id

nameacronym

TBRole

PK id

name

TBUser

PK email

namepasswordphone

FK1 institutionFK2 role

designerCandidatereplicatorCandidate

Modelo Físico: controle de usuário

TBActivity

PK id

description

TBWorkflow

PK,FK1 activityIdPK,FK2 experimentName

status

Modelo Físico: controle de workflowTBTable

PK id

namedescription

TBField

PK id

namedescriptionpk

FK2 fk_tableFK3 fk_fieldFK1 tab_id

type

TBData

PK id

FK1 field_idrecord

TBDate

PK,FK1 id

dataTBNumber

PK,FK1 id

dataTBText

PK,FK1 id

data

Modelo Físico: meta-modelo

questionnaire

PK id

FK1 experimentNameFK2 questionId

typesequence

question

PK id

question

participant

PK,FK2 userEmailPK,FK1 experimentName

alias

profile

PK,FK2 userEmailPK,FK2 experimentNamePK,FK1 questionId

answer

configuration

PK,FK1 userEmailPK,FK1 experimentNamePK,FK3 documentIdPK,FK4 techniqueId

FK2 perspectiveIdsequencestatus

perspective

PK id

FK1 techniqueIdnamefiletool

technique

PK id

namefile

training

PK id

FK1 techniqueIdinstructorartifact

document

PK id

namefile

defect

PK id

FK1 documentIdpagerequirementdescription

FK2 type

falsePositive

PK,FK1 id

documentIddescription

reported defect

PK id

FK3 userEmailFK3 experimentNameFK3 documentIdFK3 techniqueIdFK1 defectIdFK2 falsePositive

nonDefectdescriptioncommentstaxonomy

PK id

namedescription

variable

PK id

FK1 experimentTitledescriptiontype

validity

PK id

FK1 experimentTitledescriptiontype

experimentQuestion

PK id

descriptionh0

FK1 experimentTitle

metric

PK id

FK1 experimentTitledescription

hypothesis

PK id

FK1 questionIddescription

artifact

PK id

FK1 trainingIdartifact

Figura 4.4: Modelos físico e lógico da base de dados.

4.4. MODELAGEM 55

O modelo físico está sub-dividido em:

• Controle de usuário → Nessas tabelas estão os registros referentes aos usuários cadas-trados na ExpVVT (tabela TBUser), assim como a associação de cada usuário com umpapel (tabela TBRole) dentro do sistema. Cada usuário está associado a uma instituição(tabela TBInstitution);

• Controle de workflow → As tabelas TBActivity e TBWorkflow são as tabelas que armaze-nam as atividades de um experimento, registrando quais atividades já foram conduzidase quais estão pendentes.

• Meta-modelo → São as tabelas responsáveis pelo registro da estrutura do modelo lógico.Cada tabela do modelo lógico é um registro da tabela (TBTable) do meta-modelo, assimcomo cada atributo das tabelas lógicas é um registro da tabela TBField. Dessa forma, épossível criar meta-estruturas para um experimento e conduzir experimentos com estru-turas diferentes sem alterar a base de dados física.

Os dados dos experimentos conduzidos são armazenados na tabela TBData, mais espe-cificamente nas tabelas TBText, TBDate e TBNumber, a depender do tipo de dado (texto,data ou numérico).

Uma vantagem da utilização de meta-modelo para a elaboração da base de dados é que aestrutura do modelo físico fica inalterada com mudanças entre as replicações e os experimentosoriginais, mas o modelo lógico consegue acompanhar essa evolução. Com essa abordagem nãoé necessário alterar o modelo físico a cada alteração na estrutura do experimento, uma vez quepara cada nova tabela no modelo lógico um novo registro é inserido na tabela TBTable do meta-modelo (destaque da Figura 4.4), acontecendo o mesmo para novos atributos e relacionamentosno modelo lógico

Uma desvantagem da utilização de meta-modelo é a alta quantidade de acessos ao banco dedados para registrar ou obter dados das tabelas lógicas, pois para montar um registro com osdados de uma tabela lógica é necessário fazer n consultas ao banco de dados, sendo n a quan-tidade de atributos da tabela lógica. Considere, por exemplo, a tabela lógica taxonomy. Paraobter os dados de um registro dessa tabela é necessário fazer três consultas (uma consulta paracada atributo) à tabela física TBData. Essa quantidade de consultas ocasiona uma diminuiçãono tempo de resposta do sistema em relação ao modelo tradicional de banco de dados.

O modelo lógico utilizado pela ExpVVT foi definido a partir do modelo conceitual apresen-tado anteriormente. O script de criação da base de dados (modelo físico e lógico) se encontrano Apêndice A.

4.4.3 Atores

Foram estabelecidos quatro papéis para os usuários do sistema:


1. Administrador → Responsável por definir um usuário como projetista ou como replica-dor;

2. Projetista → Responsável pela criação de um novo experimento.

3. Replicador → Responsável pela replicação de um experimento utilizando o pacote delaboratório criado pelo projetista. Pode-se fazer alterações no experimento ao replica-lo,conforme apresentado anteriormente na Subseção 2.3.6 e nos exemplos de replicações doExperimento PBR no Capítulo 3. Por exemplo, é possível alterar em uma replicação asperspectivas da PBR que serão utilizadas.

4. Participante → Responsável pela execução do experimento, conforme este foi planejado.

Esses papéis foram organizados de forma hierárquica, seguindo a ordem em que foramapresentadas acima. Foi definido dessa forma, pois um usuário pode atuar em papéis diferentesdependendo do experimento, por exemplo, um usuário que seja replicador em um experimentopode atuar como participante em outro experimento. Sendo assim, esse usuário terá tanto avisão de replicador quanto a visão de participante em relação ao sistema, mas em relação aum determinado experimento esse usuário só poderá ter uma visão. Sendo assim, não é ne-cessário criar mais de um usuário no sistema para que uma pessoa exerça papéis diferentes emexperimentos diferentes.

4.4.4 Diagrama de caso de uso

O Diagrama de caso de uso geral do sistema é apresentado na Figura 4.5. A seguir serádetalhado cada caso de uso:

• Cadastrar-se no sistema: O usuário registra-se ao sistema, sendo associado ao papel departicipante. Caso o usuário queira realizar ações relacionadas a outro papel, deve-sesolicitar a mudança de papel (caso de uso Solicitar mudança de papel).

• Alterar dados pessoais: O usuário pode alterar seus dados pessoais como, por exemplo,e-mail, telefone e senha.

• Solicitar mudança de papel: Usuários podem solicitar mudança de papel no sistema. Comisso, por exemplo, é possível que um usuário altere seu papel de participante para repli-cador, podendo replicar experimentos a partir da alteração de papel.

• Alterar papel de usuário: Cabe ao administrador a decisão de alterar o papel de um usuá-rio. Com essa alteração o usuário pode realizar operações associadas ao novo papel dousuário.

• Criar experimento: O projetista define e planeja a condução de um novo experimento.

4.4. MODELAGEM 57

Alterar dados pessoais

Cadastrar-se no sistema

Usuário

Aplicar experimento/replicação

Alterar papel de usuárioParticipante

Criar experimento

Editar experimento

Remover experimento

Projetista

Solicitar mudança de papel

Visualizar experimento/replicação

Replicar experimentoEditar replicação

Remover replicação

Inserir informações de análise

Classificar defeitos reportados

Replicador

Administrador

Gerar backup

File: C:\Documents and Settings\Bira\Desktop\diagramas\usecase.mdl 00:45:13 sexta-feira, 23 de junho de 2006 Use Case Diagram: Logical View / UseCase Geral Page 1

Figura 4.5: Diagrama de caso de uso do sistema.

• Editar experimento: O projetista pode alterar e/ou completar informações referentes a umexperimento.

• Remover experimento: Ocorre a remoção lógica do experimento na base de dados.Decidiu-se fazer uma remoção lógica para não gerar inconsistência entre experimentose replicações na base de dados, além de não perder completamente os dados referentesa experimentos já conduzidos. A remoção ocorre alterando o atributo status da tabelaexperiment

• Visualizar experimento/replicação: As informações de um experimento/replicação sãoapresentadas ao usuário.

• Replicar experimento: Ocorre a replicação de um experimento registrado na base de da-dos.

• Editar replicação: As informações referentes à replicação podem ser alteradas ou com-plementadas.

• Remover replicação: Assim como a remoção de um experimento, a remoção de umareplicação ocorre de forma lógica.


• Aplicar experimento/replicação: Esse caso descreve a condução do experimento/repli-cação conforme planejado. Durante a condução formulários são disponibilizados pelaferramenta aos participantes ocorrendo a coleta dos dados com o preenchimento dos for-mulários.

• Inserir informações de análise: Os dados de análise são colocados em arquivos e sãoarmazenados no sistema. Esses dados de análise complementam o pacote de laboratóriodo experimento.

• Classificar defeitos reportados: Após a coleta dos dados pelos participantes, o projetis-ta/replicador deverá analisar os defeitos reportados e classifica-los como defeitos reais,falsos positivos ou não defeitos.

• Gerar backup: Cabe ao administrador gerar periodicamente backup das informações con-tidas na base de dados.

4.4.5 Diagrama de atividades

De um modo geral, as atividades que devem ser realizadas desde a definição até a análisedos dados são apresentadas na Figura 4.6.

ParticipanteProjetista

Identificar experimento Definir experimento

Planejar experimento Aplicar experimento

Analisar experimento

Figura 4.6: Diagrama de atividades referente ao workflow da condução de experimentos.

A atividade de planejamento é detalhada na Figura 4.7. Como já apresentado anteriormente,é nessa atividade que é definido como ocorrerá a condução do experimento.

As atividades realizadas pelo participante na condução do experimento são detalhadas naFigura 4.8.

4.4. MODELAGEM 59

Preencher hipóteses, variáveis e restrições

à validade

Definir técnicas e perspectivas PBR

Definir projeto experimental

Selecionar participantes

Definir treinamentoDefinir documentos

Figura 4.7: Diagrama de atividades referente ao planejamento do experimento.

Preencher formulário de

consentimento


perfil

Realizar treinamento

Aplicar técnicaDisponibilizar documento


feedback

Figura 4.8: Diagrama de atividades referente à execução do experimento.

4.4.6 Mapa do caminho de navegação

Um dos modelos que compõem a metodologia WAE é o mapa do caminho de navegaçãode nível superior para uma aplicação Web. No mapa de navegação é fornecida uma visão geralda estrutura de navegação da aplicação, utilizando uma extensão para a UML. São criados doisestereótipos nessa extensão: «screen» representando uma página e «input form» representandoos formulários para a entrada de dados. Um formulário de entrada pode ser representado poruma classe de associação entre as páginas ou como uma classe contida (Conallen, 2003).

Na Figura 4.9 é apresentada parte do mapa do caminho de navegação do módulo de controlede usuário. A partir da tela inicial é possível navegar para a tela de cadastro de usuário, na qualos usuários irão preencher seus dados pessoais para registrar-se ao sistema. A partir da telainicial também é possível solicitar uma nova senha, caso a senha anterior seja perdida. Decidiu-se, com o intuito de obter uma maior segurança ao sistema, atribuir uma nova senha ao usuário.Essa nova senha é enviada para o e-mail do usuário cadastrado no sistema.

Na Figura 4.10 é apresentado o mapa do caminho de navegação dos módulos de definiçãoe planejamento do sistema, representando a criação de um experimento. Inicialmente o experi-mento é identificado com o registro de um nome para o experimento, tema, parceiros, etc. Napágina de definição é registrado o objetivo global, o modelo de meta, as questões e as métricasutilizadas. Da página de definição deve-se navegar para a página de registro das hipóteses evariáveis. Depois são selecionados os participantes dos experimentos, os documentos que serão


Nova instituição<<screen>>

Formulário da instituição<<input form>>

Formulário do usuário<<input form>>

Novo usuário<<screen>>

Usuário adicionado<<screen>>

Home<<screen>>

Esqueceu senha<<screen>>

Senha enviada por email<<screen>>

Formulário de nova senha<<input form>>

File: C:\Documents and Settings\Bira\Desktop\diagramas\diagramas expvvt.mdl 22:06:45 domingo, 18 de junho de 2006 Class Diagram: Logical View/ Navegação Inicial Page 1

Figura 4.9: Mapa do caminho de navegação.

inspecionados, as perspectivas da PBR que serão utilizadas e o projeto experimental. Por fim,o planejamento do experimento é visualizado e finalizado. Esse mapa de navegação está emconsonância com o processo de condução de experimento controlado apresentado na Seção 2.3.O que difere entre a criação e a replicação de um experimento em termos da ferramenta é quena replicação deve-se escolher inicialmente o experimento que será replicado.

Estes diagramas e todos os outros elaborados no desenvolvimento deste trabalho encontram-se num documento de trabalho que contém a descrição da modelagem e implementação daferramenta ExpVVT (Maltez Jr., 2006). A partir dessa modelagem o sistema foi implementado.A seguir são discutidas algumas questões relativas à implementação do ambiente.

4.5 Implementação

Conforme citado na Seção 4.3, a ExpVVT foi projetada seguindo a arquitetura MVC (Model

View Controller), com o intuito de melhor dividir a interface da lógica de negócios. Como lin-guagem de desenvolvimento foi escolhida a linguagem Java por ser uma linguagem com grandebiblioteca, o que facilita a implementação de certos recursos, como a leitura de arquivos XML.Para apoiar a implementação utilizando a arquitetura MVC, decidiu-se utilizar o framework Ja-

vaServer Faces (JSF) (Sun Microsystems, 2006). A principal vantagem da utilização do JSF éa facilidade com que ele trata a separação entre a lógica e apresentação da aplicação.

Foi utilizado o MySQL (MySQL AB, 2006) como Sistema Gerenciador de Banco de Dados(SGBD), pois atende às necessidades referentes à criação do modelo físico e lógico da basede dados, assim como mostrado anteriormente. O servidor de aplicações Web utilizado foi oTomcat que é um container Web livre e de código aberto desenvolvido dentro do projeto ApacheJakarta (The Apache Software Foundation, 2006). O ambiente de desenvolvimento utilizadofoi o Eclipse (The Eclipse Foundation, 2006) juntamente com o plugin Exadel Studio (Exadel,2006).

4.5. IMPLEMENTAÇÃO 61

Identificação<<screen>>

Formulário de identificação<<input form>>

Definição<<screen>>

Formulário de definição<<input form>>

Hipóteses e Variáveis<<screen>>

Formulário de hipóteses e variáveis<<input form>>

Seleção de participantes<<screen>>

Formulário de seleção de participantes<<input form>>

Formulário de seleção de documento<<input form>>

Seleção de documento<<screen>>

Registrar defeito<<screen>>

Formulário de registro de defeitos<<input form>>

Lista inicial de defeitos<<screen>>

Seleção de técnica<<screen>>

Registrar perspectiva<<screen>>

Formulário de registo de perspectiva<<input form>>

Projeto experimental<<screen>>

Formulário do projeto experimental<<input form>>

Finalizar planejamento<<screen>>

Visualizar experimento<<screen>>

Formulário de seleção de técnicas<<input form>>

Lista de Perspectiva PBR<<screen>>

File: C:\Documents and Settings\Bira\Desktop\diagramas\diagramas expvvt.mdl 22:08:12 domingo, 18 de junho de 2006 Class Diagram: Logical View / Navegação - Criação de experimento Page 1

Figura 4.10: Mapa do caminho de navegação de criação de experimento.

Foram implementadas 53 classes no desenvolvimento da ExpVVT, divididas entre os módu-los conforme apresentado na Tabela 4.5, sendo um total de 5999 linhas de código. Ressalta-seque a camada de apresentação foi desconsiderada nessa contagem.

Tabela 4.1: Esforço da implementação da camada de modelo do ambiente ExpVVT.

Módulos N o Classes N o LOCControle de usuário 9 710

Workflow e visualização do experimento 30 4173Classes de suporte 14 1116

Total 53 5999

Com o intuito de importar dados gerados por outras ferramentas, como por exemplo a PBRTool, foram definidos neste trabalho três documentos XML, conforme apresentado na arquite-tura da ExpVVT (Figura 4.2 - Seção 4.3). Esses documentos XML definem os dados de entradanecessários para os módulos de definição, planejamento e operação. Na Listagem B.1 é exem-plificado o DTD (Document Type Definition) que descreve o formato do documento XML deentrada do Módulo de Definição. Os DTDs dos outros documentos XML são apresentados noApêndice B. Foi definido também um documento XML com as informações referentes a umexperimento registrado na base de dados. Esse documento XML do experimento foi definido apartir da junção dos documentos de entrada.


Listagem 4.1: DTD que descreve o documento XML de entrada do Módulo de Definição<!ELEMENT experiment ( definition ) >

<!ATTLIST experiment title CDATA #REQUIRED >

<!ELEMENT definition ( identification, characterization, globalObjective, specificAims,

questions, metrics ) >

<!ELEMENT identification ( description, theme, technicalArea, researcher, date ) >

<!ELEMENT description ( #PCDATA ) >

<!ELEMENT theme ( #PCDATA ) >

<!ELEMENT technicalArea ( #PCDATA ) >

<!ELEMENT researcher ( name, email, institution ) >

<!ELEMENT name ( #PCDATA ) >

<!ELEMENT email ( #PCDATA ) >

<!ELEMENT institution ( #PCDATA ) >

<!ELEMENT date ( #PCDATA ) >

<!ELEMENT characterization ( type, domain, language, partners ) >

<!ELEMENT type ( #PCDATA ) >

<!ELEMENT domain ( #PCDATA ) >

<!ELEMENT language ( #PCDATA ) >

<!ELEMENT partners ( institution* ) >

<!ELEMENT globalObjective ( #PCDATA ) >

<!ELEMENT specificAims ( objectOfStudy, purpose, qualityFocus, perspective, context ) >

<!ELEMENT objectOfStudy ( #PCDATA ) >

<!ELEMENT purpose ( #PCDATA ) >

<!ELEMENT qualityFocus ( #PCDATA ) >

<!ELEMENT perspective ( #PCDATA ) >

<!ELEMENT context ( #PCDATA ) >

<!ELEMENT questions ( question+ ) >

<!ELEMENT question ( #PCDATA ) >

<!ELEMENT metrics ( metric+ ) >

<!ELEMENT metric EMPTY >

<!ATTLIST metric description CDATA #REQUIRED >

<!ATTLIST metric metric CDATA #REQUIRED >

Com a finalidade de garantir que a ExpVVT se comunique de forma transparente com outrasferramentas é necessária a utilização de uma ferramenta de integração que fará transformaçõesestruturais e semânticas nos dados dos documentos XML, como por exemplo a ferramentaxMapper desenvolvida no contexto do Projeto Readers, mencionada no Capítulo 2. Exemplifi-cando a integração entre as ferramentas, caso o participante de um experimento utilize a ferra-menta PBR Tool para apoiar a aplicação da técnica PBR, um documento XML descrevendo asdiscrepâncias encontradas é produzido pela ferramenta. O documento XML gerado pela PBR

Tool é transformado utilizando a ferramenta de integração, e moldado conforme o documentode entrada para o módulo de operação da ExpVVT.

4.6 Aspectos operacionais

Esta seção descreve os aspectos operacionais de ferramenta ExpVVT. A tela inicial da fer-ramenta é apresentada na Figura 4.11. Nessa tela o usuário realiza a autenticação no sistema,utilizando um e-mail previamente cadastrado e uma senha.

Caso o usuário ainda não seja cadastrado no sistema, é necessário preencher o formulário decadastro, conforme a tela apresentada na Figura 4.12. É solicitados ao usuário informar nome,

4.6. ASPECTOS OPERACIONAIS 63

Figura 4.11: Tela de autenticação.

e-mail, telefone e instituição. Caso a instituição não esteja na lista, deve-se cadastrar uma novainstituição (Figura 4.13). O cadastro da instituição é realizado pelo próprio usuário no momentodo cadastro.

O sistema irá atribuir automaticamente o papel de participante ao usuário. Caso o usuáriodeseje atuar como projetista ou replicador, ele deverá marcar a opção correspondente na tela decadastro. Caberá ao administrador do sistema alterar o papel do usuário. Essa alteração de papeltambém pode ser solicitada posteriormente. Ao cadastrar-se no sistema, um e-mail é enviadoao usuário com a senha de acesso.

Ao realizar a autenticação no sistema, o usuário irá visualizar a tela da Figura 4.14. Essa telaapresenta todos os experimentos associados ao usuário. Nessa tela também é possível excluiros experimentos. Observa-se que só é possível excluir experimentos nos quais o usuário temparticipação como projetista ou replicador.

Foi definido um status para os experimentos/replicações, com a finalidade de representar asituação corrente desse experimento/replicação. Os status definidos foram:

• Em edição: A fase de planejamento ainda não foi concluída;

• Em execução: Está esperando a finalização da coleta de dados pelos participantes; e

• Análise: Os defeitos reportados devem ser analisados de classificados como defeitos re-ais, falsos positivos ou não defeitos.


Figura 4.12: Tela de cadastro de usuário.

Figura 4.13: Tela de cadastro de instituição.


Figura 4.14: Tela principal.

• Finalizado: O experimento está concluído.

Será exemplificada a criação de um experimento utilizando os dados do pacote de laborató-rio da Replicação 1, descrita no Capítulo 3. Para criar um experimentos deve-se, inicialmente,identificar o experimento, conforme apresentado na Figura 4.15. Deve ser dado um nome aoexperimento, além de descrição, tema, tipo (in vivo, in vitro, in virtuo ou in silico (Travassos eBarros, 2003)), domínio, idioma e instituições parceiras.

Após a identificação, o experimento deve ser definido registrando o objetivo global, modelode meta, questões que devem ser respondidas e métricas (Figura 4.16).

O passo seguinte é o planejamento o experimento. Para cada questão que foi definida, deve-se criar uma hipótese nula e uma ou mais hipóteses alternativas (Figura 4.17). Além disso, deve-se registrar as variáveis (independentes e dependentes) e os riscos à validade (interna, externa,conclusão e construção) (Figura 4.18). Nessa tela também deve-se descrever o mecanismo deanálise e as limitações do experimento.

O próximo passo é a escolha dos participantes. Todos os usuários cadastrados no sistemasão listados em uma tela, como mostrado pela Figura 4.19. O projetista/replicador deve entãoselecionar os participantes que aplicarão o experimento.

Após a escolha dos participantes, devem ser selecionados os documentos que serão inspe-cionados. Na Figura 4.20 é apresentada a tela de upload desse artefato. Após o upload do


Figura 4.15: Tela de identificação do experimento.

Figura 4.16: Tela de definicao do experimento.


Figura 4.17: Tela de registro das hipóteses.

documento de requisito, deve-se definir a lista inicial de defeitos desse documento. Pode-se no-tar na Figura 4.21 que cada defeito possui informações como página e requisito do documentono qual esse defeito foi localizado, descrição e tipo. Ao clicar no botão Adicionar Defeito atela da Figura 4.22 é apresentada. Nesta tela o usuário adiciona um defeito ao documento derequisitos. Ao clicar no botão Finalizar documento, o usuário é redirecionado para a tela daFigura 4.20 para poder cadastrar o segundo documento que será utilizado no experimento, e sualista inicial de defeitos.

Ao finalizar a seleção de documentos, o usuário é direcionado para a seleção da técnicaque será utilizada em contra-partida à PBR, conforme apresentado na Figura 4.23. Nessa teladeve-se preencher o nome da técnica e fazer o upload de um documento que a descreva. Casoessa técnica seja apoiada por alguma ferramenta computacional, deve-se marcar a opção Apoio

Ferramental, e definir qual a ferramenta de apoio.

O próximo passo é definir as perspectivas PBR que serão utilizadas no experimento, con-forme apresentado na Figura 4.24. Ao clicar no botão Adicionar Perspectiva, o usuário é dire-cionado para a tela de cadastro de nova perspectiva, tela similar à da Figura 4.23.

Caso o projetista/replicador queira disponibilizar o material de treinamento para download

no momento da aplicação do experimento, deve-se selecionar a opção Treinamento no menu. Atela de upload do treinamento é apresentada na Figura 4.25.

Para finalizar o planejamento do experimento, é necessário definir o projeto experimental.É apresentada na Figura 4.26 a tela que define-se o projeto experimental. Nessa tela deve-sedefinir qual técnica será aplicada primeiro, e qual será o tempo de aplicação das técnicas. Cadaparticipante também é associado a um grupo e a uma perspectiva PBR. A ExpVVT agrupa e as-socia cada participante a uma perspectiva PBR de maneira aleatória, permitindo que o projetistaaltere essa distribuição. Conforme essa figura, um participante que for associado, por exemplo,


Figura 4.18: Tela de registro das variáveis e riscos à validade.


Figura 4.19: Tela de seleção de participantes.


Figura 4.20: Tela de upload do documento de requisito.

Figura 4.21: Tela na qual define-se a lista inicial de defeitos.


Figura 4.22: Tela na qual adiciona defeito a lista inicial de defeitos.

Figura 4.23: Tela na qual define-se a técnica utilizada em contra-partida com a PBR.


Figura 4.24: Tela na qual definem-se as perspectivas PBR.

Figura 4.25: Tela de upload do treinamento.


ao Grupo 2 e à perspectiva User irá aplicar a Técnica Checklist no documento Parking Garage

e a Técnica PBR com a perspectiva User no documento Automated Teller Machine Network.Ao clicar no botão Finalizar Planejamento, um e-mail é enviado aos participantes avisando queeles foram convidados a participar do experimento. Cada participante também recebe um "ape-lido"para que a pessoa não seja identificada no momento de verificação dos defeitos reportados.

Figura 4.26: Tela de definição do projeto experimental.

Ao executar o experimento, o participante deverá reportar os defeitos encontrados nos do-cumentos os quais ele está inspecionando. A lista de defeitos reportados pelo participante éapresentada na tela da Figura 4.27. Para adicionar um novo defeito, o participante deve clicarno botão Adicionar Defeito, sendo direcionado para uma tela similar a da Figura 4.22, ondedeverá preencher as informações sobre o defeito o qual estará reportando. Caso o participanteutilize outra ferramenta de apoio à aplicação das técnicas, o documento XML com os dados dosdefeitos reportados deve ser importado utilizando o campo em destaque na Figura 4.27.


Figura 4.27: Tela com a lista de defeitos reportados.

Finalizada a coleta de dados pelos participantes, o projetista/replicador deverá classificaros defeitos que foram reportados por cada participante. A tela de classificação de defeitosreportados é apresentada na Figura 4.28.

Figura 4.28: Tela com a lista de defeitos reportados.

O procedimento para replicar um experimento é idêntico ao detalhado para a criação doexperimento, com exceção que deve inicialmente escolher qual experimento servirá como basepara a replicação. Em uma replicação, as telas mostradas anteriormente vêm preenchidas comos valores do experimento que está sendo replicado.


Uma outra funcionalidade da ferramenta é a visualização de experimentos, detalhando opacote de laboratório do experimento que está sendo visualizado. A tela com a visualização doexperimento é apresentada na Figura 4.29.

Figura 4.29: Tela com a visualização de um experimento.

Caso o usuário utilize outra ferramenta para a apoiar as fases de Definição e Planejamento,os dados gerados por essas ferramentas devem ser importados para a ExpVVT. A tela de impor-tação de documentos XML é apresentada na Figura 4.30.

Figura 4.30: Tela com a importação de documentos XML.

As informações coletadas na utilização da ferramenta ExpVVT são salvas na base de dadose em um documento XML. Ferramentas estatísticas e de análise visual, como por exemplo as


ferramentas Spotfire e Minitab, podem ser utilizadas para análise dos dados dos experimentos.Porém, as versões atuais dessas ferramentas somente realizam consultas sobre base de dadosou planilhas eletrônicas, não realizando consultas utilizando documentos XML. Assim sendo,existem duas possibilidades para integrar a ExpVVT com essas ferramentas de análise:

• as ferramentas de análise podem fazer consultas diretamente a base de dados da ExpVVT.Porém, nesse caso é necessário que o projetista/replicador tenha conhecimento da estru-tura da base de dados, tanto do modelo físico quanto do modelo lógico.

• pode-se utilizar uma ferramenta que faça o mapeamento do documento XML para umaplanilha ou para uma base de dados que não utilize a abordagem de meta-modelo. Dessaforma, o projetista/replicador não precisaria ter conhecimento da estrutura de meta-modelo, mas somente da estrutura do experimento que está sendo analisado. Um exemplode ferramenta que gera uma base de dados a partir de um documento XML é a ferramentaXML2DB3.

É importante destacar que a validação da ferramenta ExpVVT foi realizada com a inclusãode dados no sistema utilizando como entrada os dados do pacote de laboratório da R1. Arealização de um experimento controlado para aplicar e validar a ferramenta em cenários reaisé uma das atividades futuras a ser conduzida em decorrência deste trabalho.


Neste capítulo foram apresentados a ferramenta ExpVVT e seus conceitos principais. Foramdescritas a arquitetura e a modelagem da ferramenta. Além disso, foi exemplificado o uso daferramenta, demonstrando como ocorre o apoio à condução do Experimento PBR e de suasreplicações. Considerando as fases do processo de experimentação, a ferramenta apóia as fasesde Planejamento e Operação, além de apoiar o registro das informações referentes às outrasfases.

As atividades de cada fase são realizadas por usuários com papéis diferentes. Sendo assim,foram definidos os papéis de projetista - responsável pela criação de um experimento -, replica-dor - responsável pela replicação de experimentos -, e participante - responsável pela execuçãodo experimento. Além desses papéis, existe o papel de administrador, que é responsável pelocontrole de uso da ferramenta.

Como vantagens do apoio da ferramenta na condução do experimento e replicações emrelação a condução manual, pode-se citar a diminuição de custo, pois formulários e documentossão disponibilizados de maneira eletrônica; execução remota do experimento, pois a ExpVVTé uma ferramenta desenvolvida para Web; facilidade na análise dos dados coletados, pois esses

3http://www.telaxion.com/xml2db.html

4.7. CONSIDERAÇÕES FINAIS 77

dados se encontram em uma base de dados que podem ser acessados por ferramentas de análise,além de maior legibilidade desses dados coletados.

No próximo capítulo são apresentados as conclusões e trabalhos futuros que poderão serdesenvolvidos a partir deste trabalho.

CAPÍTULO

5Conclusão

A Engenharia de Software emergiu na década de 70 e vem evoluindo significativamente,procurando estabelecer técnicas, critérios, métodos e ferramentas para o processo de desenvol-vimento de software com qualidade (Pressman, 2005). Porém, uma vez desenvolvidas novasabordagens, a ausência de dados que comprovem a sua eficácia requer o desenvolvimento deestudos que venham a corroborar, ou não, os resultados esperados. A existência de uma basede dados histórica nesse contexto é fundamental como suporte à caracterização da eficácia dasabordagens propostas. No entanto, a formação dessa base consiste em um trabalho alcançadoem longo prazo, pois é preciso uma grande quantidade de dados para que os resultados sejamsignificativos. Assim, é de fundamental importância a condução e a replicação de experimen-tos controlados para que se consiga esse volume dados, de forma a se ter uma base de dadosconsolidada. Essas replicações são apoiadas pela disponibilidade de pacotes de laboratório quedocumentam o experimento.

Um exemplo desse contexto é dado pelo Projeto Readers, no qual replicações de algunsexperimentos foram conduzidas, com o intuito de caracterizar técnicas de VV&T, entre elas, atécnica PBR, que apóia a detecção de defeitos em documentos de requisitos. Esse experimento,denominado neste trabalho de Experimento PBR (Basili et al., 1996), foi replicado algumasvezes e essas replicações evidenciaram as contribuições que poderiam ser obtidas com o apoiocomputacional, uma vez que essas replicações geram uma grande quantidade de dados quedevem ser coletados, armazenados e, posteriormente, analisados. Essas atividade, quando feitasde forma manual torna-se lenta e propensa a erros.

Sendo assim, com a finalidade de automatizar as atividades de Planejamento e Operaçãodo Experimento PBR, este trabalho definiu, modelou e implementou a ferramenta ExpVVT.

79

80 CAPÍTULO 5. CONCLUSÃO

A ExpVVT apóia várias atividades relacionadas às pessoas envolvidas no experimento, comopor exemplo criação de um experimento pelo projetista, apresentando os passos que devem serseguidos conforme o processo experimental definido por Wohlin et al. (2000). Além disso, suainterface auxilia no registro das informações referentes ao pacote de laboratório, auxiliando suaelaboração e evolução.

A ExpVVT contribui para redução dos custos e esforços de preparação, coleta e análise dosdados do Experimento PBR, tarefas essas associadas às atividades de replicação, viabilizando,dessa maneira, a condução de um maior número de replicações e a formação de uma base dedados histórica, contribuindo desta forma para a consolidação do conhecimento associado àstécnicas investigadas.

5.1 Contribuições

Como principais contribuições deste trabalho, pode-se citar:

• projeto e implementação da ferramenta ExpVVT, que apóia a condução e replicação deexperimentos baseados em documento de requisitos utilizando a técnica PBR, automa-tizando o processo de experimentação e apoiando o registro dos dados em uma base dedados.

• criação de uma estrutura de meta-tabelas que facilita o registro da evolução dos pacotesde laboratório.

• viabilização e incentivo da condução de replicações do Experimento PBR, uma vez quea ferramenta facilita e apóia várias atividades do mesmo. Com mais replicações, umamaior quantidade de dados podem ser coletados e analisados, contribuindo para umamaior consolidação de uma base de dados histórica que caracterize as técnicas exploradasnesse experimento.

5.2 Trabalhos futuros

As seguintes atividades são vistas como continuidade a este trabalho:

• modificar a ferramenta ExpVVT para acompanhar a evolução do meta-modelo utilizado, aqual atualmente pode ocorrer, mas fica transparente para a ferramenta. Assim, a evoluçãodo pacote de laboratório poderia ser acompanhada automaticamente pela ferramenta.

• modificar a ferramenta com o objetivo de apoiar outros experimentos, como por exemploo experimento de VV&T, que explora técnicas de teste e de inspeção no nível de código.

5.2. TRABALHOS FUTUROS 81

• conduzir experimentos e replicações utilizando a ExpVVT, ampliando a quantidade dedados para serem analisados, além de validar a ferramenta.

82 CAPÍTULO 5. CONCLUSÃO

Referências Bibliográficas

AMARAL, E. A. G. G. Empacotamento de experimentos em engenharia de software. Dis-sertação de Mestrado, COPPE/UFRJ, 2003.

AMARAL, E. A. G. G.; TRAVASSOS, G. H. Em busca de uma abordagem para empaco-tamento de experimentos em engenharia de software. In: Anais da 2a Jornada Ibero-

Americana de Engenharia de Software e Engenharia de Conhecimento, Salvador, Brasil,2002.

AMARAL, E. A. G. G.; TRAVASSOS, G. H. A package model for Software Engineering ex-periments. In: Proceddings of the 2003 ACM-IEEE International Symposium on Empirical

Software Engineering (ISESE 2003), Roma, Itália, Sessão de Poster, 2003.

ARISHOLM, E.; SJØBERG, D. A controlled experiment with professionals to evaluate the

effect of a delegated versus centralized control style on the maintainability of object-oriented

software. Relatório Técnico 2003-6, Simula Reseach Laboratory, Lysaker, Noruega, 2003.

ARISHOLM, E.; SJØBERG, D. I. K.; CARELIUS, G. J.; LINDSJØRN, Y. SESE - an experi-ment support environment for evaluating Software Engineering technologies. In: Proced-

dings of the Tenth Nordic Workshop on Programming and Software Development Tools and

Techniques (NWPER’2002), Copenhagen, Dinamarca, 2002, p. 81–98.

ARISHOLM, E.; SJØBERG, D. I. K.; JØRGENSEN, M. Assessing the changeability of twoobject-oriented design alternatives - a controlled experiment. Empirical Software Enginee-

ring, v. 6, n. 3, p. 231–277, 2001.

AVDICAUSEVIC, E.; LENIC, M.; MERNIK, M.; ZUMER, V. AspectCOOL: An experimentin design and implementation of aspect-oriented language. ACM SIGPLAN Notices, v. 36,n. 12, p. 84–94, 2001.

83

84 REFERÊNCIAS BIBLIOGRÁFICAS

BARROS NETO, B.; SCARMINIO, I. S.; BRUNS, R. E. Como fazer experimentos: Pesquisa

e desenvolvimento na ciência e na indústria. Campinas, São Paulo, Brasil: Editora daUNICAMP, 401 p., 2001.

BASILI, V. R.; CALDIERA, G.; ROMBACH, H. D. Experience factory. Encyclopedia of

Software Engineering, v. I, p. 469–476, 1994.

BASILI, V. R.; GREEN, S.; LAITENBERGER, O.; SHULL, F.; SORUMGARD, S.; ZELKOWITZ,M. The empirical investigation of Perspective-Based Reading. Empirical Software Engi-

neering: An International Journal, v. 1, n. 2, p. 133–164, 1996.

BASILI, V. R.; SELBY, R. W. Comparing the effectiveness of software testing strategies.IEEE Transactions Software Engineering, v. 13, n. 12, p. 1278–1296, 1987.

BASILI, V. R.; SHULL, F.; LANUBILLE, F. Building knowledge through families of experi-ments. IEEE Transactions on Software Engineering, v. 25, n. 4, p. 456–473, 1999.

BELGAMO, A. GUCCRA: Técnicas de Leitura para Construção de Modelos de Casos de Uso

e Análise do Documento de Requisitos. Dissertação de Mestrado, UFSCar, 2004.

BELGAMO, A.; FABBRI, S. C. P. F.; MALDONADO, J. C. TUCCA: Improving the Ef-fectiveness of Use Case Construction and Requirement Analysis. In: Proceedings of 4thInternational Symposium on Empirical Software Engineering - ISESE, 2005.

BENESTAD, H. C.; ARISHOLM, E.; SJØBERG, D. How to recruit professionals as subjects insoftware engineering experiments. In: IRISt’28 (Information Systems Research in Scandi-

navia), Kristiansand, Noruega, 2005.

BRIAND, L. C.; DIFFERDING, C. M.; ROMBACH, H. D. Pratical guidelines formeasurement-based process improvement. Journal of Empirical Software Engineering, v. 2,n. 3, p. 291–312, 1997.

CAGNIN, M. I.; MALDONADO, J. C.; GERMANO, F. S.; CHAN, A.; PENTEADO, R. D. Umestudo de caso de reengenharia utilizando o processo PARFAIT. In: Simpósio de Desenvol-

vimento e Manutenção de Software da Marinha, Rio de Janeiro, Brasil, 2003a.

CAGNIN, M. I.; MALDONADO, J. C.; GERMANO, F. S.; PENTEADO, R. D. PARFAIT:Towards a framework-based agile reengineering process. In: IEEE Agile Development Con-

ference, Salt Lake City, UTHA, EUA, 2003b, p. 22–31.

CEBASE Center for Empirically-Based Software Engineering. [On-line].Disponível em http://www.cebase.org/ (Último acesso em 11/07/2005)

REFERÊNCIAS BIBLIOGRÁFICAS 85

CHAIM, M. L. POKE-TOOL - uma ferramenta para suporte ao teste estrutural de programas

baseados em análise de fluxo de dados. Dissertação de Mestrado, DCA/FEE/UNICAMP,Campinas, Brasil, 1991.

CHAPETTA, W. A.; SANTOS, P. S. M.; TRAVASSOS, G. H. Supporting meta-description ac-tivities in experimental software engineering environments. In: 2nd Experimental Software

Engineering Latin American Workshop - ESELAW, Uberlândia, Brasil, 2005.

COADY, Y.; KICZALES, G.; FEELEY, M. Exploring an aspect-oriented approach to operatingsystem code. In: ACM Conference on Object-Oriented Programming, Systems, Languages,

and Applications (OOPSLA), Minneapolis, Minnesota, EUA, 2000.

CONALLEN, J. Desenvolvendo aplicações web com UML. 2a ed. Editora Campus, 504 p.,2003.

CONRADI, R. NTNU OORT experiment – some qualitative observations. In: ISERN meeting,Honolulu, Hawai, 2000.

COOK, T. D.; CAMPBELL, D. T. Quasi-experimental design and analysis issues for field

settings. Boston, Massachusetts, EUA: Houghton-Mifflin Company, 1979.

DELAMARO, M. E. Proteum: Um ambiente de teste baseado na análise de mutantes. Disser-tação de Mestrado, Universidade de São Paulo – ICMC/USP, São Carlos, São Paulo, Brasil,1993.

DESMET Determining an evaluation methodology for software methods and tools. SoftwareEngineering Group at the National Computing Centre, 1994.

DO, H.; ELBAUM, S.; ROTHERMEL, G. Supporting Controlled Experimentation with TestingTechniques: An Infrastructure and its Potential Impact. in Empirical Software Engineering:

An International Journal, v. 10, n. 4, 2005.

DÓRIA, E. S. Replicação de estudos empíricos em engenharia de software. Dissertação deMestrado, Instituto de Ciências Matemáticas e Computação – Universidade de São Paulo,São Carlos, São Paulo, Brasil, 2001.

EXADEL Exadel Studio. [On-line].Disponível em http://www.eclipse.org (Último acesso em 09/06/2006)

FELIZARDO, K. R. COTEST - uma ferramenta de apoio à replicação de um experimento

baseado em código fonte. Dissertação de Mestrado, Universidade Federal de São Carlos,São Carlos, São Paulo, Brasil, 2003.


FELIZARDO, K. R.; FABBRI, S.; MALDONADO, J. C. COTEST: Uma ferramenta de apoio àreplicação de experimento de avaliação de técnicas de vv&t em nível de código. In: Anais da

10a Sessão de Ferramentas do 17o Simpósio Brasileiro de Engenharia de Software, Manaus,Brasil, 2003, p. 37–42.

GARCIA, R. E. Visualização para apoio a estudos empíricos em verificação, validação eteste de software. Exame de qualificação de doutorado. Instituto de Ciências Matemáticas eComputação – Universidade de São Paulo, São Carlos, São Paulo, Brasil, 2003.

HETZEL, W. C. An experimental analysis of program verification methods. Tese de Douto-ramento, University of North Carolina at Chapel Hill, 1976.

HÖHN, E.; MALDONADO, J. C.; MENDONÇA, M.; FABBRI, S.; BOAS, A. L. V.; TAMBAS-CIA, C.; FREITAS, M. E.; PAGLIUSO, P. PBR: Transferência de Tecnologia Baseada emPacotes de Experimentação. (Anais do III Simpósio Brasileiro de Qualidade de Software),Brasília, 2004, p. 161–175.

HÖHN, E. N. Técnicas de leitura de especificação de requisitos de software: estudos empíricos

e gerência de conhecimento em ambientes acadêmico e industrial. Dissertação de Mestrado,Instituto de Ciências Matemáticas e Computação – Universidade de São Paulo, São Carlos,São Paulo, Brasil, 2003.

ISERN International Software Engineering Research Network. [On-line].Disponível em http://www.iese.fhg.de/ISERN/ (Último acesso em 25/07/2005)

KALINOWSKI, M. Infra-estrutura computacional de apoio ao processo de inspeção de soft-

ware. Dissertação de Mestrado, COPPE/UFRJ, 2004.

KAMSTIES, E.; LOTT, C. M. An empirical evaluation of three defect-detection techniques.In: Proceedings of the 5th European Software Engineering Conference, Sitges, Espanha:Springer-Verlag, 1995, p. 362–383.

KITCHENHAM, B. A.; DYBÅ, T.; JØRGENSEN, M. Evidence-based Software Engineering.Proceedings of the 26th International Conference on Software Engineering (ICSE’04), Sco-tland, 2004.

MACDONALD, F.; MILLER, J. A comparison of tool-based and paper-based software ins-pection. Empirical Software Engineering: An International Journal, v. 3, n. 3, p. 233–253,1998.

MALTEZ JR., U. P. Modelagem da ferramenta ExpVVT. Instituto de Ciências Matemáticase de Computação, ICMC-USP, São Carlos, documento de trabalho, em elaboração, 2006.


MARUCCI, R. A. Definição de uma estratégia de inspeção para um processo de desenvolvi-

mento de software orientado a objetos. Dissertação de Mestrado, Universidade Federal deSão Carlos, São Carlos, São Paulo, Brasil, 2002.

MENDONÇA, M. G.; MALDONADO, J. C.; OLIVEIRA, M. C. F.; CARVER, J.; FABBRI, S.C. P. F.; SHULL, F.; TRAVASSOS, G. H.; HÖHN, E. N.; BASILI, V. R. A Framework toCoordinate and Evolve Software Engineering Controlled Experiments. Empirical Software

Engineering: An International Journal, submetido, 2006.

MIAN, P. G.; TRAVASSOS, G. H.; ROCHA, A. R. C. A computerized infrastructure forsupporting experimentation in software engineering. In: 2nd Experimental Software Engi-

neering Latin American Workshop - ESELAW, Uberlândia, Brasil, 2005.

MYERS, G. J. A controlled experiment in program testing and code walkthough inspections.Communications of the ACM, v. 21, n. 9, p. 760–768, 1978.

MYSQL AB Mysql. [On-line].Disponível em http://www.mysql.com (Último acesso em 09/06/2006)

PFAHL, D.; LAITENBERGER, O.; DORSCH, J.; RUHE, G. An externally replicated experi-ment for evaluating the learning effectiveness of using simulations in software project ma-nagement education. Empirical Software Engineering: An International Journal, v. 8, n. 4,p. 367–395, 2003.

PRECHELT, L. An experiment on the usefulness of design patterns: detailed description and

evaluation. Relatório Técnico iratr-1997-9, Universitat Karlsruhe, Alemanha, 1997.

PRECHELT, L.; UNGER, B.; TICHY, W. F.; BROSSLER, P.; VOTTA, L. G. A controlled expe-riment in maintenance comparing design patterns to simpler solutions. IEEE Transactions

on Software Engineering, v. 27, n. 12, p. 1134–1144, 2001.

PRESSMAN, R. S. Software Engineering: a practitioner’s approach. McGraw-Hill, 2005.

PROJETO READERS Relatório final de atividades. 2004.

REIS, L. N. M. Apoio automatizado à configuração e aplicação de OORTs. In: Anais do 8o

WTES - Workshop de Teses em Engenharia de Software, Manaus, Brasil, 2003, p. 35–40.

SHULL, F. Developing techniques for using software documents: A series of empirical studies.Tese de Doutoramento, University of Maryland, 1998.

SHULL, F.; MENDONÇA, M.; BASILI, V. R.; CARVER, J.; MALDONADO, J. C.; FABBRI,S.; TRAVASSOS, G. H.; FERREIRA, M. C. Knowledge-sharing issues in experimentalsoftware engineering. Empirical Software Engineering: An International Journal, v. 9, n. 1,p. 111–137, 2004.


SHULL, F.; RUS, I.; BASILI, V. R. How Perspective-Based Reading can improve requeri-ments inspections. IEEE Computer, v. 33, n. 7, p. 73–79, 2000.

SILVA, L. F. S. Apoio ferramental para aplicação de técnicas de leitura baseada em perspec-

tiva (PBR). Dissertação de Mestrado, COPPE/UFRJ, 2004.

SJØBERG, D. I. K.; ANDA, B.; ARISHOLM, E.; DYBÅ, T.; JØRGENSEN, M.; KARAHA-SANOVIC, A.; KOREN, E. F.; VOKÁC, M. Conducting realistic experiments in softwareengineering. In: Proceedings of the 2002 International Symposium on Empirical Software

Engineering (ISESE’02), Nara, Japão: IEEE Computer Society, 2002, p. 17–26.

SJØBERG, D.I.K., H. J. H. O. K. V. K. A. L. N.; REKDAL, A. A Survey of Controlled Ex-periments in Software Engineering. IEEE Transactions on Software Engineering, v. 31(9),p. 733–753, 2005.

SPÍNOLA, R. O. Uma infra-estrutura para integração de ferramentas CASE baseada em XML,

esquemas e ontologias. Dissertação de Mestrado, COPPE/UFRJ, 2004.

SPÍNOLA, R. O.; KALINOWSKI, M.; TRAVASSOS, G. H. Um Mecanismo para a Integraçãode Ferramentas CASE. (Anais do XIX Simpósio Brasileiro de Engenharia de Software -SBES’04), Brasília, 2004.

SUN MICROSYSTEMS JavaServer Faces. [On-line].Disponível em http://java.sun.com/j2ee/javaserverfaces (Último acessoem 09/06/2006)

THE APACHE SOFTWARE FOUNDATION Apache Tomcat. [On-line].Disponível em http://tomcat.apache.org (Último acesso em 09/06/2006)

THE ECLIPSE FOUNDATION Eclipse. [On-line].Disponível em http://www.eclipse.org (Último acesso em 09/06/2006)

THELIN, T. Empirical evaluations of Usage-Based Reading and fault content estimation forsoftware inspections. Empirical Software Engineering: An International Journal, v. 8, n. 3,p. 309–313, 2003.

THELIN, T.; RUNESON, P.; WOHLIN, C.; OLSSON, T.; ANDERSSON, C. Evaluation ofUsage-Based Reading - conclusions after three experiments. Empirical Software Enginee-

ring: An International Journal, v. 9, n. 1, p. 77–110, 2004.

TRAVASSOS, G. H.; BARROS, M. O. Contributions of in virtuo and in silico experimentesfor the future of empirical studies in software engineering. In: 2nd Workshop in Workshop

Series on Empirical Software Engineering (WSESE03), Roma, Itália, 2003, p. 108–121.


TRAVASSOS, G. H.; GUROV, D.; AMARAL, E. A. G. Introdução à Engenharia de Soft-

ware Experimental. Relatório Técnico RT-ES-590/02, COPPE/UFRJ, Rio de Janeiro, Brasil,2002a.

TRAVASSOS, G. H.; SHULL, F.; CARVER, J.; BASILI, V. R. Reading techniques for OO

design inspections. Relatório Técnico CS-TR-4353, University of Maryland Computer Sci-ence Department, 2002b.

TRAVASSOS, G. H.; SHULL, F.; FREDERICKS, M.; BASILI, V. R. Detecting defects in objectoriented designs: Using reading techniques to increase software quality. In: Proceedings of

the 14th ACM SIGPLAN conference on Object-oriented programming, systems, languages,

and applications, Denver, Colorado, EUA: ACM Press, 1999, p. 47–56.

VOKÁC, M.; TICHY, W.; SJØBERG, D.; ARISHOLM, E.; ALDRIN, M. A controlled experi-ment comparing the maintainability of programs designed with and without design patterns– a replication in a real programming environment. Empirical Software Engineering, v. 9,n. 3, p. 149–195, 2004.

WOHLIN, C.; RUNESON, P.; HÖST, M.; OHLSSON, M. C.; REGNELL, B.; WESSLÉN, A.Experimentation in Software Engineering: an introduction. Kluwer Academic Publishers,204 p., 2000.

APÊNDICE

A

Script SQL de criação da base de dados

1 DROP DATABASE IF EXISTS experimentation;

2 CREATE DATABASE experimentation;

3 USE experimentation;

45 /* Usuário */

67 /* ================ INSTITUIÇÃO ================ */

89 CREATE TABLE TBInstitution (

10 id Smallint UNSIGNED NOT NULL AUTO_INCREMENT,

11 name Varchar(50) NOT NULL,

12 acronym Varchar(15),

13 PRIMARY KEY (id),

14 UNIQUE KEY (name)

15 ) TYPE=InnoDB;

1617 SET @name = "Universidade de São Paulo", @acronym = "USP";

18 INSERT INTO TBInstitution (name, acronym)

19 VALUES (@name, @acronym);

2021 /* ================ PAPEL ================ */

2223 CREATE TABLE TBRole (





28 ) TYPE=InnoDB;

2930 SET @name = "administrator";

31 INSERT INTO TBRole (name) VALUES (@name);

32 SET @name = "designer";


91

92 APÊNDICE A. SCRIPT SQL DE CRIAÇÃO DA BASE DE DADOS

34 SET @name = "replicator";


36 SET @name = "subject";


3839 /* ================ USUÁRIO ================ */

4041 CREATE TABLE TBUser (

42 email Varchar(50) NOT NULL,


44 password Varchar(45) NOT NULL,

45 phone Varchar(15),

46 institution Smallint UNSIGNED NOT NULL,

47 role Smallint UNSIGNED NOT NULL DEFAULT 4,

48 /* 1 -> Administrator, 2 -> Designer, 3 -> Replicator, 4 -> Subject */

49 designerCandidate Bool NOT NULL DEFAULT 0,

50 replicatorCandidate Bool NOT NULL DEFAULT 0,

51 /* 0 -> False, 1 -> True */

52 PRIMARY KEY (email),

53 INDEX INDEX_TBUser_1 (institution),

54 INDEX INDEX_TBUser_2 (role),

55 FOREIGN KEY (institution)

56 REFERENCES TBInstitution(id)

57 ON UPDATE CASCADE ON DELETE RESTRICT,

58 FOREIGN KEY (role)

59 REFERENCES TBRole(id)

60 ON UPDATE CASCADE ON DELETE RESTRICT

61 ) TYPE=InnoDB;

6263 INSERT INTO TBUser (email, name, password, institution, role)

64 SELECT "[email protected]", "admin", PASSWORD("admin"), TBInstitution.id, TBRole.id

65 FROM TBInstitution, TBRole

66 WHERE TBInstitution.name = "Universidade de São Paulo" AND

67 TBRole.name = "administrator";

6869 /* Workflow */

7071 /* ================ ATIVIDADE ================ */

7273 CREATE TABLE TBActivity (


75 description Varchar(50) NOT NULL,


77 UNIQUE KEY (description)

78 ) TYPE=InnoDB;

7980 SET @description = "identification";

81 INSERT INTO TBActivity (description) VALUES (@description);

82 SET @description = "definition";


84 SET @description = "planningHypo";


86 SET @description = "technique";


88 SET @description = "document";


90 SET @description = "subject";


92 SET @description = "training";

93


94 SET @description = "design";


96 SET @description = "operation";


98 SET @description = "analysis";


100101 /* ================ WORKFLOW ================ */

102103 CREATE TABLE TBWorkflow (

104 activityId Smallint UNSIGNED NOT NULL,

105 experimentName Varchar(50) NOT NULL,

106 status Varchar(50) NOT NULL,

107 PRIMARY KEY (activityId, experimentName),

108 FOREIGN KEY (activityId)

109 REFERENCES TBActivity(id)


111 ) TYPE=InnoDB;

112113 /* Modelo lógico */

114115 /* ================ TABELA ================ */

116117 CREATE TABLE TBTable (



120 description Varchar(50),



123 ) TYPE=InnoDB;

124125 SET @name = "experiment";

126 INSERT INTO TBTable (name) VALUES (@name);

127 SET @name = "experimentQuestion";


129 SET @name = "hypothesis";


131 SET @name = "variable";


133 SET @name = "metric";


135 SET @name = "validity";


137 SET @name = "partner";


139 SET @name = "participant";


141 SET @name = "question";


143 SET @name = "questionnaire";


145 SET @name = "profile";


147 SET @name = "technique";


149 SET @name = "training";


151 SET @name = "artifact";



153 SET @name = "perspective";


155 SET @name = "document";


157 SET @name = "taxonomy";


159 SET @name = "defect";


161 SET @name = "falsePositive";


163 SET @name = "configuration";


165 SET @name = "reportedDefect";


167168 /* ================ ATRIBUTO ================ */

169170 CREATE TABLE TBField (



173 description Varchar(50),

174 pk Bool NOT NULL DEFAULT 0, /* 0 -> Not PK, 1 -> PK */

175 fk_table Smallint UNSIGNED,

176 fk_field Smallint UNSIGNED,

177 tab_id Smallint UNSIGNED NOT NULL,

178 type Enum (’date’,’number’,’text’) NOT NULL,


180 INDEX INDEX_TBField_1 (tab_id),

181 INDEX INDEX_TBField_2 (fk_table),

182 INDEX INDEX_TBField_3 (fk_field),

183 FOREIGN KEY (tab_id)

184 REFERENCES TBTable(id)


186 FOREIGN KEY (fk_table)

187 REFERENCES TBTable(id)


189 FOREIGN KEY (fk_field)

190 REFERENCES TBField(id)


192 ) TYPE=InnoDB;

193194 /* Table Experiment */

195 SET @table = "experiment";

196 SET @field = "title", @pk = true, @type = "text", @fk_table = null,

197 @fk_field = null;

198 INSERT INTO TBField (name, pk, fk_table, fk_field, tab_id, type)

199 SELECT @field, @pk, TBTableFK.id, TBFieldFK.id, TBTable.id, @type

200 FROM TBTable LEFT OUTER JOIN TBTable TBTableFK ON (TBTableFK.name = @fk_table)

201 LEFT OUTER JOIN TBField TBFieldFK ON (TBFieldFK.name = @fk_field AND

202 TBFieldFK.tab_id = TBTableFK.id)

203 WHERE TBTable.name = @table;

204 SET @field = "date", @pk = false, @type = "date", @fk_table = null,







95


212 SET @field = "researcher", @pk = false, @type = "text", @fk_table = "TBUser",

213 @fk_field = "name";







220 SET @field = "description", @pk = false, @type = "text", @fk_table = null,








228 SET @field = "theme", @pk = false, @type = "text", @fk_table = null,








236 SET @field = "techinicalArea", @pk = false, @type = "text", @fk_table = null,








244 SET @field = "type", @pk = false, @type = "text", @fk_table = null,








252 SET @field = "domain", @pk = false, @type = "text", @fk_table = null,








260 SET @field = "language", @pk = false, @type = "text", @fk_table = null,








268 SET @field = "globalObjective", @pk = false, @type = "text", @fk_table = null,









276 SET @field = "objectOfStudy", @pk = false, @type = "text", @fk_table = null,








284 SET @field = "purpose", @pk = false, @type = "text", @fk_table = null,








292 SET @field = "qualityFocus", @pk = false, @type = "text", @fk_table = null,








300 SET @field = "perspective", @pk = false, @type = "text", @fk_table = null,








308 SET @field = "context", @pk = false, @type = "text", @fk_table = null,








316 SET @field = "executionProcedure", @pk = false, @type = "text", @fk_table = null,








324 SET @field = "analysisMechanisms", @pk = false, @type = "text", @fk_table = null,





97




332 SET @field = "restriction", @pk = false, @type = "text", @fk_table = null,








340 SET @field = "status", @pk = false, @type = "text", @fk_table = null,








348 SET @field = "replication", @pk = false, @type = "text", @fk_table = "experiment",

349 @fk_field = "title";







356357 /* Table Experiment Question */

358 SET @table = "experimentQuestion";

359 SET @field = "id", @pk = true, @type = "number", @fk_table = null,
















375 SET @field = "h0", @pk = false, @type = "text", @fk_table = null,








383 SET @field = "experimentTitle", @pk = false, @type = "text", @fk_table = "experiment",









391392 /* Table Hypothesis */

393 SET @table = "hypothesis";









402 SET @field = "questionId", @pk = false, @type = "number", @fk_table = "experimentQuestion",

403 @fk_field = "id";















418419 /* Table Variable */

420 SET @table = "variable";



























99







453454 /* Table Metric */

455 SET @table = "metric";

























480481 /* Table Validity */

482 SET @table = "validity";


































515516 /* Table Partner */

517 SET @table = "partner";

518 SET @field = "partnerId", @pk = true, @type = "number", @fk_table = "TBInstitution",








526 SET @field = "experimentTitle", @pk = true, @type = "text", @fk_table = "experiment",








534535 /* Table Participant */

536 SET @table = "participant";

537 SET @field = "userEmail", @pk = true, @type = "text", @fk_table = "TBUser",

538 @fk_field = "email";







545 SET @field = "experimentName", @pk = true, @type = "text", @fk_table = "experiment",








553 SET @field = "alias", @pk = false, @type = "text", @fk_table = null,








561562 /* Table Question */

563 SET @table = "question";


101








572 SET @field = "question", @pk = false, @type = "text", @fk_table = null,








580581 /* Table Questionnaire */

582 SET @table = "questionnaire";









591 SET @field = "experimentName", @pk = false, @type = "text", @fk_table = "experiment",








599 SET @field = "questionId", @pk = false, @type = "number", @fk_table = "question",
















615 SET @field = "sequence", @pk = false, @type = "text", @fk_table = null,








623


624 /* Table Profile */

625 SET @table = "profile";

















642 SET @field = "questionId", @pk = true, @type = "number", @fk_table = "question",








650 SET @field = "answer", @pk = false, @type = "text", @fk_table = null,








658659 /* Table Technique */

660 SET @table = "technique";









669 SET @field = "name", @pk = false, @type = "text", @fk_table = null,








677 SET @field = "file", @pk = false, @type = "text", @fk_table = null,






103



685686 /* Table Training */

687 SET @table = "training";









696 SET @field = "techniqueId", @pk = false, @type = "number", @fk_table = "technique",








704 SET @field = "instructor", @pk = false, @type = "text", @fk_table = null,








712713 /* Table Artifact */

714 SET @table = "artifact";









723 SET @field = "trainingId", @pk = false, @type = "number", @fk_table = "training",








731 SET @field = "artifact", @pk = false, @type = "text", @fk_table = null,








739740 /* Table Perspective */

741 SET @table = "perspective";


































774 SET @field = "tool", @pk = false, @type = "text", @fk_table = null,








782783 /* Table Document */

784 SET @table = "document";

















105









809810 /* Table Taxonomy */

811 SET @table = "taxonomy";

























836837 /* Table Defect */

838 SET @table = "defect";









847 SET @field = "documentId", @pk = false, @type = "number", @fk_table = "document",








855 SET @field = "page", @pk = false, @type = "number", @fk_table = null,









863 SET @field = "requirement", @pk = false, @type = "text", @fk_table = null,
















879 SET @field = "type", @pk = false, @type = "number", @fk_table = "taxonomy",








887888 /* Table False Positive */

889 SET @table = "falsePositive";

























914915 /* Table Configuration */

916 SET @table = "configuration";



107















933 SET @field = "documentId", @pk = true, @type = "number", @fk_table = "document",








941 SET @field = "techniqueId", @pk = true, @type = "number", @fk_table = "technique",








949 SET @field = "perspectiveId", @pk = false, @type = "number", @fk_table = "perspective",








957 SET @field = "sequence", @pk = false, @type = "text", @fk_table = null,








965 SET @field = "status", @pk = false, @type = "text", @fk_table = null,








973974 /* Table Reported Defect */

975 SET @table = "reportedDefect";










984 SET @field = "userEmail", @pk = false, @type = "text", @fk_table = "TBUser",








992 SET @field = "experimentName", @pk = false, @type = "text", @fk_table = "experiment",
























1016 SET @field = "defectId", @pk = false, @type = "number", @fk_table = "defect",








1024 SET @field = "falsePositive", @pk = false, @type = "number", @fk_table = "falsePositive",








1032 SET @field = "nonDefect", @pk = false, @type = "text", @fk_table = null,





109












1048 SET @field = "comments", @pk = false, @type = "text", @fk_table = null,








10561057 /* ================ DADO ================ */

10581059 CREATE TABLE TBData (

1060 id Int UNSIGNED NOT NULL,

1061 field_id Smallint UNSIGNED NOT NULL,

1062 record Int UNSIGNED NOT NULL,


1064 INDEX INDEX_TBData_1 (field_id),

1065 INDEX INDEX_TBData_2 (record),

1066 FOREIGN KEY (field_id)

1067 REFERENCES TBField(id)


1069 FOREIGN KEY (record)

1070 REFERENCES TBData(id)


1072 ) TYPE=InnoDB;

10731074 CREATE TABLE TBDate (


1076 data Date NOT NULL,


1078 FOREIGN KEY (id)



1081 ) TYPE=InnoDB;

10821083 CREATE TABLE TBNumber (


1085 data Numeric(10,0) NOT NULL,





1090 ) TYPE=InnoDB;

10911092 CREATE TABLE TBText (


1094 data Text NOT NULL,






1099 ) TYPE=InnoDB;

APÊNDICE

B

Document Type Definition dosdocumentos XML

Listagem B.1: DTD que descreve o documento XML de entrada do Módulo de Definição<!ELEMENT experiment ( definition ) >


<!ELEMENT definition ( identification, characterization, globalObjective, specificAims,

questions, metrics ) >

<!ELEMENT identification ( description, theme, technicalArea, researcher, date ) >


<!ELEMENT theme ( #PCDATA ) >

<!ELEMENT technicalArea ( #PCDATA ) >

<!ELEMENT researcher ( name, email, institution ) >




<!ELEMENT date ( #PCDATA ) >

<!ELEMENT characterization ( type, domain, language, partners ) >


<!ELEMENT domain ( #PCDATA ) >

<!ELEMENT language ( #PCDATA ) >

<!ELEMENT partners ( institution* ) >

<!ELEMENT globalObjective ( #PCDATA ) >

<!ELEMENT specificAims ( objectOfStudy, purpose, qualityFocus, perspective, context ) >

<!ELEMENT objectOfStudy ( #PCDATA ) >

<!ELEMENT purpose ( #PCDATA ) >

<!ELEMENT qualityFocus ( #PCDATA ) >

<!ELEMENT perspective ( #PCDATA ) >

<!ELEMENT context ( #PCDATA ) >

<!ELEMENT questions ( question+ ) >

<!ELEMENT question ( #PCDATA ) >

<!ELEMENT metrics ( metric+ ) >

111

112 APÊNDICE B. DOCUMENT TYPE DEFINITION DOS DOCUMENTOS XML

<!ELEMENT metric EMPTY >

<!ATTLIST metric description CDATA #REQUIRED >

<!ATTLIST metric metric CDATA #REQUIRED >

Listagem B.2: DTD que descreve o documento XML de entrada do Módulo de Planejamento<!ELEMENT experiment ( planning ) >


<!ELEMENT planning ( hypothesesFormulation, variablesSelections, subjectsSelection, techniques,

documents, experimentDesign, analysisMechanisms, resultsValidity,

training, executionProcedure ) >

<!ELEMENT hypothesesFormulation ( question+ ) >

<!ELEMENT question ( h0, ha+ ) >

<!ATTLIST question question CDATA #REQUIRED >

<!ELEMENT h0 ( #PCDATA ) >

<!ELEMENT ha ( #PCDATA ) >

<!ELEMENT variablesSelections ( independentVariables, dependentVariables ) >

<!ELEMENT independentVariables ( variable+ ) >

<!ELEMENT dependentVariables ( variable+ ) >

<!ELEMENT variable ( #PCDATA ) >

<!ELEMENT subjectsSelection ( subject+ ) >

<!ELEMENT subject ( name, email, institution, group, perspectivePBR ) >




<!ELEMENT group ( #PCDATA ) >

<!ELEMENT perspectivePBR ( #PCDATA ) >

<!ELEMENT techniques ( technique, technique ) >

<!ELEMENT technique ( perspective*, documentDescription?, suportTool?, toolName? ) >

<!ATTLIST technique title CDATA #REQUIRED >

<!ELEMENT perspective ( documentDescription?, suportTool?, toolName? ) >

<!ATTLIST perspective name CDATA #REQUIRED >

<!ELEMENT documentDescription ( #PCDATA ) >

<!ELEMENT suportTool ( #PCDATA ) >

<!ELEMENT toolName ( #PCDATA ) >

<!ELEMENT documents ( document, document ) >

<!ELEMENT document ( description?, file?, defectList ) >

<!ATTLIST document name CDATA #REQUIRED >


<!ELEMENT file ( #PCDATA ) >

<!ELEMENT defectList ( defect* ) >

<!ELEMENT defect ( page?, requirement?, description, type ) >

<!ELEMENT page ( #PCDATA ) >

<!ELEMENT requirement ( #PCDATA ) >


<!ELEMENT experimentDesign ( firstTec, execDuration, execution+ ) >

<!ELEMENT firstTec ( #PCDATA ) >

<!ELEMENT execDuration ( #PCDATA ) >

<!ELEMENT execution EMPTY >

<!ATTLIST execution group CDATA #REQUIRED >

<!ATTLIST execution technique CDATA #REQUIRED >

<!ATTLIST execution document CDATA #REQUIRED >

<!ELEMENT analysisMechanisms ( #PCDATA ) >

<!ELEMENT resultsValidity ( internal?, external?, conclusion?, construction? ) >

<!ELEMENT internal ( validity+ ) >

<!ELEMENT external ( validity+ ) >

<!ELEMENT conclusion ( validity+ ) >

<!ELEMENT construction ( validity+ ) >

<!ELEMENT validity ( #PCDATA ) >

113

<!ELEMENT training ( procedure, instructor, artifacts ) >

<!ELEMENT procedure ( #PCDATA ) >

<!ELEMENT instructor ( #PCDATA ) >

<!ELEMENT artifacts ( artifact+ ) >

<!ELEMENT artifact ( name, description, file ) >

<!ELEMENT executionProcedure ( #PCDATA ) >

Listagem B.3: DTD que descreve o documento XML de entrada do Módulo de Operação<!ELEMENT experiment ( subject+ ) >


<!ELEMENT subject ( technique+ ) >

<!ATTLIST subject name CDATA #REQUIRED >

<!ELEMENT technique ( document+ ) >

<!ATTLIST technique name CDATA #REQUIRED >

<!ELEMENT document ( reportedDefect ) >

<!ATTLIST document name CDATA #REQUIRED >

<!ELEMENT reportedDefect ( defect* ) >

<!ELEMENT defect EMPTY >

<!ATTLIST defect number CDATA #REQUIRED >

<!ATTLIST defect page CDATA #REQUIRED >

<!ATTLIST defect requirement CDATA #REQUIRED >

<!ATTLIST defect type CDATA #REQUIRED >

<!ATTLIST defect description CDATA #REQUIRED >