Proceedings of 6th Experimental Software Engineering Latin American Workshop (ESELAW 2009)

Tamanho: px
Começar a partir da página:

Download "Proceedings of 6th Experimental Software Engineering Latin American Workshop (ESELAW 2009)"

Transcrição

1 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

2

3 E96p Experimental Software Engineering Latin American Workshop (ESELAW 2009) (6. : 2009 : São Carlos, SP) 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, ISBN: 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

4 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

5 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

6 Committees Steering Committee Sandra C. Pinto Ferraz Fabbri Guilherme Horta Travassos José Carlos Maldonado Márcio Eduardo Delamaro Manoel G. de Mendonça Neto (DC-UFSCar, Brazil) -- General Chair (COPPE/UFRJ, Brazil) (ICMC-USP, Brazil) (ICMC-USP, Brazil) (UFBA, Brazil) Program Committee Auri M. R. Vincenzi (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 Deysiane Matos Sande Elis Cristina Montoro Hernandes Erika Höhn Fernanda Aparecida R. da Silva Guilherme Freire Lucas Bueno Ruas de Oliveira (DC-UFSCar, Brazil) (DC-UFSCar, Brazil) (DC-UFSCar, Brazil) (ICMC-USP, Brazil) (DC-UFSCar, Brazil) (DC-UFSCar, Brazil) (ICMC- USP, Brazil)

7 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

8 External Reviewers Adenilso Simao Alfredo Goldman André Domingues Anna Grimán Arilo Dias Neto Arlindo da Conceição Claudia de O. Melo Debora Paiva Delano Medeiros Beder Edmundo Spoto Edson Moreira Elisa Yumi Nakagawa Erika Hohn Esteban Fernandez Tuesta Fabiano Cutigi Ferrari Fabio Lucena Felipe Besson Juliano Oliveira Katia Felizardo Marcelo Morandini Marco Silva Marco Antônio P. Araújo Maria Istela Cagnin Martin Solari Otávio Lemos Paulo Bernardo Paulo Sérgio Santos Pedro Treccani Plínio Leitão-Júnior Rafael Prikladnicki Rogério Eduardo Garcia Rosana Braga Rudinei Goularte Tayana Conte Valter Camargo Vinícius Humberto Durelli Vitor Lopes Viviane Malheiros (ICMC - USP, Brazil) (IME - USP, Brazil) (ICMC - USP, Brazil) (Simón Bolívar University, Venezuela) (COPPE - UFRJ, Brazil) (DCT - UNIFESP, Brazil) (IME - USP, Brazil) (UFMS, Brazil) (EACH - USP, Brazil) (UNIVASF, Brazil) (ICMC - USP, Brazil) (ICMC - USP, Brazil) (ICMC - USP, Brazil) (ICMC - USP, Brazil) (ICMC - USP, Brazil) (UFG, Brazil) (EACH - USP, Brazil) (UFG, Brazil) (ICMC - USP, Brazil) (EACH - USP, Brazil) (USP, Brazil) (COPPE UFRJ, Brazil) (UFMS, Brazil) (ORT University, Uruguay) (ICMC-USP, Brazil) (USP, Brazil) (UFRJ, Brazil) (UFPA, Brazil) (UFG, Brazil) (PUCRS, Brazil) (UNESP, Brazil) (ICMC USP, Brazil) (ICMC USP, Brazil) (DCC UFAM, Brazil) (UFSCar, Brazil) (ICMC USP, Brazil) (COPPE UFRJ, Brazil) (SERPRO/USP, Brazil)

9 Contents Invited Talk 2 Measuring and Monitoring Technical Debt (Carolyn Seaman) Free, Libre, Open Source Competence Centers - an opportunity for experimentation (Alfredo Goldman) Short Courses 6 Systematic Review - Scientific Research in Software Engineering (Katia Romero Felizardo, Rafael Messias Martins and Erika Nina Höhn) Using Qualitative Methods in Empirical Studies of Software Engineering (Carolyn Seaman) Introduction to Experimental Software Engineering (Manoel G. Mendonça) 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) Technical Session 1 - Experimentation in Software Engeneering 11 A Quantitative Assessment on Team Building Criteria for Software Project Teams (A. César C. França, Évisson Fernandes Lucena, Fabio Q. B. da Silva). 12 Apoio na Concepção de Workflow Científico Abstrato para Estudos in virtuo e in silico em Engenharia de Software (Wallace M. Pereira, Marco Antônio P. Araújo, Guilherme H. Travassos) 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) Experimentação em Engenharia de Software: Glossário de Termos (Vitor Pires Lopes, Guilherme Horta Travassos) Rastreabilidade Indutiva Aplicada a Artefatos de Software (Raquel Nitsche dos Santos, Raul Sidnei Wazlawick) Technical Session 2 - Systematic reviews 62 A Systematic Review on Software Product Lines Scoping (Marcela Balbino S. de Moraes, Eduardo Santana de Almeida, Silvio Romero de Lemos Meira) Implementação de Variabilidades de Linhas de Produto de Software utilizando Aspectos: Uma Revisão Sistemática (Antonio Carlos C. Júnior, Thelma Elita Colanzi, Paulo César Masiero) Uma Abordagem Visual para Auxiliar a Revisão da Seleção de Estudos Primários na Revisão Sistemática (Katia R. Felizardo, Gabriel F. Andery, José C. Maldonado, Rosane Minghim) Technical Session 3 - Verification, validation and test 93 Granularity on Persistent Data Flow Testing of Active Database Applications (Plinio S. Leitao Junior, Plinio R. S. Vilela, Mario Jino, Joao C. Silva)

10 Redução de Potenciais Defeitos através da Detecção de Anomalias em Diagramas de Classes (Isela Macía, Arndt von Staa) Reutilização de Conjuntos de Teste: Um Estudo no domínio de Algoritmos de Ordenação (Diogo Nascimento Campanha, Simone do Rocio S. Souza, Otávio Augusto L. Lemos, Ellen Francine Barbosa e José C. Maldonado) WDP-RT: Uma técnica de leitura para inspeção de usabilidade de aplicações Web (Marcos Gomes, Davi Viana, Lennon Chaves, Andreza Castro, Verônica T. Vaz, Altigran Soares, Guilherme H. Travassos, Tayana Conte)

11 INVITED TALK 3

12 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

13 Alfredo Goldman: Free, Libre, Open Source Competence Centers - an opportunity for experimentation Free, Libre, Open Source Software (FLOSS) Competence Centers are being established in several countries around the world. One of the first Brazilian initiatives in this direction is the USP Qualipso FLOSS Competence Center with branches at IME and ICMC. Its goal is to be a meeting point for students, professors, researchers, and professionals from public and private companies for exchanging information and conducting scientific and technological research and development projects around FLOSS. In this talk, we will tell the history and describe the goals of the USP FLOSS Competence Center and of the Qualipso Project and will describe a series of recentlyinitiated research projects in the area of Experimental Software Engineering that have the USP competence center as its testbed. Alfredo Goldman received his B.Sc. in applied mathematics from University of São Paulo, Brazil, his M.Sc. in computer science also from University of São Paulo, and his doctorate in computer science from the Institut National Polytechnique de Grenoble, France. He currently is an associated professor in the Department of Computer Science at University of São Paulo. His research interests include parallel and distributed computing, mobile computing and grid computing. 5

14 INVITED SHORT COURSES 6

15 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

16 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

17 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 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 ), 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 There he headed heads the Networking and Computing Research Center (NUPERC) from 2004 to He also served as a member of the Computer Science Technical Chamber at the Bahia State Research Agency (FAPESB) from 2005 to He joined the Computer Science Depatment of the Federal University of Bahia in He holds a research productivity scholarship from the Brazilian Research Council (CNPq) since 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

18 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

19 TECHNICAL SESSION 1 Experimentation in Software Engeneering (ESE) 11

