Proceedings of 6th Experimental Software Engineering Latin ...eselaw09/proceedingsEselaw2009.pdf ·...

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 (DC-UFSCar, Brazil) -- General Chair

Guilherme Horta Travassos (COPPE/UFRJ, Brazil)

José Carlos Maldonado (ICMC-USP, Brazil)

Márcio Eduardo Delamaro (ICMC-USP, Brazil)

Manoel G. de Mendonça Neto (UFBA, Brazil)

Program Committee

Auri M. R. Vincenzi (UFG, Brazil) -- Program Chair

Ana M. Moreno (Universidad Politecnica de Madrid, Spain)

Andreas Jedlitschka (IESE-Fraunhofer, Germany)

Cleidson Ronald Botelho de Souza (UFPA, Brazil)

Ellen Francine Barbosa (ICMC-USP, Brazil)

Emilia Mendes (Auckland University, New Zeland)

Fabio Kon (IME-USP, Brazil)

Giovanni Cantone (Tor Vergata, Italy)

Guilherme Horta Travassos (COPPE-UFRJ, Brazil)

Jeffrey Carver (University of Alabama, Tuscaloosa, EUA)

José Carlos Maldonado (ICMC-USP, Brazil)

Manoel G. de Mendonça Neto (UFBA, Brazil)

Marcello Visconti (UTFSM, Chile)

Marcos L. Chaim (EACH-USP, Brazil)

Marcio Eduardo Delamaro (ICMC-USP, Brazil)

Natalia Juristo (Politecnica de Madrid, Spain)

Sandro Morasca (Università dell´Insubria, Italy)

Support Committee

Daniel de Paula Porto (DC-UFSCar, Brazil)

Deysiane Matos Sande (DC-UFSCar, Brazil)

Elis Cristina Montoro Hernandes (DC-UFSCar, Brazil)

Erika Höhn (ICMC-USP, Brazil)

Fernanda Aparecida R. da Silva (DC-UFSCar, Brazil)

Guilherme Freire (DC-UFSCar, Brazil)

Lucas Bueno Ruas de Oliveira (ICMC- USP, Brazil)

Organizing Committee

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 (ICMC - USP, Brazil)

Alfredo Goldman (IME - USP, Brazil)

André Domingues (ICMC - USP, Brazil)

Anna Grimán (Simón Bolívar University, Venezuela)

Arilo Dias Neto (COPPE - UFRJ, Brazil)

Arlindo da Conceição (DCT - UNIFESP, Brazil)

Claudia de O. Melo (IME - USP, Brazil)

Debora Paiva (UFMS, Brazil)

Delano Medeiros Beder (EACH - USP, Brazil)

Edmundo Spoto (UNIVASF, Brazil)

Edson Moreira (ICMC - USP, Brazil)

Elisa Yumi Nakagawa (ICMC - USP, Brazil)

Erika Hohn (ICMC - USP, Brazil)

Esteban Fernandez Tuesta (ICMC - USP, Brazil)

Fabiano Cutigi Ferrari (ICMC - USP, Brazil)

Fabio Lucena (UFG, Brazil)

Felipe Besson (EACH - USP, Brazil)

Juliano Oliveira (UFG, Brazil)

Katia Felizardo (ICMC - USP, Brazil)

Marcelo Morandini (EACH - USP, Brazil)

Marco Silva (USP, Brazil)

Marco Antônio P. Araújo (COPPE– UFRJ, Brazil)

Maria Istela Cagnin (UFMS, Brazil)

Martin Solari (ORT University, Uruguay)

Otávio Lemos (ICMC-USP, Brazil)

Paulo Bernardo (USP, Brazil)

Paulo Sérgio Santos (UFRJ, Brazil)

Pedro Treccani (UFPA, Brazil)

Plínio Leitão-Júnior (UFG, Brazil)

Rafael Prikladnicki (PUCRS, Brazil)

Rogério Eduardo Garcia (UNESP, Brazil)

Rosana Braga (ICMC – USP, Brazil)

Rudinei Goularte (ICMC – USP, Brazil)

Tayana Conte (DCC – UFAM, Brazil)

Valter Camargo (UFSCar, Brazil)

Vinícius Humberto Durelli (ICMC – USP, Brazil)

Vitor Lopes (COPPE – UFRJ, Brazil)

Viviane Malheiros (SERPRO/USP, Brazil)

Contents

Invited Talk 2Measuring and Monitoring Technical Debt (Carolyn Seaman) . . . . . . . . . . . 4Free, Libre, Open Source Competence Centers - an opportunity for experimen-

tation (Alfredo Goldman) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Short Courses 6Systematic Review - Scientific Research in Software Engineering (Katia Romero

Felizardo, Rafael Messias Martins and Erika Nina Hohn) . . . . . . . . . . . . 7Using Qualitative Methods in Empirical Studies of Software Engineering (Carolyn

Seaman) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Introduction to Experimental Software Engineering (Manoel G. Mendonca) . . . . 9The Use of Statistical Methods for Planning and Analyzing Experimental Studies

in Software Engineering Area (Guilherme Horta Travassos and Marco Antonio

Pereira Araujo) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Technical Session 1 - Experimentation in Software Engeneering 11A Quantitative Assessment on Team Building Criteria for Software Project

Teams (A. Cesar C. Franca, Evisson Fernandes Lucena, Fabio Q. B. da Silva) . 12Apoio na Concepcao de Workflow Cientıfico Abstrato para Estudos in virtuo e

in silico em Engenharia de Software (Wallace M. Pereira, Marco Antonio P.

Araujo, Guilherme H. Travassos) . . . . . . . . . . . . . . . . . . . . . . . . 22Estudo da Alocacao de Pessoas em Projetos de Software atraves da Teoria

Fundamentada em Dados (Cinthya S. Oliveira, Cleidson R. B. de Souza, Carla

A. L. Reis) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Experimentacao em Engenharia de Software: Glossario de Termos (Vitor Pires

Lopes, Guilherme Horta Travassos) . . . . . . . . . . . . . . . . . . . . . . . 42Rastreabilidade Indutiva Aplicada a Artefatos de Software (Raquel Nitsche dos

Santos, Raul Sidnei Wazlawick) . . . . . . . . . . . . . . . . . . . . . . . . . 52

Technical Session 2 - Systematic reviews 62A Systematic Review on Software Product Lines Scoping (Marcela Balbino S. de

Moraes, Eduardo Santana de Almeida, Silvio Romero de Lemos Meira) . . . . 63Implementacao de Variabilidades de Linhas de Produto de Software utilizando

Aspectos: Uma Revisao Sistematica (Antonio Carlos C. Junior, Thelma Elita

Colanzi, Paulo Cesar Masiero) . . . . . . . . . . . . . . . . . . . . . . . . . . 73Uma Abordagem Visual para Auxiliar a Revisao da Selecao de Estudos Primarios

na Revisao Sistematica (Katia R. Felizardo, Gabriel F. Andery, Jose C. Mal-

donado, Rosane Minghim) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Technical Session 3 - Verification, validation and test 93Granularity on Persistent Data Flow Testing of Active Database Applications

(Plinio S. Leitao Junior, Plinio R. S. Vilela, Mario Jino, Joao C. Silva) . . . . . 94

1

Reducao de Potenciais Defeitos atraves da Deteccao de Anomalias em Diagra-mas de Classes (Isela Macıa, Arndt von Staa) . . . . . . . . . . . . . . . . . 104

Reutilizacao de Conjuntos de Teste: Um Estudo no domınio de Algoritmos deOrdenacao (Diogo Nascimento Campanha, Simone do Rocio S. Souza, Otavio

Augusto L. Lemos, Ellen Francine Barbosa e Jose C. Maldonado) . . . . . . . 114WDP-RT: Uma tecnica de leitura para inspecao de usabilidade de aplicacoes

Web (Marcos Gomes, Davi Viana, Lennon Chaves, Andreza Castro, Veronica

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 recently-

initiated research projects in the area of Experimental Software Engineering that have

the USP competence center as its testbed.

Alfredo Goldman received his B.Sc. in applied mathematics from University of São

Paulo, Brazil, his M.Sc. in computer science also from University of São Paulo, and his

doctorate in computer science from the Institut National Polytechnique de Grenoble,

France. He currently is an associated professor in the Department of Computer Science

at University of São Paulo. His research interests include parallel and distributed

computing, mobile computing and grid computing.

5

INVITED SHORT COURSES

6

Systematic Review - Scientific Research in Software

Engineering

Katia Romero Felizardo, Rafael Messias Martins and Erika Nina Höhn

The results produced by traditional literature reviews can be limited and of questionable

scientific value if not guided by a sound process. The systematic review approach

provides a comprehensive and systematic evaluation of research using a predefined

strategy of search aiming at minimizing bias. The term systematic review is used to

refer to thorough and fair methodology of literature review and it is used to

summarizing, assessing and interpreting the relevance of all research related to a

specific question, topic area, or phenomenon of interest. This is an introductory course

on systematic review. Its first goal is to motivate and illustrate the application of

systematic reviews in the software engineering area. A complete example is provided in

order to give the attendees a notion on the advantages, limitations and constraints of

systematic reviews in practice.

Katia Romero Felizardo has a MSc. degree in Computer Sciences from the

Universidade Federal de São Carlos (UFSCar). She has been assistant professor at

Universidade do Oeste Paulista (UNOESTE), Universidade Estadual de Londrina

(UEL) and Universidade Estadual do Norte do Paraná (UENP). Currently she is PhD

student in Computer Sciences at Universidade de São Paulo (USP), campus of São

Carlos, and has experience in software engineering, focused mainly in the subjects:

Software Quality, Systematic Review of Literature, Ontologies and Information

Visualization.

Rafael Messias Martins is B.Sc. in Computer Science from the Universidade Estadual

Paulista Julio de Mesquita Filho (UNESP), and currently is M.Sc. student at the

Instituto de Ciências Matemáticas e de Computação at the Universidade de São

Paulo(ICMC/USP). His research interests include mainly Software Engineering and

Information Visualization, with emphasison Systematic Reviews (and Ontologies),

Software Architecture and Reengineering.

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 Lucena

1,2, Fabio Q. B. da Silva

1

1Centro de Informática – Universidade Federal de Pernambuco (CIn – UFPE) CEP

50732 - 970 – Recife – PE – Brasil

2Coordenadoria 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


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


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


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) Low – Medium – High

Importance level of Si (i = 1 … 2) Low – Medium – High

Level of formal use of Si (i = 1 … 2) Low – Medium – High

15


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 small-

business, 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

Low Medium High 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?

( ) ( ) ( )

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)? Not

Satisfied Satisfied

Strongly

satisfied

M1. Costs ( ) ( ) ( ) M2. Implementation date ( ) ( ) ( )

…

How were the goals listed below satisfied by the project B (failed)? Not

Satisfied Satisfied

Strongly

satisfied

M1. Costs ( ) ( ) ( ) M2. Implementation date ( ) ( ) ( )

…

Both questionnaires have passed through a pre-test evaluation, performed with 5

project managers. They are described above already with the improvements resulted

1 According to the standards from IBGE – Instituto Brasileiro de Geografia e Estatística.

16


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.

Table 5: Evaluation of the success goals on the successful projects

Su

ccess

Goa

ls

Achievement Level

Not

Satisfied Satisfied

Strongly

Satisfied

M1 4.2% 8.3% 87.5%

M2 16.7% 4.2% 79.2%

M3 8.3% 0.0% 91.7%

M4 4.2% 8.3% 87.5%

M5 0.0% 12.5% 87.5%

M6 8.3% 0.0% 91.7%

Table 6: Evaluation of the success goals on the failed projects

Su

ccess

Goa

ls

Achievement Level

Not

Satisfied Satisfied

Strongly Satisfied

M1 75.0% 4.2% 20.8%

M2 91.7% 0.0% 8.3%

M3 50.0% 16.7% 33.3%

M4 87.5% 8.3% 4.2%

M5 66.7% 8.3% 25.0%

M6 58.3% 12.5% 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


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

Success Goals Achievement level Not satisfied

(n = 24)

Satisfied

(n = 24)

Strongly

Satisfied

(n = 24)

M1 Costs p=0.000 p=0.555 p=0.000

M2 Implementation date p=0.000 p=0.317 p=0.000

M3 Functionality/scope p=0.000 p=0.388 p=0.000 M4 Effective project team work p=0.000 p=1.000 p=0.000

M5 User satisfaction p=0.000 p=0.640 p=0.000

M6 Professional satisfaction on the part of the project manager p=0.000 p=0.077 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.

Table 8: Formalization level of the team building criteria on successful projects

Tea

m B

uil

din

g C

rite

ria

Formalization level

Low Medium High

C1 0.0% 4.2% 95.8%

C2 16.7% 16.7% 66.7%

C3 12.5% 16.7% 70.8%

C4 25.0% 20.8% 54.2%

C5 12.5% 16.7% 70.8%

C6 8.3% 20.8% 70.8%

S1 12.5% 8.3% 79.2%

S2 16.7% 8.3% 75.0%

Table 9: Formalization level of the team building criteria on failed projects

Tea

m B

uil

din

g C

rite

ria

Formalization level

Low Medium High

C1 29.2% 29.2% 41.7%

C2 45.8% 16.7% 37.5%

C3 54.8% 20.8% 20.8%

C4 45.8% 25.0% 29.2%

C5 54.2% 20.8% 25.0%

C6 54.2% 20.8% 25.0%

S1 41.7% 8.3% 50.0%

S2 50.0% 0.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

Team building criteria Formalization level Low

(n=24)

Medium

(n=24)

High

(n=24)

C1 Technical profile p=0,005 p=0,021 p=0,000 C2 Individual costs p=0,031 p=1,000 p=0,045

C3 Experience and Productivity p=0,001 p=0,714 p=0,001

C4 Availability of human resources p=0,135 p=0,734 p=0,082 C5 Personality p=0,002 p=0,714 p=0,002

C6 Behavioral skills p=0,001 p=1,000 p=0,002

S1 Project importance p=0,024 p=1,000 p=0,037 S2 Customer importance p=0,015 p=0,153 p=0,077

() - Significant differences only for p ≤ 0.05

18


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

Tea

m B

uil

din

g C

rite

ria

Importance Level

Low Medium High

C1 4,2% 8,3% 87,5%

C2 16,7% 8,3% 75,0%

C3 4,2% 4,2% 91,7%

C4 25% 16,7% 58,3%

C5 8,3% 16,7% 75,0%

C6 4,2% 8,3% 87,5%

S1 4,2% 4,2% 91,7%

S2 4,2% 12,5% 83,3%

Table 12: Importance order of the team building criteria, according to the Project

managers’ opinions

1. 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


software engineering field still are building their teams based heavily on their own past-

experiences.

However, França et. al. (2008) made an exploratory research with the goal to

empirically identify some of the criteria used by project managers to build successful

teams. The main objective of the research described in this article was to assess the

effectiveness of the use of those criteria by calculating the statistical correlation of them

with project success goals.

From a carefully planned field research, it was possible to conclude that the

analysis of technical profile, experience and productivity, personality, and behavioral

skills are positively related to the project success among the studied sample.

Complement other researches in the area, the results presented here also emphasize

individual costs, customer importance and project importance as relevant factors to be

considered in team building. Individual costs, specially, are not described explicitly in

the team building literature, even though it is consistent with the project management

literature (PMI, 2004). On the other hand, there is no significant correlation between

availability of human resources and neither project success nor project failure.

This paper’s main 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 non-

parametric test that makes the results weaker than using parametric tests, which was

impracticable in this research.

Beyond the effectiveness of the team building criteria, verified through a

practical experience, there are two other noteworthy results. The first one would be the

tools designed to assess and correlate team building criteria and project goals, including

the data packet resulting from the research. The second would be the methodology

prepared for this field research, which could be used for future work to verify factors

with similar data behavior.

Finally, it is important to emphasize that this article is a part of a wider research,

which aims to study the whole of team lifecycle management on software engineering

organizations. Also, both industry and academy have shown an increasing interest for

this theme.

References

BATITUCCI, M. D. (2002) Equipes 100% - O novo modelo do trabalho cooperativo no

3º milênio. São Paulo: Makron Books.

BECKER, M.; BURNS-HOWELL, J.; KYRIAKIDES, J.(2000) IS Team effectiveness

factors and performance, 2000.

BROOKS, F. P. (1975) The Mythical Man-Month: Essays on Software Engineering.

Addison-Wesley Professional, 1975, ISBN 0201835959, 336p.

DeMARCO, T.; LISTER, T. (1987) Peopleware: Productive Projects and Teams. New

York: Dorset House Publishing Co, ed. 2, 1999.

20


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



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 infra-structures 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


em ambientes virtuais, compostos por modelos computacionais. Nos estudos in silico tanto os participantes quanto o ambiente são simulados, ao contrário do s 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 experi-mentaçã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 pro-dutos 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 recu-pera 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 pesquisa-dor 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


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


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

