ESELAW 2009 - Departamento de Computação

Transcrição

Proceedings of 6th Experimental Software
Engineering Latin American Workshop
(ESELAW 2009)
November 11-13, 2009
São Carlos, SP - Brazil
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
1. Ciência da Computação. 2. Engenharia de Software.
3. Experimentação em Engenharia de Software. I.UFSCar,
II. ICMC/USP, III. UFG, IIII. Título.
AMS 68NXX
6th Experimental Software Engineering
Latin American Workshop
(ESELAW 2009)
November 11-13, 2009
São Carlos, SP - Brazil
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.
Sandra C. Pinto Ferraz Fabbri
Auri Marcelo Rizzo Vincenzi
Committees
Steering Committee
Sandra C. Pinto Ferraz Fabbri
Guilherme Horta Travassos
José Carlos Maldonado
Márcio Eduardo Delamaro
Manoel G. de Mendonça Neto
(DC-UFSCar, Brazil) -- General Chair
(COPPE/UFRJ, Brazil)
(ICMC-USP, Brazil)
(ICMC-USP, Brazil)
(UFBA, Brazil)
Program Committee
Auri M. R. Vincenzi
Ana M. Moreno
Andreas Jedlitschka
Cleidson Ronald Botelho de Souza
Ellen Francine Barbosa
Emilia Mendes
Fabio Kon
Giovanni Cantone
Guilherme Horta Travassos
Jeffrey Carver
José Carlos Maldonado
Manoel G. de Mendonça Neto
Marcello Visconti
Marcos L. Chaim
Marcio Eduardo Delamaro
Natalia Juristo
Sandro Morasca
(UFG, Brazil) -- Program Chair
(Universidad Politecnica de Madrid, Spain)
(IESE-Fraunhofer, Germany)
(UFPA, Brazil)
(ICMC-USP, Brazil)
(Auckland University, New Zeland)
(IME-USP, Brazil)
(Tor Vergata, Italy)
(COPPE-UFRJ, Brazil)
(University of Alabama, Tuscaloosa, EUA)
(ICMC-USP, Brazil)
(UFBA, Brazil)
(UTFSM, Chile)
(EACH-USP, Brazil)
(ICMC-USP, Brazil)
(Politecnica de Madrid, Spain)
(Università dell´Insubria, Italy)
Support Committee
Daniel de Paula Porto
Deysiane Matos Sande
Elis Cristina Montoro Hernandes
Erika Höhn
Fernanda Aparecida R. da Silva
Guilherme Freire
Lucas Bueno Ruas de Oliveira
(DC-UFSCar, Brazil)
(DC-UFSCar, Brazil)
(DC-UFSCar, Brazil)
(ICMC-USP, Brazil)
(DC-UFSCar, Brazil)
(DC-UFSCar, Brazil)
(ICMC- USP, Brazil)
Organizing Committee
Tutorial and Short Course Coordinator
Márcio Eduardo Delamaro, ICMC-USP, Brazil
Local arrangments Chair
Valter Vieira de Camargo, DC-UFSCAR, Brazil
Publication Chair
Elisa Yumi Nakagawa, ICMC-USP, Brazil
External Reviewers
Adenilso Simao
Alfredo Goldman
André Domingues
Anna Grimán
Arilo Dias Neto
Arlindo da Conceição
Claudia de O. Melo
Debora Paiva
Delano Medeiros Beder
Edmundo Spoto
Edson Moreira
Elisa Yumi Nakagawa
Erika Hohn
Esteban Fernandez Tuesta
Fabiano Cutigi Ferrari
Fabio Lucena
Felipe Besson
Juliano Oliveira
Katia Felizardo
Marcelo Morandini
Marco Silva
Marco Antônio P. Araújo
Maria Istela Cagnin
Martin Solari
Otávio Lemos
Paulo Bernardo
Paulo Sérgio Santos
Pedro Treccani
Plínio Leitão-Júnior
Rafael Prikladnicki
Rogério Eduardo Garcia
Rosana Braga
Rudinei Goularte
Tayana Conte
Valter Camargo
Vinícius Humberto Durelli
Vitor Lopes
Viviane Malheiros
(ICMC - USP, Brazil)
(IME - USP, Brazil)
(Simón Bolívar University, Venezuela)
(COPPE - UFRJ, Brazil)
(DCT - UNIFESP, Brazil)
(IME - USP, Brazil)
(UFMS, Brazil)
(EACH - USP, Brazil)
(UNIVASF, Brazil)
(UFG, Brazil)
(UFG, Brazil)
(USP, Brazil)
(COPPE– UFRJ, Brazil)
(UFMS, Brazil)
(ORT University, Uruguay)
(ICMC-USP, Brazil)
(USP, Brazil)
(UFRJ, Brazil)
(UFPA, Brazil)
(UFG, Brazil)
(PUCRS, Brazil)
(UNESP, Brazil)
(ICMC – USP, Brazil)
(DCC – UFAM, Brazil)
(UFSCar, Brazil)
(COPPE – UFRJ, Brazil)
(SERPRO/USP, Brazil)
Contents
Invited Talk
Measuring and Monitoring Technical Debt (Carolyn Seaman) . . . . . . . . . . .
Free, Libre, Open Source Competence Centers - an opportunity for experimentation (Alfredo Goldman) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
4
5
Short Courses
6
Systematic Review - Scientific Research in Software Engineering (Katia Romero
Felizardo, Rafael Messias Martins and Erika Nina Höhn) . . . . . . . . . . . .
7
Using Qualitative Methods in Empirical Studies of Software Engineering (Carolyn
Seaman) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
Introduction to Experimental Software Engineering (Manoel G. Mendonça) . . . . 9
The Use of Statistical Methods for Planning and Analyzing Experimental Studies
in Software Engineering Area (Guilherme Horta Travassos and Marco Antônio
Pereira Araújo) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Technical Session 1 - Experimentation in Software Engeneering
A Quantitative Assessment on Team Building Criteria for Software Project
Teams (A. César C. França, Évisson Fernandes Lucena, Fabio Q. B. da Silva) .
Apoio na Concepção de Workflow Cientı́fico Abstrato para Estudos in virtuo e
in silico em Engenharia de Software (Wallace M. Pereira, Marco Antônio P.
Araújo, Guilherme H. Travassos) . . . . . . . . . . . . . . . . . . . . . . . .
Estudo da Alocação de Pessoas em Projetos de Software através da Teoria
Fundamentada em Dados (Cinthya S. Oliveira, Cleidson R. B. de Souza, Carla
A. L. Reis) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Experimentação em Engenharia de Software: Glossário de Termos (Vitor Pires
Lopes, Guilherme Horta Travassos) . . . . . . . . . . . . . . . . . . . . . . .
Rastreabilidade Indutiva Aplicada a Artefatos de Software (Raquel Nitsche dos
Santos, Raul Sidnei Wazlawick) . . . . . . . . . . . . . . . . . . . . . . . . .
11
Technical Session 2 - Systematic reviews
A Systematic Review on Software Product Lines Scoping (Marcela Balbino S. de
Moraes, Eduardo Santana de Almeida, Silvio Romero de Lemos Meira) . . . .
Implementação de Variabilidades de Linhas de Produto de Software utilizando
Aspectos: Uma Revisão Sistemática (Antonio Carlos C. Júnior, Thelma Elita
Colanzi, Paulo César Masiero) . . . . . . . . . . . . . . . . . . . . . . . . . .
Uma Abordagem Visual para Auxiliar a Revisão da Seleção de Estudos Primários
na Revisão Sistemática (Katia R. Felizardo, Gabriel F. Andery, José C. Maldonado, Rosane Minghim) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
12
22
32
42
52
63
73
83
Technical Session 3 - Verification, validation and test
93
Granularity on Persistent Data Flow Testing of Active Database Applications
(Plinio S. Leitao Junior, Plinio R. S. Vilela, Mario Jino, Joao C. Silva) . . . . . 94
1
Redução de Potenciais Defeitos através da Detecção de Anomalias em Diagramas de Classes (Isela Macı́a, Arndt von Staa) . . . . . . . . . . . . . . . . . 104
Reutilização de Conjuntos de Teste: Um Estudo no domı́nio de Algoritmos de
Ordenação (Diogo Nascimento Campanha, Simone do Rocio S. Souza, Otávio
Augusto L. Lemos, Ellen Francine Barbosa e José C. Maldonado) . . . . . . . 114
WDP-RT: Uma técnica de leitura para inspeção de usabilidade de aplicações
Web (Marcos Gomes, Davi Viana, Lennon Chaves, Andreza Castro, Verô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.
Dr. Seaman is an Associate Professor at UMBC in Baltimore and a Scientist at the
Fraunhofer Center, Maryland. Her research emphasizes software measurement,
maintenance, communication, and qualitative research methods. She holds degrees in
Computer Science and Mathematics from the University of Maryland, Georgia Tech,
and the College of Wooster (Ohio). She has worked in the software industry as a
software engineer and consultant, and has conducted most of her research in industrial
and governmental settings.
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 recentlyinitiated 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.
Erika Nina Höhn is Graduated in Computer Science at Universidade Federal do
Maranhão (UFMA, 1996), posgraduate in System Analysis and Design at Universidade
Federal do Maranhão (UFMA, 2000) and Masters in Computer Science and
Computational Mathematics at Universidade de São Paulo (USP, 2003). Currently is
PhD student at Universidade de São Paulo. Experience in Computer Science, with
emphasis on Software Engineering, acting on the following subjects: experimentation,
lab packages.
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.
Dr. Seaman is an Associate Professor at UMBC in Baltimore and a Scientist at the
Fraunhofer Center, Maryland. Her research emphasizes software measurement,
maintenance, communication, and qualitative research methods. She holds degrees in
Computer Science and Mathematics from the University of Maryland, Georgia Tech,
and the College of Wooster (Ohio). She has worked in the software industry as a
software engineer and consultant, and has conducted most of her research in industrial
and governmental settings.
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.
Guilherme Horta Travassos is Associate Professor in the Program of Computing and
Systems Engineering at COPPE/UFRJ. He has a MsC and a DSc degree in the
Program of Computing and Systems Engineering from COPPE/UFRJ and a Pos-Doc in
Experimental Software Engineering from University of Maryland – College Park. He
has experience in Experimental Software Engineering and his interests subjects are
scientific methodology applied to software engineering,software development
environments and web engineering.
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
A Quantitative Assessment on Team Building Criteria for
Software Project Teams
A. César C. França1, Évisson Fernandes Lucena1,2, Fabio Q. B. da Silva1
1
Centro de Informática – Universidade Federal de Pernambuco (CIn – UFPE) CEP
50732 - 970 – Recife – PE – Brasil
2
Coordenadoria Ministerial de Tecnologia da Informação – Ministério Público de
Pernambuco (MPPE) Recife – PE – Brasil
[email protected], {efl, fabio}@cin.ufpe.br
Abstract. The study of software projects teams has acquired space in both
industry and academy. However, the criteria identified as relevant to build
teams are still the subject of researches. This article describes a qualitative
research performed with 48 software projects with aim to verify the relation
between eight team building criteria and the success or failure of these
projects. According to the results, the formal use of seven of the team building
criteria can favor project performance, while one of the criteria was refuted.
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
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.
2.1. Team Building Criteria
Lettice and McCracken (2007) show that previous studies related to team management
in software engineering have focused in two important complementary aspects:

The identification of factors which are capable to improve team effectiveness,
team performance, and project success (BRADLEY and HERBER, 1997;
BECKER, BURNS-HOWELL and KYRIAKIDE, 2000; TARRICONE and
LUCA, 2002)

How to blend different types of people together to build effective teams, by
evaluating their psychological profiles (GORLA and LAM, 2004; HIGGS,
PLEWNIA and PLOCH, 2005).
More recently, França and da Silva (2007) contributed with results about the
relationships between individual behavior and the development of technical tasks in
software engineering. França and da Silva (2009a, 2009b, 2009c) studied motivation as
a factor that influences individual and team performance.
These researches have provided significant insights on how to build and manage
software teams from a conceptual point of view. However, França et. al. (2008) found
out that these models are not popular in the software engineering industry.
In this
study, França et. al. (2008) made a qualitative and explorative research aiming to figure
out how project managers build their teams, in practice. Six experienced project
managers, from six different software companies with different organizational maturity
13
ESELAW’09
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.
2.2. A Definition of Software Project Success
Current literature on software project management has several different definitions of
project success; some are overlapping while others are disjoint. For instance, the nature
of the definition of success is very different between traditional approaches (e.g. the
PMBOK® Guide) and agile methods like SCRUM (see Mariz (2009) for an in depth
discussion on this issue).
14
ESELAW’09
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.
3.1. Experimental Unit and Subjects
Using the concepts as defined in Juristo and Moreno (2001), the experimental unit is the
software project and the experimental subjects are the project manager and project team
members.
3.2. Variables and Scales
The independent variables were defined from the set of team building criteria found by
França et. al. (2008). As a starting point, the seven team building criteria were used.
However, during the pre-test phase of the data collection it was found that the criterion
S1 - Project Importance could be interpreted as either the project strategic importance
or the customer importance for the organization. Therefore, it was divided in two
separate criteria: S1 - Project Importance and S2 - Customer Importance. This second
strategic criterion can be described as the importance of some customer for the business,
even when its project does not have substantial importance. Even though S1 and S2 have
strategic impact, they seem to be independent factors from the management perspective.
From the set of criteria two sets of independent variables have been defined: (I)
the level of formal use of each team building criterion in the project; (II) the importance
of each team building criterion in practice. The scale used is ordinal with three values
(Low, Medium, High). The dependent variables were defined from the set of project
success criteria (project goals) defined by Hackman (1990) and Hallows (1998),
presented in Section 2.2. The scale is ordinal with three values ([Goal] Not Satisfied,
Satisfied, Strongly Satisfied). Table 1 and Table 2: Dependent Variables present
independent and dependent variables and possible values.
Table 1: Independent Variables
Variable
Scale Values
Importance level of Ci (i = 1 … 6)
Low – Medium – High
Level of formal use of Ci (i = 1 … 6)
Importance level of Si (i = 1 … 2)
Level of formal use of Si (i = 1 … 2)
15
ESELAW’09
Table 2: Dependent Variables
Variable
Scale Values
Satisfaction of Goal Mi (i = 1 … 6)
Not Satisfied – Satisfied – Strongly Satisfied
3.3. Data Collection Procedure
The field research was performed in nine distinct Brazilian states: Bahia, Ceará, Minas
Gerais, Paraíba, Pernambuco, Paraná, Santa Catarina, São Paulo e Tocantins. The data
collection occurred from 11-01-2008 to 12-01-2008.
An electronic questionnaire was sent by internet to 46 software organizations. It
was possible to achieve a 52% response rate, which correspond to 24 software
organizations. Each surveyed organization supplied the questionnaire with data from
two projects: one that they consider as being successful and another considered as not
successful. Therefore, data form 48 projects were collected.
The surveyed managers had 2 to 18 years of experience in project management.
Every project team had at least three members, including the project manager. The
profile of the software companies is as follows: 16 are micro-business, 16 are smallbusiness, 4 are medium-business and 12 are large organizations1.
3.4.
Data Collection Instruments
A questionnaire was designed to collect data regarding the independent
variables. This questionnaire uses a likert scale structure, with forced choices between
values in the scale. Each variable was evaluated by a single question, totaling 16
questions for the 16 dependent variables. Table 3 shows an example of the questions.
Table 3: Team building criteria assessment instrument
variable: level of formal use of C1
1. How formal was the “Technical Profile” considered in the
team building for this project?
variable: importance level of C1
2. How important is the “Technical Profile” to help achieving the project
success?
Low
Medium
High
( )
( )
( )
( )
( )
( )
To evaluate project success or failure, the questionnaire defined by Haggerty (2000)
was used. The structure is similar to the team building criteria assessment instrument
discussed above. Table 4 shows examples of the questions in the second instrument.
Table 4: Project success measurement instrument
How were the goals listed below satisfied by the project A (successful)?
M1. Costs
M2. Implementation date
…
How were the goals listed below satisfied by the project B (failed)?
M1. Costs
M2. Implementation date
…
Not
Satisfied
( )
( )
Not
Satisfied
( )
( )
Satisfied
( )
( )
Satisfied
( )
( )
Strongly
satisfied
( )
( )
Strongly
satisfied
( )
( )
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
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.
3.5. Data analysis procedure
Based on the taken, it is not possible determine if the behavior of these variable are part
of a normal distribution or not. Also, the variables as described above cannot be
measured accurately, because they are based on the opinion of the project manager.
Therefore, the non-parametric MANN-WHITNEY U test was chosen to calculate
correlation among variables. The software PASW version 16.0 for Windows®
(formerly called SPSS – Statistical Package for the Social Sciences) was used in the
statistic calculation.
The first step was the sample testing. This step consisted on two tests, which
aimed to verify the match between the classification of successful and failed projects
provided by the project managers with the success project goals as established by the
values of the dependent variables This step was carried out to verify consistency
between the manager’s impression about project success and the objective value of de
success criteria. If this test was successful, it would be valid to consider the projects’
success and failure to assess the effectiveness of the used of the team building criteria.
Then, the relationships between the use and importance of team building criteria
and project success was verified by applying the MANN-WHITNEY U test between the
evaluation of the team building criteria in successful projects and in failed projects. In
this case, the test might show if the evaluation of the formal level of each criterion in
successful and failure are significantly different. If so, it is possible to infer that they are
related to the project performance.
The last step consisted on a simple calculation of the arithmetic means of the
evaluation given by the project managers to the importance of each team building
criterion. The ordering was based on greater percentage of “High” scores, then on
smaller percentage of “Low” scores.
4. Results and Data Analysis
4.1. Sample Testing
The Cronbach’s alpha test showed 91.6% of reliability for the analyzed data. Table 5
and Table 6 describe the scores given by the project managers to the satisfaction level of
each project success goal for both the successful and failed projects, respectively.
M1
M2
M3
M4
M5
M6
Achievement Level
Not
Satisfied
Satisfied
4.2%
8.3%
16.7%
4.2%
8.3%
0.0%
4.2%
8.3%
0.0%
12.5%
8.3%
0.0%
Table 6: Evaluation of the success goals
on the failed projects
Strongly
Satisfied
87.5%
79.2%
91.7%
87.5%
87.5%
91.7%
Success Goals
Success Goals
Table 5: Evaluation of the success goals
on the successful projects
M1
M2
M3
M4
M5
M6
Achievement Level
Not
Satisfied
Satisfied
75.0%
4.2%
91.7%
0.0%
50.0%
16.7%
87.5%
8.3%
66.7%
8.3%
58.3%
12.5%
Strongly
Satisfied
20.8%
8.3%
33.3%
4.2%
25.0%
29.2%
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
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
Not satisfied
(n = 24)
Success Goals Achievement level
M1
M2
M3
M4
M5
M6
p=0.000 
p=0.000 
p=0.000 
p=0.000 
p=0.000 
p=0.000 
Costs
Implementation date
Functionality/scope
Effective project team work
User satisfaction
Professional satisfaction on the part of the project manager
Satisfied
(n = 24)
p=0.555
p=0.317
p=0.388
p=1.000
p=0.640
p=0.077
Strongly
Satisfied
(n = 24)
p=0.000 
p=0.000 
p=0.000 
p=0.000 
p=0.000 
p=0.000 
() - Significant differences only for p ≤ 0.05
4.2. Relations existing among Team Building and Project Success
Since the validity of the sample has been verified, the next step was the analysis of the
formalization level of the team building criteria. Table 8 and Table 9 show the
evaluation, with data from the field research. These tables show the percentage of
projects which have been evaluated as Low/Medium/High for all team building criteria.
C1
C2
C3
C4
C5
C6
S1
S2
Formalization level
Low
Medium
0.0%
4.2%
16.7%
16.7%
12.5%
16.7%
25.0%
20.8%
12.5%
16.7%
8.3%
20.8%
12.5%
8.3%
16.7%
8.3%
Table 9: Formalization level of the team
building criteria on failed projects
Team Building Criteria
Table 8: Formalization level of the team
building criteria on successful projects
High
95.8%
66.7%
70.8%
54.2%
70.8%
70.8%
79.2%
75.0%
C1
C2
C3
C4
C5
C6
S1
S2
Formalization level
Low
Medium
29.2%
29.2%
45.8%
16.7%
54.8%
20.8%
45.8%
25.0%
54.2%
20.8%
54.2%
20.8%
41.7%
8.3%
50.0%
0.0%
High
41.7%
37.5%
20.8%
29.2%
25.0%
25.0%
50.0%
50.0%
Therefore, Table 10 shows the result of the MANN-WHITNNEY U test applied
between these two distributions.
Table 10: MANN-WHITNEY U test applied to the formalization level of the team building
criteria on successful and failed projects
Low
(n=24)
p=0,005 
p=0,031 
p=0,001 
p=0,135
p=0,002 
p=0,001 
p=0,024 
p=0,015 
Team building criteria Formalization level
C1
C2
C3
C4
C5
C6
S1
S2
Technical profile
Individual costs
Experience and Productivity
Availability of human resources
Personality
Behavioral skills
Project importance
Customer importance
() - Significant differences only for p ≤ 0.05
18
Medium
(n=24)
p=0,021 
p=1,000
p=0,714
p=0,734
p=0,714
p=1,000
p=1,000
p=0,153
High
(n=24)
p=0,000 
p=0,045 
p=0,001 
p=0,082
p=0,002 
p=0,002 
p=0,037 
p=0,077
ESELAW’09
From this analysis, it is possible to make some conclusions:
•
•
The formalization level of almost all the team building criteria on successful
projects is significantly different from their formalization level on failed
projects, which means that the criteria have a positive relation with the project
performance.
All criteria whose evaluation is “Medium” are not enough to favor project
success because the “Medium” scores tend to have the same behavior in both
successful and failed project, which makes it impossible to draw some
conclusion about them.
The criterion C4 - Availability of Human Resources deserves special attention
in the Table 10, because it tends to appear in failed as often as in successful projects,
unlike all other criteria. Due to this fact, it is possible to infer that C4 does not have any
direct influence in the project performance. This means that if all criteria but C4 are used
in the team building process, the project is more likely to be successful. Also, this
means that if no or only few criteria are used, the project is more likely to be
unsuccessful.
4.3. Relation of Priority Order among the Team Building Criteria
The second relevant result achieved by this research was the relation of priority order
among the team building criteria. This result shows the opinion of the project managers
interviewed about the importance of considering each criterion in a team building
process, looking for increasing the chances of success of a project. The average
evaluation given by the project managers are described in the Table 11 while the Table
12 presents the criteria ordered from the most to the least important.
Table 11: Evaluation of the team building
criteria, according to the Project
managers’ opinions
C1
C2
C3
C4
C5
C6
S1
S2
Importance Level
Low
Medium
4,2%
8,3%
16,7%
8,3%
4,2%
4,2%
25%
16,7%
8,3%
16,7%
4,2%
8,3%
4,2%
4,2%
4,2%
12,5%
Table 12: Importance order of the team
building criteria, according to the Project
managers’ opinions
1.
High
87,5%
75,0%
91,7%
58,3%
75,0%
87,5%
91,7%
83,3%
S1
Project Importance
C3 Experience and Productivity
3.
C1 Technical profile
C6 Behavioral skills
5.
S2
Customer Importance
6.
C5 Personalidade
7.
C2 Personality
8.
C4 Availability of human resources
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
software engineering field still are building their teams based heavily on their own pastexperiences.
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 weakness 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 nonparametric 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
FRANÇA, A. C. C. et. al, (2008). A Qualitative Research on Software Projects Team
Building. In: CONTECSI – 5ª International Conference on Technology and
Information Systems, 2008, São Paulo.
FRANÇA, A. C. C.; da SILVA, F. Q. B. (2007) “Um estudo sobre Relações entre
Papéis Funcionais do RUP e o Comportamento Pessoal no Trabalho em Equipe em
Fábricas de Software”. III Workshop Um Olhar Sociotécnico sobre a Engenharia de
Software – WOSES pp25-36.
______. (2009a). Motivational Strategies for Software Project Team Management: an
exploratory study. V Workshop Um Olhar Sociotécnico sobre a Engenharia de
Software – WOSES. Ouro Preto, MG.
______. (2009b). Desenvolvendo um Programa de Motivação para Engenheiros de
Software através de um Método Experimental. XXIII Simpósio Brasileiro de
Engenharia Software – SBES. Fortaleza, CE.
______. (2009c). An Empirical Study on Software Engineers Motivational Factors. 3rd
International Symposium on Empirical Software Engineering and Measurement –
ESEM’2009, Short Paper Session. Lake Buena Vista, FL.
GORLA, N.; LAM, Y. W. (2004) Who should work with whom? building effective
software project teams. Communications Of The Acm, v. 47, n. 6, 2004.
HAGGERTY, N. (2000) Understanding the link between IT project manager skills and
project success research in progress. IN: Proceedings of the 2000 ACM SIGCPR
conference on Computer personnel research, p.192-195, April 2000, Chicago,
Illinois, United States.
HIGGS, M.; PLEWNIA, U.; PLOCH, J. (2005) Influence of team composition and task
complexity on team performance. Team Performance Management, Emerald Group
Publishing Limited, v. 11, n. 7/8, p.227 – 250, 2005, ISSN1352-7592.
JURISTO, N.; MORENO, A. (2001). Basics of software engineering experimentation,
Kluwer Academic Publishers, ISBN: 978-0-7923-7990-4, 420 p.
LETTICE, F.; McCRACKEN, M. (2007) Team performance management: a review and
look forward. Team Performance Management Vol. 13 No. 5/6, 2007 pp. 148-159.
Emerald Group Publishing Limited 1352-7592.
MARIZ, L. (2009). Um Estudo Experimental sobre a Influência da Composição da
Equipe no Sucesso de Projetos que Utilizam SCRUM (in Portuguese). Master
Dissertation, Center of Informatics, Federal University of Pernambuco.
PMI (2004). Um guia do conjunto de conhecimentos em gerenciamento de projetos
(Guia PMBOK), Project Management Institute, 2004, ISBN 1930699743, 388p.
SOMMERVILLE, Ian. Engenharia de Software (2007). ed 8. Translation: Selma Shin
Shimizu Melkinoff, Reginaldo Arakaki, Edilson de Andrade Barbosa. São Paulo:
Pearson Addison-Wesley, 2007.
TARRICONE, P. and LUCA, J. (2002) “Successful teamwork: A case study”. Higher
Education Research and Development Society of Australasia – HERDSA conference
2002 proceedings pp640-646.
21
ESELAW’09
Apoio na Concepção de Workflow Científico Abstrato para
Estudos in virtuo e in silico em Engenharia de Software
Wallace M. Pereira1, Marco Antônio P. Araújo2, Guilherme H. Travassos1
1
Programa de Engenharia de Sistemas e Computação (PESC), COPPE/UFRJ
Universidade Federal do Rio de Janeiro, Brasil, Caixa Postal 68511 – CEP 21945-970
2
Centro de Ensino Superior de Juiz de Fora / Faculdade Metodista Granbery
{wpereira,ght}@cos.ufrj.br, [email protected]
Abstract. Science evolution has been supported by complex computerized infrastructures with growing interests in simulation based studies based on scientific
workflows. However, the conception of such workflows is not easy and the current
ad-hoc approaches make it a risky process. Therefore, this paper describes the
application of an approach for the conception of scientific workflows for Software
Engineering simulation based large scale studies in software decay.
Resumo. A evolução da ciência tem sido apoiada por infra-estrutura computacional
complexa para realizar as pesquisas, com crescente interesse em estudos baseados
em simulação utilizando tecnologias de workflow científico. Entretanto, a concepção
de workflows não é trivial e as práticas correntes ad-hoc podem trazer riscos ao
estudo. Por isto, este trabalho apresenta a aplicação de uma abordagem de apoio à
concepção de workflow científicos para estudos larga escala baseados em simulação
em Engenharia de Software no domínio da Evolução de Software.
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
em ambientes virtuais, compostos por modelos computacionais. Nos estudos in silico
tanto os participantes quanto o ambiente são simulados, ao contrário dos estudos in
virtuo, onde o ambiente sofre interação dos participantes [Travassos & Barros, 2003].
A utilização de simulação, embora com ênfase recente em Engenharia de
Software, representa prática corrente em outras áreas da ciência como meio de realização de suas pesquisas (e.g., Biologia, Engenharia, Física, dentre outras) [Mattos et al.,
2008]. Estas áreas fazem uso de tecnologias como workflow científico e Sistemas
Gerenciadores de Workflow Científico (SGWfC) para apoiar este tipo de estudo.
Basicamente, o workflow científico é um modelo ou template que representa uma
seqüência de atividades, implementadas por ferramentas (programas ou serviços), a fim
de realizar um determinado objetivo [Deelman et. al., 2009]. Esses workflows são
interpretados e executados pelos SGWfCs. Em geral, os SGWfCs permitem a
especificação, modelagem e execução do workflow científico, representado em uma
linguagem própria, referente a cada um destes sistemas. Os workflows científicos e
SGWfCs trazem benefícios para experimentação como: a possibilidade de registro da
proveniência dos dados utilizados; automação da execução do fluxo de atividades;
controle e invocação das ferramentas que implementam as atividades; manipulação dos
dados passados entre as atividades [Mattos et al., 2008].
Um workflow científico, que representa um estudo baseado em simulação, segue
um conjunto de fases (Composição, Execução, Análise e Proveniência [Oinn et. al.,
2007]) semelhante ao processo de experimentação (Definição, Planejamento, Execução,
Análise e Interpretação, Empacotamento [Wohlin et al., 2000]) para sua instanciação. A
Composição é similar às etapas de Definição e Planejamento no processo de experimentação, sendo uma importante fase, onde o pesquisador estrutura e define o estudo,
em termos da seqüência de atividades necessárias, os tipos de dados de entrada e os produtos esperados. Essa fase, na verdade, é decomposta em duas subfases, a Concepção,
no qual o pesquisador define um novo workflow, e o Reuso, no qual o pesquisador recupera um workflow e o adapta para atender a um novo estudo ou objetivo. Contudo,
muitos autores sugerem que a Composição deve seguir um conceito de criação através
de níveis de abstração [Medeiros et. al., 2005; Gil et. al., 2007], pois, assim, o pesquisador poderia, em momentos diferentes, definir o comportamento (objetivo, atividades e
escopo) do workflow e depois, gradualmente, ir identificando questões de tecnologia
(e.g., local de execução, tipo de chamada de uma ferramenta, dentre outras). Pode-se, de
forma simplificada, definir em dois níveis a abstração do worklfow: concreto e abstrato.
Neste caso, o nível mais abstrato é ligado à definição do comportamento do workflow,
sendo denominado workflow abstrato. Já o nível concreto é ligado aos recursos
computacionais necessários à execução do workflow científico, já pronto para execução
em um SGWfC, sendo denominado workflow concreto [Mattos et al., 2008].
Com o crescente uso de estudos experimentais baseados em simulação na
Engenharia de Software [Zhang et. al., 2008], faz se necessário buscar formas de
auxiliar os pesquisadores em sua realização. Uma possível maneira, como em outras
áreas científicas, é através do uso de tecnologias de workflow científico e SGWfCs,
visto que trazem as vantagens já enumeradas anteriormente, como controle,
proveniência e automação. Porém, apesar desses benefícios, o uso dessas tecnologias
gera novas questões associadas à especificação, modelagem e reutilização deste tipo de
estudo experimental [Mattoso et al., 2008]. Soma-se a isso o fato de estudos do tipo in
23
ESELAW’09
virtuo e in silico, naturalmente, já adicionarem complexidade a realização do estudo,
pois requerem maior apoio computacional e infra-estrutura complexa, bem como maior
conhecimento do domínio onde a pesquisa será realizada [Travassos & Barros, 2003].
Isso tudo torna a Concepção não trivial para o pesquisador. Assim, a concepção pode se
tornar uma barreira para a modelagem computacional de estudos baseados em
simulação. De fato, Modelagem Computacional já foi identificado como um dos
desafios para computação [Kavanagh & Hall, 2008; SBC, 2009].
No momento da concepção do workflow científico, o pesquisador enfrenta uma
série de dificuldades para sua realização. De forma geral, essa tarefa é realizada
diretamente no nível concreto e de maneira ad hoc, o que pode acarretar em riscos para
a pesquisa [Gil et. al., 2007; Verdi et al., 2007]. Soma-se a isso a falta de apoio dos
SGWfC’s para documentação mais detalhada do estudo. Estes sistemas, por exemplo,
não permitem a especificação de atividades manuais ou semi-automatizadas, e também
não apóiam a representação de diferentes fluxos de execução ligados ao estudo definido
no mesmo workflow, característica existente nos estudos em Engenharia de Software.
Isso pode acarretar perda do conhecimento, que fica somente disponível com o
pesquisador responsável pelo workflow, tornando-o tácito. Ainda, como não existe um
processo bem definido, a concepção pode não ser realizada organizadamente e, assim, o
conhecimento não ser explorado e documentado de forma sistemática, acarretando
dificuldades para seu posterior reuso por outro pesquisador [Mattoso et. al., 2008].
Em uma revisão tradicional da literatura técnica, não foi possível identificar uma
abordagem de concepção de workflow abstrato para estudos do tipo in virtuo e in silico,
que utilizasse tarefas bem definidas e definisse meios de garantir a qualidade dos
produtos gerados (especificação do workflow abstrato). Por isso, Pereira & Travassos
(2009) propuseram uma abordagem para concepção de workflows científicos abstratos e
conseqüente especificação destes estudos experimentais. Esta abordagem visa oferecer
meios para garantir o aumento da qualidade do produto final e da padronização das
tarefas e produtos gerados.
Este trabalho descreve a aplicação da abordagem de concepção de workflows
abstratos para estudos in virtuo e in silico [Pereira & Travassos, 2009] em Engenharia
de Software através de sua aplicação no domínio da Evolução de Software [Araujo,
2009]. O artigo é organizado da seguinte forma: a Seção 2 apresenta, resumidamente, a
Abordagem de Concepção; a Seção 3 apresenta um exemplo de aplicação no domínio de
Simulação da Evolução; a Seção 4 apresenta as lições aprendidas com a aplicação da
abordagem; a Seção 5 apresenta alguns trabalhos relacionados; a Seção 6 apresenta o
andamento da pesquisa, os trabalhos futuros e a conclusão.
2. Abordagem para Concepção de Workflows Abstratos
A Abordagem para Concepção de Workflows Abstratos, proposta por Pereira &
Travassos (2009), inspira-se nos processos de desenvolvimento de software e explora as
técnicas usualmente utilizadas na Engenharia de Software [Pfleeger, 2004]. Essa
abordagem intenciona auxiliar o pesquisador na concepção de estudos experimentais in
virtuo e in silico, que utilizem a tecnologia de workflow científico, oferecendo
facilidades para garantir a qualidade da especificação. São utilizados modelos e
formulários para representar a especificação do workflow abstrato. Os modelos são
24
ESELAW’09
baseados no diagrama de atividades da UML 2.2 [OMG, 2009], enquanto os formulários
(Atividades, Artefatos e Ferramentas) são compostos por campos que representam os
requisitos do estudo experimental. O responsável pela especificação e modelagem é
denominado modelador, sendo ele um pesquisador ou engenheiro de software. A Figura
1 apresenta a Abordagem de Concepção, maiores detalhes em [Pereira & Travassos,
2009]. De maneira resumida, a seguir é apresentada a Abordagem de Concepção.
Definir
modelo inicial
do workflow
científico
Identificar e
modelar requisitos
do workflow
científico
Inspecionar a
especificação
do workflow
científico
Nova
rodada
de inspeção
Avançar na
concepção
Validar a
especificação
do workflow
científico
Não
validado
Validado
Figura 1. Tarefas da Abordagem para Concepção de Workflows Abstratos
[Pereira & Travassos, 2009].
Inicialmente, realiza-se a tarefa Definir o modelo inicial do workflow científico,
onde o modelador concebe o modelo inicial, construindo uma visão global do estudo
através da discussão com outros pesquisadores. Após esta tarefa, Identificar e modelar
requisitos do workflow científico é executado. Nela, o modelador cria a especificação do
workflow abstrato através de reuniões semi-estruturadas com os pesquisadores. Os
formulários são utilizados como guias nas perguntas da entrevista e o modelo inicial
como base para o modelo de workflow abstrato.
Conforme citado anteriormente, a abordagem também foca na garantia da
qualidade da especificação gerada. Para alcançar esse objetivo, primeiramente é
realizada uma verificação da especificação (Inspecionar a especificação do workflow
científico), através de uma inspeção ad hoc, no qual os inspetores, pesquisadores do
domínio não envolvidos na especificação, verificam todo o documento em busca de
discrepâncias. Os defeitos são categorizados e corrigidos. Já a tarefa de validação,
Validar a especificação do workflow científico, é realizada através de reuniões com
todos os participantes, no qual todo o conteúdo do documento é avaliado, assim
confirmando se os requisitos do estudo experimental foram capturados de maneira a
atender o seu propósito. Essa abordagem vem sendo utilizada no contexto de um
projeto real, Gexp (http://gexp.nacad.ufrj.br), para a especificação de workflows
abstratos no domínio de exploração de petróleo em sistemas alto mar (offshore).
3. Domínio da Simulação de Evolução de Software
A pesquisa sobre Evolução de Software tem como objetivo entender como sistemas
evoluem e modificam-se ao longo do seu ciclo de vida e como isto pode influenciar no
decaimento de sua qualidade. Para isto, podem-se construir modelos de simulação para
ajudar a observar a evolução do software ao longo de sucessivos ciclos de manutenção.
Araújo (2009) apresenta um modelo, baseado nas Leis de Evolução de Software (LSE –
Laws of Software Evolution) [LEHMAN et al. 1998], que permite a observação do processo de decaimento do software ao longo do tempo, através da simulação do comportamento de determinadas características do software. O modelo de Araújo baseia-se em
premissas descritas através de formulações lógicas das LSE. Essas formulações representam as tendências do comportamento de determinadas características de software ao
longo do tempo (e.g., características da fase de codificação: esforço, tamanho, periodici25
ESELAW’09
dade, complexidade, confiabilidade, manutenibilidade,). Entretanto, as premissas não
permitem a observação direta do processo de decaimento da qualidade do software, pois
não representam as influências que uma Lei exerce em outra. Assim, utiliza-se
ferramentas para simular as características do software, através das equações definidas,
que representam as influências entre as LSE e como essas afetam as características. A
Figura 2 apresenta o processo para observação de Evolução de Software [Araújo, 2009].
Engenheiro
de Software
Coleta de
Métricas
Geração
das
Equações
Construção
Planilha
Ferramenta para
Dinâmica de
Sistemas
Simulação
Evolução de
Software
Figura 2. Processo para Observação de Evolução de Software [Araújo, 2009].
Essa Figura 2 e uma descrição textual do processo são a especificação do estudo
experimental apresentado em Araújo (2009). Contudo, a especificação apresentada não
é padronizada, o que pode apresentar problemas. Por exemplo, na representação do
modelo (Figura 2), estão misturados informações como: o perfil do pesquisador
(Engenheiro de Software), a ferramenta utilizada (Ferramenta para Dinâmica de
Sistemas) e as atividades do estudo. Estas informações distintas, sem um padrão de
representação, que explicite qual é o significado de cada um desses no modelo, pode
gerar confusão para um pesquisador que pretende repetir o estudo. Além disso,
informações (e.g., descrição das atividades, insumos e produtos, dentre outras) estão
descritas em formato textual sem um template, provocando o risco do pesquisador ao
documentar esquecer alguma informação, pois, não há um conjunto característico de
informações pré-definidas para cada elemento (Atividade, Ferramenta e Artefato) que
deva sempre ser identificado. Estes exemplos de problemas, possíveis, no uso de uma
especificação não padronizada, ilustram a necessidade do uso de uma abordagem que
permita a identificação e documentação do conhecimento e dos requisitos
(funcionalidades, restrições e objetivos) do estudo experimental a ser realizado. Com
isso, foi aplicada a abordagem descrita na Seção 2, a fim de conceber uma especificação
do estudo, incluindo atividades opcionais e/ou manuais e alternativas de ferramentas que
suportam a execução do processo. Com essa especificação do workflow abstrato, esperase que, posteriormente, seja possível definir e repetir este estudo em um SGWfC.
3.1. Aplicação do processo de concepção
Para representar o estudo in virtuo apresentado, foi criado, primeiramente, o modelo
inicial do estudo (Figura 3), sendo ele um diagrama de atividades em alto nível de
abstração. Foram identificadas, inicialmente, três atividades, retiradas do modelo
(Figura 2) e, durante a modelagem inicial, foi identificada uma nova atividade: 1)
Preparar dados para simulação, na qual as métricas extraídas do processo real de
desenvolvimento são padronizadas, avaliadas e excluídas caso apresentem
comportamento incomum; 2) Gerar as equações para simulação, na qual são criadas as
equações baseadas nas formulações da LSE e que servirão como modelo para simulação
das características do software; 3) Simular a evolução do software, na qual ocorre a
simulação da evolução das características do software para um determinado tempo
definido; 4) Análise do resultado da simulação, na qual o objetivo é gerar uma análise
do resultado da simulação executada. Nesta etapa, também se identificou o papel do
26
ESELAW’09
Engenheiro de Software, cuja responsabilidade é garantir a qualidade dos dados
escolhidos, das equações geradas e análise do resultado da simulação. O modelo inicial
(Figura 3) serviu como insumo para a tarefa de Identificar e modelar do processo de
concepção.
Início Experimento
Preparar dados
para simulação
Simular a
evolução do
software
Gerar as
equações para
simulação
Análise do
resultado da
simulação
Fim Experimento
Figura 3. Modelo Inicial para Simulação da Evolução de Software.
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
Dados reais do
processo de
desenvolvimento
«decisão»
{Base de medidas das
versões é válida e suficiente
para gerar as equações?}
«datastore»
Base de medidas da
organização
Tabela com
versões do
software
«structured»
Preparar dados para
simulação
[SIM]
[NÃO]
«decisão»
{Qual é origem do
problema? Ação a
ser tomada?}
[MODIFICAR
MEDIDAS DO
SOFTWARE]
Análise do
resultado da
simulação
Final_Simulacao_Decaimento
Tabela com
versões do
software
Dados da
simulação da
evolução
Equações para
simulação
[MODIFICAR
EQUAÇÕES
PARA
SIMULAÇÃO]
[NÃO]
«Semi-automatizada»
Análise do resultado da
simulação
«structured»
Gerar as equações para
simulação
Dados da
simulação da
evolução
[SIM]
«structured»
Simular a evolução do
software
«decisão»
{Equações
representam o
modelo dinâmico?}
Equações para
simulação
Figura 4. Workflow abstrato para Simulação da Evolução de Software.
O modelo que representa os fluxos (controle e dados) da atividade Gerar as
equações para simulação pode ser visto na Figura 5. Essa representação por subworkflows permitiu uma melhor organização, pois deixa os modelos mais legíveis para o
pesquisador.
Tabela com
versões do
software
«structured»
Gerar as equações para simulação
Tabela com versões do software
«Semi-automatizada»
Final_Gerar_Equações
Criar equações da
simulação
Versão base
Equações para Equações para
Versão base
simulação
simulação
Tabela com versões do software
Inicio_Gerar_Equações
«Manual»
Definir versão base
da simulação
Figura 5. Sub-workflow para Gerar equações para simulação.
A especificação é composta pelos diagramas de atividades, mas também por um
conjunto de formulários. Estes documentam cada atividade, artefato e ferramenta utilizada no estudo. Os formulários foram preenchidos conforme ocorreram as reuniões, em
conjunto com a concepção dos modelos do workflow abstrato. A Tabela 1 apresenta
alguns campos do formulário da atividade Criar equações da simulação. A Tabela 2
27
ESELAW’09
apresenta o formulário associado ao artefato Equações para simulação, que contém as
equações geradas em Criar equações da simulação. A Tabela 3 apresenta o formulário
da ferramenta Tabela_Excel. O documento de especificação é composto por uma seção
de introdução, descrição dos papéis envolvidos, apresentação dos modelos (diagramas
de atividades) e formulários preenchidos.
Tabela 1. Formulário atividade Criar equações da simulação.
Atividade
Descrição
Criar equações da simulação
As equações combinadas (referentes à formulação lógica pra cada Lei de Evolução de Software) e os
valores base das características são definidos nas equações para simulação, estas serão efetivamente
utilizadas na simulação da evolução do software. Para tal utilizam-se duas técnicas: regressão linear; e,
método de mínimos quadrados.
A aplicação da técnica de regressão linear, apesar da possibilidade de aumento do erro, é condizente
com a análise semi-quantitativo dos dados, pois neste estudo é a tendência do comportamento de uma
variável que deve ser considerado, mais do que seus valores individuais.
A aplicação do método de mínimos quadrados, que é uma técnica de otimização matemática, procura
encontrar o melhor ajustamento para um conjunto de dados, tentando minimizar a soma dos quadrados
das diferenças entre a curva ajustada e os dados, onde essas diferenças são chamadas de resíduos.
Engenheiro de Software
Tipo de Atividade Semi-Automatizada
Papéis
Obrigatoriedade Obrigatória
Pré-condições Nenhuma
Tabela_Excel
Ferramentas
Pós-condições Nenhuma
versão
base
da
Equações para simulação
Produtos
Pré-atividades Definir
simulação
Tabela com versões do software; Versão base
Insumos
Tabela 2. Formulário artefato Dados da simulação da evolução.
Artefato Dados da simulação da evolução
Descrição Este artefato é construído a partir das influências identificadas entre as características de software, considerando
que a periodicidade é uma variável em função do tempo decorrido, e as demais características são calculadas a
partir das funções das outras características que nela influenciam que, por sua vez, são calculadas a partir da
regressão linear dos dados coletados do sistema em observação. Também estão considerados aqui os valores da
versão base e o incremento de tempo (em dias) a ser utilizado no processo de simulação.
Digital.
Utilização Atividade
Entrada/ Obrigatoriedade Formato
Saída
Interna
Origem
Criar equações da simulação Saída
Obrigatória
Tabela_Excel
Ferramenta
Simular evolução
Entrada
Obrigatória
Nenhum
Sinônimos
Tabela 3 – Formulário ferramenta Tabela_Excel.
Ferramenta
Descrição
Tipo de aplicação
Versão
Sistema Operacional
Tabela_Excel
Tabela no formato “.xls” onde já estão pré-definidos campos para o cálculo da regressão linear e
do método dos mínimos quadrados. São geradas as equações para simulação a partir dos dados das
versões do software e permite a definição dos valores das características do software versão base.
Interface
Formatos Suportados Formato “.xls”.
Não há.
Local
Local de Execução
Windows XP SP3 com Office Excel Forma de disparo
Chamada por interface gráfica.
Figura 6. Planilha para relato de discrepâncias encontradas na inspeção.
Após a tarefa de Identificar e modelar, foi solicitado a um pesquisador, que não
participou da especificação, que inspecionasse e relatasse as discrepâncias em uma
28
ESELAW’09
planilha, como apresentado na Figura 6. Foram encontradas 20 discrepâncias no
documento. Após isso, as discrepâncias foram analisadas para descartar as que não
fossem defeitos reais (falso positivos – 2 no total). Após a correção dos defeitos, o
documento foi validado em conjunto, modelador e dois pesquisadores do domínio
(incluindo o inspetor), sendo realizada a distância por um dos participantes.
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 defeitos 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 representaçã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 somente usar modelos, como em Verdi et. al. (2007), pode acabar por não capturar algumas 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
(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 concebidos, 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 capturar 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 produtos, 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
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: SBCSEMISH´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
Estudo da Alocação de Pessoas em Projetos de Software
através da Teoria Fundamentada em Dados
Cinthya S. Oliveira, Cleidson R. B. de Souza, Carla A. L. Reis
Programa de Pós-Graduação em Ciência da Computação
Instituto de Ciências Exatas e Naturais - Universidade Federal do Pará
{cinthyaseko, cdesouza, clima}@ufpa.br
Abstract. Staffing a software project is a crucial activity on software
development because of its impact on project quality and success. Despite its
importance, current knowledge about how staffing takes place in real life is
limited. This paper presents the results of a qualitative study conducted on a
software development organization where staffing takes place in projects of
different sizes and under various situations. Our goal was to understand how
managers perform staffing in their daily work. Data collection and analysis
was performed using grounded theory. Results include staffing criteria
alongside their importance levels that can be adopted by other organizations,
and, more importantly, highlight the importance of negotiation during the
staffing process, an overlooked aspect of staffing software projects.
Resumo. A alocação de pessoas a um projeto de software é uma atividade de
extrema importância no desenvolvimento de software, pois são as pessoas que
determinam a qualidade e o sucesso de um projeto. O objetivo neste artigo é
apresentar os resultados de um estudo empírico conduzido em uma
organização onde se realizam alocações de pessoas em projetos de diferentes
portes e envolvendo situações distintas. Como resultados são mostrados
critérios para a alocação de pessoas juntamente com os seus níveis de
importância que poderão ser adotados em outras empresas, facilidades para
auxiliar a atividade de alocação de pessoas e a importância da negociação
durante o processo de alocação de pessoas.
1.
Introdução
A atividade de desenvolvimento de software é um esforço coletivo, complexo e criativo,
e a qualidade do produto de software depende fortemente das pessoas, organizações e
procedimentos utilizados para criá-lo [Fuggetta 2000]. Nesse contexto, a alocação de
pessoas a um projeto de software é uma atividade de extrema importância no
desenvolvimento de software, pois são as pessoas que determinam a qualidade e o
sucesso de um projeto [ABNT 2000].
Na norma NBR ISO 10006 [ABNT 2000], no PMBOK [PMI 2004] e no modelo
CMMI [SEI 2002] são citados fatores que devem ser levados em consideração para a
alocação de pessoas a cada atividade de projeto, tais como: conhecimento, habilidade,
disponibilidade, experiência, interesses pessoais e custo. Além de levar em conta as
características individuais de cada membro da equipe, é importante considerar também
fatores que influenciam o desempenho de uma equipe, como [Biffl 2003], [Shetler
1996], [Smith 2001]: habilidade, afinidade entre os membros, tamanho e diversidade de
habilidades da equipe. Outros autores como Acuña (2006), Barreto (2005), França
32
ESELAW’09
(2007) e Fernandes (2007) também propõem abordagens para auxiliar a alocação de
pessoas utilizando diferentes métodos.
Apesar das diferentes recomendações e abordagens na literatura, existem poucos
estudos que explorem como a tarefa de alocação de atividades é realizada no dia-a-dia
por gerentes de projeto de software. Assim, para entender como a alocação de
atividades é feita na prática, foi realizado um estudo empírico em uma empresa
chamada simplesmente de Alpha (para preservar a sua identidade). A Alpha foi
selecionada por: (1) existirem pessoas que realizassem a alocação de recursos em
atividades de desenvolvimento de software; (2) ser uma empresa cujo porte
possibilitasse um estudo de campo envolvendo diversos gerentes de projetos de
software; (3) utilizar um processo de desenvolvimento de software com papéis
definidos; e finalmente, (4) ter uma estrutura de escritório de projetos que estivesse
envolvida na alocação de pessoas. A abordagem utilizada neste trabalho foi uma
abordagem qualitativa baseada em estudos de campo, envolvendo coleta de dados por
meio de entrevistas semi-estruturadas, onde são colocadas questões abertas que
permitem maior interação e novas questões são abordadas de acordo com o
conhecimento de novas informações [DeWalt 2002]. A análise dos dados foi realizada
através da Teoria Fundamentada em Dados [Strauss 2008] que visa originar uma teoria
que explique o que foi observado a partir dos dados. Como resultados serão mostradas
boas práticas e critérios para a alocação de pessoas que poderão ser adotados em outras
empresas e também a importância das negociações que ocorrem durante esta atividade,
um aspecto pouco explorado na literatura. Do ponto de vista metodológico, este artigo
apresenta um exemplo de utilização da teoria fundamentada em dados.
O restante do artigo está organizado da seguinte forma: a seção 2 apresenta o
estado da arte sobre alocação de pessoas. A seção 3 define a metodologia utilizada no
trabalho: a Teoria Fundamentada em Dados. A seção 4 apresenta a caracterização do
estudo empírico. A seção 5 apresenta os resultados, enquanto que a seção 6 apresenta a
discussão dos resultados obtidos no estudo. Finalmente, a seção 7 contém as
considerações finais e os trabalhos futuros.
2.
Alocação de pessoas em projetos de software
A alocação de pessoas em projetos de software envolve a designação de pessoas para as
tarefas do projeto. Além da dificuldade em combinar características requeridas por
atividades e características dos profissionais passíveis de serem alocados, existe pouco
apoio automatizado para a realização da alocação de pessoas.
Na tentativa de minimizar essas dificuldades, várias abordagens têm sido
propostas como, por exemplo, em [Schnaider 2003] é disponibilizado um mapa de
conhecimentos, habilidades, formação acadêmica e experiências dos profissionais da
organização de forma a apoiar a alocação feita pelo gerente. Em [Barreto 2005] a
alocação é tratada como um problema de satisfação de restrições associadas a fatores
como custo, experiência e tamanho da equipe. Em [Acuña 2006] é utilizado um método
baseado em capacidades pessoais requeridas. Em [Silva 2007] é apresentado um
mecanismo baseado em políticas definidas pelo usuário, características das pessoas e
necessidades do processo, produzindo sugestões de alocação. Finalmente, em [França
2007] é realizado um estudo sobre a relação entre habilidades necessárias em papéis
funcionais do Rational Unified Process (RUP) com o comportamento de papéis de time
descrito na Teoria de Papéis de Belbin [Belbin 1981]. Uma abordagem similar é
apresentada em [Fernandes 2007] que faz a correlação entre o comportamento de papéis
33
ESELAW’09
de time descrito na Teoria de Belbin com as competências pessoais definidas no Project
Management Competency Development – PMCD [PMI 2001]. Apesar destas
abordagens, poucos estudos de campo foram realizados para o entendimento do
processo de alocação de pessoas na prática. O objetivo deste estudo é justamente dirimir
esta lacuna na literatura de gerenciamento de projetos.
3.
A Teoria Fundamentada em Dados
A teoria fundamentada em dados (do inglês, grounded theory) [Glaser 1967] visa
originar a partir dos dados coletados, uma teoria que explique o que foi observado
nesses dados. Isto é feito através da criação de categorias e relacionamentos entre as
mesmas e permite extrair informações úteis de dados que a princípio formavam um
grande de volume de dados desestruturados. Dessa forma, a teoria que resulta desta
abordagem se parece mais com a “realidade” do que uma teoria derivada de maneira
diferente, como a partir da reunião de uma série de conceitos baseados em experiência
ou somente por meio de especulação. Teorias fundamentadas, por serem baseadas em
dados, tendem a melhorar o entendimento de um contexto e fornecer um guia
importante para ação [Strauss 2008].
Um aspecto importante da teoria fundamentada em dados é que ela intercala as
fases de coleta e análise / validação dos dados para fornecer um entendimento sobre o
que ocorre na prática e as razões que explicam tais fatos [Seaman 2008]. Portanto,
durante as entrevistas, hipóteses são geradas, testadas e modificadas conforme a análise
dos dados coletados. Para ser mais especifico, as fases da teoria fundamentada em dados
são [Strauss 2008]: (1) Codificação aberta que é um processo analítico por meio do qual
os conceitos são identificados e suas propriedades e dimensões descobertas nos dados.
De forma geral, durante a codificação aberta, os dados são separados em partes
distintas, rigorosamente examinados e comparados em busca de similaridades e de
diferenças; (2) Codificação axial que consiste em relacionar categorias com
subcategorias e examinar como as categorias se cruzam e se associam, isto é, esta fase
visa identificar os relacionamentos entre as categorias; e (3) Codificação seletiva que é
um processo contínuo de integração e refinamento da teoria após o reconhecimento das
relações entre os conceitos. Neste caso, uma categoria central é escolhida e a teoria é
detalhada em torno desta.
4.
Caracterização do Estudo
4.1
O Contexto da organização
O estudo de campo foi conduzido na Empresa Alpha que tem unidades de
desenvolvimento espalhadas em 10 Estados do país atendendo aos requisitos do CMMInível 2 ou 3. Em algumas destas unidades existe o escritório de projetos implantado.
Além disso, existe um processo de desenvolvimento de software que foi publicado em
2001 e é utilizado por toda a organização.
As entrevistas foram realizadas com dez entrevistados responsáveis pela
alocação de pessoas em projetos de desenvolvimento de software. O porte das unidades
envolvidas no estudo variou de 44 a 130 empregados e o nível de experiência dos
gerentes de projetos variou de 1 ano e meio a 10 anos de experiência, sendo que todos
os entrevistados tiveram treinamento corporativo em Gerenciamento de Projetos. A
seleção de gerentes de projetos se deu com o intuito de incluir unidades de portes
diferentes, com ou sem Escritório de Projetos Funcional [Kerzner 2006] estabelecido,
com níveis de experiência variados e que atendem a projetos de características distintas
34
ESELAW’09
(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
critérios de alocação de pessoas; (2) níveis de importância entre os critérios de alocação;
(3) uma teoria sobre a importância da negociação durante a alocação de pessoas o que
inclui questões como: o que, quando, onde, como e quem estaria envolvido nessa
atividade. Cada um destes aspectos será discutido a seguir. Seguindo as recomendações
da teoria fundamentada em dados [Strauss 1967], para ilustrar as conclusões de cada um
dos resultados no decorrer do texto serão citados exemplos de onde os mesmos foram
extraídos.
5.1
Critérios de alocação
Experiência no negócio
A experiência no negócio envolve conhecimentos sobre: objetivo do sistema, regras de
negócio, cliente e integrações com outros sistemas e equipes. Este foi o critério mais
citado nas entrevistas: oito dos dez entrevistados citaram esse critério. Em muitas
entrevistas esse critério foi citado como mais importante que o
conhecimento/experiência na plataforma e até mesmo a disponibilidade do
desenvolvedor. A importância desse critério também se deve ao fato dele ser
considerado muitas vezes em situações críticas, em que existe a necessidade de
atendimento de uma manutenção corretiva, onde o prazo é crítico e em manutenções
evolutivas em que se deve ter conhecimento sobre o sistema para realizar a avaliação de
impactos. De acordo com o Entrevistado 07:
“O último projeto foi crítico (dificuldade e prazo), por isso, selecionei pessoas
que além de domínio sobre o negócio (objetivo do sistema), têm alta
produtividade, pois funcionalidades críticas seriam alteradas e é mais fácil
alocar quem gerou o código”
Conhecimento ou experiência na tecnologia
Muitos dos entrevistados citaram este critério como importante para a alocação. Em
alguns casos, conhecimento e experiência foram utilizados como termos sinônimos.
Entretanto, foi observado que muitas vezes o que é de fato importante, é a experiência,
já que não adianta o desenvolvedor ter sido capacitado (ter o conhecimento) se ainda
não o aplicou em nenhum projeto:
“A alocação é feita pela experiência da pessoa, se já trabalhou com Java,
design e etc..” (Entrevistado 01)
“Considero conhecimento na tecnologia: ferramentas GED, conversão para
formato PDF, ...” (Entrevistado 09)
Conhecimento relacionado ao papel do processo de desenvolvimento
Como as unidades pesquisadas seguem a um processo de software definido, uma das
premissas que todos os entrevistados citaram é que as pessoas são designadas para os
papéis definidos no processo e devem deter conhecimento sobre as atividades inerentes
ao papel, conforme exemplo abaixo do Entrevistado 06.
“Levo em considerações os papéis, já que as pessoas do pólo são treinadas e
detêm conhecimentos de acordo com os papéis definidos no processo.”
Características pessoais
De uma forma geral, as características pessoais não foram citadas como um critério de
alocação, mas alguns entrevistados citaram que as mesmas são consideradas em
conjunto com o papel a ser executado no projeto.
“Para o papel de testador levo em consideração características pessoais. A
pessoa tem que ser criteriosa.” (Entrevistado 03)
Disponibilidade
36
ESELAW’09
Constatou-se que os períodos de disponibilidade podem derivar de informações sobre a
indisponibilidade de cada profissional, como: envolvimento em outros projetos, férias,
licença médica e outros afastamentos. Oito dos dez gerentes citaram que a
disponibilidade de projeto é considerada como critério de alocação de pessoas.
“Realizo a alocação via MS-Project... recursos (humanos) são integrados
usando [o] banco de recursos, onde são registrados o abono, licença médica e
férias.” (Entrevistado 02)
O trecho acima ilustra também a necessidade de gerenciar as indisponibilidades das
pessoas de alguma forma, por exemplo, em algum tipo de ferramenta para que estas
indisponibilidades não atrapalhem inesperadamente o andamento do projeto. Isto
também permite uma realocação ou replanejamento do projeto quando uma
indisponibilidade futura é identificada.
Interesse pessoal
O interesse pessoal foi considerado como fator de motivação para que desenvolvedores
participassem do projeto, mesmo que para isso a produtividade fosse reduzida.
“... [considero em] quais áreas têm maior conhecimento e quais gostariam de
trabalhar mesmo que não tenham todo esse conhecimento.” (Entrevistado 02)
O trecho acima corrobora que o interesse pessoal do desenvolvedor deve ser
considerado conforme consta na norma NBR ISO 10006 (2000), PMBOK [PMI 2004] e
[Pfleeger 2004]. O interessante no trecho acima, é que o entrevistado chega a considerar
o interesse pessoal em detrimento ao conhecimento na tecnologia e à produtividade.
Produtividade
A importância da produtividade dos desenvolvedores foi citada em algumas entrevistas,
principalmente em situações que envolviam prazos curtos, importância do sistema para
o cliente e criticidade da funcionalidade a ser alterada.
“Na formação dos grupos de trabalho foram mapeadas as pessoas: as pessoas
que são rápidas (alta produtividade) foram alocadas no grupo de manutenções
corretivas, as que apresentam maior curva de aprendizado foram alocadas no
grupo de trabalho de evolutiva.” (Entrevistado 08)
Complexidade do projeto ou da tarefa
Nas entrevistas, constatou-se que a complexidade do projeto ou da tarefa em geral
estava ligada à complexidade da regra de negócio do sistema.
“A característica do projeto considerada importante é a complexidade da regra
de negócio, ...” (Entrevistado 10)
“Depende da complexidade do projeto, se tiver muitas atividades, se muitas
delas forem complexas e os analistas experientes forem poucos (eles são
geralmente priorizados para as tarefas complexas)” (Entrevistado 04)
Criticidade do Projeto
A criticidade do projeto foi citada como aspecto ligado à importância do mesmo para o
cliente ou para a unidade. Nessas situações, foram constatados casos em que existe até
remanejamento de pessoas de outros projetos.
“Como característica do projeto, considero se ele é crítico (estratégico para o
cliente). Para esse caso, escolho pessoa que cumpre prazo” (Entrevistado 09)
“... é necessário pensar a quanto à criticidade dos projetos, já que em alguns
projetos mais críticos, deve-se ceder as pessoas.” (Entrevistado 2).
É justamente este remanejamento de pessoas que leva a necessidade de
negociação entre os gerentes das equipes de desenvolvimento. Este aspecto é discutido
em mais detalhes na seção 5.3.
37
ESELAW’09
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
A negociação poderá ocorrer se a pessoa mais indicada para participar em um projeto
estiver indisponível por estar alocada em outro projeto em andamento. Durante o estudo
de campo foi constatado que essa negociação envolve gerentes de projetos, gerentes das
unidades e titulares dos Escritórios de Projetos e pode levar até mesmo dias para ser
finalizada, impactando no tempo necessário para a realização da alocação. Abaixo
exemplos que mostram a necessidade e a complexidade da atividade de negociação com
outros gerentes.
“Quando tem papéis a serem executadas por pessoas de outra equipe (exemplo:
consultor de garantia de qualidade) tem que negociar com outro líder.”
(Entrevistado 03)
“O que leva mais tempo é para negociar, pode levar dias. Quando o recurso já
está para outro projeto tem que negociar, envolve até o gerente do pólo.”
(Entrevistado 05)
A negociação é uma atividade complexa, já que se a pessoa estiver alocada em
outro projeto, isso desencadeará a realocação no projeto de origem. Nessas negociações
deve ser determinado qual projeto é mais prioritário para a unidade ou para o cliente e
isso implica em uma maior força no momento de fornecer aporte de recursos humanos
para esse projeto. Essa decisão é tomada normalmente pelo gerente da unidade,
conforme exemplo abaixo.
“Isso já aconteceu [alocação de outras pessoas fora da equipe], aí o gerente da
unidade interfere na alocação dando mais força para projetos mais
críticos/estratégicos para o pólo/cliente.” (Entrevistado 01)
De forma complementar, para apoiar a decisão do gerente da unidade e até
diminuir o esforço envolvido na negociação, alguns entrevistados citaram a importância
38
ESELAW’09
do escritório de projetos da unidade realizar atividades de gestão de portfólio de
projetos de forma a manter uma lista priorizada dos projetos mais importantes de acordo
com as estratégias da unidade e também realizar a gestão de competências das pessoas.
Isso pode ser confirmado no trecho abaixo do Entrevistado 02.
“Alocação deve ser feita pelo escritório de projetos, de forma a não ser de
responsabilidade do líder de projeto a negociação com outros líderes.”
6.
Discussão
Na norma NBR ISO 10006 [ABNT 2000], no PMBOK [PMI 2004] e no CMMI [SEI
2002] são citados que critérios devem ser considerados na atividade de alocação de
pessoas, sem fornecer detalhamentos da importância dos mesmos para a execução das
atividades e formação das equipes. Os resultados deste trabalho permitem identificar
como cada um desses critérios é considerado no dia-a-dia dos gerentes, além de permitir
o entendimento de como a prioridade entre os critérios é tratada pelos entrevistados de
acordo com os resultados esperados pela alocação.
Por exemplo, a experiência de um desenvolvedor é considerada em dois
aspectos: experiência no negócio e experiência na tecnologia. Um fato interessante é
que a experiência no negócio em muitos casos foi considerada mais importante que a
experiência na tecnologia. No critério conhecimento, os gerentes enfatizaram a
necessidade de conhecimento tanto na tecnologia como no papel a ser alocado no
processo de desenvolvimento. O interesse pessoal deve ser considerado levando em
consideração a sua motivação em realizar a tarefa, conforme sugerido em [Pfleeger
2004] e [Ferreira 2008]. Entretanto, foi interessante observar que em alguns casos, para
considerar esse fator, o gerente de projetos dispensa outros fatores tradicionalmente
considerados mais importantes, como a produtividade. Além disso, considerar o
interesse pessoal é visto como uma forma de motivar o empregado. A alocação baseada
em características pessoais de acordo com o papel a ser desempenhado corrobora o
trabalho de Acuña (2006).
Foi possível observar que os gerentes de projetos consideram as características
do projeto como um todo ao invés de pensar nas características de cada atividade
envolvida, pois isso influi diretamente no resultado esperado da alocação e na definição
do perfil da pessoa a ser alocada. Um exemplo disto foi comentado pelo Entrevistado
09: “Como característica do projeto, considero se ele é crítico (estratégico para o
cliente). Para esse caso, escolho a pessoa que cumpre prazo”. As características do
projeto consideradas relevantes foram: (1) tipo (sistema novo, manutenção corretiva,
manutenção evolutiva, etc.); (2) complexidade; e (3) criticidade. Estes resultados são
diferentes dos apresentados em [Barreto 2005], [Souza 2007] e [Schnaider 2003].
Outro ponto que merece destaque é quanto à disponibilidade. Alguns autores
como Barreto (2005) e Souza (2007) consideram que a alocação depende da
disponibilidade das pessoas. Entretanto, os resultados deste estudo sugerem que esta é
uma forma limitada de tratar o problema de alocação de pessoas, já que muitas vezes as
pessoas a serem designadas já estão alocadas para outros projetos. Isto requer uma
intensa e demorada negociação entre diversos atores, e caso a negociação tenha sucesso,
ela pode causar uma realocação de pessoas nos projetos.
O principal resultado deste trabalho está relacionado à importância da
negociação para a adequada alocação de pessoas, um aspecto que não é tão discutido na
literatura. Nesse sentido, no PMBOK [PMI 2004] é comentada a necessidade de
negociação entre equipes de gerenciamento de projetos dentro da organização executora
39
ESELAW’09
para designar adequadamente recursos escassos ou especializados. Portanto, a
negociação identificada nesse trabalho refere-se especificamente à realocação de
pessoas. Essa negociação, por sua vez, envolve a discussão de que projetos são os mais
prioritários e quais os perfis de competências das pessoas envolvidas. Além disso, a
duração da atividade de alocação é diretamente influenciada pela negociação, que pode,
quando requerida, necessitar de vários dias para ser concluída. Este aspecto – a duração
da atividade de alocação – não é discutido em trabalhos anteriores. Em [Barreto 2005],
por exemplo, a complexidade desta tarefa e a necessidade de apoio computacional para
a mesma é apenas comentada.
Para apoiar a negociação levando em conta a criticidade e o impacto em projetos
em andamento é importante que exista uma ferramenta que apresente uma visão
integrada dos projetos e atividades em execução além dos que ainda serão executados.
Também, as pessoas passíveis de alocação poderiam ser tanto as que estão disponíveis
no período quanto as que já estão alocadas. Além disso, deve ser fornecida uma forma
de verificar os impactos no projeto de origem com a realocação. Outros aspectos
relacionados ao projeto de ferramentas foram identificados, mas não puderam ser
discutidos neste artigo por limitação de espaço.
7.
Considerações Finais e Trabalhos Futuros
O presente trabalho apresentou os resultados de um estudo qualitativo realizado na
empresa Alpha. Nesta empresa, foi possível estudar unidades de desenvolvimento de
software de diferentes portes, com e sem escritório de projetos implantado, com
gerentes de projetos de variados níveis de experiência e envolvendo projetos com
características diferentes. A partir da coleta e análise de dados utilizando-se a teoria
fundamentada em dados, foi possível identificar em projetos reais os critérios que são
levados em consideração durante a alocação de pessoas, o nível de importância destes
critérios e as facilidades consideradas interessantes para auxiliar a atividade de
alocação. Além disso, como principal resultado, destaca-se a importância da negociação
no processo de alocação de pessoas.
Espera-se que os resultados deste trabalho possam aperfeiçoar o processo atual
de alocação de pessoas na empresa Alpha que não prevê a negociação durante a
alocação, mas que, conforme discutido neste artigo influi tanto no tempo gasto para
alocação quanto em relação aos impactos nos projetos em andamento. Também será
possível propor melhorias no processo da empresa.
Como trabalhos futuros estão a elaboração de um survey a ser aplicado a um
número maior de gerentes de projetos da empresa Alpha visando obter dados
quantitativos sobre o processo de negociação. Este survey deverá abordar aspectos,
como: quais as pessoas envolvidas, quanto tempo dura essa atividade, como é realizada
a priorização dos projetos e a análise dos perfis das pessoas a serem liberadas dos
projetos e quais impactos são considerados aceitáveis durante a realocação.
Agradecimentos
Esta pesquisa é financiada pelo CNPq através do Edital Universal 2008 (473220/20083) 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
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
Experimentação em Engenharia de Software:
Glossário de Termos
Vitor Pires Lopes, Guilherme Horta Travassos
COPPE / UFRJ – Programa de Engenharia de Sistemas e Computação
Caixa Postal 68.511, CEP 21945-970, Rio de Janeiro – Brasil
{vitorlopes, ght}@cos.ufrj.br
Abstract. There is an increasing agreement in the Software Engineering
community that experimentation is necessary to develop or to improve
software development and maintenance processes, methods and tools.
Motivated by the importance of Experimental Software Engineering, some
researchers have tried to adapt concepts and definitions to their own
perspectives and research practices. This scenario frequently leads to
difficulties in knowledge exchanging between research groups and, mainly, in
study results comparison. To address this problem, a glossary of terms
concerned with Experimental Software Engineering has been organized. This
paper describes the construction of this glossary and introduces a web-based
tool that turns it accessible to the research community.
Resumo. Existe um consenso crescente na comunidade de Engenharia de
Software que experimentação é necessária para desenvolver ou melhorar
processos de desenvolvimento e manutenção de software, métodos e
ferramentas. Motivados pela importância da Engenharia de Software
Experimental, alguns pesquisadores tentam adaptar conceitos e definições a
suas perspectivas e práticas de pesquisa locais. Este cenário freqüentemente
leva a dificuldades na troca de conhecimento e, principalmente, na
comparação de resultados de estudo. Para tratar este problema, um glossário
de termos em Experimentação em Engenharia de Software foi construído. Este
artigo relata o processo de construção deste glossário e apresenta uma
ferramenta web que o torna acessível para a comunidade de pesquisa em
engenharia de software.
Palavras-chave. Engenharia de Software Experimental, Taxonomia, Glossário
de Termos, Experimentação
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
apóiem o processo de tomada de decisão a respeito da utilização de tecnologias de
software.
Na pesquisa em Engenharia de Software, iniciativas na condução de estudos
experimentais vêm aumentando consideravelmente ano após ano. Diferentes grupos de
pesquisa executam e incentivam a adoção de estudos primários e secundários como
meios de gerar evidências e construir um corpo de conhecimento científico válido em
Engenharia de Software [Travassos et al., 2008].
Motivados pela importância de Experimentação no avanço da pesquisa em
Engenharia de Software, vários grupos de pesquisa tentaram adaptar conceitos e
definições de Experimentação para suas próprias perspectivas e metodologias de
trabalho, freqüentemente diferentes entre si. Isto traz dificuldades no compartilhamento
e disseminação do conhecimento produzido, pois cada grupo de pesquisa passa a utilizar
um conjunto de conceitos e definições próprio. O estímulo à colaboração entre
pesquisadores também é dificultado pela ausência de uma normatização de termos
empregados na área. Além disso, a comparação entre resultados de grupos diferentes
pode ser prejudicada em função de não apresentarem um padrão de descrição
compatível entre si. A falta de uma taxonomia em comum dificulta a evolução científica
da área [Sjøberg et al., 2007].
Tendo em vista este cenário, a comunidade de pesquisadores do ISERN1
(International Software Engineering Research Network) deu início, em 1995, à
construção de uma primeira versão de um glossário de termos que contemplasse os
conceitos com sua respectiva definição no domínio da experimentação em Engenharia
de Software. Tomando como ponto de partida este trabalho do ISERN, combinado com
informações extraídas de outras iniciativas mais recentes [Amaral, 2003], o grupo de
Engenharia de Software Experimental2 da COPPE/UFRJ iniciou a reorganização do
glossário de termos. Em complemento, planejou e conduziu, em parceria com diferentes
pesquisadores, sessões de revisão que reuniram cientistas e alunos no sentido de
fornecer contribuições para melhorar a completude e a corretude deste glossário. Para
facilitar o acesso às informações e sua constante atualização e avaliação através da
contribuição contínua da comunidade, o glossário está disponível através de uma
ferramenta web baseada na tecnologia wiki3, onde funcionalidades para facilitar a
navegação e consulta da lista de termos foram acrescentadas, incluindo a possibilidade
de representação em diferentes línguas nativas.
Este trabalho descreve o processo de construção do glossário de termos,
contemplando detalhes sobre o planejamento e a execução das sessões de revisão que
contribuíram para a definição da lista de termos atual. É discutida também a integração
do glossário ao repositório de conhecimento de um ambiente de Experimentação em
Engenharia de Software. Além disto, são apresentadas as principais características da
ferramenta4 sobre a qual o glossário foi disponibilizado à comunidade.
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
O artigo está organizado em quatro seções: A primeira compreende esta
introdução. A seção 2 descreve o processo de construção do glossário de termos. A
seção 3 detalha as facilidades fornecidas pela ferramenta que disponibiliza o glossário.
A última seção resume e conclui este artigo.
2. Processo de Construção do Glossário de Termos
No contexto de experimentação em larga-escala, a troca de conhecimento e experiência
entre os pesquisadores fica dificultada quando estes não se utilizam de um vocabulário
em comum. Freqüentemente, cada grupo de pesquisa adapta conceitos e definições sob
suas próprias perspectivas. Isto conduz a divergências entre os pesquisadores, por vezes
tornando difícil a comparação entre os resultados dos estudos e assim atrasando a
evolução da área [Sjøberg et al., 2007].
Visando tentar reduzir as divergências terminológicas e construir uma
perspectiva em comum para a área, foi desenvolvido um glossário de termos de
Experimentação em Engenharia de Software. As subseções a seguir detalham a
construção da versão inicial do glossário, a condução de revisões de seu conteúdo em
parceria com diferentes pesquisadores e alunos e a integração do glossário ao repositório
de conhecimento do eSEE, um ambiente de apoio à Experimentação em Engenharia de
Software.
2.1.
Construção da Versão Inicial do Glossário de Termos
A comunidade ISERN disponibilizou uma primeira versão de um glossário de termos
[ISERN, 1995], elaborado a partir dos estudos usualmente executados na época no
contexto desta comunidade e relacionados principalmente a estudos in vitro no domínio
de inspeções de software. Desde então foi possível perceber uma demanda crescente
pela utilização de experimentação em Engenharia de Software, com foco diversificado e
direcionado a diferentes categorias de estudo. Desta forma, o glossário proposto
inicialmente, embora adequado para uma categoria em particular de estudos, não
permitia o entendimento consistente dos conceitos envolvidos nos novos tipos de
estudo. Assim, visando contribuir para a evolução da experimentação em Engenharia de
Software, uma nova versão do glossário de termos passou a ser organizada a partir de
2004.
Um conjunto evoluído de termos foi organizado a partir da consolidação da
terminologia básica estabelecida pelo ISERN e dos trabalhos de Amaral (2003), Costa et
al. (2003) e Chapetta (2006). Estes trabalhos abordam conceitos básicos sobre
experimentação e também específicos sobre diferentes categorias de estudo,
contribuindo assim para consolidar um glossário mais contemporâneo e com uma
cobertura mais satisfatória. Nesta reorganização, foram removidas as duplicatas cuja
definição fosse menos precisa. Foi organizada uma sessão no ESELAW’06 para
apresentá-lo à comunidade. O terceiro Workshop de Experimentação em Engenharia de
Software – ESELAW’06 – apresentou objetivos similares aos anteriores: reportar e
discutir novos resultados na área e encorajar a troca de idéias para compreender, a partir
de um ponto de vista experimental, aspectos de qualidade e deficiências de tecnologias
de Engenharia de Software. O evento reuniu vários pesquisadores da América Latina
(principalmente do Brasil) e, portanto, representou uma excelente oportunidade para
conduzir uma sessão de discussão entre os participantes para identificar melhorias no
44
ESELAW’09
glossário e os possíveis requisitos para estrutura computacional de apoio a sua utilização
através da web. Assim, consolidou-se a primeira versão do glossário de termos de
Experimentação em Engenharia de Software. Este resultado se encontra disponível nos
Anais do ESELAW’06.
A discussão conduzida no ESELAW’06 apontou a importância de facilidades
para navegação, inclusão, alteração e exclusão de conceitos e definições no uso do
glossário. Ressaltaram também a facilidade de acesso como sendo uma característica
determinante no incentivo à normatização terminológica na área. Tendo em vista estas
perspectivas, foram identificadas e estudadas tecnologias candidatas para apoiar o
desenvolvimento de uma ferramenta que torne o glossário mais acessível e forneça
operações básicas de manipulação de seu conteúdo. Dentre as opções disponíveis, foi
escolhida a tecnologia wiki. Esta tecnologia fornece uma infra-estrutura com diversas
facilidades construídas especificamente para glossários, incluindo recursos de controle
de acesso, navegação, inclusão, alteração e exclusão de termos e definições. A seção 3
fornece maiores detalhes sobre as funcionalidades oferecidas pela ferramenta que
disponibiliza o glossário. A subseção a seguir descreve como foram conduzidas revisões
do glossário.
2.2.
Revisões do Glossário de Termos
Após apresentação no ESELAW’06 e consolidação da primeira versão do glossário, seu
conteúdo passou por sessões de revisão por diferentes grupos relacionados à Engenharia
de Software Experimental. Foram conduzidas sessões de revisão em eventos científicos
que reunissem pesquisadores de diferentes comunidades, representando assim uma
excelente oportunidade de divulgação do glossário no meio de pesquisa e de discussões
visando melhorias na completude e corretude da lista de termos.
Uma primeira revisão ocorreu na reunião do ISERN em 2007. Como uma das
primeiras iniciativas de concepção do glossário veio do ISERN através da definição de
uma terminologia básica, a reunião entre os membros deste grupo foi considerada para
divulgar o glossário e executar uma revisão. Em seguida, outra revisão ocorreu no
ESELAW’07. Os objetivos destas revisões foram avaliar a pertinência e a correção do
conteúdo do glossário.
Nestas revisões, apresentou-se o glossário e uma discussão foi promovida a fim
de identificar quais termos podiam ser incluídos e quais seriam passíveis de exclusão
por não estarem ligados diretamente à experimentação em Engenharia de Software. Os
participantes foram divididos em grupos que receberam um documento (Figura 1)
listando os termos inclusos no glossário, organizados em ordem alfabética. Os
participantes foram orientados a discutir em grupo quais termos poderiam ser inclusos e,
dentre aqueles listados, quais seriam passíveis de exclusão.
45
ESELAW’09
Figura 1. Documento distribuído para registrar
sugestões de inclusão e exclusão de termos
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.
2.3.
Integração a um repositório de conhecimento
Executar estudos experimentais envolve grande volume de conhecimento consumido e
produzido ao longo da execução do Processo de Experimentação [Shull et al., 2001].
Este conhecimento precisa ser gerenciado adequadamente, sendo disponibilizado no
momento certo ao pesquisador para auxiliá-lo em tomadas de decisão e também
registrado para posterior consulta.
Em vista disto, Lopes e Travassos (2009) destacaram a necessidade de um
repositório que formalize este conhecimento, tornando-o acessível ao pesquisador
durante a execução do Processo de Experimentação. Este repositório foi proposto como
sendo o núcleo de recuperação de conhecimento do eSEE (experimental Software
46
ESELAW’09
Engineering Environment), uma infra-estrutura computacional baseada em serviços web
que provê facilidades de instanciação de ambientes de apoio ao Processo de
Experimentação em Engenharia de Software [Travassos et al., 2008]. O eSEE consulta
o repositório e disponibiliza ao pesquisador o conhecimento necessário para instanciar
ambientes com todas as facilidades requeridas para conduzir o estudo desejado [Lopes e
Travassos, 2009].
Repositórios de conhecimento expressam, através de uma linguagem de
representação de conhecimento específica, conceitos e seus relacionamentos [O’Leary,
1998]. Como o repositório proposto para o eSEE contempla conceitos de
Experimentação em Engenharia de Software, os termos listados no glossário podem
constituir um conteúdo inicial deste repositório. Assim, o glossário construído até então
se revelou um importante mecanismo de representação de conhecimento a ser adotado
na estruturação deste repositório [Lopes e Travassos, 2009].
O eSEE contempla a instanciação de ambientes para diferentes tipos de estudo e,
portanto, o conhecimento a cerca desses estudos deve estar refletido no repositório.
Lopes e Travassos (2008) identificaram o domínio deste conhecimento, que contempla
conceitos ligados às taxonomias de estudo segundo abordagem de pesquisa, estratégia
de estudo, método de pesquisa e ambiente de estudo. Entretanto, o glossário construído
até então carece de uma cobertura mais satisfatória a cerca dos conceitos sobre essas
taxonomias. Desta forma, para consolidar a integração do glossário ao repositório,
realizou-se uma pesquisa em referências importantes na literatura de Experimentação
em Engenharia de Software. O objetivo foi agregar novos termos sobre as taxonomias
previstas em [Lopes e Travassos, 2008], tornando o conteúdo do glossário mais aderente
ao conhecimento requerido pelo repositório de conhecimento do eSEE. As referências
selecionadas foram [Juristo e Moreno, 2001], [Shull et al., 2008] e [Wöhlin, 2000].
Foram identificados 28 novos termos, incluídos com sua respectiva definição no
glossário através da ferramenta wiki.
Com a inclusão dos conceitos sobre os diferentes tipos de estudos previstos em
[Lopes e Travassos, 2008], o glossário foi integrado como um dos mecanismos
estruturantes do repositório de conhecimento do eSEE (Figura 2). Como o repositório
também deve explicitar relacionamentos entre os conceitos, foram construídas
ontologias que representam as relações entre os conceitos expressos no glossário [Lopes
e Travassos, 2009].
Figura 2. Repositório de conhecimento de Experimentação
em Engenharia de Software47
[Lopes e Travassos, 2009]
ESELAW’09
3. Características do Glossário de Termos
A primeira versão do glossário foi construída e disponibilizada em um documento. O
aumento gradativo no número de termos, embora crucial do ponto de vista de
completude, trouxe dificuldades para os pesquisadores navegarem pela lista, procurar
por um termo específico e, sobretudo, controlar o acesso aos direitos de alteração no
glossário. Assim, deu-se início, após consolidação da primeira versão do glossário, de
um estudo sobre tecnologias disponíveis que pudessem ser empregadas no
desenvolvimento de uma ferramenta que disponibilizasse o glossário. Os requisitos da
ferramenta que a tecnologia deve apoiar são:

Ser composto como um sistema web, permitindo seu uso em diferentes
localidades e entre comunidades de pesquisa;

Prover controle de acesso;

Disponibilizar operações de inclusão, alteração e exclusão de termos, definições
e referências.
Dentre as opções disponíveis, foi escolhida a tecnologia wiki [MediaWiki,
2009]. Esta tecnologia fornece uma infra-estrutura que satisfaz os requisitos
estabelecidos por ter sido concebida para viabilizar a criação e manutenção de
glossários. A infra-estrutura é disponibilizada em um pacote de instalação contendo
nativamente recursos de controle de acesso, navegação, inclusão, alteração e exclusão de
termos e definições. Perfis de moderadores podem cadastrar novos usuários com
diferentes permissões de alteração no glossário. Por padrão, todo usuário da ferramenta
pode consultar os termos do glossário sem, entretanto, estar efetivamente cadastrado. A
ferramenta está acessível através do endereço http://lens-ese.cos.ufrj.br/wikiese.
A ferramenta apresenta a lista de termos em ordem alfabética, na qual o usuário
pode navegar facilmente entre os termos utilizando hiperlinks (Figura 3). A fim de
adicionar uma forma de navegação diferenciada, desenvolveu-se um componente
baseado em hipergrafo (Figura 4) que oferece uma nova perspectiva sobre a lista. Os
termos são apresentados em um hipergrafo e ligados pelos nós rotulados pela sua inicial.
Figura 3. Lista de Termos
48
ESELAW’09
Figura 4. Hipergrafo do Glossário de Termos
Ao acionar o link de um dos termos da lista ou do hipergrafo, o pesquisador é
conduzido à página (Figura 5) contendo a definição em inglês, português e espanhol do
termo em questão. Além disso, são citadas as referências que fundamentam a definição e
outras fontes importantes na contextualização do termo.
Figura 5. Definições em diferentes línguas do termo selecionado
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
os diferentes tipos de estudo experimentais. Ao final foram apresentadas as principais
características da ferramenta que disponibiliza o glossário na web.
Dentre as contribuições deste trabalho, destacamos a construção do glossário
como uma importante iniciativa para estabelecer uma terminologia comum na área de
Experimentação em Engenharia de Software. As avaliações conduzidas constituíram
uma relevante contribuição para que o glossário atingisse níveis de corretude e
completude satisfatórios em comparação com sua versão inicial. Destacamos também a
importância do glossário na estruturação do repositório de conhecimento do eSEE,
através do qual o glossário pode ser utilizado. O glossário revisado pode ser acessado
também de forma independente através do endereço http://lens-ese.cos.ufrj.br/wikiese.
Acreditamos que a comunidade possui importantes contribuições a fornecer no
sentido de melhorar e divulgar o glossário, fomentando seu uso de forma extensiva entre
os pesquisadores. A colaboração de membros da comunidade para evolução contínua e
divulgação do glossário representa um importante passo na normatização da
terminologia e melhoria constante do glossário, que deve refletir a própria evolução da
área de Experimentação em Engenharia de Software.
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
Lopes, V.P., Travassos, G.H. (2008) “Infra-estrutura Conceitual para Ambientes de
Experimentação em Engenharia de Software”, Experimental Software Engineering
Latin American Workshop (ESELAW'08), Brasil.
Lopes, V.P., Travassos, G.H. (2009) “Estrutura do Repositório de Conhecimento de um
Ambiente
para
Experimentação
em
Larga
Escala
em Engenharia de Software”, Em: Anais do XXIII Simpósio Brasileiro de
Engenharia de Software, SBES, Fortaleza, CE, Brasil, Outubro.
O’Leary, D.E., (1998), “Using AI in Knowledge Management: Knowledge Bases and
Ontologies”. IEEE Intelligent Systems, v. 13, n. 3 (May/Jun), pp. 33-39.
Shull, F., Singer, J., Sjøberg, D. I. K. et al., “Guide to Empirical Software Engineering”,
Springer, ISBN: 978-1-84800-043-8, 2008.
Shull, F., Carver, J., Travassos, G.H., (2001), “An Empirical Methodology for
Introducing Software Processes”. In: 8th European Software EngineeringSymposium
and 9th ACM SIGSOFT Symposium on the Foundations of Software Engineering
(FSE-9) and 8th European Software Engineering Conference (ESEC), Vienna,
Austria, September.
Sjøberg, D.I.K., Diba, T., Jorgensen, M., (2007), “The Future of Empirical Methods in
Software Engineering Research”. Em: International Conference on Software
Engineering (ICSE), Minneapolis, Estados Unidos, Maio.
Travassos, G. H., Santos, P. S. M., Mian, P. G., Dias Neto A. C., Biolchini, J., “A
Environment to Support Large Scale Experimentation in Software Engineering”, 13th
IEEE International Conference on Engineering of Complex Computer Systems,
Abril, 2008.
MediaWiki, (2009), http://www.mediawiki.org/wiki/MediaWiki
Wohlin, C., Runeson, P., Höst, M., Ohlsson, M., Regnell, B., Wesslén, A.,
Experimentation in Software Engineering – An Introduction. Kluwer Academic
Publishers. 2000.
51
ESELAW’09
Rastreabilidade Indutiva Aplicada a Artefatos de Software
Trabalho técnico
Raquel Nitsche dos Santos, Raul Sidnei Wazlawick
Departamento de Informática e Estatística – Programa de Pós-Graduação em Ciência da
Computação – Universidade Federal de Santa Catarina (UFSC) – Cx. P. 476 –
Florianópolis, SC – Brasil
{raquelnitsche, raul}@inf.ufsc.br
Abstract. Maintaining quality and consistency of artifacts through a software
project can be more effective with the use of traceability. However, creating
consistent traceability relationships can be a task so complex that it is often
ignored or minimized. Techniques such as automatic discovery and traceability
matrix have known limitations. This paper examines an alternative that consists in
allowing the creation of traceability relationships inductively during the software
development process. Experiments with a CASE tool showed encouraging results
indicating that the technique can significantly improve productivity.
Resumo. A tarefa de manter a qualidade e consistência de artefatos ao longo de
um projeto de software pode ser mais efetiva com a utilização de rastreabilidade.
Porém, a criação de relações de rastreabilidade consistentes ao longo de um
projeto é uma tarefa tão complexa que muitas vezes é deixada de lado. Técnicas
como a recuperação automática e a matriz de rastreabilidade apresentam
limitações. Este trabalho examina outra abordagem que consiste em permitir a
criação de relações de rastreabilidade indutivamente ao longo do
desenvolvimento dos artefatos do projeto. Experimentos com uma ferramenta
CASE mostraram resultados animadores indicando que a técnica pode melhorar
significativamente a produtividade.
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
na análise de impacto e no reuso de software, proporcionando ao desenvolvedor uma
importante visão para o processo de desenvolvimento e evolução do software. A
rastreabilidade é reconhecida como um importante fator para obtenção da qualidade no
processo de desenvolvimento, bem como para um gerenciamento de projeto eficiente [5].
Processos de melhoria da qualidade de software como o CMMI nível 3, ISO 15504 e MPSBR estabelecem que práticas básicas de rastreabilidade devem ser seguidas.
As principais técnicas de rastreabilidade existentes são a matriz de rastreabilidade e
a recuperação automática de rastreabilidade. Ambas são importantes, porém possuem
limitações que dificultam o uso efetivo da rastreabilidade na prática.
De acordo com Cleland-Huang et alii [20] a matriz de rastreabilidade assume um
tamanho que rapidamente se torna não gerenciável, uma vez que o número de relações
tende a aumentar significativamente, tornando a utilização da matriz complexa. O empenho
dos desenvolvedores é retardado pela carência de suporte por parte das ferramentas, o que
causa uma percepção de que o custo despendido para manter a matriz de rastreabilidade é
muito alto, em comparação aos seus benefícios [21].
Técnicas de recuperação automática não recuperam todos os relacionamentos
corretos sem também recuperar muitos falsos, o que acarreta trabalho extra para o
desenvolvedor no descarte destes relacionamentos [15]. A tarefa de descarte pode ser muito
trabalhosa, pois o desenvolvedor pode gastar mais tempo para descartar relações falsas do
que rastreando as corretas. Ainda que seja possível melhorar o desempenho destas técnicas
elas estão longe de ser uma solução viável para o problema [22].
Mesmo que a rastreabilidade seja requerida em grande parte das aplicações de
segurança crítica, e faça parte de diversas iniciativas de melhoria de processo de software,
as organizações ainda buscam uma maneira de implementá-la de forma que traga um bom
custo-benefício [21].
Apesar de sua reconhecida importância, não é satisfatório o suporte para a
rastreabilidade em ferramentas CASE contemporâneas, especificamente aquelas que
permitem a construção de artefatos UML. O principal defeito destas ferramentas é a falta de
um suporte automático ou semi-automático para a criação e manutenção de links de
rastreabilidade, o que torna sua utilização cansativa e custosa [6]. Esta carência é um dos
fatores que promovem a baixa qualidade de sistemas [3].
As relações de causa-efeito entre elementos de artefatos não são identificadas
automaticamente nas ferramentas CASE porque a inclusão de novos elementos nos
diagramas usualmente é feita sem que sua origem ou causa seja explicitada, os elementos
são criados de forma individual, geralmente a partir de toolboxes. Desta forma, a criação da
rastreabilidade é uma tarefa deixada para depois, ou seja, após inserir o novo elemento no
diagrama o usuário da ferramenta CASE deverá indicar quais as relações de rastreabilidade
se aplicam àquele elemento.
Este artigo mostra que é possível automatizar a criação de relações de
rastreabilidade sob a hipótese de que a inserção de novos elementos nos artefatos não
consiste simplesmente em criar um novo elemento no diagrama, mas em uma ação que, em
muitos casos, tem uma causa bem definida a partir de algum outro elemento. Por exemplo,
53
ESELAW’09
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
rastreabilidade, mas apenas ferramentas em trabalhos de pesquisa [13, 14].
A técnica indutiva, aqui proposta, diferencia-se dos trabalhos citados em três
aspectos: (1) ela não procura detectar ligações de rastreabilidade entre elementos
preexistentes, mas propõe que a criação de novos elementos em artefatos seja feita de
forma que a ligação de rastreabilidade seja criada pela explicitação da relação causa-efeito
entre o elemento causador e o elemento criado, possibilitando assim um menor esforço no
mapeamento das relações; (2) a técnica é definida de maneira totalmente genérica, ou seja,
pode ser aplicada a quaisquer elementos e quaisquer artefatos, pois não analisa o conteúdo
dos elementos ou seu significado, mas a forma de criação destes, o que possibilita o
atendimento de diversos artefatos e não apenas de artefatos específicos e (3) a técnica já foi
integrada a uma ferramenta CASE de largo uso comercial.
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
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
artefato de
destino
2- Seleciona o
elemento-causa
3- Deriv a o
elemento-efeito
Figura 1. Passos da rastreabilidade indutiva.
Um plugin foi desenvolvido na ferramenta CASE Enterprise Architect™ (EA) [8],
para permitir a utilização da técnica indutiva. Na Figura 2 é apresentada sua interface, os
itens destacados (1, 2 e 3) correspondem aos passos necessários para a criação da
rastreabilidade apresentados na Figura 1. Neste exemplo são derivados casos de uso a partir
de requisitos, porém a técnica indutiva pode permitir a criação de elementos em diversos
outros artefatos. As relações criadas podem ser visualizadas por meio da matriz de
rastreabilidade e também da funcionalidade Hierarchy do EA. Hierarchy apresenta de
forma hierárquica as dependências entre os elementos.
1
2
3
Figura 2. Interface do plugin de rastreabilidade.
A intenção da técnica indutiva é reduzir o esforço do desenvolvedor no mapeamento
da rastreabilidade, tornando a atividade menos penosa em comparação às técnicas
atualmente utilizadas. Com isto espera-se que a resistência à utilização da rastreabilidade
possa diminuir.
56
ESELAW’09
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
matriz de relacionamentos. A hipótese H1 (hipótese alternativa) é que em média a técnica
indutiva possui maior desempenho que a técnica matriz de relacionamentos, para a criação
e evolução de relações de rastreabilidade.
Maior desempenho, neste trabalho, significa criar o maior número de relações
corretas. Relações corretas são aquelas criadas entre elementos que realmente possuem uma
relação de dependência. Um erro comum no mapeamento da rastreabilidade é criar por
engano uma relação entre elementos que não possuem dependência (relação falsa).
Figura 3. Relações de rastreabilidade corretas criadas com cada técnica.
As amostras são independentes, pois as técnicas foram executadas com grupos
diferentes. Neste caso aplica-se o teste t para amostras independentes. Ao aplicar o teste o
resultado foi 8,27. Com 8 graus de liberdade a probabilidade de significância foi p=0,02.
Considerando um nível de significância de 5% (a=0,05) tem-se (p<a), o que
significa que se deve rejeitar H0 em favor de H1. Conclui-se, portanto, com 95% de
confiança que a técnica indutiva tende a apresentar maior desempenho do que a técnica
matriz de relacionamentos. O desempenho melhor da técnica indutiva indica que o esforço
despendido para sua utilização pode ser significativamente menor em comparação à técnica
matriz de relacionamentos.
O mesmo teste foi realizado comparando o desempenho da técnica indutiva com o
da técnica criação de links, onde a probabilidade de significância resultou em p=0. Concluise com 95% de confiança que a técnica indutiva tende a apresentar maior desempenho do
que a técnica criação de links.
O teste também foi aplicado entre a técnica matriz de relacionamentos e a técnica
criação de links, avaliando se as duas técnicas possuíam desempenho distinto. O teste não
detectou diferença entre estas duas técnicas.
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
buscam uma forma de criar as relações de rastreabilidade que forneça um bom custobenefí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
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 costquality 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
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, 4756.
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 costquality 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, 4142.
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
A Systematic Review on Software Product Lines Scoping
Marcela Balbino Santos de Moraes1, Eduardo Santana de Almeida2, Silvio Romero
de Lemos Meira1
1
Federal University of Pernambuco (UFPE), Brazil
2
Federal University of Bahia (UFBA), Brazil
{mbsm, srlm}@cin.ufpe.br, [email protected]
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
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
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.
3. Research Questions and Studies Search
The research questions are considered the key aspects of the systematic review. In this
review the questions were identified with the investigation of studies in SPL scoping and
with discussions at RiSE (Reuse in Software Engineering) Labs members. In this study,
eight questions were defined as can be seen in Table 1.
Table1. Research questions
Q1. What activities are
addressed for scoping in
the software product
lines?
The objective of this question is to identify the activities of scoping used by the approaches, as well as
analyzing the inputs and outputs addressed by each activity.
Q2.
Do
approaches
scope?
the
SPL
optimize
This question aims to identify if the approaches optimize scope and which techniques are used for this
optimization. Optimize scope is to adapt a scope to maximizes specific objectives [Schmid 2002], i.e. to
align the scope according with business objectives of the organization, as time-to-market and development
effort.
Q3. What are the types
of scope addressed by the
approaches?
The purpose of this question is to identify the types of scope covered by each approach. According to
Schmid [Schmid 2002], in general, three types of scope can be identified: I. product portfolio scoping, it
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
are involved in the scope
definition process?
This question aims to identify the essentials stakeholders at the scope definition process and their
importance (roles and attributions). According to Clements [Clements 2005], the involvement of a wide
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
use specific metrics or
cost models for scope
definition?
The goal of this question is to identify if the approaches for scope definition use specific metrics, general
software metrics or cost models. Moreover, this question aims to identify which types of metrics are used
and their importance for the economical value evaluation of the software product line assets.
Q6. Are the approaches
customizable?
The goal of this question is to identify if the approaches are customized for different contexts. Besides, the
question aims to determine which customization factors are used.
Q7. Do the approaches
treat the new perspective
of agile SPL planning?
The goal of this question is to identify if the approaches insert agile aspects in scoping and which
techniques, principles or practices are used.
Q8.
How
are
the
approaches related with
SPL development?
The goal of this question is to identify if the approaches have specifics activities to define scope according
with the different development stages, considering situations as: product line development started from the
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
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.
4.1. Scoping Activities
Analyzing the primary studies, we found a wide variety of activities for scoping.
However, the lack of standardization can be faced as a problem. In general, each
analyzed approach has specific activities to define scope. Besides, the majority of the
approaches do not have the activities showed clearly in an easy and applicable way, and
the guidelines for its application are described in high level. Therefore, in general, the use
of the approaches is considered difficult by the organizations and their activities,
typically, are adapted for definition of the scope to have success.
In general, the activities defined by the approaches can be clustered in three
groups: identification, analysis and prioritization. Identification is related with features,
requirements and products, the analysis is based on domains and sub-domains and the
prioritization is related with optimization factors. However, there few approaches which
address activities related with scope optimization, besides are also few the approaches
which address activities as: market analysis and release planning. Therefore, the current
scenario shows that there are not approaches that present activities for all the contexts in
which the product lines can be inserted, occurring inevitably an adaptation of the
activities or the use of two or more approaches in set to identify the scope adequately.
Table 2 summarizes some characteristics related with each approach and can help
researches and organizations to choice the most suitable approaches.
66
ESELAW’09
Table2. Summary of the aspects of the scoping approaches
Approaches Activities
Author
Optimization
Scope
Types
Stakehol Met Customi Agile
ders
rics zation
Factors
Relate
clearly
Scoping and
Developmen
t
Riebisch
[2001]
identification,
prioritization, use
priorities assets
interpretation of features
calculation and
decision tables
no
no
no
no
yes
Kish
identify
requirements
and do not define product
products, list and prioritize optimization
architecture
candidates, tasks for scoping
categorize requirements, examine
candidates for the product-line
scope
no
no
no
no
no
Schmid
[2002]
identification and description of optimize
the domain,
products, features and domains, feature
matrix assets
product
map
prioritization, using GQM
identification and prioritization
of assets
no
yes
no
no
no
Rommes
[2003]
writing and review of user do not define product
scenarios,
requirements optimization
identification
tasks for scoping
yes
no
no
no
no
Lee [2004]
market
analysis,
feature do not define assets
modeling,
feature
binding optimization
analysis, assets identification, tasks for scoping
core
assets
development,
production plan documentation
no
no
no
no
no
Helferich
[2005]
identify customer requirements,
product functions and evaluate
different
technologies
and
architectures
yes
no
no
no
no
no
yes
no
no
no
scenarios, do not define product
matrix, optimization
tasks for scoping
yes
no
no
no
no
John [2006] mandatory
activities: product prioritize
and domain,
identification,
plan
product optimized
the assets
releases, assess features, identify feature matrix
features, specify product feature
matrix and identify domains
yes
yes
yes
no
no
Inoki [2007] product line development plans do not define assets
no
yes
no
no
no
yes
no
no
yes
no
[2002]
use QFD to product
identify the true
needs of the
customers
Park [2005] analysis of commonality and do not define assets
variability,
variability optimization
dependencies analysis, domain tasks for scoping
model refinement, economical
evaluation of core asset
Clements
[2005]
development
of
attributes/products
products analysis
analysis, create product line optimization
development plan, create road tasks for scoping
map,
define
organizational
standards
Noor [2007] identify
and agree domains,
define features for each domain,
analyze products, define products
in terms of features, prioritize
product map
make
domain,
prioritization
assets
and optimization
of the product
map
4.2. Scope Optimization
According to Schmid [Schmid 2002], it is important to distinguish scoping according
with three goal levels: identification of a scope, i.e., simply writing down the scope;
67
ESELAW’09
evaluation of a scope, i.e., to determine advantages and disadvantages of a particular
scope; and, finally, optimization of a scope, optimization of the scope in terms of
identifying what should be built for reuse, it aims at the optimization of the underlying
concept (product line, domain, asset), so as to optimize some sort of benefit.
In our review was possible to identify optimization in product portfolio scoping
and asset scoping. The optimization in product portfolio scoping is performed, in
general, to determine a feature set aligned with market and business goal. In assets
scoping, the optimization activities are related, often, to the identification of the assets
implementation effort and their potential for each product and for all product line.
Optimization of SPL scope still is an aspect partly addressed. Few are the
approaches that define directly activities for optimization, as activities related with
components economic evaluation, where are used economic models, and optimization
criteria, where are used parameters, such as: market segments, customer view point,
product value and so on.
4.3. Scope Types
Analyzing the scope types, we can identify the focus of each approach. In general, the
approaches address product portfolio scoping and assets scoping, as can be seen in Table
2. With the review was possible to identify that more of 36% of the approaches have
activities related with product portfolio scoping, focusing on the identification of
products and features based on the market analysis and products analysis which are
economically useful and beneficial to product line development. Besides, assets scoping
is addressed by more of 63% of the approaches analyzed, focusing on the analysis of the
potential of the assets, identifying efforts and costs of implementation of them for
product line, and making analysis of variability dependencies.
On the other hand, there are few approaches which define domain scoping,
approximately 27 %, these are based on activities of domain potential assessment,
considering risks and benefits of the domains for the product line.
Based on the scope types addressed by the approaches, we can identify the levels
in which they perform scoping and their goals.
4.4. Stakeholders and Roles into Scoping
The participation of representative stakeholders with well-defined roles is very important
for the scoping phase. With the effective presence of them in the process, risks
associated with SPL are minimized, for example, the risk of including products lacking
some essential feature or with unnecessary features. However, the approaches do not
have an effective definition of stakeholders and roles, in spite of this information to be
extremely necessary for the success of the scope definition. This makes difficult to judge
which approaches have a team appropriated for scoping. Moreover, the choice of the
stakeholders and roles into project depends on a series of factors such as: resources,
project type, complexity, and so on. Nevertheless, roles such as: domain experts, with
technical or marketing knowledge; scoping expert, to conduct the tasks of the process
and identify constraints; end user or customer, to enable a customizable SPL; architects,
to phase of assets scoping, with the function of defining the conflicts and impacts of the
reusable assets; developers, to determine the effort to implement the features and
manager, to define the organizational goals, are the roles most relevant into of the
context of SPL Scoping.
68
ESELAW’09
4.5. Cost Models and Metrics
Analyzing the eleven studies, we identify that the lack of metrics is an aspect in the
majority of the approaches. Information as effort and costs of the product line are
attributes do not measurement by the majority of them and when are, in general, it is
made across of estimative of experienced stakeholders.
Among the analyzed studies that define metrics are: I. [Schmid 2002], where is
achieved business goal operationalization to define metrics, as for example, metrics
which determine the cost of implementation of a specific feature. It is performed based in
the top-down approach that was derived from the GQM approach [Briand et al. 1996],
[Schmid 1999]. With this approach is possible to define a simplistic model to express the
desired business objective as the result of properties of the features and products, in a
way that can be determined by the experts; II. [Park and Kim 2005], where are used cost
metrics to analyze economical value of the core assets. Besides, in the analysis of the
scope economical value are considered the variability and also dependencies among it.
With this approach is possible to identify the economic impact which each asset has on
the SPL; III. [John et al. 2006], in this study the quality models measure economic
factors such as effort and risk. Thus, the assets which maximize the economical return
can be prioritized; and IV. [Inoki and Fukazawa 2007], where metrics which evaluate
levels coverage and consistency are used. The level of coverage is a quantitative measure
that describes to what degree elements of core assets are prepared. It considers returns
of investment and should be adjusted depending of the conditions of an organization.
This metric determines if an asset should be reused in various products. The level of
consistency is a qualitative measure of all core assets; it describes the consistency of all
core assets in a product line. Core assets with a high level of consistency do not
contradict each other.
The use of metrics can be an effective way to optimize scope and to determine
the costs associated with the SPL. In this context, GQM has if showed the way most
used by the organizations, because it makes possible align the scope to the business
goals, considering the views of different stakeholders of a SPL project.
4.6. Scoping Customization
[John and Eisenbarth 2009] highlight that applying scoping in practice, it should be
customized to the concrete situation and activities, and representative stakeholders,
artifacts generated and the execution time for the tasks can change according to several
factors, such as: resources, organizations factors, size of the team, domain
characteristics, available assets and so on.
Among the approaches analyzed in this review, only the PuLSE Scoping Process
[John et al. 2006] defines customization factors which are adaptable for the context.
These factors are grouped in five categories: I. operational context, related with project
and organizational constraints; II. domain characteristics, related to domain complexity;
III. integratable artifacts, this category identifies the existence of artifacts relevant for
scoping; IV. enterprise context, this category is related with the structure and maturity of
the organization; V. resources, related with the knowledge of the stakeholders and
resources available for scoping definition. However, this approach does not define an
activity set associated for each situation. The current scenario shows that is necessary a
framework, which indicates specific activities, stakeholders and artifacts for different
projects, driving the organizations in the application of scoping.
69
ESELAW’09
4.7. Agile Planning of SPL
An important research area which is being investigated by the communities of SPL and
Agile is the join between SPL and Agile Methods (AM). Product lines and AM offer
similar benefits, both aiming reduction of time-to-market and development costs and
increase of quality. In addition, as cited in [McGregor 2008] considering the similar
goals and the differing perspectives of each method, when blending their tasks, has
allowed organizations effectively to deploy hybrid methods that are agile and yet assetbased at the same time.
According to Noor [Noor et al. 2007] the union between SPL and AM can
increase the potential of the organizations and open new markets for it. In this research
area, there is only one approach related to scoping [Noor et al. 2007]. This approach
makes agile planning, combining agile principles and practices, collaboration engineering
and PuLSE Eco [Schmid 2002]. The goal of the approach is to define a product map
which prioritizes features, domains and product with active participation and
collaboration among the stakeholders. However, in general, this approach does not use
all the potential which AM can offer, presenting as agile characteristic most relevant the
collaboration among the stakeholders. Finally, this approach was validated in only one
industrial project and the lack of approaches which address agile aspects in SPL scoping
make difficult to create a comparative and to judge the agility of the approach.
4.8. Scoping and SPL Development
The activities and results of scoping can have direct influence in the SPL development.
However, the majority of the approaches do not offer support well-defined for relation
between scoping and the development steps.
In general, the approaches define tasks for product lines started from the scratch.
Among the studies analyzed, only [Riebisch 2001] treat clearly the results of scoping as
basis for further development steps. In this study, three cases which relate scoping with
the development stage of the SPL are discussed: development from scratch; when it is
started from scratch using as basis existents products; and when the SPL is in evolution.
It considers priority levels for features implementation using decision tables. According
to the priority levels, in which the features are and with the development stage, the
features can be implemented or not.
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
6. Concluding Remarks and Future Work
Scoping is the initial phase of the SPL where is performed the planning, defining the
products which will integrate the product line, its features and the costs related with the
SPL.
As widely discussed along of this paper, the main purpose of this systematic
review was to understand how SPL scoping is being considered by the available
approaches. At the end of the review, we identified that the majority of the approaches
do not discuss the activities systematically and the guidelines for their applications are
described in high- level. Other important issue is that the optimization of SPL scoping is
partly addressed by the approaches, and there are not techniques or activities related
with domain optimization. Besides, in general, it does not consider the domain
according to its relation with business goal and assets costs. Other finding was that
among the approaches which define stakeholders, the main ones defined were:
managers, customers, developers and architects. In addition, the lack of metrics is an
aspect presents in the majority of the approaches and only one of it defines
customization factors for aligning scoping according to the context. Moreover, only one
approach considers the integration among SPL and AM, but it does not explore all
potential which AM and SPL can have. Finally, we identified that the approaches define
tasks for product lines started from the scratch and do not treat clearly the results of
scoping as basis for further development steps.
On the other hand, the main challenges identified are related with the following
questions: I. How to maximize the potential of union between product lines and agile
methodologies in scoping? II. How to customize scoping in SPL? III. Which techniques
can be used to optimize scope? and IV. How the approaches combine scoping with SPL
development? These questions have good potential of research and can be used as basis
for new approaches of SPL scoping.
In addition, the effort and quality of the review present an important result that
can be used as background information for scoping researches and companies that use
SPL or are planning to adopt it, since it presents a important view of the state-of-the-art
in scoping approaches, showing how scoping is addressed by the approaches.
As future work, we are intended to create an agile SPL scoping process
considering the best practices, gaps and main challenges identified in this review, with
focus on the insertion of agile principles, practices and techniques in each scoping
activity. Additionally, we invited the community to access our systematic review website
in providing us feedback.
References
America, P., Thiel, S., Ferber, S. and Mergel, M. (2001) “Introduction to Domain Analysis”,
ESAPS Project.
Briand, L., Differding, C. and Rombach, D. (1996) “Practical Guidelines for MeasurementBased Process Improvement”, In: Software Process Improvement and Practice Journal.
Clements, P. and Northrop, L. (2001) Software Product Lines: Practices and Patterns, Addison
Wesley.
Clements, P. (2005) Software Product Lines – SEI Framework.
Clements, P. and Northrop, L. (2007) “A Framework for Software Product Line Practice”,
version 5.0. technical report, SEI.
71
ESELAW’09
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.: AddisonWesley.
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
!
"
"
%
#$
&'
(
%
"
!"#$% &"$'$(#$$
'
&
"
)* % +
,
/. )
*
)
/)0/.
-.
/) % +
% /.
[email protected], [email protected], [email protected]
!"
#
!$
%
%
%
%
%
%
%
&
%
'
()
()
%
,
+
"
)
()
%
)
()
(*
'
'
/
.
() $
%
%
()
&
()
0
'
%
%+
1 2
)
3
/ 3
1)/
5
4
2
5
7
###:
;
8
2
5
1)/ =
7
2
81
?
5
1 6 * 4 '$$>:
;
5
9
6
2
<
1)/
5
. 5
(
7
%
@
4
73
4 @
ESELAW’09
?
7
1)/
-.
7
<
7
.
-.
D
7
2
5
C
7
E
F
G
5
C
•
@
•
@
•
-.
H
2
2
7
9
;
B
2
-.
-.
-.
5
.
% %
. .
6
%
A
%
3
KI 6
A
3 6 L
(
5
5
.M
(
5
A
.M
5
(
@
?
6 -.
2
5
N
H
-.
)
L
M
M
)
-.
'$$>:
C
2
2
'$$!:A
(
.
@
2
7
1)/
89IJ
2
. ;
6
. ;
6
@
A
2
;
?
-. ?
81
)?
1 6 * 4 '$$>:
;
-.
,
-.
@
8 2
;
5
*
(
)? 5
##": 9
6 -.
=
=
,
;
2
.
;
8O 6
5
-.
)?
1)/
;
6
6
2
=
3
2
5
4
( (
4 =
2
.
-.
.
;
7
5
.
;
A
4
-.
-.
/ -. '
/ -. Q
/ -. P
)
.
.
;
5
.
4
-.
8O 2 2
-.
.
7
1)/ ? =
4
2
-R
6 -.
)?
A
.
)
2
74
6
C
6
-.
'$$P:
2
ESELAW’09
*+
,
"
.
4
=
O 2 2
'$$P
'$$! ?
2
+
R
2
4
)
-.
-.
(
.
6 '$$#
B<
- ,
? 4
-.
.
/
0
5
A G
;
A
5
•
G
. )
•
G
. /
C
. /
•
G
•
G
;
1)/
5
1)/4 =
=
-.
-.
.
1
;
,
1)/
-R
. )
•
G
•
G
. /
C
. /
(
G
12
T
S
,
1)/S
=
,
S
R
.
A
1)/
A / -R
-.
'A )
QA
1)/
5
6 -.
1)/
6
0
)?
=
1)/
5
(
!
-.
;
5
)
,
4
K
A
5
K
2 A
7 M)
7
)?
6
3
2
)?
0
2
. /
•
A
A K;
5
( 2
5, A
•
.
6 -.
1)/S
-.
•
)?
6
-.
5
G
;
6 -.
1)/
.
•
)?
-.
-.
'A G
)?
QA G
. /
6
2
R 5
-.
"
-.
H
H
,
,
5
2
.
=
U
/
7
-R
75
ESELAW’09
•
)
E 2
A E
F
( 2
-
E)
!$
-
%
2
%
1
() $
%
5
2
%
F
F
,
!
1
%
%
$
!
$ 2
.
.
1$
()
$
$
2 $
-.
( 2
K
T
?
2
;
.
7
4
(5
9
5
-.
2 5
2
;
5 R
5 R
.
2
6
5
7
;
5
,
A
)
C
!
-R
!
1
-
F
E
-. ?
7
2
.
.
= 7
;
2 5
= .
;
*+
%+"
.
6
7
'$$& 4 2
'$$&
6
5
2
6
)
4 2
'$$#
5
T
2
2
5
6
2
4
. ?
2
R
T
6
'$$#
7
%
4 -R
.
-R
( 2
;
5
-.
;
5
= .
(
.
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 productfamily 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
-R
%
D
76
6
5
ESELAW’09
%
6
.
5
5
9
-.
5 ""
#
-.
$
5
?
5
&"
2
4 &"
=
P>
T
7
-. ;
2
5
2
2
PQV
7
-.
7
'$'
2
"$V
1)/
6
)?
T
-.
= 7
""V
'QV
-.
;
5
Q$V
Figura 1. (a) Estudos incluídos na revisão classificados por fonte; (b) Classificação dos estudos selecionados.
6+
?
@
2
B<
.
2
(
6 '$$# T
)
-.
1)/
-.
;
A
6
)?
5
5 .
6 -.
.
=
5
6
.
=
-.
5
2
R
4
;
2
=
7
2
6
K
=
5
.
2 5
Q
5
7
(
-.
-.
-.
1)/
77
)?
7
ESELAW’09
•
74- 8
- AG
2
;
5
4
?
T?
;
(
4
8 6
;
=
3
?
8
+
-.
I '$$>:
'$$P:
•
A
-.
2
6 -.
1)/
•
-
- ,
-.
-
1)/
2
2
;
)?
-.
•
A
@
-.
-.
5
6
7--8 ,! 5
4
9
-.
5
6
,
)?
7
7
2
6 -.
.
;
@
/
- A
1)/ ;
-.
7
9
2
=
W
<
5
2
'$$#
R
)
-.
1)/
)?
6
-. *
;
5
-.
'$$"
-.
1)/
•
2
2
9 - A
-.
6 -.
-R
•
@
:
G
;
8O
T?
4
)?
2
6
'$$>:
-
;
7) ;;8
2
A
9
.
;
-R
1)/
4
R
)?
-.
8U 2
-.
•
5
7
'$$!:
0
2
) ;
5
-.
,
1)/
7
)?
1)/ 5
)?
6 -.
A
.(
5
7
.
6
%
1)/4 =
78
-.
ESELAW’09
•
-
)
%
1)/ ??
)?
-.
2
1)/
-.
5
5X
1)/
?
U
4
7
)?
1)/
@
1)/
?
7
6 -.
7
2
-R
-R
)?
%
-.
@
U
7
A
4
.
0
;
/
1
H
(
-.
WI
6
K
0B
5
2
5
'
. 9
(
;
)?
1)/
(
7
-.
2
)?
2
K
2
;
1)/
T?
6
2
7
'
.
.A
(
(
-.
5
@
2
1)/
*
)?
)?
3
5
R
)?
R
-. U
)?
(
2
)
=
<
5
5
6 -.
B
-.
-.
9
?
/
5
7
2
)?
,
1)/
@
-.
9
0
-.
-.
5
7
1)/
7
2
(
<
6 -.
7
P
.
P' PQ
<+"
-R
)?
??
/ 4
6 -.
<
.
.
-.
;
-.
1)/
6
)?
79
!
ESELAW’09
Tabela 1 – Sumário das Técnicas e Abordagens Selecionadas
'
3
-
(
'
Q
P
!>
"&
-
4
T?
)?
4
T?
)?
4
T?
)?
-.
)?
1)/ ??
-.
)?
1)/ ??
#
P
! > "
$ Q
'
&
# '$
' ''
'Q 'P '!
'>
R
-.
R
R
6
-.
-.
% 1)/ ??
/
-.
9.
/
/
/
9.
9.
/
9.
9.
9.
)?
/
9.
)?
)?
9.
9.
9.
9.
9.
9.
/
9.
/
9.
9.
9.
9.
9.
9.
9.
9.
9.
9.
9.
/
9.
)?
4
)?
4
4
)?
)?
-.
'"
1)/
@
'&
'#
Q$ Q
=
)?
)?
4
)?
Q'
%
5
2
1)/
)?
5
-.
Tabela 2 – Sumário dos Estudos de Caso Selecionados
'
QP
;
QQ Q> Q"
P Q! Q& Q#
P$
P
P'
PQ
PP
!
P! P>
3
-
=
2
2
@
@
U
4
-. C
.
(
.
%
(
9.
9.
9.
9.
9.
/
9.
9.
9.
5
4
-R
'$'
9
4
.
-R
H
1
9.
/
9.
9.
9.
/
9.
/
9.
0
;
/
/
U)1 7
=
-.
5 P>
'QV
(
5
%
.
6 -.
-R
( 2
(
6
.
( 2
(
R
6
5
2
H
%
7
5
5
;
4
<
=
5
.
5
7
4 -.
80
ESELAW’09
)
(
5
5
5
.
-.
(
2
5
7
4
(
-.
A
)?
C ;
1)/
-.
;
=
-.
.
;
5
;
5
=
5
/ 3
?
2
-R
-.
3
-
-.
-.
-.
R
5
=
,
-
6 -.
1)/
.
1)/
5
;
0
5
2
7
2
5
)? ;
-.
)?
2
7
1)/
)?
)?
-.
=
3
5
1)/
;
4
3
-
9
1)/
2
?
;
.
-.
)?
1)/
-.
-.
5
1
G
5
2 5
.
2
5
.(
5
T
5
K
5
(
1)/
C
)?
-.
.
-.
4
.
=
2
U
) K0
(/ /
>
/
A)
+
2
)
)
+
BM
3
I
'$$> EL 2
T
2 !2
U
)
9 3 Y Z 9Y /
) U M9
F K 2
)
9 2
1
F [ . '$ / 3
2 ) B I ###
B<
-.
[
MK
*
### E
S
)
!#%>&
/
IF
U W '$$! E/I
3
*K( />"#0$! ) / ( ?)) 0 T*B
T
3 Z
/ 3
)
1
I
6 K
'$$# E
*
. /
1)/
6
)? F * @ ;
81
9
ESELAW’09
0)* +
U 2
+
)
T
2 /
/ 23
F
2 #2
2 L Z2
'$$!
- /
W
/
2
(?
/ 3
)
)
O 6
3
/
/
([
O 2 2
K 2
O
6
BM
(?
19 / 'P
2Z
M
)
? 4 (?
B
##"
B)
B 1 6* *
[
F
?
)
6
)
?
M?
L
/ 3
Y Z
9IJ
KI 6 3 6 /
[
I
/ 3
)
/ 3
)
1
)
(1
%
I
*
B
(?
[
F
'$$" B . )
?
/ 3
) +
2
A ^^ / @
)
1
L
1
]
M1
B
2
??)
)
L Z2
)
I
(
(?
F
2
]
2
3 2T
'2
/ 3
*
B
3
I
O
(
U
)
'$$> L Z 2
'$$>
I
K '$$! E
S
/
M
2
T
'$$> E
6
F
2 &2
/. T
'$$> E
(1
L Z2
)
)
O '$$P E[
F
A )
T
/ '$$P
'"% Q>
/I
)
I
3F
% $P$$$ K
9 K
/
/
( O
K
1 O
0/ (
* 5
'$$>
/
F )
)
* 4 W '$$> EK2 *
2 !2
)
2 U)
1
'$$> )
?
2
O *
K 2 5
/ 3
*
2
M1
) U
K 2 5
O 3
U
1
I
)
)
/ 3
1
[
2 T
F
+ '$$P E)
*
K*0/ ($P$ O
U
%
/ 3
%9
2(
1
[
?
0\
'$$! E
T
/ 3
)
1
/ 3
)
1
'$$# E*
)
*
2
'$$#
U M1
B ##" E
333
(?
/ U/?TK
)
9 3
IF
2 #2
2 L Z2
T
)
'$$" E? 2
I
K 2 5
)
1
+
2
/ 3
/+ / '$$"
2
1
L Z2
(
1 (L /) '$$"
#( Q$
82
ESELAW’09
Uma Abordagem Visual para Auxiliar a Revisão da Seleção de
Estudos Primários na Revisão Sistemática
Katia R. Felizardo1 , Gabriel F. Andery1 , José Carlos Maldonado1 , Rosane Minghim1
1 Instituto
de Ciências Matemáticas e de Computação (ICMC) - Universidade de São Paulo
Caixa Postal: 668 – 13560-970 – São Carlos – SP – Brazil
{katiarf,gfandery,jcmaldon,rminghim}@icmc.usp.br
Abstract. This paper presents an approach that uses Visual Text Mining (VTM)
techniques and associated tool to support the reliability of inclusion and exclusion 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 Mineraçã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 adicional 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 relevante 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 propostas 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 revisã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 controlados, 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
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 relevantes (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 complementar a descrição [Kitchenham 2004].
Como mencionado anteriormente, a atividade de Revisão da Seleção procura evitar a eliminação de estudos relevantes, o que pode prejudicar consideravelmente o resultado 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
Pesquisas relacionadas ao contexto mencionado foram desenvolvidas por Malheiros et al.
[Malheiros et al. 2007], que sugeriram estratégias de VTM para apoiar a seleção de estudos primários. Os autores compararam o desempenho de revisores ao realizar a seleção
dos estudos efetuando apenas a leitura dos seus resumos com o desempenho ao utilizar
as estratégias sugeridas com o apoio de uma ferramenta de VTM denominada Projection
Explorer (PEx) [Paulovich and Minghim 2006].
Assim como o trabalho de Malheiros et al. [2007], este trabalho também faz uso
de técnicas de VTM e da PEx para apoiar o processo de revisão sistemática, no entanto,
enquanto o objetivo do primeiro é utilizar essas técnicas para realizar a seleção dos estudos, a proposta deste trabalho é utilizá-las para revisar a seleção. Além disso, as técnicas
de VTM utilizadas nesses dois trabalhos são diferentes.
Não foram identificadas outras pesquisas que utilizam técnicas de VTM com o
mesmo objetivo deste trabalho.
84
ESELAW’09
3. Abordagem Proposta e Aplicação em Situações Reais
A Projection Explorer - PEx [Paulovich and Minghim 2006] é uma plataforma genérica
de visualização de código aberto. A ferramenta disponibiliza diversas facilidades para
manipulação de textos e exploração de uma coleção de documentos com o uso de técnicas de VTM. De forma resumida, tem-se que a ferramenta faz uso do modelo espaço
vetorial para estruturar, comparar e calcular as distâncias entre os documentos. As distâncias calculadas são utilizadas por técnicas de projeções multidimensionais para gerar
um mapa de documentos, ou seja, uma representação gráfica da coleção de textos. Nesse
mapa, cada ponto (círculo), definido no espaço bidimensional representa um texto. Uma
vez gerada a visualização, a principal ideia é a possibilidade do usuário interagir com
o resultado, permitindo-lhe explorar, compreender e extrair informações relevantes dos
dados.
Nas Figuras 1(a) e 1(b) estão representados dois mapas de documentos gerados
pela PEx. Esses mapas representam os estudos primários analisados em duas revisões sistemáticas. Essas e as outras revisões utilizadas neste artigo são do domínio de Engenharia
de Software.
(a) Revisão sistemática 1
(b) Revisão sistemática 2
Figura 1. Mapas de documentos gerados com a PEx
A diferença de cor entre os pontos identifica a classe (incluído ou excluído) a
qual cada estudo pertence. Essas classes foram definidas com base na aplicação (por um
especialista no domínio de cada revisão) da estratégia tradicional de seleção de estudos
primários, leitura dos resumos ou textos completos e aplicação dos critérios de inclusão,
exclusão e qualidade. Nos mapas, os pontos vermelhos identificam os estudos excluídos
da revisão, e os azuis, os incluídos. Na revisão sistemática 1, representada na Figura 1(a),
foram incluídos 40 estudos e excluídos 77, já na revisão sistemática 2, representada na
Figura 1(b), foram incluídos 33 estudos e excluídos 205.
Partindo da criação e exploração visual de um mapa de documentos, a estratégia
sugerida aqui para revisar a seleção dos estudos primários analisados pode ser resumida
em dois passos principais: (1) primeiro, um algoritmo de clustering é aplicado sobre o
mapa de documentos compondo grupos de documentos altamente relacionados (similares) – para tal o algoritmo k-means [MacQueen 1967] foi empregado; (2) então, os agrupamentos resultantes são analisados, em termos dos documentos incluídos e excluídos
85
ESELAW’09
que os formam, a fim de encontrar inconsistências. Nessa análise, as possíveis configurações que um agrupamento pode alcançar, e as possíveis consequências para o processo de
reavaliação são:
• Situação (a): Cluster Puro – todos os documentos possuem a mesma classificação (todos incluídos ou todos excluídos). Esse caso não desperta inicialmente a
necessidade de uma reavaliação;
• Situação (b): Cluster Misto – documentos com classificação diferente. Esses casos são alertas ao revisor e os estudos ali agrupados, principalmente os que possuem classificação divergente da maioria, devem ser reavaliados seguindo o método tradicional; e
• Situação (c): Ponto Isolado – esses casos também são alertas ao revisor, sendo que
o estudo isolado, se classificado como incluído, deve ser reavaliado uma vez que
não possui semelhança com nenhum outro estudo.
Os mesmos mapas das Figuras 1(a) e 1(b) estão reproduzidos nas Figuras 2(a) e
2(b) respectivamente, porém com a identificação dos clusters e das situações que devem
ser detectadas segundo a abordagem descrita anteriormente.
Figura 2. Identificação das situações (a), (b) e (c)
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.
3.1. Recursos Baseados em Conteúdo
Os documentos (pontos) contidos no mapa gerado pela PEx são posicionados de acordo
com a similaridade entre seus conteúdos, conforme explicado anteriormente. A ferramenta também possui funcionalidades para modificar os atributos visuais dos pontos, por
exemplo, a cor, de modo a refletir propriedades dos objetos. Dessa forma, dois recursos
baseados nessas funcionalidades podem ser utilizados para apoiar a análise visual dos
clusters.
86
ESELAW’09
3.1.1. Histórico das Exclusões
O primeiro recurso prevê a criação de mapas de documentos baseados em conteúdo, contendo os estudos coletados e analisados na revisão sistemática, destacando por meio de
cores o histórico das exclusões, ou seja, os estudos que foram excluídos nas diferentes
etapas da seleção.
O mapa da Figura 3(a) representa o resultado da fase de Execução da revisão sistemática 3, contendo 49 estudos primários, 38 excluídos da revisão (pontos vermelhos)
e 11 incluídos (pontos azuis). Na Figura 3(b) o mesmo mapa de documentos da Figura
3(a) é reapresentado, mas agora colorido de acordo com o histórico das inclusões e exclusões. Os 16 pontos vermelhos representam estudos excluídos da revisão na primeira etapa
(apenas com a leitura do resumo); os 22 pontos verdes, os incluídos na primeira etapa da
seleção, porém excluídos na segunda (leitura completa do artigo); e os 11 pontos azuis,
os incluídos. Assim, pontos verdes e vermelhos, 38 no total, são documentos excluídos e
os azuis, documentos incluídos. No caso específico da revisão sistemática 3 foi mantido
contato com os revisores, que disponibilizaram o histórico, o que não ocorreu com os
demais exemplos utilizados neste artigo, retirados de publicações na literatura.
(a) Sem histórico
(b) Com histórico
Figura 3. Mapas de documentos referentes à revisão sistemática 3
Com a coloração por histórico é possível a formação de quatro tipos de clusters
mistos: (i) verdes e vermelhos; (ii) azuis e verdes; (iii) azuis e vermelhos; e (iv) azuis,
verdes e vermelhos.
Estudos em verde em conjunto com estudos em vermelho, apesar de mistos na
representação por histórico, equivalem a clusters puros (todos excluídos) e, portanto, não
precisam ser reavaliados.
Estudos em azul (incluídos) em conjunto com estudos em verde ou vermelho (excluídos) formam clusters mistos nas duas representações, com ou sem o uso do recurso
de histórico. Entretanto, considerando que os pontos azuis e verdes foram avaliados na
segunda etapa pela leitura integral do texto, apenas os clusters contendo pontos azuis e
vermelhos despertam a necessidade de reavaliação, pois representam estudos excluídos
já na primeira etapa, apenas com a leitura do resumo, similares à estudos incluídos, lidos
na íntegra. Por fim, clusters que contêm as três cores também devem ser reavaliados,
pois configuram a mesma situação mencionada anteriormente, ou seja, pontos vermelhos
87
ESELAW’09
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 especialistas, um mecanismo importante para embasar a decisão inicialmente tomada (e
mantida) de incluir ou excluir um determinado estudo primário da revisão.
3.1.2. Classificação da Qualidade dos Estudos
O segundo recurso é similar ao primeiro, mas ao invés de colorir o mapa com base no histó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.
(a) Excluídos e incluídos
(b) Classificação de qualidade
Figura 4. Mapas de documentos referentes à revisão sistemática 4
Nessa revisão a qualidade atribuída pelos revisores refletiu o conteúdo da maioria dos artigos, o que é possível observar na concentração de artigos de maior qualidade
(Q1 a Q3, em uma escala de 1, maior qualidade, a 7, menor qualidade) no canto superior
do mapa (todos incluídos). No entanto, não é possível afirmar que estudos com poucos
detalhes na escrita são de baixa qualidade, isto porque não se pode assumir que algo não
reportado não tenha sido feito [Kitchenham et al. 2007]. Uma situação interessante foi o
caso destacado como (1) na Figura 4(b), ou seja, um artigo excluído (vermelho) similar a
um incluído de qualidade Q7. Nesse caso, duas situações são possíveis e devem ser avaliadas: (i) o estudo de qualidade Q7 omitiu detalhes e, portanto, mais informações devem
ser obtidas com os autores desse artigo para assegurar a sua inclusão; (ii) o estudo possui informações suficientes e, portanto, sua inclusão é questionável. Assim, fica evidente
que os critérios de qualidade proveram mais detalhes do que apenas os fornecidos pelos
critérios de inclusão e exclusão.
3.2. Recurso Baseado em Rede de Citações
Como mencionado anteriormente o conteúdo dos estudos primários pode não refletir a
sua qualidade. Assim, é possível utilizar outras opções para visualizar esses estudos, de
88
ESELAW’09
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 referê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 (revisores). 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 palavraschave 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 classificados 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.
Figura 5. Redes de citações das revisões 5 e 6
Foi possível visualizar na rede de citações da Figura 5(a) que a maioria dos artigos 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 pontos 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
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 igualdade. 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.
(a) Mapa de documentos
(b) Rede de citações
Figura 6. Coordenação: mapa e rede de citações da revisão sistemática 5
Figura 7. Coordenação 1: mapa e rede de citações da revisão sistemática 6
90
ESELAW’09
O uso da técnica de coordenação por igualdade permitiu identificar que o artigo
incluído que não possui nenhuma referência na revisão sistemática 6 (ponto azul mais
abaixo na Figura 5(b)) é similar a vários outros estudos excluídos da revisão. A Figura
7 apresenta esse cenário, sendo que na Figura 7(a) está exibido o mapa de documentos
dessa revisão sistemática e na Figura 7(b) a sua respectiva rede de citações.
A Figura 8 apresenta outro exemplo de coordenação por igualdade da revisão 6.
Essa coordenação revelou que um estudo que foi incluído, mas que aparece isolado no
mapa de documentos, ou seja, sem similaridade com os demais estudos (Figura 8(a),
ponto mais à direita), na verdade possui muitas referências em comum com outro estudo
também incluído (Figura 8(a), ponto azul ao centro). Esses dois estudos estão destacados
na rede de citações da Figura 8(b).
Figura 8. Coordenação 2: mapa e rede de citações da revisão sistemática 6
4. Resultados Obtidos e Trabalhos Futuros
A abordagem sugerida disponibiliza mecanismos de interação que possibilitam ao revisor
uma melhor compreensão dos estudos primários analisados em uma revisão sistemática.
Utilizando a abordagem, é possível combinar diferentes técnicas de VTM para
apoiar o revisor na tarefa de reavaliar os estudos primários, tanto as baseadas em conteúdo
(classificação por histórico e qualidade) como em redes de citações (coordenação por
igualdade), todas disponibilizadas na PEx.
A abordagem é uma combinação de recursos para convalidar ou alertar sobre a
decisão de incluir ou excluir um estudo primário da revisão sistemática e, principalmente,
garantir que não foram eliminados estudos relevantes.
Os resultados obtidos com a aplicação das técnicas de VTM demonstraram que
as mesmas fornecem subsídios para facilitar a solução de divergências entre os revisores,
quando a revisão é executada em conjunto. A visualização pode confirmar a decisão de um
dos revisores, por exemplo, incluir um estudo de classificação divergente, caso o mesmo
seja similar a vários estudos incluídos, ou que possua muitas referências em comum com
outros também incluídos.
No caso das revisões executadas individualmente as técnicas eliminam a escolha
91
ESELAW’09
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 medidas 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 intermediaçã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 multidimensional 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 review 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 withincompany 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 Berkeley 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 document 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
Granularity on Persistent Data Flow Testing of Active
Database Applications
Plinio S. Leitao-Junior1 , Plinio R. S. Vilela2 , Mario Jino3 , Joao C. Silva1
Instituto de Informática – Universidade Federal de Goias (UFG)
Campus Samambaia, Caixa postal 131 – 74001-970 – Goiania – GO – Brazil
1
Universidade Metodista de Piracicaba (UNIMEP)
Rodovia do Acucar, Km. 156 – 13400-911 – Piracicaba – SP – Brazil
2
Universidade Estadual de Campinas (UNICAMP)
Avenida Albert Einstein, 400 – 13083-970 – Campinas – SP – Brazil
3
{plinio,jcs}@inf.ufg.br, [email protected], [email protected]
Abstract. Active databases have been traditionally used as an alternative to
implement persistent data requirements of applications on several knowledge
domains. Their principle is the activation of tasks with specific functionalities as
a response to events. These reactive abilities are generally expressed with active
rules defined within the database itself. We investigate the use of data flowbased testing to identify the presence of faults in active rules written in SQL.
Our research is based on the precision of data flow analysis, also named as data
flow granularity, aiming at comparing different granularities and preliminarily
evaluating their fault-revealing effectiveness. This analysis has an important
impact on the cost of database application testing. The results point to higher
granularities do not improve the fault detecting ability.
1. Introduction
Data persistency is an attribute associated to the demand for non-volatile data. Applications 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 organizations [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 testing 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 systematic 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 developers [Fortier 1999, Elmasri and Navathe 2006]. The use of relational databases has
94
ESELAW’09
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 appropriate 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 application’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 investigation 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.
2. Active Rules in SQL
Active rules in SQL, called triggers, are activated by a database state transition. The
source of events is limited to operations on the database structure, specifically a relation
state transition. The rule condition consists of any SQL predicate, including sub-queries
and user defined functions [Kulkarni et al. 1998]. Baralis et al. [Baralis et al. 1998]
present the event-condition model for triggers. Three components make up the model:
i) the event set: the set of data manipulation operations being monitored; ii) the condition: a predicate that references the current database state and the rule transition values;
and iii) the action: a sequence of data manipulation operations. The transition values
associated to a given active rule execution are transient data that are being inserted, updated or excluded by the event operation. Figure 1 presents the syntax for the creation of
a trigger, according to Kulkarni et al. [Kulkarni et al. 1998].
The production <trigger action time> – Figure 1 – determines whether the rule
will be triggered before or after the event operation acts on the database. The production <trigger event> defines the type of state changing operations that cause the rule to
be triggered. The clause FOR EACH { ROW | STATEMENT } specifies whether the
rule is triggered for each event occurrence or for a set of event occurrences. The production <search condition> does not include state changing operations, differently from the
production <triggered SQL statement>; the dispatch between triggers, not necessarily
distinct, can occur only from the action rule execution, not from the condition rule evaluation. If the execution of the action rule causes the event of another rule, the execution of
the former is interrupted and the control is given to the latter.
95
ESELAW’09
<trigger definition> ::=
CREATE TRIGGER <trigger name>
<trigger action time>
<trigger event> ON <table name>
[ REFERENCING <old or new values alias list> ]
<trigger action>
<trigger action time> ::= BEFORE | AFTER
<trigger event> ::= INSERT | DELETE | UPDATE [ OF <column name list> ]
<old or new values alias list> ::= <old or new values alias>
<old or new values alias> ::=
OLD [AS] <identifier> |
NEW [AS] <identifier |
OLD_TABLE [AS] <identifier> |
NEW_TABLE [AS] <identifier>
<trigger action> ::=
[ FOR EACH { ROW | STATEMENT } ]
[ <trigger condition> ]
<triggered SQL statement>
<trigger condition> ::=
WHEN <left paren> <search condition> <right paren>
<triggered SQL statement> ::=
<SQL procedure statement> |
BEGIN ATOMIC
{ <SQL procedure statement> <semicolon> }
END
Figure 1. Syntax of trigger creation.
The notation ri (ei , ci , ai ) indicates that the rule ri is described by event ei , condition 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, respectively, 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)
FOR EACH ROW
DECLARE NUMBER X;
BEGIN
SELECT COUNT(*) INTO X
FROM PendingOrders
WHERE Part = :New.Part;
IF X = 0 THEN
INSERT INTO PendingOrders
VALUES (:New.Part, :New.OrderQuantity, SYSDATE);
END IF;
END;
3
4
5
6
7
(a)
(b)
Figure 2. Example of an active rule in SQL: (a) source code (b) control flow graph.
3. Persistent Data Flow
The data flow in manipulation commands is characterized by: definition, use and usedefinition. The first is the result of the execution of the insert command; the second
corresponds to the execution of the select command; and the last one is the result of
the execution of the update and delete commands. Data flow of implicit operations
are also considered; for example, the opening of a cursor is a persistent data use.
The ddef notation represents persistent data definitions: ddef(i)={variable v —
v is a database variable defined in node i}. The definition of a persistent variable is a
96
ESELAW’09
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).
4. Granularity on Persistent Data Flow
To define the data flow associations created from the database usage we should decide on
a level of granularity of the database variables in which we can trace their definition and
their later use [Daou et al. 2001]. The granularity, also called data flow analysis precision, determines the rigor of data flow analysis and defines coverage levels for persistent
data flow relations. According to Kapfhammer and Soffa[Kapfhammer and Soffa 2003]
the granularity levels are: database, relation, attribute, tuple, and attribute value.
At granularity level relation persistent variable are mapped to database relations,
no matter which tuples or attributes had been affected by manipulation operations. This
approach easy the analysis and reduce the number of variables, since it considers each
relation as a single variable. Nevertheless establishes a conservative approach, since every
variable definition followed by a variable use is a data flow association, regardless of
which data they are manipulating.
At granularity level attribute the definition occurrences and uses of relation attributes are explored, with no concerns of which tuples have been manipulated. It is more
precise then the relation level, since it differentiates the attributes at each relation. Data
flow associations can be characterized when the intersection of the two sets of manipulated columns, the definition occurrences and the use occurrence, are not empty. An
advantage of this approach is that the number of columns in a relation is fixed and their
occurrences of definitions and uses are statically identified. Daou et al. [Daou et al. 2001]
set forth a strategy to the regression testing of database applications and use the granularity at the column level to determine the database modules affected by modifications in the
database component definitions.
The granularity level tuple is used when a refined data flow analysis is necessary
to determine the affected tuples in each data manipulation operation. Generally, statically
determine which tuples are affected by a data operation is not possible, due to the complexity that can be reached by the line selection predicates [Vaduva 1999] and the current
database state. In a relational database a tuple, in general, represents a real world entity, an association among entities or some particular aspect of an entity. So use the line
granularity level means reach the real world entities manipulated by database operations.
The database and attribute value granularity levels represent two ends of data flow
analysis precision. The former considers the whole database as a single variable and the
97
ESELAW’09
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> established 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 testing 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 persistent 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.
5.1. Experiment Design
The experiment applied a family of adequacy testing criteria, called Interaction Between
Active Rules based Criteria, defined in [Leitao-Junior et al. 2008]. The complexity of
testing requirements can be used to derive their application cost; it is defined as the number of required test cases in the worst case, even so in practice this situation is unlikely to
occur. Although Interaction Between Active Rules based Criteria are an extension to AllUses criterion, in which the worst case scenario is a function of control flow structures,
their complexities are indexed by manipulation operations that possess both definition and
use of persistent data, such that SQL command update.
98
ESELAW’09
A four-rule set of SQL rules, named as Rx , which has 74 interaction associations,
was applied to the Oracle database management system. The Oracle system has been frequently used by the academic community [Daou et al. 2001]. This approach could be extended to others systems, such as SQLServer, DB2, SyBase, M ySQL, and Inf ormix.
Versions of the rule set Rx were built by seeding one fault for each version. The
manipulation fault type list introduced in [Leitao-Junior et al. 2005] was used to derive
26 faulty versions of Rx , aiming at testing them by applying Interaction Between Active
Rules based Criteria. The set of manipulation commands in Rx in which their execution
can cause persistent data flow of interaction associations was targeted during the seeding
of faults. The SQL manipulation command and the fault type were selected randomly for
each faulty version in order to avoid bias in fault seeding.
All faulty versions were tested at granularities relation, attribute, tuple, and attribute value, in order to observe whether higher data flow analysis precisions improve
the fault-revealing ability. Test data were generated for each faulty version, aiming at
exercising all interaction associations at each granularity. The triggering commands were
elaborated to cover all event rule operations of Rx . The generation of testing database
was based on [Ostrand and Balcer 1988, Chays et al. 2000]: basically, the tester provides
a list of values that are conceptually different for each database attribute, according to
its domain, which are combined to derive insertion commands to database relations; the
commands in which execution does not satisfy any database integrity constraints are discarded.
5.2. Experiment Application
All rules of Rx were enabled for triggering before the application of each test case; this
establishes the real operation of Rx . The execution of the faulty rule was not isolated, and
the triggering between rules could occur in a chain.
The experiment application was supported by a tool, called ADAPT-TOOL – Active Database APplication Testing TOOL for active rules written in SQL – that was developed aiming at the automation of Interaction Between Active Rules based Criteria. The
tool builds a database testing using relational model structures, and focuses on the following functions: test data generation, control of rule set faulty versions, application (and
re-application) of test cases, testing oracle, and evaluation of test case sets by granularity.
5.3. Analysis of the Results
Table 1 shows the summary of 632 applications of test cases. The data table relate the
number of test cases, presenting values of interaction association coverage per granularity,
and of raised exceptions. The columns are labeled (I), (II), and (III); lines are labeled
(a) to (j). Columns (I) and (II) distinguish fault-revealing and non fault-revealing test
cases, respectively; column (III) refers to all test cases, sum of columns (I) and (II).
Line (a) refers to test cases that did not exercise the faulty node. Test cases that exercised
the faulty node but covered no interaction association are summarized in line (b). Lines
(c), (d), (e), and (f ) synthesize test cases related to interaction association coverage at
granularities relation, attribute, tuple, and attribute value, respectively. To understand
how the values in lines (c) to (f ) were computed, consider the cell (I : d), column (I)
and line (d); it states the number of fault-revealing test cases to the granularity tuple,
99
ESELAW’09
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 granularity 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 )
(III : c) + (III : d) + (III : e) + (III : f )
(1)
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. Computing 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 precision.
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 faultrevealing. 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
The raised exceptions were traced in order to help the oracle role. From faultrevealing 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 occurrences usually can cause the loss of database transactions, eliminating the instrumentation data.
The demonstrated effectiveness is an initial empirical evidence. Additional studies 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.
5.4. Threats to Validity
Although the seeded faults were not collected from real software projects, they are representative of real fault types, according to Leitao et al. [Leitao-Junior et al. 2005]. Even
then the replication of this study with real fault data is desirable.
A threat is related to the fact that the experiment uses only one set of rules, with
several different versions. To compensate this approach the set has several interaction
points, which makes its behavior very complex at run time. Such interaction points, specially the triggering between rules, result in some cases on the execution of more than a
thousand nodes, increasing the chances of unexpected or incorrect behavior.
Another limitation is related to the artificial seeding of faults, that are unique in
each version of the rule set, in spite of the random selection of manipulation occurrences
and of fault types. In practice it is observed that faults do not occur in isolation, defective
programs will in general have more than one fault at the same time. We have to point
out that a secondary goal of this empirical investigation is to evaluate different data flow
granularities to detect the presence of faults. The isolation of faults allow a finer level of
control when analyzing the influence of each granularity in the detection of each fault.
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 execution 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
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,
Suá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 activities 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 addition 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 coverage of interaction associations at higher granularities does not improve the fault detecting
ability; fault-revealing and non fault-revealing scenarios were identified at every granularity level.
The realization of new empirical studies is desirable, since several factors are involved 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 Analysis 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 Applications (CODAS’99), pages 364–375.
Chays, D., Dan, S., Frankl, P. G., Vokolos, F. I., and Weyuker, E. J. (2000). A Framework 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
Clarke, L. A., Podgurski, A., Richardson, D. J., and Zeil, S. J. (1989). A Formal Evaluation 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 Applications. 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. SpringerVerlag.
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 Conference 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 SQLbased 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 information. IEEE Trans. Soft. Eng., SE-11(4).
Suá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, University 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
Redução de Potenciais Defeitos através da Detecção de
Anomalias em Diagramas de Classes
Isela Macía, Arndt von Staa
Departamento de Informática – PUC-Rio – Rio de Janeiro – RJ – Brazil
{ibertran, arndt}@inf.puc-rio.br
Abstract. This paper defines strategies to assist the identification of flaws
related to inter-dependencies between classes and packages that can be
observed in class diagrams. The flaws described in this paper are Shotgun
Surgery, God Package and Misplaced Class. The accuracy, precision and
recall of the proposed strategies were evaluated and compared to the
measurements of similar flaws made at code level by means of an experimental
study. The study showed that two of the three proposed detection strategies God Package and Misplaced Class - yield very close results to published
detection strategies applied to code, hence are good predictors at the design
level.
Resumo. Este trabalho define estratégias para detectar anomalias associadas
com interdependências entre classes e pacotes e que podem ser observadas em
diagramas de classes. As anomalias descritas neste artigo são Shotgun
Surgery, God Package e Misplaced Class. A acurácia, precisão e recall das
estratégias propostas foram avaliadas e comparadas, por intermédio de um
estudo experimental, com medições feitas aplicando estratégias similares no
correspondente código. O estudo mostrou que a detecção no modelo de duas
das três anomalias analisadas - God Package e Misplaced Class - produz
resultados muito próximos aos obtidos por estratégias publicadas de detecção
no código, constituindo, portanto, bons preditores no nível de projeto.
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
antes de se iniciar o desenvolvimento do código [Pressman, 2001; Sapsomboon, 2002;
Brykczynski et al., 1994]. Embora existam trabalhos que definem métricas em
diagramas de classes e diagramas de estados [Genero et al., 2001; Genero et al., 2002;
Zhou e Baowen, 2002] e ferramentas como [SDMetrics, 2008; MetricView, 2005] que
automatizam a aplicação destas métricas, esses trabalhos possuem uma série de
limitações. Dentre elas encontram-se: (i) eles não provêem suporte para identificação de
anomalias de modularidade forçando ao projetista ter que exaustivamente inferí-las a
partir de uma extensa inspeção do conjunto de valores “anormais” de métricas, (ii)
atributos externos da qualidade não são estimados a partir de quantificações das
propriedades do design (tamanho, acoplamento, entre outras).
Uma primeira iniciativa de definição de estratégias para a detecção de
anomalias, recorrentes na literatura, em modelos é [Macia et al., 2008]. Nesse trabalho
adaptamos duas estratégias para a detecção de Data Class e God Class e desenvolvemos
uma ferramenta para apoiar sua aplicação automatizada. As medições realizadas a partir
dos modelos foram confrontadas com medições realizadas a partir do código e
mostraram uma forte coerência. Ou seja, os resultados obtidos naquele trabalho
mostraram que essas estratégias propostas podem ser utilizadas como ajuda aos
projetistas para evitar anomalias de design antes da criação do código. Porém, anomalias
mais complexas, envolvendo interdependências múltiplas, devem ser exploradas em
modelos.
Neste trabalho definimos um conjunto de estratégias para a detecção de
anomalias de design no contexto de modelos UML, especificamente em diagramas de
classes (Seção 3), visando complementar as estratégias definidas em [Macia et al.,
2008]. Essas anomalias estão associadas com interdependências indesejáveis entre
classes e pacotes. Mais especificamente, adaptamos para modelos as estratégias
definidas por Lanza & Marinescu (2006) para detecção no código dos problemas de
design chamados de Shotgun Surgery, God Package e Misplaced Class [Fowler et al.,
1999]. Além disso, realizamos um estudo experimental para verificar a acurácia,
precisão e recall dessas estratégias aplicadas a modelos (Seção 4). Os resultados do
estudo são discutidos na Seção 5. Esses resultados mostraram que as estratégias
propostas podem antecipar anomalias de design encontradas posteriormente na etapa de
geração de código. Finalmente, a Seção 6 apresenta conclusões e trabalhos futuros.
2. Estratégias para a Detecção de Anomalias de Design em Código Fonte
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
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),
em que: a métrica NOED (Number Of External Dependencies) conta o número de
classes de outros pacotes das quais a classe avaliada depende, (ii) a métrica CL (Class
Locality) conta a porcentagem de dependências que uma classe tem em seu próprio
pacote em relação ao total de dependências que ela possui, e (iii) a métrica DD
(Dependency Dispersion) representa o número de outros pacotes dos quais a classe
avaliada depende. Os detalhes de implementação e as referências originais dessas
métricas podem ser encontrados em [Lanza & Marinescu, 2006].
3. Estratégias para a Detecção de Anomalias de Design em Modelos UML
Com o objetivo de antecipar a detecção de anomalias de design desde os modelos do
sistema, adaptamos um conjunto de estratégias de detecção - Shotgun Surgery, God
Package e Misplaced Class - a fim de permitir que elas sejam aplicadas em diagramas
de classes. Diferentemente de [Macia et al., 2008], neste trabalho nos preocupamos com
a adaptação de estratégias que cobrem problemas de maior complexidade tais como
106
ESELAW’09
interdependências de classes e pacotes. As adaptações realizadas foram de dois tipos: (i)
mudança na forma de computar algumas métricas de modo que fossem consideradas
apenas informações disponíveis em diagramas de classes, e (ii) inclusão de métricas
para contornar a ausência de informações nos diagramas de classes.
Shotgun Surgery. As duas métricas usadas na estratégia de detecção de Shotgun
Surgery para código (Seção 2) – CC, CM – dependem de informações disponíveis
exclusivamente no código interno dos métodos, respectivamente, para determinar: (i) os
métodos que podem ser afetados por modificações na classe avaliada, e (ii) a quantidade
de classes em que são definidos os métodos possivelmente afetados pelas mudanças na
classe avaliada. Como essas informações não estão disponíveis em diagramas de
classes, tivemos que realizar adaptações para definir a estratégia de detecção de Shotgun
Surgery para modelos.
Primeiramente, na computação de CMadpt, passamos a considerar os métodos de
outras classes: (i) com parâmetros cujos tipos fazem referência à classe avaliada, e (ii)
que redefinem algum método da classe avaliada. Segundo, incluímos a métrica CA
(Changing Attributes) que representa a quantidade de atributos cujo tipo faz referência à
classe avaliada. Esta inclusão está apoiada pelo fato de que os atributos de uma classe
normalmente são acessados pelos métodos por ela definidos. Terceiro, no cálculo de
CCadpt, foram consideradas as classes que: (i) algum de seus métodos foi identificado
pela CMadpt, ou (ii) apresentam relações de associação ou dependência com a classe
avaliada. Dessa forma, a estratégia de detecção de Shotgun Surgery para modelos é
definida da seguinte maneira:
Shotgun Surgery := (CCadpt > τ) and (CMadpt + CA > η),
em que, as métricas CCadpt e CMadpt referem-se às métricas CC e CM adaptadas. Os
valores limites utilizados foram representados, respectivamente, pelos símbolos τ e η,
uma vez que estudos empíricos ainda precisam ser realizados para que se possam
determinar os valores que reduzam a freqüência de falsos positivos, sem no entanto
gerar falsos negativos que possam comprometer a qualidade do software. Além disso, a
escolha desses valores limites também depende das características do sistema que está
sendo analisado. Por ora, caberá ao desenvolvedor especificar quais valores serão
utilizados para parametrizar a estratégia de detecção.
God Package. Aqui três das quatro métricas utilizadas na estratégia de detecção para
código (Seção 2) – PS, NOCC, NOCP e PC – dependem de informações disponíveis do
código dos métodos para determinar o grau de dependência entre as classes e pacotes
nos diagramas de classes. Como essas informações não estão disponíveis em diagramas
de classes, tivemos que adaptar as métricas NOCC, NOCP e PC de forma a que elas
passassem a considerar apenas que uma classe depende de outra classe quando: (i)
existem relações de dependência, herança ou associação entre elas; e (ii) utiliza
informações por meio de declarações de atributos e/ou parâmetros. Uma classe depende
de um pacote quando utiliza alguma das classes definidas nele. Sendo assim, a estratégia
de detecção God Package para modelos é definida da seguinte forma:
God Package = (PS > τ) and (NOCCadpt > η) and
(NOCPadpt > δ) and (PCadpt <ζ),
em que, as métricas NOCCadpt, NOCPadpt, PCadpt, referem-se às métricas NOCC, NOCP
e PC adaptadas. Os valores limites associados às métricas PSadpt, NOCCadpt, NOCPadpt e
107
ESELAW’09
PCadpt foram representados utilizando, respectivamente, os símbolos τ, η e δ, de maneira
semelhante à estratégia Shotgun Surgery.
Misplaced Class. As três métricas usadas na estratégia de detecção Misplaced Class
para código (Seção 2) – NOED, CL e DD – dependem de informações disponíveis
apenas no código fonte para determinar: (i) quando uma classe depende de outra classe,
e (ii) quando um pacote depende de outro pacote. Ao realizar as adaptações nas métricas
NOEDadpt, CLadpt e DDadpt, consideramos os mesmos critérios utilizados na estratégia
God Package para determinar se uma classe depende de outra classe ou se depende de
um pacote. Sendo assim, a estratégia de detecção de Misplaced Class para modelos é
definida da seguinte forma:
Misplaced Class = (NOEDadpt > τ) and (CLadpt < η) and (DDadpt > δ),
em que as métricas NOEDadpt, CLadpt e DDadpt. referem-se às métricas NOED, CL e DD
adaptadas. Os valores limites associados às métricas NOEDadpt, CLadpt e DDadpt foram
representados utilizando, respectivamente, os símbolos τ, η e δ.
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.1. Definição do Estudo
Analisar: as estratégias de detecção propostas para modelos
Com o propósito de: avaliar
Com respeito a: sua precisão, acurácia e recall na identificação das mesmas anomalias
que suas correspondentes para código.
Do ponto de vista: do pesquisador
No contexto de: estudantes da pós-graduação do Laboratório de Engenharia de
Software da PUC-Rio.
4.2. Planejamento
O estudo supõe o processo off-line e apresenta ausência de randomização tanto na
seleção dos objetos quanto na seleção dos participantes. Em virtude da dificuldade de
encontrar sistemas desenvolvidos a partir de modelos, os nove sistemas envolvidos no
estudo apresentado em [Macia et al., 2008] foram utilizados para avaliar as estratégias
aqui propostas. Esses sistemas são: um framework para a geração de relatórios
estatísticos para o gerenciamento de incidentes (S1), um framework para o
gerenciamento de conteúdos (S2), uma linha de produto de software de locadora de
filmes (S3), um framework para a aplicação de métricas no código fonte (S4), QCDTool
108
ESELAW’09
[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 posgraduação na área de engenharia de software da PUC-Rio.
Tabela 1 - Características dos sistemas utilizados no estudo
Sistema
S1
S2
S3
S4
S5
S6
S7
S8
S9
Num. Pacotes
12
38
27
18
16
17
16
21
25
Num. Classes
61
102
110
96
150
172
332
313
401
Num. Métodos
513
529
898
459
679
1.438
3.117
3.251
3.986
Num. Atributos
142
218
194
248
459
363
361
735
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
Métrica
Valor Limite
CM + CA
10
CC
5
God Package
Métrica
Valor Limite
PS
20
NOCC
18
NOCP
3
PC
0,33
Misplacd Class
Métrica
Valor Limite
NOED
5
CL
0,33
DD
3
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
objetivos deste trabalho realizar os estudos empíricos necessários para ajustar os valores
utilizados.
4.4. Análise e Interpretação
No contexto deste trabalho, as medidas de acurácia, precisão e recall são definidas da
seguinte forma: a acurácia representa o grau com o qual as estratégias de detecção para
modelo classificaram as entidades no design de forma semelhante às suas homólogas
para código fonte. A precisão corresponde à proporção entre a quantidade de entidades
com anomalias identificadas pelas estratégias para modelo e pelas correspondentes para
código, e o total de entidades com anomalias identificadas no modelo. Finalmente, o
recall representa a proporção entre a quantidade de entidades de design com anomalias
identificadas pelas estratégias para modelo e pelas correspondentes para código, e o total
de entidades com anomalias identificadas no código. Para o cálculo destas medidas foi
necessário categorizar as entidades classificadas pelas estratégias em cada sistema da
seguinte forma: Falsos Positivos (FP), incluem todos os suspeitos revelados no modelo
que não foram detectados no código; Falsos Negativos (FN), referem-se a todas as
entidades que não foram classificadas como suspeitas no modelo, porém, foram
identificadas no código; Verdadeiros Positivos (VP), incluem todos os suspeitos no
modelo que foram detectados também no código; e Verdadeiros Negativos (VN),
referem-se às entidades não identificadas no modelo nem no código. Sendo assim, a
acurácia, precisão e recall podem ser calculadas da seguinte forma:
Acurácia =
VP VN
VP VN FP
FN
Precisão =
VP
VP
e Recall =
VP FP
VP FN
Os resultados da aplicação das estratégias de detecção nos sistemas avaliados estão
resumidos na Error! Reference source not found.3. A tabela apresenta os graus de
acurácia, precisão e recall das estratégias para modelos em cada um dos nove sistemas.
Tabela 3 - Resultado das estratégias de detecção propostas
Shotgun Surgery
Sistemas Acurácia
S1
S2
S3
S4
S5
S6
S7
S8
S9
96%
98%
95%
95%
98%
98%
98%
98%
99%
God Package
Misplaced Class
Precisão
Recall
Acurácia
Precisão
Recall
Acurácia
Precisão
Recall
100%
0%
0%
0%
0%
33%
100%
100%
100%
66%
100%
100%
100%
100%
100%
87%
85%
83%
100%
100%
100%
100%
93%
100%
100%
90%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
50%
100%
100%
33%
100%
96%
100%
100%
100%
100%
100%
97%
100%
100%
33%
100%
100%
100%
100%
100%
50%
100%
100%
100%
100%
100%
100%
100%
100%
50%
100%
100%
A estratégia de detecção Shotgun Surgery apresentou bons resultados de precisão
apenas nos sistemas em que os modelos foram gerados mediante engenharia reversa
(sistemas S7-S9). Nestes modelos evidenciou-se um aumento dos valores das métricas
CCadpt, CMadpt em relação aos outros modelos, acarretando uma quantidade maior de
verdadeiros positivos. Isso aconteceu porque, baseadas nas informações disponíveis
apenas no código fonte, as ferramentas de engenharia reversa podem gerar
relacionamentos entre entidades que normalmente não são incluídos pelos projetistas
110
ESELAW’09
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
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.
6. Conclusões e Trabalhos Futuros
Neste artigo apresentamos três estratégias de detecção para a identificação de anomalias
de design associadas com interdependências indesejáveis em diagramas de classes, com
objetivo de ajudar os projetistas a diminuir a quantidade de correções de defeitos em
etapas posteriores. A aplicação automatizada destas estatrégias de detecção foi apoiada
pela ferramenta QCDTool apresentada em [Macia et al., 2008]. Realizamos um estudo
experimental (Seção 4) para verificar o grau com o qual cada estratégia para modelos
detecta as mesmas classes que sua estratégia correspondente para código. Embora
preliminares, os resultados do estudo mostraram que a estratégia Shotgun Surgery
depende muito de informações disponíveis apenas no código fonte o que torna difícil
alcançar uma boa precisão na identificação dessa anomalia no modelo. As estratégias
112
ESELAW’09
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
Reutilização de Conjuntos de Teste: Um Estudo no Domı́nio
de Algoritmos de Ordenação
Diogo Nascimento Campanha1 , Simone do Rocio Senger Souza1 ,
Otávio Augusto Lazzarini Lemos1 , Ellen Francine Barbosa1 e
José Carlos Maldonado1
Departamento de Sistemas de Computação
Instituto de Ciências Matemáticas e de Computação
Universidade de São Paulo (USP)
Caixa Postal: 668 – 13560-970 - São Carlos - SP
1
{diogonc,srocio,oall,francine,jcmaldon}@icmc.usp.br
Resumo. De acordo com resultados anteriores, um conjunto de teste (T) adequado para o critério Análise de Mutantes (AM) – AM-adequado – para um
programa P não é adequado para um programa Q, equivalente a P . Por outro
lado, apesar de T não ser 100% adequado para o teste de Q, é possı́vel que na
prática ele seja próximo ao adequado, motivando sua reutilização. Neste artigo
apresenta-se um experimento que busca avaliar o nı́vel de adequação de Ts AMadequados para programas de referência em outros programas equivalentes. O
estudo é realizado no domı́nio de algoritmos de ordenação. Foram construı́dos
Ts AM-adequados para 6 algoritmos diferentes de ordenação, conjuntos estes que foram executados contra 22 implementações diferentes construı́das por
alunos de graduação. Para verificar a similaridade das médias das coberturas
atingidas pelos diferentes Ts, foram realizados testes estatı́sticos de análise de
variância. Resultados indicam que não há diferença significativa entre as coberturas atingidas pelos diferentes Ts, o que motiva a sua reutilização. Além
disso um segundo teste indicou que essas coberturas são superiores às obtidas
por um T aleatório.
1. Introdução
Para reduzir os custos da atividade de teste de software, muitas vezes se torna interessante reutilizar conjuntos de (casos de) teste criados anteriormente. Isso ocorre particularmente no caso de programas semanticamente semelhantes (ou equivalentes), ou seja,
programas que implementam a mesma funcionalidade, poré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 afirmação
ser intuitiva, é importante verificar na prática o nı́vel de adequaçã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 é, do tipo de critério de adequação adotado). Este artigo apresenta um estudo experimental sobre esse problema, no contexto da
reutilização de casos de teste criados a partir do critério Análise de Mutantes (AM) para
programas equivalentes que implementam diferentes algoritmos de ordenação. O critério
AM [DeMillo et al. 1978] é considerado custoso, o que torna esse tipo de experimento
importante para a obtenção de indı́cios sobre a viabilidade da reutilização de conjuntos de
teste nesse contexto.
De acordo com o axioma da antiextensionalidade de critérios de teste definido por
Weyuker [Weyuker 1986] tem-se que: dado dois programas P e Q, tal que P é equivalente a Q, um conjunto de teste T adequado a P não é necessariamente adequado a Q. A
mesma autora demonstra teoricamente que essa propriedade se aplica ao critério AM. Isso
114
ESELAW’09
é claramente observado, já que o critério AM leva em conta a sintaxe do programa, ou
seja, os mutantes gerados e, consequentemente, os casos de teste, dependem diretamente
de como o programa é implementado. Entretanto, apesar de T não ser necessariamente
adequado a Q – ou seja, não atingir 100% de cobertura para o critério AM –, é possı́vel
que ele seja próximo do adequado, o que motivaria a sua reutilização. Em um trabalho
anterior [Maldonado et al. 1995], verificou-se indı́cios de que os escores de mutação são
de fato similares quando se utiliza conjuntos de teste de referência aplicados a diversos
programas que implementam algoritmos de ordenação. Entretanto, nesse primeiro estudo
foi utilizada apenas uma implementação de cada algoritmo de ordenação, desenvolvida
pelos próprios autores.
Além disso, estudos indicam que o critério AM é bastante eficaz para revelar diversos tipos de defeitos [Mathur and Wong 1993]. No entanto, a sua aplicação em geral
é custosa devido à grande quantidade de mutantes gerados que precisam ser analisados
e executados contra os conjuntos de teste [Maldonado et al. 1995]. Dessa forma, estudos que indiquem que a reutilização de conjuntos de teste é efetiva para esse critério são
importantes para viabilizar, por exemplo, a criação de bases de conjuntos de teste para diferentes funcionalidades que podem ser reutilizados pelos desenvolvedores. Tais práticas
poderiam compensar o alto custo de aplicação do critério, já que ofereceriam um ponto
de partida no teste de diferentes aplicações.
O estudo apresentado neste artigo procura avaliar os mesmos resultados atingidos por Maldonado et al. [Maldonado et al. 1995], porém, neste caso com um número
maior de implementações desenvolvidas por programadores diferentes e com análises
estatı́sticas dos resultados obtidos. Comparou-se, ainda, a cobertura atingida pelos conjuntos de teste gerados a partir da utilização do critério AM com a cobertura obtida por
conjuntos de teste gerados aleatoriamente, para verificar a utilidade dos conjuntos gerados
sistematicamente.
O estudo experimental envolveu 28 implementações de algoritmos de ordenação,
sendo 22 desenvolvidas por alunos de graduação do curso de Engenharia de Computação
– divididas em implementações do bubble sort, do selection sort e do insertion sort – e 6
implementações-referência de diferentes algoritmos de ordenação (bubble sort, insertion
sort, selection sort, shell sort, merge sort e quick sort). Conjuntos de teste adequados
para o critério AM foram gerados para os programas-referência. A partir daı́, executou-se
os conjuntos de referência em todos os programas, coletando a cobertura atingida. Para
verificar se a média das coberturas atingidas foi de fato alta e similar para todos os programas, aplicou-se a ANOVA [Wohlin et al. 2000] (ANalysis Of VAriance). O mesmo teste
foi aplicado uma segunda vez, considerado um conjunto de teste gerado aleatoriamente.
Os resultados atingidos indicam que casos de teste gerados a partir do critério
AM para programas que implementam algoritmos de ordenação podem ser efetivamente
reutilizados em programas semanticamente semelhantes. Além disso, demonstra-se que
o conjunto de teste aleatório obtém cobertura significativamente mais baixa, o que indica que a utilização dos conjuntos de teste gerados sistematicamente é interessante nesse
contexto.
O restante do artigo está organizado como segue. Na Seção 2 apresentam-se
conceitos gerais sobre o critério AM e o axioma definido por Weyuker. Na Seção 3
descreve-se o estudo experimental, mostrando sua definição e planejamento, e na Seção 4
apresenta-se a análise dos resultados alcançados e discussões. Por fim, na Seção 5
apresentam-se as conclusões e trabalhos futuros.
115
ESELAW’09
2. Critério Análise de Mutantes e Axiomatização
2.1. Análise de Mutantes
O critério Análise de Mutantes (AM) utiliza informações sobre os defeitos cometidos
frequentemente por programadores ou projetistas durante o desenvolvimento do software
para definir os requisitos de teste [DeMillo et al. 1978]. Com base nos defeitos que se
deseja evidenciar, pequenas modificações sintáticas são realizadas sobre o código-fonte,
gerando programas ligeiramente alterados denominados mutantes. Assim, o objetivo do
critério é gerar casos de testes que demonstrem que o programa não possui os defeitos
representados pelos mutantes, observando-se a saı́da durante a execução do programa
original e dos mutantes gerados. Um mutante é considerado morto quando a saı́da gerada
por ele difere da saı́da gerada pelo programa original. Mutantes equivalentes são aqueles
que geram a mesma saı́da que o programa original para qualquer valor de entrada contido
no domı́nio de entrada.
A medida de cobertura do critério AM é o escore de mutação, calculado como a
razão entre o número de mutantes mortos sobre o número de mutantes não equivalentes.
O escore de mutação pode variar de 0 a 1 e quanto mais próximo de 1 maior é a qualidade
do conjunto de casos de testes aplicado.
Diversos estudos foram realizados com o objetivo de avaliar o critério AM e os
resultados indicam que esse critério possui uma alta eficácia para revelar defeitos quando
comparado com outros critérios [Maldonado et al. 2007]. Entretanto, um problema que
compromete o seu uso é o alto custo de aplicação. Mesmo para pequenos programas o
número de mutantes gerados e que precisam ser analisados é bastante elevado. Desse
modo, diversas estratégias foram propostas visando reduzir o custo de aplicação sem prejudicar a sua eficácia. Dentre elas, destacam-se estratégias para realização de mutação
seletiva [Offutt et al. 1993], mutação aleatória [Acree et al. 1979] e geração de conjunto
seletivo de operadores [Barbosa et al. 1998].
Além disso, dada a relevância desse critério para a atividade de teste, iniciativas
visando automatizar sua aplicação podem ser identificadas. Nesse contexto, destaca-se a
ferramenta Proteum, desenvolvida por Delamaro [Delamaro 1993], que apóia a aplicação
do critério AM para programas na linguagem C. A ferramenta é guiada por sessões de
teste, sendo que em cada sessão o usuário pode criar mutantes para o programa a ser
testado a partir de um conjunto de 71 operadores, criar casos de testes e executá-los com o
programa original e com os mutantes e analisar os resultados. A ferramenta disponibiliza
relatórios estatı́sticos, mostrando a quantidade de mutantes que cada caso de teste matou,
quantos mutantes ainda estão vivos, dentre outras informações.
2.2. Axiomatização de Critérios de Teste
Existem diversas técnicas e critérios definidos para auxiliar a atividade de teste. Weyuker [Weyuker 1986] procurou identificar um conjunto de caracterı́sticas desejáveis em
um critério de teste. Tais caracterı́sticas foram organizadas em axiomas e alguns critérios
foram avaliados teoricamente em relação aos axiomas definidos.
No contexto deste trabalho, foca-se no axioma da antiextensionabilidade que
afirma que: “dado dois programas P e Q, onde P é equivalente a Q e T o conjunto
de casos de teste adequado a P , T não é necessáriamente adequado a Q”. Programas
equivalentes são aqueles para os quais todo valor de entrada x contido no domı́nio de
entrada de P e Q obtém a mesma saı́da nos dois programas, ou seja, P (x) = Q(x).
Por meio de estudos teóricos sobre as caracterı́sticas do critério AM, Weyuker [Weyuker 1986] constatou que o axioma da antiextensionalidade é satisfeito por esse
critério. Isso significa que programas com semelhança semântica exigem conjuntos de casos de testes diferentes para esse critério de teste. A autora fundamenta sua argumentação
116
ESELAW’09
no fato do critério ser fortemente relacionado com a implementação dos programas e não
com a sua especificação. Ela afirma que “dois programas que realizam a mesma função
de forma diferente terão um conjunto de mutantes diferentes gerados que irão exigir, portanto, um conjunto de casos de testes diferente para distingui-lo do programa original”.
Apesar desse fato, é importante avaliar a cobertura atingida por conjuntos de teste
adequados para um programa P em programas Q semanticamente semelhante. Isso porque a cobertura pode não ser de 100%, mas se for estatisticamente semelhante à cobertura
do conjunto adequado no programa de referência, motivar-se-ia sua reutilização.
3. Descrição do Estudo Realizado
Nesta seção são descritas as caracterı́sticas da condução do experimento, seguindo o processo definido por Wohlin et al (2000).
3.1. Planejamento
Definição: Avaliação na prática do axioma de antiextensionabilidade de Weyuker [Weyuker 1986] em relação ao critério AM. Em outras palavras, avaliar o quanto
um conjunto de casos de teste adequado a um programa de referência é adequado para
testar versões alternativas ou evoluções desse programa.
Contexto: Avaliação de programas no domı́nio de ordenação de vetores, implementados
em C por alunos de graduação em uma disciplina introdutória (Introdução à Ciência da
Computação I) do curso de Engenharia de Computação do ICMC/USP. Definição de um
conjunto de programas de referência, também referentes ao domı́nio de ordenação, implementados com base na literatura [Ziviani 2005, Cormen et al. 2001]. Esses programas de
referência são implementados e testados (usando a ferramenta Proteum), por dois alunos
de pós-graduação.
Hipóteses: Deseja-se avaliar as seguintes hipóteses:
•
•
•
•
Hipótese Nula H1.0: Dados vários programas que implementam algoritmos de
ordenação (ou seja, programas equivalentes) e T um conjunto de casos de teste
adequado a um programa-referência P para o critério AM, T obtém cobertura
semelhante1 quando executado sobre todos os programas.
Hipótese Alternativa H1.1: Dados vários programas que implementam algoritmos de ordenação (ou seja, programas equivalentes) e T um conjunto de casos
de teste adequado a um programa-referência P para o critério AM, T não obtém
cobertura semelhante quando executado sobre todos os programas.
Hipótese Nula H2.0: Dados vários programas que implementam algoritmos de
ordenação (ou seja, programas equivalentes), T1 um conjunto de casos de teste
adequado a um programa-referência P para o critério AM, e T2 um conjunto
gerado aleatoriamente, T1 e T2 obtêm coberturas semelhantes quando executados
sobre todos os programas.
Hipótese Alternativa H2.1: Dados vários programas que implementam algoritmos de ordenação (ou seja, programas equivalentes), T1 um conjunto de casos
de teste adequado a um programa-referência P para o critério AM, e T2 um
conjunto gerado aleatoriamente, T1 e T2 não obtêm coberturas semelhantes
quando executados sobre todos os programas.
1
Definem-se coberturas semelhantes àquelas que, em média, são estatisticamente semelhantes (ou seja,
não apresentam diferença significativa quando testadas a partir de um nı́vel de confiança de 99%).
117
ESELAW’09
Variáveis Independentes: critério AM, ferramenta Proteum, especificação dos programas e programas de referência.
Variáveis Dependentes: casos de testes construı́dos para os programas de referência,
programas implementados pelos alunos, complexidade dos programas, mutantes gerados,
mutantes equivalentes identificados e escore de mutação obtido.
Participantes: 60 alunos da disciplina de Introdução à Ciência da Computação I do curso
de Engenharia de Computação do ICMC/USP, os quais desenvolveram versões de programas para serem avaliados. Dois alunos de Pós-Graduação que geraram conjuntos de teste
adequados a um grupo de programas de referência.
Descrição do experimento: Na primeira parte do experimento os alunos foram treinados
a respeito de métodos de ordenação com a apresentação dos algoritmos de 3 métodos:
bubble sort, insertion sort e selection sort. Durante a parte prática, os 60 alunos foram
separados em 30 duplas. Cada dupla ficou responsável por implementar um dos métodos
de ordenação (considerando os três algoritmos vistos), totalizando 10 implementações de
cada método de ordenação. Essa atividade foi realizada em horário de aula prática e os
alunos levaram em torno de 1 hora para implementação dos programas.
Em paralelo a essa atividade, dois alunos de Pós-Graduação envolvidos com
o estudo, implementaram, com base nos algoritmos disponı́veis em [Ziviani 2005,
Cormen et al. 2001], 6 métodos de ordenação: bubble sort, insertion sort, selection sort,
quick sort, merge sort e shell sort. Esses programas foram testados pelos alunos de pósgraduação com o auxı́lio da ferramenta Proteum e, para cada programa, um conjunto de
casos de testes adequado foi gerado.
Na segunda parte do experimento, as implementações dos alunos de graduação
foram analisadas e os programas incorretos foram excluı́dos do experimento. Dos 30
programas implementados 22 seguiram para a próxima etapa do experimento. Os 8 programas descartados não foram utilizados pois continham erros de codificação, o que prejudicaria a análise do experimento. O escore de mutação é valido somente para programas
corretos, pois a distinção entre um mutante vivo e um mutante morto é avaliada comparando a saı́da gerada pelo mutante com a saı́da do programa original. Para cada um desses
22 programas foram identificados os mutantes equivalentes levando em consideração os
71 operadores da Proteum.
Foram coletadas algumas métricas relacionadas à complexidade dos programas
e ao critério análise de mutantes, sendo elas: Linhas de Código (LOC), Complexidade
de McCabe[McCabe 1976], quantidade de mutantes gerados e quantidade de mutantes
equivalentes identificados. Essas métricas também foram coletadas dos programas de
referência com o objetivo de verificar se existe alguma relação entre os diferentes métodos
de ordenação testados.
Para a automatização dos testes utilizou-se a interface de scripts da Proteum. Foi
implementado um conjunto de instruções que automatizou três atividades importantes:
criar a sessão de teste, criar um conjunto de casos de testes e marcar os mutantes como
equivalentes. A execução dos casos de testes contra os mutantes e a verificação do escore
de mutação atingidos foi feita utilizando a interface gráfica da ferramenta.
Foi verificada também a cobertura obtida pelos casos de testes adequados aos
programas de referência, sobre os próprios programas de referência. Esses dados foram
coletados com o objetivo de avaliar se a complexidade dos programas interfere de alguma
forma no escore de mutação atingido. Esses dados são importantes pois o conjunto de
programas de referência contém métodos de ordenação mais complexos como o quick
sort, o merge sort e o shell sort. Para avaliar as hipóteses levantadas, foram realizados testes estatı́sticos aplicando o método ANOVA (analysis of variance) e os resultados obtidos
118
ESELAW’09
podem ser vistos na Seção 4.
Validade: Os aspectos de validade do experimento são divididos em validade interna e
externa: A validade interna busca identificar quais aspectos podem influenciar a relação
entre a causa e o efeito durante a realização do experimento. As ameaças a validade
interna identificadas foram:
Implementações idênticas pelos alunos de graduação: Foram tomados alguns cuidados durante a execução do experimento para que os alunos não se comunicassem enquanto implementavam os algoritmos. Além disso, os códigos foram analisados individualmente e não foram identificadas evidências de plágio.
Aprendizado em relação à construção de casos de testes pelos alunos de pósgraduação: Como os casos de testes foram construı́dos por apenas dois alunos, estes
podem ter aprendido com os primeiros programas a construir casos de testes mais eficazes, ou até mesmo aproveitar os casos de testes construı́dos para programas anteriores, o
que poderia influenciar o escore de mutação obtido. Como tratamento a essa ameaça, a
ordem de construção de casos de testes para os programas de referência foi selecionada
de forma aleatória. Além disso os testes foram construı́dos seguindo sistematicamente
o critério AM, ou seja, cada caso de teste foi construı́do com o objetivo de matar um
mutante especı́fico relativo a uma determinada implementação.
Simplicidade dos programas testados: Pode-se supor que devido à simplicidade
do domı́nio de programas escolhido, qualquer conjunto de casos de testes, seria suficiente
para alcançar um escore de mutação satisfatório. O tratamento relativo a essa ameaça foi
a utilização de um conjunto de casos de testes aleatórios. Esse conjunto obteve resultados
inferiores aos obtidos pelos casos de testes dos programas de referência, como pode ser
visto na Seção 3.2.
A validade externa do experimento refere-se à capacidade de generalização dos
resultados obtidos. Como os programas estudados foram especı́ficos do domı́nio de
ordenação, não se pode generalizar os resultados obtidos para outros domı́nios de programas. Como trabalhos futuros pretende-se realizar o mesmo experimento em outros
domı́nios e assim obter resultados mais genéricos em relação às hipóteses estudadas.
3.2. Resultados obtidos
Na Tabela 1 são apresentadas as métricas coletadas de cada um dos programas implementados pelos alunos de graduação. Nas linhas estão listados os programas que não
apresentaram erros. A tabela foi quebrada ao meio e na primeira coluna é apresentada a identificação dos programas seguida da quantidade de linhas de código (LOC) e
da complexidade ciclomática (McCabe) [McCabe 1976]. Nas duas últimas colunas são
apresentadas as métricas relativas ao critério AM: a quantidade de mutantes gerados e a
quantidade de mutantes equivalentes identificados.
Pode-se observar que apesar dos programas serem baseados em três métodos diferentes as métricas obtidas foram muito próximas, não havendo diferenças significativas
entre os métodos. Esse resultado já era esperado pois apesar de serem métodos distintos, trata-se de programas semelhantes em relação à forma de ordenar os números. É
interessante comparar a complexidade desses programas com os programas de referência,
pois esses possuem menos semelhanças em relação ao método de ordenação. As métricas
relativas aos programas de referência são apresentados na Tabela 2.
Observa-se que os três últimos programas (shell, merge e quick) apresentaram
valores mais altos em todas as métricas coletadas, com exceção da quantidade de mutantes
119
ESELAW’09
Tabela 1. Métricas coletadas dos
graduação
Programas LOC McCabe Mutantes
B1
23
7
478
B2
22
7
462
B3
24
7
456
B4
20
7
514
B5
24
7
444
B6
27
7
568
B9
24
7
482
I1
23
7
491
I2
23
7
495
I3
23
7
473
I4
21
6
779
programas implementados pelos alunos de
ME
34
41
44
41
43
37
51
20
20
19
39
Programas LOC McCabe Mutantes ME
I5
19
7
473
18
I7
23
7
473
21
I8
23
7
414
17
I9
23
7
473
20
I10
21
7
473
18
S1
26
7
517
44
S2
22
7
493
41
S4
25
7
561
42
S5
24
7
530
37
S7
24
7
542
55
S10
25
7
560
39
LOC McCabe Mutantes ME
Média 23,14
6,95
506,86 33,68
Tabela 2. Métricas coletadas dos programas de referência
Programas LOC McCabe Mutantes ME
bubble sort
20
7
489
42
insertion sort 25
6
451
50
selection sort 23
7
511
70
shell sort
27
9
667
48
merge sort
50
12
1715
70
quick sort
38
9
674
14
Média
30,50
8,33
751,17 49,00
equivalentes (que foi a menor de todas no quick sort). Os resultados mais altos podem ter
ocorrido devido ao fato dos três métodos de ordenação adicionais serem mais complexos
e adotarem estratégias diferentes em relação aos programas anteriores.
Para cada programa de referência foi criado um conjunto de casos de testes adequado à sua implementação. Foi gerado, também, um conjunto de casos de teste aleatório,
independente de qualquer método de ordenação. Cada um desses conjuntos de casos de
testes foi então aplicado aos 22 programas implementados pelos alunos de graduação.
Nas tabelas 3, 4 e 5 podem ser observados o escore de mutação para os métodos bubble,
insertion e selection respectivamente. Nas linhas estão representados os casos de testes
adequados a cada um dos programas de referência e nas colunas os programas implementados pelos alunos de graduação
Tabela 3. Escore de mutação obtido para o método bubble sort implementados
pelos alunos de graduação
Referência
B1
B2
B3
B4
B5
B6
B9 Mé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 aleató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 semelhantes entre os três métodos implementados. Além disso, os casos de teste adequados aos
120
ESELAW’09
Tabela 4. Escore de mutação obtido para o método insertion sort implementados
Referência
I1
I2
I3
I4
I5
I7
I8
I9
I10 Média
CT bubble
0,998 0,998 0,998 1,000 0,998 0,998 1,000 0,998 0,998 0,998
CT insertion 0,998 0,998 0,998 1,000 0,998 0,998 1,000 0,998 0,998 0,998
CT selection 0,998 0,998 0,998 1,000 0,998 0,998 0,997 0,998 0,998 0,998
CT shell
0,998 0,998 0,998 1,000 0,998 0,998 1,000 0,998 0,998 0,998
CT merge
0,994 0,994 0,993 0,999 0,993 0,993 0,995 0,993 0,993 0,994
CT quick sort 0,996 0,996 0,996 0,999 0,996 0,996 0,995 0,996 0,996 0,996
CT aleatório 0,970 0,962 0,960 0,984 0,960 0,960 0,965 0,960 0,960 0,965
Tabela 5. Escore de mutação obtido para o método selection sort implementados
Referência
S1
S2
S4
S5
S7
S10 Média
CT bubble
0,994 0,996 0,987 0,990 0,994 0,987 0,991
CT insertion 0,996 1,000 0,990 0,992 0,996 0,985 0,993
CT selection 0,998 0,998 0,996 0,998 0,998 0,996 0,997
CT shell
0,992 0,991 0,990 0,992 0,992 0,988 0,991
CT merge
0,996 0,993 0,992 0,994 0,994 0,996 0,994
CT quick sort 0,996 0,993 0,992 0,994 0,994 0,996 0,994
CT aleatório 0,964 0,967 0,961 0,963 0,963 0,962 0,963
programas de referência atingiram, em todos os casos, escores maiores do que 0,99 obtendo a média de 0,996. Em contrapartida, o conjunto de casos de teste gerados de forma
aleatória, apesar de também obter um escore de mutação relativamente alto, ficou sempre
abaixo de qualquer um dos outros conjuntos de casos de teste. Ainda em relação aos
resultados, não foi possı́vel identificar, de forma preliminar, uma relação entre o método
utilizado e o escore de mutação obtido, já que os resultados foram muito próximos. Não
parece existir também uma relação com a complexidade do método, visto que não houve
diferenças significativas entre o escore obtido pelos casos de teste adequados aos 3 primeiros algoritmos e aqueles adequados aos algoritmos mais complexos.
Foi verificado também a adequação dos conjuntos de teste de cada programa de
referência para os demais programas de referência. Dessa forma pode-se analisar se o
conjunto de casos de teste adequado a um programa mais simples como o bubble sort
também é adequado a programas mais complexos como shell, merge e quick sort. Os
resultados obtidos podem ser vistos na Tabela 6.
Tabela 6. Escore de mutação obtido para os programas de referência
Referência bubble insertion selection shell merge quick Média
CT bubble
1,000
0,997
0,995 0,993 0,969 0,980 0,989
CT insertion 1,000
1,000
0,990 0,993 0,994 0,935 0,986
CT selection 0,997
1,000
1,000 0,991 0,969 0,993 0,992
CT shell
1,000
1,000
0,995 1,000 0,975 0,993 0,994
CT merge
0,993
0,997
0,995 0,995 1,000 0,993 0,995
CT quick sort 0,993
0,997
0,995 0,995 0,989 1,000 0,995
CT aleatorio 0,959
0,960
0,963 0,964 0,984 0,965 0,966
Em relação ao conjunto de casos de teste aleatório, os resultados ficaram próximos
dos obtidos para os programas implementados pelos alunos de graduação. Observouse, porém, que a média obtida foi mais baixa, principalmente devido ao menor escore
alcançado para os programas mais complexos, chegando a atingir um mı́nimo de 0,935
para o conjunto de casos de teste adequado ao insertion sort aplicado no quick sort. Na
Seção 4 esses resultados são análisados estatisticamente e discutidos.
121
ESELAW’09
4. Análise e Discussão
Para analisar estatisticamente se os diferentes conjuntos de casos de teste gerados para os
programas de referência obtêm, em média, cobertura alta e semelhante quando executados
sobre todas as implementações de ordenação de vetores, decidiu-se realizar a análise de
variância (analysis of variance, ou ANOVA). A ANOVA oferece um teste estatı́stico que
verifica se as médias de diferentes grupos são iguais, generalizando o teste t de Student
quando se tem mais de dois grupos.
No caso do estudo em questão, aplica-se a ANOVA para verificar as hipóteses
formuladas na Seção 3. Para que o teste seja rigoroso, assume-se o nı́vel de confiança
de 99% (portanto, p-valor = 0,01). A ANOVA é aplicada duas vezes: uma para verificar
se as coberturas obtidas para todos os programas são igualmente altas em média, quando
se permuta os conjuntos de casos de teste de referência; e outra para verificar se, caso a
semelhança seja evidenciada no primeiro caso, o mesmo não ocorre quando se considera
as coberturas atingidas pelos casos de teste aleatórios. O segundo teste é realizado para
verificar o quanto os casos de teste gerados aleatoriamente se aproximam daqueles gerados sistematicamente a partir do critério AM. A ausência de diferença significativa nesse
caso é um indı́cio de que nã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 não há diferença significativa entre as
coberturas obtidas pelos conjuntos de casos de teste gerados para os programas de referência, quando executados sobre todos os programas (note-se que também se considera
o conjunto de casos de teste referência aplicado ao próprio programa utilizado para a
geração do conjunto). Como o p-valor foi avaliado em 0,6809 – ou seja, consideravelmente maior do que 0,01 – não se obteve evidência suficiente para se rejeitar a hipótese
nula H1.0 de que as médias das coberturas obtidas são semelhantes. Além disso, essas
mesmas médias encontram-se entre 0,99 e 1, ou seja, praticamente 100%. Esse resultado é uma evidência da efetividade de se reutilizar casos de teste gerados para uma dada
implementação de ordenação em outras implementações equivalentes utilizando o critério
AM. Entretanto, quando se considera o conjunto aleatório de casos de teste, a diferença
obtida é significativa. O p-valor nesse caso foi muito menor do que 0,01 (2.2 × 10−16 ),
ou seja, uma forte evidência para se rejeitar a hipótese nula H2.0 de que as médias das
coberturas são semelhantes, quando se considera o conjunto aleatório.
Para se ter uma idéia visual dos resultados, a Figura 1 apresenta o boxplot das
coberturas obtidas por cada conjunto de casos de teste, incluindo o aleatório, executados
em todos os programas (riscos em negrito representam as médias). Note-se que o número
de outliers não é significativo e, além disso, a semelhança entre as coberturas obtidas
pelos casos de teste gerados para os programas de referência é claramente visı́vel nos
valores mais à direita no gráfico. A cobertura é claramente menor para os casos de teste
gerados aleatoriamente, como pode ser visto nos valores mais à esquerda no gráfico (a
média das coberturas se encontra entre 0,96 e 0,97).
5. Conclusões
Neste artigo foi apresentado um estudo sobre a reutilização de conjuntos de teste adequados para o critério AM em programas equivalentes. O estudo foi realizado no domı́nio de
algoritmos de ordenação. Os resultados obtidos indicam que os conjuntos de teste gerados
para programas de referência obtêm a mesma cobertura, em média (entre 99% e 100%),
quando aplicados aos 22 programas implementados pelos alunos e aos próprios programas de referência. A análise estatı́stica indicou que não houve diferenças significativas
entre as coberturas obtidas pelos conjuntos de teste. Em contrapartida, o conjunto de casos de testes aleatórios obteve cobertura significativamente mais baixa, o que indica que
122
0.97
0.94
0.95
0.96
cobertura
0.98
0.99
1.00
ESELAW’09
aleatório
bubble
insertion
merge
quick
selection
shell
referência
Figura 1. Boxplot dos dados obtidos no estudo.
a utilização dos conjuntos de teste gerados sistematicamente é interessante. Esses resultados oferecem indı́cios de que a reutilização de casos de teste gerados a partir do critério
AM em programas equivalentes pode ser de fato efetiva. Trabalhos futuros incluem estudos similares em outros domı́nios, para que os resultados possam ser generalizados.
Referê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 contribuição para a determinação de
um conjunto essencial de operadores de mutação no teste de programas C. In XII Simpósio Brasileiro
de Engenharia de Software (SBES 98), pages 103–120, Maringá, 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 análise de mutantes. Master’s thesis,
ICMC-USP, Sã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). Análise de mutantes: Uma avaliação
empı́rica do axioma de antiextensionalidade. In Anais do Workshop de Qualidade de Sofware (em conjunto 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). Introdução ao teste de software. chapter Estudos Teó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
Simpó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 Wesslén, A. (2000). Experimentation
in software engineering: an introduction. Kluwer Academic Publishers.
Ziviani, N. (2005). Projeto de Algoritmos com Implementações em Pascal e C. Thomson, 2nd. edition.
123
ESELAW’09
WDP-RT: Uma técnica de leitura para inspeção de
usabilidade de aplicações Web
Marcos Gomes1, Davi Viana1, Lennon Chaves1, Andreza Castro1, Verônica T.
Vaz2, Altigran Soares1, Guilherme H. Travassos2, Tayana Conte1
1
Departamento de Ciência da Computação
Universidade Federal do Amazonas (UFAM) – Manaus, AM - Brasil
2
PESC – COPPE/UFRJ, Cx Postal 68.511, CEP 21945-970, Rio de Janeiro, RJ, Brasil
{marcos.sgomes, davi.viana, lennon.correach, andreza.dy}@gmail.com , {alti,
tayana}@dcc.ufam.edu.br, [email protected], [email protected]
Abstract. Some available technologies can be usually used by software
engineers in detecting usability defects, such as ad-hoc, Heuristic Evaluation
and the checklist based technique WDP (Web Design Perspective-based
Inspection). However, usability inspections still represent a challenge
concerned with effort, efficiency and efficacy in software engineering. This
paper describes a controlled study to evaluate the feasibility of the WDP-RT
(Web Design Perspective-based Inspection – Reading Technique), an
evolution of WDP represented by a reading technique for usability inspection,
specific for inspection of Web applications. Results from an experimental
study indicated that WDP-RT can be feasible and possibly presenting better
efficacy and similar efficiency when compared to WDP.
Resumo. Algumas tecnologias disponíveis podem ser utilizadas pelos
engenheiros de software na detecção de defeitos de usabilidade, tais como adhoc, Avaliação Heurística e a técnica baseada em checklist WDP (Web
Design Perspective-Based Inspection). No entanto, as inspeções de
usabilidade ainda representam um desafio em relação ao esforço, eficiência e
eficácia em engenharia de software. Este trabalho apresenta um estudo
controlado para avaliar a viabilidade da WDP-RT (Web Design PerspectiveBased Inspection - Reading Technique), uma evolução da WDP para uma
técnica de leitura, específica para a inspeção de aplicações web. Resultados
de um estudo experimental indicaram que WDP-RT pode ser viável,
possivelmente apresentando melhor eficácia e eficiência semelhante quando
comparada à WDP.
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
A usabilidade tem como objetivo elaborar interfaces capazes de permitir uma
interação fácil, agradável, com eficácia e eficiência. Ela deve capacitar a criação de
interfaces transparentes de maneira a não dificultar o processo, permitindo ao usuário
pleno controle do ambiente sem se tornar um obstáculo durante a interação.
Devido à relevância da usabilidade para as aplicações Web, a indústria de
desenvolvimento de software está investindo em técnicas e ferramentas para projetos e
avaliações que ajudem a melhorar esse quesito de qualidade em suas aplicações Web
(MATERA et al. 2006). Técnicas de avaliação de usabilidade específicas para
aplicações Web, tais como CWW (BLACKMON et al. 2002), MiLE+ (BOLCHINI e
GARZOTTO, 2007) e WDP (CONTE et al. 2009b), estão sendo desenvolvidas.
A WDP (CONTE et al., 2007b) é uma técnica de inspeção baseada em checklist,
onde os inspetores recebem uma lista de verificação que os ajudam a encontrar os
defeitos. A técnica WDP foi definida e aperfeiçoada utilizando uma abordagem baseada
em evidência para definição de novas tecnologias de software apresentada em (MAFRA
et al. 2006), uma extensão da metodologia proposta em (SHULL et al. 2001) para a
introdução de tecnologias de software na indústria, que se baseia em estudos
experimentais como forma de determinar o que funciona ou não na aplicação da
tecnologia proposta. A técnica WDP foi proposta com base no resultado de estudos
secundários (CONTE et al. 2005) e até o presente momento foi avaliada através de dois
estudos de viabilidade (CONTE et al. 2007a, CONTE et al. 2007b), um estudo de
observação (CONTE et al. 2009b) e dois estudos de caso em ambiente industrial (VAZ
et al. 2008). Os resultados do estudo de observação indicaram que a evolução da WDP
para uma técnica de leitura ajudaria os inspetores novatos na detecção de problemas de
usabilidade. Uma técnica de leitura proporciona foco, que é usado para guiar um
inspetor durante a atividade de detecção de problemas de usabilidade, fornecendo
orientação mais estrita, visando reduzir as dificuldades de inspeção dos inspetores com
menor conhecimento sobre avaliação de usabilidade (CONTE, 2009).
Com o intuito de auxiliar os inspetores novatos na avaliação de interfaces, este
trabalho apresenta a WDP-RT (Web Design Perspectives-based Inspection – Reading
Technique), extensão da técnica WDP para uma técnica de leitura. Para apoiar a
definição e o aprimoramento da técnica proposta, também está sendo utilizada a
abordagem experimental apresentada em (SHULL et al., 2001). Este artigo apresenta o
estudo controlado realizado para avaliar a viabilidade da versão inicial técnica proposta.
No processo de avaliação e evolução da técnica WDP, foi executado um estudo de
viabilidade (CONTE et al., 2007b) que comparava a eficiência e eficácia da mesma com
o método Avaliação Heurística (a base para a definição da WDP). De maneira análoga,
o presente estudo de viabilidade teve como objetivo responder a questão de pesquisa:
“A técnica WDP-RT é eficiente e eficaz para inspeções de usabilidade?” em
comparação com a técnica WDP.
O restante deste artigo está estruturado da seguinte forma. A seção 2 descreve a
técnica WDP, que foi utilizada como base para a nova técnica de inspeção. A seção 3
apresenta a definição da primeira versão da WDP-RT. A seção 4 discorre sobre o estudo
de viabilidade realizado para avaliar a WDP-RT. Por fim, a seção 5 conclui o artigo.
2. WDP – Web Design Perspective-based Usability Evaluation
125
ESELAW’09
A técnica WDP (CONTE et al, 2007a) é uma extensão ao método de Avaliação
Heurística. Esta técnica utiliza as heurísticas de NIELSEN (1994) como base,
direcionando a avaliação de usabilidade através de perspectivas específicas para a
representação de aplicações Web: apresentação, conceituação e navegação.
A usabilidade em relação à perspectiva apresentação preocupa-se com a
consistência das informações apresentadas ao usuário. Sob esta perspectiva, a
usabilidade é satisfatória caso a programação visual e o layout da interface permitam ao
usuário realizar suas tarefas de maneira eficaz, eficiente e agradável. A pergunta chave
para avaliação desta perspectiva é: “Estou vendo?”.
A usabilidade em relação à perspectiva conceituação preocupa-se com a clareza
e a concisão dos elementos do domínio do problema. Sob essa perspectiva, a
usabilidade é satisfatória se o sistema utilizar representação facilmente compreendida
pelo usuário, não levando o usuário a cometer erros por causa de termos ambíguos,
inconsistentes ou desconhecidos. As perguntas chaves para a perspectiva conceituação
são: “Eu compreendo? Eu entendo?”.
Em relação à perspectiva navegação, a usabilidade preocupa-se com a
acessibilidade das funcionalidades do sistema pelos diferentes tipos de usuários. Sob
essa perspectiva, a usabilidade é satisfatória caso as opções de navegação do sistema
permitam a todos os tipos de usuários realizarem suas tarefas de maneira eficaz,
eficiente e agradável. A pergunta chave desta perspectiva é: “Eu alcanço?”.
A Tabela 1 mostra o relacionamento das heurísticas propostas por NIELSEN
(1994) com as perspectivas de Projeto Web na WDP v5.
Tabela 1: Heurísticas x Perspectivas da WDP v5
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
A Figura 1 mostra um extrato da técnica, apresentando os itens de verificação
(itens do checklist) para o par A.5. O texto completo da versão v5 está disponível em
(CONTE 2009).
Figura 1 - Par Heurística x Perspectiva A.5.
126
ESELAW’09
3. Proposta inicial da técnica WDP-RT (Web Design Perspectives-based
Inspection – Reading Technique)
Por ser uma técnica de inspeção baseada em checklist, a WDP se adéqua facilmente ao
uso por inspetores com alguma experiência em inspeções de usabilidade, onde eles têm
a liberdade de executar a inspeção da forma mais conveniente, e contam com a ajuda do
checklist para verificação de características pontuais na aplicação Web. A abstração das
heurísticas e o acréscimo das perspectivas tornam a avaliação de usabilidade mais
simples, porém, como apresentado no estudo de observação da WDP (CONTE, 2009b),
isto ainda não é suficiente para ajudar inspetores novatos na execução desta atividade.
Inspetores novatos precisam de direcionamento, um procedimento a ser seguido para
executar a inspeção. A WDP fornece as diretrizes para a avaliação, porém não informa
aos inspetores em que ordem estas diretrizes ou mesmo as perspectivas de projeto WEB
devem ser aplicadas.
A WDP-RT se baseia em um conjunto de instruções que devem ser executadas
para a verificação da usabilidade da aplicação. Com o propósito de aumentar a cobertura
de avaliação da WDP, as instruções da WDP-RT foram definidas através da análise das
características de usabilidade de outros dois conjuntos de características a serem
consideradas em avaliações de usabilidade, os “requisitos não funcionais de
usabilidade” (FERREIRA E LEITE, 2003), e o conjunto de “características funcionais
de usabilidade” (JURISTO et. al., 2007). Foi feita uma análise de equivalência entre os
conjuntos de recomendações propostos por (FERREIRA e LEITE 2003; JURISTO et al.
2007) e o conjunto de itens a serem verificados propostos pela WDP, com base nas
heurísticas de (NIELSEN, 1994).
Foi realizada uma análise detalhada das características destes conjuntos de
usabilidade, relacionando os três conjuntos, sua relevância para aplicações Web em
geral e verificando cada uma de suas recomendações. Com base nesta análise, foi
elaborado o conjunto base de recomendações para a WDP-RT e seu conjunto de
instruções. As instruções da WDP-RT estão agrupadas de acordo com as três
perspectivas de projeto Web, sendo executadas primeiramente as instruções para a
verificação da usabilidade em relação à perspectiva Apresentação, seguida das
instruções referentes à perspectiva Conceituação, e por fim, à perspectiva Navegação. A
Figura 2 apresenta uma visão da primeira versão da WDP-RT (WDP-RT v1). O texto
completo da WDP-RT v1 está disponível em (GOMES e CONTE, 2009).
Figura 2 - Extrato da WDP-RT v1
127
ESELAW’09
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).
Figura 3 – Objetivos do estudo de viabilidade.
Os participantes deste estudo foram os alunos matriculados na disciplina, além
de duas desenvolvedoras de software de uma instituição de pesquisa. Os alunos
puderam optar por participar ou não do estudo. Ao todo, 18 alunos concordaram
inicialmente em participar do estudo. Todos os participantes assinaram um Termo de
Consentimento Livre e Esclarecido e preencheram um formulário de caracterização que
continha perguntas que deveriam ser respondidas em uma escala de 1 (nenhuma
experiência prática) a 5 (experiência em vários projetos industriais) sobre a experiência
dos participantes em relação ao seu conhecimento sobre usabilidade, avaliações e
inspeções de software e em desenvolvimento de software web. As respostas dos
formulários de caracterização permitiram classificar os participantes e dividi-los em
dois grupos de dez inspetores (equipes WDP e WDP-RT) com níveis de experiência
balanceados. A Tabela 2 apresenta a caracterização da experiência dos inspetores.
A aplicação inspecionada foi o portal da Sociedade Brasileira de Computação
(SBC), para o qual foi definido um roteiro com oito atividades básicas a serem
desempenhadas no portal: informar-se sobre o POSCOMP, associar-se a SBC,
informar-se sobre alunos destaques, realizar o download do modelo de artigo da SBC,
informar-se sobre o secretário regional, informar-se sobre a diretoria atual da SBC,
cadastrar-se no portal e informar-se sobre o Simpósio Brasileiro de Engenharia de
Software (SBES, 2009).
O treinamento dos grupos foi realizado separadamente, sendo que cada grupo de
participantes recebeu um treinamento com duração de uma hora. Cada treinamento
incluía conceitos sobre usabilidade, além da técnica específica que o grupo deveria
utilizar para realizar a inspeção. Apesar de cada treinamento apresentar uma técnica de
inspeção distinta, os exemplos de problemas de usabilidade apresentados foram os
mesmos para ambas as turmas. Ao término de cada treinamento, cada participante
recebeu o roteiro com as atividades a serem avaliadas, a técnica de inspeção estudada no
treinamento impressa, uma planilha para a anotação das discrepâncias encontradas, além
128
ESELAW’09
da própria apresentação do treinamento. Além disso, eles também receberam um
questionário de avaliação da técnica estudada. Cada inspetor pode realizar a detecção
individual no horário que lhe fosse mais conveniente, respeitando-se apenas o prazo de
dois dias.
4.2.Execução da Inspeção
No prazo estipulado, dezesseis inspetores (nove do grupo WDP e sete do grupo WDPRT) enviaram as suas planilhas de anotação de discrepâncias e o questionário de
avaliação da técnica. Uma destas planilhas, proveniente de um inspetor do grupo WDPRT, teve que ser descartada, pois o inspetor não seguiu o roteiro pré-estabelecido para a
inspeção. Outras três planilhas, provenientes de inspetores do grupo WDP também
foram descartadas, pois estes não informaram o tempo de inspeção. Desta forma, foram
analisadas seis planilhas do grupo WDP e seis do grupo WDP-RT.
As listas de discrepâncias individuais foram então integradas a uma única lista,
retirando-se a referência do inspetor e da técnica utilizada por ele. Uma equipe de três
pesquisadores em Engenharia de Software realizou uma reunião para decidir quais
dessas discrepâncias eram únicas e quais eram duplicatas (discrepâncias equivalentes
apontadas por mais de um inspetor).
A reunião de discriminação, que visa verificar se as discrepâncias são defeitos
reais, contou com a participação dos três pesquisadores que elaboraram a coleção das
duplicatas e de um diretor da SBC, que atuou como responsável pelo portal. Nesta
reunião, as interações avaliadas foram re-executadas, sendo assim possível verificar inloco cada discrepância relatada. Após a discussão da equipe, o diretor da SBC
classificava a discrepância em defeito ou falso-positivo.
4.3. Resultados obtidos
Para verificar a viabilidade da WDP-RT, temos que verificar se ela alcança o seu
objetivo de detectar defeitos. Para isso, medimos o número de defeitos encontrados por
cada inspetor na avaliação do portal da SBC. A Tabela 2 mostra os diferentes níveis de
experiência e o resultado de cada inspetor e o resultado por técnica. Ao analisar a
Tabela 2 podemos verificar que a WDP-RT ajudou os inspetores a detectarem mais
defeitos na inspeção. Os inspetores que utilizaram a WDP-RT detectaram mais que o
dobro de defeitos que os inspetores que utilizaram a WDP (127 x 55). Isto é um indício
de que a técnica WDP-RT cumpre com o seu propósito.
Tabela 2: Resultados por inspetor
Técnica/ Experiência Experiência
Experiência
#
#
#
1
2
3 Tempo
Inspetor Usabilidade Inspeções Desenvolvimento Disc. FP Def.
10
Médio
Médio
Nenhum
10
3
7
110
11
Médio
Médio
Médio
11
0
11
45
13
Médio
Médio
Baixo
13
3
10
140
WDP
14
Baixo
Médio
Baixo
11
2
9
60
17
Médio
Médio
Baixo
16
4
12
50
18
Alto
Médio
Médio
8
2
6
38
WDP 20
Médio
Médio
Baixo
11
1
10
90
-RT 21
Nenhum
Médio
Nenhum
16
1
15
200
22
Alto
Alto
Alto
33
2
31
240
23
Médio
Médio
Alto
26
4
22
120
24
Baixo
Médio
Médio
34
6
28
180
Baixo
Médio
Nenhum
24
3
21
200
25
129
1 – número de discrepâncias, 2 – número de falso-positivos, 3 – número de defeitos
Def./
Hora
3,82
14,67
4,29
9,00
14,40
9,47
6,00
4,50
7,75
11,00
9,33
6,30
Total
Defeitos
55
127
ESELAW’09
Um dos indicadores medidos neste estudo, o indicador eficácia, está diretamente
relacionado ao apoio da técnica em encontrar os defeitos. Para analisar a eficácia, é
necessário conhecer o número de defeitos únicos encontrados (sem a contabilização das
duplicatas). Considerando-se ambas as técnicas, foi encontrado um total de 73 defeitos
únicos. A eficácia então é definida como a razão entre o número de defeitos únicos
detectados pela técnica e o número total de defeitos únicos que nós conhecemos. A
Tabela 3 compara a eficácia das técnicas.
Tabela 3: Comparativo de eficácia
Defeitos únicos
Total de defeitos únicos
Eficácia
WDP
46
73
63,01%
WDP-RT
66
90,41%
Além disso, foi feita uma análise estatística utilizando o teste Anova (análise de
variância), conforme apresentado na Figura 4. Este teste confirmou que a técnica WDPRT influenciou positivamente para encontrar mais defeitos do que a técnica WDP.
35
Defeitos Total
30
25
20
15
10
5
WDP
WDP-RT
Tecnica
Each Pair
Student's t
0.05
Figura 4 - Análise do Total de Defeitos por Técnica utilizando Anova
Para responder a segunda pergunta referente a este estudo (“o tempo é bem
empregado?”), precisamos analisar a eficiência da técnica. Para esta análise, é
necessário considerar todos os defeitos (únicos e duplicatas) encontrados. A eficiência
então é definida como a razão entre o número total de defeitos e o tempo gasto na
inspeção. A Tabela 4 mostra o comparativo de eficiência para ambas as técnicas.
Tabela 4: Comparativo de eficiência
Total
de
Defeito
Defeitos
por
Inspetor
Média de
tempo
(hora)
Média de
Defeitos
/hora
Desvio Padrão
(Defeitos por
Inspetor)
% Desvio Padrão
(Defeitos por
Inspetor)
WDP
55
9,16
1,23
7,44
2,31
25,27%
WDPRT
127
21,16
2,86
7,39
7,83
37%
As Tabelas 3 e 4 apontam que a WDP-RT foi mais eficaz que a WDP,
encontrando 90,41% dos defeitos únicos conhecidos do sistema, além de apresentar
eficiência semelhante à WDP.
130
ESELAW’09
Para avaliar os dados qualitativos, foi desenvolvido um questionário baseado no
Modelo de Aceitação de Tecnologia - TAM (DAVIS, 1989), para verificar a opinião
dos inspetores em relação à facilidade de uso e a utilidade da técnica WDP-RT. Além
disso, foram acrescidas perguntas especificas em relação à WDP-RT, como a facilidade
de compreensão das instruções e das perspectivas. A análise qualitativa ainda está sendo
realizada. Como resultado preliminar, a análise destes questionários aponta que os
inspetores consideram a WDP-RT útil para inspeções de usabilidade e de fácil
utilização. Ainda consideraram as perspectivas de projeto Web e as instruções da WDPRT fáceis de compreender. Entretanto, metade dos inspetores também ressaltou o alto
tempo de inspeção, como pode ser verificado na Tabela 2.
4.4. Ameaças a validade do estudo
Em todos os estudos experimentais existem ameaças que podem afetar a validade dos
resultados. As ameaças relacionadas a este estudo são apresentadas a seguir,
classificadas em quatro categorias: validade interna, validade externa, validade de
conclusão e validade de constructo.
Validade Interna: foram consideradas três principais ameaças que representavam um
risco de interpretação imprópria dos resultados: (1) efeitos de treinamento, (2)
classificação de experiência e (3) medição de tempo. Em relação à primeira ameaça,
poderia haver um efeito causado pelo treinamento, caso o treinamento da técnica WDP
tivesse qualidade inferior ao treinamento da WDP-RT. Este risco foi controlado
preparando treinamentos equivalentes com os mesmos exemplos de problemas
detectados aplicando WDP ou WDP-RT. Em relação à classificação de experiência dos
participantes, ela foi uma auto-classificação, com base em número e tipo de
experiências anteriores (experiência na indústria, experiência acadêmica). Finalmente,
sobre a medição do tempo, foi solicitado aos participantes que eles fossem muito
precisos nas suas medições, porém não há garantia que o tempo relatado foi realmente
medido cuidadosamente.
Validade Externa: três questões foram consideradas: (1) provavelmente estudantes não
são bons substitutos para inspetores da indústria; (2) normalmente ambientes
acadêmicos não simulam totalmente as condições existentes em um ambiente de
desenvolvimento industrial; e (3) validade do portal SBC como representante de
aplicações Web. Sobre a questão (1), a maior parte dos estudantes possuía experiência
em engenharia de sistemas em ambiente industrial. Mesmo os estudantes que não
possuem experiência em aplicações na indústria podem apresentar habilidades similares
a inspetores menos experientes. Adicionalmente, CARVER et al. (2003) apontam uma
série de benefícios que pesquisadores podem obter de estudos experimentais com alunos
como participantes. Em relação à questão (2), o objeto da inspeção (portal SBC) é uma
aplicação Web real. Sobre a questão (3), não é possível afirmar que o portal SBC
represente todo tipo de aplicação Web, uma vez que são várias as categorias de
aplicações (KAPPEL et al. 2006).
Validade de Conclusão: o maior problema é o tamanho da amostra, com um número
pequeno de data points, não ideal do ponto de vista estatístico. Devido a este fato, há
limitação nos resultados, sendo estes considerados não conclusivos, e sim indícios.
Validade de Constructo: referente a este tipo de ameaça de validade, considerou-se a
definição dos indicadores. Os indicadores adotados neste estudo - Eficiência e Eficácia
- são comumente utilizados em estudos que investigam técnicas de detecção de defeitos
131
ESELAW’09
e estes indicadores foram medidos utilizando a mesma abordagem proposta por
DENGER e KOLB (2006) e aplicada em (CONTE et al. 2007a).
5. Conclusões e trabalhos futuros
Este artigo apresentou uma técnica de leitura para inspeção de usabilidade de aplicações
Web, a WDP-RT, baseada na extensão da técnica WDP. O desenvolvimento da técnica
está sendo de acordo com uma metodologia baseada em experimentação. No primeiro
estudo experimental realizado, um estudo de viabilidade, os resultados obtidos apontam
que a WDP-RT é viável e possivelmente mais eficaz e tão eficiente quanto a WDP. No
entanto, devido à pequena amostra, não é possível considerar este resultado conclusivo,
sendo necessário repetir este estudo com um maior número de participantes.
Como trabalhos futuros, temos a evolução da WDP-RT para uma nova versão,
considerando os resultados quantitativos e qualitativos obtidos neste estudo, a fim de
tornar a inspeção menos cansativa e mais ágil. Seguindo a metodologia experimental,
será realizado um estudo de observação, já com a nova versão da WDP-RT. Este estudo
visa coletar dados de como os inspetores aplicam a técnica, com o propósito de
responder a segunda questão da metodologia: “Os passos do processo fazem sentido?”.
É preciso investigar se a WDP-RT oferece maior apoio aos inspetores novatos, fato que
não pode ser constatado neste estudo. Pretende-se também verificar as causas da
diferença no resultado individual dos inspetores utilizando a WDP-RT (ver Tabela 2),
onde podemos verificar que o inspetor com melhor desempenho, considerando-se a
média de defeitos por hora, teve um desempenho quase três vezes melhor que o inspetor
com pior desempenho (11 defeitos/hora x 4,5 defeitos/hora).
Agradecimentos
Os autores agradecem a todos que participaram do estudo experimental e ao CNPq,
FAPERJ, à FAPEAM e à Trópico Telecomunicações Avançadas pelo apoio financeiro.
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
CONTE, T., 2009. “Técnica de Inspeção de Usabilidade Baseada em Perspectivas de Projeto
Web”. Rio de Janeiro: UFRJ/COPPE 194 p. Tese (Doutorado) – UFRJ/ COPPE/ Programa
de Engenharia de Sistemas e Computação.
CONTE, T., MASSOLAR, J., MENDES, E., TRAVASSOS, P. G. H., 2009a. “Web Usability
Inspection Technique Based on Design Perspectives.” IET Software Journal, v. 3, n. 2, pp.
106-123.
CONTE, T., VAZ, V., MASSOLAR, J., MENDES, E., TRAVASSOS, G. H., 2009b
"Improving a Web Usability Inspection Technique using Qualitative and Quantitative Data
from an Observational Study". In: XXIII Simpósio Brasileiro de Engenharia de Software SBES 2009 (accepted for publication), Fortaleza, Brazil.
DAVIS, F., 1989. "Perceived usefulness, perceived ease of use, and user acceptance of
information technology." MIS Quarterly, v. 13, n. 3, pp. 319-339.
DENGER, C., KOLB, R., 2006. "Testing and inspecting reusable product line components: first
empirical results". In: Proceedings of the 2006 ACM/IEEE international symposium on
Empirical software engineering (ISESE 2006), pp. 184 – 193, Rio de Janeiro, Brazil.
September 2006.
GOMES, M., CONTE, T., 2009. “WDP-RT: Uma técnica de leitura para inspeções de
usabilidade de aplicações Web”. Relatório técnico RT-DCC-ES001/2009. DCC/ UFAM.
ISO/IEC 9126-1, International Organization for Standardization. “Information Technology –
Software Product Quality. Part 1: Quality Model”. 1999.
JURISTO, N., MORENO, A., SANCHEZ-SEGURA, M.-I., 2007. “Guidelines for Eliciting
Usability Functionalities”. IEEE Transactions on Software Engineering, v. 33, n. 11, pp.
744-758.
FERREIRA, S. B. L., LEITE, J. C. S. P., 2003. “Avaliação da Usabilidade em Sistemas de
Informação: O Caso do Sistema Submarino”. Revista de Administração Contemporânea RAC, Curitiba, PR, v. 7, n. 3, p. 115-136.
KAPPEL, G., PRÖLL, B., REICH, S., RETSCHITZEGGER, W., 2006. "An Introduction to
Web Engineering".In: Kappel, G., Pröll, B., Reich, S., Retschitzegger, W. (eds), Web
Engineering: The Discipline of Systematic Development of Web Applications, John Wiley \
& Sons.
MAFRA, S., BARCELOS, R., TRAVASSOS, G. H., 2006. “Aplicando uma metodologia
Baseada em Evidência na Definição de Novas Tecnologias de Software”. In: Proceedings of
the 20th Brazilian Symposium on Software Engineering (SBES 2006), v. 1, pp. 239 – 254,
Florianopolis.
MATERA, M., RIZZO, F., CARUGHI, G. T., 2006. “Web Usability: Principles and Evaluation
Methods”. In: Mendes, E., Mosley, N. (eds), Web Engineering, Chapter 5, New York,
Spinger Verlag.
NIELSEN, J., 1993. “Usability Engineering”. Academic Press, Cambridge, MA.
NIELSEN, J., 1994. “Heuristic evaluation”. In: Jacob Nielsen, Mack, R. L. (eds), Usability
inspection methods, Heuristic Evaluation, New York, NY, John Wiley & Sons, Inc.
NIELSEN, J.,1999. “Design Web Usability”. New Riders Publish, Indianapolis, Indiana, USA.
PRATES, R. O., BARBOSA, S. D. J., (2003). “Avaliação de Interfaces de Usuário - Conceitos
e Métodos”. In: Coello, J. M. A., Fabbri, S. C. P. F. (eds), Jornada de Atualização em
Informática do Congresso da Sociedade Brasileira de Computação, Capítulo 6, Campinas.
PREECE, J.; ROGERS, Y.; SHARP, E. (2002) “Interaction Design: Beyond Human-computer
Interaction”. New York, NY: John Wiley & Sons. 2002.
SHULL, F., CARVER, J., TRAVASSOS, G. H., 2001. “An empirical methodology for
introducing software processes”. ACM SIGSOFT Software Engineering Notes, v. 26, n. 5,
pp. 288-296.
TRAVASSOS, G. H., SHULL, F., FREDERICKS, M., BASILI, V., 1999. “Detecting defects in
object-oriented designs: using reading techniques to increase software quality.” ACM
SIGPLAN Notices, v. 34, n. 10, pp. 47-56.
133

ESELAW 2009 - Departamento de Computação

Transcrição

Documentos relacionados

Circular 28 - Sindicato dos Bancários do Norte

Engenharia da Computação

w orkshop

Eduardo Siqueira Brick, PhD.

Engenharia da Computação

Utilizando Experimentação para Apoiar a Pesquisa em Educação

Nota de imprensa Workshop Critical: Lisbon_143 KB

Engineering no mercado de Gas

separados por dois pontos – centralizados e sem

workshop “elabore um traje medieval”