20 A Quantitative Assessment on Team Building Criteria for Software Project Teams A. César C. França 1, Évisson Fernandes Lucena 1,2, Fabio Q. B. da Silva 1 1 Centro de Informática Universidade Federal de Pernambuco (CIn UFPE) CEP Recife PE Brasil 2 Coordenadoria Ministerial de Tecnologia da Informação Ministério Público de Pernambuco (MPPE) Recife PE Brasil {efl, 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

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

22 levels, were interviewed. The interview data was analyzed using qualitative methods and the following set of team building criteria (C x ) has emerged: C 1 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. C 2 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. C 3 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 C 1 because technical knowledge can be learned relatively quickly, while experience and productivity takes more time to develop. C 4 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. C 5 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. C 6 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 (S x ) because it was considered strategic criteria: S 1 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 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

23 This research uses the work of Hackman (1990) and Hallows (1998), where project success is measured by the following set of criteria: M 1 - Costs, M 2 - Implementation date, M 3 - Functionality/Scope, M 4 - Effective project team work, M 5 - User satisfaction, and M 6 - 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 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 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 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 S 1 - 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: S 1 - Project Importance and S 2 - 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 S 1 and S 2 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. Variable Importance level of C i (i = 1 6) Level of formal use of C i (i = 1 6) Importance level of S i (i = 1 2) Level of formal use of S i (i = 1 2) Table 1: Independent Variables Scale Values Low Medium High Low Medium High Low Medium High Low Medium High 15

24 Table 2: Dependent Variables Variable Satisfaction of Goal M i (i = 1 6) Scale Values 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 to An electronic questionnaire was sent by internet to 46 software organizations. It was possible to achieve a 52% response rate, which correspond to 24 software organizations. Each surveyed organization supplied the questionnaire with data from two projects: one that they consider as being successful and another considered as not successful. Therefore, data form 48 projects were collected. The surveyed managers had 2 to 18 years of experience in project management. Every project team had at least three members, including the project manager. The profile of the software companies is as follows: 16 are micro-business, 16 are smallbusiness, 4 are medium-business and 12 are large organizations Data Collection Instruments A questionnaire was designed to collect data regarding the independent variables. This questionnaire uses a likert scale structure, with forced choices between values in the scale. Each variable was evaluated by a single question, totaling 16 questions for the 16 dependent variables. Table 3 shows an example of the questions. Table 3: Team building criteria assessment instrument variable: level of formal use of C 1 1. How formal was the Technical Profile considered in the team building for this project? Low Medium High ( ) ( ) ( ) variable: importance level of C 1 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 Strongly Satisfied Satisfied satisfied M 1. Costs ( ) ( ) ( ) M 2. Implementation date ( ) ( ) ( ) How were the goals listed below satisfied by the project B (failed)? Not Satisfied Satisfied Strongly satisfied M 1. Costs ( ) ( ) ( ) M 2. 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

25 Success Goals Success Goals ESELAW 09 from the pre-test. For ethical reasons, two more sessions were added to the research instrument: a presentation session and another describing the confidentiality policy 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 Achievement Level Not Strongly Satisfied Satisfied Satisfied M 1 4.2% 8.3% 87.5% M % 4.2% 79.2% M 3 8.3% 0.0% 91.7% M 4 4.2% 8.3% 87.5% M 5 0.0% 12.5% 87.5% M 6 8.3% 0.0% 91.7% Table 6: Evaluation of the success goals on the failed projects Achievement Level Not Strongly Satisfied Satisfied Satisfied M % 4.2% 20.8% M % 0.0% 8.3% M % 16.7% 33.3% M % 8.3% 4.2% M % 8.3% 25.0% M % 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

26 Team Building Criteria Team Building Criteria ESELAW 09 projects has not satisfied them (under 17%). For the failed projects on Table 6, however, most of the projects have not satisfied the success goals (above 50%) while only the minority of the projects have strongly satisfied some of the success goals (under 34%). However, it was necessary to apply the MANN-WHITNNEY U test on these two sets of projects for assure that the samples really match with the necessary specifications of success and failure. As showed in Table 7, the differences between the successful and failed projects were significant for all success goals. In the U Test, the differences between two samples are meaningful when the result of p (confidence level) is equal or less 0.05, which represents 95% of certainty. Table 7: MAN-WHITNEY U Test applied to the success goals among successful and failed projects Success Goals Achievement level Not satisfied (n = 24) Satisfied (n = 24) Strongly Satisfied (n = 24) M 1 Costs p=0.000 p=0.555 p=0.000 M 2 Implementation date p=0.000 p=0.317 p=0.000 M 3 Functionality/scope p=0.000 p=0.388 p=0.000 M 4 Effective project team work p=0.000 p=1.000 p=0.000 M 5 User satisfaction p=0.000 p=0.640 p=0.000 M 6 Professional satisfaction on the part of the project manager p=0.000 p=0.077 p=0.000 ( ) - Significant differences only for p 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 Formalization level Low Medium High C 1 0.0% 4.2% 95.8% C % 16.7% 66.7% C % 16.7% 70.8% C % 20.8% 54.2% C % 16.7% 70.8% C 6 8.3% 20.8% 70.8% S % 8.3% 79.2% S % 8.3% 75.0% Table 9: Formalization level of the team building criteria on failed projects Formalization level Low Medium High C % 29.2% 41.7% C % 16.7% 37.5% C % 20.8% 20.8% C % 25.0% 29.2% C % 20.8% 25.0% C % 20.8% 25.0% S % 8.3% 50.0% S % 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 Medium High (n=24) (n=24) (n=24) C 1 Technical profile p=0,005 p=0,021 p=0,000 C 2 Individual costs p=0,031 p=1,000 p=0,045 C 3 Experience and Productivity p=0,001 p=0,714 p=0,001 C 4 Availability of human resources p=0,135 p=0,734 p=0,082 C 5 Personality p=0,002 p=0,714 p=0,002 C 6 Behavioral skills p=0,001 p=1,000 p=0,002 S 1 Project importance p=0,024 p=1,000 p=0,037 S 2 Customer importance p=0,015 p=0,153 p=0,077 ( ) - Significant differences only for p

27 Team Building Criteria ESELAW 09 From this analysis, it is possible to make some conclusions: The formalization level of almost all the team building criteria on successful projects is significantly different from their formalization level on failed projects, which means that the criteria have a positive relation with the project performance. All criteria whose evaluation is Medium are not enough to favor project success because the Medium scores tend to have the same behavior in both successful and failed project, which makes it impossible to draw some conclusion about them. The criterion C 4 - 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 C 4 does not have any direct influence in the project performance. This means that if all criteria but C 4 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 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 Table 12: Importance order of the team building criteria, according to the Project managers opinions Importance Level Low Medium High C 1 4,2% 8,3% 87,5% C 2 16,7% 8,3% 75,0% C 3 4,2% 4,2% 91,7% C 4 25% 16,7% 58,3% C 5 8,3% 16,7% 75,0% C 6 4,2% 8,3% 87,5% S 1 4,2% 4,2% 91,7% S 2 4,2% 12,5% 83,3% 1. S 1 Project Importance C 3 Experience and Productivity 3. C 1 Technical profile C 6 Behavioral skills 5. S 2 Customer Importance 6. C 5 Personalidade 7. C 2 Personality 8. C 4 Availability of human resources In the same sense of what was discussed before, in the end of the Session 4.2, C 4 - 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 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

28 software engineering field still are building their teams based heavily on their own pastexperiences. However, França et. al. (2008) made an exploratory research with the goal to empirically identify some of the criteria used by project managers to build successful teams. The main objective of the research described in this article was to assess the effectiveness of the use of those criteria by calculating the statistical correlation of them with project success goals. From a carefully planned field research, it was possible to conclude that the analysis of technical profile, experience and productivity, personality, and behavioral skills are positively related to the project success among the studied sample. Complement other researches in the area, the results presented here also emphasize individual costs, customer importance and project importance as relevant factors to be considered in team building. Individual costs, specially, are not described explicitly in the team building literature, even though it is consistent with the project management literature (PMI, 2004). On the other hand, there is no significant correlation between availability of human resources and neither project success nor project failure. This paper s main weakness is the reduced sample. Although the sample is not big enough to draw general conclusions (a threat to external validity), it is important to notice that not only 48 software projects is a reasonable sample comparing with the average in software engineering research field, but also the experimental research process designed can serve as a reference for other related researches that could repeat the same experiment with an expanded sample. Another problem is the use of a nonparametric test that makes the results weaker than using parametric tests, which was impracticable in this research. Beyond the effectiveness of the team building criteria, verified through a practical experience, there are two other noteworthy results. The first one would be the tools designed to assess and correlate team building criteria and project goals, including the data packet resulting from the research. The second would be the methodology prepared for this field research, which could be used for future work to verify factors with similar data behavior. Finally, it is important to emphasize that this article is a part of a wider research, which aims to study the whole of team lifecycle management on software engineering organizations. Also, both industry and academy have shown an increasing interest for this theme. References BATITUCCI, M. D. (2002) Equipes 100% - O novo modelo do trabalho cooperativo no 3º milênio. São Paulo: Makron Books. BECKER, M.; BURNS-HOWELL, J.; KYRIAKIDES, J.(2000) IS Team effectiveness factors and performance, BROOKS, F. P. (1975) The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley Professional, 1975, ISBN , 336p. DeMARCO, T.; LISTER, T. (1987) Peopleware: Productive Projects and Teams. New York: Dorset House Publishing Co, ed. 2,

29 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 pp (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. 3 rd 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, 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 , 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 , 2005, ISSN JURISTO, N.; MORENO, A. (2001). Basics of software engineering experimentation, Kluwer Academic Publishers, ISBN: , 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 Emerald Group Publishing Limited 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 , 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, TARRICONE, P. and LUCA, J. (2002) Successful teamwork: A case study. Higher Education Research and Development Society of Australasia HERDSA conference 2002 proceedings pp

30 Apoio na Concepção de Workflow Científico Abstrato para Estudos in virtuo e in silico em Engenharia de Software Wallace M. Pereira 1, Marco Antônio P. Araújo 2, Guilherme H. Travassos 1 1 Programa de Engenharia de Sistemas e Computação (PESC), COPPE/UFRJ Universidade Federal do Rio de Janeiro, Brasil, Caixa Postal CEP Centro de Ensino Superior de Juiz de Fora / Faculdade Metodista Granbery Abstract. Science evolution has been supported by complex computerized infrastructures with growing interests in simulation based studies based on scientific workflows. However, the conception of such workflows is not easy and the current ad-hoc approaches make it a risky process. Therefore, this paper describes the application of an approach for the conception of scientific workflows for Software Engineering simulation based large scale studies in software decay. Resumo. A evolução da ciência tem sido apoiada por infra-estrutura computacional complexa para realizar as pesquisas, com crescente interesse em estudos baseados em simulação utilizando tecnologias de workflow científico. Entretanto, a concepção de workflows não é trivial e as práticas correntes ad-hoc podem trazer riscos ao estudo. Por isto, este trabalho apresenta a aplicação de uma abordagem de apoio à concepção de workflow científicos para estudos larga escala baseados em simulação em Engenharia de Software no domínio da Evolução de Software. 1. Introdução A Engenharia de Software (ES) vem utilizando a Experimentação como meio para a criação de um corpo de conhecimento. Para que apresente validade científica, cada um de seus itens de conhecimento deve ser verificado perante a realidade [Juristo & Moreno, 2001]. Essa verificação pode ser realizada através de estudos experimentais, que permitam ao pesquisador um maior controle da situação e a manipulação do comportamento do ambiente de forma direta, precisa e sistemática [Wohlin et al., 2000]. Diferentes tipos de estudos experimentais podem ser utilizados, contando com a participação de profissionais. Esses estudos visam observar a validade desses itens de conhecimento quando relacionada a seus possíveis comportamentos em processos de software e como podem afetar o produto gerado. Contudo, em situações onde o tempo necessário para observação do comportamento é longo, a utilização de profissionais pode não ser inicialmente viável, tornando a observação mais difícil, trazendo riscos de continuidade da pesquisa. Essas condições têm motivado o uso cada vez mais freqüente de estudos baseados em simulação na Engenharia de Software Experimental [Zhang et. al., 2008]. Dentre as vantagens que podem ser obtidas, destacam-se: maior controle do ambiente, menor custo de pessoal e antecipação a possíveis riscos. Também, existe a possibilidade de observar, de forma restrita, a viabilidade das tecnologias de software sob investigação. Os estudos que fazem uso de ambientes simulados são denominados: in virtuo e in silico. Esses estudos permitem observar o mundo real através de simulação 22

31 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 experimentação, sendo uma importante fase, onde o pesquisador estrutura e define o estudo, em termos da seqüência de atividades necessárias, os tipos de dados de entrada e os produtos esperados. Essa fase, na verdade, é decomposta em duas subfases, a Concepção, no qual o pesquisador define um novo workflow, e o Reuso, no qual o pesquisador recupera um workflow e o adapta para atender a um novo estudo ou objetivo. Contudo, muitos autores sugerem que a Composição deve seguir um conceito de criação através de níveis de abstração [Medeiros et. al., 2005; Gil et. al., 2007], pois, assim, o pesquisador poderia, em momentos diferentes, definir o comportamento (objetivo, atividades e escopo) do workflow e depois, gradualmente, ir identificando questões de tecnologia (e.g., local de execução, tipo de chamada de uma ferramenta, dentre outras). Pode-se, de forma simplificada, definir em dois níveis a abstração do worklfow: concreto e abstrato. Neste caso, o nível mais abstrato é ligado à definição do comportamento do workflow, sendo denominado workflow abstrato. Já o nível concreto é ligado aos recursos computacionais necessários à execução do workflow científico, já pronto para execução em um SGWfC, sendo denominado workflow concreto [Mattos et al., 2008]. Com o crescente uso de estudos experimentais baseados em simulação na Engenharia de Software [Zhang et. al., 2008], faz se necessário buscar formas de auxiliar os pesquisadores em sua realização. Uma possível maneira, como em outras áreas científicas, é através do uso de tecnologias de workflow científico e SGWfCs, visto que trazem as vantagens já enumeradas anteriormente, como controle, proveniência e automação. Porém, apesar desses benefícios, o uso dessas tecnologias gera novas questões associadas à especificação, modelagem e reutilização deste tipo de estudo experimental [Mattoso et al., 2008]. Soma-se a isso o fato de estudos do tipo in 23

32 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

33 baseados no diagrama de atividades da UML 2.2 [OMG, 2009], enquanto os formulários (Atividades, Artefatos e Ferramentas) são compostos por campos que representam os requisitos do estudo experimental. O responsável pela especificação e modelagem é denominado modelador, sendo ele um pesquisador ou engenheiro de software. A Figura 1 apresenta a Abordagem de Concepção, maiores detalhes em [Pereira & Travassos, 2009]. De maneira resumida, a seguir é apresentada a Abordagem de Concepção. Definir modelo inicial do workflow científico Identificar e modelar requisitos do workflow científico Inspecionar a especificação do workflow científico Nova rodada de inspeção Avançar na concepção Validar a especificação do workflow científico Não validado Validado Figura 1. Tarefas da Abordagem para Concepção de Workflows Abstratos [Pereira & Travassos, 2009]. Inicialmente, realiza-se a tarefa Definir o modelo inicial do workflow científico, onde o modelador concebe o modelo inicial, construindo uma visão global do estudo através da discussão com outros pesquisadores. Após esta tarefa, Identificar e modelar requisitos do workflow científico é executado. Nela, o modelador cria a especificação do workflow abstrato através de reuniões semi-estruturadas com os pesquisadores. Os formulários são utilizados como guias nas perguntas da entrevista e o modelo inicial como base para o modelo de workflow abstrato. Conforme citado anteriormente, a abordagem também foca na garantia da qualidade da especificação gerada. Para alcançar esse objetivo, primeiramente é realizada uma verificação da especificação (Inspecionar a especificação do workflow científico), através de uma inspeção ad hoc, no qual os inspetores, pesquisadores do domínio não envolvidos na especificação, verificam todo o documento em busca de discrepâncias. Os defeitos são categorizados e corrigidos. Já a tarefa de validação, Validar a especificação do workflow científico, é realizada através de reuniões com todos os participantes, no qual todo o conteúdo do documento é avaliado, assim confirmando se os requisitos do estudo experimental foram capturados de maneira a atender o seu propósito. Essa abordagem vem sendo utilizada no contexto de um projeto real, Gexp (http://gexp.nacad.ufrj.br), para a especificação de workflows abstratos no domínio de exploração de petróleo em sistemas alto mar (offshore). 3. Domínio da Simulação de Evolução de Software A pesquisa sobre Evolução de Software tem como objetivo entender como sistemas evoluem e modificam-se ao longo do seu ciclo de vida e como isto pode influenciar no decaimento de sua qualidade. Para isto, podem-se construir modelos de simulação para ajudar a observar a evolução do software ao longo de sucessivos ciclos de manutenção. Araújo (2009) apresenta um modelo, baseado nas Leis de Evolução de Software (LSE Laws of Software Evolution) [LEHMAN et al. 1998], que permite a observação do processo de decaimento do software ao longo do tempo, através da simulação do comportamento de determinadas características do software. O modelo de Araújo baseia-se em premissas descritas através de formulações lógicas das LSE. Essas formulações representam as tendências do comportamento de determinadas características de software ao longo do tempo (e.g., características da fase de codificação: esforço, tamanho, periodici- 25

34 dade, complexidade, confiabilidade, manutenibilidade,). Entretanto, as premissas não permitem a observação direta do processo de decaimento da qualidade do software, pois não representam as influências que uma Lei exerce em outra. Assim, utiliza-se ferramentas para simular as características do software, através das equações definidas, que representam as influências entre as LSE e como essas afetam as características. A Figura 2 apresenta o processo para observação de Evolução de Software [Araújo, 2009]. Engenheiro de Software Coleta de Métricas Construção Planilha Geração das Equações Simulação Evolução de Software Ferramenta 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, esperase que, posteriormente, seja possível definir e repetir este estudo em um SGWfC 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

35 Engenheiro de Software, cuja responsabilidade é garantir a qualidade dos dados escolhidos, das equações geradas e análise do resultado da simulação. O modelo inicial (Figura 3) serviu como insumo para a tarefa de Identificar e modelar do processo de concepção. Início Experimento Preparar dados para simulação Gerar as equações para simulação Simular a evolução do software Análise do resultado da simulação Fim Experimento Figura 3. Modelo Inicial para Simulação da Evolução de Software. Este modelo inicial foi refinado e, assim, foram identificados alguns pontos de decisão no estudo (vide Figura 4). No modelo foram representados os fluxos de controle e dados do modelo, o que possibilita ao pesquisador visualizar as dependências entre as atividades do estudo, trazendo a ele uma visão dessas duas perspectivas. Também foi percebido que três atividades eram compostas de sub-atividades. Na Figura 4, as atividades compostas estão estereotipadas com <<structured>>, que representam o conceito de sub-workflows. Inicio_Simulacao_Decaimento Dados reais do processo de desenvolvimento «datastore» Base de medidas da organização «structured» Preparar dados para simulação Tabela com versões do software «decisão» {Base de medidas das versões é válida e suficiente para gerar as equações?} [SIM] Tabela com versões do software «structured» Gerar as equações para simulação [MODIFICAR MEDIDAS DO SOFTWARE] Final_Simulacao_Decaimento Análise do resultado da simulação [NÃO] «Semi-automatizada» Análise do resultado da simulação «decisão» {Qual é origem do problema? Ação a ser tomada?} Dados da simulação da evolução [MODIFICAR EQUAÇÕES PARA SIMULAÇÃO] Dados da simulação da evolução [NÃO] [SIM] «structured» Simular a evolução do software Equações para simulação Figura 4. Workflow abstrato para Simulação da Evolução de Software. «decisão» {Equações representam o modelo dinâmico?} Equações para simulação O modelo que representa os fluxos (controle e dados) da atividade Gerar as equações para simulação pode ser visto na Figura 5. Essa representação por subworkflows permitiu uma melhor organização, pois deixa os modelos mais legíveis para o pesquisador. Tabela com versões do software Inicio_Gerar_Equações Tabela com versões do software «Manual» Definir versão base da simulação «structured» Gerar as equações para simulação Tabela com versões do software Versão base Versão base «Semi-automatizada» Criar equações da simulação Equações para simulação Final_Gerar_Equações Figura 5. Sub-workflow para Gerar equações para simulação. Equações para simulação A especificação é composta pelos diagramas de atividades, mas também por um conjunto de formulários. Estes documentam cada atividade, artefato e ferramenta utilizada no estudo. Os formulários foram preenchidos conforme ocorreram as reuniões, em conjunto com a concepção dos modelos do workflow abstrato. A Tabela 1 apresenta alguns campos do formulário da atividade Criar equações da simulação. A Tabela 2 27

36 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 Insumos Tabela com versões do software; Versão base simulação 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/ Obrigatoriedade Formato Digital. Saída 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

37 planilha, como apresentado na Figura 6. Foram encontradas 20 discrepâncias no documento. Após isso, as discrepâncias foram analisadas para descartar as que não fossem defeitos reais (falso positivos 2 no total). Após a correção dos defeitos, o documento foi validado em conjunto, modelador e dois pesquisadores do domínio (incluindo o inspetor), sendo realizada a distância por um dos participantes. 4. Lições aprendidas A abordagem foi desenvolvida para ser aplicada por pesquisadores, porém foi observado ser ainda necessário conhecimento sobre modelagem UML, em especial sobre o diagrama de atividades. A aprendizagem sobre este modelo demanda tempo pelos participantes, em especial os pesquisadores. Por isso, a tarefa de Definir o modelo inicial do workflow científico é importante, pois abre a possibilidade do pesquisador ir assimilando os conceitos sobre modelagem e da própria técnica. Um ponto importante é a participação do pesquisador responsável e a necessidade de comprometimento por parte dos participantes, pois como em processos de software, o cliente é fundamental na captura e identificação dos requisitos. Relacionado à especificação e aos formulários, foi percebido que o crescimento do número de atividades, artefatos e ferramentas que fazem parte do estudo, pode dificultar o seu preenchimento, a sua manipulação e a consistência. Como os formulários foram criados para serem inter-relacionados, algumas informações ao sofrerem alteração demandam esforço para modificações em outros formulários. Ainda, destaca-se a possibilidade, apontada por um dos pesquisadores, de utilizar a especificação como forma de disseminação de conhecimento entre outros pesquisadores (novos no domínio). O modelo em diagrama de atividades permite uma visualização do encadeamento das atividades e os dados passados entre elas, enquanto os formulários sintetizam as informações e permitem um rápido acesso a um conteúdo organizado. 5. Trabalhos relacionados Em uma revisão da literatura técnica, apenas Verdi et al. (2007) apresentou um processo definido para concepção de workflows científicos abstratos. Este é composto por 3 fases de modelagem, com etapas de projeto e de validação. Contudo, não definem nenhuma atividade de verificação dos artefatos gerados, realizando somente a validação pelos próprios autores. Este tipo de abordagem pode acarretar risco da não percepção de defeitos no documento. Ainda, a captura das informações é realizada através de três modelos, um para capturar o fluxo de dados, outro para controle e um para hierarquia entre as atividades. Quanto ao modelo de hierarquia, o diagrama de atividades permite a representação de atividades compostas e, em geral, as ferramentas já mantém a consistência entre a atividade e seu modelo interno. Já sobre os fluxos de controle e dados, quando separados, pode haver inconsistência entre as informações nos diversos modelos. Além disso, muitos modelos diferentes podem gerar inconsistência na documentação e somente usar modelos, como em Verdi et. al. (2007), pode acabar por não capturar algumas informações consideradas importantes (e.g. pré e pós-condições, papéis ou riscos). Alguns sistemas utilizam o conceito de template para representar o estudo experimental abstratamente. Contudo, os templates são dependentes do SGWfC e à sua infra-estrutura de execução, onde foram concebidos. Gil et al. (2007) e Kaster et al. 29

38 (2005) apresentam abordagens desse tipo. Esses sistemas permitem que um pesquisador com bom conhecimento do estudo defina o template que, posteriormente, é instanciado para uma infra-estrutura computacional provida pelos sistemas. Porém, isto acarreta uma forte dependência entre o estudo, o template e a plataforma na qual foram concebidos, afinal ele só é utilizado no próprio SGWfC. O estudo acaba ficando restrito, pois a especificação que deveria ser independente de linguagem, ou máquina de workflow, já é concebida pensando em questões relacionadas ao SGWfC. Afinal, os requisitos são os mesmos para o estudo, não importando o SGWfC a ser utilizado. 6. Conclusão A experimentação baseada em simulação vem sendo cada vez mais utilizada em Engenharia de Software [Travassos & Barros, 2003]. Outras áreas da ciência também fazem uso da simulação e, para concretizá-la, utilizam tecnologias como workflows científicos. A Engenharia de Software, em especial a experimental, pode também utilizar tais tecnologias para obter vantagens, como controle, automação da execução e proveniência dos dados gerados em estudos experimentais baseados em simulação. Por isso, foi proposta uma abordagem para apoiar o pesquisador a especificar e gerar workflows científicos abstratos para estudos in virtuo e in silico [Pereira & Travassos, 2009]. Entendemos que a concepção de workflow científicos, em nível abstrato, deve ser independente de SGWfC, pois o estudo em si é independente de tecnologias e a sua execução deveria ser possível, a princípio, em qualquer infra-estrutura. Este artigo apresentou a aplicação da Abordagem de Concepção no domínio da observação da Evolução de Software. Através do uso da abordagem, foi possível capturar o processo para Simular a Evolução de Software de maneira incremental. O modelador e pesquisador responsável identificaram, inicialmente, as atividades e o seus objetivos, artefatos gerados e consumidos e ferramentas, gerando ao final uma especificação do workflow abstrato. Os formulários, quando utilizados, induzem a identificação das informações necessárias para o estudo e sua representação em workflow abstrato, levando à percepção de detalhes ou conhecimento não explicitado se feito de forma ad hoc. A formalização do estudo permite a posterior exploração dessa especificação como insumo para uma implementação em algum SGWfC ou ambiente computacional. A abordagem utilizada neste trabalho ainda está em desenvolvimento para apoiar experimentação baseada em simulação em Engenharia de Software. Melhorias já estão previstas, tal como uso de técnica de inspeção mais formal, por exemplo, checklists calibrados para guiar o inspetor na verificação de questões importantes para o domínio ou na completude das informações. No momento, está sendo revisada de forma mais sistemática a literatura técnica em busca de possíveis abordagens que atendam e possam ser adaptadas a este contexto de estudo in virtuo e in silico. O volume de informações e a repetição de tarefas indicam a necessidade de apoio computacional para melhorar o gerenciamento do conteúdo e inserção automática de informações (e.g., insumos e produtos, pré-atividades, dentre outras), visando diminuir problemas com a consistência entre as informações e o esforço na manipulação e preenchimento dos formulários. 30

39 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 Deelman, E. et al. (2009) Workflows and e-science: An overview of workflow system features and capabilities, In: FGCS, v. 25, n. 5, pp Gil, Y. et al. (2007) Wings for Pegasus: Creating Large-Scale Scientific Applications Using Semantic Representations of Computational Workflows, IAAI 07, Vancouver, Canadá, p 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 Kavanagh, J.; Hall, W. (2008) Grand Challenges in Computing Research 2008, Juristo, N.; Moreno, A.M. (2001) Basics of software engineering experimentation, 1 st 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 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 Medeiros et. al., C.B. (2005) WOODSS and the Web: annotating and reusing scientific workflows, SIGMOD Record, v. 34, n. 3, p Oinn, T. et. al. (2007) "Taverna/myGrid: Aligning a Workflow System with the Life Sciences Community", In: Workflows for e-science, Springer, p Object Management Group (2009) OMG Unified Modeling Language Specification, versão 2.2, formal/ , 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, 2 nd ed., Prentice Hall, 560p. Sociedade Brasileira de Computação (2006). Grandes Desafios da Computação no Brasil: , 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 WESSE, Roma, Italy, pp 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 th APSEC. IEEE Computer Society, Washington, DC, pp

40 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, 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 [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

41 (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

42 de time descrito na Teoria de Belbin com as competências pessoais definidas no Project Management Competency Development PMCD [PMI 2001]. Apesar destas abordagens, poucos estudos de campo foram realizados para o entendimento do processo de alocação de pessoas na prática. O objetivo deste estudo é justamente dirimir esta lacuna na literatura de gerenciamento de projetos. 3. A Teoria Fundamentada em Dados A teoria fundamentada em dados (do inglês, grounded theory) [Glaser 1967] visa originar a partir dos dados coletados, uma teoria que explique o que foi observado nesses dados. Isto é feito através da criação de categorias e relacionamentos entre as mesmas e permite extrair informações úteis de dados que a princípio formavam um grande de volume de dados desestruturados. Dessa forma, a teoria que resulta desta abordagem se parece mais com a realidade do que uma teoria derivada de maneira diferente, como a partir da reunião de uma série de conceitos baseados em experiência ou somente por meio de especulação. Teorias fundamentadas, por serem baseadas em dados, tendem a melhorar o entendimento de um contexto e fornecer um guia importante para ação [Strauss 2008]. Um aspecto importante da teoria fundamentada em dados é que ela intercala as fases de coleta e análise / validação dos dados para fornecer um entendimento sobre o que ocorre na prática e as razões que explicam tais fatos [Seaman 2008]. Portanto, durante as entrevistas, hipóteses são geradas, testadas e modificadas conforme a análise dos dados coletados. Para ser mais especifico, as fases da teoria fundamentada em dados são [Strauss 2008]: (1) Codificação aberta que é um processo analítico por meio do qual os conceitos são identificados e suas propriedades e dimensões descobertas nos dados. De forma geral, durante a codificação aberta, os dados são separados em partes distintas, rigorosamente examinados e comparados em busca de similaridades e de diferenças; (2) Codificação axial que consiste em relacionar categorias com subcategorias e examinar como as categorias se cruzam e se associam, isto é, esta fase visa identificar os relacionamentos entre as categorias; e (3) Codificação seletiva que é um processo contínuo de integração e refinamento da teoria após o reconhecimento das relações entre os conceitos. Neste caso, uma categoria central é escolhida e a teoria é detalhada em torno desta. 4. Caracterização do Estudo 4.1 O Contexto da organização O estudo de campo foi conduzido na Empresa Alpha que tem unidades de desenvolvimento espalhadas em 10 Estados do país atendendo aos requisitos do CMMInível 2 ou 3. Em algumas destas unidades existe o escritório de projetos implantado. Além disso, existe um processo de desenvolvimento de software que foi publicado em 2001 e é utilizado por toda a organização. As entrevistas foram realizadas com dez entrevistados responsáveis pela alocação de pessoas em projetos de desenvolvimento de software. O porte das unidades envolvidas no estudo variou de 44 a 130 empregados e o nível de experiência dos gerentes de projetos variou de 1 ano e meio a 10 anos de experiência, sendo que todos os entrevistados tiveram treinamento corporativo em Gerenciamento de Projetos. A seleção de gerentes de projetos se deu com o intuito de incluir unidades de portes diferentes, com ou sem Escritório de Projetos Funcional [Kerzner 2006] estabelecido, com níveis de experiência variados e que atendem a projetos de características distintas 34

43 (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

44 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

45 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 (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

46 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

47 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 [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

48 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 N o 017/

49 8. Referências ABNT. NBR ISO Gestão da Qualidade Diretrizes para a Qualidade no Gerenciamento de Projetos 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 IEEE Software. 23, 2 (Mar. 2006), 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 IV Simpósio Brasileiro de Qualidade de Software - SBQS Porto Alegre, Brasil. BELBIN, M.R. Management Teams: Why they succeed or Fail. Butterworth-Heinemann, BIFFL, S.; HALLING, M. Investigating the Defect Detection Effectiveness and Cost Benefit of Nominal Inspection IEEE Transactions on Software Engineering 29 (5), DEWALT, K. M.; DEWALT, B. R. Participant Observation A Guideline for Fieldworkers. Altamira Press, California, FERNANDES, F.; SILVA, F. Relações entre Competências Pessoais e Tipos de Personalidade do Gerente de Projetos o. Congresso Brasileiro de Gerenciamento de Projetos FERREIRA, P. ; SILVA, F. Fatores Humanos que Influenciam a Utilização de Processos de Software 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 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, KERZNER, H.Gestão de Projetos: As Melhores Práticas. 2ªed.Bookman, Porto Alegre, PMI - Project Management Institute. A Guide to the Project Management Body of Knowledge - PMBOK Guide. 3rd ed PMI - Project Management Institute. Project Management Competency Development (PMCD) Framework PFLEEGER, S. L. Engenharia de Software: teoria e prática. 2ªEd., SP:Prentice Hall, SCHNAIDER, L.R.C. Planejamento da alocação de recursos humanos em ambientes de desenvolvimento de software orientados à organização 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, p SEI-SOFTWARE ENGINEERING INSTITUTE. CMMi for Software Engineering. Staged Representation (CMU/SEI-02TR029). Pittsburg: Carnegie Mellon University, SHETLER, J. Teaming in the microprocessor laboratory Frontiers in Education Conference, 1996, FIE'96. Volume 3, 6-9 Nov.1996, pp 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 VI Simpósio Brasileiro de Qualidade de Software - SBQS Porto de Galinhas, Brasil SMITH D.C.; BECKER M.; BURNS-HOWELL J.;KYRIAKIDES, J. Creating High performance IS Teams SAICSIT, Pretoria, 2001, SOUZA, M. M. Uma Metodologia de Predição Estatística de Projetos Baseada em Simulação 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,

50 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 , CEP , Rio de Janeiro Brasil {vitorlopes, 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

51 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 ISERN 1 (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 Experimental 2 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 wiki 3, 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 ferramenta 4 sobre a qual o glossário foi disponibilizado à comunidade

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

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

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

55 Engineering Environment), uma infra-estrutura computacional baseada em serviços web que provê facilidades de instanciação de ambientes de apoio ao Processo de Experimentação em Engenharia de Software [Travassos et al., 2008]. O esee consulta o repositório e disponibiliza ao pesquisador o conhecimento necessário para instanciar ambientes com todas as facilidades requeridas para conduzir o estudo desejado [Lopes e Travassos, 2009]. Repositórios de conhecimento expressam, através de uma linguagem de representação de conhecimento específica, conceitos e seus relacionamentos [O Leary, 1998]. Como o repositório proposto para o esee contempla conceitos de Experimentação em Engenharia de Software, os termos listados no glossário podem constituir um conteúdo inicial deste repositório. Assim, o glossário construído até então se revelou um importante mecanismo de representação de conhecimento a ser adotado na estruturação deste repositório [Lopes e Travassos, 2009]. O esee contempla a instanciação de ambientes para diferentes tipos de estudo e, portanto, o conhecimento a cerca desses estudos deve estar refletido no repositório. Lopes e Travassos (2008) identificaram o domínio deste conhecimento, que contempla conceitos ligados às taxonomias de estudo segundo abordagem de pesquisa, estratégia de estudo, método de pesquisa e ambiente de estudo. Entretanto, o glossário construído até então carece de uma cobertura mais satisfatória a cerca dos conceitos sobre essas taxonomias. Desta forma, para consolidar a integração do glossário ao repositório, realizou-se uma pesquisa em referências importantes na literatura de Experimentação em Engenharia de Software. O objetivo foi agregar novos termos sobre as taxonomias previstas em [Lopes e Travassos, 2008], tornando o conteúdo do glossário mais aderente ao conhecimento requerido pelo repositório de conhecimento do esee. As referências selecionadas foram [Juristo e Moreno, 2001], [Shull et al., 2008] e [Wöhlin, 2000]. Foram identificados 28 novos termos, incluídos com sua respectiva definição no glossário através da ferramenta wiki. Com a inclusão dos conceitos sobre os diferentes tipos de estudos previstos em [Lopes e Travassos, 2008], o glossário foi integrado como um dos mecanismos estruturantes do repositório de conhecimento do esee (Figura 2). Como o repositório também deve explicitar relacionamentos entre os conceitos, foram construídas ontologias que representam as relações entre os conceitos expressos no glossário [Lopes e Travassos, 2009]. Figura 2. Repositório de conhecimento de Experimentação em Engenharia de Software 47 [Lopes e Travassos, 2009]

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

57 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

58 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 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, Juristo, N., Moreno, A. (2001). Basics of Software Engineering Experimentation, Kluwer Academic Press, 1ª edição. 50

59 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 Shull, F., Singer, J., Sjøberg, D. I. K. et al., Guide to Empirical Software Engineering, Springer, ISBN: , 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, MediaWiki, (2009), Wohlin, C., Runeson, P., Höst, M., Ohlsson, M., Regnell, B., Wesslén, A., Experimentation in Software Engineering An Introduction. Kluwer Academic Publishers

60 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, 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 desenvolvedor 1 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

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

62 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 rastreabilidade 2, 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

63 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 = {a 1, a 2,... a n } cada qual contendo um conjunto de elementos, ou seja, A = { {e 1,1, e 1,2,...}, {e 2,1, e 2,2,...},... {e n,1, e n,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

64 poderiam ser os elementos base. A partir destes são derivados casos de usos e protótipos, dos quais são derivadas classes, e assim por diante. A técnica não obriga o desenvolvedor a utilizar a derivação, mas se ele a usar as relações de rastreabilidade serão criadas automaticamente pela ferramenta CASE. Os principais passos da técnica indutiva podem ser visualizados na Figura 1. No passo inicial o artefato de destino do elemento a ser derivado é selecionado. Isso só é necessário quando o elemento a ser derivado deve pertencer a um artefato diferente do elemento-causa. Para derivar elementos dentro do mesmo artefato não é necessário selecionar o artefato de destino. O segundo passo consiste em selecionar o elemento-causa, elemento de origem da relação de rastreabilidade. Pode-se, inclusive, selecionar dois ou mais elementos como elemento-causa em uma derivação porque um elemento pode ter várias causas. No terceiro passo é aplicada a derivação sobre o elemento-causa, para dar origem ao elemento-efeito. Juntamente com a criação do elemento-efeito é criada a relação de rastreabilidade. 1- Seleciona o artefato de destino 2- Seleciona o elemento-causa 3- Deriv a o elemento-efeito Figura 1. Passos da rastreabilidade indutiva. Um plugin foi desenvolvido na ferramenta CASE Enterprise Architect (EA) [8], para permitir a utilização da técnica indutiva. Na Figura 2 é apresentada sua interface, os itens destacados (1, 2 e 3) correspondem aos passos necessários para a criação da rastreabilidade apresentados na Figura 1. Neste exemplo são derivados casos de uso a partir de requisitos, porém a técnica indutiva pode permitir a criação de elementos em diversos outros artefatos. As relações criadas podem ser visualizadas por meio da matriz de rastreabilidade e também da funcionalidade Hierarchy do EA. Hierarchy apresenta de forma hierárquica as dependências entre os elementos Figura 2. Interface do plugin de rastreabilidade. A intenção da técnica indutiva é reduzir o esforço do desenvolvedor no mapeamento da rastreabilidade, tornando a atividade menos penosa em comparação às técnicas atualmente utilizadas. Com isto espera-se que a resistência à utilização da rastreabilidade possa diminuir. 56

UNIVERSIDADE DE SÃO PAULO FACULDADE DE EDUCAÇÃO JOÃO FÁBIO PORTO. Diálogo e interatividade em videoaulas de matemática

UNIVERSIDADE DE SÃO PAULO FACULDADE DE EDUCAÇÃO JOÃO FÁBIO PORTO. Diálogo e interatividade em videoaulas de matemática UNIVERSIDADE DE SÃO PAULO FACULDADE DE EDUCAÇÃO JOÃO FÁBIO PORTO Diálogo e interatividade em videoaulas de matemática São Paulo 2010 JOÃO FÁBIO PORTO Diálogo e interatividade em videoaulas de matemática

Leia mais

Banca examinadora: Professor Paulo N. Figueiredo, Professora Fátima Bayma de Oliveira e Professor Joaquim Rubens Fontes Filho

Banca examinadora: Professor Paulo N. Figueiredo, Professora Fátima Bayma de Oliveira e Professor Joaquim Rubens Fontes Filho Título: Direção e Taxa (Velocidade) de Acumulação de Capacidades Tecnológicas: Evidências de uma Pequena Amostra de Empresas de Software no Rio de Janeiro, 2004 Autor(a): Eduardo Coelho da Paz Miranda

Leia mais

Interoperability through Web Services: Evaluating OGC Standards in Client Development for Spatial Data Infrastructures

Interoperability through Web Services: Evaluating OGC Standards in Client Development for Spatial Data Infrastructures GeoInfo - 2006 Interoperability through Web Services: Evaluating OGC Standards in Client Development for Spatial Data Infrastructures Leonardo Lacerda Alves Clodoveu A. Davis Jr. Information Systems Lab

Leia mais

Course Computer Science Academic year 2012/2013 Subject Social Aspects of Computers ECTS 5

Course Computer Science Academic year 2012/2013 Subject Social Aspects of Computers ECTS 5 Course Computer Science Academic year 2012/2013 Subject Social Aspects of Computers ECTS 5 Type of course Compulsory Year 2º Semester 2nd sem Student Workload: Professor(s) Natalia Gomes, Ascensão Maria

Leia mais

Mestrado em Ciências Jurídicas Especialização em História do Direito 2015-16

Mestrado em Ciências Jurídicas Especialização em História do Direito 2015-16 Mestrado em Ciências Jurídicas Especialização em História do Direito Unidade curricular História do Direito Português I (1º sem). Docente responsável e respectiva carga lectiva na unidade curricular Prof.

Leia mais

A Cloud Computing Architecture for Large Scale Video Data Processing

A Cloud Computing Architecture for Large Scale Video Data Processing Marcello de Lima Azambuja A Cloud Computing Architecture for Large Scale Video Data Processing Dissertação de Mestrado Dissertation presented to the Postgraduate Program in Informatics of the Departamento

Leia mais

User interface evaluation experiences: A brief comparison between usability and communicability testing

User interface evaluation experiences: A brief comparison between usability and communicability testing User interface evaluation experiences: A brief comparison between usability and communicability testing Kern, Bryan; B.S.; The State University of New York at Oswego kern@oswego.edu Tavares, Tatiana; PhD;

Leia mais

Tese / Thesis Work Análise de desempenho de sistemas distribuídos de grande porte na plataforma Java

Tese / Thesis Work Análise de desempenho de sistemas distribuídos de grande porte na plataforma Java Licenciatura em Engenharia Informática Degree in Computer Science Engineering Análise de desempenho de sistemas distribuídos de grande porte na plataforma Java Performance analysis of large distributed

Leia mais

Digital Cartographic Generalization for Database of Cadastral Maps

Digital Cartographic Generalization for Database of Cadastral Maps Mariane Alves Dal Santo marianedalsanto@udesc.br Francisco Henrique de Oliveira chicoliver@yahoo.com.br Carlos Loch cloch@ecv.ufsc.br Laboratório de Geoprocessamento GeoLab Universidade do Estado de Santa

Leia mais

Project Management Activities

Project Management Activities Id Name Duração Início Término Predecessoras 1 Project Management Activities 36 dias Sex 05/10/12 Sex 23/11/12 2 Plan the Project 36 dias Sex 05/10/12 Sex 23/11/12 3 Define the work 15 dias Sex 05/10/12

Leia mais

BR-EMS MORTALITY AND SUVIVORSHIP LIFE TABLES BRAZILIAN LIFE INSURANCE AND PENSIONS MARKET

BR-EMS MORTALITY AND SUVIVORSHIP LIFE TABLES BRAZILIAN LIFE INSURANCE AND PENSIONS MARKET BR-EMS MORTALITY AND SUVIVORSHIP LIFE TABLES BRAZILIAN LIFE INSURANCE AND PENSIONS MARKET 2015 1 e-mail:mario@labma.ufrj.br Tables BR-EMS, mortality experience of the Brazilian Insurance Market, were constructed,

Leia mais

Ficha de unidade curricular Curso de Doutoramento

Ficha de unidade curricular Curso de Doutoramento Ficha de unidade curricular Curso de Doutoramento Unidade curricular História do Direito Português I (Doutoramento - 1º semestre) Docente responsável e respectiva carga lectiva na unidade curricular Prof.

Leia mais

DPI. Núcleo de Apoio ao Desenvolvimento de Projetos e Internacionalização Project Development And Internationalization Support Office

DPI. Núcleo de Apoio ao Desenvolvimento de Projetos e Internacionalização Project Development And Internationalization Support Office DPI Núcleo de Apoio ao Desenvolvimento de Projetos e Internacionalização Project Development And Internationalization Support Office Apresentação/Presentation Criado em 1 de março de 2011, o Núcleo de

Leia mais

Geração automática de suíte de teste para GUI a partir de Rede de Petri

Geração automática de suíte de teste para GUI a partir de Rede de Petri Raquel Jauffret Guilhon Geração automática de suíte de teste para GUI a partir de Rede de Petri Dissertação de Mestrado Dissertação apresentada como requisito parcial para obtenção do grau de Mestre pelo

Leia mais

Reitor / President Marcos Macari, Ph.D. Vice-Reitor /Vice-President Herman Jacobus Cornelis Voorwald, Ph.D.

Reitor / President Marcos Macari, Ph.D. Vice-Reitor /Vice-President Herman Jacobus Cornelis Voorwald, Ph.D. UNIVERSIDADE ESTADUAL PAULISTA JULIO DE MESQUITA FILHO Reitor / President Marcos Macari, Ph.D. Vice-Reitor /Vice-President Herman Jacobus Cornelis Voorwald, Ph.D. Pró-Reitora de Pós-Graduação / Graduate

Leia mais

Ontology Building Process: The Wine Domain

Ontology Building Process: The Wine Domain Ontology Building Process: The Wine Domain João Graça, Márcio Mourão, Orlando Anunciação, Pedro Monteiro, H. Sofia Pinto, and Virgílio Loureiro Summary Context Ontology Wine Domain Existing Wine Ontologies

Leia mais

Analysis, development and monitoring of business processes in Corporate environment

Analysis, development and monitoring of business processes in Corporate environment Analysis, development and monitoring of business processes in Corporate environment SAFIRA is an IT consulting boutique known for transforming the way organizations do business, or fulfil their missions,

Leia mais

Engenharia de Requisitos. Professor: Dr. Eduardo Santana de Almeida Universidade Federal da Bahia esa@dcc.ufba.br

Engenharia de Requisitos. Professor: Dr. Eduardo Santana de Almeida Universidade Federal da Bahia esa@dcc.ufba.br Engenharia de Requisitos Professor: Dr. Eduardo Santana de Almeida Universidade Federal da Bahia esa@dcc.ufba.br O Documento de Requisitos Introdução The requirements for a system are the descriptions

Leia mais

BIBLIOGRAFIA. Faupel, A. & Sharp, P. (2003). Promoting emotional literacy. Guidelines for schools, local authorities and

BIBLIOGRAFIA. Faupel, A. & Sharp, P. (2003). Promoting emotional literacy. Guidelines for schools, local authorities and RESUMO EXPANDIDO Pode definir-se Literacia Emocional como a capacidade para reconhecer, compreender, expressar e gerir estados emocionais, do próprio e de outras pessoas, existindo associações entre esta

Leia mais

Português 207 Portuguese for Business

Português 207 Portuguese for Business Português 207 Portuguese for Business Spring 2012: Porugal and the EU Instructor: Jared Hendrickson Office: 1149 Van Hise Office Hours: Monday and Thursday, 11:00 am-12:00 pm e-mail: jwhendrickso@wisc.edu

Leia mais

Software product lines. Paulo Borba Informatics Center Federal University of Pernambuco

Software product lines. Paulo Borba Informatics Center Federal University of Pernambuco Software product lines Paulo Borba Informatics Center Federal University of Pernambuco Software product lines basic concepts Paulo Borba Informatics Center Federal University of Pernambuco Um produto www.usm.maine.edu

Leia mais

INFORMATION SECURITY IN ORGANIZATIONS

INFORMATION SECURITY IN ORGANIZATIONS INFORMATION SECURITY IN ORGANIZATIONS Ana Helena da Silva, MCI12017 Cristiana Coelho, MCI12013 2 SUMMARY 1. Introduction 2. The importance of IT in Organizations 3. Principles of Security 4. Information

Leia mais

Universidade do Minho. Escola de Engenharia. UC transversais Programas Doutorais 1º semestre 2012-13. 11 de outubro 2012

Universidade do Minho. Escola de Engenharia. UC transversais Programas Doutorais 1º semestre 2012-13. 11 de outubro 2012 Universidade do Minho Escola de Engenharia UC transversais Programas Doutorais 1º semestre 2012-13 11 de outubro 2012 1 2 2 courses offered in the first semestre: Métodos de Investigação em Engenharia

Leia mais

ESTRUTURA DE CAPITAL: UMA ANÁLISE EM EMPRESAS SEGURADORAS

ESTRUTURA DE CAPITAL: UMA ANÁLISE EM EMPRESAS SEGURADORAS ESTRUTURA DE CAPITAL: UMA ANÁLISE EM EMPRESAS SEGURADORAS THE CAPITAL STRUCTURE: AN ANALYSE ON INSURANCE COMPANIES FREDERIKE MONIKA BUDINER METTE MARCO ANTÔNIO DOS SANTOS MARTINS PAULA FERNANDA BUTZEN

Leia mais

1. Lingüística Periódicos. 2. Língua Inglesa Periódicos

1. Lingüística Periódicos. 2. Língua Inglesa Periódicos ISSN 0102-7077 the ESP São Paulo Vol. 25 nº especial p. 1-114 2004 The Especialist/Centro de Pesquisas, Recursos e Informação em Leitura da Pontifícia Universidade Católica de São Paulo CEPRIL. V. 1, n.

Leia mais

Uma Análise da História do VEM, WBVS e WMSWM

Uma Análise da História do VEM, WBVS e WMSWM VEM Uma Análise da História do VEM, WBVS e WMSWM Renato Novais, Thiago S. Mendes, Fernando Teles Instituto Federal da Bahia (IFBA) Salvador Bahia Brasil {renato,thiagosouto,fernandoteles}@ifba.edu.br Abstract.

Leia mais

Contribution of the top boat game for learning production engineering concepts

Contribution of the top boat game for learning production engineering concepts Contribution of the top boat game for learning production engineering concepts Carla Sena Batista, Fabiana Lucena Oliveira, Enily Vieira do Nascimento, Viviane Da Silva Costa Novo Research Problem: How

Leia mais

A tangibilidade de um serviço de manutenção de elevadores

A tangibilidade de um serviço de manutenção de elevadores A tangibilidade de um serviço de manutenção de elevadores Tese de Mestrado em Gestão Integrada de Qualidade, Ambiente e Segurança Carlos Fernando Lopes Gomes INSTITUTO SUPERIOR DE EDUCAÇÃO E CIÊNCIAS Fevereiro

Leia mais

ACFES MAIORES DE 23 ANOS INGLÊS. Prova-modelo. Instruções. Verifique se o exemplar da prova está completo, isto é, se termina com a palavra FIM.

ACFES MAIORES DE 23 ANOS INGLÊS. Prova-modelo. Instruções. Verifique se o exemplar da prova está completo, isto é, se termina com a palavra FIM. ACFES MAIORES DE 23 ANOS INGLÊS Prova-modelo Instruções Verifique se o exemplar da prova está completo, isto é, se termina com a palavra FIM. A prova é avaliada em 20 valores (200 pontos). A prova é composta

Leia mais

e-lab: a didactic interactive experiment An approach to the Boyle-Mariotte law

e-lab: a didactic interactive experiment An approach to the Boyle-Mariotte law Sérgio Leal a,b, João Paulo Leal a,c Horácio Fernandes d a Departamento de Química e Bioquímica, FCUL, Lisboa, Portugal b Escola Secundária com 3.º ciclo Padre António Vieira, Lisboa, Portugal c Unidade

Leia mais

Lucas Figueiredo Gonçalves

Lucas Figueiredo Gonçalves Lucas Figueiredo Gonçalves Master s student in Computer Graphics at Federal University of Rio de Janeiro luccashappy@gmail.com Summary I m a Master s student in Computer Graphics at Federal University

Leia mais

Online Collaborative Learning Design

Online Collaborative Learning Design "Online Collaborative Learning Design" Course to be offered by Charlotte N. Lani Gunawardena, Ph.D. Regents Professor University of New Mexico, Albuquerque, New Mexico, USA July 7- August 14, 2014 Course

Leia mais

Autor: Débora Saraiva de Melo Anversa 1 Co-Autores: Teresinha Rita Boufleuer 2 Franciele Pastre 3 Andreici Daiani Vedovatto 4 Ademar Tibola 5

Autor: Débora Saraiva de Melo Anversa 1 Co-Autores: Teresinha Rita Boufleuer 2 Franciele Pastre 3 Andreici Daiani Vedovatto 4 Ademar Tibola 5 Proposta de Desenvolvimento do Empreendedor na INCTECh: adequação à prática chave segundo a metodologia CERNE 1. Proposal for Entrepreneurial Development at INCTECh: suitability to practice key according

Leia mais

Universidade de São Paulo USP Departamento de Engenharia de Produção EESC Programa de Pós-Graduação em Engenharia de Produção

Universidade de São Paulo USP Departamento de Engenharia de Produção EESC Programa de Pós-Graduação em Engenharia de Produção Universidade de São Paulo USP Departamento de Engenharia de Produção EESC Programa de Pós-Graduação em Engenharia de Produção APLICAÇÃO DOS ESTILOS DE APRENDIZAGEM NA FORMAÇÃO DE EQUIPES :um estudo de

Leia mais

METODOLOGIA DE AVALIAÇÃO DAS STARTUPS DO MIDI TECNOLÓGICO

METODOLOGIA DE AVALIAÇÃO DAS STARTUPS DO MIDI TECNOLÓGICO METODOLOGIA DE AVALIAÇÃO DAS STARTUPS DO MIDI TECNOLÓGICO RESUMO As incubadoras de empresas são ambientes dotados de competência gerencial, técnica e administrativa que impulsionam a promoção do nascimento

Leia mais

Multicriteria Impact Assessment of the certified reference material for ethanol in water

Multicriteria Impact Assessment of the certified reference material for ethanol in water Multicriteria Impact Assessment of the certified reference material for ethanol in water André Rauen Leonardo Ribeiro Rodnei Fagundes Dias Taiana Fortunato Araujo Taynah Lopes de Souza Inmetro / Brasil

Leia mais

Informática e Programação. Computer Science and Programming. Semestre do plano de estudos 1

Informática e Programação. Computer Science and Programming. Semestre do plano de estudos 1 Nome UC Informática e Programação CU Name Código UC 4 Curso LEC Semestre do plano de estudos 1 Área científica Informática Duração Semestral Horas de trabalho 135 ECTS 5 Horas de contacto TP - 67,5 Observações

Leia mais

A meus pais, Ari e Célia, sempre presentes, todo o meu amor incondicional!

A meus pais, Ari e Célia, sempre presentes, todo o meu amor incondicional! ii A meus pais, Ari e Célia, sempre presentes, todo o meu amor incondicional! iii Agradeço à Deus, esta força maior, pela vida, pela sabedoria e pelo amor. Mas, sobretudo, por me ensinar saber fazer ser

Leia mais

ACEF/1112/04062 Decisão de apresentação de pronúncia

ACEF/1112/04062 Decisão de apresentação de pronúncia ACEF/1112/04062 Decisão de apresentação de pronúncia ACEF/1112/04062 Decisão de apresentação de pronúncia Decisão de Apresentação de Pronúncia ao Relatório da Comissão de Avaliação Externa 1. Tendo recebido

Leia mais

USPTO No. 15143095 USPTO No. 15143095 USPTO No. 15143095 USPTO No. 15143095 USPTO No. 15143095 USPTO No. 15143095 USPTO No. 15143095 WORK PLAN FOR IMPLEMENTATION OF THE UNITED STATES PATENT AND

Leia mais

Consórcio do Politecnico di Milano. Fevereiro 2013

Consórcio do Politecnico di Milano. Fevereiro 2013 Consórcio do Politecnico di Milano Fevereiro 2013 DESIGN DEFINITIONS SENAI & POLI.design Fevereiro 2013 Design como uma atividade específica no processo de P&D que visa a projetação dos aspectos funcionais

Leia mais

JOSE GABRIEL REGO. Resumo. Especializações. Experiência. Assistant Card Manager at Grupo Banco Popular jgrego@netcabo.pt

JOSE GABRIEL REGO. Resumo. Especializações. Experiência. Assistant Card Manager at Grupo Banco Popular jgrego@netcabo.pt JOSE GABRIEL REGO jgrego@netcabo.pt Resumo My main objective is to develop my career in order to deepen the experience I accumulated over the years based in the development of practical and theoretical

Leia mais

Salud Brasil SECRETARIA DE VIGILÂNCIA EM SAÚDE

Salud Brasil SECRETARIA DE VIGILÂNCIA EM SAÚDE Salud Brasil SECRETARIA DE VIGILÂNCIA EM SAÚDE IV EXPOEPI International Perspectives on Air Quality: Risk Management Principles for Oficina de Trabalho: Os Desafios e Perspectivas da Vigilância Ambiental

Leia mais

Institutional Skills. Sessão informativa INSTITUTIONAL SKILLS. Passo a passo. www.britishcouncil.org.br

Institutional Skills. Sessão informativa INSTITUTIONAL SKILLS. Passo a passo. www.britishcouncil.org.br Institutional Skills Sessão informativa INSTITUTIONAL SKILLS Passo a passo 2 2 British Council e Newton Fund O British Council é a organização internacional do Reino Unido para relações culturais e oportunidades

Leia mais

T Ã O B O M Q U A N T O N O V O

T Ã O B O M Q U A N T O N O V O D I S S E R T A Ç Ã O D E M E S T R A D O M A S T E R I N G D I S S E R T A T I O N A V A L I A Ç Ã O D A C O N D I Ç Ã O D E T Ã O B O M Q U A N T O N O V O U M A A P L I C A Ç Ã O E N V O L V E N D O

Leia mais

NCE/11/01206 Decisão de apresentação de pronúncia - Novo ciclo de estudos

NCE/11/01206 Decisão de apresentação de pronúncia - Novo ciclo de estudos NCE/11/01206 Decisão de apresentação de pronúncia - Novo ciclo de estudos NCE/11/01206 Decisão de apresentação de pronúncia - Novo ciclo de estudos Decisão de Apresentação de Pronúncia ao Relatório da

Leia mais

ESCOLA SUPERIOR DE TECNOLOGIA E GESTÃO DE FELGUEIRAS

ESCOLA SUPERIOR DE TECNOLOGIA E GESTÃO DE FELGUEIRAS Curricular Unit Plan ESCOLA SUPERIOR DE TECNOLOGIA E GESTÃO DE FELGUEIRAS CURSO Licenciatura em Engenharia Informática U.C. GESTÃO DE PROJECTOS INFORMÁTICOS Horas presenciais / Ano 56 Ano Lectivo 2010

Leia mais

NCE/10/00806 Decisão de apresentação de pronúncia - Novo ciclo de estudos

NCE/10/00806 Decisão de apresentação de pronúncia - Novo ciclo de estudos NCE/10/00806 Decisão de apresentação de pronúncia - Novo ciclo de estudos NCE/10/00806 Decisão de apresentação de pronúncia - Novo ciclo de estudos Decisão de Apresentação de Pronúncia ao Relatório da

Leia mais

GUIÃO A. Ano: 9º Domínio de Referência: O Mundo do Trabalho. 1º Momento. Intervenientes e Tempos. Descrição das actividades

GUIÃO A. Ano: 9º Domínio de Referência: O Mundo do Trabalho. 1º Momento. Intervenientes e Tempos. Descrição das actividades Ano: 9º Domínio de Referência: O Mundo do Trabalho GUIÃO A 1º Momento Intervenientes e Tempos Descrição das actividades Good morning / afternoon / evening, A and B. For about three minutes, I would like

Leia mais

A Influência do Correio Eletrônico na Comunicação Organizacional

A Influência do Correio Eletrônico na Comunicação Organizacional Claudia Müller de Almeida A Influência do Correio Eletrônico na Comunicação Organizacional Dissertação de Mestrado Dissertação apresentada como requisito parcial para obtenção do grau de Mestre pelo Programa

Leia mais

PREFEITURA MUNICIPAL DE BOM DESPACHO-MG PROCESSO SELETIVO SIMPLIFICADO - EDITAL

PREFEITURA MUNICIPAL DE BOM DESPACHO-MG PROCESSO SELETIVO SIMPLIFICADO - EDITAL CADERNO DE PROVAS 1 A prova terá a duração de duas horas, incluindo o tempo necessário para o preenchimento do gabarito. 2 Marque as respostas no caderno de provas, deixe para preencher o gabarito depois

Leia mais

UNIVERSIDADE DE ÉVORA

UNIVERSIDADE DE ÉVORA UNIVERSIDADE DE ÉVORA MESTRADO EM INTERVENÇÃO SÓCIO-ORGANIZACIONÀL NA SAÚDE Curso ministrado em parceria com a Escola Superior de Tecnologia da Saúde de Lisboa (DR Série, n.. 250 de 29 de Outubro de 2002)

Leia mais

Semestre do plano de estudos 1

Semestre do plano de estudos 1 Nome UC Inglês CU Name Código UC 6 Curso LEC Semestre do plano de estudos 1 Área científica Gestão Duração Semestral Horas de trabalho 54 ECTS 2 Horas de contacto TP - 22,5 Observações n.a. Docente responsável

Leia mais

MAUS TRATOS NA POPULAÇÃO IDOSA INSTITUCIONALIZADA

MAUS TRATOS NA POPULAÇÃO IDOSA INSTITUCIONALIZADA Universidade de Lisboa Faculdade de Medicina de Lisboa MAUS TRATOS NA POPULAÇÃO IDOSA INSTITUCIONALIZADA Catarina Isabel Fonseca Paulos Mestrado em Medicina Legal e Ciências Forenses 2005 Esta dissertação

Leia mais

Welcome to Lesson A of Story Time for Portuguese

Welcome to Lesson A of Story Time for Portuguese Portuguese Lesson A Welcome to Lesson A of Story Time for Portuguese Story Time is a program designed for students who have already taken high school or college courses or students who have completed other

Leia mais

Information technology specialist (systems integration) Especialista em tecnologia da informação (integração de sistemas)

Information technology specialist (systems integration) Especialista em tecnologia da informação (integração de sistemas) Information technology specialist (systems integration) Especialista em tecnologia da informação (integração de sistemas) Professional activities/tasks Design and produce complex ICT systems by integrating

Leia mais

Interactive Internet TV Architecture Based on Scalable Video Coding

Interactive Internet TV Architecture Based on Scalable Video Coding Interactive Internet TV Architecture Based on Scalable Video Coding Pedro Gomes Moscoso Dissertação para obtenção do Grau de Mestre em Engenharia de Redes de Comunicações Presidente: Orientador: Co-Orientador:

Leia mais

Software reliability analysis by considering fault dependency and debugging time lag Autores

Software reliability analysis by considering fault dependency and debugging time lag Autores Campos extraídos diretamente Título Software reliability analysis by considering fault dependency and debugging time lag Autores Huang, Chin-Yu and Lin, Chu-Ti Ano de publicação 2006 Fonte de publicação

Leia mais

Apresentação V.B.M.P.S.

Apresentação V.B.M.P.S. ISSN 0102-7077 the ESP São Paulo Vol. 25 nº 1 p. 1-106 2004 The Especialist/Centro de Pesquisas, Recursos e Informação em Leitura da Pontifícia Universidade Católica de São Paulo CEPRIL. V. 1, n. 1 (1980)-.

Leia mais

BRIGHAM AND EHRHARDT PDF

BRIGHAM AND EHRHARDT PDF BRIGHAM AND EHRHARDT PDF ==> Download: BRIGHAM AND EHRHARDT PDF BRIGHAM AND EHRHARDT PDF - Are you searching for Brigham And Ehrhardt Books? Now, you will be happy that at this time Brigham And Ehrhardt

Leia mais

OUTRA FORMA DE VER? A CONSTRUÇÃO DO AUTOCONCEITO DE CRIANÇAS CEGAS E AMBLIOPES

OUTRA FORMA DE VER? A CONSTRUÇÃO DO AUTOCONCEITO DE CRIANÇAS CEGAS E AMBLIOPES UNIVERSIDADE CATÓLICA PORTUGUESA CENTRO REGIONAL DE BRAGA FACULDADE DE CIÊNCIAS SOCIAIS OUTRA FORMA DE VER? A CONSTRUÇÃO DO AUTOCONCEITO DE CRIANÇAS CEGAS E AMBLIOPES II Ciclo de Estudos em Ciências da

Leia mais

FICHAS DE UNIDADES CURRICULARES

FICHAS DE UNIDADES CURRICULARES FICHAS DE UNIDADES CURRICULARES a. Unidade curricular Course unit title: Construção da Imagem Fílmica Construction of the Filmic Image Código: 01343927 Code: 01343927 b. ECTS: 5.0 c. Horas de contacto

Leia mais

Unidade curricular: Sistemas de Informação para a Gestão Nº horas: 75 ECTS: 7 1.º ano

Unidade curricular: Sistemas de Informação para a Gestão Nº horas: 75 ECTS: 7 1.º ano Licenciatura em Gestão (1º ciclo) First Cycle Degree in Management Unidade curricular: Sistemas de Informação para a Gestão Nº horas: 75 ECTS: 7 1.º ano Curricular Unit: Information Systems for Management

Leia mais

assumptions of that particular strengthening the participation of families and local communities in the strategic direction of schools, not taking

assumptions of that particular strengthening the participation of families and local communities in the strategic direction of schools, not taking Agradecimentos A dissertação do Mestrado que adiante se apresenta resulta na concretização de um projecto que me parecia difícil mas não impossível de alcançar. Foram meses seguidos de trabalho de investigação,

Leia mais

Guião A. Descrição das actividades

Guião A. Descrição das actividades Proposta de Guião para uma Prova Grupo: Ponto de Encontro Disciplina: Inglês, Nível de Continuação, 11.º ano Domínio de Referência: Um Mundo de Muitas Culturas Duração da prova: 15 a 20 minutos 1.º MOMENTO

Leia mais

Guião M. Descrição das actividades

Guião M. Descrição das actividades Proposta de Guião para uma Prova Grupo: Inovação Disciplina: Inglês, Nível de Continuação, 11.º ano Domínio de Referência: O Mundo do trabalho Duração da prova: 15 a 20 minutos 1.º MOMENTO Guião M Intervenientes

Leia mais

Avaliação de Investimentos em Tecnologia da Informação: uma Perspectiva de Opções Reais

Avaliação de Investimentos em Tecnologia da Informação: uma Perspectiva de Opções Reais André Fichel Nascimento Avaliação de Investimentos em Tecnologia da Informação: uma Perspectiva de Opções Reais Dissertação de Mestrado Dissertação apresentada ao Programa de Pós-graduação em Engenharia

Leia mais

A PERCEPÇÃO DOS DISCENTES SOBRE O DESEMPENHO DOS DOCENTES DOS CURSOS DE CIÊNCIAS CONTÁBEIS E ADMINISTRAÇÃO DA UNIVERSIDADE REGIONAL DE BLUMENAU

A PERCEPÇÃO DOS DISCENTES SOBRE O DESEMPENHO DOS DOCENTES DOS CURSOS DE CIÊNCIAS CONTÁBEIS E ADMINISTRAÇÃO DA UNIVERSIDADE REGIONAL DE BLUMENAU A PERCEPÇÃO DOS DISCENTES SOBRE O DESEMPENHO DOS DOCENTES DOS CURSOS DE CIÊNCIAS CONTÁBEIS E ADMINISTRAÇÃO DA UNIVERSIDADE REGIONAL DE BLUMENAU PERCEPTION OF STUDENTS PERFORMANCE OF TEACHERS OF SCIENCE

Leia mais

A elaboração da presente dissertação foi apoiada, em parte, por um financiamento da Junta Nacional de Investigação Científica e Tecnológica, no

A elaboração da presente dissertação foi apoiada, em parte, por um financiamento da Junta Nacional de Investigação Científica e Tecnológica, no Dissertação de Mestrado em Psicologia, especialização em Psicologia Desportiva, sob a orientação conjunta do Prof. Doutor José Fernando da Silva Azevedo Cruz e do Prof. Doutor Leandro da Silva Almeida.

Leia mais

Redes Neurais na Manutenção Preditiva de Caminhões Fora de Estrada

Redes Neurais na Manutenção Preditiva de Caminhões Fora de Estrada Felipe Miana de Faria Furtado Redes Neurais na Manutenção Preditiva de Caminhões Fora de Estrada Dissertação de Mestrado Dissertação apresentada como requisito parcial para obtenção do grau de Mestre pelo

Leia mais

Erasmus Student Work Placement

Erasmus Student Work Placement Erasmus Student Work Placement EMPLOYER INFORMATION Name of organisation Address Post code Country SPORT LISBOA E BENFICA AV. GENERAL NORTON DE MATOS, 1500-313 LISBOA PORTUGAL Telephone 21 721 95 09 Fax

Leia mais

Ficha da Unidade Curricular

Ficha da Unidade Curricular ESCOLA SUPERIOR DE TECNOLOGIA E GESTÃO DE FELGUEIRAS CURSO Licenciatura em Engenharia Informática U.C. SISTEMAS DE INFORMAÇÃO Ficha da Unidade Curricular Horas presenciais / Ano 56 Ano Lectivo 2010 / 2011

Leia mais

UNIVERSIDADE CATÓLICA PORTUGUESA. A Reputação e a Responsabilidade Social na BP Portugal: A importância da Comunicação. Por. Ana Margarida Nisa Vintém

UNIVERSIDADE CATÓLICA PORTUGUESA. A Reputação e a Responsabilidade Social na BP Portugal: A importância da Comunicação. Por. Ana Margarida Nisa Vintém UNIVERSIDADE CATÓLICA PORTUGUESA A Reputação e a Responsabilidade Social na BP Portugal: A importância da Comunicação Relatório de estágio apresentado à Universidade Católica Portuguesa para obtenção do

Leia mais

Uma Abordagem para a Avaliação de Processos de Desenvolvimento de Software Baseada em Risco e Conformidade

Uma Abordagem para a Avaliação de Processos de Desenvolvimento de Software Baseada em Risco e Conformidade Rafael de Souza Lima Espinha Uma Abordagem para a Avaliação de Processos de Desenvolvimento de Software Baseada em Risco e Conformidade Dissertação de Mestrado Dissertação apresentada como requisito parcial

Leia mais

MODELAGEM VISUAL DE UM SOFTWARE PARA O GERENCIAMENTO DAS COMUNICAÇÕES EM GESTÃO DE PROJETOS

MODELAGEM VISUAL DE UM SOFTWARE PARA O GERENCIAMENTO DAS COMUNICAÇÕES EM GESTÃO DE PROJETOS 127 MODELAGEM VISUAL DE UM SOFTWARE PARA O GERENCIAMENTO DAS COMUNICAÇÕES EM GESTÃO DE PROJETOS VISUAL MODELING OF SOFTWARE FOR COMMUNICATION MANAGEMENT IN PROJECT MANAGEMENT Ricardo Rall 1 Arilson José

Leia mais

design para a inovação social

design para a inovação social design para a inovação social mestrado em design - 15 16 universidade de aveiro gonçalo gomes março de 2016 s.1 ergonomia ergonomia > definição Ergonomia A ergonomia (do grego "ergon": trabalho; e "nomos":

Leia mais

Ficha de Unidade Curricular Ano letivo 2014/2015

Ficha de Unidade Curricular Ano letivo 2014/2015 6.2.1.1. Unidade curricular: Curricular Unit: Ficha de Unidade Curricular Ano letivo 2014/2015 Design de Interface Interface Design 6.2.1.2. Docente responsável e respectivas horas de contacto na unidade

Leia mais

Treinamento para Pais Cidadania digital No Nível Fundamental. Parent Academy Digital Citizenship. At Elementary Level

Treinamento para Pais Cidadania digital No Nível Fundamental. Parent Academy Digital Citizenship. At Elementary Level Parent Academy Digital Citizenship At Elementary Level Treinamento para Pais Cidadania digital No Nível Fundamental Pan American School of Bahia March 18 and 29, 2016 Digital Citizenship Modules Cyberbullying

Leia mais

Capital Humano e Capital Social: Construir Capacidades para o Desenvolvimento dos Territórios

Capital Humano e Capital Social: Construir Capacidades para o Desenvolvimento dos Territórios UNIVERSIDADE DE LISBOA FACULDADE DE LETRAS DEPARTAMENTO DE GEOGRAFIA Capital Humano e Capital Social: Construir Capacidades para o Desenvolvimento dos Territórios Sandra Sofia Brito da Silva Dissertação

Leia mais

SPATIAL DISTRIBUITION OF TURBITY IN A STRETCH OF MADEIRA RIVER MONITORING MADEIRA RIVER PROJECT PORTO VELHO (RO)

SPATIAL DISTRIBUITION OF TURBITY IN A STRETCH OF MADEIRA RIVER MONITORING MADEIRA RIVER PROJECT PORTO VELHO (RO) SPATIAL DISTRIBUITION OF TURBITY IN A STRETCH OF MADEIRA RIVER MONITORING MADEIRA RIVER PROJECT PORTO VELHO (RO) 4th scientific meeting of the ORE-HIBAM. September 2011 4a Scientific Meeting ORE-HYBAM

Leia mais

Proposta de Modelo de Desenvolvimento de Sistema de Medição de Desempenho Logístico

Proposta de Modelo de Desenvolvimento de Sistema de Medição de Desempenho Logístico Winston Carvalho Santana Proposta de Modelo de Desenvolvimento de Sistema de Medição de Desempenho Logístico DISSERTAÇÃO DE MESTRADO DEPARTAMENTO DE ENGENHARIA INDUSTRIAL Programa de Pós-Graduação Profissional

Leia mais

Responsabilidade Social no Ensino em Administração: um estudo exploratório sobre a visão dos estudantes de graduação

Responsabilidade Social no Ensino em Administração: um estudo exploratório sobre a visão dos estudantes de graduação Renata Céli Moreira da Silva Responsabilidade Social no Ensino em Administração: um estudo exploratório sobre a visão dos estudantes de graduação Dissertação de Mestrado Dissertação apresentada ao Programa

Leia mais

NORMAS PARA AUTORES. As normas a seguir descritas não dispensam a leitura do Regulamento da Revista Portuguesa de Marketing, disponível em www.rpm.pt.

NORMAS PARA AUTORES. As normas a seguir descritas não dispensam a leitura do Regulamento da Revista Portuguesa de Marketing, disponível em www.rpm.pt. NORMAS PARA AUTORES As normas a seguir descritas não dispensam a leitura do Regulamento da Revista Portuguesa de Marketing, disponível em www.rpm.pt. COPYRIGHT Um artigo submetido à Revista Portuguesa

Leia mais

2. Conhecer a diversidade e complexidade de temáticas que podem ser abrangidas por esta área de conhecimento.

2. Conhecer a diversidade e complexidade de temáticas que podem ser abrangidas por esta área de conhecimento. Ficha de Unidade Curricular 1. Unidade curricular / Curricular Unit Psicologia Geral / General Psychology 2. Designação do Ciclo de Estudos em que se insere a Unidade Curricular (com semestre e ano lectivo)

Leia mais

SUPLEMENTO AO DIPLOMA DA UNIVERSIDADE DO MINHO (MESTRADO EM ENGENHARIA URBANA) (2º CICLO)

SUPLEMENTO AO DIPLOMA DA UNIVERSIDADE DO MINHO (MESTRADO EM ENGENHARIA URBANA) (2º CICLO) SUPLEMENTO AO DIPLOMA DA UNIVERSIDADE DO MINHO (MESTRADO EM ENGENHARIA URBANA) (2º CICLO) 1 Principal(ais) área(s) de estudo da qualificação: Engenharia Civil - Planeamento Urbanístico Engenharia Civil

Leia mais

Prova de Seleção Mestrado LINGUA INGLESA 15/02/2016

Prova de Seleção Mestrado LINGUA INGLESA 15/02/2016 Prova de Seleção Mestrado LINGUA INGLESA 15/02/2016 Instruções aos candidatos: (1) Preencher somente o número de inscrição em todas as folhas. (2) Usar caneta preta ou azul. 1 2 3 4 5 6 7 8 9 10 11 12

Leia mais

Educação Vocacional e Técnica nos Estados Unidos. Érica Amorim Simon Schwartzman IETS

Educação Vocacional e Técnica nos Estados Unidos. Érica Amorim Simon Schwartzman IETS Educação Vocacional e Técnica nos Estados Unidos Érica Amorim Simon Schwartzman IETS Os principais modelos Modelo europeu tradicional: diferenciação no secundário entre vertentes acadêmicas e técnico-profissionais

Leia mais

CIENCIA VIVA. A Portuguese initiative for scientific and technological culture

CIENCIA VIVA. A Portuguese initiative for scientific and technological culture CIENCIA VIVA A Portuguese initiative for scientific and technological culture OUR MISSION CIENCIA VIVA IN SCHOOLS Science Education, practical work in partnership with research institutions NATIONAL SCIENTIFIC

Leia mais

Definição de Ontologia para Identificação de Riscos de Projetos de Software. Definition of Ontology for Software Projects Risk Identification

Definição de Ontologia para Identificação de Riscos de Projetos de Software. Definition of Ontology for Software Projects Risk Identification SEMINÁRIO DE PESQUISA EM ONTOLOGIA NO BRASIL 11 E 12 de Julho Universidade Federal Fluminense Departamento de Ciência da Informação Niterói Rio de Janeiro Brasil Definição de Ontologia para Identificação

Leia mais

UNIDADE DE PESQUISA CLÍNICA Centro de Medicina Reprodutiva Dr Carlos Isaia Filho Ltda. SAMPLE SIZE DETERMINATION FOR CLINICAL RESEARCH

UNIDADE DE PESQUISA CLÍNICA Centro de Medicina Reprodutiva Dr Carlos Isaia Filho Ltda. SAMPLE SIZE DETERMINATION FOR CLINICAL RESEARCH SAMPLE SIZE DETERMINATION FOR CLINICAL RESEARCH Duolao Wang; Ameet Bakhai; Angelo Del Buono; Nicola Maffulli Muscle, Tendons and Ligaments Journal, 2013 Santiago A. Tobar L., Dsc. Why to determine the

Leia mais

Sustainability issues in the Brazilian automotive industry: electric cars and end-of-life vehicles

Sustainability issues in the Brazilian automotive industry: electric cars and end-of-life vehicles Sustainability issues in the Brazilian automotive industry: electric cars and end-of-life vehicles Adcley Souza (adcley.souza@hotmail.com) Sustainability issues in the Brazilian automotive industry: electric

Leia mais

FUNDAÇÃO INSTITUTO CAPIXABA DE PESQUISAS EM CONTABILIDADE, ECONOMIA E FINANÇAS GEORGE PINHEIRO RAMOS

FUNDAÇÃO INSTITUTO CAPIXABA DE PESQUISAS EM CONTABILIDADE, ECONOMIA E FINANÇAS GEORGE PINHEIRO RAMOS FUNDAÇÃO INSTITUTO CAPIXABA DE PESQUISAS EM CONTABILIDADE, ECONOMIA E FINANÇAS GEORGE PINHEIRO RAMOS FATORES DETERMINANTES E INFLUENCIADORES DE COMPRA DA MÚSICA GOSPEL VITÓRIA 2013 2 GEORGE PINHEIRO RAMOS

Leia mais

INTRODUÇÃO ÀS BOAS PRÁTICAS DE ENGENHARIA APLICADAS À GESTÃO DOS SISTEMAS INSTRUMENTADOS DE SEGURANÇA: UMA ABORDAGEM DE SIL

INTRODUÇÃO ÀS BOAS PRÁTICAS DE ENGENHARIA APLICADAS À GESTÃO DOS SISTEMAS INSTRUMENTADOS DE SEGURANÇA: UMA ABORDAGEM DE SIL INTRODUÇÃO ÀS BOAS PRÁTICAS DE ENGENHARIA APLICADAS À GESTÃO DOS SISTEMAS INSTRUMENTADOS DE SEGURANÇA: UMA ABORDAGEM DE SIL Ana Cristina Costa Almeida Risk and Reliability Senior Consultant DNV Energy

Leia mais

José Benedito Alves Junior

José Benedito Alves Junior 1 José Benedito Alves Junior Gerenciamento de Projetos de TI: Uma análise sobre a possibilidade de aplicação da estrutura motivacional sugerida pelo Project Management Body of Knowledge - PMBOK - em uma

Leia mais

Ficha de Unidade de Formação Departamento: DCTI Área: Sistemas de Informação Activa nos Planos Curriculares: CET em TPSI

Ficha de Unidade de Formação Departamento: DCTI Área: Sistemas de Informação Activa nos Planos Curriculares: CET em TPSI Ficha de Unidade de Formação Departamento: DCTI Área: Sistemas de Informação Activa nos Planos Curriculares: CET em TPSI Estado: Aprovado Código: 00292 Nome (pt): Projecto de Sistemas de Informação Name

Leia mais

Revisão do Mapeamento de Processos em Levantamentos Topográficos de Áreas Patrimoniais. Antônio Diego Oliveira de Almeida Ivanildo Barbosa

Revisão do Mapeamento de Processos em Levantamentos Topográficos de Áreas Patrimoniais. Antônio Diego Oliveira de Almeida Ivanildo Barbosa Revisão do Mapeamento de Processos em Levantamentos Topográficos de Áreas Patrimoniais Antônio Diego Oliveira de Almeida Ivanildo Barbosa Instituto Militar de Engenharia - IME CEP 22290-270 - Rio de Janeiro

Leia mais

01-A GRAMMAR / VERB CLASSIFICATION / VERB FORMS

01-A GRAMMAR / VERB CLASSIFICATION / VERB FORMS 01-A GRAMMAR / VERB CLASSIFICATION / VERB FORMS OBS1: Adaptação didática (TRADUÇÃO PARA PORTUGUÊS) realizada pelo Prof. Dr. Alexandre Rosa dos Santos. OBS2: Textos extraídos do site: http://www.englishclub.com

Leia mais

desenvolvimento de software em indústria, comunidades acadêmicas e científicas uma fábrica de software?... joa@ufrpe.br silvio@cesar.org.

desenvolvimento de software em indústria, comunidades acadêmicas e científicas uma fábrica de software?... joa@ufrpe.br silvio@cesar.org. desenvolvimento de software em indústria, comunidades acadêmicas e científicas uma fábrica de software?... joa@ufrpe.br silvio@cesar.org.br laboratórios de desenvolvimento... Produção de Software: histórico

Leia mais

USO DOS CONCEITOS DE INTERAÇÃO HUMANO-COMPUTADOR NO DESENVOLVIMENTO WEB PARA EDUCAÇÃO A DISTÂNCIA

USO DOS CONCEITOS DE INTERAÇÃO HUMANO-COMPUTADOR NO DESENVOLVIMENTO WEB PARA EDUCAÇÃO A DISTÂNCIA Discutindo a visibilidade da EaD Pública no Brasil USO DOS CONCEITOS DE INTERAÇÃO HUMANO-COMPUTADOR NO DESENVOLVIMENTO WEB PARA EDUCAÇÃO A DISTÂNCIA Priscilla Márcia Scarpelli Bastos 1, Diogo Marcos de

Leia mais

Estereoscopia Digital no Ensino da Química AGRADECIMENTOS

Estereoscopia Digital no Ensino da Química AGRADECIMENTOS AGRADECIMENTOS O findar desta dissertação é o momento indicado para agradecer ao Professor Doutor João Carlos de Matos Paiva pela sua grande ajuda, pela disponibilidade sempre manifestada, pelo seu empenho

Leia mais