Nova rodadade inspeção

Avançar naconcepção

Inspecionar a especificação do workflow

científico

Validar a especificação do workflow

científico

Nãovalidado

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 pro-cesso de decaimento do software ao longo do tempo, através da simulação do compor-tamento 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 repre-sentam 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, periodici-

25


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].

Coleta de Métricas

Construção Planilha

Geração das

EquaçõesEngenheirode Software

Simulação Evolução de

SoftwareFerramenta para

Dinâmica de Sistemas

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, espera-se 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


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 ExperimentoPreparar dadospara simulação

Gerar asequações para

simulação

Simular aevolução do

softwareFim Experimento

Análise doresultado dasimulação

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.

«structured»Preparar dados para

simulação

Tabela comversões dosoftware

Dados reais doprocesso dedesenvolvimento

«structured»Gerar as equações para

simulação


Equações parasimulação

Final_Simulacao_Decaimento

«decisão»{Equações representam o modelo dinâmico?}

«decisão»{Base de medidas das versões é válida e suficiente para gerar as equações?}

Inicio_Simulacao_Decaimento «datastore»Base de medidas da

organização

«structured»Simular a evolução do

software

Equações parasimulaçãoDados da

simulação daevolução

«decisão»{Qual é origem do problema? Ação a ser tomada?}

«Semi-automatizada»Análise do resultado da

simulaçãoDados dasimulação daevolução

Análise doresultado dasimulação

[SIM]

[NÃO]

[SIM]

[MODIFICARMEDIDAS DOSOFTWARE]

[MODIFICAREQUAÇÕESPARASIMULAÇÃO]

[NÃ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 sub-workflows permitiu uma melhor organização, pois deixa os modelos mais legíveis para o pesquisador.

«structured»Gerar as equações para simulação


Equações parasimulaçãoInicio_Gerar_Equações

Final_Gerar_Equações«Semi-automatizada»Criar equações da

simulaçãoVersão base

Tabela com versões do software

Equações parasimulação

«Manual»Definir versão base

da simulação Versão base

Tabela com versões do software

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 utili-zada 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


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 Criar equações da simulação Descriçã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.

Tipo de Atividade Semi-Automatizada Papéis Engenheiro de Software Obrigatoriedade Obrigatória Pré-condições Nenhuma Ferramentas Tabela_Excel Pós-condições Nenhuma Produtos Equações para simulação Pré-atividades Definir versão base da

simulação Insumos Tabela com versões do software; Versão base

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.

Utilização Atividade Entrada/ Saída

Obrigatoriedade Formato Digital. Origem Interna

Criar equações da simulação Saída Obrigatória Ferramenta Tabela_Excel Simular evolução Entrada Obrigatória Sinônimos Nenhum

Tabela 3 – Formulário ferramenta Tabela_Excel.

Ferramenta Tabela_Excel Descrição 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.

Tipo de aplicação Interface Formatos Suportados Formato “.xls”. Versão Não há. Local de Execução Local Sistema Operacional 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


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 defei-tos no documento. Ainda, a captura das informações é realizada através de três modelos, um para capturar o fluxo de dados, outro para controle e um para hierarquia entre as atividades. Quanto ao modelo de hierarquia, o diagrama de atividades permite a repre-sentação de atividades compostas e, em geral, as ferramentas já mantém a consistência entre a atividade e seu modelo interno. Já sobre os fluxos de controle e dados, quando separados, pode haver inconsistência entre as informações nos diversos modelos. Além disso, muitos modelos diferentes podem gerar inconsistência na documentação e so-mente usar modelos, como em Verdi et. al. (2007), pode acabar por não capturar algu-mas informações consideradas importantes (e.g. pré e pós-condições, papéis ou riscos).

Alguns sistemas utilizam o conceito de template para representar o estudo experimental abstratamente. Contudo, os templates são dependentes do SGWfC e à sua infra-estrutura de execução, onde foram concebidos. Gil et al. (2007) e Kaster et al.

29


(2005) apresentam abordagens desse tipo. Esses sistemas permitem que um pesquisador com bom conhecimento do estudo defina o template que, posteriormente, é instanciado para uma infra-estrutura computacional provida pelos sistemas. Porém, isto acarreta uma forte dependência entre o estudo, o template e a plataforma na qual foram conce-bidos, afinal ele só é utilizado no próprio SGWfC. O estudo acaba ficando restrito, pois a especificação que deveria ser independente de linguagem, ou máquina de workflow, já é concebida pensando em questões relacionadas ao SGWfC. Afinal, os requisitos são os mesmos para o estudo, não importando o SGWfC a ser utilizado.

6. Conclusão A experimentação baseada em simulação vem sendo cada vez mais utilizada em Engenharia de Software [Travassos & Barros, 2003]. Outras áreas da ciência também fazem uso da simulação e, para concretizá-la, utilizam tecnologias como workflows científicos. A Engenharia de Software, em especial a experimental, pode também utilizar tais tecnologias para obter vantagens, como controle, automação da execução e proveniência dos dados gerados em estudos experimentais baseados em simulação. Por isso, foi proposta uma abordagem para apoiar o pesquisador a especificar e gerar workflows científicos abstratos para estudos in virtuo e in silico [Pereira & Travassos, 2009]. Entendemos que a concepção de workflow científicos, em nível abstrato, deve ser independente de SGWfC, pois o estudo em si é independente de tecnologias e a sua execução deveria ser possível, a princípio, em qualquer infra-estrutura.

Este artigo apresentou a aplicação da Abordagem de Concepção no domínio da observação da Evolução de Software. Através do uso da abordagem, foi possível captu-rar o processo para Simular a Evolução de Software de maneira incremental. O modelador e pesquisador responsável identificaram, inicialmente, as atividades e o seus objetivos, artefatos gerados e consumidos e ferramentas, gerando ao final uma especificação do workflow abstrato. Os formulários, quando utilizados, induzem a identificação das informações necessárias para o estudo e sua representação em workflow abstrato, levando à percepção de detalhes ou conhecimento não explicitado se feito de forma ad hoc. A formalização do estudo permite a posterior exploração dessa especificação como insumo para uma implementação em algum SGWfC ou ambiente computacional.

A abordagem utilizada neste trabalho ainda está em desenvolvimento para apoiar experimentação baseada em simulação em Engenharia de Software. Melhorias já estão previstas, tal como uso de técnica de inspeção mais formal, por exemplo, checklists calibrados para guiar o inspetor na verificação de questões importantes para o domínio ou na completude das informações. No momento, está sendo revisada de forma mais sistemática a literatura técnica em busca de possíveis abordagens que atendam e possam ser adaptadas a este contexto de estudo in virtuo e in silico. O volume de informações e a repetição de tarefas indicam a necessidade de apoio computacional para melhorar o gerenciamento do conteúdo e inserção automática de informações (e.g., insumos e pro-dutos, pré-atividades, dentre outras), visando diminuir problemas com a consistência entre as informações e o esforço na manipulação e preenchimento dos formulários.

30


Agradecimentos Este trabalho é parte do projeto Engenharia de Software Experimental e Ciência em Larga Escala - CNPq (475459/2007-5) e FAPERJ. Os autores agradecem também a ao CAPES e FINEP por apoiar esta pesquisa.

Referências Araújo, M. A. P. (2009) "Um Modelo para Observação de Evolução de Software", Tese de

Doutorado, PESC/COPPE, Rio de Janeiro, UFRJ, p. 191. Deelman, E. et al. (2009) “Workflows and e-Science: An overview of workflow system features

and capabilities”, In: FGCS, v. 25, n. 5, pp. 528-540. Gil, Y. et al. (2007) “Wings for Pegasus: Creating Large-Scale Scientific Applications Using

Semantic Representations of Computational Workflows”, IAAI’07, Vancouver, Canadá, p. 1767-1774.

Kaster, D.; Medeiros, C.; Rocha, H., (2005) “Supporting modeling and problem solving from precedent experiences: The role of workflows and case-based reasoning”, Environmental Modelling and Software, v. 20, pp. 689-704.

Kavanagh, J.; Hall, W. (2008) “Grand Challenges in Computing Research 2008”, http://www.ukcrc.org.uk/grand_challenges/news/gccr08final.pdf.

Juristo, N.; Moreno, A.M. (2001) “Basics of software engineering experimentation”, 1st ed., Kluwer Academic Publishers, 395p.

Lehman, M.M.; Perry, D.E.; Ramil, J.F. (1998), “Implications of Evolution Metrics on Software Maintenance”, In:ICSM, v. 16, ed. 20, pp 208 – 217.

Mattos, A. et al. (2008) “Gerência de Workflows Científicos: uma análise crítica no contexto da bioinformática”, COPPE/UFRJ, PESC, Technical Report ES-716/08.

Mattoso, M. et al. (2008) “Gerenciando Experimentos Científicos em Larga Escala” In: SBC-SEMISH´08, Belém, Brasil. p.121-135.

Medeiros et. al., C.B. (2005) “WOODSS and the Web: annotating and reusing scientific workflows”, SIGMOD Record, v. 34, n. 3, p. 18-23.

Oinn, T. et. al. (2007) "Taverna/myGrid: Aligning a Workflow System with the Life Sciences Community", In: Workflows for e-Science, Springer, p. 300-319.

Object Management Group (2009) “OMG Unified Modeling Language Specification”, versão 2.2, formal/09-02-02, http://www.omg.org/spec/UML/2.2/.

Pereira, W. M., Travassos, G.H. (2009) “Abordagem para concepção de experimentos científicos em larga escala suportados por workflows científicos” In: 3 E-Science Workshop colocado ao SBBD/SBES, Fortaleza, Brasil, in press.

Pfleeger, S. L. (2004) “Engenharia de Software: Teoria e Prática”, 2nd ed., Prentice Hall, 560p. Sociedade Brasileira de Computação (2006). Grandes Desafios da Computação no Brasil:

2006-2016, http://www.sbc.org.br/index.php?language=1&content=downloads&id=272. Travassos, G. H.; Barros, M. O. (2003) “Contributions of In Virtuo and In Silico Experiments

for the Future of Empirical Studies in Software Engineering”, In: ESEIW 2003 - WESSE, Roma, Italy, pp. 117–130.

Verdi, K.; Ellis, H.; Gryk, M. (2007) “Conceptual-level workflow modeling of scientific experiments using NMR as a case study”, BMC Bioinformatics, v. 8, n. 31, 12p.

Wohlin, C. et al. (2000) “Experimentation in Software Engineering”, Kluwer Academic Publishers, 204p.

Zhang, H., Kitchenham, B., and Pfahl, D. (2008) “Software Process Simulation Modeling: Facts, Trends and Directions”, In Proceedings of the 2008 15th APSEC. IEEE Computer Society, Washington, DC, pp. 59-66.

31


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


(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


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 CMMI-ní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


(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


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


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


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


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


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/2008-3) e pela Fundação de Amparo à Pesquisa do Estado do Pará (FAPESPA) através do Edital Universal N.° 003/2008 e do Edital de Apoio a Grupos de Pesquisa No 017/2008.

40


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


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


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


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


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


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


Figura 2. Repositório de conhecimento de Experimentação

em Engenharia de Software [Lopes e Travassos, 2009]

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].

47


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


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


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


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


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


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 MPS-

BR 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


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


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


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.

2- Seleciona o

elemento-causa

1- Seleciona o

artefato dedestino

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.

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.

2

3

1

56


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


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. Conclui-

se 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


buscam uma forma de criar as relações de rastreabilidade que forneça um bom custo-

benefício.

A principal vantagem da técnica indutiva comparada a matriz de relacionamentos

está no fato de que o desenvolvedor pode criar os relacionamentos de rastreabilidade de

forma integrada aos elementos, utilizando apenas o ambiente de criação dos elementos. Já

na matriz de relacionamentos o desenvolvedor deve criar os elementos e depois criar as

relações de rastreabilidade, utilizando para isto dois ambientes, um para a criação de

elementos, outro para a criação dos relacionamentos (matriz). A utilização de dois

ambientes pode tornar mais trabalhoso e menos eficaz o mapeamento da rastreabilidade.

O experimento realizado indicou que a técnica indutiva tende a apresentar uma

maior produtividade em relação às técnicas tradicionais, por meio da criação de um maior

número que relações de rastreabilidade. O esforço despendido para sua utilização pode ser

significativamente menor, tornando a atividade menos penosa, reduzindo o esforço do

desenvolvedor. Desta forma futuramente a técnica indutiva poderia ser utilizada nas

organizações.

Em relação à técnicas de recuperação automática (como LSI), a técnica indutiva não

apresenta as mesmas desvantagens, pois não procura identificar relações a partir de

artefatos existentes. Ao invés disso, a técnica indutiva procura criar as relações de

rastreabilidade no momento da criação dos próprios elementos, o que evita a formação de

falsas relações de rastreabilidade.

A técnica indutiva, por outro lado, propõe que a tarefa executada pelo

desenvolvedor seja redefinida. Ao invés de simplesmente desenhar uma classe em um

diagrama, o desenvolvedor deverá deixar claro o porquê desta classe, ou seja, qual o outro

elemento que fez com que ele chegasse à conclusão de que tal classe seria necessária.

A técnica indutiva proposta é eficaz apenas em sistemas cuja documentação ainda

vai ser produzida, onde se tem a oportunidade de utilizar a técnica desde o início. Ela não

detecta relações que deveriam existir entre elementos e que por alguma razão não foram

incluídas. Estas são limitações da técnica proposta. Nestas situações, ela pode ser

complementada, por exemplo, com a aplicação de recuperação automática.

Referências Bibliográficas

1. Gotel, O.C.Z. e Finkelstein, C.W. (1994) “An analysis of the requirements traceability

problem”, Requirements Engineering: Proceedings of the First International Conference,

p. 94-101.

2. Jiang, H., Nguyen, T. N.; Chang, C. K. e Dong, F. (2007) "Traceability Link Evolution

Management with Incremental Latent Semantic Indexing", In: Proceedings of the 31st

Annual International Computer Software and Applications Conference, IEEE Computer

Society, USA, p.309-316.

3. Lucia, A. D., Fasano, F., Oliveto, R., e Tortora, G. (2007) “Recovering traceability links

in software artifact management systems using information retrieval methods”, ACM

Trans. Softw. Eng. Methodol, USA, p.13.

59


4. Maletic, J. I., Collard, M. L., e Simoes, B. (2005) “An XML based approach to support

the evolution of model-to-model traceability links”, In: Proceedings of the 3rd

international Workshop on Traceability in Emerging Forms of Software Engineering,

ACM, USA.

5. Neumuller, C. e Grunbacher, P. (2006) “Automating Software Traceability in Very

Small Companies: A Case Study and Lessons Learned”, In: Proceedings of the 21st

IEEE/ACM international Conference on Automated Software Engineering, IEEE

Computer Society, USA, p. 145-156.

6. Oliveto, R., Antoniol, G., Marcus, A. e Hayes, J. (2007) "Software Artefact Traceability:

the Never-Ending Challenge", Software Maintenance, IEEE International Conference.

7. Palmer, J. D. (1997) “Traceability”, In: Software Requirements Engineering, R.H.

Thayer and M. Dorfman, p. 364-374.

8. Sparx Systems. (2009) "Enterprise Architect". Disponível em:

http://www.sparxsystems.com/products/ea. Acesso em: 01 mai. 2009.

9. Barbetta, P. A., Reis, M. M. e Bornia, A. C. “Estatística para Cursos de Engenharia e

Informática”. São Paulo: Atlas, 2004.

10. SmartGuyz Incorporatec. (2009) "ScreenCam". Disponível em:

http://www.smartguyz.com/index-2.html. Acesso em: 01 mai. 2009.

11. Marcus, A. and Maletic, J. I. (2003). “Recovering documentation-to-source-code

traceability links using latent semantic indexing”. In Proceedings of the 25th

international Conference on Software Engineering (Portland, Oregon, May 03 - 10,

2003). IEEE Computer Society, Washington, DC, 125-135.

12. Antoniol, G., Canfora, G., Casazza, G., De Lucia, A., and Merlo, E. (2002)

“Recovering Traceability Links between Code and Documentation”. IEEE Trans. Softw.

Eng. 28, 10 (Oct. 2002), 970-983.

13. Murta, L. G., Hoek, A., and Werner, C. M. (2008) “Continuous and automated

evolution of architecture-to-implementation traceability links”. Automated Software

Eng. 15, 1 (Mar. 2008), 75-10.

14. Aldrich, J., Chambers, C., and Notkin, D. (2002) “ArchJava: connecting software

architecture to implementation”. In: Proceedings of the 24th international Conference on

Software Engineering. ICSE '02. ACM, New York.

15. Settimi, R., Cleland-Huang, J., Khadra, O. B., Mody, J., Lukasik, W., and DePalma, C.

(2004) “Supporting Software Evolution through Dynamically Retrieving Traces to UML

Artifacts”. In: Proceedings of the Principles of Software Evolution, 7th international

Workshop. IWPSE. IEEE Computer Society, Washington, DC.

16. Egyed, A., Biffl, S., Heindl, M., and Grünbacher, P. (2005) Determining the cost-

quality trade-off for automated software traceability. In Proceedings of the 20th

IEEE/ACM international Conference on Automated Software Engineering. ASE '05.

ACM, New York, NY, 360-363.

60


17. Lormans, M. and Van Deursen, A. (2006) Can LSI help Reconstructing Requirements

Traceability in Design and Test?. In Proceedings of the Conference on Software

Maintenance and Reengineering, CSMR. IEEE Computer Society, Washington, DC, 47-

56.

18. Antoniol, G., Cimitile, A., and Casazza, G. (2000) Traceability Recovery by Modeling

Programmer Behavior. In Proceedings of the Seventh Working Conference on Reverse

Engineering (Wcre'00), WCRE. IEEE Computer Society, Washington, DC, 240.

19. Egyed, A., Biffl, S., Heindl, M., and Grünbacher, P. (2005) Determining the cost-

quality trade-off for automated software traceability. In Proceedings of the 20th

IEEE/ACM international Conference on Automated Software Engineering ASE '05.

ACM, New York, NY, 360-363.

20. Cleland-Huang, J., Zemont, G., Lukasik, W. (2004) "A Heterogeneous Solution for

Improving the Return on Investment of Requirements Traceability," Requirements

Engineering, IEEE International Conference on, pp. 230-239, 12th IEEE International

Requirements Engineering Conference (RE'04).

21. Cleland-Huang, J. (2006) Just Enough Requirements Traceability. In Proceedings of the

30th Annual international Computer Software and Applications Conference - Volume 01

(September 17 - 21, 2006). COMPSAC. IEEE Computer Society, Washington, DC, 41-

42.

22. De Lucia, A., Fasano, F., Oliveto, R., and Tortora, G. (2006) Can Information Retrieval

Techniques Effectively Support Traceability Link Recovery?. In Proceedings of the 14th

IEEE international Conference on Program Comprehension. ICPC. IEEE Computer

Society, Washington, DC, 307-316.

23. Almeida, J. P., Eck, P. v., and Iacob, M. (2006) Requirements Traceability and

Transformation Conformance in Model-Driven Development. In Proceedings of the 10th

IEEE international Enterprise Distributed Object Computing Conference. EDOC. IEEE

Computer Society, Washington, DC, 355-366.

24. Jesse Fletcher, Jane Cleland-Huang. (2006) "Softgoal Traceability Patterns," Software

Reliability Engineering, International Symposium on, pp. 363-374, 17th International

Symposium on Software Reliability Engineering (ISSRE'06).

25. De Lucia, A., Oliveto, R., Zurolo, F., and Di Penta, M. (2006) Improving

Comprehensibility of Source Code via Traceability Information: a Controlled

Experiment. In Proceedings of the 14th IEEE international Conference on Program

Comprehension. ICPC. IEEE Computer Society, Washington, DC, 317-326.

61

TECHNICAL SESSION 2

Systematic reviews (SR)

62


A Systematic Review on Software Product Lines Scoping

Marcela Balbino Santos de Moraes1, Eduardo Santana de Almeida

2, Silvio Romero

de Lemos Meira1

1Federal University of Pernambuco (UFPE), Brazil

2Federal 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


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


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 the SPL

approaches optimize

scope?

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


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


Table2. Summary of the aspects of the scoping approaches

Approaches

Author

Activities Optimization Scope

Types

Stakehol

ders

Met

rics

Customi

zation

Factors

Agile Relate

clearly

Scoping and

Developmen

t

Riebisch

[2001]

identification, prioritization,

interpretation of features

use priorities

calculation and

decision tables

assets no no no no yes

Kish

[2002]

identify requirements and

products, list and prioritize

architecture candidates,

categorize requirements, examine

candidates for the product-line

scope

do not define

optimization

tasks for scoping

product no no no no no

Schmid

[2002]

identification and description of

products, features and domains,

product map prioritization,

identification and prioritization

of assets

optimize the

feature matrix

using GQM

domain,

assets

no yes no no no

Rommes

[2003]

writing and review of user

scenarios, requirements

identification

do not define

optimization

tasks for scoping

product yes no no no no

Lee [2004] market analysis, feature

modeling, feature binding

analysis, assets identification,

core assets development,

production plan documentation

do not define

optimization

tasks for scoping

assets no no no no no

Helferich

[2005]

identify customer requirements,

product functions and evaluate

different technologies and

architectures

use QFD to

identify the true

needs of the

customers


Park [2005] analysis of commonality and

variability, variability

dependencies analysis, domain

model refinement, economical

evaluation of core asset

do not define

optimization

tasks for scoping

assets no yes no no no

Clements

[2005]

development of scenarios,

attributes/products matrix,

products analysis

do not define

optimization

tasks for scoping


John [2006] mandatory activities: product

identification, plan product

releases, assess features, identify

features, specify product feature

matrix and identify domains

prioritize and

optimized the

feature matrix

domain,

assets

yes yes yes no no

Inoki [2007] product line development plans

analysis, create product line

development plan, create road

map, define organizational

standards

do not define

optimization

tasks for scoping

assets no yes no no no

Noor [2007] identify and agree domains,

define features for each domain,

analyze products, define products

in terms of features, prioritize

product map

make

prioritization

and optimization

of the product

map

domain,

assets

yes no no yes no

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


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


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


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 asset-

based 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


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 Measurement-

Based 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


Helferich, A., Herzwurm, G. and Schockert, S. (2005) “QFD-PPP: Product Line Portfolio

Planning Using Quality Function Deployment”, In: 9th International Software Product Line

Conference, France, p.162-173.

Inoki M., Fukazawa, Y. (2007) “Core Asset Scoping Method: Product Line Positioning Based on

Levels of Coverage and Consistency” In: First International Workshop on Management and

Economics of Software Product Lines, Japan.

John, I., Knodel, J., Lehner, T. and Muthig, D. (2006) “A Practical Guide to Product Line

Scoping”, In: 10th International Software Product Line Conference, USA, p.3-12.

John, I. and Eisenbarth, M. (2009) “A Decade of Scoping – A Survey”, In: 13th International

Software Product Line Conference, USA.

Kishi, T.; Noda, N. and Katayama, T.A (2002) “Method for Product Line Scoping Based on a

Decision-Making Framework”, In: 6th International Software Product Line Conference, USA,

p. 348-365.

Kitchenham, B. and Charters, S. (2007) “Guidelines for Performing Systematic Literature

Reviews in Software Engineering”, In: 11th Evidence-Based Software Engineering, technical

report, USA.

Kruchten, P. (1998) The Rational Unified Process: An Introduction, Reading, Ma.: Addison-

Wesley.

Lee, J., Kang, K. C. and Kim, S. (2004) “A Feature-Based Approach to Product Line Production

Planning”, In: 8th International Software Product Line Conference, USA.

McGregor, J. D. (2008) “Agile Software Product Lines, Deconstructed” In: Journal of Object

Technology, Volume 7, Issue 8, p. 7-19.

Noor, M.A, Rabiser, R.; Grünbacher, P. (2008) “Agile Product Line Planning: A Collaborative

Approach and a Case Study” In: Journal of Systems and Software, Volume 81, Issue 6.

Park, S. Y. and Kim, S. D. (2005) “A Systematic Method for Scoping Core Assets in Product

Line Engineering”, In: 12th Asia-Pacific Software Engineering Conference, USA, p.491-498.

Pohl, K., B¨ockle, G. and Van der Linden, F. (2005) Software Product Line Engineering:

Foundations, Principles, and Techniques.

Riebisch, M., Streitferdt, D. and Philippow, I. (2001) “Feature Scoping for Product Lines”, In:

International Workshop on Product Line Engineering – The Early Steps: Planning, Managing

and Modeling, Germany.

Rommes, E. (2003) “A People Oriented Approach to Product Line Scoping: Enabling

Stakeholder Cooperation with User Scenarios”, In: International Workshop on Product Line

Engineering, Germany, p.284-303.

Schmid, K. (1999) “An Economic Perspective on Product Line Software Development”, In: First

Workshop on Economics-Driven Software Engineering Research, USA.

Schmid, K. (2000) “Scoping Software Product Lines - An Analysis of an Emerging Technology”,

In: Software Product Line Conference, p. 513-532.

Schmid, K. (2002) “A Comprehensive Product Line Scoping Approach and its Validation”, In:

Proceedings of the 24th International Conference on Software Engineering, USA, p. 593-603.

72


��

��

�� !��

��"��"��#$��%&�'��(��"��

%&��"��) ��

*�

�� !"#$�%�&"$'$(#$$ �� )*�%�+��

'� ��,��-.��/.��)��/)0/.��%�/.�� /)�%�+��

[email protected], [email protected], [email protected]

��

��

��!"��#��

��!$�� %��%��%��

�� %� � ��

��%��

�� %� ��

� ��

��

�� %��

��& � ��%� �� '��

�� ()��(*��+��"��)��

��()�� %�� '� �� ()��

�� ,��%��()��$�� %��

�� -��

��)�� '��& �� %��

�� ()��.�� /��()�� ()��

�� 0�� '��

�� %��

%+��

�� 1�2�� )�� /��3�� 1)/�� 4�� 3�� 5�� 2�� 5�� 6��7��8��9��2��###:�� ;� �� 5�� 2�� <�� 1)/ � �=�� 7�� 5�� 1)/�� 2��81�� 1��6��*�4��'$$>:��

?�� ;� �� 5�� 5�� .� �5�� (�� %�� 4�� @��7��@�� 4��

73


� �

?��1)/��A��2�� 7�� 2�� -.�� 2�� 7�� 7�� 7�� <��9��;��5��7��.��B��2��-.��C��-.��-.��-.��7�� D� �� 5�� .�� E��F ��5��7��

G�� C� ��-.�� 1)/� �� 3�� H��89IJ� �KI�6��3��6��L ��'$$!:A�

• �@�� 2�� %��%� �� A� ��(�� 5�� .��.��6��.�M�• �@��2��%�� A��(��5��.��;��6��.�M�• �@��-��%�� A��(��5��.��;��6��

�� .��C��6�-.��@��(�� 5��2��M��2�� 2�� M� � � �� 5�� 2�� N��@�� )�� H�� ;�� ?��-.��?��81�� 1��6��*�4��'$$>:��

��)��-.��?��)?��;��-.��-.��8��2�� *��L �� '$$>:�� ,� �� -.�� @�� 5�� ;� �� (�� )?� �5��6�-.��3��8O��6��##":�� 9�� =�� ;� �� 2�� 2�� 5�� ;�� =��,��)?��-.��1)/�� .�� 6�� .�� ;�� 6�� 5�� 4�� ;��2�� (��(��)��5��4��=�� ;�� .��=��.�� 2�� .�� 7�� -.��5��;��8O��2�2��'$$P:��.��A��4�� -.��-.��2��

�� 4�� .�� 6�� -.�� 7�� C� ��6�-.�� )?�� -.��1)/��?��=��6��A�� /�-.�� '� �� 4�� -.�� .�� /�-.�� Q� �� .�� 2�� )�� /�-.��P��-R��2��

74


��

*+��,��"��

�� .�� 4�� =�� 2��O��2�2��'$$P�� +��2�� '$$!�� ?� �� R��4��)��-.��-� ��(��-.�� -.��.�� B<��6��'$$#��

-�,�� ?� ��4�� .�� ;�� -.�� 1)/� ��6�� )?�� ;� �� =�� 5�� 2�� 6�-.�� )?�� -.��-.��1)/�4��=��

.��/�� 0��5��R��5��-.��.��A�

• G��.�� )��A� G�� ;�� ,� �� 6�� 1)/��S�

• G��.��/��A��5��-R��6�-.��)?��C��-.��1)/S�

• G��.�� /�� 'A� G�� 0�� ,� ��)?��-.��1)/S�

• G��.�� /�� QA� G�� =�� ,� �� -.��1)/��S�

"��1�� 5��R��.�� ;��.��2��A�

• G��.��)��A�K;��1)/��

• G��.��/��A�/��-R��5��6�-.��)?��C��-.��1)/��

• G��.��/��'A�)��0��)?��-.��1)/��

• G��.��/��QA��=��5�� -.��1)/��6��

(��12�� 3�� (�� !��)�� ;�� ,�� 5�� 5��6�� 5�� 4��2��(�2�� K�� .�� 5�,��A�

• T��A��H��=�� 5��H��U��/��

• �� K��2��A� ��,� � �� 7�� 2��7��M�)��,� ��-R�� 7��

75


� �

• )��(�2��A� E�� F� �� E��!�� %��F� �� ,�� E��2��F��E)��-.��?��F��,�� -R��A�

- �� 1� �� !�� !��

- ��!$�� %��1� �� %��%�� $�� !�� $�2��

- �� 1��.�� .�- ��%��()�� $�� 1� $��()�� $��2�� $�� 2�$��

��)��-.��%��(�2��K��C��5��T��2��?��2��;��.��7��

��4�� (5�� 9�� 2�� 5�� 5��6��7�� ;�� 7�� 2�� 5��-.�� 2�� ;�� .� � �� ; � ��2��5��5��R��.��2��5��.��5��R��=��7��;��=��.��

*+%+�"��

��.��6��7��'$$&��4�2��'$$#��'$$&��6��5�� 2��)�� 6��4�2��'$$# � �� 5�� ;�� -.�� T�� 2�� 4�� 5�� ;��2�� 5�� 2�� .�� ?��(�� 5��6��R�� .��=��.��2��

T�� 7�� %�� .� � �� 6��4�-R��(�2��-R�� A�

(linha de produtos OR família de produtos) AND (Programação Orientada a Aspectos OR Orientação a Aspectos OR POA OR Desenvolvimento de Software Orientado a Aspectos OR DSOA)

(product line OR product-line OR product family OR product-family OR family of products) AND (aspect-oriented program OR aspects programming OR AOP OR aspect-oriented software development OR aspect oriented software development OR AOSD)

��C��5��6�� -R��%��D��5��

76


��

��%� �� 6�� .��5��5��

9��-.��#��2��5�� 5�� ""� �� -.�� 2�� 5�� $� �� ?�� 4� � &"� ��2�� 7�� 5�� =�� PQV� �� -.�� &"� �� P>� �� 7�� -.�� T��

�� '$'��2�� =��7��""V��'QV��2�� 7�� "$V��;�� -.��1)/��6��)?� ��5��Q$V��-.��;��T��

��

Figura 1. (a) Estudos incluídos na revisão classificados por fonte; (b) Classifi-cação dos estudos selecionados.�

6+��

?��@��.�� 2��2��(��B<��6��'$$#��T��-.��A��)��-.��1)/��6��)?� ��5��;��6�-.�� 5��.�� .� � �� 5�� .�� =��6��=��

� �� -.�� 5�� R��2�� 4�� ;��2��=�� 7�� 6�� 2��K��2��5��=��5��.��Q�� 5�� 7��-.��

� �� (�� -.�� )?��-.��1)/��7��

77


� �

• �� 74-�8��-�A�G��2��5�� ;�� ?� �� 4�� ;�� T?�� =�� ;�� -.�� (�� 3�� 8�� +��I� '$$>:� ��4��8��6��?��'$$P:��

• �� A� �� 2�� -.��6�-.�� 1)/��

• �� -�� -�,��7--8�,!��5��A� ��1)/� ��-.��4��@��2�� 2��;��-��9�� -.��)?��-.�� 5�� 5�� -.�� )?�� 6�� -.��7��,�� ;��6��7��2��6�-.��@��

• .�� /�� -�A� �� 1)/�;��-.�� 7�� 9�� 2�� 5�� R�� 1)/� �� )��=�� W��2��'$$#��-.��)?��6��-.�� <�� -.�� *�� '$$"�� ;�� 5�� -.�� 1)/��

• ��2��2�� 9��-�A��;��T?� ��2��;��6�-.��-.��4��)?� �� -R��@��8O��6��'$$>:��

• ��:�� -�� 7);;8��A�G�� 2�� 9�� .�� ;�� -R�� 5�� 4�� 1)/�� R�� -.�� 7��)?��-.��8U��2��'$$!:��

• �� 0�� A� ��2��-.��)?��5��.�(�� )��; � ��,�� 6�-.�� 5��1)/ ��7��7��.��)?��6��-.��1)/ �5��%��1)/�4��=��

78


��

• -��)��%� �� 1)/� ??� �� )?� � ��6�-.�� 4�� )?�� %��2��-.��7��1)/ ��-.��5��1)/��)?��-.��1)/��@��

� ?��7�� 7��5X��-R��2��@�� 1)/� �� -R�� U�� ?�� 7�� A�U�� 4�� .� � 0�� /�� 1�� /�� ;��H��

� �� (�� 5�� B� �� -.�� WI��0B � �� 2�� 5�� 6��-.��

� �� K�� '� �� .�� 9�� (�� ;�� -.�� 1)/� �� )?� � �� 9�� (�� 7��-.�� K�� 2�� 2�� R�� )?��;�� T?��)��-.��U��?�� 2�� 6�� )?�� 1)/ � �� =�� )?�� -.��<�� )?��-.��5�� 2�� 5�� 3��5 ��

� ��5��R��'��.��(��7��6�-.��)?��-.��1)/ �� (�� 5�� 7�� 2�� 7�� .�A� �� @�� 2�� -.��(�� @�� 9�� <�� 2�� 7�� 0�� 6�-.�� 1)/��

� *��(��5�� 2��7�� P��!��,��)?��1)/�� .��P'��PQ��-R��)?��??��

<+�"�� /��4��

��6�-.��.�� <�� .�� -.�� ;�� -.�� 1)/��6��)?��

79


� �

Tabela 1 – Sumário das Técnicas e Abordagens Selecionadas

'�� (�� 3��=��

�-��

��

�-��

� �'� ��4��T?��)?�� 9.�� 9.��Q� ��4��T?��)?�� /�� /��P� ��4��T?��)?�� /�� 9.��

! �>� ��-.��)?��1)/�??� /�� 9.��" �&� ��-.��)?��1)/�??� 9.�� 9.��

# �� P ��! ��> ��"�

��R��-.��)?�� /�� 9.��

�$ ��Q� ��R��-.��)?�� 9.�� 9.��'� ��R��-.��)?�� 9.�� /��&� 6��%��1)/�??��)?�� 9.�� 9.��

�# �'$� /��-.�� 9.�� 9.��'� �''� ��4��)?�� 9.�� 9.��

'Q �'P �'!� ��4��)?�� 9.�� 9.��'>� ��4��)?�� /�� 9.��

'"� ��-.��1)/��

�@��)?��9.�� 9.��

'&� ��)?��5��1)/� 9.�� 9.��'#� ��4��%��2��)?�� 9.�� 9.��

Q$ �Q� �Q'��)?��-.��5��

��/�� 9.��

Tabela 2 – Sumário dos Estudos de Caso Selecionados

'�� ;��=�� 3��=��

�-��

��

�-��

QQ �Q> �Q"� ��2��@�� 9.�� 9.��QP ��P �Q! �Q& �Q#� ��2��@�� /�� 9.��

P$� U�� 4��.�� 9.�� 9.��P�� 0�� 9.�� 9.��P'� �� 9.�� 9.��PQ� ��;��H��(�� /�� /��PP� /��1�� 9.�� 9.��!� /�� /�� 9.��

P! �P>� U)1��7�� 9.�� 9.��

� �� -.�� C� ��.�� (�� 5�� 4�� -R�� -.�� %��9�� '$'�� 5��P>��.� ��4� ��'QV��-R��(��5�� %�� .�� R��6�-.��.��(��5�� 6��-R�� (�2�� 2�� H�� (�2�� 7�� %��;�� (�� 5�� 4�� .�� 6��<��5��5�� 5��=��7��4��-.��

80


��

� )��(��5��.��2��5��5��-.��;��5��-.��2��2��5��-.��9�� (�� 5�� 7�� .�� 4��5��

1��(�� -.�� .�� A� �� -.�� )?��-.��1)/��

G��C��;�� =��-.��)?��1)/ ��; ��.� ��-.��-.��1)/�� 2��3��;��5��-��-.��3�� 5�� ;� �� 5�� =��R�� ;�� 5�� /��3��?��4��=��1)/��

?��2��5��,��-.��-R�� -��6�-.��)?��-.��1)/��.��5��2��3��1)/��-�� ;� �� 7��-��0��5��)?��1)/��

��2��7��)?�� -.�� 5�� .�(�� =��2��5��)?��;�� 5��

T�� .��.��5��K��5��(��C��-.��1)/��)?� ��4��-.��=��

�2��

��U��)�K0��(/�/��

��>��

�� /��+��I ��'$$>��EL 2��T��S��/��IF�� A�)��2��!�2� ��U��)�� )��9�3�Y��Z �9Y ��/� ��!#%>&��

+��2�� B�M�� )��U�M�9�� M�K�� U��W��'$$!��E/I��3��3��F��K��2��*��*K(�/�>"#0$! �)�/��(��?))�0�T*B��

�� )�� 9��2�� 1�� ###�� E�� T��3��Z� �� /��3�� )�� 1��)��F �[��.��'�$��/��3�� I �)��2 �)� �B��I��###��

�� B<�� 6� � K�� '$$#�� E�� *��.�� /�� -.��[��1)/��6��)?�F��*��@��;�� 9��

81


� �

�� 0)* �+�� 333��0\��

U��2�� +��2�� /� ��/�23�� '$$!��E��T��)��F�� 2�� #�2� �� /��3�� )�� 1�� )�� 2�� L ��Z�2�� /��3�� )�� 1�� *�� T��-��/��'$$!�

W�� /��2�� '$$#��E*��[��I��/��3��)��1�� (?�� )��F�� 2�� T��2� �� /��3�� *��2 � �� )��] �)�� )��/��'$$#��

O��6�� U�M� 1�� B�M� ��2�Z�� M� �� M� 1�� M� 1�� B�� M� �3� � B�� ##"�� E��(?�� )��F�� )��2�� 2�� ?�4��(?�� )�� ??)� � T��/��([��19�/��'P��B��##"��

O��2�2� � +�� '$$P�� E)�� I�� 3�F�� B��K��2�� *�� K*0/�($P$�� O�� %� $P$$$��K�� 9 �K�� /��3�� U�� %� �� /�� (� O�� I� ��/��3��%�9�� K��1�� O��0/��(�O��2(��

O��6� � �� 1�� B�� )� � �� )� � U�� '$$>�� E��6�� (?�� [�� U�� K��2�5��F�� 2�� &�2� ��/��3��O�3��/.��T��

1�� B� �1��6 �*��*��*�4� �W��'$$>��EK2��*�� )��1��[��F�� 2��!�2� ��U��)��)��2��U)��'$$>�L ��Z�2��(?��)��1�� '$$>��)�� ?��'$$>��

��2�� O� � *�� ?�� L �� '$$>�� E��I�� (?��K��2�5��/��3��)��(1��F�� 2�� *�5�� L ��Z�2�� )��] � �� /��'$$>��

��6�� M� ?�� O�� '$$P�� E[��I� �� 3��2� T��(?��)�� F� A� )�� 2�� '�2� �� / U/?TK� ��/I��T��/��3�� )��9�3�Y��Z �� /� �'$$P ��'"%�Q>��

9IJ� �� KI�6��3��6 �/� ��L �� K��'$$!��E��[��I� �� /��3�� )�� 1��S� �� /��IF�� 2�� #�2� ��/��3�� )�� 1�� )�� 2�� L ��Z�2�� )��(1��%��I��L ��Z�2��*�� T��

*�� B�� )� �+�� )� �� '$$"��E?��2��I��(?�� 2�� K��2�5�� )�� 1��[��F�� A�^^ �/��@��+��2��/��3��/+�/�'$$"� �'$$" � B�.�� )�� )�� 2�� 1�� L ��Z�2�� (?��/��3��1�(L �/)� �'$$"��#(�Q$��

82


Uma Abordagem Visual para Auxiliar a Revisão da Seleção deEstudos Primários na Revisão Sistemática

Katia R. Felizardo1, Gabriel F. Andery1, José Carlos Maldonado1, Rosane Minghim1

1Instituto de Ciências Matemáticas e de Computação (ICMC) - Universidade de São PauloCaixa 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 exclu-sion decisions in the conduction stage of a systematic review. The approach hasbeen applied to real systematic reviews and the results showed that the use ofvisualization is an additional component and it can assist the reviewer to decidethat relevant studies were not deleted.

Resumo. Este artigo apresenta uma abordagem que faz uso de técnicas de Mi-neração Visual de Texto (Visual Text Mining - VTM) e ferramenta associadapara apoiar a revisão da seleção de estudos primários na etapa de Execução darevisão sistemática. A abordagem foi aplicada em revisões sistemáticas reaise os resultados mostraram que o uso da visualização é um componente adicio-nal e pode auxiliar o revisor na decisão de garantir que estudos relevantes nãoforam eliminados.

1. Introdução

A comunidade de Engenharia de Software tem adotado revisões sistemáticas como umaforma de reunir dados de diferentes estudos experimentais para caracterizar uma dadatecnologia.

A revisão sistemática é uma maneira de avaliar e interpretar toda pesquisa re-levante e disponível sobre uma questão de pesquisa específica, tópico ou fenômeno deinteresse, fazendo uso de uma metodologia de revisão que seja confiável, rigorosa e quepermita auditagem [Kitchenham 2004].

O processo de condução da revisão sistemática, adaptado para a Engenharia deSoftware, foi sugerido por Biolchini et al. [2005] e baseado nas diretrizes iniciais propos-tas por Kitchenham [2004]. O processo envolve três etapas, o Planejamento da revisão, aExecução e a Análise dos Resultados [Biolchini et al. 2005].

Durante a etapa de Planejamento é identificada a necessidade de uma nova revi-são sistemática, os objetivos da pesquisa são definidos e é criado o protocolo, que contémitens como a seleção de fontes, métodos de busca e palavras-chave, critérios de inclusão,exclusão e qualidade dos estudos primários [Biolchini et al. 2005]. Experimentos con-trolados, estudos de caso e surveys são exemplos de estudos primários, que atuam comofonte de informação para as revisões sistemáticas, ou seja, os estudos experimentais é quelevantam os dados que são agrupados e sumarizados pelas revisões sistemáticas, que sãoos estudos secundários [Kitchenham 2004, Sjøberg et al. 2007].

83


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 oscritérios de inclusão e exclusão definidos no protocolo são aplicados nos estudos da listaem duas etapas, inicialmente por meio da leitura do título, resumo e conclusões, seguidopela leitura do texto completo. Os resultados dessa análise são registrados, sendo que alista dos estudos deve ser reavaliada para garantir que não foram eliminados estudos re-levantes (Revisão da Seleção). Ao final dessa atividade, as informações são extraídas dosestudos identificados como incluídos.

Por fim, é na etapa de Análise dos Resultados que os resultados dos estudos primá-rios que atendem ao propósito da revisão são sintetizados. Essa síntese pode ser descritiva,mas um sumário quantitativo obtido por meio de um cálculo estatístico pode complemen-tar a descrição [Kitchenham 2004].

Como mencionado anteriormente, a atividade de Revisão da Seleção procura evi-tar a eliminação de estudos relevantes, o que pode prejudicar consideravelmente o re-sultado final da revisão, uma vez que exclui informações que deveriam ser avaliadas esintetizadas na etapa de Análise dos Resultados. Este artigo tem como objetivo proporuma abordagem que faz uso combinado de técnicas de Visual Text Mining (VTM) paraauxiliar 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 auxiliana discussão das divergências entre revisores, oferecendo outros recursos para apoiar atomada de decisão; e (ii) Revisão sistemática individual: A abordagem proposta podesugerir indícios sobre quais artigos devem ser revistos, tanto para inclusão, quanto paraexclusão, sem se basear em uma escolha aleatória.

Este artigo está organizado da seguinte forma: na Seção 2 são apresentados ostrabalhos 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 asconclusõ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 estu-dos primários. Os autores compararam o desempenho de revisores ao realizar a seleçãodos estudos efetuando apenas a leitura dos seus resumos com o desempenho ao utilizaras estratégias sugeridas com o apoio de uma ferramenta de VTM denominada ProjectionExplorer (PEx) [Paulovich and Minghim 2006].

Assim como o trabalho de Malheiros et al. [2007], este trabalho também faz usode 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 estu-dos, a proposta deste trabalho é utilizá-las para revisar a seleção. Além disso, as técnicasde VTM utilizadas nesses dois trabalhos são diferentes.

Não foram identificadas outras pesquisas que utilizam técnicas de VTM com omesmo objetivo deste trabalho.

84


3. Abordagem Proposta e Aplicação em Situações ReaisA Projection Explorer - PEx [Paulovich and Minghim 2006] é uma plataforma genéricade visualização de código aberto. A ferramenta disponibiliza diversas facilidades paramanipulação de textos e exploração de uma coleção de documentos com o uso de téc-nicas de VTM. De forma resumida, tem-se que a ferramenta faz uso do modelo espaçovetorial para estruturar, comparar e calcular as distâncias entre os documentos. As dis-tâncias calculadas são utilizadas por técnicas de projeções multidimensionais para gerarum mapa de documentos, ou seja, uma representação gráfica da coleção de textos. Nessemapa, cada ponto (círculo), definido no espaço bidimensional representa um texto. Umavez gerada a visualização, a principal ideia é a possibilidade do usuário interagir como resultado, permitindo-lhe explorar, compreender e extrair informações relevantes dosdados.

Nas Figuras 1(a) e 1(b) estão representados dois mapas de documentos geradospela PEx. Esses mapas representam os estudos primários analisados em duas revisões sis-temáticas. Essas e as outras revisões utilizadas neste artigo são do domínio de Engenhariade 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) aqual cada estudo pertence. Essas classes foram definidas com base na aplicação (por umespecialista no domínio de cada revisão) da estratégia tradicional de seleção de estudosprimá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ídosda 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 naFigura 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égiasugerida aqui para revisar a seleção dos estudos primários analisados pode ser resumidaem dois passos principais: (1) primeiro, um algoritmo de clustering é aplicado sobre omapa de documentos compondo grupos de documentos altamente relacionados (simila-res) – para tal o algoritmo k-means [MacQueen 1967] foi empregado; (2) então, os agru-pamentos resultantes são analisados, em termos dos documentos incluídos e excluídos

85


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 dereavaliaçã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 anecessidade de uma reavaliação;

• Situação (b): Cluster Misto – documentos com classificação diferente. Esses ca-sos são alertas ao revisor e os estudos ali agrupados, principalmente os que pos-suem 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 queo estudo isolado, se classificado como incluído, deve ser reavaliado uma vez quenã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) e2(b) respectivamente, porém com a identificação dos clusters e das situações que devemser 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). Porfim, um exemplo de ponto isolado está identificado na Figura 2(b) pela marcação (c). Aavaliação dos clusters pode ser refinada com o apoio de recursos baseados em conteúdo oucitação, descritos na sequência, e que podem ser utilizados individualmente ou de formacombinada.

3.1. Recursos Baseados em ConteúdoOs documentos (pontos) contidos no mapa gerado pela PEx são posicionados de acordocom a similaridade entre seus conteúdos, conforme explicado anteriormente. A ferra-menta também possui funcionalidades para modificar os atributos visuais dos pontos, porexemplo, a cor, de modo a refletir propriedades dos objetos. Dessa forma, dois recursosbaseados nessas funcionalidades podem ser utilizados para apoiar a análise visual dosclusters.

86


3.1.1. Histórico das Exclusões

O primeiro recurso prevê a criação de mapas de documentos baseados em conteúdo, con-tendo os estudos coletados e analisados na revisão sistemática, destacando por meio decores o histórico das exclusões, ou seja, os estudos que foram excluídos nas diferentesetapas da seleção.

