Professional Documents
Culture Documents
WDP-RT : Uma t écnica de leit ura para inspeção de usabilidade de aplicações Web
Tayana Uchoa Cont e
Evoluindo uma Técnica de Avaliação de Usabilidade at ravés de Est udos In Vit ro e In Vivo
Tayana Uchoa Cont e
Proceedings of 6th Experimental Software
Engineering Latin American Workshop
(ESELAW 2009)
Organization
Departamento de Computação, Universidade Federal de São Carlos
Instituto de Ciências Matemáticas e de Computação, Universidade de São Paulo
Sponsor
Brazilian Computer Society – SBC
Experimental Software Engineering Latin American Workshop
(ESELAW 2009) (6. : 2009 : São Carlos, SP)
E96p
Proceedings / 6th Experimental Software Engineering
Latin American Workshop (ESELAW 2009)
: November 11-13, 2009 – São Carlos, São Paulo, Brazil ;
organizers UFSCar, UFG, ICMC/USP -- São Carlos, SP :
UFSCar, 2009.
ISBN: 978-85-99673-03-4
(ESELAW 2009)
Organization
Departamento de Computação, Universidade Federal de São Carlos
Instituto de Ciências Matemáticas e de Computação, Universidade de São Paulo
Sponsor
Brazilian Computer Society – SBC
Edited By
Sandra C. Pinto Ferraz Fabbri, DC-UFSCar
Auri Marcelo Rizzo Vincenzi, UFG
Elisa Yumi Nakagawa, ICMC – USP
Presentation
No science can evolve without measurement and experimentation. The progress of any
discipline involves building theories and testing them through experimental studies. For
this reason, there is a growing awareness in the software engineering community that
experimental studies are necessary to develop and improve software engineering
processes, methods and tools. The Software Engineering Discipline should have a
strong foundation in experimentation; however software engineering experimentation is
not an easy task. It is complex, time consuming, and multi-faceted.
Therefore, a forum for researchers and practitioners to report on and discuss new
research results in Experimental Software Engineering is an essential initiative for the
growing of this area, being the main target of ESELAW – Experimental Software
Engineering Latin American Workshop. As in the previous editions, ESELAW 2009
aims to bring together Latin America´s academic, industrial and commercial
communities for the exchange of ideas to understand the strengths and weaknesses of
software engineering technologies, focusing on the process, design and structure of
empirical studies, as well as on the results from specific studies.
ESELAW 2009 – the sixth edition of the event – includes two talks, four short courses
and three technical sections. Prof. Carolyn Seaman discusses in the opening talk the
problem of delayed maintenance tasks and in the short course the use of qualitative
methods in empirical studies of software engineering. The second invited talk by Prof.
Alfredo Goldman explores the free, libre, open source centers as an opportunity for
experimentation. Prof. Manoel Mendonça presents an introduction to experimental
software engineering, Prof. Guilherme Travassos discusses the use of statistical
methods for planning and analyzing experimental studies in software engineering area
and Katia Felizardo talks about scientific research in software engineering through
systematic review. These three themes correspond to the other three short courses.
Besides, there are three technical sections that present researches on experimentation,
systematic review and verification, validation and testing activities.
The event received forty five paper submissions that were reviewed by three referees
each one, and twelve of them were selected for presentation in the technical sessions.
These papers are printed in these proceedings as well as a summary of the talks and the
short courses. We thank the dedicated work of the student Lucas Bueno Ruas de
Oliveira for the organization of this document.
The Department of Computing at Federal University of São Carlos, SP, Brazil is hosting
this edition of ESELAW.
Steering Committee
Sandra C. Pinto Ferraz Fabbri (DC-UFSCar, Brazil) -- General Chair
Guilherme Horta Travassos (COPPE/UFRJ, Brazil)
José Carlos Maldonado (ICMC-USP, Brazil)
Márcio Eduardo Delamaro (ICMC-USP, Brazil)
Manoel G. de Mendonça Neto (UFBA, Brazil)
Program Committee
Auri M. R. Vincenzi (UFG, Brazil) -- Program Chair
Ana M. Moreno (Universidad Politecnica de Madrid, Spain)
Andreas Jedlitschka (IESE-Fraunhofer, Germany)
Cleidson Ronald Botelho de Souza (UFPA, Brazil)
Ellen Francine Barbosa (ICMC-USP, Brazil)
Emilia Mendes (Auckland University, New Zeland)
Fabio Kon (IME-USP, Brazil)
Giovanni Cantone (Tor Vergata, Italy)
Guilherme Horta Travassos (COPPE-UFRJ, Brazil)
Jeffrey Carver (University of Alabama, Tuscaloosa, EUA)
José Carlos Maldonado (ICMC-USP, Brazil)
Manoel G. de Mendonça Neto (UFBA, Brazil)
Marcello Visconti (UTFSM, Chile)
Marcos L. Chaim (EACH-USP, Brazil)
Marcio Eduardo Delamaro (ICMC-USP, Brazil)
Natalia Juristo (Politecnica de Madrid, Spain)
Sandro Morasca (Università dell´Insubria, Italy)
Support Committee
Daniel de Paula Porto (DC-UFSCar, Brazil)
Deysiane Matos Sande (DC-UFSCar, Brazil)
Elis Cristina Montoro Hernandes (DC-UFSCar, Brazil)
Erika Höhn (ICMC-USP, Brazil)
Fernanda Aparecida R. da Silva (DC-UFSCar, Brazil)
Guilherme Freire (DC-UFSCar, Brazil)
Lucas Bueno Ruas de Oliveira (ICMC- USP, Brazil)
Organizing Committee
Publication Chair
Elisa Yumi Nakagawa, ICMC-USP, Brazil
External Reviewers
Short Courses 6
Systematic Review - Scientific Research in Software Engineering (Katia Romero
Felizardo, Rafael Messias Martins and Erika Nina Höhn) . . . . . . . . . . . . 7
Using Qualitative Methods in Empirical Studies of Software Engineering (Carolyn
Seaman) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Introduction to Experimental Software Engineering (Manoel G. Mendonça) . . . . 9
The Use of Statistical Methods for Planning and Analyzing Experimental Studies
in Software Engineering Area (Guilherme Horta Travassos and Marco Antônio
Pereira Araújo) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1
Redução de Potenciais Defeitos através da Detecção de Anomalias em Diagra-
mas de Classes (Isela Macı́a, Arndt von Staa) . . . . . . . . . . . . . . . . . 104
Reutilização de Conjuntos de Teste: Um Estudo no domı́nio de Algoritmos de
Ordenação (Diogo Nascimento Campanha, Simone do Rocio S. Souza, Otávio
Augusto L. Lemos, Ellen Francine Barbosa e José C. Maldonado) . . . . . . . 114
WDP-RT: Uma técnica de leitura para inspeção de usabilidade de aplicações
Web (Marcos Gomes, Davi Viana, Lennon Chaves, Andreza Castro, Verônica
T. Vaz, Altigran Soares, Guilherme H. Travassos, Tayana Conte) . . . . . . . . 124
2
INVITED TALK
3
Carolyn Seaman: Measuring and Monitoring Technical Debt
The “technical debt” metaphor characterizes the relationship between the short-term
benefits of delaying certain maintenance tasks and the long-term cost of those delays.
This metaphor frames the problem of delayed maintenance tasks as a type of “debt,”
which brings a short-term benefit (usually in terms of higher productivity or shorter
release time) but which might have to be paid back, with “interest,” later. The
“principal” on the debt is the amount of effort required to “pay off” the debt (i.e.
complete the task), while the “interest” is the potential penalty (in terms of increased
effort and decreased productivity) that will have to be paid in the future as a result of
not completing these tasks in the present. Many practitioners find this metaphor
intuitively appealing and helpful in thinking about the issues. What is missing, however,
is an underlying theoretical basis upon which management mechanisms can be built to
support decision-making. This talk will propose a simple technical debt management
model, and present recent results from our ongoing study of this issue.
4
Alfredo Goldman: Free, Libre, Open Source Competence
Centers - an opportunity for experimentation
Free, Libre, Open Source Software (FLOSS) Competence Centers are being established
in several countries around the world. One of the first Brazilian initiatives in this
direction is the USP Qualipso FLOSS Competence Center with branches at IME and
ICMC. Its goal is to be a meeting point for students, professors, researchers, and
professionals from public and private companies for exchanging information and
conducting scientific and technological research and development projects around
FLOSS.
In this talk, we will tell the history and describe the goals of the USP FLOSS
Competence Center and of the Qualipso Project and will describe a series of recently-
initiated research projects in the area of Experimental Software Engineering that have
the USP competence center as its testbed.
Alfredo Goldman received his B.Sc. in applied mathematics from University of São
Paulo, Brazil, his M.Sc. in computer science also from University of São Paulo, and his
doctorate in computer science from the Institut National Polytechnique de Grenoble,
France. He currently is an associated professor in the Department of Computer Science
at University of São Paulo. His research interests include parallel and distributed
computing, mobile computing and grid computing.
5
INVITED SHORT COURSES
6
Systematic Review - Scientific Research in Software
Engineering
Katia Romero Felizardo, Rafael Messias Martins and Erika Nina Höhn
The results produced by traditional literature reviews can be limited and of questionable
scientific value if not guided by a sound process. The systematic review approach
provides a comprehensive and systematic evaluation of research using a predefined
strategy of search aiming at minimizing bias. The term systematic review is used to
refer to thorough and fair methodology of literature review and it is used to
summarizing, assessing and interpreting the relevance of all research related to a
specific question, topic area, or phenomenon of interest. This is an introductory course
on systematic review. Its first goal is to motivate and illustrate the application of
systematic reviews in the software engineering area. A complete example is provided in
order to give the attendees a notion on the advantages, limitations and constraints of
systematic reviews in practice.
Katia Romero Felizardo has a MSc. degree in Computer Sciences from the
Universidade Federal de São Carlos (UFSCar). She has been assistant professor at
Universidade do Oeste Paulista (UNOESTE), Universidade Estadual de Londrina
(UEL) and Universidade Estadual do Norte do Paraná (UENP). Currently she is PhD
student in Computer Sciences at Universidade de São Paulo (USP), campus of São
Carlos, and has experience in software engineering, focused mainly in the subjects:
Software Quality, Systematic Review of Literature, Ontologies and Information
Visualization.
Rafael Messias Martins is B.Sc. in Computer Science from the Universidade Estadual
Paulista Julio de Mesquita Filho (UNESP), and currently is M.Sc. student at the
Instituto de Ciências Matemáticas e de Computação at the Universidade de São
Paulo(ICMC/USP). His research interests include mainly Software Engineering and
Information Visualization, with emphasison Systematic Reviews (and Ontologies),
Software Architecture and Reengineering.
7
Using Qualitative Methods in Empirical Studies of Software
Engineering
Carolyn Seaman
This course covers the basics of applying qualitative research methods to research
projects in software engineering. The course will enable participants to: Appreciate the
fundamental philosophical underpinnings of qualitative research. Be able to critically
evaluate qualitative research. Gain mastery of core qualitative data collection and
analysis techniques. Synthesize this material through several interactive examples.
8
Introduction to Experimental Software Engineering
Manoel G. Mendonça
This course will present students with the fundamentals of experimentation in software
engineering. It will start by introducing the basic concepts of experimentation,
presenting the particularities of experimentation in software engineering
experimentation and drawing comparisons with other subject areas. The course will
then discuss how to run controlled experiments, surveys and case studies in software
engineering, presenting examples to illustrate the discussions. The course will close by
discussing aspects of knowledge management and sharing experimental findings in
software engineering.
Manoel G. Mendonça received his Ph.D. in computer science from the University of
Maryland at College Park in 1997. He also holds a M.Sc. in computer engineering from
the State University of Campinas (UNICAMP-1990), and a Bachelors in electrical
engineering from the Federal University of Bahia, (UFBa - 1986), both in Brazil. Dr.
Mendonça was a visiting scientist and was awarded a doctoral fellowship from the IBM
Toronto Laboratory's Centre for Advanced Studies. Between 1997 and 2000, he worked
as a Faculty Research Associate at the University of Maryland and as a scientist at the
Fraunhofer Center for Experimental Software Engineering in Maryland. He joined the
Salvador University (UNIFACS) as a Professor in 2000. There he headed heads the
Networking and Computing Research Center (NUPERC) from 2004 to 2008. He also
served as a member of the Computer Science Technical Chamber at the Bahia State
Research Agency (FAPESB) from 2005 to 2008. He joined the Computer Science
Depatment of the Federal University of Bahia in 2009. He holds a research productivity
scholarship from the Brazilian Research Council (CNPq) since 2001. Prof. Mendonça
is a member of the Brazilian Computer Society (SBC) and the Association for
Computing Machinery (ACM), and a senior member of IEEE. His main research
interest are on software engineering, information visualization, mobile computing and
knowledge management supporting systems.
9
The Use of Statistical Methods for Planning and Analyzing
Experimental Studies in Software Engineering Area
Guilherme Horta Travassos and Marco Antônio Pereira Araújo
The objective of this course is to present the main statistical techniques used for
planning and analyzing experimental studies in software engineering. The course will
apply a practical approach using, as much as possible, examples in the context of the
real word. Aiming at supporting the discussion on the techniques, data from
experimental studies already run by the authors or from the literature will be used .
Besides the concepts of experimentation and statistics, the course will indicate possible
applications of such techniques.
Marco Antônio Pereira Araújo has a MsC and a DSc degree in the Program of
Computing and Systems Engineering from COPPE/UFRJ and a title of Specialist in
Statistical Methods for Computing from Universidade Federal de Juiz de Fora. He is a
Lecturer in the Bachelor of Information Systems course at Centro de Ensino Superior
de Juiz de Fora and Faculdade Metodista Granbery. His interest areas are
experimental software engineering, software evolution, system dynamics and statistical
methods.
10
TECHNICAL SESSION 1
Experimentation in Software Engeneering
(ESE)
11
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
1. Introduction
It is possible to notice that any project that focuses on solving problems, whatever its
subject is, for example, software development, innovation, product management, and
others, has a fundamental element: the development team. Team is formally defined as a
set of people working in an interdependent way and sharing common objectives, for
which everybody all together feels responsible (BATITUCCI, 2002). Team
management has been looked recently as a definitive factor for success or failure of any
people intensive project, such as software development.
Personnel factors have been a concern since the early days of software
engineering. In the NATO 68 Software Engineering Conference report (NATO, 1968),
the section dealing with such factor opens with the statement that “Many of the
problems of producing large software systems involve personnel factors”. One of the
first attempts on how to structure a team in software development has been proposed by
Brooks (1975).
Lettice and McCracken (2007) reported that the amount of researches related to
software projects team management has doubled in the last 10 years. These researches
are mainly focused on: (1) how the software team can increase projects’ chances of
success; (2) how the team building process can be related to the team performance; and
(3) how to manage human factors to maintain and improve the team effectiveness.
Becker et. Al (2000), discussed the issue, related to (2), of how to identify suitable
criteria for selecting individuals to build a software team. However, the inherent
complexity of dealing with personality and behavior, and the different managerial levels
(strategic, tactic, and operational) influenced by each criterion, make the application of
such criteria in day-to-day decisions a difficult task.
12
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
França et. al. (2008) has indentified a set of criteria for software projects
team building from a field research made with six software companies. This exploratory
and qualitative study provided important insights on how software project managers
apply criteria for team building and how such criteria might influence final project
performance. Two important questions have been raised from that research: (I) Can the
use of these criteria be related to software projects success? (II) What is the order
of importance among these criteria, according to the project managers’ opinions?
This article describes a field research designed to assess the criteria identified
by França et. al. (2008) using quantitative methods. The goal is twofold. First, to look
for relationships between the criteria and project success in order to create evidence that
the criteria are relevant in practice. Second, to establish an order relation for applying
these criteria. The results, in a form of an ordered set of criteria for selecting
individuals, is expected to assist project managers in the difficult and relevant task of
building software teams
This article is organized as follows. In Section 2, the conceptual underpinnings
of this research are briefly discussed . In Section 3, the methodology used in this
research is described. In Section 4, the main findings of the research are presented and
analyzed. In Section 5, some conclusions and future directions for this research are
presented.
2. Conceptual Underpinnings
This research aims to relate two variables: (1) criterion for the selection of individuals to
build software teams and (2) software project success. This section provides a brief (due
to space constraints) but necessary characterization of these variables.
levels, were interviewed. The interview data was analyzed using qualitative methods
and the following set of team building criteria (Cx) has emerged:
C1 Technical profile: refers to the individual technical knowledge in a specific
technology or tool. This criterion also includes the knowledge related to some of
the modules or business process areas of software. However, the technical
profile evaluation indicates just if a professional is able or not to work in some
project, without consider his/her experience and productivity.
C2 Individual costs: refers to the costs of each professional hired by the
organization, and consequently to the impacts of each one in the project budget.
This is usually cited by the project managers as an important restriction rule in
the team building process. However, previous research on software team
building did not have considered this aspect so far.
C3 Experience and Productivity: refers to the professional experience of each
individual and his/her historical productivity rates. This also can be described as
the project manager perception of how each person can individually contribute
to improve the team performance at all. It differs from C1 because technical
knowledge can be learned relatively quickly, while experience and productivity
takes more time to develop.
C4 Availability of human resources: refers to the availability of the needed people
inside an organization. It shows up that, on practice, different projects can be
either sharing resources or concurring for them. Also, the availability of human
resources could be extended to evaluate not only the internal availability, but
also the capacity of finding and hiring people with the required characteristics in
due time.
C5 Personality: refers to the motivation generated on an individual, when his/her
personal profile fits with his/her functional role in the development process or
role inside a team. This is the most complex criterion, because its evaluation
should be based on formal psychological analysis on individuals, but it is not
usual the project managers use it, so they may make some misleading.
C6 Behavioral skills: refers to specific behavior individuals are expected to present
in different situations or roles in the development processes.
Besides these six criteria, França et. al. (2008) also identified another factor that
influences the decision to allocate an individual to a software team in a given project,
which received a distinct notation (Sx) because it was considered strategic criteria:
S1 Project importance: refers to the business strategic importance of the project or
the customer. This factor influences all other criteria at the same time, so it can
determine how strongly another criterion will be considered, since more than
one project can share the same resources. Also, usually the most important
project has the most valuable professionals in the organization.
14
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
This research uses the work of Hackman (1990) and Hallows (1998), where
project success is measured by the following set of criteria: M1 - Costs, M2 -
Implementation date, M3 - Functionality/Scope, M4 - Effective project team work, M5 -
User satisfaction, and M6 - Professional satisfaction on the part of the project manager.
One project is considered successful if it satisfactorily achieves these six criteria.
Haggerty (2000) presented a questionnaire to evaluate project success according to the
above set of criteria. This instrument is used in this research and is further explained in
Section 3.4.
3. Methodology
This research is empirical, nomothetic, descriptive and relational. It uses statistical
methods to find relationships among team building criteria and software projects
success in a limited set of software projects. The nature of the variables is, therefore,
quantitative. Data acquisition was done by a survey carried out with software companies
in several Brazilian cities.
15
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
How were the goals listed below satisfied by the project B (failed)? Not Strongly
Satisfied
Satisfied satisfied
M1. Costs ( ) ( ) ( )
M2. Implementation date ( ) ( ) ( )
…
Both questionnaires have passed through a pre-test evaluation, performed with 5
project managers. They are described above already with the improvements resulted
1
According to the standards from IBGE – Instituto Brasileiro de Geografia e Estatística.
16
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
from the pre-test. For ethical reasons, two more sessions were added to the research
instrument: a presentation session and another describing the confidentiality policy.
Success Goals
For the successful projects, on Table 5, it’s possible to notice that all success
goals have a high level of strong satisfaction (above 79%) while only a minority of the
17
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
projects has not satisfied them (under 17%). For the failed projects on Table 6, however,
most of the projects have not satisfied the success goals (above 50%) while only the
minority of the projects have strongly satisfied some of the success goals (under 34%).
However, it was necessary to apply the MANN-WHITNNEY U test on these two sets of
projects for assure that the samples really match with the necessary specifications of
success and failure. As showed in Table 7, the differences between the successful and
failed projects were significant for all success goals. In the U Test, the differences
between two samples are meaningful when the result of p (confidence level) is equal or
less 0.05, which represents 95% of certainty.
Table 7: MAN-WHITNEY U Test applied to the success goals among successful and
failed projects
Strongly
Not satisfied Satisfied
Success Goals Achievement level Satisfied
(n = 24) (n = 24)
(n = 24)
p=0.000 p=0.000
p=0.000 p=0.000
M1 Costs p=0.555
p=0.000 p=0.000
M2 Implementation date p=0.317
p=0.000 p=0.000
M3 Functionality/scope p=0.388
p=0.000 p=0.000
M4 Effective project team work p=1.000
p=0.000 p=0.000
M5 User satisfaction p=0.640
M6 Professional satisfaction on the part of the project manager p=0.077
() - Significant differences only for p ≤ 0.05
p=0,031 p=0,045
C1 Technical profile
p=0,001 p=0,001
C2 Individual costs p=1,000
C3 Experience and Productivity p=0,714
p=0,002 p=0,002
C4 Availability of human resources p=0,135 p=0,734 p=0,082
p=0,001 p=0,002
C5 Personality p=0,714
p=0,024 p=0,037
C6 Behavioral skills p=1,000
p=0,015
S1 Project importance p=1,000
S2 Customer importance p=0,153 p=0,077
() - Significant differences only for p ≤ 0.05
18
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
In the same sense of what was discussed before, in the end of the Session 4.2, C4
- Availability of Human Resources was evaluated as the least important criteria, which
means that the project managers also would not suggest this criterion as essential to
favor project success. This is, therefore, consistent with the findings in Section 4.2.
5. Conclusions
Even though there are already some theoretical models for team building for software
engineering projects, it is possible to notice that they are not widely used by practioners,
as found by França et. al (2008). While these researches are concerned to develop
methodologies for effective teams building, it was found that project managers on
19
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
software engineering field still are building their teams based heavily on their own past-
experiences.
However, França et. al. (2008) made an exploratory research with the goal to
empirically identify some of the criteria used by project managers to build successful
teams. The main objective of the research described in this article was to assess the
effectiveness of the use of those criteria by calculating the statistical correlation of them
with project success goals.
From a carefully planned field research, it was possible to conclude that the
analysis of technical profile, experience and productivity, personality, and behavioral
skills are positively related to the project success among the studied sample.
Complement other researches in the area, the results presented here also emphasize
individual costs, customer importance and project importance as relevant factors to be
considered in team building. Individual costs, specially, are not described explicitly in
the team building literature, even though it is consistent with the project management
literature (PMI, 2004). On the other hand, there is no significant correlation between
availability of human resources and neither project success nor project failure.
This paper’s main wea ness is the reduced sample. Although the sample is not
big enough to draw general conclusions (a threat to external validity), it is important to
notice that not only 48 software projects is a reasonable sample comparing with the
average in software engineering research field, but also the experimental research
process designed can serve as a reference for other related researches that could repeat
the same experiment with an expanded sample. Another problem is the use of a non-
parametric test that makes the results weaker than using parametric tests, which was
impracticable in this research.
Beyond the effectiveness of the team building criteria, verified through a
practical experience, there are two other noteworthy results. The first one would be the
tools designed to assess and correlate team building criteria and project goals, including
the data packet resulting from the research. The second would be the methodology
prepared for this field research, which could be used for future work to verify factors
with similar data behavior.
Finally, it is important to emphasize that this article is a part of a wider research,
which aims to study the whole of team lifecycle management on software engineering
organizations. Also, both industry and academy have shown an increasing interest for
this theme.
References
BATITUCCI, M. D. (2002) Equipes 100% - O novo modelo do trabalho cooperativo no
3º milênio. São Paulo: Makron Books.
BECKER, M.; BURNS-HOWELL, J.; KYRIAKIDES, J.(2000) IS Team effectiveness
factors and performance, 2000.
BROOKS, F. P. (1975) The Mythical Man-Month: Essays on Software Engineering.
Addison-Wesley Professional, 1975, ISBN 0201835959, 336p.
DeMARCO, T.; LISTER, T. (1987) Peopleware: Productive Projects and Teams. New
York: Dorset House Publishing Co, ed. 2, 1999.
20
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
21
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
1. Introdução
A Engenharia de Software (ES) vem utilizando a Experimentação como meio para a
criação de um corpo de conhecimento. Para que apresente validade científica, cada um
de seus itens de conhecimento deve ser verificado perante a realidade [Juristo &
Moreno, 2001]. Essa verificação pode ser realizada através de estudos experimentais,
que permitam ao pesquisador um maior controle da situação e a manipulação do
comportamento do ambiente de forma direta, precisa e sistemática [Wohlin et al.,
2000]. Diferentes tipos de estudos experimentais podem ser utilizados, contando com a
participação de profissionais. Esses estudos visam observar a validade desses itens de
conhecimento quando relacionada a seus possíveis comportamentos em processos de
software e como podem afetar o produto gerado. Contudo, em situações onde o tempo
necessário para observação do comportamento é longo, a utilização de profissionais
pode não ser inicialmente viável, tornando a observação mais difícil, trazendo riscos de
continuidade da pesquisa. Essas condições têm motivado o uso cada vez mais freqüente
de estudos baseados em simulação na Engenharia de Software Experimental [Zhang et.
al., 2008]. Dentre as vantagens que podem ser obtidas, destacam-se: maior controle do
ambiente, menor custo de pessoal e antecipação a possíveis riscos. Também, existe a
possibilidade de observar, de forma restrita, a viabilidade das tecnologias de software
sob investigação. Os estudos que fazem uso de ambientes simulados são denominados:
in virtuo e in silico. Esses estudos permitem observar o mundo real através de simulação
22
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
24
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
26
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
Este modelo inicial foi refinado e, assim, foram identificados alguns pontos de
decisão no estudo (vide Figura 4). No modelo foram representados os fluxos de controle
e dados do modelo, o que possibilita ao pesquisador visualizar as dependências entre as
atividades do estudo, trazendo a ele uma visão dessas duas perspectivas. Também foi
percebido que três atividades eram compostas de sub-atividades. Na Figura 4, as
atividades compostas estão estereotipadas com <<structured>>, que representam o
conceito de sub-workflows.
Inicio_Simulacao_Decaimento «datastore» «decisão»
Base de medidas da {Base de medidas das
Dados reais do versões é válida e suficiente
organização
processo de para gerar as equações?}
desenvolvimento
Tabela com Tabela com
«structured» versões do versões do «structured»
Preparar dados para software software Gerar as equações para
simulação [SIM] simulação
Equações para
[NÃO] «decisão» [MODIFICAR
simulação
{Qual é origem do EQUAÇÕES
[MODIFICAR
problema? Ação a PARA «decisão»
MEDIDAS DO
ser tomada?} SIMULAÇÃO] {Equações
SOFTWARE]
representam o
[NÃO] modelo dinâmico?}
Análise do [SIM]
Equações para
resultado da Dados da simulação
simulação «Semi-automatizada» simulação da «structured»
Análise do resultado da Dados da evolução Simular a evolução do
simulação simulação da software
Final_Simulacao_Decaimento evolução
27
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
28
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
4. Lições aprendidas
A abordagem foi desenvolvida para ser aplicada por pesquisadores, porém foi observado
ser ainda necessário conhecimento sobre modelagem UML, em especial sobre o
diagrama de atividades. A aprendizagem sobre este modelo demanda tempo pelos
participantes, em especial os pesquisadores. Por isso, a tarefa de Definir o modelo
inicial do workflow científico é importante, pois abre a possibilidade do pesquisador ir
assimilando os conceitos sobre modelagem e da própria técnica. Um ponto importante é
a participação do pesquisador responsável e a necessidade de comprometimento por
parte dos participantes, pois como em processos de software, o cliente é fundamental na
captura e identificação dos requisitos.
Relacionado à especificação e aos formulários, foi percebido que o crescimento
do número de atividades, artefatos e ferramentas que fazem parte do estudo, pode
dificultar o seu preenchimento, a sua manipulação e a consistência. Como os
formulários foram criados para serem inter-relacionados, algumas informações ao
sofrerem alteração demandam esforço para modificações em outros formulários. Ainda,
destaca-se a possibilidade, apontada por um dos pesquisadores, de utilizar a
especificação como forma de disseminação de conhecimento entre outros pesquisadores
(novos no domínio). O modelo em diagrama de atividades permite uma visualização do
encadeamento das atividades e os dados passados entre elas, enquanto os formulários
sintetizam as informações e permitem um rápido acesso a um conteúdo organizado.
5. Trabalhos relacionados
Em uma revisão da literatura técnica, apenas Verdi et al. (2007) apresentou um processo
definido para concepção de workflows científicos abstratos. Este é composto por 3 fases
de modelagem, com etapas de projeto e de validação. Contudo, não definem nenhuma
atividade de verificação dos artefatos gerados, realizando somente a validação pelos
próprios autores. Este tipo de abordagem pode acarretar risco da não percepção de defei-
tos no documento. Ainda, a captura das informações é realizada através de três modelos,
um para capturar o fluxo de dados, outro para controle e um para hierarquia entre as
atividades. Quanto ao modelo de hierarquia, o diagrama de atividades permite a repre-
sentação de atividades compostas e, em geral, as ferramentas já mantém a consistência
entre a atividade e seu modelo interno. Já sobre os fluxos de controle e dados, quando
separados, pode haver inconsistência entre as informações nos diversos modelos. Além
disso, muitos modelos diferentes podem gerar inconsistência na documentação e so-
mente usar modelos, como em Verdi et. al. (2007), pode acabar por não capturar algu-
mas informações consideradas importantes (e.g. pré e pós-condições, papéis ou riscos).
Alguns sistemas utilizam o conceito de template para representar o estudo
experimental abstratamente. Contudo, os templates são dependentes do SGWfC e à sua
infra-estrutura de execução, onde foram concebidos. Gil et al. (2007) e Kaster et al.
29
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
(2005) apresentam abordagens desse tipo. Esses sistemas permitem que um pesquisador
com bom conhecimento do estudo defina o template que, posteriormente, é instanciado
para uma infra-estrutura computacional provida pelos sistemas. Porém, isto acarreta
uma forte dependência entre o estudo, o template e a plataforma na qual foram conce-
bidos, afinal ele só é utilizado no próprio SGWfC. O estudo acaba ficando restrito, pois
a especificação que deveria ser independente de linguagem, ou máquina de workflow, já
é concebida pensando em questões relacionadas ao SGWfC. Afinal, os requisitos são os
mesmos para o estudo, não importando o SGWfC a ser utilizado.
6. Conclusão
A experimentação baseada em simulação vem sendo cada vez mais utilizada em
Engenharia de Software [Travassos & Barros, 2003]. Outras áreas da ciência também
fazem uso da simulação e, para concretizá-la, utilizam tecnologias como workflows
científicos. A Engenharia de Software, em especial a experimental, pode também
utilizar tais tecnologias para obter vantagens, como controle, automação da execução e
proveniência dos dados gerados em estudos experimentais baseados em simulação. Por
isso, foi proposta uma abordagem para apoiar o pesquisador a especificar e gerar
workflows científicos abstratos para estudos in virtuo e in silico [Pereira & Travassos,
2009]. Entendemos que a concepção de workflow científicos, em nível abstrato, deve ser
independente de SGWfC, pois o estudo em si é independente de tecnologias e a sua
execução deveria ser possível, a princípio, em qualquer infra-estrutura.
Este artigo apresentou a aplicação da Abordagem de Concepção no domínio da
observação da Evolução de Software. Através do uso da abordagem, foi possível captu-
rar o processo para Simular a Evolução de Software de maneira incremental. O
modelador e pesquisador responsável identificaram, inicialmente, as atividades e o seus
objetivos, artefatos gerados e consumidos e ferramentas, gerando ao final uma
especificação do workflow abstrato. Os formulários, quando utilizados, induzem a
identificação das informações necessárias para o estudo e sua representação em
workflow abstrato, levando à percepção de detalhes ou conhecimento não explicitado se
feito de forma ad hoc. A formalização do estudo permite a posterior exploração dessa
especificação como insumo para uma implementação em algum SGWfC ou ambiente
computacional.
A abordagem utilizada neste trabalho ainda está em desenvolvimento para apoiar
experimentação baseada em simulação em Engenharia de Software. Melhorias já estão
previstas, tal como uso de técnica de inspeção mais formal, por exemplo, checklists
calibrados para guiar o inspetor na verificação de questões importantes para o domínio
ou na completude das informações. No momento, está sendo revisada de forma mais
sistemática a literatura técnica em busca de possíveis abordagens que atendam e possam
ser adaptadas a este contexto de estudo in virtuo e in silico. O volume de informações e
a repetição de tarefas indicam a necessidade de apoio computacional para melhorar o
gerenciamento do conteúdo e inserção automática de informações (e.g., insumos e pro-
dutos, pré-atividades, dentre outras), visando diminuir problemas com a consistência
entre as informações e o esforço na manipulação e preenchimento dos formulários.
30
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
Agradecimentos
Este trabalho é parte do projeto Engenharia de Software Experimental e Ciência em Larga
Escala - CNPq (475459/2007-5) e FAPERJ. Os autores agradecem também a ao CAPES e
FINEP por apoiar esta pesquisa.
Referências
Araújo, M. A. P. (2009) "Um Modelo para Observação de Evolução de Software", Tese de
Doutorado, PESC/COPPE, Rio de Janeiro, UFRJ, p. 191.
Deelman, E. et al. (2009) “Workflows and e-Science: An overview of workflow system features
and capabilities”, In: FGCS, v. 25, n. 5, pp. 528-540.
Gil, Y. et al. (2007) “Wings for Pegasus: Creating Large-Scale Scientific Applications Using
Semantic Representations of Computational Workflows”, IAAI’07, Vancouver, Canadá, p.
1767-1774.
Kaster, D.; Medeiros, C.; Rocha, H., (2005) “Supporting modeling and problem solving from
precedent experiences: The role of workflows and case-based reasoning”, Environmental
Modelling and Software, v. 20, pp. 689-704.
Kavanagh, J.; Hall, W. (2008) “Grand Challenges in Computing Research 2008”,
http://www.ukcrc.org.uk/grand_challenges/news/gccr08final.pdf.
Juristo, N.; Moreno, A.M. (2001) “Basics of software engineering experimentation”, 1st ed.,
Kluwer Academic Publishers, 395p.
Lehman, M.M.; Perry, D.E.; Ramil, J.F. (1998), “Implications of Evolution Metrics on
Software Maintenance”, In:ICSM, v. 16, ed. 20, pp 208 – 217.
Mattos, A. et al. (2008) “Gerência de Workflows Científicos: uma análise crítica no contexto da
bioinformática”, COPPE/UFRJ, PESC, Technical Report ES-716/08.
Mattoso, M. et al. (2008) “Gerenciando Experimentos Científicos em Larga Escala” In: SBC-
SEMISH´08, Belém, Brasil. p.121-135.
Medeiros et. al., C.B. (2005) “WOODSS and the Web: annotating and reusing scientific
workflows”, SIGMOD Record, v. 34, n. 3, p. 18-23.
Oinn, T. et. al. (2007) "Taverna/myGrid: Aligning a Workflow System with the Life Sciences
Community", In: Workflows for e-Science, Springer, p. 300-319.
Object Management Group (2009) “OMG Unified Modeling Language Specification”, versão
2.2, formal/09-02-02, http://www.omg.org/spec/UML/2.2/.
Pereira, W. M., Travassos, G.H. (2009) “Abordagem para concepção de experimentos
científicos em larga escala suportados por workflows científicos” In: 3 E-Science Workshop
colocado ao SBBD/SBES, Fortaleza, Brasil, in press.
Pfleeger, S. L. (2004) “Engenharia de Software: Teoria e Prática”, 2nd ed., Prentice Hall, 560p.
Sociedade Brasileira de Computação (2006). Grandes Desafios da Computação no Brasil:
2006-2016, http://www.sbc.org.br/index.php?language=1&content=downloads&id=272.
Travassos, G. H.; Barros, M. O. (2003) “Contributions of In Virtuo and In Silico Experiments
for the Future of Empirical Studies in Software Engineering”, In: ESEIW 2003 - WESSE,
Roma, Italy, pp. 117–130.
Verdi, K.; Ellis, H.; Gryk, M. (2007) “Conceptual-level workflow modeling of scientific
experiments using NMR as a case study”, BMC Bioinformatics, v. 8, n. 31, 12p.
Wohlin, C. et al. (2000) “Experimentation in Software Engineering”, Kluwer Academic
Publishers, 204p.
Zhang, H., Kitchenham, B., and Pfahl, D. (2008) “Software Process Simulation Modeling:
Facts, Trends and Directions”, In Proceedings of the 2008 15th APSEC. IEEE Computer
Society, Washington, DC, pp. 59-66.
31
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
32
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
33
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
34
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
(porte e tipo). As unidades entrevistadas têm uma estrutura matricial fraca, isto é,
possuem características de organizações funcionais e projetizadas. Nesse tipo de
organização, embora se reconheça a necessidade de um gerente de projetos, ele não
possui autoridade total sobre o projeto e seus recursos financeiros.
4.2 Coleta de Dados
A coleta de dados foi realizada através de entrevistas semi-estruturadas, onde não são
fornecidas opções de resposta para não limitar ou direcionar a resposta do entrevistado.
Nestas entrevistas são colocadas questões abertas que permitem maior interação com o
entrevistado e novas questões são abordadas de acordo com o conhecimento de novas
informações [DeWalt 2002]. Além de caracterizar os gerentes de projetos e a unidade
onde trabalham, as perguntas foram elaboradas com o intuito de estimular os
entrevistados a falarem sobre o seu trabalho no dia-a-dia, como realizam a alocação de
pessoas: incluindo métodos e ferramentas utilizadas, interações com outras pessoas e
outros fatores que influenciam nesta atividade. Para ser mais especifico, as seções do
roteiro de entrevista contemplaram: (1) caracterização da unidade organizacional; (2)
atividades que o gerente de projetos ou titular o escritório de projetos realiza; (3) como
são realizadas as alocações de pessoas; (4) a experiência do entrevistado; e (5) o nível
de capacitação do entrevistado em gerenciamento de projetos. A coleta de dados foi
realizada ao longo de dois meses, sendo que quatro entrevistas foram presenciais e as
demais foram realizadas remotamente via telefone. As entrevistas duraram entre 15 e 25
minutos.
Além dos registros das entrevistas, foi utilizada de forma complementar a
análise de documentação e artefatos de auxílio à alocação citados na entrevista. Esses
artefatos eram solicitados pelos autores e, posteriormente analisados. Essas informações
foram usadas para confirmar ou complementar informações geradas pelas entrevistas.
4.3 Análise dos dados
O objetivo inicial do estudo estava focado nos critérios de alocação de pessoas e como
estes eram priorizados e aplicados durante o projeto. Entretanto, através das entrevistas
semi-estruturadas e da análise dos dados foi possível constatar a importância da
negociação no processo de alocação de pessoas. Durante as entrevistas observou-se que
o processo de alocação vai além do conhecimento e aplicação dos critérios de alocação:
a negociação envolvendo líderes de projeto, gerente da unidade e titulares do escritório
de projetos é uma atividade de extrema importância nesse processo. Este é um aspecto
importante deste trabalho, pois contrasta diretamente com os trabalhos de [Barreto
2005] e [Souza 2007] onde a disponibilidade é uma das premissas para alocação de
pessoas. A partir desta constatação, as novas entrevistas exploraram de maneira mais
significativa a negociação que ocorre durante a atividade de alocação de pessoas.
A análise de dados foi feita utilizando-se a ferramenta MAXqda2, onde as
categorias foram identificadas juntamente com as suas propriedades e os
relacionamentos entre as mesmas.
5. Resultados
A partir da descrição de como os gerentes realizavam a alocação de pessoas e de suas
atividades diárias foi possível realizar o ordenamento conceitual dos dados coletados,
envolvendo suas propriedades e dimensões. Com isso, foi possível identificar: (1)
35
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
36
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
37
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
Tipo do Projeto
O tipo de projeto foi citado como um fator que influencia a alocação e está relacionado
ao critério de experiência do desenvolvedor. No caso das manutenções evolutivas, a
experiência é necessária para que se realize a análise de impactos das evoluções nas
funcionalidades existentes. Para os casos das corretivas, um dos fatores é a urgência
com que a correção deve ser efetuada e, por isso, uma pessoa experiente poderá corrigir
o problema com maior agilidade.
“Como se tratava de uma manutenção envolvendo a alteração de sistema
implantado, por isso precisava de pessoas experientes (plataforma e
conhecimento do negócio do cliente)” (Entrevistado 03)
5.2 Níveis de importância entre os critérios de alocação de pessoas
Dentre os critérios de alocação citados pelos entrevistados, ficou claro que para cada
situação, alguns critérios teriam que ser considerados em conjunto com outros para que
se obtivesse o resultado esperado para a alocação. Além disso, existem níveis de
importância entre os critérios, conforme os trechos abaixo.
“Se tiver uma tarefa muito complexa e eu colocar uma pessoa inexperiente, ela
não conseguirá dar vazão mesmo que tenha disponibilidade.” (Entrevistado 05)
“Considero primeiramente o nível de conhecimento do negócio e, em seguida, o
conhecimento na linguagem.” (Entrevistado 09)
O primeiro exemplo ilustra que o trabalho a ser realizado não será executado no
prazo se apenas o critério disponibilidade for considerado.
5.3 A importância da negociação durante a alocação de pessoas
38
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
39
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
Agradecimentos
Esta pesquisa é financiada pelo CNPq através do Edital Universal 2008 (473220/2008-
3) e pela Fundação de Amparo à Pesquisa do Estado do Pará (FAPESPA) através do
Edital Universal N.° 003/2008 e do Edital de Apoio a Grupos de Pesquisa No 017/2008.
40
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
8. Referências
ABNT. NBR ISO 10006. Gestão da Qualidade – Diretrizes para a Qualidade no Gerenciamento
de Projetos. 2000. Associação Brasileira de Normas Técnicas, Rio de Janeiro, RJ, Brasil.
ACUÑA, S. T.; JURISTO, N.; MORENO, A. M. Emphasizing Human Capabilities in Software
Development. 2006. IEEE Software. 23, 2 (Mar. 2006), 94-101.
BARRETO, A. S.; BARROS, M. O.; WERNER, C. M. L. Apoio à Alocação de Recursos
Humanos em Projetos de Software: Uma Abordagem Baseada em Satisfação de Restrições.
2005. IV Simpósio Brasileiro de Qualidade de Software - SBQS 2005. Porto Alegre, Brasil.
BELBIN, M.R. Management Teams: Why they succeed or Fail. Butterworth-Heinemann, 1981.
BIFFL, S.; HALLING, M. Investigating the Defect Detection Effectiveness and Cost Benefit of
Nominal Inspection. 2003. IEEE Transactions on Software Engineering 29 (5), 385–397
DEWALT, K. M.; DEWALT, B. R. Participant Observation – A Guideline for Fieldworkers.
Altamira Press, California, 2002.
FERNANDES, F.; SILVA, F. Relações entre Competências Pessoais e Tipos de Personalidade
do Gerente de Projetos. 2007. 2o. Congresso Brasileiro de Gerenciamento de Projetos. 2007.
FERREIRA, P. ; SILVA, F. Fatores Humanos que Influenciam a Utilização de Processos de
Software. 2008. VII Simpósio Brasileiro de Qualidade de Software. Florianópolis, Brasil.
FRANÇA, C.; SILVA, F. Um estudo sobre Relações entre Papéis Funcionais do RUP e o
Comportamento Pessoal no Trabalho em Equipe em Fábricas de Software 2007. In: III
Workshop Um Olhar Sócio-técnico sobre a Engenharia de Software. Porto de Galinhas, PE.
FUGGETTA, A. Software process: a roadmap. Proceedings of the Conference on The Future of
Software Engineering, p.25-34, June 2000, Limerick, Ireland.
GLASER, B. G.; STRAUSS, A. The discovery of grounded theory: Strategies for Qualitative
Research. Aldine de Gruyter, NY, 1967.
KERZNER, H .Gestão de Projetos: As Melhores Práticas. 2ªed.Bookman, Porto Alegre, 2006.
PMI - Project Management Institute. A Guide to the Project Management Body of Knowledge -
PMBOK Guide. 3rd ed. 2004.
PMI - Project Management Institute . Project Management Competency Development (PMCD)
Framework. 2001.
PFLEEGER, S. L. Engenharia de Software: teoria e prática. 2ªEd., SP:Prentice Hall, 2004.
SCHNAIDER, L.R.C. Planejamento da alocação de recursos humanos em ambientes de
desenvolvimento de software orientados à organização. 2003. Dissertação de Mestrado –
COPPE/UFRJ, Rio de Janeiro, RJ, Brasil.
SEAMAN, C. B. Qualitative Methods. In: SHULL, F. et al. Guide to Advanced Empirical
Software Engineering London: Springer-Verlag, 2008. p. 35-62
SEI-SOFTWARE ENGINEERING INSTITUTE. CMMi for Software Engineering. Staged
Representation (CMU/SEI-02TR029). Pittsburg: Carnegie Mellon University, 2002.
SHETLER, J. Teaming in the microprocessor laboratory. 1996. Frontiers in Education
Conference, 1996, FIE'96. Volume 3, 6-9 Nov.1996, pp.1437-1440.
SILVA, M. A; LIMA REIS, C. A.; REIS, R. Q. Auxílio a Alocação de Pessoas em Projetos de
Software Através de Políticas. 2007. VI Simpósio Brasileiro de Qualidade de Software -
SBQS 2007. Porto de Galinhas, Brasil
SMITH D.C.; BECKER M.; BURNS-HOWELL J.;KYRIAKIDES, J. Creating High
performance IS Teams. 2001. SAICSIT, Pretoria, 2001, 172–181
SOUZA, M. M. Uma Metodologia de Predição Estatística de Projetos Baseada em Simulação.
2007. Dissertação de Mestrado – Programa de Mestrado em Ciência da Computação,
Universidade Federal de Pernambuco, Recife.
STRAUSS, A.; CORBIN J. Pesquisa Qualitativa – Técnicas e procedimentos para o
desenvolvimento de teoria fundamentada. 2ªed. Bookman, Porto Alegre, 2008.
41
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
1. Introdução
Atualmente, grande parte das informações sobre novas tecnologias de software
(processos, métodos, técnicas e ferramentas) ainda são baseadas em opinião própria ou
propaganda. Entretanto, a pesquisa científica não pode ser baseada em opiniões ou
interesses comerciais [Juristo e Moreno, 2001]. Neste contexto, experimentação provê
uma forma sistemática, disciplinada e controlada para avaliar processos e atividades
humanas [Wöhlin et al., 2000]. Estudos experimentais contribuem no sentido de prover
justificativas para o uso ou não de tecnologias, baseadas em indicações sobre a
efetividade destas tecnologias para melhoria da qualidade do software. Assim, os
resultados de estudos experimentais executados em diferentes cenários de pesquisa
podem ser utilizados como pontos de partida para definir um conjunto de critérios que
42
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
1
http://isern.iese.de/network/ISERN/pub
2
http://ese.cos.ufrj.br
3
http://www.mediawiki.org/wiki/MediaWiki
4
http://lens-ese.cos.ufrj.br/wikiese
43
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
45
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
Os termos sugeridos por cada grupo foram comparados para eliminar eventuais
duplicatas e serem efetivamente inseridos. Como as avaliações não solicitaram
definições para os termos sugeridos, realizou-se uma pesquisa na literatura para fornecer
as definições com suas devidas referências. Como resultado, um modelo bem mais
estável e cobrindo um conjunto mais abrangente de tipos de estudos foi obtido.
A seguir, em 2008, como uma última atividade antes da liberação do glossário
para a comunidade, foi realizada uma sessão de inspeção como um dos trabalhos da
disciplina de Experimentação em Engenharia de Software, ministrada pelo Programa de
Engenharia de Sistema e Computação da COPPE/UFRJ. A disciplina foi direcionada
para 22 alunos, dentre os quais 18 mestrandos e 4 doutorandos, tendo transcorrido nos
meses de outubro, novembro e dezembro de 2008. Referências importantes na área de
Experimentação em Engenharia de Software, tais como [Wöhlin et al., 2000] e [Juristo
e Moreno, 2001], juntamente com o conhecimento transmitido na disciplina,
subsidiaram a realização por parte dos alunos de uma inspeção no glossário. Os
objetivos desta inspeção contemplaram a detecção de discrepâncias que não foram
objetivo de avaliação nas revisões anteriores. Os alunos focaram na identificação de
problemas relacionados à omissão de termos e definições, correção de das definições e
alteração de nome dos termos. Um total de 190 oportunidades de melhoria foi
identificado após discriminação e remoção de duplicatas.
46
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
48
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
4. Conclusão
Este artigo descreveu o glossário de termos de Experimentação em Engenharia de
Software. O processo de construção do glossário foi detalhado em termos da
consolidação de sua versão inicial e das revisões conduzidas entre os pesquisadores,
visando ampliar a completude e a corretude da lista de termos. Discutiu-se também a
integração do glossário a um repositório de conhecimento sobre Experimentação em
Engenharia de Software, que demandou a inclusão de termos a cerca de conceitos sobre
49
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
Agradecimentos
O glossário de termos é parte do projeto Engenharia de Software Experimental e Ciência
em Larga Escala - CNPq (475459/2007-5) e FAPERJ. Agradecemos ao grupo de
Engenharia de Software Experimental, em especial aos alunos Felipe Pinto e Vinicios
Bravo, pelas importantes contribuições na construção da versão inicial da ferramenta
wiki. Os autores reconhecem e agradecem o apoio de Mike Baker (ISERN) e Sandra
Fabbri (UFSCar-ESELAW) nas atividades de organização e revisão do glossário.
Referências
Amaral, E. A. G. G. (2003) “Empacotamento de Experimentos em Engenharia de
Software”, Dissertação de Mestrado, COPPE/UFRJ, Engenharia de Sistemas e
Computação, RJ, Brazil.
Basili, V.R., Shull, F., Lanubile, F. (1999). “Building Knowledge through Families of
Experiments”, In: IEEE Trans. on Software Engineering, vol. 25, No. 4.
Chapetta, W. A., (2006), “Uma Infra-estrutura para Planejamento, Execução e
Empacotamento de Estudos Experimentais em Engenharia de Software”, Dissertação
de Mestrado, Programa de Engenharia de Sistemas e Computação, COPPE/UFRJ,
Universidade Federal do Rio de Janeiro. Rio de Janeiro, RJ, Brasil.
Costa, H.R.; Mian, P.G. Travassos, G.H., (2004), “Estendendo um Modelo de Processo
e de Empacotamento de Estudos Experimentais”, Relatório Técnico do Projeto eSEE.
ISERN, (1995), “ISERN basic terminology in Experimental Software Engineering”,
http://www.cs.umd.edu/projects/SoftEng/tame/isern/isern.definitions.html.
Juristo, N., Moreno, A. (2001). “Basics of Software Engineering Experimentation”,
Kluwer Academic Press, 1ª edição.
50
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
51
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
1. Introdução
Os artefatos de software são constituídos por diversos elementos. Por exemplo, o
modelo conceitual é formado por classes, atributos e associações, enquanto o diagrama de
caso de uso é formado por casos de uso, associações e atores. Para que o desenvolvedor1
possa saber quais elementos afetam e são afetados por outros, ele pode utilizar o conceito
de rastreabilidade, que consiste em uma maneira de associar elementos indicando uma
relação de causa-efeito entre eles. A rastreabilidade entre elementos de artefatos permite
acompanhar a vida de um artefato durante o ciclo de vida do software [1].
A rastreabilidade auxilia na compreensão dos relacionamentos entre os artefatos [7],
1
Desenvolvedor é entendido neste artigo como qualquer profissional (analista de sistemas, projetista,
programador, etc.) que crie artefatos relacionados ao produto de software em desenvolvimento.
52
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
53
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
uma classe pode estar sendo inserida no modelo conceitual devido à existência de um caso
de uso que a menciona. Ou ainda, um caso de uso pode estar sendo inserido no diagrama
em função de um ou mais requisitos que lhe dão origem. Assim, a idéia examinada neste
artigo é de que a de inserção de elementos nos artefatos seja indutiva. Ou seja, com exceção
dos elementos iniciais (base) a inserção de um elemento em um artefato deverá ocorrer a
partir de outro elemento, o qual consiste em sua causa.
Este artigo apresenta, então, uma abordagem semi-automática para a criação da
rastreabilidade2, que objetiva tornar sua utilização menos custosa que a técnica tradicional,
almejando seu uso efetivo nas organizações.
O restante do artigo apresenta na seção 2 trabalhos relacionados; na seção 3
definições de rastreabilidade; na seção 4 a rastreabilidade indutiva, incluindo sua
implementação em uma ferramenta CASE; na seção 5 o experimento realizado e seus
resultados; e na seção 6 as conclusões.
2. Trabalhos Relacionados
A matriz e a recuperação automática de rastreabilidade são as principais técnicas da área.
Estas tratam a rastreabilidade como uma atividade à parte da criação dos elementos nos
artefatos, ou seja, primeiro são criados os elementos, depois são definidas as relações.
Em sua forma mais simples a matriz de rastreabilidade se manifesta em tabelas com
linhas e colunas, nas quais os elementos de um projeto são relacionados aos requisitos que
os satisfazem [23]. As relações são, geralmente, estabelecidas pelo relacionamento
explícito entre dois artefatos [24], e esta ainda é a forma como as relações são criadas
atualmente nas organizações [21]. A matriz de rastreabilidade é a técnica mais atendida
pelas ferramentas CASE que suportam a rastreabilidade.
Recentemente, técnicas de recuperação automática de relações de rastreabilidade
vêm sendo pesquisadas na tentativa de encontrar uma alternativa para o problema da
custosa e complexa definição da rastreabilidade [16, 17, 18]. A recuperação automática
procura identificar relações de rastreabilidade baseando-se na similaridade entre o texto
contido nos artefatos. Um exemplo de técnica de recuperação é a LSI (Latent Semantic
Indexing) [3, 11, 12, 15]. No entanto, segundo alguns autores [2, 3, 4], ainda existem
muitos desafios que precisam ser superados. Um dos problemas é que as técnicas de
recuperação confiam na hipótese de que o uso correto de termos do domínio entre artefatos
permite rastreá-los. Nos casos em quem isto não acontece, o processo de recuperação
automático torna-se ineficiente [25], pois muitos links possíveis deixam de ser detectados e
falsos links podem ser detectados. Estas técnicas de recuperação não são completamente
automáticas, pois o usuário deve interagir com o sistema para decidir sobre a aceitação ou
rejeição das relações recuperadas.
Durante a realização das pesquisas para este artigo não foram identificadas
ferramentas CASE de escala industrial que suportassem a recuperação automática da
2
O escopo deste artigo compreende o processo de criação das relações de rastreabilidade, já manutenção das
relações não faz parte de seu intuito.
54
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
3. Rastreabilidade
Nesta seção são definidos os conceitos fundamentais para este trabalho: elemento, artefato
e relação de rastreabilidade.
Um elemento e é uma unidade de informação que compõe um artefato. O universo
de todos os elementos possíveis é denotado por E. Exemplos de elementos: um caso de uso,
uma classe, um requisito, um protótipo de tela,
Um artefato a é definido como sendo um conjunto de elementos de E. Um sistema
de software pode então ser modelado por um conjunto de artefatos A = {a1, a2, ... an} cada
qual contendo um conjunto de elementos, ou seja, A = { {e1,1, e1,2, ...}, {e2,1, e2,2, ...}, ...
{en,1, en,2, ...} }. As eventuais associações entre elementos de um artefato (composição,
generalização, associação simples, etc.) são também consideradas elementos dos artefatos.
Faz-se exceção apenas às relações de rastreabilidade, definidas a seguir, que são
consideradas externas aos artefatos, não sendo, portanto, elementos destes.
A relação de rastreabilidade R ⊆ E × E é uma relação acíclica e transitiva que
estabelece relações entre elementos de artefatos. A relação de rastreabilidade se dá entre os
elementos: mesmo que um elemento esteja presente em um ou mais artefatos, suas relações
permanecem as mesmas.
4. Rastreabilidade Indutiva
O processo de desenvolvimento de software inclui a criação de artefatos e seus
elementos nos diferentes graus de abstração. Então, na prática, o processo de
desenvolvimento, do ponto de vista das atividades de um desenvolvedor, pode ser
entendido como uma seqüência de ações que visam criar elementos nos diferentes artefatos.
Diferente da técnica tradicional, na técnica indutiva a criação das relações está
inserida no processo de construção dos elementos nos artefatos, ou seja, as relações são
criadas como uma conseqüência da criação dos elementos nos diferentes artefatos e não
como uma atividade extra.
O processo se inicia com a criação do elemento base. A partir dele podem ser
derivados os demais elementos nos diferentes artefatos. Por exemplo, os requisitos
55
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
poderiam ser os elementos base. A partir destes são derivados casos de usos e protótipos,
dos quais são derivadas classes, e assim por diante. A técnica não obriga o desenvolvedor a
utilizar a derivação, mas se ele a usar as relações de rastreabilidade serão criadas
automaticamente pela ferramenta CASE.
Os principais passos da técnica indutiva podem ser visualizados na Figura 1. No
passo inicial o artefato de destino do elemento a ser derivado é selecionado. Isso só é
necessário quando o elemento a ser derivado deve pertencer a um artefato diferente do
elemento-causa. Para derivar elementos dentro do mesmo artefato não é necessário
selecionar o artefato de destino.
O segundo passo consiste em selecionar o elemento-causa, elemento de origem da
relação de rastreabilidade. Pode-se, inclusive, selecionar dois ou mais elementos como
elemento-causa em uma derivação porque um elemento pode ter várias causas.
No terceiro passo é aplicada a derivação sobre o elemento-causa, para dar origem ao
elemento-efeito. Juntamente com a criação do elemento-efeito é criada a relação de
rastreabilidade.
1- Seleciona o 2- Seleciona o 3- Deriv a o
artefato de elemento-causa elemento-efeito
destino
2 1
56
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
5. Experimento
A fim de comparar o desempenho da técnica indutiva e da técnica tradicional
realizou-se um experimento com três grupos, sendo que um grupo usou a técnica indutiva, e
os outros dois usaram ferramentas disponíveis no EA para definição de rastreabilidade a
posteriori, ou seja, a matriz de relacionamentos e a janela de edição do elemento (criação
direta de links).
O experimento foi estruturado de tal forma que a subjetividade e reflexão
proporcionassem pouca interferência nos resultados, uma vez que o objetivo deste consistiu
em realizar uma análise quantitativa da técnica indutiva, analisando a quantidade de
relações de rastreabilidade que podem ser criadas com a técnica indutiva comparada às
técnicas tradicionais no mesmo intervalo de tempo.
Para o experimento foram apresentados 80 requisitos no diagrama de requisitos e se
solicitou a cada grupo que criasse um caso de uso correspondente para cada requisito bem
como as relações de rastreabilidade. O tempo disponibilizado para a tarefa foi de 10
minutos.
Quinze desenvolvedores foram avaliados no experimento, dos quais cinco usaram a
técnica indutiva, cinco usaram a técnica criação de links e cinco usaram a técnica matriz de
relacionamentos. As técnicas foram atribuídas de forma aleatória. Cada um recebeu um
material com instruções sobre como realizar o experimento com a técnica correspondente.
Medidas foram tomadas a fim de produzir dados sem vícios, objetivando evitar
possíveis interferências nos resultados. Essas medidas foram adotadas antes, durante e
depois do experimento, conforme detalhado a seguir.
Antes da realização do experimento real os desenvolvedores receberam um arquivo
de testes com os requisitos para praticarem e tirar dúvidas relacionadas ao funcionamento
da técnica e do EA. Isto foi feito no intuito de nivelar o conhecimento dos mesmos.
A configuração (hardware e software) dos computadores do laboratório foi
verificada, assegurando que todos possuíam as mesmas características. Pois diferenças nas
velocidades dos computadores poderiam interferir no número de elementos criados.
A execução da tarefa de cada desenvolvedor foi gravada em vídeo com o software
ScreenCam™ [10], com o objetivo de detectar anormalidades, tais como: o usuário realizar
outra atividade além do experimento e falha no funcionamento dos softwares.
Para avaliação dos resultados foram contabilizados, para cada um dos
desenvolvedores, o número de relações de rastreabilidade corretamente criadas, conforme
mostrado na Figura 3. Nesta figura observa-se que a média de relações criada com a técnica
indutiva (72,6) é significativamente maior do que a média obtida com a técnica matriz de
relacionamentos (28,2) e a média obtida com a técnica de criação de links (23,6).
Em função do tamanho da amostra, foram aplicados testes estatísticos de hipóteses
[9] para verificar se a diferença encontrada é significativa. O teste de hipóteses foi aplicado
primeiramente comparando a técnica indutiva com a matriz de relacionamentos. A hipótese
H0 (hipótese nula) é que em média o desempenho da técnica indutiva é igual ao da técnica
57
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
6. Conclusão
As principais técnicas de rastreabilidade apresentam limitações. A matriz de
relacionamentos, técnica atualmente utilizada nas organizações, torna-se de difícil
gerenciamento à medida que o número de artefatos aumenta. A recuperação automática,
apesar de ser uma alternativa para a matriz, pode detectar muitos relacionamentos falsos e
ainda não é amplamente utilizada por ferramentas CASE comerciais. As organizações ainda
58
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
buscam uma forma de criar as relações de rastreabilidade que forneça um bom custo-
benefício.
A principal vantagem da técnica indutiva comparada a matriz de relacionamentos
está no fato de que o desenvolvedor pode criar os relacionamentos de rastreabilidade de
forma integrada aos elementos, utilizando apenas o ambiente de criação dos elementos. Já
na matriz de relacionamentos o desenvolvedor deve criar os elementos e depois criar as
relações de rastreabilidade, utilizando para isto dois ambientes, um para a criação de
elementos, outro para a criação dos relacionamentos (matriz). A utilização de dois
ambientes pode tornar mais trabalhoso e menos eficaz o mapeamento da rastreabilidade.
O experimento realizado indicou que a técnica indutiva tende a apresentar uma
maior produtividade em relação às técnicas tradicionais, por meio da criação de um maior
número que relações de rastreabilidade. O esforço despendido para sua utilização pode ser
significativamente menor, tornando a atividade menos penosa, reduzindo o esforço do
desenvolvedor. Desta forma futuramente a técnica indutiva poderia ser utilizada nas
organizações.
Em relação à técnicas de recuperação automática (como LSI), a técnica indutiva não
apresenta as mesmas desvantagens, pois não procura identificar relações a partir de
artefatos existentes. Ao invés disso, a técnica indutiva procura criar as relações de
rastreabilidade no momento da criação dos próprios elementos, o que evita a formação de
falsas relações de rastreabilidade.
A técnica indutiva, por outro lado, propõe que a tarefa executada pelo
desenvolvedor seja redefinida. Ao invés de simplesmente desenhar uma classe em um
diagrama, o desenvolvedor deverá deixar claro o porquê desta classe, ou seja, qual o outro
elemento que fez com que ele chegasse à conclusão de que tal classe seria necessária.
A técnica indutiva proposta é eficaz apenas em sistemas cuja documentação ainda
vai ser produzida, onde se tem a oportunidade de utilizar a técnica desde o início. Ela não
detecta relações que deveriam existir entre elementos e que por alguma razão não foram
incluídas. Estas são limitações da técnica proposta. Nestas situações, ela pode ser
complementada, por exemplo, com a aplicação de recuperação automática.
Referências Bibliográficas
1. Gotel, O.C.Z. e Finkelstein, C.W. (1994) “An analysis of the requirements traceability
problem”, Requirements Engineering: Proceedings of the First International Conference,
p. 94-101.
2. Jiang, H., Nguyen, T. N.; Chang, C. K. e Dong, F. (2007) "Traceability Link Evolution
Management with Incremental Latent Semantic Indexing", In: Proceedings of the 31st
Annual International Computer Software and Applications Conference, IEEE Computer
Society, USA, p.309-316.
3. Lucia, A. D., Fasano, F., Oliveto, R., e Tortora, G. (2007) “Recovering traceability links
in software artifact management systems using information retrieval methods”, ACM
Trans. Softw. Eng. Methodol, USA, p.13.
59
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
4. Maletic, J. I., Collard, M. L., e Simoes, B. (2005) “An XML based approach to support
the evolution of model-to-model traceability links”, In: Proceedings of the 3rd
international Workshop on Traceability in Emerging Forms of Software Engineering,
ACM, USA.
5. Neumuller, C. e Grunbacher, P. (2006) “Automating Software Traceability in Very
Small Companies: A Case Study and Lessons Learned”, In: Proceedings of the 21st
IEEE/ACM international Conference on Automated Software Engineering, IEEE
Computer Society, USA, p. 145-156.
6. Oliveto, R., Antoniol, G., Marcus, A. e Hayes, J. (2007) "Software Artefact Traceability:
the Never-Ending Challenge", Software Maintenance, IEEE International Conference.
7. Palmer, J. D. (1997) “Traceability”, In: Software Requirements Engineering, R.H.
Thayer and M. Dorfman, p. 364-374.
8. Sparx Systems. (2009) "Enterprise Architect". Disponível em:
http://www.sparxsystems.com/products/ea. Acesso em: 01 mai. 2009.
9. Barbetta, P. A., Reis, M. M. e Bornia, A. C. “Estatística para Cursos de Engenharia e
Informática”. São Paulo: Atlas, 2004.
10. SmartGuyz Incorporatec. (2009) "ScreenCam". Disponível em:
http://www.smartguyz.com/index-2.html. Acesso em: 01 mai. 2009.
11. Marcus, A. and Maletic, J. I. (2003). “Recovering documentation-to-source-code
traceability links using latent semantic indexing”. In Proceedings of the 25th
international Conference on Software Engineering (Portland, Oregon, May 03 - 10,
2003). IEEE Computer Society, Washington, DC, 125-135.
12. Antoniol, G., Canfora, G., Casazza, G., De Lucia, A., and Merlo, E. (2002)
“Recovering Traceability Links between Code and Documentation”. IEEE Trans. Softw.
Eng. 28, 10 (Oct. 2002), 970-983.
13. Murta, L. G., Hoek, A., and Werner, C. M. (2008) “Continuous and automated
evolution of architecture-to-implementation traceability links”. Automated Software
Eng. 15, 1 (Mar. 2008), 75-10.
14. Aldrich, J., Chambers, C., and Notkin, D. (2002) “ArchJava: connecting software
architecture to implementation”. In: Proceedings of the 24th international Conference on
Software Engineering. ICSE '02. ACM, New York.
15. Settimi, R., Cleland-Huang, J., Khadra, O. B., Mody, J., Lukasik, W., and DePalma, C.
(2004) “Supporting Software Evolution through Dynamically Retrieving Traces to UML
Artifacts”. In: Proceedings of the Principles of Software Evolution, 7th international
Workshop. IWPSE. IEEE Computer Society, Washington, DC.
16. Egyed, A., Biffl, S., Heindl, M., and Grünbacher, P. (2005) Determining the cost-
quality trade-off for automated software traceability. In Proceedings of the 20th
IEEE/ACM international Conference on Automated Software Engineering. ASE '05.
ACM, New York, NY, 360-363.
60
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
17. Lormans, M. and Van Deursen, A. (2006) Can LSI help Reconstructing Requirements
Traceability in Design and Test?. In Proceedings of the Conference on Software
Maintenance and Reengineering, CSMR. IEEE Computer Society, Washington, DC, 47-
56.
18. Antoniol, G., Cimitile, A., and Casazza, G. (2000) Traceability Recovery by Modeling
Programmer Behavior. In Proceedings of the Seventh Working Conference on Reverse
Engineering (Wcre'00), WCRE. IEEE Computer Society, Washington, DC, 240.
19. Egyed, A., Biffl, S., Heindl, M., and Grünbacher, P. (2005) Determining the cost-
quality trade-off for automated software traceability. In Proceedings of the 20th
IEEE/ACM international Conference on Automated Software Engineering ASE '05.
ACM, New York, NY, 360-363.
20. Cleland-Huang, J., Zemont, G., Lukasik, W. (2004) "A Heterogeneous Solution for
Improving the Return on Investment of Requirements Traceability," Requirements
Engineering, IEEE International Conference on, pp. 230-239, 12th IEEE International
Requirements Engineering Conference (RE'04).
21. Cleland-Huang, J. (2006) Just Enough Requirements Traceability. In Proceedings of the
30th Annual international Computer Software and Applications Conference - Volume 01
(September 17 - 21, 2006). COMPSAC. IEEE Computer Society, Washington, DC, 41-
42.
22. De Lucia, A., Fasano, F., Oliveto, R., and Tortora, G. (2006) Can Information Retrieval
Techniques Effectively Support Traceability Link Recovery?. In Proceedings of the 14th
IEEE international Conference on Program Comprehension. ICPC. IEEE Computer
Society, Washington, DC, 307-316.
23. Almeida, J. P., Eck, P. v., and Iacob, M. (2006) Requirements Traceability and
Transformation Conformance in Model-Driven Development. In Proceedings of the 10th
IEEE international Enterprise Distributed Object Computing Conference. EDOC. IEEE
Computer Society, Washington, DC, 355-366.
24. Jesse Fletcher, Jane Cleland-Huang. (2006) "Softgoal Traceability Patterns," Software
Reliability Engineering, International Symposium on, pp. 363-374, 17th International
Symposium on Software Reliability Engineering (ISSRE'06).
25. De Lucia, A., Oliveto, R., Zurolo, F., and Di Penta, M. (2006) Improving
Comprehensibility of Source Code via Traceability Information: a Controlled
Experiment. In Proceedings of the 14th IEEE international Conference on Program
Comprehension. ICPC. IEEE Computer Society, Washington, DC, 317-326.
61
TECHNICAL SESSION 2
Systematic reviews (SR)
62
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
Abstract. Software Product Lines are a systematic way to achieve the benefits
related with large-scale reuse. In Software Product Lines, an important phase
is the Scoping, which is essential for the success of the product lines. It aims
to determine the viability of a product line, identifying aspects such as:
products that will constitute the product line, risks, reuse potential and costs
for implementation of the core assets. However, some of their important
aspects are not well-defined in the existent approaches, as the customization
of the Scoping according to the context in which is inserted. In this context,
this paper presents a systematic literature review in order to investigate the
state-of-the-art, trying to summarize the current scenario, identifying best
practices, challenges and limitations.
1. Introduction
Software Product Lines (SPL) is currently considered an efficient way to achieve the
benefits related to large-scale reuse. Its adoption in the industry has decreased
implementation costs, reduced time to market and improved quality of derived products
[Clements and Northrop 2007]. According to [Clements and Northrop 2001], “a
software product line is a set of software-intensive systems sharing a common, managed
set of features that satisfy the specific needs of a particular market segment or mission
and that are developed from a common set of core assets in a prescribed way”. In
general, the software product line engineering paradigm involves two processes: core
asset development, responsible for establishing the reusable platform and to define the
commonality and variability of the product line; and product development, responsible
for deriving product line applications from the platform established in core asset
development [Pohl et al. 2005]. Both processes cover all phases of software
development such as scoping, requirements engineering, design, implementation, testing
and evolution.
In this life cycle, scoping is a process by which information used in developing
software systems within the domain is identified, captured and organized with the
purpose of making it reusable when building new products [America et al. 2001].
According to Kruchten [Kruchten 1998], the scoping captures the context, the most
important requirements and constraints in order to derive acceptance criteria for the end
product. Hence, is clear the association of scoping to the SPL success, being necessary a
scoping process very well-defined to implant efficiently product lines and to reduce their
risks.
63
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
Organizations that desire to adopt SPL and need to define scope should identify
the most appropriate approach to its context, considering the main activities defined in
the approaches. Thus, the analysis and comparison among existent scoping approaches is
crucial for selection of an appropriate approach for a specific context.
In this context, this paper presents a systematic review to investigate the existent
approaches on SPL scoping, aiming to identify, compare and summarize evidence about
the scope definition techniques, analyzing their activities, roles, guidelines, concepts,
strong points and drawbacks, and the main features. This study is based on interesting
issues analysis, covered by a set of research questions. Moreover, since it is
systematically performed and documented, its result is believable to serve as a guide to
aid the research community regarding future directions. In addition, it is important to
summarize the current status of the approaches in the field of scoping. Finally, for
practitioners, it can identify the more appropriate approach to be used in industrial
scenarios. This review is systematically performed following Kitchenham's guidelines
[Kitchenham and Charters 2007], which aids in assuring consistent results from
individual studies (called primary studies).
This paper is organized as follows: Section 2 discusses related work in the field.
Section 3 discusses the research question and the studies investigated. The obtained
results are presented in Section 4. Section 5 discusses the threats and, finally, Section 6
presents concluding remarks and future work.
2. Related Work
Two surveys were found with a similar proposal: to evaluate scoping approaches.
Schmid [Schmid 2000] presented a survey of scoping-related technology, both
from software engineering, as well as from non-software disciplines, presenting a
framework for approaches analysis associated to two problem dimensions: task of
scoping and object of scoping, and two solution dimensions: scoping product and
scoping process. This framework is used to structure the field of scoping. The analysis
made in [Schmid 2000] had the following goals:
Organize and structure the field of scoping;
Provide an overview of what approaches exist for scoping and their relevant
advantages and disadvantages;
Aid in selecting among existent approaches; and
Aid in improving existent methods and building news ones.
In [John and Eisenbarth 2009] was performed the investigation of some aspects
in SPL scoping. Their focus was to identify the following aspects: the goal of the
approaches, how to treat variability, the main inputs and outputs of the approaches, the
involved roles, the effort to perform scoping, and the maturity and benefits with the use
of the approaches.
Moreover, in this survey were indicated some new research questions such as:
How is the connection of scoping and Requirements Engineering?
How is the connection between scoping and architecture?
How to produce quantifiable results?
It is important to highlight that our work performed the evaluation using a formal
and defined approach. Thus, it can be repeatable for other researchers and research
64
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
groups, since all the process was documented and detailed in the protocol of the
systematic review and can be accessed on the web page:
http://www.cin.ufpe.br/~sople/scoping/sr/. In addition, several issues and approaches
that were not considering in [Schmid 2000] as approaches which define stakeholders,
agile characteristics with SPL and so on are being extensively discussed in our review.
Moreover, our study can be useful to reinforce the findings identified in [John and
Eisenbarth 2009] since we investigated similar issues such as: main activities, inputs,
outputs, defined stakeholders, and so on. On the other hand, our research complements
their work since new issues are also investigated by our research questions, such as:
customization, relationship between SPL and development agile principles and metrics.
Q2. Do the SPL This question aims to identify if the approaches optimize scope and which techniques are used for this
approaches optimize optimization. Optimize scope is to adapt a scope to maximizes specific objectives [Schmid 2002], i.e. to
scope? align the scope according with business objectives of the organization, as time-to-market and development
effort.
Q3. What are the types The purpose of this question is to identify the types of scope covered by each approach. According to
of scope addressed by the Schmid [Schmid 2002], in general, three types of scope can be identified: I. product portfolio scoping, it
approaches? aims at identifying the particular products that should be developed as well as the features they should
provide; II. domain scoping, it is the task of bounding the domains that are relevant to the product line;
and III. assets scoping, it aims at identifying functional parts of the product line that should be developed
in a reusable manner. This question is important to identify the focus of each approach.
Q4. Which stakeholders This question aims to identify the essentials stakeholders at the scope definition process and their
are involved in the scope importance (roles and attributions). According to Clements [Clements 2005], the involvement of a wide
definition process? range of stakeholders increases the awareness of the product line efforts, obtains stakeholders' critical
input, and builds momentous for the long-term investment in core asset development and use.
Q5. Do the approaches The goal of this question is to identify if the approaches for scope definition use specific metrics, general
use specific metrics or software metrics or cost models. Moreover, this question aims to identify which types of metrics are used
cost models for scope and their importance for the economical value evaluation of the software product line assets.
definition?
Q6. Are the approaches The goal of this question is to identify if the approaches are customized for different contexts. Besides, the
customizable? question aims to determine which customization factors are used.
Q7. Do the approaches The goal of this question is to identify if the approaches insert agile aspects in scoping and which
treat the new perspective techniques, principles or practices are used.
of agile SPL planning?
Q8. How are the The goal of this question is to identify if the approaches have specifics activities to define scope according
approaches related with with the different development stages, considering situations as: product line development started from the
SPL development? scratch, product line development with existents products and evolution of an existent product line.
From the research question were extracted some keywords used to search the
primary study sources. They are: scope, domain scope, product scope, assets scope,
features scope, scope definition techniques, scope definition and scope metrics. All
terms were combined with the term “Software Product Line” and “Software Product
Family” by using Boolean “AND” operator, to match the search goals. At the end,
sixteen strings had been generated. They all were joined each other by using “OR”
operator so that it could improve the reliability of the results.
65
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
The search process was manual and performed in references found in related
papers to the topic, digital libraries of some important publishers and organizations in
software engineering and web search engines such as IEEE, ACM and Springer Link. In
this search, were also considered important conferences as: Annual ACM Symposium on
Applied Computing, Euromicro Conference on Software Engineering and Advanced
Applications, Fundamental Approaches to Software Engineering, International
Computer Software and Applications Conference, International Conference on
Advanced Information Systems Engineering, International Conference on Software
Engineering, Asia Pacific Software Engineering Conference, International Conference
on Software Reuse, Software Product Line Conference; and journals as: ACM TOSEM,
Communications of the ACM, IEEE Computer, IEEE Software, IEEE Transaction on
SW Engineering, Journal of Systems and Software, Software Practice and Experience
Journal.
The selection of the papers was performed in two stages. In the first stage for
each selected primary study was applied a brief analysis of the following elements: titles,
abstracts, keywords, conclusion and references. The resulted of this stage was 28 studies
raised from the web search. In the second stage was performed a complete analysis of
the 28 studies found in the first stage. After complete analysis and application of our
criteria of inclusion, exclusion and quality, 11 approaches and two surveys were
included in our review.
All the information used in the search and selection of the studies as: keywords,
list of search engines, conferences and journals, and the criteria for selection can be seen
in the systematic review web site.
4. Reporting
In this section, the results of the review will be presented and each research question will
be discussed and analyzed, and conclusions will be drawn.
John [2006] mandatory activities: product prioritize and domain, yes yes yes no no
identification, plan product optimized the assets
releases, assess features, identify feature matrix
features, specify product feature
matrix and identify domains
Inoki [2007] product line development plans do not define assets no yes no no no
analysis, create product line optimization
development plan, create road tasks for scoping
map, define organizational
standards
Noor [2007] identify and agree domains, make domain, yes no no yes no
define features for each domain, prioritization assets
analyze products, define products and optimization
in terms of features, prioritize of the product
product map map
67
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
5. Threats to Validity
In this study, the following threats were related to the review: I. research questions, it
is possible that some questions defined in the protocol and which drive the systematic
review are not so relevant. In order to avoid it, we had several discussions with RiSE
members and experts in the area; II. search of the approaches, it is possible also that
our search criteria did not find all the relevant approaches. Nevertheless, we searched the
main conferences and journals and checked the references found in these papers to avoid
it; III. excluded studies, in this case, the research team had discussions in order to
define a consensus about the work to be excluded. Besides, criteria of exclusion and
inclusion were defined to aid in this decision.
70
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
Helferich, A., Herzwurm, G. and Schockert, S. (2005) “QFD-PPP: Product Line Portfolio
Planning Using Quality Function Deployment”, In: 9th International Software Product Line
Conference, France, p.162-173.
Inoki M., Fukazawa, Y. (2007) “Core Asset Scoping Method: Product Line Positioning Based on
Levels of Coverage and Consistency” In: First International Workshop on Management and
Economics of Software Product Lines, Japan.
John, I., Knodel, J., Lehner, T. and Muthig, D. (2006) “A Practical Guide to Product Line
Scoping”, In: 10th International Software Product Line Conference, USA, p.3-12.
John, I. and Eisenbarth, M. (2009) “A Decade of Scoping – A Survey”, In: 13th International
Software Product Line Conference, USA.
Kishi, T.; Noda, N. and Katayama, T.A (2002) “Method for Product Line Scoping Based on a
Decision-Making Framework”, In: 6th International Software Product Line Conference, USA,
p. 348-365.
Kitchenham, B. and Charters, S. (2007) “Guidelines for Performing Systematic Literature
Reviews in Software Engineering”, In: 11th Evidence-Based Software Engineering, technical
report, USA.
Kruchten, P. (1998) The Rational Unified Process: An Introduction, Reading, Ma.: Addison-
Wesley.
Lee, J., Kang, K. C. and Kim, S. (2004) “A Feature-Based Approach to Product Line Production
Planning”, In: 8th International Software Product Line Conference, USA.
McGregor, J. D. (2008) “Agile Software Product Lines, Deconstructed” In: Journal of Object
Technology, Volume 7, Issue 8, p. 7-19.
Noor, M.A, Rabiser, R.; Grünbacher, P. (2008) “Agile Product Line Planning: A Collaborative
Approach and a Case Study” In: Journal of Systems and Software, Volume 81, Issue 6.
Park, S. Y. and Kim, S. D. (2005) “A Systematic Method for Scoping Core Assets in Product
Line Engineering”, In: 12th Asia-Pacific Software Engineering Conference, USA, p.491-498.
Pohl, K., B¨ockle, G. and Van der Linden, F. (2005) Software Product Line Engineering:
Foundations, Principles, and Techniques.
Riebisch, M., Streitferdt, D. and Philippow, I. (2001) “Feature Scoping for Product Lines”, In:
International Workshop on Product Line Engineering – The Early Steps: Planning, Managing
and Modeling, Germany.
Rommes, E. (2003) “A People Oriented Approach to Product Line Scoping: Enabling
Stakeholder Cooperation with User Scenarios”, In: International Workshop on Product Line
Engineering, Germany, p.284-303.
Schmid, K. (1999) “An Economic Perspective on Product Line Software Development”, In: First
Workshop on Economics-Driven Software Engineering Research, USA.
Schmid, K. (2000) “Scoping Software Product Lines - An Analysis of an Emerging Technology”,
In: Software Product Line Conference, p. 513-532.
Schmid, K. (2002) “A Comprehensive Product Line Scoping Approach and its Validation”, In:
Proceedings of the 24th International Conference on Software Engineering, USA, p. 593-603.
72
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
!
% % *
" " #$ &' ( " & " )
!"#$ % &"$'$(#$$ )* % +
'
, -.
/. ) /)0/. % /. /) % +
antoniocarloscjr@hotmail.com, thelma@din.uem.br, masiero@icmc.usp.br
!" #
!$ % % %
%
%
%
%
& % '
() (* + " )
() % ' ()
, % () $ %
-
) ' & %
() . / () ()
0 '
%
%+
1 2 ) / 3 1)/ 4
3 5 2 5 6
7 8 9 2
###: ; 5 2 <
1)/ = 7 5 1)/
2 81 1 6 * 4 '$$>:
? ; 5
5 . 5
( % 4 @
7 @ 4
73
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
? 1)/ A 2
7 2 -. 2 7
7 7
< 9 ;
5 7 . B 2 -.
C -. -. -.
7 D 5 .
E F 5 7
G C -. 1)/ 3
H 89IJ KI 6 3 6 L '$$!:A
• @ 2 % % A ( 5
. . 6 . M
• @ 2 % A ( 5
. ; 6 . M
• @ - % A ( 5
. ; 6
. C 6 -.
@ ( 5 2 M 2
2 M 5 2
N
@ ) H ;
? -. ? 81 1 6 * 4 '$$>:
) -. ? )? ;
-. -. 8 2 *
L '$$>: , -. @ 5 ;
(
)? 5 6 -. 3 8O 6
##": 9 = ; 2 2 5 ;
= , )? -.
1)/ . 6 .
; 6 5 4 ;
2 ( ( ) 5
4 = ; .
= . 2 . 7
-. 5 ; 8O 2 2 '$$P:
. A 4 -. -. 2
4 . 6
-. 7 C 6 -. )?
-. 1)/ ? = 6 A
/ -. ' 4 -. .
/ -. Q . 2 )
/ -. P -R 2
74
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
*+ , "
. 4 =
2 O 2 2 '$$P
+ 2 '$$! ?
R 4
) -. - ( -.
-. .
B< 6 '$$#
- , ? 4 . ;
-. 1)/ 6 )? ;
= 5 2 6 -. )?
-. -. 1)/ 4 =
. / 0 5 R 5 -. . A
• G . ) A G ; , 6
1)/ S
• G . / A 5 -R 6 -. )?
C -. 1)/S
• G . / 'A G 0 ,
)? -. 1)/S
• G . / QA G = ,
-. 1)/ S
" 1 5 R .
; . 2 A
• G . ) A K; 1)/
• G . / A/ -R 5 6 -. )?
C -. 1)/
• G . / 'A ) 0 )?
-. 1)/
• G . / QA = 5 -.
1)/ 6
( 12 3 ( ! )
; , 5
5 6 5 4 2
( 2 K .
5 , A
• T A H =
5 H U /
• K 2 A , 7
2 7 M) , -R
7
75
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
• ) ( 2 A E F E ! % F ,
E 2 F E) -. ? F ,
-R A
- 1 ! !
- !$ % 1 % % $ !
$ 2
- 1 . .
- % () $ 1 $ () $
2 $ 2 $
) -.
% ( 2 K
C 5 T
2 ? 2 ;
. 7
4 (5 9 2
5 5 6 7
; 7 2
5 -. 2 ; . ;
2 5 5 R . 2 5
. 5 R = 7 ; = .
*+%+ "
. 6 7 '$$& 4 2 '$$#
'$$& 6
5 2 )
6 4 2 '$$#
5 ; -.
T 2 4 5 ;
2 5 2 . ? ( 5
6 R . = .
2
T 7 % .
6 4 -R ( 2 -R A
(linha de produtos OR família de produtos) AND (Programação
Orientada a Aspectos OR Orientação a Aspectos OR POA OR
Desenvolvimento de Software Orientado a Aspectos OR DSOA)
(product line OR product-line OR product family OR product-
family OR family of products) AND (aspect-oriented program OR
aspects programming OR AOP OR aspect-oriented software
development OR aspect oriented software development OR AOSD)
C 5 6
-R % D 5
76
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
% 6
. 5 5
9 -. # 2 5
5 "" -. 2
5 $
? 4 &" 2 7
5 = PQV -.
&" P> 7 -.
T
'$' 2 = 7 ""V 'QV
2 7 "$V ; -.
1)/ 6 )? 5 Q$V
-. ; T
Figura 1. (a) Estudos incluídos na revisão classificados por fonte; (b) Classifi-
cação dos estudos selecionados.
6+
? @ . 2
2 (
B< 6 '$$# T -. A
) -. 1)/ 6 )? 5
; 6 -. 5 .
. 5 .
= 6 =
-. 5 R
2 4
; 2 =
7 6
2 K 2 5
= 5 . Q
5 7 -.
( -. )?
-. 1)/ 7
77
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
• 74- 8 - AG 2 5
; ? 4 ;
T? =
; -.
( 3 8 + I '$$>:
4 8 6 ? '$$P:
• A 2
-. 6 -.
1)/
• - - , 7--8 ,! 5 A
1)/ -. 4 @
2 2 ; - 9 -.
)? -.
5
5 -. )? 6
-. 7 , ;
6 7 2 6 -. @
• . / - A
1)/ ;
-. 7 9
2 5 R
1)/ )
= W 2 '$$# -. )? 6 -.
< -. *
'$$" ; 5
-.
1)/
• 2 2 9 - A ; T? 2 ;
6 -. -. 4 )?
-R @ 8O 6 '$$>:
• : - 7);;8 A
G 2 9
. ; -R 5
4 1)/
R -. 7
)? -. 8U 2 '$$!:
• 0 A
2 -. )? 5 . (
) ; , 6 -.
5 1)/ 7
7 .
)? 6 -.
1)/ 5 % 1)/ 4 =
78
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
• - )
% 1)/ ?? )? 6 -. 4 )? %
2 -. 7
1)/ -. 5 1)/ )? -.
1)/ @
? 7
7 5X -R 2 @
1)/ -R U
? 7 A
U 4 . 0 / 1 /
; H
( 5 B
-.
WI 0B 2 5
6 -.
K ' . 9
( ;
-. 1)/ )?
9 (
7 -. K
2 2 R
)? ; T? ) -. U
? 2 6 )?
1)/ = )? -.
< )? -.
5 2 5 3 5
5 R ' . ( 7
6 -. )? -. 1)/
( 5 7
2 7 . A @ 2
-. (
@ 9 <
2 7 0 6 -.
1)/
* ( 5 2 7 P !
, )?
1)/ .
P' PQ -R )? ??
<+ " / 4
6 -. .
< . -.
; -.
1)/ 6 )?
79
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
-. C . ( 5 4
-R -.
% 9 '$' 5 P>
. 4 'QV
-R ( 5
%
. R
6 -. . ( 5 6
-R ( 2 2 H
( 2 7 % ;
( 5 4 .
6 < 5 5
5 = 7 4 -.
80
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
) ( 5 . 2
5 5 -. ;
5 -. 2 2 5 -. 9
( 5 7 .
4 5
1 ( -. .
A -.
)? -. 1)/
G C ; = -.
)? 1)/ ; . -. -.
1)/ 2 3
; 5 - -. 3
5 ; 5 = R ; 5
/ 3 ? 4 = 1)/
? 2 5 , -.
-R - 6 -. )?
-. 1)/ . 5 2
3 1)/ -
; 7
- 0 5 )? 1)/
2 7 )?
-. 5 . (
= 2 5 )? ;
5
T . .
5 K 5 ( C -.
1)/ )? 4
-. =
2
U ) K0 (/ /
>
/ + I '$$> EL2 T S / IF
A) 2 !2 U )
) 9 3 Y Z 9Y / !#%>&
+ 2 BM ) UM9 MK U W '$$! E/I 3
3 F K 2 * *K( / >"#0$! ) / ( ?)) 0 T*B
) 9 2 1 ### E T 3 Z / 3 ) 1
) F [ . '$ / 3 I
) 2 ) B I ###
B< 6 K '$$# E * . /
-. [ 1)/ 6 )? F * @ ; 9
81
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
0)* + 333 0\
U 2 + 2 / / 23 '$$! E T )
F 2 #2 / 3 ) 1
) 2 L Z2 / 3 ) 1 *
T - / '$$!
W / 2 '$$# E* [ I / 3 ) 1
(? ) F 2 T 2
/ 3 * 2 ) ]
) ) / '$$#
O 6 UM 1 BM 2 Z M M 1 M 1 B M
3 B ##" E (? ) F ) 2 2
? 4 (? ) ??) T
/ ([ 19 / 'P B ##"
O 2 2 + '$$P E) I 3F B
K 2 * K*0/ ($P$ O % $P$$$ K 9 K / 3
U % / ( O I
/ 3 %9 K 1 O 0/ ( O
2(
O 6 1 B ) ) U '$$> E 6 (
? [ U K 2 5 F 2 &2
/ 3 O 3 /. T
1 B 1 6 * * * 4 W '$$> EK2 * )
1 [ F 2 !2 U )
) 2 U) '$$> L Z 2 (
? ) 1 '$$> ) ? '$$>
2 O * ? L '$$> E I (?
K 2 5 / 3 ) (1 F 2
* 5 L Z2 ) ]
/ '$$>
6 M ? O '$$P E[ I 3 2 T (?
) F A ) 2 '2 / U/?TK
/I T / 3 ) 9 3
Y Z / '$$P '"% Q>
9IJ KI 6 3 6 / L K '$$! E
[ I / 3 ) 1 S / IF 2 #2
/ 3 ) 1 ) 2 L Z2
) (1 % I L Z2 * T
* B ) + ) '$$" E? 2 I
(? 2 K 2 5 ) 1
[ F A ^^ / @ + 2 / 3 /+ / '$$"
'$$" B . ) ) 2 1 L Z2 (
? / 3 1 (L /) '$$" #( Q$
82
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
Abstract. This paper presents an approach that uses Visual Text Mining (VTM)
techniques and associated tool to support the reliability of inclusion and exclu-
sion decisions in the conduction stage of a systematic review. The approach has
been applied to real systematic reviews and the results showed that the use of
visualization is an additional component and it can assist the reviewer to decide
that relevant studies were not deleted.
Resumo. Este artigo apresenta uma abordagem que faz uso de técnicas de Mi-
neração Visual de Texto (Visual Text Mining - VTM) e ferramenta associada
para apoiar a revisão da seleção de estudos primários na etapa de Execução da
revisão sistemática. A abordagem foi aplicada em revisões sistemáticas reais
e os resultados mostraram que o uso da visualização é um componente adicio-
nal e pode auxiliar o revisor na decisão de garantir que estudos relevantes não
foram eliminados.
1. Introdução
A comunidade de Engenharia de Software tem adotado revisões sistemáticas como uma
forma de reunir dados de diferentes estudos experimentais para caracterizar uma dada
tecnologia.
A revisão sistemática é uma maneira de avaliar e interpretar toda pesquisa re-
levante e disponível sobre uma questão de pesquisa específica, tópico ou fenômeno de
interesse, fazendo uso de uma metodologia de revisão que seja confiável, rigorosa e que
permita auditagem [Kitchenham 2004].
O processo de condução da revisão sistemática, adaptado para a Engenharia de
Software, foi sugerido por Biolchini et al. [2005] e baseado nas diretrizes iniciais propos-
tas por Kitchenham [2004]. O processo envolve três etapas, o Planejamento da revisão, a
Execução e a Análise dos Resultados [Biolchini et al. 2005].
Durante a etapa de Planejamento é identificada a necessidade de uma nova revi-
são sistemática, os objetivos da pesquisa são definidos e é criado o protocolo, que contém
itens como a seleção de fontes, métodos de busca e palavras-chave, critérios de inclusão,
exclusão e qualidade dos estudos primários [Biolchini et al. 2005]. Experimentos con-
trolados, estudos de caso e surveys são exemplos de estudos primários, que atuam como
fonte de informação para as revisões sistemáticas, ou seja, os estudos experimentais é que
levantam os dados que são agrupados e sumarizados pelas revisões sistemáticas, que são
os estudos secundários [Kitchenham 2004, Sjøberg et al. 2007].
83
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
A etapa de Execução tem como objetivo a obtenção e análise dos estudos primá-
rios. Assim, os estudos são identificados, coletados e organizados em uma lista. Então os
critérios de inclusão e exclusão definidos no protocolo são aplicados nos estudos da lista
em duas etapas, inicialmente por meio da leitura do título, resumo e conclusões, seguido
pela leitura do texto completo. Os resultados dessa análise são registrados, sendo que a
lista dos estudos deve ser reavaliada para garantir que não foram eliminados estudos re-
levantes (Revisão da Seleção). Ao final dessa atividade, as informações são extraídas dos
estudos identificados como incluídos.
Por fim, é na etapa de Análise dos Resultados que os resultados dos estudos primá-
rios que atendem ao propósito da revisão são sintetizados. Essa síntese pode ser descritiva,
mas um sumário quantitativo obtido por meio de um cálculo estatístico pode complemen-
tar a descrição [Kitchenham 2004].
Como mencionado anteriormente, a atividade de Revisão da Seleção procura evi-
tar a eliminação de estudos relevantes, o que pode prejudicar consideravelmente o re-
sultado final da revisão, uma vez que exclui informações que deveriam ser avaliadas e
sintetizadas na etapa de Análise dos Resultados. Este artigo tem como objetivo propor
uma abordagem que faz uso combinado de técnicas de Visual Text Mining (VTM) para
auxiliar a Revisão da Seleção dos estudos primários, oferecendo as seguintes contribui-
ções: (i) Revisão sistemática com dois ou mais revisores: A abordagem proposta auxilia
na discussão das divergências entre revisores, oferecendo outros recursos para apoiar a
tomada de decisão; e (ii) Revisão sistemática individual: A abordagem proposta pode
sugerir indícios sobre quais artigos devem ser revistos, tanto para inclusão, quanto para
exclusão, sem se basear em uma escolha aleatória.
Este artigo está organizado da seguinte forma: na Seção 2 são apresentados os
trabalhos relacionados; na Seção 3 a abordagem é descrita, juntamente com a sua aplica-
ção em revisões sistemáticas reais e os resultados obtidos. Por fim, na Seção 4 estão as
conclusões e os trabalhos futuros.
2. Trabalhos Relacionados
Exemplos de clusters puros estão identificados na Figura 2(a) pelas marcações (a).
Exemplos de clusters mistos estão identificados na Figura 2(b) pelas marcações (b). Por
fim, um exemplo de ponto isolado está identificado na Figura 2(b) pela marcação (c). A
avaliação dos clusters pode ser refinada com o apoio de recursos baseados em conteúdo ou
citação, descritos na sequência, e que podem ser utilizados individualmente ou de forma
combinada.
similares à azuis.
Vale destacar que sem o uso do histórico todos os clusters mistos deveriam ser
reavaliados. Os mapas e o recurso de histórico foram considerados, na opinião dos es-
pecialistas, um mecanismo importante para embasar a decisão inicialmente tomada (e
mantida) de incluir ou excluir um determinado estudo primário da revisão.
O segundo recurso é similar ao primeiro, mas ao invés de colorir o mapa com base no his-
tórico, o mesmo é colorido de acordo com a qualidade definida e atribuída pelos revisores
para cada um dos estudos incluídos. A revisão sistemática 4 foi formatada para apresentar
a aplicação desse recurso.
modo a complementar o que somente o conteúdo não revela. A rede de citações é uma
dessas opções.
A forma mais comum de representar visualmente as redes de citações (redes
complexas) é por meio de grafos, que são formados por um conjunto de vértices
e arestas, os quais representam os objetos e as relações entre eles, respectivamente
[Andery et al. 2009]. Nesse caso, os estudos primários (vértices ou pontos) e suas re-
ferências bibliográficas (arestas).
Através dessa visualização é possível identificar, por exemplo, estudos que não
estão conectados aos demais, ou seja, não compartilham referências. Esses estudos, que
estão isolados em termos de referências, merecem atenção por parte dos especialistas (re-
visores). Outro caso que merece destaque são as referências de estudos incluídos com
muitas conexões. Isso porque buscas por estudos usando bibliotecas digitais e palavras-
chave podem não ser suficientes para uma revisão sistemática completa. Outras fontes
devem ser pesquisadas, incluindo as listas de referência dos estudos revisados e classifi-
cados como incluídos [Kitchenham et al. 2007].
Exemplificações de redes de citações estão ilustradas na sequência, com outros
conjuntos de revisões sistemáticas. As Figuras 5(a) e 5(b) representam as redes de citações
das revisões 5 e 6, respectivamente. Essas redes também foram geradas pela ferramenta
PEx, que foi adaptada por Andery et al. [2009] para permitir esse tipo de visualização.
Os pontos vermelhos representam artigos excluídos; os azuis, os incluídos; e os cinzas,
artigos referenciados.
Foi possível visualizar na rede de citações da Figura 5(a) que a maioria dos arti-
gos incluídos (localizados na região central) compartilham as mesmas referências, assim
como os excluídos (localizados na região à esquerda, acima). Os estudos isolados foram
todos classificados como excluídos. Vale destacar que o “ponto azul” localizado no canto
inferior direito, se observado com detalhe, não é um único ponto isolado, mas dois pon-
tos que compartilham exatamente as mesmas referências, não citadas em nenhum outro
estudo.
Situações críticas e que merecem ser reavaliadas foram percebidas na rede de
citações correspondente à revisão sistemática 6 (Figura 5(b)). Uma delas é a presença de
89
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
estudos incluídos totalmente isolados do restante (pontos azuis conectados apenas com
suas respectivas referências), que totalizam 10 ocorrências.
Um recurso adicional que pode ser utilizado é a técnica de coordenação por igual-
dade. Essa técnica cria um relacionamento direto entre os mesmos documentos contidos
em diferentes visualizações. Dessa forma, quando um estudo primário ou um conjunto
de estudos é selecionado no mapa de documentos, os mesmos objetos são destacados na
rede de citações (ou vice-versa).
Na Figura 6 está ilustrado o uso da estratégia de coordenação por igualdade para
a revisão sistemática 5, sendo que na Figura 6(a) está apresentado o mapa de documentos
dessa revisão sistemática e na Figura 6(b) a sua respectiva rede de citações. Os mesmos
documentos selecionados no mapa da Figura 6(a) (pontos destacados à esquerda, acima)
estão ressaltados na rede de citações da Figura 6(b) (ao centro). Os documentos (pontos)
destacados permanecem com suas opacidades originais e os demais, não selecionados,
ficam semi-transparentes. A utilização da coordenação permitiu visualizar que os estudos
incluídos e localizados no mesmo cluster, além de similares em termos de conteúdo, são
citados entre si.
aleatória dos artigos a serem reavaliados, sendo essa escolha baseada em critérios de
similaridade e citações, ou seja, em informações sólidas contidas no conjunto de estudos,
porém não reveladas sem o auxílio visual.
Um dos formatos de entrada aceito pela PEx é o próprio conjunto de documentos
em formato de texto. Por isso, se os estudos estiverem armazenados em qualquer outro
formato, é necessária a conversão, uma tarefa a mais ao processo de revisão, que já é
moroso, sendo essa uma limitação quanto à utilização da abordagem.
Como trabalho futuro, pretende-se automatizar a conversão dos estudos primários
para o formato de entrada da PEx. Além disso, deverá ser investigado o uso de me-
didas de importância de vértice em redes complexas (redes de citações), como grau de
centralidade (degree centrality), grau de proximidade (closeness centrality) e grau de in-
termediação (betweenness centrality), de modo a fornecer informações adicionais para o
revisor embasar as suas escolhas, uma vez que essas medidas permitem identificar o grau
importância de um vértice dentro da rede. Essas medidas serão implementadas na PEx e
será avaliado o uso das mesmas para apoiar as atividades de seleção e revisão dos estudos
primários.
Referências
Andery, G. F., Lopes, A. A., and Minghim, R. (2009). Exploração visual multidimen-
sional de redes sociais. In 2nd International Workshop on Web and Text Intelligence
(WTI’09), pages 1–9, São Carlos.
Biolchini, J., Mian, P. G., Natali, A. C., and Travassos, G. H. (2005). Systematic re-
view in software engineering: Relevance and utility. Technical Report RT-ES 679/05,
PESC/COPPE/UFRJ.
Kitchenham, B. (2004). Procedures for performing systematic reviews. Technical Report
TR/SE-0401, Keele University and NICTA.
Kitchenham, B. A., Mendes, E., and Travassos, G. H. (2007). Cross versus within-
company cost estimation studies: A systematic review. IEEE Transactions on Software
Engineering, 33(5):316–329.
MacQueen, J. B. (1967). Some methods for classification and analysis of multivariate
observations. In Cam, L. M. L. and Neyman, J., editors, Proceedings of the fifth Berke-
ley Symposium on Mathematical Statistics and Probability, volume 1, pages 281–297.
University of California Press.
Malheiros, V., Höhn, E. N., Pinho, R., Mendonca, M., and Maldonado, J. (2007). A visual
text mining approach for systematic reviews. In Proceedings of the First International
Symposium on Empirical Software Engineering and Measurement (ESEM’07), pages
245–254, Washington, DC, USA. IEEE Computer Society.
Paulovich, F. and Minghim, R. (2006). Text map explorer: a tool to create and explore do-
cument maps. In Proceedings of the conference on Information Visualization (IV’06),
pages 245–251, Washington, DC, USA. IEEE Computer Society.
Sjøberg, D. I. K., Dybå, T., and Jørgensen, M. (2007). The future of empirical methods in
software engineering research. In Briand, L. and Wolf, A., editors, Future of Software
Engineering (FOSE’07), pages 358–378. IEEE Computer Society.
92
TECHNICAL SESSION 3
Verification, validation and test
(VV&T)
93
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
1. Introduction
Data persistency is an attribute associated to the demand for non-volatile data. Applica-
tions that manipulate such data are different from conventional applications, since they
incorporate persistent data in their execution input and output domains. In this context,
database-enabled applications play an important role in the majority of modern organiza-
tions [Chays et al. 2000]. A database application is a program running in an environment
containing one or more databases [Kapfhammer and Soffa 2003]
Considering that faults are inherently part of software production, the proposition
of approaches to improve the quality of database applications is pertinent. Software test-
ing is the most commonly used method of software quality assurance. Software testing
techniques for conventional programs have been proposed, implemented and evaluated
over the years, but relatively little effort has been dedicated to the development of system-
atic testing techniques aimed to the database application domain [Chan and Cheung 1999,
Chays et al. 2000, Kapfhammer and Soffa 2003, Zhang et al. 2001].
The motivation for this work is to contribute to the improvement of the quality
of SQL-based applications. An SQL-based application interacts with the database using
SQL (Structured Query Language), the most used language by database application de-
velopers [Fortier 1999, Elmasri and Navathe 2006]. The use of relational databases has
94
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
increased in applications that manipulate persistent data and, in this context, SQL is the
most widely accepted and adopted in relational database systems [Daou et al. 2001].
Active database systems monitor specific events and, as they occur, trigger appro-
priate responses at the appropriate time. When the triggering of events occurs, a condition
is evaluated against the database state, and an action is activated if its true. From the appli-
cation’s point of view, part of its functionality is expressed as rules, such that the control
and data flows are transferred from the application to the active rules during execution. An
application domain overview of active database systems and their implementation aspects
are found in [Ceri et al. 2000, Ceri and Widom 1996].
The question associated to this research is the lack of testing techniques in the
context of active rules written in SQL. This motivates new testing techniques based on the
use of SQL, aiming to reveal faults not yet discovered.
Testing criteria for active rules written in SQL were proposed and analyzed in the
context of data flow based structural testing [Leitao-Junior et al. 2008]. The criteria are
an extension to the All-Uses criterion [Rapps and Weyuker 1985], and exploits persistent
data flow relations associated to rule interaction. We carried out an empirical investiga-
tion aiming to evaluate the applicability of different data flow analysis precisions and to
compare their fault detecting ability.
Section 2 deals with active rules written in SQL. Persistent data flow is discussed
in Section 3. Section 4 introduces persistent data flow analysis precision. An empirical
analysis is exploited in Section 5. Section 6 deals with related work. Section 7 concludes
with directions for future work.
The notation ri (ei , ci , ai ) indicates that the rule ri is described by event ei , condi-
tion ci and action ai . In the control flow context, similarly to conventional programs, a
rule r is represented by a directed-graph, given by G(r) = (N, B, e, x), where: N is the
set of nodes in the rule; B is the set of branches; the entrance and exit nodes are, respec-
tively, e and x; the entrance node is also called event node. Figure 2(b) shows the control
flow graph of the SQL active rule in Figure 2(a); dashed edges represent exceptions due
to the execution of SQL manipulation commands.
1
2
CREATE TRIGGER Reorder
AFTER UPDATE OF PartOnHand ON Inventory
WHEN (:New.PartOnHand < :New.ReorderPoint)
3
FOR EACH ROW
DECLARE NUMBER X;
BEGIN
SELECT COUNT(*) INTO X 4
FROM PendingOrders
WHERE Part = :New.Part;
IF X = 0 THEN 5
INSERT INTO PendingOrders
VALUES (:New.Part, :New.OrderQuantity, SYSDATE);
END IF;
END; 6
(a) (b)
Figure 2. Example of an active rule in SQL: (a) source code (b) control flow graph.
persistent definition. The persistent use may affect the control flow, due to the occurrence
of exception conditions. Persistent uses occur in the output edges of SQL nodes, due to
the potential exceptions. The duse notation represents the persistent data use: duse(i,j)=-
{variable v — v is a database variable used in the edge (i,j)}. The use of a persistent
variable is a persistent use.
A persistent data flow association, persistent association, ddef-duse-association,
or simply ddua, is a triple [i, (j, k), v], such that: v ∈ ddef (i); v ∈ duse(j, k); and
there is a definition-free path with respect to (w.r.t.) v from i to (j, k). Alternatively, if
ddu(v,i)={edges (j,k) — v ∈ ddef(i), v ∈ duse(j,k) and there is a definition-free path w.r.t.
v from i to (j,k)}, a persistent association is represented by the triple [i, (j, k), v], such that
(j, k) ∈ ddu(v, i).
definition and use occurrences are statically determined. The latter is the level of greater
dataflow analysis precision and represents a composition of tuple and attribute, and is also
not decidable by static analysis.
The coverage of persistent data flow association is affected by the granularity of
the data flow analysis. The coverage of a ddua at the β granularity is reached when
the intersection of sets ddef and duse established at level β is not null and at least one
definition free path with respect to the persistent variable is executed.
Therefore, in the context of persistent data flow based testing, testing requirements
are pairs <criterion, granularity> which coverage analysis consider exercised paths and
manipulated persistent data along these paths. The pair <criterion, granularity> estab-
lished a new testing requirement, since it requires the analysis of the input domains that
are appropriate to the coverage of a particular criterion on each granularity level. To
reach coverage at more precise granularity levels implies a greater effort during the test-
ing activities, since the input domain is reduced. Moreover, it is in general not possible to
statically determine if a particular <criterion, granularity> will be covered by the test.
5. Empirical Analysis
The experiment investigated the applicability of testing requirement <criterion,
granularity>, and preliminarily analyze its fault-revealing effectiveness at different data
flow analysis precisions.
The coverage of pair <criterion, granularity> demands dynamic analysis of per-
sistent data along exercised paths, since in general the static determination of defined and
used database entities due to manipulation command execution is an open question. The
effectiveness of coverage criteria depends not only on the selected paths but also on the
test data for those paths [Clarke et al. 1989].
Consider that the application of a test case set produces the tuple < Π, Γ > such
that: Π is the resulting path set, Π = {π1 , · · · , π1 }, p > 0; and Γ is persistent data defined
and used along each path of Π; Γ = {γ1 , · · · , γp }, such that γk ∈ Γ is persistent data
defined and used along path πk ∈ Π.
We will consider a testing requirement effective if the application of an adequate
test data is capable of revealing at least half of the software faults in the subject programs.
In addition, we consider a testing requirement to be applicable if the number of test cases
required in a real application is substantially less than that expected by their theoretical
complexity, so that the use of the criteria is possible in a practical manner.
those test cases in which tuple were the highest granularity obtained at all interaction
associations covered by them. Raised exceptions are exploited in lines (h) to (j). Line
(i) refers to user exceptions – those raised by the programmer using the command raise.
Line (j) refers to persistent manipulation exceptions – those raised due to manipulation
command execution and not handled by the programmer. Line (h) refers to test cases
applied with no exception.
Table 1. Summary of fault and non fault-revealing executed test cases, by granu-
larity and raised exception type.
(I) (II) (III)
Test cases Fault-revealing Non fault-revealing All
(a) Fault not exercised 0 8 8
(b) No coverage 20 2 22
(c) Relation coverage 213 89 302
(d) Tuple coverage 46 20 66
(e) Attribute coverage 81 37 118
(f) Attribute value coverage 64 52 116
(g) all 424 208 632
(h) No exception 281 198 479
(i) User exception 112 10 122
(h) System exception 31 0 31
(j) All 424 208 632
The application of the adequate test data was capable of revealing all of the faults,
and the number of test cases was substantially less than that expected by the theoretical
complexity of each rule set faulty version. To evaluate the applicability of the data flow
analysis, a measure was used, denoted by the number of fault-revealing test cases of
adequate test set, stated by Equation 1.
(I : c) + (I : d) + (I : e) + (I : f )
(1)
(III : c) + (III : d) + (III : e) + (III : f )
Equation 1 was used by all data flow criteria, using any model, deriving adequate
test sets that include at least one fault-revealing test case . The value 0.6711 resulted from
the expression above, denoting that 2/3 of the adequate test sets are fault-revealing. Com-
puting the effectiveness per granularity, the values 0.7053, 0.6970, 0.6864, and 0.5517
were obtained for granularities relation, attribute, tuple, and attribute value, respectively,
showing that the effectiveness reaches higher values for the lower data flow analysis pre-
cision.
The coverage at higher granularities does not improve the fault detection ability.
The coverage at granularity relation was enough to reveal the presence of all faults. In
some versions of Rx , the coverage at granularities tuple and attribute value was non fault-
revealing. Two scenarios were observed: i) two state changing commands characterize
the interaction association, such as update-update, so that the execution of the second one
fix the error due to execution of the first one; and ii) the triggering between rules leads to
failure elimination due to the sequential execution of state changing commands.
100
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
The raised exceptions were traced in order to help the oracle role. From fault-
revealing test cases, 33.7% (143 out of 424) raised exceptions, the majority resulted from
raise command executions. Note that user exceptions implement behavior according to
the software specification and they should be used to decide on the presence of faults. The
instrumentation of exception situations required special mechanisms, since exception oc-
currences usually can cause the loss of database transactions, eliminating the instrumen-
tation data.
The demonstrated effectiveness is an initial empirical evidence. Additional stud-
ies are required since several factors are involved in the investigation, such as, test data
generation strategy, active rules used in the experiment, and fault types and active rules
selected faults.
6. Related Work
In the active rule context, Vaduva [Vaduva 1999] establishes an approach based on rules
sequences, independently of the existence of triggering between rules, in order to reveal
inadequate rule interactions or improper sequences of rule execution. That work is based
on SAMOS, an object oriented database system. The goal of each test case is the ex-
ecution of a specific rule sequence from a rule set. SQL is not used and the structural
elements of the rules, such as control and data flow, are not considered in the coverage of
a particular sequence.
Kapfhammer and Soffa [Kapfhammer and Soffa 2003] define testing criteria
based on data flow analysis for database applications exploiting several granularity levels.
The list of data flow associations is dependent on the database initial state: the size of the
database determines the number of required elements, since associations are defined for
each possible element of the database. The results of their empirical investigation indicate
that the number of required elements varies with the precision of the data flow analysis.
The authors based their empirical investigation on a couple of Java programs accessing
a MySQL database. There is a tendency for a high number of required elements when
101
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
tuple and attribute value granularities are used, even with a reduced database. The work
does not investigate the fault-revealing aspect of the proposed criteria.
Additional work concentrate on the generation of testing
databases [Chays et al. 2000, Daou et al. 2001, Davies et al. 2000, Zhang et al. 2001]
and on the definition of approaches to test database applications [Chan and Cheung 1999,
Suárez-Cabal and Tuya 2004].
7. Conclusions
This work investigates the applicability of persistent data flow strategies in testing of
active rules written in SQL, representing a valuable resource to the quality assurance ac-
tivities related to the development of active database applications. A family of adequacy
criteria was used, called Interaction Between Rules based Criteria, to promotes the use
of a systematic approach to testing and eventually contributes to the dissemination of the
use of active rules databases.
The results of the empirical investigation, supported by the tool ADAPT-TOOL,
show that the criteria are capable of revealing faults in manipulation commands, in addi-
tion to their applicability at several granularities. The effectiveness was 2/3 of adequate
data set, and reached higher values for the lower data flow analysis precision. The cover-
age of interaction associations at higher granularities does not improve the fault detecting
ability; fault-revealing and non fault-revealing scenarios were identified at every granu-
larity level.
The realization of new empirical studies is desirable, since several factors are in-
volved in the results of the study, such as: data flow generation techniques; set of active
rules utilized; test data generated; faults and types of faults seeded in the active rules.
Additional sets of active rules could be used to include samples of real rules to reduce
threats to the study’s validity.
References
Baralis, E., Ceri, S., and Paraboschi, S. (1998). Compile-Time and Runtime Analy-
sis of Active Behaviors. IEEE Transactions on Knowledge and Data Engineering,
10(3):353–370.
Ceri, S., Cochrane, R., and Widom, J. (2000). Practical Applications of Triggers and
Constraints: Success and Lingering Issues. In Proc. of the 26th Very Large Database
(VLDB) Conference, pages 254–262, Cairo, Egypt.
Ceri, S. and Widom, J. (1996). Applications of Active Databases. In Widom, J. and
Ceri, S., editors, Active Database Systems: Triggers and Rules for Advanced Database
Processing, pages 259–291. Morgan Kaufmann Publishers.
Chan, M. and Cheung, S. (1999). Testing Database Applications with SQL Semantics. In
Proc. of the 2nd Intl. Symp. on Cooperative Database Systems for Advanced Applica-
tions (CODAS’99), pages 364–375.
Chays, D., Dan, S., Frankl, P. G., Vokolos, F. I., and Weyuker, E. J. (2000). A Frame-
work for Testing Database Applications. In Proc. of the 2000 ACM SIGSOFT Intl.
Symposium on Software Testing and Analysis, pages 147–157, Portland, Oregon.
102
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
Clarke, L. A., Podgurski, A., Richardson, D. J., and Zeil, S. J. (1989). A Formal Evalua-
tion of Data Flow Path Selection Criteria. IEEE Transactions on Software Engineering,
15(11):1318–1332.
Daou, B., Haraty, R. A., and Mansour, N. (2001). Regression Testing of Database Ap-
plications. In Proc. of the 2001 ACM Symposium on Applied Computing, Las Vegas,
Nevada.
Davies, R. A., Beynon, R. J. A., and Jones, B. F. (2000). Automating the Testing of
Databases. In Proc. of the 1st Intl. Workshop on Automated Program Analysis, Testing
and Verification.
Elmasri, R. and Navathe, S. (2006). Fundamentals of Database Systems. Addison Wesley,
Boston, MA, 5th edition.
Fortier, P. J. (1999). Implementing the SQL Foundation Standard. McGraw-Hill.
Kapfhammer, G. M. and Soffa, M. L. (2003). A Family of Test Adequacy Criteria for
Database-Driven Applications. In European Software Engineering Conference and
ACM SIGSOFT Symposium on the Foundations of Software Engineering, ESEC/FSE
2003, Helsinki, Finland.
Kulkarni, K., Mattos, N., and Cochrane, R. (1998). Active Database Features In SQL3.
In Paton, N. W., editor, Active Rules in Database Systems, pages 197–219. Springer-
Verlag.
Leitao-Junior, P. S., Vilela, P. R. S., and Jino, M. (2005). Mapping Faults to Failures in
SQL Manipulation Commands. In Proc. of the 3rd 3 ACS/IEEE International Confer-
ence on Computer Systems and Applications (AICCSA-05), Egypt, Cairo.
Leitao-Junior, P. S., Vilela, P. R. S., and Jino, M. (2008). Data Flow Testing of SQL-
based Active Database Applications. In Proc. of the 3rd International Conference on
Software Engineering Advances (ICSEA-08), Sliema, Malta.
Ostrand, T. J. and Balcer, M. J. (1988). The Category-partition Method for Specifying
and Generating Functional Testing. Communications of the ACM, 31(6):676–686.
Rapps, S. and Weyuker, E. (1985). Selecting software test data using data flow informa-
tion. IEEE Trans. Soft. Eng., SE-11(4).
Suárez-Cabal, M. J. and Tuya, J. (2004). Using a SQL Coverage Measurement for Testing
Database Applications. In Proc. of the 12th Intl. Symp. on the Foundations of Software
Engineering, Newport Beach, California.
Vaduva, A. (1999). Rule Development for Active Database Systems. PhD thesis, Univer-
sity of Zurich.
Zhang, J., Xu, C., and Cheung, S. (2001). Automatic Generation of Database Instances
for White-box Testing. In Proc. of the 25th Annual International Computer Software
and Applications Conference (COMPSAC’01), Chicago, Illinois.
103
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
1. Introdução
Anomalias de design são resultados das más escolhas e têm o efeito potencial de
degradar a qualidade do design e, conseqüentemente, tendem a impactar a qualidade do
software. Alguns pesquisadores propuseram mecanismos baseados em métricas de
código fonte para capturar desvios dos princípios de bom design orientado a objetos
[Munro, 2005; Lanza & Marinescu, 2006]. Marinescu & Lanza chamam esse
mecanismo de estratégias de detecção. Uma estratégia de detecção é uma condição
lógica, composta por métricas, que detecta candidatos de elementos do projeto com
anomalias específicas. Tais estratégias, embora possam gerar um número considerável
de falsos positivos, aliviam o problema do projetista ter que exaustivamente inferir
anomalias a partir de uma extensa inspeção do conjunto de valores “anormais” de
métricas.
A maioria dos trabalhos existentes propõe ou estuda estratégias de detecção com
base exclusivamente em informações do código fonte. No entanto, a detecção a partir do
código fonte é indesejável, uma vez que leva a um considerável volume de retrabalho
inútil que poderia ser evitado caso as medições fossem realizadas nos projetos, ainda
104
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
Shotgun Surgery. Este problema de design corresponde a classes nas quais uma
modificação, implica pequenas modificações em muitas outras classes [Fowler et al.,
1999]. Quando as modificações estão espalhadas, elas são difíceis de encontrar e, por
isso, é muito provável esquecer uma modificação importante. Isto acarreta, portanto, um
impacto negativo na manutenibilidade dos sistemas já que as mudanças não estão
agrupadas. As classes que possuem esta anomalia de design normalmente apresentam as
seguintes características: (i) seus métodos são muito utilizados por outras classes, e (ii)
elas têm muitas outras classes como clientes, ou seja, têm um acoplamento elevado.
Com base nessas características, a estratégia para a detecção de classes com essa
anomalia é definida da seguinte forma [Lanza & Marinescu, 2006]:
Shotgun Surgery = (CC > 5) and (CM > 10),
105
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
em que: (i) a métrica CM (Changing Methods) conta o número de métodos que podem
ser potencialmente afetados por mudanças na classe avaliada, e CC (Changing Class)
conta o número de classes que deverão ser inspecionadas se ocorrerem mudanças na
classe avaliada. Os detalhes de implementação e as referências originais dessas métricas
podem ser encontrados em [Lanza & Marinescu, 2006].
God Package. Este problema de design refere-se a pacotes que tendem a ser muito
grandes e possuir classes que não interdependem, ou seja, classes com baixa coesão
entre elas. Além disso, segundo Lanza & Marinescu (2006), outro sintoma desta
anomalia são pacotes que possuem muitos clientes. A estratégia para detecção de God
Package é definida da seguinte forma:
God Package = (PS > 20) and (NOCC > 20) and
(NOCP > 3) and (PC < 0,33),
em que: (i) a métrica PS (Package Size) conta o número de classes que estão definidas
no pacote avaliado. A métrica NOCC (Number Of Client Classes) representa o número
de classes definidas em outros pacotes e que usam o pacote avaliado. Uma classe utiliza
um pacote se ela realiza chamadas a métodos, acessa a variáveis ou herda de alguma
classe definida nesse pacote. A métrica NOCP (Number Of Client Packages) conta o
número de pacotes que utilizam o pacote avaliado. Um pacote A utiliza outro pacote B
se ao menos uma das classes definidas em A usa alguma classe do pacote B. A métrica
PC (Package Cohesion) é definida como o número relativo de pares de classes que
dependem entre si. Os detalhes de implementação e as referências originais dessas
métricas podem ser encontrados em [Lanza & Marinescu, 2006].
Misplaced Class. Este problema de design faz referência às classes em que é baixo o
grau de interdependência com as demais classes definidas em um dado pacote, além de
dependerem muito de classes definidas em outros pacotes. Uma classe que utiliza
principalmente as funcionalidades definidas em pacotes diferentes do seu, deveria
provavelmente ser movida para outro pacote. Baseado nas características prováveis de
estas classes a estratégia de detecção para código foi definida da seguinte forma [Lanza
& Marinescu, 2006]:
Misplaced Class = (NOED > 6) and (CL < 0,33) and (DD > 3),
106
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
4. Estudo Experimental
O objetivo do estudo experimental é avaliar a acurácia, a precisão e o recall das
estratégias aqui propostas na identificação das mesmas entidades com anomalias que as
estratégias correspondentes para código. Estas medidas foram escolhidas por elas serem
normalmente utilizadas para avaliar a eficácia de um sistema de recuperação de
informação. Nesse contexto, elas são definidas da seguinte forma: acurácia representa o
grau de veracidade dos resultados; precisão corresponde à relevância dos resultados
obtidos de acordo à consulta realizada, e recall representa a habilidade para a
recuperação dos resultados relevantes de acordo à consulta realizada (Baeza & Ribeiro,
1999). O estudo se baseou na estrutura proposta por Wholin et al (2000).
4.2. Planejamento
108
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
[Macia et al., 2008] uma ferramenta para a aplicação das estratégias de detecção em
diagramas de classes (S5) e as versões 5.2 (S6), 6.0 (S7), 7.0 (S8) e 7.1 (S9) do sistema
open source JHotdraw [JHotdraw, 2008]. Os modelos dos primeiros cinco sistemas
foram gerados como parte do processo de desenvolvimento como trabalho da matéria
Projeto Projeto de Sistemas de Software do programa de pós-graduação em informática
da PUC-Rio. Esta disciplina avalia a correspondência dos diagramas UML com o
código implementado. Os modelos escolhidos apresentaram bons resultados e alta
coerência com o código fonte. No entanto, os diagramas de classes das diferentes
versões do sistema JHotdraw foram gerados mediante engenharia reversa apoiada pela
ferramenta Enterprise Architecture [EA, 2008]. As características desses sistemas são
resumidas na Tabela 1. A realização do estudo envolveu apenas um estudante de pos-
graduação na área de engenharia de software da PUC-Rio.
Tabela 1 - Características dos sistemas utilizados no estudo
Sistema Num. Pacotes Num. Classes Num. Métodos Num. Atributos
S1 12 61 513 142
S2 38 102 529 218
S3 27 110 898 194
S4 18 96 459 248
S5 16 150 679 459
S6 17 172 1.438 363
S7 16 332 3.117 361
S8 21 313 3.251 735
S9 25 401 3.986 1.198
4.3. Execução
Devido a que utilizamos os sistemas envolvidos no estudo apresentado em [Macia et al.,
2008] não tivemos que nos preocupar por uma fase de preparação. Sendo assim, a
execução deste estudo pode ser resumida nos seguintes passos: (i) aplicação das
estratégias de detecção nos diagramas de classes, usando uma extensão de nossa
ferramenta QCDTool, (ii) aplicação das estratégias de detecção no código, utilizando a
ferramenta Together (2008), e (iii) análise dos resultados. Escolhemos utilizar Together
pelo fato de automatizar muitas das estratégias de detecção para código propostas em
[Lanza & Marinescu, 2006], incluindo as adaptadas neste trabalho.
Tabela 2 – Valores Limites utilizados.
Shotgun Surgery God Package Misplacd Class
Métrica Valor Limite Métrica Valor Limite Métrica Valor Limite
CM + CA 10 PS 20 NOED 5
NOCC 18 CL 0,33
CC 5
NOCP 3
DD 3
PC 0,33
Os valores limites foram usados nas estratégias para modelos com base nos
valores limites das estratégias correspondentes para código. Sendo assim, utilizamos
mesmos valores para: (i) as métricas cuja informação necessária para seu cálculo está
disponível no modelo em nível de detalhe semelhante ao do código, (ii) valores padrões
utilizados, por exemplo, um terço, e (iii) valores absolutos muito pequenos tais como 3
e 5. Valores limites menores foram usados para as métricas cuja informação necessária
para seu cálculo está disponível no modelo em menor detalhe que no código. Os valores
limites associados a cada uma das métricas são apresentados na Tabela 2. Extrapola os
109
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
objetivos deste trabalho realizar os estudos empíricos necessários para ajustar os valores
utilizados.
Sistemas Acurácia Precisão Recall Acurácia Precisão Recall Acurácia Precisão Recall
110
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
como parte do processo de desenvolvimento. Com isto podemos dizer que é difícil
alcançar boa precisão na identificação dessa anomalia no modelo, uma vez que ela
depende muito de informações disponíveis apenas no código fonte.
A estratégia de detecção God Package apresentou a melhor precisão para todas
as estratégias analisadas (100% para todos os sistemas avaliados). Isto significa que
todos os pacotes classificados como instâncias God Package no modelo foram também
detectados no código. Isso permite aos usuários antecipar a correção desta anomalia de
design já desde a etapa de modelagem. Porém, não todas as entidades identificadas no
código foram identificadas também no modelo o que motivou baixos valores de recall,
para alguns dos sistemas, por exemplo, sistemas S5 e S8 (Error! Reference source not
found.3). Por fim, o alto grau de acurácia dessa estratégia indicou que ela classifica as
entidades de maneira semelhante a sua correspondente para código.
Finalmente, a estratégia de detecção Misplaced Class apresentou apenas um caso
de falso positivo para os sistemas S1 e S7. Porém, devido ao baixo número de entidades
identificadas como esta anomalia, no modelo e no código, os casos de falsos positivos
encontrados tiveram alto impacto no cálculo da precisão (sistemas S1 e S7 Error!
Reference source not found.3). Por outro lado, algumas das entidades identificadas
com anomalias no modelo não foram identificadas como tal no código. Isso pode
acarretar que essas entidades sejam tratadas como instâncias dessa anomalia no modelo
sem realmente serem e, portanto, contribuem para baixos valores de recall (sistema S7
Error! Reference source not found.3).
4.5. Validação da análise
O único aspecto que ameaça a validade de conclusão de nosso estudo é o tamanho da
amostra, que é pequeno para o tipo de estudo realizado. Estamos cientes disso e,
portanto, consideramos os resultados apenas como preliminares. As ameaças à validade
de construção são mínimas porque a computação das estratégias de detecção tanto para
modelos como para código foi totalmente automatizada. A principal ameaça à validade
interna do estudo está relacionada ao grau de correspondência entre os diagramas e
código. Porém, os diagramas dos sistemas S1 a S5 foram gerados pelos próprios
desenvolvedores como parte do processo de desenvolvimento e os diagramas dos
restantes sistemas foram gerados mediante engenharia reversa automatizada.
Consideramos que o fato de apenas um estudante de pós-graduação ter conduzido o
estudo não constitui uma ameaça principal já que a condução do estudo foi totalmente
automatizada. A principal ameaça à validade externa do nosso estudo é natureza dos
sistemas analisados. Para minimizar essa ameaça procuramos usar sistemas de tamanho
diferentes e desenvolvidos por pessoas e ambientes (academia e open-source) distintos.
Porém estamos cientes que mais estudos experimentais evolvendo sistemas comerciais
devem ser realizados no futuro.
5. Discussão
As diferenças entre os resultados das duas estratégias de detecção Shotgun
Surgery, ocorreram porque as métricas da versão para modelo foram adaptadas de forma
a usar menos informações que as correspondentes da versão para código. Por exemplo,
uma das cláusulas dessa estratégia diz que, para ser uma Shotgun Surgery, uma classe
tem que ter CM > 10 (Seção 2). A métrica CM conta o número de métodos que podem
111
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
ser potencialmente afetados por mudanças realizadas na classe avaliada. Essa métrica
considera que um método é potencialmente afetado sempre que em seu escopo sejam
realizadas chamadas a alguns dos métodos definidos na classe avaliada. No entanto,
como no modelo não há informações para determinar as chamadas a métodos da classe
avaliada, na métrica CMadpt foram utilizadas as referências a essa classe feitas através de
atributos e parâmetros. Por causa disso, algumas referências à classe avaliada foram
consideradas no modelo, mas não o foram no código por elas não realizarem chamadas a
métodos dessa classe. Isso fez com que algumas classes tiveram valor maior para CMadpt
no modelo, e conseqüentemente, fossem classificadas como Shotgun Surgery no modelo
e não no código.
Os resultados da estratégia de detecção God Package também foram afetados
pelas adaptações realizadas às métricas. Por exemplo, uma das cláusulas dessa estratégia
diz que, para ser um God Package, um pacote tem que ter NOCC > 20. A métrica
NOCC, definida no contexto de código fonte, conta o número de classes clientes em
outros pacotes que um pacote possui. Dentre outras coisas, essa métrica utiliza os
acessos a informações de outras classes para determinar a quantidade de clientes que um
pacote possui. Estes acessos são determinados por declarações de variáveis, chamadas a
métodos e acessos a atributos de outras classes. No entanto, como no modelo não há
informações para detectar estes acessos, as classes clientes foram detectadas utilizando
apenas as referências realizadas nas declarações de atributos e parâmetros, além de
associações, herança e dependências entre classes (NOCCadpt , NOCPadpt e PCadpt Seção
3.2). Por causa disto, algumas classes foram identificadas como clientes no código, mas
não o foram no modelo. Isso fez com que alguns pacotes tivessem maior número de
classes clientes no código, e conseqüentemente, fossem classificados como God
Package no código e não no modelo.
Situações semelhantes aconteceram na estratégia de detecção Misplaced Class.
Nesta estratégia, duas de suas cláusulas dizem que, para ser uma Misplaced Class uma
classe tem que ter NOEDadpt > 6 e DDadpt > 3 (Seção 3.2). Essas métricas correspondem
adaptações para modelo de métricas que contam o número de pacotes e classes que uma
determinada classe acessa (Seção 2). A ausência de informação no modelo para
determinar esses acessos acarretou que essas métricas apresentaram menores valores que
suas correspondentes para código. Isso fez com que algumas classes fossem
classificadas como Misplaced Class no código e não no modelo, o que contribuiu para
alguns casos de falsos negativos.
para detectar God Package e Misplaced Class no modelo apresetaram bons graus de
acurácia, precisão e recall. Isso indica que essas estratégias podem ser utilizadas para
avaliar modelos de modo a construir software com menos retrabalho inútil e menos
defeitos remanescentes. Pretendemos no futuro realizar esse um estudo mais
aprofundado envolvendo um maior número de sistemas e participantes.
Referências
BAEZA, R.; RIBEIRO, B. Modern Information Retrieval. Addison Wesley Longman,
1999.
BRYKCZYNSKI, B.; MEESON, R.; WHEELER, D.A. Software Inspection:
Eliminating Software Defects; Sixth Annual Software Technology Conference;
1994
EA. Enterprise Architecture. Disponível em <http://www.sparxsystems.com.au/>.
FOWLER, M.; BECK, K.; BRANT, J., OPDYKE, W.; ROBERTS, D. Refactoring:
Improving the Design of Existing Code. Addison-Wesley, 1999.
GENERO, M.; PIATTINI, M.; CALERO, C. Empirical validation of class diagram
metrics. In Proceedings of 2002 International Symposium on Empirical Software
Engineering, Nara, Japan, 2002, pages 195–203.
JHotdraw. Disponível em <http://www.jhotdraw.org/>. Acceso em: maio 2008
LANZA, M.; MARINESCU, R. Object-Oriented Metrics In Practice. Using Software
Metrics to Characterize, Evaluate, and Improve the Design of Object-Oriented
Systems. Berlin, Alemanha: Springer, 2006
MACIA, I.; SANT’ANNA, C.; STAA, A. Detectando Problemas de Design em
Diagramas de Classes: Um Estudo Experimental. V Experimental Software
Engineering Latin American Workshop (ESELAW’2008), 2008.
MetricView 2005. Disponível em: <http://www.win.tue.nl/empanada/metricview/>.
Acesso em: Abril 2008.
MUNRO, M. J. Product Metrics for Automatic Identification of “Bad Smells” Design
Problems in Java Source-Code. IEEE International Conference, 2005.
PRESSMAN, R.S. Software Engineering – A Practitioner’s Approach, 2001.
SAHRAOUI, H.; BOUKADOUM, M.; LOUNIS, H. Building Quality Estimation
models with Fuzzy Threshold Values. L’Objet, 17(4), 2001, pages 535-554.
SAPSOMBOON, B. “Shared Defect Detection : The Effects of Annotations in
Asynchronous Software Inspection,” PhD thesis, University of Pittsburgh, 2002.
SDMetrics. Disponível em: <http://www.sdmetrics.com/> . Acesso em: maio 2008.
WOHLIN, C.; RUNESON, P.; HOST, M.; OHLSON, M.; REGNELL, B.; Wesslen, A.
Experimentation in Software Engineering: An Introduction, Kluwer Academic
Publishers, 2000.
ZHOU, Y.; BAOWEN, X. Measuring structure complexity of UML class diagrams.
Journal of Electronics, China, 20(3), 2003, pages 227-231.
113
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
1. Introdução
Para reduzir os custos da atividade de teste de software, muitas vezes se torna interes-
sante reutilizar conjuntos de (casos de) teste criados anteriormente. Isso ocorre particu-
larmente no caso de programas semanticamente semelhantes (ou equivalentes), ou seja,
programas que implementam a mesma funcionalidade, porém de forma diferente. Em
outras palavras, dado que se tem disponı́vel um conjunto de teste T adequado para o teste
de um programa P , e se quer testar um programa Q semanticamente semelhante a P ,
T pode ser utilizado como ponto de partida para se testar Q. Apesar de tal afirmação
ser intuitiva, é importante verificar na prática o nı́vel de adequação do conjunto de teste
reutilizado, pois isso pode depender diretamente da funcionalidade implementada e da
forma como o conjunto de teste foi gerado (isto é, do tipo de critério de adequação ado-
tado). Este artigo apresenta um estudo experimental sobre esse problema, no contexto da
reutilização de casos de teste criados a partir do critério Análise de Mutantes (AM) para
programas equivalentes que implementam diferentes algoritmos de ordenação. O critério
AM [DeMillo et al. 1978] é considerado custoso, o que torna esse tipo de experimento
importante para a obtenção de indı́cios sobre a viabilidade da reutilização de conjuntos de
teste nesse contexto.
De acordo com o axioma da antiextensionalidade de critérios de teste definido por
Weyuker [Weyuker 1986] tem-se que: dado dois programas P e Q, tal que P é equiva-
lente a Q, um conjunto de teste T adequado a P não é necessariamente adequado a Q. A
mesma autora demonstra teoricamente que essa propriedade se aplica ao critério AM. Isso
114
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
115
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
no fato do critério ser fortemente relacionado com a implementação dos programas e não
com a sua especificação. Ela afirma que “dois programas que realizam a mesma função
de forma diferente terão um conjunto de mutantes diferentes gerados que irão exigir, por-
tanto, um conjunto de casos de testes diferente para distingui-lo do programa original”.
Apesar desse fato, é importante avaliar a cobertura atingida por conjuntos de teste
adequados para um programa P em programas Q semanticamente semelhante. Isso por-
que a cobertura pode não ser de 100%, mas se for estatisticamente semelhante à cobertura
do conjunto adequado no programa de referência, motivar-se-ia sua reutilização.
3.1. Planejamento
Definição: Avaliação na prática do axioma de antiextensionabilidade de Weyu-
ker [Weyuker 1986] em relação ao critério AM. Em outras palavras, avaliar o quanto
um conjunto de casos de teste adequado a um programa de referência é adequado para
testar versões alternativas ou evoluções desse programa.
Contexto: Avaliação de programas no domı́nio de ordenação de vetores, implementados
em C por alunos de graduação em uma disciplina introdutória (Introdução à Ciência da
Computação I) do curso de Engenharia de Computação do ICMC/USP. Definição de um
conjunto de programas de referência, também referentes ao domı́nio de ordenação, imple-
mentados com base na literatura [Ziviani 2005, Cormen et al. 2001]. Esses programas de
referência são implementados e testados (usando a ferramenta Proteum), por dois alunos
de pós-graduação.
Hipóteses: Deseja-se avaliar as seguintes hipóteses:
• Hipótese Nula H1.0: Dados vários programas que implementam algoritmos de
ordenação (ou seja, programas equivalentes) e T um conjunto de casos de teste
adequado a um programa-referência P para o critério AM, T obtém cobertura
semelhante1 quando executado sobre todos os programas.
• Hipótese Alternativa H1.1: Dados vários programas que implementam algorit-
mos de ordenação (ou seja, programas equivalentes) e T um conjunto de casos
de teste adequado a um programa-referência P para o critério AM, T não obtém
cobertura semelhante quando executado sobre todos os programas.
• Hipótese Nula H2.0: Dados vários programas que implementam algoritmos de
ordenação (ou seja, programas equivalentes), T1 um conjunto de casos de teste
adequado a um programa-referência P para o critério AM, e T2 um conjunto
gerado aleatoriamente, T1 e T2 obtêm coberturas semelhantes quando executados
sobre todos os programas.
• Hipótese Alternativa H2.1: Dados vários programas que implementam algorit-
mos de ordenação (ou seja, programas equivalentes), T1 um conjunto de casos
de teste adequado a um programa-referência P para o critério AM, e T2 um
conjunto gerado aleatoriamente, T1 e T2 não obtêm coberturas semelhantes
quando executados sobre todos os programas.
1
Definem-se coberturas semelhantes àquelas que, em média, são estatisticamente semelhantes (ou seja,
não apresentam diferença significativa quando testadas a partir de um nı́vel de confiança de 99%).
117
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
118
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
Pode-se observar que apesar dos programas serem baseados em três métodos di-
ferentes as métricas obtidas foram muito próximas, não havendo diferenças significativas
entre os métodos. Esse resultado já era esperado pois apesar de serem métodos distin-
tos, trata-se de programas semelhantes em relação à forma de ordenar os números. É
interessante comparar a complexidade desses programas com os programas de referência,
pois esses possuem menos semelhanças em relação ao método de ordenação. As métricas
relativas aos programas de referência são apresentados na Tabela 2.
equivalentes (que foi a menor de todas no quick sort). Os resultados mais altos podem ter
ocorrido devido ao fato dos três métodos de ordenação adicionais serem mais complexos
e adotarem estratégias diferentes em relação aos programas anteriores.
Para cada programa de referência foi criado um conjunto de casos de testes ade-
quado à sua implementação. Foi gerado, também, um conjunto de casos de teste aleatório,
independente de qualquer método de ordenação. Cada um desses conjuntos de casos de
testes foi então aplicado aos 22 programas implementados pelos alunos de graduação.
Nas tabelas 3, 4 e 5 podem ser observados o escore de mutação para os métodos bubble,
insertion e selection respectivamente. Nas linhas estão representados os casos de testes
adequados a cada um dos programas de referência e nas colunas os programas implemen-
tados pelos alunos de graduação
Tabela 3. Escore de mutação obtido para o método bubble sort implementados
pelos alunos de graduação
Referência B1 B2 B3 B4 B5 B6 B9 Média
CT bubble 1,000 1,000 1,000 1,000 1,000 0,996 1,000 0,999
CT insertion 1,000 1,000 1,000 1,000 1,000 0,996 1,000 0,999
CT selection 1,000 1,000 1,000 1,000 1,000 0,994 1,000 0,999
CT shell 1,000 1,000 1,000 1,000 1,000 1,000 1,000 1,000
CT merge 0,995 0,995 0,995 0,993 0,995 0,990 0,995 0,994
CT quick 0,995 0,995 0,995 0,993 0,995 0,990 0,995 0,994
CT aleatório 0,961 0,959 0,958 0,968 0,965 0,967 0,967 0,964
De acordo com as tabelas, pode-se observar que os resultados obtidos foram seme-
lhantes entre os três métodos implementados. Além disso, os casos de teste adequados aos
120
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
programas de referência atingiram, em todos os casos, escores maiores do que 0,99 ob-
tendo a média de 0,996. Em contrapartida, o conjunto de casos de teste gerados de forma
aleatória, apesar de também obter um escore de mutação relativamente alto, ficou sempre
abaixo de qualquer um dos outros conjuntos de casos de teste. Ainda em relação aos
resultados, não foi possı́vel identificar, de forma preliminar, uma relação entre o método
utilizado e o escore de mutação obtido, já que os resultados foram muito próximos. Não
parece existir também uma relação com a complexidade do método, visto que não houve
diferenças significativas entre o escore obtido pelos casos de teste adequados aos 3 pri-
meiros algoritmos e aqueles adequados aos algoritmos mais complexos.
Foi verificado também a adequação dos conjuntos de teste de cada programa de
referência para os demais programas de referência. Dessa forma pode-se analisar se o
conjunto de casos de teste adequado a um programa mais simples como o bubble sort
também é adequado a programas mais complexos como shell, merge e quick sort. Os
resultados obtidos podem ser vistos na Tabela 6.
4. Análise e Discussão
Para analisar estatisticamente se os diferentes conjuntos de casos de teste gerados para os
programas de referência obtêm, em média, cobertura alta e semelhante quando executados
sobre todas as implementações de ordenação de vetores, decidiu-se realizar a análise de
variância (analysis of variance, ou ANOVA). A ANOVA oferece um teste estatı́stico que
verifica se as médias de diferentes grupos são iguais, generalizando o teste t de Student
quando se tem mais de dois grupos.
No caso do estudo em questão, aplica-se a ANOVA para verificar as hipóteses
formuladas na Seção 3. Para que o teste seja rigoroso, assume-se o nı́vel de confiança
de 99% (portanto, p-valor = 0,01). A ANOVA é aplicada duas vezes: uma para verificar
se as coberturas obtidas para todos os programas são igualmente altas em média, quando
se permuta os conjuntos de casos de teste de referência; e outra para verificar se, caso a
semelhança seja evidenciada no primeiro caso, o mesmo não ocorre quando se considera
as coberturas atingidas pelos casos de teste aleatórios. O segundo teste é realizado para
verificar o quanto os casos de teste gerados aleatoriamente se aproximam daqueles gera-
dos sistematicamente a partir do critério AM. A ausência de diferença significativa nesse
caso é um indı́cio de que não faz sentido utilizar casos de teste gerados sistematicamente
nesse contexto (principalmente devido ao pequeno porte dos programas analisados).
O primeiro teste estatı́stico evidenciou que não há diferença significativa entre as
coberturas obtidas pelos conjuntos de casos de teste gerados para os programas de re-
ferência, quando executados sobre todos os programas (note-se que também se considera
o conjunto de casos de teste referência aplicado ao próprio programa utilizado para a
geração do conjunto). Como o p-valor foi avaliado em 0,6809 – ou seja, consideravel-
mente maior do que 0,01 – não se obteve evidência suficiente para se rejeitar a hipótese
nula H1.0 de que as médias das coberturas obtidas são semelhantes. Além disso, essas
mesmas médias encontram-se entre 0,99 e 1, ou seja, praticamente 100%. Esse resul-
tado é uma evidência da efetividade de se reutilizar casos de teste gerados para uma dada
implementação de ordenação em outras implementações equivalentes utilizando o critério
AM. Entretanto, quando se considera o conjunto aleatório de casos de teste, a diferença
obtida é significativa. O p-valor nesse caso foi muito menor do que 0,01 (2.2 × 10−16 ),
ou seja, uma forte evidência para se rejeitar a hipótese nula H2.0 de que as médias das
coberturas são semelhantes, quando se considera o conjunto aleatório.
Para se ter uma idéia visual dos resultados, a Figura 1 apresenta o boxplot das
coberturas obtidas por cada conjunto de casos de teste, incluindo o aleatório, executados
em todos os programas (riscos em negrito representam as médias). Note-se que o número
de outliers não é significativo e, além disso, a semelhança entre as coberturas obtidas
pelos casos de teste gerados para os programas de referência é claramente visı́vel nos
valores mais à direita no gráfico. A cobertura é claramente menor para os casos de teste
gerados aleatoriamente, como pode ser visto nos valores mais à esquerda no gráfico (a
média das coberturas se encontra entre 0,96 e 0,97).
5. Conclusões
Neste artigo foi apresentado um estudo sobre a reutilização de conjuntos de teste adequa-
dos para o critério AM em programas equivalentes. O estudo foi realizado no domı́nio de
algoritmos de ordenação. Os resultados obtidos indicam que os conjuntos de teste gerados
para programas de referência obtêm a mesma cobertura, em média (entre 99% e 100%),
quando aplicados aos 22 programas implementados pelos alunos e aos próprios progra-
mas de referência. A análise estatı́stica indicou que não houve diferenças significativas
entre as coberturas obtidas pelos conjuntos de teste. Em contrapartida, o conjunto de ca-
sos de testes aleatórios obteve cobertura significativamente mais baixa, o que indica que
122
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
1.00
0.99
0.98
0.97
cobertura
0.96
0.95
0.94
referência
Referências
Acree, A. T., Budd, T. A., DeMillo, R. A., Lipton, R. J., and Sayward, F. G. (1979). Mutation analysis.
Technical Report GIT-ICS-79/08, Georgia Institute of Technology, Atlanta, GA.
Barbosa, E. F., Vincenzi, A. M. R., and Maldonado, J. C. (1998). Uma contribuição para a determinação de
um conjunto essencial de operadores de mutação no teste de programas C. In XII Simpósio Brasileiro
de Engenharia de Software (SBES 98), pages 103–120, Maringá, PR.
Cormen, T. H., Leiserson, C. E., Rivest, R. L., and Stein, C. (2001). Introduction to Algorithms. MIT Press
and McGraw-Hill.
Delamaro, M. E. (1993). Proteum: Um ambiente de teste baseado na análise de mutantes. Master’s thesis,
ICMC-USP, São Carlos, SP.
DeMillo, R. A., Lipton, R. J., and Sayward, F. G. (1978). Hints on test data selection: Help for the practicing
programmer. IEEE Computer, 11(4):34–43.
Maldonado, J. C., Delamaro, M. E., and Souza, S. R. S. (1995). Análise de mutantes: Uma avaliação
empı́rica do axioma de antiextensionalidade. In Anais do Workshop de Qualidade de Sofware (em con-
junto com o SBES 1995), pages 136–140, Recife.
Maldonado, J. C., Souza, S. R. S., Fabbri, S. C. P. F., Barbosa, E. F., Chaim, M. L., Vincenzi, A. M. R.,
Delamaro, M. E., and Jino, M. (2007). Introdução ao teste de software. chapter Estudos Teóricos e
Experimentais. Campus / Elsevier, 1st edition.
Mathur, A. P. and Wong, W. E. (1993). Evaluation of the cost of alternative mutation strategies. In VII
Simpósio Brasileiro de Engenharia de Software (SBES 93), pages 320–335, Rio de Janeiro, RJ.
McCabe, T. (1976). A complexity measure. IEEE Transactions on Software Engineering, 2(4):308–320.
Offutt, A. J., Rothermel, G., and Zapf, C. (1993). An experimental evaluation of selective mutation. In 15th
International Conference on Software Engineering (ICSE 93), pages 100–107, Baltimore, MD.
Weyuker, E. J. (1986). Axiomatizing software testing data adequacy. IEEE Transactions on Software
Engineering, 12(12):1128–1138.
Wohlin, C., Runeson, P., Host, M., Ohlsson, M. C., Regnell, B., and Wesslén, A. (2000). Experimentation
in software engineering: an introduction. Kluwer Academic Publishers.
Ziviani, N. (2005). Projeto de Algoritmos com Implementações em Pascal e C. Thomson, 2nd. edition.
123
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
1. Introdução
Assim como testes funcionais são importantes para validar a implementação frente aos
requisitos do software, a avaliação de interface é importante para analisar a qualidade de
uso de um software. O conceito geral de qualidade de uso está estreitamente relacionado
à capacidade e facilidade de os usuários atingirem suas metas com eficiência e
satisfação (PRATES et al., 2003). O conceito de qualidade de uso mais amplamente
utilizado é a usabilidade.
124
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
125
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
Perspectivas x Heurísticas
Relacionadas com as perspectivas de:
Heurística Apresentação Conceituação Navegação
Visibilidade do estado do sistema A.1 C.1
Concordância entre o sistema e o mundo real A.2 C.2
Controle e liberdade ao usuário N.3
Consistência e padrões A.4 C.4
Prevenção de erros A.5 N.5
Reconhecer ao invés de lembrar A.6 C.6
Flexibilidade e eficiência de uso A.7 N.7
Projeto minimalista e estético A.8
Reconhecimento, diagnóstico e recuperação de erros A.9 C.9 N.9
Ajuda e documentação A.10 C.10 N.10
126
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
127
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
4. Estudo de viabilidade
4.1. Planejamento do estudo
De acordo com a metodologia proposta por SHULL et al. (2001), o primeiro
estudo que deve ser realizado para a avaliação de uma nova tecnologia é um estudo de
viabilidade, que visa avaliar se a nova tecnologia é viável e se o tempo empregado é
bem utilizado. Para podermos responder a estas perguntas, foi realizada uma inspeção
de usabilidade utilizando-se as técnicas WDP e WDP-RT. Esta inspeção ocorreu em
Junho de 2009, no âmbito da disciplina de Engenharia de Software, do curso de
graduação em Ciência da Computação da Universidade Federal do Amazonas. A Figura
3 apresenta o objetivo deste estudo, de acordo com o paradigma GQM (BASILI e
ROMBACH, 1988).
129
1 – número de discrepâncias, 2 – número de falso-positivos, 3 – número de defeitos
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
30
Defeitos Total
25
20
15
10
5
WDP WDP-RT Each Pair
Student's t
Tecnica 0.05
130
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
Referências Bibliográficas
BLACKMON, M. H., POLSON, P. G., KITAJIMA, M., LEWIS, C., 2002. "Cognitive
walkthrough for the web". In: Proceedings of the SIGCHI conference on Human factors in
computing systems: Changing our world, changing ourselves, v. 5 (1), pp. 463 - 470,
Minneapolis, Minnesota, USA.
BOLCHINI, D., GARZOTTO, F., 2007. "Quality of Web Usability Evaluation Methods: An
Empirical Study on MiLE+". In: International Workshop on Web Usability and Accessibility
(IWWUA) WISE 2007 Workshops, v. LNCS 4832, pp. 481 - 492, Nancy, France.
CARVER, J., JACCHERI, L., MORASCA, S., SHULL, F., 2003. "Issues in Using Students in
Empirical Studies in Software Engineering Education". In: Proceedings of the 9th
International Symposium on Software Metrics (METRICS’03), pp. 239 – 249, Sydney,
Australia.
CONTE, T., MENDES, E., TRAVASSOS, G. H., 2005. "Processos de Desenvolvimento para
Aplicações Web: Uma Revisão Sistemática". In: Proceedings of the 11th Brazilian
Symposium on Multimedia and Web (WebMedia 2005), v. 1, pp. 107 - 116, Poços de
Caldas. November 2005.
CONTE T., MASSOLAR, J., MENDES, E., TRAVASSOS, G., 2007a. “Web Usability
Inspection Technique Based on Design Perspectives”. SBES 2007, João Pessoa, PB, Brasil.
CONTE, T., MASSOLLAR, J., MENDES, E., TRAVASSOS, G. H., 2007b. "Usability
Evaluation Based on Web Design Perspectives". In: Proceedings of the First International
Symposium on Empirical Software Engineering and Measurement (ESEM 2007), Madrid,
Spain. September 2007.
132
ESELAW’09
VI Experimental Software Engineering Latin American Workshop
133