O mapa da Figura 3(a) representa o resultado da fase de Execução da revisão sis-temá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 Figura3(a) é reapresentado, mas agora colorido de acordo com o histórico das inclusões e exclu-sõ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 daseleçã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 eos azuis, documentos incluídos. No caso específico da revisão sistemática 3 foi mantidocontato com os revisores, que disponibilizaram o histórico, o que não ocorreu com osdemais 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 clustersmistos: (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 narepresentação por histórico, equivalem a clusters puros (todos excluídos) e, portanto, nãoprecisam ser reavaliados.

Estudos em azul (incluídos) em conjunto com estudos em verde ou vermelho (ex-cluídos) formam clusters mistos nas duas representações, com ou sem o uso do recursode histórico. Entretanto, considerando que os pontos azuis e verdes foram avaliados nasegunda etapa pela leitura integral do texto, apenas os clusters contendo pontos azuis evermelhos despertam a necessidade de reavaliação, pois representam estudos excluídosjá na primeira etapa, apenas com a leitura do resumo, similares à estudos incluídos, lidosna í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


similares à azuis.

Vale destacar que sem o uso do histórico todos os clusters mistos deveriam serreavaliados. Os mapas e o recurso de histórico foram considerados, na opinião dos es-pecialistas, um mecanismo importante para embasar a decisão inicialmente tomada (emantida) 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 his-tórico, o mesmo é colorido de acordo com a qualidade definida e atribuída pelos revisorespara cada um dos estudos incluídos. A revisão sistemática 4 foi formatada para apresentara 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 maio-ria 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 superiordo mapa (todos incluídos). No entanto, não é possível afirmar que estudos com poucosdetalhes na escrita são de baixa qualidade, isto porque não se pode assumir que algo nãoreportado não tenha sido feito [Kitchenham et al. 2007]. Uma situação interessante foi ocaso destacado como (1) na Figura 4(b), ou seja, um artigo excluído (vermelho) similar aum incluído de qualidade Q7. Nesse caso, duas situações são possíveis e devem ser ava-liadas: (i) o estudo de qualidade Q7 omitiu detalhes e, portanto, mais informações devemser obtidas com os autores desse artigo para assegurar a sua inclusão; (ii) o estudo pos-sui informações suficientes e, portanto, sua inclusão é questionável. Assim, fica evidenteque os critérios de qualidade proveram mais detalhes do que apenas os fornecidos peloscrité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 asua qualidade. Assim, é possível utilizar outras opções para visualizar esses estudos, de

88


modo a complementar o que somente o conteúdo não revela. A rede de citações é umadessas opções.

A forma mais comum de representar visualmente as redes de citações (redescomplexas) é por meio de grafos, que são formados por um conjunto de vérticese arestas, os quais representam os objetos e as relações entre eles, respectivamente[Andery et al. 2009]. Nesse caso, os estudos primários (vértices ou pontos) e suas re-ferências bibliográficas (arestas).

Através dessa visualização é possível identificar, por exemplo, estudos que nãoestão conectados aos demais, ou seja, não compartilham referências. Esses estudos, queestão isolados em termos de referências, merecem atenção por parte dos especialistas (re-visores). Outro caso que merece destaque são as referências de estudos incluídos commuitas conexões. Isso porque buscas por estudos usando bibliotecas digitais e palavras-chave podem não ser suficientes para uma revisão sistemática completa. Outras fontesdevem ser pesquisadas, incluindo as listas de referência dos estudos revisados e classifi-cados como incluídos [Kitchenham et al. 2007].

Exemplificações de redes de citações estão ilustradas na sequência, com outrosconjuntos de revisões sistemáticas. As Figuras 5(a) e 5(b) representam as redes de citaçõesdas revisões 5 e 6, respectivamente. Essas redes também foram geradas pela ferramentaPEx, 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 arti-gos incluídos (localizados na região central) compartilham as mesmas referências, assimcomo os excluídos (localizados na região à esquerda, acima). Os estudos isolados foramtodos classificados como excluídos. Vale destacar que o “ponto azul” localizado no cantoinferior direito, se observado com detalhe, não é um único ponto isolado, mas dois pon-tos que compartilham exatamente as mesmas referências, não citadas em nenhum outroestudo.

Situações críticas e que merecem ser reavaliadas foram percebidas na rede decitações correspondente à revisão sistemática 6 (Figura 5(b)). Uma delas é a presença de

89


estudos incluídos totalmente isolados do restante (pontos azuis conectados apenas comsuas respectivas referências), que totalizam 10 ocorrências.

Um recurso adicional que pode ser utilizado é a técnica de coordenação por igual-dade. Essa técnica cria um relacionamento direto entre os mesmos documentos contidosem diferentes visualizações. Dessa forma, quando um estudo primário ou um conjuntode estudos é selecionado no mapa de documentos, os mesmos objetos são destacados narede de citações (ou vice-versa).

Na Figura 6 está ilustrado o uso da estratégia de coordenação por igualdade paraa revisão sistemática 5, sendo que na Figura 6(a) está apresentado o mapa de documentosdessa revisão sistemática e na Figura 6(b) a sua respectiva rede de citações. Os mesmosdocumentos 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 estudosincluídos e localizados no mesmo cluster, além de similares em termos de conteúdo, sãocitados 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


O uso da técnica de coordenação por igualdade permitiu identificar que o artigoincluído que não possui nenhuma referência na revisão sistemática 6 (ponto azul maisabaixo na Figura 5(b)) é similar a vários outros estudos excluídos da revisão. A Figura7 apresenta esse cenário, sendo que na Figura 7(a) está exibido o mapa de documentosdessa 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 nomapa 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 estudotambém incluído (Figura 8(a), ponto azul ao centro). Esses dois estudos estão destacadosna 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 FuturosA abordagem sugerida disponibiliza mecanismos de interação que possibilitam ao revisoruma 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 paraapoiar 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 porigualdade), todas disponibilizadas na PEx.

A abordagem é uma combinação de recursos para convalidar ou alertar sobre adecisã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 queas 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 umdos revisores, por exemplo, incluir um estudo de classificação divergente, caso o mesmoseja similar a vários estudos incluídos, ou que possua muitas referências em comum comoutros também incluídos.

No caso das revisões executadas individualmente as técnicas eliminam a escolha91


aleatória dos artigos a serem reavaliados, sendo essa escolha baseada em critérios desimilaridade 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 documentosem formato de texto. Por isso, se os estudos estiverem armazenados em qualquer outroformato, é 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áriospara o formato de entrada da PEx. Além disso, deverá ser investigado o uso de me-didas de importância de vértice em redes complexas (redes de citações), como grau decentralidade (degree centrality), grau de proximidade (closeness centrality) e grau de in-termediação (betweenness centrality), de modo a fornecer informações adicionais para orevisor embasar as suas escolhas, uma vez que essas medidas permitem identificar o grauimportância de um vértice dentro da rede. Essas medidas serão implementadas na PEx eserá avaliado o uso das mesmas para apoiar as atividades de seleção e revisão dos estudosprimários.

ReferênciasAndery, G. F., Lopes, A. A., and Minghim, R. (2009). Exploração visual multidimen-

sional de redes sociais. In 2nd International Workshop on Web and Text Intelligence(WTI’09), pages 1–9, São Carlos.

Biolchini, J., Mian, P. G., Natali, A. C., and Travassos, G. H. (2005). Systematic re-view in software engineering: Relevance and utility. Technical Report RT-ES 679/05,PESC/COPPE/UFRJ.

Kitchenham, B. (2004). Procedures for performing systematic reviews. Technical ReportTR/SE-0401, Keele University and NICTA.

Kitchenham, B. A., Mendes, E., and Travassos, G. H. (2007). Cross versus within-company cost estimation studies: A systematic review. IEEE Transactions on SoftwareEngineering, 33(5):316–329.

MacQueen, J. B. (1967). Some methods for classification and analysis of multivariateobservations. In Cam, L. M. L. and Neyman, J., editors, Proceedings of the fifth Berke-ley Symposium on Mathematical Statistics and Probability, volume 1, pages 281–297.University of California Press.

Malheiros, V., Höhn, E. N., Pinho, R., Mendonca, M., and Maldonado, J. (2007). A visualtext mining approach for systematic reviews. In Proceedings of the First InternationalSymposium on Empirical Software Engineering and Measurement (ESEM’07), pages245–254, Washington, DC, USA. IEEE Computer Society.

Paulovich, F. and Minghim, R. (2006). Text map explorer: a tool to create and explore do-cument maps. In Proceedings of the conference on Information Visualization (IV’06),pages 245–251, Washington, DC, USA. IEEE Computer Society.

Sjøberg, D. I. K., Dybå, T., and Jørgensen, M. (2007). The future of empirical methods insoftware engineering research. In Briand, L. and Wolf, A., editors, Future of SoftwareEngineering (FOSE’07), pages 358–378. IEEE Computer Society.

92

TECHNICAL SESSION 3

Verification, validation and test

(VV&T)

93


Granularity on Persistent Data Flow Testing of ActiveDatabase Applications

Plinio S. Leitao-Junior1, Plinio R. S. Vilela2, Mario Jino3, Joao C. Silva1

1Instituto de Informatica – Universidade Federal de Goias (UFG)Campus Samambaia, Caixa postal 131 – 74001-970 – Goiania – GO – Brazil

2Universidade Metodista de Piracicaba (UNIMEP)Rodovia do Acucar, Km. 156 – 13400-911 – Piracicaba – SP – Brazil

3Universidade Estadual de Campinas (UNICAMP)Avenida Albert Einstein, 400 – 13083-970 – Campinas – SP – Brazil

{plinio,jcs}@inf.ufg.br, [email protected], [email protected]

Abstract. Active databases have been traditionally used as an alternative toimplement persistent data requirements of applications on several knowledgedomains. Their principle is the activation of tasks with specific functionalities asa response to events. These reactive abilities are generally expressed with activerules defined within the database itself. We investigate the use of data flow-based 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 dataflow granularity, aiming at comparing different granularities and preliminarilyevaluating their fault-revealing effectiveness. This analysis has an importantimpact on the cost of database application testing. The results point to highergranularities do not improve the fault detecting ability.

1. Introduction

Data persistency is an attribute associated to the demand for non-volatile data. Applica-tions that manipulate such data are different from conventional applications, since theyincorporate persistent data in their execution input and output domains. In this context,database-enabled applications play an important role in the majority of modern organiza-tions [Chays et al. 2000]. A database application is a program running in an environmentcontaining one or more databases [Kapfhammer and Soffa 2003]

Considering that faults are inherently part of software production, the propositionof approaches to improve the quality of database applications is pertinent. Software test-ing is the most commonly used method of software quality assurance. Software testingtechniques for conventional programs have been proposed, implemented and evaluatedover the years, but relatively little effort has been dedicated to the development of system-atic testing techniques aimed to the database application domain [Chan and Cheung 1999,Chays et al. 2000, Kapfhammer and Soffa 2003, Zhang et al. 2001].

The motivation for this work is to contribute to the improvement of the qualityof SQL-based applications. An SQL-based application interacts with the database usingSQL (Structured Query Language), the most used language by database application de-velopers [Fortier 1999, Elmasri and Navathe 2006]. The use of relational databases has

94


increased in applications that manipulate persistent data and, in this context, SQL is themost widely accepted and adopted in relational database systems [Daou et al. 2001].

Active database systems monitor specific events and, as they occur, trigger appro-priate responses at the appropriate time. When the triggering of events occurs, a conditionis evaluated against the database state, and an action is activated if its true. From the appli-cation’s point of view, part of its functionality is expressed as rules, such that the controland data flows are transferred from the application to the active rules during execution. Anapplication domain overview of active database systems and their implementation aspectsare found in [Ceri et al. 2000, Ceri and Widom 1996].

The question associated to this research is the lack of testing techniques in thecontext of active rules written in SQL. This motivates new testing techniques based on theuse of SQL, aiming to reveal faults not yet discovered.

Testing criteria for active rules written in SQL were proposed and analyzed in thecontext of data flow based structural testing [Leitao-Junior et al. 2008]. The criteria arean extension to the All-Uses criterion [Rapps and Weyuker 1985], and exploits persistentdata flow relations associated to rule interaction. We carried out an empirical investiga-tion aiming to evaluate the applicability of different data flow analysis precisions and tocompare their fault detecting ability.

Section 2 deals with active rules written in SQL. Persistent data flow is discussedin Section 3. Section 4 introduces persistent data flow analysis precision. An empiricalanalysis is exploited in Section 5. Section 6 deals with related work. Section 7 concludeswith directions for future work.

2. Active Rules in SQLActive rules in SQL, called triggers, are activated by a database state transition. Thesource of events is limited to operations on the database structure, specifically a relationstate transition. The rule condition consists of any SQL predicate, including sub-queriesand 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 condi-tion: 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 valuesassociated to a given active rule execution are transient data that are being inserted, up-dated or excluded by the event operation. Figure 1 presents the syntax for the creation ofa trigger, according to Kulkarni et al. [Kulkarni et al. 1998].

The production <trigger action time> – Figure 1 – determines whether the rulewill be triggered before or after the event operation acts on the database. The produc-tion <trigger event> defines the type of state changing operations that cause the rule tobe triggered. The clause FOR EACH { ROW | STATEMENT } specifies whether therule is triggered for each event occurrence or for a set of event occurrences. The produc-tion <search condition> does not include state changing operations, differently from theproduction <triggered SQL statement>; the dispatch between triggers, not necessarilydistinct, can occur only from the action rule execution, not from the condition rule evalu-ation. If the execution of the action rule causes the event of another rule, the execution ofthe former is interrupted and the control is given to the latter.

95


<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, condi-tion ci and action ai. In the control flow context, similarly to conventional programs, arule r is represented by a directed-graph, given by G(r) = (N,B, e, x), where: N is theset of nodes in the rule; B is the set of branches; the entrance and exit nodes are, respec-tively, e and x; the entrance node is also called event node. Figure 2(b) shows the controlflow graph of the SQL active rule in Figure 2(a); dashed edges represent exceptions dueto the execution of SQL manipulation commands.

CREATE TRIGGER ReorderAFTER UPDATE OF PartOnHand ON InventoryWHEN (:New.PartOnHand < :New.ReorderPoint)FOR EACH ROWDECLARE 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;

1

2

3

4

5

6

7

(b)(a)

Figure 2. Example of an active rule in SQL: (a) source code (b) control flow graph.

3. Persistent Data FlowThe data flow in manipulation commands is characterized by: definition, use and use-definition. The first is the result of the execution of the insert command; the secondcorresponds to the execution of the select command; and the last one is the result ofthe execution of the update and delete commands. Data flow of implicit operationsare 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


persistent definition. The persistent use may affect the control flow, due to the occurrenceof exception conditions. Persistent uses occur in the output edges of SQL nodes, due tothe 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 persistentvariable 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); andthere is a definition-free path with respect to (w.r.t.) v from i to (j, k). Alternatively, ifddu(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 ona level of granularity of the database variables in which we can trace their definition andtheir later use [Daou et al. 2001]. The granularity, also called data flow analysis preci-sion, determines the rigor of data flow analysis and defines coverage levels for persistentdata 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. Thisapproach easy the analysis and reduce the number of variables, since it considers eachrelation as a single variable. Nevertheless establishes a conservative approach, since everyvariable definition followed by a variable use is a data flow association, regardless ofwhich data they are manipulating.

At granularity level attribute the definition occurrences and uses of relation at-tributes are explored, with no concerns of which tuples have been manipulated. It is moreprecise then the relation level, since it differentiates the attributes at each relation. Dataflow associations can be characterized when the intersection of the two sets of manip-ulated columns, the definition occurrences and the use occurrence, are not empty. Anadvantage of this approach is that the number of columns in a relation is fixed and theiroccurrences 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 granular-ity at the column level to determine the database modules affected by modifications in thedatabase component definitions.

The granularity level tuple is used when a refined data flow analysis is necessaryto determine the affected tuples in each data manipulation operation. Generally, staticallydetermine which tuples are affected by a data operation is not possible, due to the com-plexity that can be reached by the line selection predicates [Vaduva 1999] and the currentdatabase state. In a relational database a tuple, in general, represents a real world en-tity, an association among entities or some particular aspect of an entity. So use the linegranularity level means reach the real world entities manipulated by database operations.

The database and attribute value granularity levels represent two ends of data flowanalysis precision. The former considers the whole database as a single variable and the

97


definition and use occurrences are statically determined. The latter is the level of greaterdataflow analysis precision and represents a composition of tuple and attribute, and is alsonot decidable by static analysis.

The coverage of persistent data flow association is affected by the granularity ofthe data flow analysis. The coverage of a ddua at the β granularity is reached whenthe intersection of sets ddef and duse established at level β is not null and at least onedefinition free path with respect to the persistent variable is executed.

Therefore, in the context of persistent data flow based testing, testing requirementsare pairs <criterion, granularity> which coverage analysis consider exercised paths andmanipulated persistent data along these paths. The pair <criterion, granularity> estab-lished a new testing requirement, since it requires the analysis of the input domains thatare appropriate to the coverage of a particular criterion on each granularity level. Toreach coverage at more precise granularity levels implies a greater effort during the test-ing activities, since the input domain is reduced. Moreover, it is in general not possible tostatically 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 dataflow analysis precisions.

The coverage of pair <criterion, granularity> demands dynamic analysis of per-sistent data along exercised paths, since in general the static determination of defined andused database entities due to manipulation command execution is an open question. Theeffectiveness of coverage criteria depends not only on the selected paths but also on thetest data for those paths [Clarke et al. 1989].

Consider that the application of a test case set produces the tuple < Π,Γ > suchthat: Π is the resulting path set, Π = {π1, · · · , π1}, p > 0; and Γ is persistent data definedand used along each path of Π; Γ = {γ1, · · · , γp}, such that γk ∈ Γ is persistent datadefined and used along path πk ∈ Π.

We will consider a testing requirement effective if the application of an adequatetest 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 casesrequired in a real application is substantially less than that expected by their theoreticalcomplexity, 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 BetweenActive Rules based Criteria, defined in [Leitao-Junior et al. 2008]. The complexity oftesting requirements can be used to derive their application cost; it is defined as the num-ber of required test cases in the worst case, even so in practice this situation is unlikely tooccur. Although Interaction Between Active Rules based Criteria are an extension to All-Uses 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 anduse of persistent data, such that SQL command update.

98


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 fre-quently used by the academic community [Daou et al. 2001]. This approach could be ex-tended to others systems, such as SQLServer,DB2, SyBase,MySQL, and Informix.

Versions of the rule set Rx were built by seeding one fault for each version. Themanipulation fault type list introduced in [Leitao-Junior et al. 2005] was used to derive26 faulty versions of Rx, aiming at testing them by applying Interaction Between ActiveRules based Criteria. The set of manipulation commands in Rx in which their executioncan cause persistent data flow of interaction associations was targeted during the seedingof faults. The SQL manipulation command and the fault type were selected randomly foreach faulty version in order to avoid bias in fault seeding.

All faulty versions were tested at granularities relation, attribute, tuple, and at-tribute value, in order to observe whether higher data flow analysis precisions improvethe fault-revealing ability. Test data were generated for each faulty version, aiming atexercising all interaction associations at each granularity. The triggering commands wereelaborated to cover all event rule operations of Rx. The generation of testing databasewas based on [Ostrand and Balcer 1988, Chays et al. 2000]: basically, the tester providesa list of values that are conceptually different for each database attribute, according toits domain, which are combined to derive insertion commands to database relations; thecommands in which execution does not satisfy any database integrity constraints are dis-carded.

5.2. Experiment Application

All rules of Rx were enabled for triggering before the application of each test case; thisestablishes the real operation of Rx. The execution of the faulty rule was not isolated, andthe triggering between rules could occur in a chain.

The experiment application was supported by a tool, called ADAPT-TOOL – Ac-tive Database APplication Testing TOOL for active rules written in SQL – that was devel-oped aiming at the automation of Interaction Between Active Rules based Criteria. Thetool builds a database testing using relational model structures, and focuses on the fol-lowing functions: test data generation, control of rule set faulty versions, application (andre-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 thenumber 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 testcases, 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 exercisedthe 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 atgranularities relation, attribute, tuple, and attribute value, respectively. To understandhow 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


those test cases in which tuple were the highest granularity obtained at all interactionassociations 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 manipulationcommand execution and not handled by the programmer. Line (h) refers to test casesapplied with no exception.

Table 1. Summary of fault and non fault-revealing executed test cases, by granu-larity and raised exception type.

(I) (II) (III)Test cases Fault-revealing Non fault-revealing All

(a) Fault not exercised 0 8 8(b) No coverage 20 2 22

(c) Relation coverage 213 89 302(d) Tuple coverage 46 20 66

(e) Attribute coverage 81 37 118(f) Attribute value coverage 64 52 116

(g) all 424 208 632(h) No exception 281 198 479(i) User exception 112 10 122

(h) System exception 31 0 31(j) All 424 208 632

The application of the adequate test data was capable of revealing all of the faults,and the number of test cases was substantially less than that expected by the theoreticalcomplexity of each rule set faulty version. To evaluate the applicability of the data flowanalysis, a measure was used, denoted by the number of fault-revealing test cases ofadequate 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 adequatetest sets that include at least one fault-revealing test case . The value 0.6711 resulted fromthe expression above, denoting that 2/3 of the adequate test sets are fault-revealing. Com-puting the effectiveness per granularity, the values 0.7053, 0.6970, 0.6864, and 0.5517were obtained for granularities relation, attribute, tuple, and attribute value, respectively,showing that the effectiveness reaches higher values for the lower data flow analysis pre-cision.

The coverage at higher granularities does not improve the fault detection ability.The coverage at granularity relation was enough to reveal the presence of all faults. Insome versions ofRx, the coverage at granularities tuple and attribute value was non fault-revealing. Two scenarios were observed: i) two state changing commands characterizethe interaction association, such as update-update, so that the execution of the second onefix the error due to execution of the first one; and ii) the triggering between rules leads tofailure elimination due to the sequential execution of state changing commands.

100


The raised exceptions were traced in order to help the oracle role. From fault-revealing test cases, 33.7% (143 out of 424) raised exceptions, the majority resulted fromraise command executions. Note that user exceptions implement behavior according tothe software specification and they should be used to decide on the presence of faults. Theinstrumentation of exception situations required special mechanisms, since exception oc-currences usually can cause the loss of database transactions, eliminating the instrumen-tation data.

The demonstrated effectiveness is an initial empirical evidence. Additional stud-ies are required since several factors are involved in the investigation, such as, test datageneration strategy, active rules used in the experiment, and fault types and active rulesselected faults.

5.4. Threats to ValidityAlthough the seeded faults were not collected from real software projects, they are rep-resentative of real fault types, according to Leitao et al. [Leitao-Junior et al. 2005]. Eventhen 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, withseveral different versions. To compensate this approach the set has several interactionpoints, which makes its behavior very complex at run time. Such interaction points, spe-cially the triggering between rules, result in some cases on the execution of more than athousand nodes, increasing the chances of unexpected or incorrect behavior.

Another limitation is related to the artificial seeding of faults, that are unique ineach version of the rule set, in spite of the random selection of manipulation occurrencesand of fault types. In practice it is observed that faults do not occur in isolation, defectiveprograms will in general have more than one fault at the same time. We have to pointout that a secondary goal of this empirical investigation is to evaluate different data flowgranularities to detect the presence of faults. The isolation of faults allow a finer level ofcontrol when analyzing the influence of each granularity in the detection of each fault.

6. Related WorkIn the active rule context, Vaduva [Vaduva 1999] establishes an approach based on rulessequences, independently of the existence of triggering between rules, in order to revealinadequate rule interactions or improper sequences of rule execution. That work is basedon SAMOS, an object oriented database system. The goal of each test case is the ex-ecution of a specific rule sequence from a rule set. SQL is not used and the structuralelements of the rules, such as control and data flow, are not considered in the coverage ofa particular sequence.

Kapfhammer and Soffa [Kapfhammer and Soffa 2003] define testing criteriabased 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 thedatabase determines the number of required elements, since associations are defined foreach possible element of the database. The results of their empirical investigation indicatethat 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 accessinga MySQL database. There is a tendency for a high number of required elements when

101


tuple and attribute value granularities are used, even with a reduced database. The workdoes not investigate the fault-revealing aspect of the proposed criteria.

Additional work concentrate on the generation of testingdatabases [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,Suarez-Cabal and Tuya 2004].

7. ConclusionsThis work investigates the applicability of persistent data flow strategies in testing ofactive rules written in SQL, representing a valuable resource to the quality assurance ac-tivities related to the development of active database applications. A family of adequacycriteria was used, called Interaction Between Rules based Criteria, to promotes the useof a systematic approach to testing and eventually contributes to the dissemination of theuse of active rules databases.

The results of the empirical investigation, supported by the tool ADAPT-TOOL,show that the criteria are capable of revealing faults in manipulation commands, in addi-tion to their applicability at several granularities. The effectiveness was 2/3 of adequatedata set, and reached higher values for the lower data flow analysis precision. The cover-age of interaction associations at higher granularities does not improve the fault detectingability; fault-revealing and non fault-revealing scenarios were identified at every granu-larity level.

The realization of new empirical studies is desirable, since several factors are in-volved in the results of the study, such as: data flow generation techniques; set of activerules 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 reducethreats to the study’s validity.

ReferencesBaralis, E., Ceri, S., and Paraboschi, S. (1998). Compile-Time and Runtime Analy-

sis of Active Behaviors. IEEE Transactions on Knowledge and Data Engineering,10(3):353–370.

Ceri, S., Cochrane, R., and Widom, J. (2000). Practical Applications of Triggers andConstraints: 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. andCeri, S., editors, Active Database Systems: Triggers and Rules for Advanced DatabaseProcessing, pages 259–291. Morgan Kaufmann Publishers.

Chan, M. and Cheung, S. (1999). Testing Database Applications with SQL Semantics. InProc. of the 2nd Intl. Symp. on Cooperative Database Systems for Advanced Applica-tions (CODAS’99), pages 364–375.

Chays, D., Dan, S., Frankl, P. G., Vokolos, F. I., and Weyuker, E. J. (2000). A Frame-work for Testing Database Applications. In Proc. of the 2000 ACM SIGSOFT Intl.Symposium on Software Testing and Analysis, pages 147–157, Portland, Oregon.

102


Clarke, L. A., Podgurski, A., Richardson, D. J., and Zeil, S. J. (1989). A Formal Evalua-tion of Data Flow Path Selection Criteria. IEEE Transactions on Software Engineering,15(11):1318–1332.

Daou, B., Haraty, R. A., and Mansour, N. (2001). Regression Testing of Database Ap-plications. In Proc. of the 2001 ACM Symposium on Applied Computing, Las Vegas,Nevada.

Davies, R. A., Beynon, R. J. A., and Jones, B. F. (2000). Automating the Testing ofDatabases. In Proc. of the 1st Intl. Workshop on Automated Program Analysis, Testingand 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 forDatabase-Driven Applications. In European Software Engineering Conference andACM SIGSOFT Symposium on the Foundations of Software Engineering, ESEC/FSE2003, Helsinki, Finland.

Kulkarni, K., Mattos, N., and Cochrane, R. (1998). Active Database Features In SQL3.In Paton, N. W., editor, Active Rules in Database Systems, pages 197–219. Springer-Verlag.

Leitao-Junior, P. S., Vilela, P. R. S., and Jino, M. (2005). Mapping Faults to Failures inSQL Manipulation Commands. In Proc. of the 3rd3 ACS/IEEE International Confer-ence on Computer Systems and Applications (AICCSA-05), Egypt, Cairo.

Leitao-Junior, P. S., Vilela, P. R. S., and Jino, M. (2008). Data Flow Testing of SQL-based Active Database Applications. In Proc. of the 3rd International Conference onSoftware Engineering Advances (ICSEA-08), Sliema, Malta.

Ostrand, T. J. and Balcer, M. J. (1988). The Category-partition Method for Specifyingand Generating Functional Testing. Communications of the ACM, 31(6):676–686.

Rapps, S. and Weyuker, E. (1985). Selecting software test data using data flow informa-tion. IEEE Trans. Soft. Eng., SE-11(4).

Suarez-Cabal, M. J. and Tuya, J. (2004). Using a SQL Coverage Measurement for TestingDatabase Applications. In Proc. of the 12th Intl. Symp. on the Foundations of SoftwareEngineering, Newport Beach, California.

Vaduva, A. (1999). Rule Development for Active Database Systems. PhD thesis, Univer-sity of Zurich.

Zhang, J., Xu, C., and Cheung, S. (2001). Automatic Generation of Database Instancesfor White-box Testing. In Proc. of the 25th Annual International Computer Softwareand Applications Conference (COMPSAC’01), Chicago, Illinois.

103


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


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


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


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 in clusã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


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


[Macia et al., 2008] uma ferramenta para a aplicação das estratégias de detecção em

diagramas de classes (S5) e as versões 5.2 (S6), 6.0 (S7), 7.0 (S8) e 7.1 (S9) do sistema

open source JHotdraw [JHotdraw, 2008]. Os modelos dos primeiros cinco sistemas

foram gerados como parte do processo de desenvolvimento como trabalho da matéria

Projeto Projeto de Sistemas de Software do programa de pós-graduação em informática

da PUC-Rio. Esta disciplina avalia a correspondência dos diagramas UML com o

código implementado. Os modelos escolhidos apresentaram bons resultados e alta

coerência com o código fonte. No entanto, os diagramas de classes das diferentes

versões do sistema JHotdraw foram gerados mediante engenharia reversa apoiada pela

ferramenta Enterprise Architecture [EA, 2008]. As características desses sistemas são

resumidas na Tabela 1. A realização do estudo envolveu apenas um estudante de pos-

graduação na área de engenharia de software da PUC-Rio.

Tabela 1 - Características dos sistemas utilizados no estudo

Sistema Num. Pacotes Num. Classes Num. Métodos Num. Atributos

S1 12 61 513 142

S2 38 102 529 218

S3 27 110 898 194

S4 18 96 459 248

S5 16 150 679 459

S6 17 172 1.438 363

S7 16 332 3.117 361

S8 21 313 3.251 735

S9 25 401 3.986 1.198

4.3. Execução

Devido a que utilizamos os sistemas envolvidos no estudo apresentado em [Macia et al.,

2008] não tivemos que nos preocupar por uma fase de preparação. Sendo assim, a

execução deste estudo pode ser resumida nos seguintes passos: (i) aplicação das

estratégias de detecção nos diagramas de classes, usando uma extensão de nossa

ferramenta QCDTool, (ii) aplicação das estratégias de detecção no código, utilizando a

ferramenta Together (2008), e (iii) análise dos resultados. Escolhemos utilizar Together

pelo fato de automatizar muitas das estratégias de detecção para código propostas em

[Lanza & Marinescu, 2006], incluindo as adaptadas neste trabalho.

Tabela 2 – Valores Limites utilizados.

Shotgun Surgery God Package Misplacd Class

Métrica Valor Limite Métrica Valor Limite Métrica Valor Limite

CM + CA 10 PS 20 NOED 5

CC 5 NOCC 18 CL 0,33

NOCP 3 DD 3

PC 0,33

Os valores limites foram usados nas estratégias para modelos com base nos

valores limites das estratégias correspondentes para código. Sendo assim, utilizamos

mesmos valores para: (i) as métricas cuja informação necessária para seu cálculo está

disponível no modelo em nível de detalhe semelhante ao do código, (ii) valores padrões

utilizados, por exemplo, um terço, e (iii) valores absolutos muito pequenos tais como 3

e 5. Valores limites menores foram usados para as métricas cuja informação necessária

para seu cálculo está disponível no modelo em menor detalhe que no código. Os valores

limites associados a cada uma das métricas são apresentados na Tabela 2. Extrapola os

109


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 = FNFPVNVP

VNVP Precisão =

FPVP

VP e Recall =

FNVP

VP

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 God Package Misplaced Class

Sistemas Acurácia Precisão Recall Acurácia Precisão Recall Acurácia Precisão Recall

S1 96% 100% 66% 100% 100% 100% 96% 33% 100%

S2 98% 0% 100% 100% 100% 100% 100% 100% 100%

S3 95% 0% 100% 100% 100% 100% 100% 100% 100%

S4 95% 0% 100% 100% 100% 100% 100% 100% 100%

S5 98% 0% 100% 93% 100% 50% 100% 100% 100%

S6 98% 33% 100% 100% 100% 100% 100% 100% 100%

S7 98% 100% 87% 100% 100% 100% 97% 50% 50%

S8 98% 100% 85% 90% 100% 33% 100% 100% 100%

S9 99% 100% 83% 100% 100% 100% 100% 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


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


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


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


Reutilizacao de Conjuntos de Teste: Um Estudo no Domıniode Algoritmos de Ordenacao

Diogo Nascimento Campanha1, Simone do Rocio Senger Souza1,Otavio Augusto Lazzarini Lemos1, Ellen Francine Barbosa1 e

Jose Carlos Maldonado1

1Departamento de Sistemas de ComputacaoInstituto de Ciencias Matematicas e de Computacao

Universidade de Sao Paulo (USP)Caixa Postal: 668 – 13560-970 - Sao Carlos - SP

{diogonc,srocio,oall,francine,jcmaldon}@icmc.usp.br

Resumo. De acordo com resultados anteriores, um conjunto de teste (T) ade-quado para o criterio Analise de Mutantes (AM) – AM-adequado – para umprograma P nao e adequado para um programa Q, equivalente a P . Por outrolado, apesar de T nao ser 100% adequado para o teste de Q, e possıvel que napratica ele seja proximo ao adequado, motivando sua reutilizacao. Neste artigoapresenta-se um experimento que busca avaliar o nıvel de adequacao de Ts AM-adequados para programas de referencia em outros programas equivalentes. Oestudo e realizado no domınio de algoritmos de ordenacao. Foram construıdosTs AM-adequados para 6 algoritmos diferentes de ordenacao, conjuntos es-tes que foram executados contra 22 implementacoes diferentes construıdas poralunos de graduacao. Para verificar a similaridade das medias das coberturasatingidas pelos diferentes Ts, foram realizados testes estatısticos de analise devariancia. Resultados indicam que nao ha diferenca significativa entre as co-berturas atingidas pelos diferentes Ts, o que motiva a sua reutilizacao. Alemdisso um segundo teste indicou que essas coberturas sao superiores as obtidaspor um T aleatorio.

1. IntroducaoPara reduzir os custos da atividade de teste de software, muitas vezes se torna interes-sante reutilizar conjuntos de (casos de) teste criados anteriormente. Isso ocorre particu-larmente no caso de programas semanticamente semelhantes (ou equivalentes), ou seja,programas que implementam a mesma funcionalidade, porem de forma diferente. Emoutras palavras, dado que se tem disponıvel um conjunto de teste T adequado para o testede 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 afirmacaoser intuitiva, e importante verificar na pratica o nıvel de adequacao do conjunto de testereutilizado, pois isso pode depender diretamente da funcionalidade implementada e daforma como o conjunto de teste foi gerado (isto e, do tipo de criterio de adequacao ado-tado). Este artigo apresenta um estudo experimental sobre esse problema, no contexto dareutilizacao de casos de teste criados a partir do criterio Analise de Mutantes (AM) paraprogramas equivalentes que implementam diferentes algoritmos de ordenacao. O criterioAM [DeMillo et al. 1978] e considerado custoso, o que torna esse tipo de experimentoimportante para a obtencao de indıcios sobre a viabilidade da reutilizacao de conjuntos deteste nesse contexto.

De acordo com o axioma da antiextensionalidade de criterios de teste definido porWeyuker [Weyuker 1986] tem-se que: dado dois programas P e Q, tal que P e equiva-lente a Q, um conjunto de teste T adequado a P nao e necessariamente adequado a Q. Amesma autora demonstra teoricamente que essa propriedade se aplica ao criterio AM. Isso

114


e claramente observado, ja que o criterio AM leva em conta a sintaxe do programa, ouseja, os mutantes gerados e, consequentemente, os casos de teste, dependem diretamentede como o programa e implementado. Entretanto, apesar de T nao ser necessariamenteadequado a Q – ou seja, nao atingir 100% de cobertura para o criterio AM –, e possıvelque ele seja proximo do adequado, o que motivaria a sua reutilizacao. Em um trabalhoanterior [Maldonado et al. 1995], verificou-se indıcios de que os escores de mutacao saode fato similares quando se utiliza conjuntos de teste de referencia aplicados a diversosprogramas que implementam algoritmos de ordenacao. Entretanto, nesse primeiro estudofoi utilizada apenas uma implementacao de cada algoritmo de ordenacao, desenvolvidapelos proprios autores.

Alem disso, estudos indicam que o criterio AM e bastante eficaz para revelar di-versos tipos de defeitos [Mathur and Wong 1993]. No entanto, a sua aplicacao em gerale custosa devido a grande quantidade de mutantes gerados que precisam ser analisadose executados contra os conjuntos de teste [Maldonado et al. 1995]. Dessa forma, estu-dos que indiquem que a reutilizacao de conjuntos de teste e efetiva para esse criterio saoimportantes para viabilizar, por exemplo, a criacao de bases de conjuntos de teste para di-ferentes funcionalidades que podem ser reutilizados pelos desenvolvedores. Tais praticaspoderiam compensar o alto custo de aplicacao do criterio, ja que ofereceriam um pontode partida no teste de diferentes aplicacoes.

O estudo apresentado neste artigo procura avaliar os mesmos resultados atingi-dos por Maldonado et al. [Maldonado et al. 1995], porem, neste caso com um numeromaior de implementacoes desenvolvidas por programadores diferentes e com analisesestatısticas dos resultados obtidos. Comparou-se, ainda, a cobertura atingida pelos con-juntos de teste gerados a partir da utilizacao do criterio AM com a cobertura obtida porconjuntos de teste gerados aleatoriamente, para verificar a utilidade dos conjuntos geradossistematicamente.

O estudo experimental envolveu 28 implementacoes de algoritmos de ordenacao,sendo 22 desenvolvidas por alunos de graduacao do curso de Engenharia de Computacao– divididas em implementacoes do bubble sort, do selection sort e do insertion sort – e 6implementacoes-referencia de diferentes algoritmos de ordenacao (bubble sort, insertionsort, selection sort, shell sort, merge sort e quick sort). Conjuntos de teste adequadospara o criterio AM foram gerados para os programas-referencia. A partir daı, executou-seos conjuntos de referencia em todos os programas, coletando a cobertura atingida. Paraverificar se a media das coberturas atingidas foi de fato alta e similar para todos os progra-mas, aplicou-se a ANOVA [Wohlin et al. 2000] (ANalysis Of VAriance). O mesmo testefoi aplicado uma segunda vez, considerado um conjunto de teste gerado aleatoriamente.

Os resultados atingidos indicam que casos de teste gerados a partir do criterioAM para programas que implementam algoritmos de ordenacao podem ser efetivamentereutilizados em programas semanticamente semelhantes. Alem disso, demonstra-se queo conjunto de teste aleatorio obtem cobertura significativamente mais baixa, o que in-dica que a utilizacao dos conjuntos de teste gerados sistematicamente e interessante nessecontexto.

O restante do artigo esta organizado como segue. Na Secao 2 apresentam-seconceitos gerais sobre o criterio AM e o axioma definido por Weyuker. Na Secao 3descreve-se o estudo experimental, mostrando sua definicao e planejamento, e na Secao 4apresenta-se a analise dos resultados alcancados e discussoes. Por fim, na Secao 5apresentam-se as conclusoes e trabalhos futuros.

115


2. Criterio Analise de Mutantes e Axiomatizacao2.1. Analise de MutantesO criterio Analise de Mutantes (AM) utiliza informacoes sobre os defeitos cometidosfrequentemente por programadores ou projetistas durante o desenvolvimento do softwarepara definir os requisitos de teste [DeMillo et al. 1978]. Com base nos defeitos que sedeseja evidenciar, pequenas modificacoes sintaticas sao realizadas sobre o codigo-fonte,gerando programas ligeiramente alterados denominados mutantes. Assim, o objetivo docriterio e gerar casos de testes que demonstrem que o programa nao possui os defeitosrepresentados pelos mutantes, observando-se a saıda durante a execucao do programaoriginal e dos mutantes gerados. Um mutante e considerado morto quando a saıda geradapor ele difere da saıda gerada pelo programa original. Mutantes equivalentes sao aquelesque geram a mesma saıda que o programa original para qualquer valor de entrada contidono domınio de entrada.

A medida de cobertura do criterio AM e o escore de mutacao, calculado como arazao entre o numero de mutantes mortos sobre o numero de mutantes nao equivalentes.O escore de mutacao pode variar de 0 a 1 e quanto mais proximo de 1 maior e a qualidadedo conjunto de casos de testes aplicado.

Diversos estudos foram realizados com o objetivo de avaliar o criterio AM e osresultados indicam que esse criterio possui uma alta eficacia para revelar defeitos quandocomparado com outros criterios [Maldonado et al. 2007]. Entretanto, um problema quecompromete o seu uso e o alto custo de aplicacao. Mesmo para pequenos programas onumero de mutantes gerados e que precisam ser analisados e bastante elevado. Dessemodo, diversas estrategias foram propostas visando reduzir o custo de aplicacao sem pre-judicar a sua eficacia. Dentre elas, destacam-se estrategias para realizacao de mutacaoseletiva [Offutt et al. 1993], mutacao aleatoria [Acree et al. 1979] e geracao de conjuntoseletivo de operadores [Barbosa et al. 1998].

Alem disso, dada a relevancia desse criterio para a atividade de teste, iniciativasvisando automatizar sua aplicacao podem ser identificadas. Nesse contexto, destaca-se aferramenta Proteum, desenvolvida por Delamaro [Delamaro 1993], que apoia a aplicacaodo criterio AM para programas na linguagem C. A ferramenta e guiada por sessoes deteste, sendo que em cada sessao o usuario pode criar mutantes para o programa a sertestado a partir de um conjunto de 71 operadores, criar casos de testes e executa-los com oprograma original e com os mutantes e analisar os resultados. A ferramenta disponibilizarelatorios estatısticos, mostrando a quantidade de mutantes que cada caso de teste matou,quantos mutantes ainda estao vivos, dentre outras informacoes.

2.2. Axiomatizacao de Criterios de TesteExistem diversas tecnicas e criterios definidos para auxiliar a atividade de teste. Weyu-ker [Weyuker 1986] procurou identificar um conjunto de caracterısticas desejaveis emum criterio de teste. Tais caracterısticas foram organizadas em axiomas e alguns criteriosforam avaliados teoricamente em relacao aos axiomas definidos.

No contexto deste trabalho, foca-se no axioma da antiextensionabilidade queafirma que: “dado dois programas P e Q, onde P e equivalente a Q e T o conjuntode casos de teste adequado a P , T nao e necessariamente adequado a Q”. Programasequivalentes sao aqueles para os quais todo valor de entrada x contido no domınio deentrada de P e Q obtem a mesma saıda nos dois programas, ou seja, P (x) = Q(x).

Por meio de estudos teoricos sobre as caracterısticas do criterio AM, Weyu-ker [Weyuker 1986] constatou que o axioma da antiextensionalidade e satisfeito por essecriterio. Isso significa que programas com semelhanca semantica exigem conjuntos de ca-sos de testes diferentes para esse criterio de teste. A autora fundamenta sua argumentacao

116


no fato do criterio ser fortemente relacionado com a implementacao dos programas e naocom a sua especificacao. Ela afirma que “dois programas que realizam a mesma funcaode forma diferente terao um conjunto de mutantes diferentes gerados que irao exigir, por-tanto, 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 testeadequados para um programa P em programas Q semanticamente semelhante. Isso por-que a cobertura pode nao ser de 100%, mas se for estatisticamente semelhante a coberturado conjunto adequado no programa de referencia, motivar-se-ia sua reutilizacao.

3. Descricao do Estudo RealizadoNesta secao sao descritas as caracterısticas da conducao do experimento, seguindo o pro-cesso definido por Wohlin et al (2000).

3.1. PlanejamentoDefinicao: Avaliacao na pratica do axioma de antiextensionabilidade de Weyu-ker [Weyuker 1986] em relacao ao criterio AM. Em outras palavras, avaliar o quantoum conjunto de casos de teste adequado a um programa de referencia e adequado paratestar versoes alternativas ou evolucoes desse programa.

Contexto: Avaliacao de programas no domınio de ordenacao de vetores, implementadosem C por alunos de graduacao em uma disciplina introdutoria (Introducao a Ciencia daComputacao I) do curso de Engenharia de Computacao do ICMC/USP. Definicao de umconjunto de programas de referencia, tambem referentes ao domınio de ordenacao, imple-mentados com base na literatura [Ziviani 2005, Cormen et al. 2001]. Esses programas dereferencia sao implementados e testados (usando a ferramenta Proteum), por dois alunosde pos-graduacao.

Hipoteses: Deseja-se avaliar as seguintes hipoteses:

• Hipotese Nula H1.0: Dados varios programas que implementam algoritmos deordenacao (ou seja, programas equivalentes) e T um conjunto de casos de testeadequado a um programa-referencia P para o criterio AM, T obtem coberturasemelhante1 quando executado sobre todos os programas.

• Hipotese Alternativa H1.1: Dados varios programas que implementam algorit-mos de ordenacao (ou seja, programas equivalentes) e T um conjunto de casosde teste adequado a um programa-referencia P para o criterio AM, T nao obtemcobertura semelhante quando executado sobre todos os programas.

• Hipotese Nula H2.0: Dados varios programas que implementam algoritmos deordenacao (ou seja, programas equivalentes), T1 um conjunto de casos de testeadequado a um programa-referencia P para o criterio AM, e T2 um conjuntogerado aleatoriamente, T1 e T2 obtem coberturas semelhantes quando executadossobre todos os programas.

• Hipotese Alternativa H2.1: Dados varios programas que implementam algorit-mos de ordenacao (ou seja, programas equivalentes), T1 um conjunto de casosde teste adequado a um programa-referencia P para o criterio AM, e T2 umconjunto gerado aleatoriamente, T1 e T2 nao obtem coberturas semelhantesquando executados sobre todos os programas.

1Definem-se coberturas semelhantes aquelas que, em media, sao estatisticamente semelhantes (ou seja,nao apresentam diferenca significativa quando testadas a partir de um nıvel de confianca de 99%).

117


Variaveis Independentes: criterio AM, ferramenta Proteum, especificacao dos progra-mas e programas de referencia.

Variaveis Dependentes: casos de testes construıdos para os programas de referencia,programas implementados pelos alunos, complexidade dos programas, mutantes gerados,mutantes equivalentes identificados e escore de mutacao obtido.

Participantes: 60 alunos da disciplina de Introducao a Ciencia da Computacao I do cursode Engenharia de Computacao do ICMC/USP, os quais desenvolveram versoes de progra-mas para serem avaliados. Dois alunos de Pos-Graduacao que geraram conjuntos de testeadequados a um grupo de programas de referencia.

Descricao do experimento: Na primeira parte do experimento os alunos foram treinadosa respeito de metodos de ordenacao com a apresentacao dos algoritmos de 3 metodos:bubble sort, insertion sort e selection sort. Durante a parte pratica, os 60 alunos foramseparados em 30 duplas. Cada dupla ficou responsavel por implementar um dos metodosde ordenacao (considerando os tres algoritmos vistos), totalizando 10 implementacoes decada metodo de ordenacao. Essa atividade foi realizada em horario de aula pratica e osalunos levaram em torno de 1 hora para implementacao dos programas.

Em paralelo a essa atividade, dois alunos de Pos-Graduacao envolvidos como estudo, implementaram, com base nos algoritmos disponıveis em [Ziviani 2005,Cormen et al. 2001], 6 metodos de ordenacao: bubble sort, insertion sort, selection sort,quick sort, merge sort e shell sort. Esses programas foram testados pelos alunos de pos-graduacao com o auxılio da ferramenta Proteum e, para cada programa, um conjunto decasos de testes adequado foi gerado.

Na segunda parte do experimento, as implementacoes dos alunos de graduacaoforam analisadas e os programas incorretos foram excluıdos do experimento. Dos 30programas implementados 22 seguiram para a proxima etapa do experimento. Os 8 pro-gramas descartados nao foram utilizados pois continham erros de codificacao, o que pre-judicaria a analise do experimento. O escore de mutacao e valido somente para programascorretos, pois a distincao entre um mutante vivo e um mutante morto e avaliada compa-rando a saıda gerada pelo mutante com a saıda do programa original. Para cada um desses22 programas foram identificados os mutantes equivalentes levando em consideracao os71 operadores da Proteum.

Foram coletadas algumas metricas relacionadas a complexidade dos programase ao criterio analise de mutantes, sendo elas: Linhas de Codigo (LOC), Complexidadede McCabe[McCabe 1976], quantidade de mutantes gerados e quantidade de mutantesequivalentes identificados. Essas metricas tambem foram coletadas dos programas dereferencia com o objetivo de verificar se existe alguma relacao entre os diferentes metodosde ordenacao testados.

Para a automatizacao dos testes utilizou-se a interface de scripts da Proteum. Foiimplementado um conjunto de instrucoes que automatizou tres atividades importantes:criar a sessao de teste, criar um conjunto de casos de testes e marcar os mutantes comoequivalentes. A execucao dos casos de testes contra os mutantes e a verificacao do escorede mutacao atingidos foi feita utilizando a interface grafica da ferramenta.

Foi verificada tambem a cobertura obtida pelos casos de testes adequados aosprogramas de referencia, sobre os proprios programas de referencia. Esses dados foramcoletados com o objetivo de avaliar se a complexidade dos programas interfere de algumaforma no escore de mutacao atingido. Esses dados sao importantes pois o conjunto deprogramas de referencia contem metodos de ordenacao mais complexos como o quicksort, o merge sort e o shell sort. Para avaliar as hipoteses levantadas, foram realizados tes-tes estatısticos aplicando o metodo ANOVA (analysis of variance) e os resultados obtidos

118


podem ser vistos na Secao 4.

Validade: Os aspectos de validade do experimento sao divididos em validade interna eexterna: A validade interna busca identificar quais aspectos podem influenciar a relacaoentre a causa e o efeito durante a realizacao do experimento. As ameacas a validadeinterna identificadas foram:

Implementacoes identicas pelos alunos de graduacao: Foram tomados alguns cui-dados durante a execucao do experimento para que os alunos nao se comunicassem en-quanto implementavam os algoritmos. Alem disso, os codigos foram analisados indivi-dualmente e nao foram identificadas evidencias de plagio.

Aprendizado em relacao a construcao de casos de testes pelos alunos de pos-graduacao: Como os casos de testes foram construıdos por apenas dois alunos, estespodem ter aprendido com os primeiros programas a construir casos de testes mais efica-zes, ou ate mesmo aproveitar os casos de testes construıdos para programas anteriores, oque poderia influenciar o escore de mutacao obtido. Como tratamento a essa ameaca, aordem de construcao de casos de testes para os programas de referencia foi selecionadade forma aleatoria. Alem disso os testes foram construıdos seguindo sistematicamenteo criterio AM, ou seja, cada caso de teste foi construıdo com o objetivo de matar ummutante especıfico relativo a uma determinada implementacao.

Simplicidade dos programas testados: Pode-se supor que devido a simplicidadedo domınio de programas escolhido, qualquer conjunto de casos de testes, seria suficientepara alcancar um escore de mutacao satisfatorio. O tratamento relativo a essa ameaca foia utilizacao de um conjunto de casos de testes aleatorios. Esse conjunto obteve resultadosinferiores aos obtidos pelos casos de testes dos programas de referencia, como pode servisto na Secao 3.2.

A validade externa do experimento refere-se a capacidade de generalizacao dosresultados obtidos. Como os programas estudados foram especıficos do domınio deordenacao, nao se pode generalizar os resultados obtidos para outros domınios de pro-gramas. Como trabalhos futuros pretende-se realizar o mesmo experimento em outrosdomınios e assim obter resultados mais genericos em relacao as hipoteses estudadas.

3.2. Resultados obtidosNa Tabela 1 sao apresentadas as metricas coletadas de cada um dos programas imple-mentados pelos alunos de graduacao. Nas linhas estao listados os programas que naoapresentaram erros. A tabela foi quebrada ao meio e na primeira coluna e apresen-tada a identificacao dos programas seguida da quantidade de linhas de codigo (LOC) eda complexidade ciclomatica (McCabe) [McCabe 1976]. Nas duas ultimas colunas saoapresentadas as metricas relativas ao criterio AM: a quantidade de mutantes gerados e aquantidade de mutantes equivalentes identificados.

Pode-se observar que apesar dos programas serem baseados em tres metodos di-ferentes as metricas obtidas foram muito proximas, nao havendo diferencas significativasentre os metodos. Esse resultado ja era esperado pois apesar de serem metodos distin-tos, trata-se de programas semelhantes em relacao a forma de ordenar os numeros. Einteressante comparar a complexidade desses programas com os programas de referencia,pois esses possuem menos semelhancas em relacao ao metodo de ordenacao. As metricasrelativas aos programas de referencia sao apresentados na Tabela 2.

Observa-se que os tres ultimos programas (shell, merge e quick) apresentaramvalores mais altos em todas as metricas coletadas, com excecao da quantidade de mutantes

119


Tabela 1. Metricas coletadas dos programas implementados pelos alunos degraduacaoProgramas LOC McCabe Mutantes ME Programas LOC McCabe Mutantes MEB1 23 7 478 34 I5 19 7 473 18B2 22 7 462 41 I7 23 7 473 21B3 24 7 456 44 I8 23 7 414 17B4 20 7 514 41 I9 23 7 473 20B5 24 7 444 43 I10 21 7 473 18B6 27 7 568 37 S1 26 7 517 44B9 24 7 482 51 S2 22 7 493 41I1 23 7 491 20 S4 25 7 561 42I2 23 7 495 20 S5 24 7 530 37I3 23 7 473 19 S7 24 7 542 55I4 21 6 779 39 S10 25 7 560 39

LOC McCabe Mutantes MEMedia 23,14 6,95 506,86 33,68

Tabela 2. Metricas coletadas dos programas de referenciaProgramas LOC McCabe Mutantes MEbubble sort 20 7 489 42insertion sort 25 6 451 50selection sort 23 7 511 70shell sort 27 9 667 48merge sort 50 12 1715 70quick sort 38 9 674 14Media 30,50 8,33 751,17 49,00

equivalentes (que foi a menor de todas no quick sort). Os resultados mais altos podem terocorrido devido ao fato dos tres metodos de ordenacao adicionais serem mais complexose adotarem estrategias diferentes em relacao aos programas anteriores.

Para cada programa de referencia foi criado um conjunto de casos de testes ade-quado a sua implementacao. Foi gerado, tambem, um conjunto de casos de teste aleatorio,independente de qualquer metodo de ordenacao. Cada um desses conjuntos de casos detestes foi entao aplicado aos 22 programas implementados pelos alunos de graduacao.Nas tabelas 3, 4 e 5 podem ser observados o escore de mutacao para os metodos bubble,insertion e selection respectivamente. Nas linhas estao representados os casos de testesadequados a cada um dos programas de referencia e nas colunas os programas implemen-tados pelos alunos de graduacao

Tabela 3. Escore de mutacao obtido para o metodo bubble sort implementadospelos alunos de graduacao

Referencia B1 B2 B3 B4 B5 B6 B9 MediaCT bubble 1,000 1,000 1,000 1,000 1,000 0,996 1,000 0,999CT insertion 1,000 1,000 1,000 1,000 1,000 0,996 1,000 0,999CT selection 1,000 1,000 1,000 1,000 1,000 0,994 1,000 0,999CT shell 1,000 1,000 1,000 1,000 1,000 1,000 1,000 1,000CT merge 0,995 0,995 0,995 0,993 0,995 0,990 0,995 0,994CT quick 0,995 0,995 0,995 0,993 0,995 0,990 0,995 0,994CT aleatorio 0,961 0,959 0,958 0,968 0,965 0,967 0,967 0,964

De acordo com as tabelas, pode-se observar que os resultados obtidos foram seme-lhantes entre os tres metodos implementados. Alem disso, os casos de teste adequados aos

120


Tabela 4. Escore de mutacao obtido para o metodo insertion sort implementadospelos alunos de graduacao

Referencia I1 I2 I3 I4 I5 I7 I8 I9 I10 MediaCT bubble 0,998 0,998 0,998 1,000 0,998 0,998 1,000 0,998 0,998 0,998CT insertion 0,998 0,998 0,998 1,000 0,998 0,998 1,000 0,998 0,998 0,998CT selection 0,998 0,998 0,998 1,000 0,998 0,998 0,997 0,998 0,998 0,998CT shell 0,998 0,998 0,998 1,000 0,998 0,998 1,000 0,998 0,998 0,998CT merge 0,994 0,994 0,993 0,999 0,993 0,993 0,995 0,993 0,993 0,994CT quick sort 0,996 0,996 0,996 0,999 0,996 0,996 0,995 0,996 0,996 0,996CT aleatorio 0,970 0,962 0,960 0,984 0,960 0,960 0,965 0,960 0,960 0,965

Tabela 5. Escore de mutacao obtido para o metodo selection sort implementadospelos alunos de graduacao

Referencia S1 S2 S4 S5 S7 S10 MediaCT bubble 0,994 0,996 0,987 0,990 0,994 0,987 0,991CT insertion 0,996 1,000 0,990 0,992 0,996 0,985 0,993CT selection 0,998 0,998 0,996 0,998 0,998 0,996 0,997CT shell 0,992 0,991 0,990 0,992 0,992 0,988 0,991CT merge 0,996 0,993 0,992 0,994 0,994 0,996 0,994CT quick sort 0,996 0,993 0,992 0,994 0,994 0,996 0,994CT aleatorio 0,964 0,967 0,961 0,963 0,963 0,962 0,963

programas de referencia atingiram, em todos os casos, escores maiores do que 0,99 ob-tendo a media de 0,996. Em contrapartida, o conjunto de casos de teste gerados de formaaleatoria, apesar de tambem obter um escore de mutacao relativamente alto, ficou sempreabaixo de qualquer um dos outros conjuntos de casos de teste. Ainda em relacao aosresultados, nao foi possıvel identificar, de forma preliminar, uma relacao entre o metodoutilizado e o escore de mutacao obtido, ja que os resultados foram muito proximos. Naoparece existir tambem uma relacao com a complexidade do metodo, visto que nao houvediferencas significativas entre o escore obtido pelos casos de teste adequados aos 3 pri-meiros algoritmos e aqueles adequados aos algoritmos mais complexos.

Foi verificado tambem a adequacao dos conjuntos de teste de cada programa dereferencia para os demais programas de referencia. Dessa forma pode-se analisar se oconjunto de casos de teste adequado a um programa mais simples como o bubble sorttambem e adequado a programas mais complexos como shell, merge e quick sort. Osresultados obtidos podem ser vistos na Tabela 6.

Tabela 6. Escore de mutacao obtido para os programas de referenciaReferencia bubble insertion selection shell merge quick MediaCT bubble 1,000 0,997 0,995 0,993 0,969 0,980 0,989CT insertion 1,000 1,000 0,990 0,993 0,994 0,935 0,986CT selection 0,997 1,000 1,000 0,991 0,969 0,993 0,992CT shell 1,000 1,000 0,995 1,000 0,975 0,993 0,994CT merge 0,993 0,997 0,995 0,995 1,000 0,993 0,995CT quick sort 0,993 0,997 0,995 0,995 0,989 1,000 0,995CT aleatorio 0,959 0,960 0,963 0,964 0,984 0,965 0,966

Em relacao ao conjunto de casos de teste aleatorio, os resultados ficaram proximosdos obtidos para os programas implementados pelos alunos de graduacao. Observou-se, porem, que a media obtida foi mais baixa, principalmente devido ao menor escorealcancado para os programas mais complexos, chegando a atingir um mınimo de 0,935para o conjunto de casos de teste adequado ao insertion sort aplicado no quick sort. NaSecao 4 esses resultados sao analisados estatisticamente e discutidos.

121


4. Analise e Discussao

Para analisar estatisticamente se os diferentes conjuntos de casos de teste gerados para osprogramas de referencia obtem, em media, cobertura alta e semelhante quando executadossobre todas as implementacoes de ordenacao de vetores, decidiu-se realizar a analise devariancia (analysis of variance, ou ANOVA). A ANOVA oferece um teste estatıstico queverifica se as medias de diferentes grupos sao iguais, generalizando o teste t de Studentquando se tem mais de dois grupos.

No caso do estudo em questao, aplica-se a ANOVA para verificar as hipotesesformuladas na Secao 3. Para que o teste seja rigoroso, assume-se o nıvel de confiancade 99% (portanto, p-valor = 0,01). A ANOVA e aplicada duas vezes: uma para verificarse as coberturas obtidas para todos os programas sao igualmente altas em media, quandose permuta os conjuntos de casos de teste de referencia; e outra para verificar se, caso asemelhanca seja evidenciada no primeiro caso, o mesmo nao ocorre quando se consideraas coberturas atingidas pelos casos de teste aleatorios. O segundo teste e realizado paraverificar o quanto os casos de teste gerados aleatoriamente se aproximam daqueles gera-dos sistematicamente a partir do criterio AM. A ausencia de diferenca significativa nessecaso e um indıcio de que nao faz sentido utilizar casos de teste gerados sistematicamentenesse contexto (principalmente devido ao pequeno porte dos programas analisados).

O primeiro teste estatıstico evidenciou que nao ha diferenca significativa entre ascoberturas obtidas pelos conjuntos de casos de teste gerados para os programas de re-ferencia, quando executados sobre todos os programas (note-se que tambem se considerao conjunto de casos de teste referencia aplicado ao proprio programa utilizado para ageracao do conjunto). Como o p-valor foi avaliado em 0,6809 – ou seja, consideravel-mente maior do que 0,01 – nao se obteve evidencia suficiente para se rejeitar a hipotesenula H1.0 de que as medias das coberturas obtidas sao semelhantes. Alem disso, essasmesmas medias encontram-se entre 0,99 e 1, ou seja, praticamente 100%. Esse resul-tado e uma evidencia da efetividade de se reutilizar casos de teste gerados para uma dadaimplementacao de ordenacao em outras implementacoes equivalentes utilizando o criterioAM. Entretanto, quando se considera o conjunto aleatorio de casos de teste, a diferencaobtida e significativa. O p-valor nesse caso foi muito menor do que 0,01 (2.2 × 10−16),ou seja, uma forte evidencia para se rejeitar a hipotese nula H2.0 de que as medias dascoberturas sao semelhantes, quando se considera o conjunto aleatorio.

Para se ter uma ideia visual dos resultados, a Figura 1 apresenta o boxplot dascoberturas obtidas por cada conjunto de casos de teste, incluindo o aleatorio, executadosem todos os programas (riscos em negrito representam as medias). Note-se que o numerode outliers nao e significativo e, alem disso, a semelhanca entre as coberturas obtidaspelos casos de teste gerados para os programas de referencia e claramente visıvel nosvalores mais a direita no grafico. A cobertura e claramente menor para os casos de testegerados aleatoriamente, como pode ser visto nos valores mais a esquerda no grafico (amedia das coberturas se encontra entre 0,96 e 0,97).

5. Conclusoes

Neste artigo foi apresentado um estudo sobre a reutilizacao de conjuntos de teste adequa-dos para o criterio AM em programas equivalentes. O estudo foi realizado no domınio dealgoritmos de ordenacao. Os resultados obtidos indicam que os conjuntos de teste geradospara programas de referencia obtem a mesma cobertura, em media (entre 99% e 100%),quando aplicados aos 22 programas implementados pelos alunos e aos proprios progra-mas de referencia. A analise estatıstica indicou que nao houve diferencas significativasentre as coberturas obtidas pelos conjuntos de teste. Em contrapartida, o conjunto de ca-sos de testes aleatorios obteve cobertura significativamente mais baixa, o que indica que

122


aleatório bubble insertion merge quick selection shell

0.94

0.95

0.96

0.97

0.98

0.99

1.00

referência

cobertura

Figura 1. Boxplot dos dados obtidos no estudo.

a utilizacao dos conjuntos de teste gerados sistematicamente e interessante. Esses resul-tados oferecem indıcios de que a reutilizacao de casos de teste gerados a partir do criterioAM em programas equivalentes pode ser de fato efetiva. Trabalhos futuros incluem estu-dos similares em outros domınios, para que os resultados possam ser generalizados.

ReferenciasAcree, 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 contribuicao para a determinacao de

um conjunto essencial de operadores de mutacao no teste de programas C. In XII Simposio Brasileirode 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 Pressand McGraw-Hill.

Delamaro, M. E. (1993). Proteum: Um ambiente de teste baseado na analise de mutantes. Master’s thesis,ICMC-USP, Sao Carlos, SP.

DeMillo, R. A., Lipton, R. J., and Sayward, F. G. (1978). Hints on test data selection: Help for the practicingprogrammer. IEEE Computer, 11(4):34–43.

Maldonado, J. C., Delamaro, M. E., and Souza, S. R. S. (1995). Analise de mutantes: Uma avaliacaoempırica do axioma de antiextensionalidade. In Anais do Workshop de Qualidade de Sofware (em con-junto com o SBES 1995), pages 136–140, Recife.

Maldonado, J. C., Souza, S. R. S., Fabbri, S. C. P. F., Barbosa, E. F., Chaim, M. L., Vincenzi, A. M. R.,Delamaro, M. E., and Jino, M. (2007). Introducao ao teste de software. chapter Estudos Teoricos eExperimentais. Campus / Elsevier, 1st edition.

Mathur, A. P. and Wong, W. E. (1993). Evaluation of the cost of alternative mutation strategies. In VIISimposio 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 Wesslen, A. (2000). Experimentation

in software engineering: an introduction. Kluwer Academic Publishers.Ziviani, N. (2005). Projeto de Algoritmos com Implementacoes em Pascal e C. Thomson, 2nd. edition.

123


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

1Departamento de Ciência da Computação Universidade Federal do Amazonas (UFAM) – Manaus, AM - Brasil

2PESC – 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 ad-hoc, 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 Perspective-Based 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


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


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


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


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


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 WDP-RT) 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 WDP-RT, 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 in-loco 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/ Inspetor

Experiência Usabilidade

Experiência Inspeções

Experiência Desenvolvimento

# Disc.1

# FP2

# Def.3 Tempo Def./

Hora Total

Defeitos 10 Médio Médio Nenhum 10 3 7 110 3,82 11 Médio Médio Médio 11 0 11 45 14,67 13 Médio Médio Baixo 13 3 10 140 4,29 14 Baixo Médio Baixo 11 2 9 60 9,00 17 Médio Médio Baixo 16 4 12 50 14,40

WDP

18 Alto Médio Médio 8 2 6 38 9,47

55

20 Médio Médio Baixo 11 1 10 90 6,00 21 Nenhum Médio Nenhum 16 1 15 200 4,50 22 Alto Alto Alto 33 2 31 240 7,75 23 Médio Médio Alto 26 4 22 120 11,00 24 Baixo Médio Médio 34 6 28 180 9,33

WDP-RT

25 Baixo Médio Nenhum 24 3 21 200 6,30

127

1 – número de discrepâncias, 2 – número de falso-positivos, 3 – número de defeitos

129


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 63,01%

WDP-RT 66

73

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 WDP-RT influenciou positivamente para encontrar mais defeitos do que a técnica WDP.

Def

eito

s T

otal

5

10

15

20

25

30

35

WDP WDP-RT

Tecnica

Each PairStudent'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%

WDP-RT

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


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 WDP-RT 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


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


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

Proceedings of 6th Experimental Software Engineering Latin ...eselaw09/proceedingsEselaw2009.pdf ·...

Documents

Transcript of Proceedings of 6th Experimental Software Engineering Latin ...eselaw09/proceedingsEselaw2009.pdf ·...