25 a 27 SMES. agosto Simpósio Mineiro de Engenharia de Software. PUC Minas Instituto de Ciências Exatas e Informática

Transcrição

1 SMES Simpósio Mineiro de Engenharia de Software 25 a 27 agosto 2014 PUC Minas no Coração Eucarístico PUC Minas Instituto de Ciências Exatas e Informática

2 SMES 2014 FICHA CATALOGRÁFICA Elaborada pela Biblioteca da Pontifícia Universidade Católica de Minas Gerais Simpósio Mineiro de Engenharia de Software (1.: : Belo Horizonte, MG) S612aAnais.../ Coordenação Maria Augusta Vieira Nelson, Marcelo Werneck Barbosa, Lucila Ishitani. Belo Horizonte: PUC Minas, p.: il. ISSN: Engenharia de software. 2.Software -Desenvolvimento. 3. Software - Manutenção. 4.Programação (Computadores). 5. Administração de projetos.i. Nelson,Maria Augusta Vieira et al. II. Título. CDU:

3 SMES 2014 SMES 2014 I Simpósio Mineiro de Engenharia de Software 25 a 27 de agosto de 2014 Belo Horizonte-MG, Brasil ANAIS VOLUME 1 ISSN COORDENADOR DO COMITÊ CIENTÍFICO DE PROGRAMA Rodrigo Baroni de Carvalho (PUC Minas) COORDENAÇÃO DO SMES 2014 Maria Augusta Vieira Nelson (PUC Minas) Marcelo Werneck Barbosa (PUC Minas) Lucila Ishitani (PUC Minas) REALIZAÇÃO Instituto de Informática e Ciências Exatas (ICEI) Pontifícia Universidade Católica de Minas Gerais (PUC Minas) APOIO Sociedade Brasileira de Computação (SBC) PATROCÍNIO Arkhi, ASR Consultoria, AvantiNegócios e Tecnologia, AvenueCode, Base2, Google, IBM, Microsoft Innovation Center PUC Minas, PrimeUp, Totum Consultoria, WGC Sistema, Novatec Editora. 3

4 SMES 2014 Autoriza-se a reprodução parcial ou total desta obra, para fins acadêmicos, desde que citada a fonte 4

5 SMES 2014 APRESENTAÇÃO Desejamos boas-vindas aos participantes do Simpósio Mineiro de Engenharia de Software 2014! Os Anais de um evento têm um duplo papel ao longo do tempo. Durante o evento, orientam os participantes sobre a programação, os temas e os conteúdos dos trabalhos a serem apresentados. Após o evento, os Anais são registros indeléveis das reflexões acerca de um tema em um determinado contexto histórico. É curiosa a experiência de um(a) pesquisador(a) ao rever os anais de eventos de 5, 10 anos atrás que povoam as suas estantes. Muitos dos temas atuais estavam lá, incipientes em alguns trabalhos. Muito do que é realidade nas empresas já estava apontado pelo farol da academia. Algumas tecnologias emergentes hoje já são padrão de mercado. Soluções já foram encontradas para muitos problemas, outros problemas novos de pesquisa apareceram e outros antigos ainda continuam a nos desafiar. Rever os Anais de um evento é quase como rever um álbum de família, pois nos remete às questões da época e nos traz lembranças de momentos e de pessoas. Por mais digitais que possamos ser em nossas interações, todo evento deve ser marcado pela experiência do encontro, do café com prosa junto aos pares, da oportunidade de rever os velhos conhecidos e também de conhecer novas pessoas e construir pontes e parcerias. Voltando para o tempo presente, com o tema Os Desafios de Sempre nas Fronteiras do Amanhã, o SMES 2014 visa a congregar pesquisadores, estudantes e profissionais de Minas Gerais e do Brasil para apresentarem e discutirem temas relacionados à área de Engenharia de Software. O intuito do evento é suscitar questões e buscar respostas para os desafios associados à crescente complexidade do desenvolvimento de software. As novas fronteiras derivadas da construção de aplicações móveis, da computação em nuvem, dos sistemas embarcados, dos jogos digitais, do software educacional, dos sistemas ubíquos entre outras plataformas bem como a maior exigência de flexibilidade e agilidade na adaptação dos sistemas às necessidades do mundo empresarial demandam perspectivas ampliadas para abordar os desafios tradicionais da Engenharia de Software como engenharia de requisitos, gestão de times geograficamente dispersos, usabilidade, testes, construção e manutenção de software. O SMES é um evento apoiado pela SBC (Sociedade Brasileira de Computação) por meio da Secretaria Regional de Minas Gerais e organizado pelo Instituto de Ciências Exatas e Informática (ICEI) da Pontifícia Universidade Católica de Minas Gerais (PUC Minas). O evento se realiza em Belo Horizonte (MG) entre 25 e 27 de agosto de 2014 e tem como objetivos promover a área de Engenharia de Software à sociedade e incentivar a criação de grupos de interesse, com a participação de profissionais da academia e da indústria envolvidos com essa linha de formação e pesquisa. 5

6 SMES 2014 Ao longo dos três dias, o evento está organizado em 3 formatos distintos: - Manhãs com Sessões Técnicas de apresentação de trabalhos científicos; - Tardes com Minicursos sobre temas emergentes correlatos à Engenharia de Software; - Noites com programação de Palestras e Painel com especialistas. Gostaríamos de agradecer a todas as pessoas que, cada uma a seu modo, promoveram uma soma de talentos que viabilizaram a realização desse evento. Parafraseando Raul Seixas, o sonho que se sonha junto se torna realidade. Façam bom uso dos Anais do evento: hoje e sempre. Guarde-o em um local seguro, pois pode ser útil bem antes do que se imagina. Desejamos a todos um ótimo evento! Rodrigo Baroni de Carvalho, PUC Minas Coordenador do Comitê Científico de Programa 6

7 SMES 2014 Comitês Técnicos SMES COORDENAÇÃO GERAL Maria Augusta Vieira Nelson, PUC Minas Marcelo Werneck Barbosa, PUC Minas Lucila Ishitani, PUC Minas SMES COMITÊ DE ORGANIZAÇÃO Eveline Alonso Veloso, PUC Minas Glívia Angélica Rodrigues Barbosa, CEFET MG Juliana Amaral Baroni de Carvalho, PUC Minas Marcelo Souza Nery, PUC Minas Rodrigo Richard Gomes, PUC Minas Rosilane Ribeiro da Mota, PUC Minas Tadeu dos Reis Faria, PUC Minas Theldo Cruz Franqueira, PUC Minas SMES COORDENAÇÃO DO COMITÊ CIENTÍFICO DE PROGRAMA Rodrigo Baroni de Carvalho, PUC Minas SMES COMITÊ CIENTÍFICO DE PROGRAMA Ana Liddy Magalhães, UFMG, FUMEC, QualityFocus Carlos Alberto Marques Pietrobon, PUC Minas/UFOP Cristiane Neri Nobre, PUC Minas Daniela Cascini Kupsch, CEFET-MG Eduardo Figueiredo, UFMG Elder José Cirilo, UFSJ Fernando Silva Parreiras, FUMEC Heitor Costa, UFLA Kécia Ferreira, CEFET-MG Laércio Baldochi, UNIFEI Lucila Ishitani, PUC Minas Manoel Palhares Moreira, PUC Minas Marcelo de Almeida Maia, UFU Marco Antônio Pereira Araujo, IF Sudeste MG Marco Tulio Valente, UFMG Mark Alan Junho Song, PUC Minas Pasteur Ottoni de Miranda Junior, PUC Minas Pedro Alves de Oliveira, PUC Minas Raquel Prates, UFMG Regina Braga, UFJF Ricardo Terra, UFLA 7

8 SMES 2014 Palestras Convidadas Modularidade Continuada: O Caminho para Engenheiros de Software? Alessandro Garcia (PUC-Rio) De forma análoga a outras disciplinas, modularidade é o atributo central para engenharia de software manutenível e confiável. A história da indústria de software tem nos ensinado que não é possível negligenciar este atributo crucial no dia-a-dia do desenvolvimento de software. Várias técnicas têm sido propostas nas últimas décadas para provisão de modularidade, seja de forma prospectiva ou retrospectiva. Ou seja, tais técnicas apoiam desenvolvedores a: (i) predizerem o impacto de decisões de modularidade, ou (ii) analisarem o impacto destas decisões importantes uma vez que já foram tomadas. Porém, pouco se tem estudado sobre técnicas para promover modularidade "continuada": isto é, técnicas que efetivamente apoiam desenvolvedores a raciocinarem sobre modularidade de forma iterativa, na medida em que tomam suas decisões de projeto e implementação. Nesta palestra, iremos revisitar os avanços e estudos recentes sobre técnicas prospectivas e retrospectivas para modularidade de software, propostas nos últimos 15 anos. Vários destes estudos indicam a necessidade de suporte à modularidade continuada. Esta necessidade é reforçada em tempos onde o ferramental para engenharia de software - tais como suporte à integração contínua - tem amadurecido e sido aceito pela indústria de software. Alessandro Garcia possui doutorado em Informática pela Pontifícia Universidade Católica do Rio de Janeiro (2004), mestrado em Ciência da Computação pela Universidade Estadual de Campinas (2000) e graduação em Ciência da Computação pela Universidade Estadual de Maringá (1998). Atuou como Professor Assistente da Universidade de Lancaster (Inglaterra) de Fevereiro 2005 a Janeiro Atualmente é Professor Adjunto do Departamento de Informática da Pontifícia Universidade Católica do Rio de Janeiro. Tem experiência na área de Ciência da Computação, com ênfase em Engenharia de Software, atuando principalmente nos seguintes temas: modularidade, tratamento de exceções, linhas de produtos, métricas, arquitetura de software e desenvolvimento de software dirigido por modelos. Ele tem sido convidado frequentemente para os Comitês de Programa e/ou Comitês de Organização das principais conferências internacionais de Engenharia de Software e áreas afins, tais como ICSE, FSE, AOSD/Modularity, MODELS, ICPC, ESEM, SPLC, AAMAS, e várias outras. Ele também publica com frequência nestas conferências. É Bolsista Produtividade do CNPq (nível 1D) e Membro Afiliado da Academia Brasileira de Ciências (ABC). Ele recebeu vários prêmios, distinções e reconhecimentos, tais como Melhor Dissertação de Mestrado de 2000 (Sociedade Brasileira de Computação), Melhor Pesquisador do Ano (Lancaster University, 2006), Jovem Cientista do Nosso Estado (FAPERJ, 2009 e 2013) e Distinção em Produtividade (PUC-Rio, 2009 e 2012). Ele lidera o grupo de pesquisa Opus, do Laboratório de Engenharia de Software da PUC-Rio, possuindo várias parcerias com outros grupos de pesquisa internacionais nos EUA, Alemanha e Espanha. Atualmente, seus projetos de pesquisa são financiados por agências de fomento -- CNPq, CAPES e FAPERJ -- e por parceiros da Indústria de Software, tais como Petrobras e Minds@Work. 8

9 SMES 2014 A Alta Maturidade no Processo de Desenvolvimento de Software Ana Cecília Peixoto Zabeu (ASR Consultoria) Nesta palestra será discutido o conceito da Alta Maturidade, sua aplicação no Processo de Desenvolvimento de Software, relacionando os objetivos esperados e como implantar a alta maturidade em uma empresa. Na apresentação de um case, serão discutidos os problemas enfrentados e as soluções adotadas, finalizando com uma visão do status atual da Alta Maturidade no Brasil. Ana Cecília Peixoto Zabeu é Sócia Diretora da ASR Consultoria e Assessoria em Qualidade Ltda. Implementadora e Avaliadora Líder do MPS.BR. Coordenadora da I.I. e I.A. para o MPS.BR da ASR Consultoria, Instrutora dos cursos C1 e C2 oficiais MPS.BR (SW e SV). Integrante da Equipe Técnica do Modelo (ETM) MPS.BR. Membro da Coordenação da ETM SV e Vice-Coordenadora da ETM de Implementação do MPS.Br. Formada em Engenharia Elétrica pela PUC Minas e Pós-graduada em Eletromagnetismo Aplicado pela PUC-RJ. Participou em avaliações CMM/CMMI nos métodos CBA/SCE e SCAMPI pelo Software Engineering Institute. Possui experiência em desenvolvimento de software e hardware integrados, gerência da qualidade e gerência de configuração, implementação de modelos de qualidade (SGQ - ISO 9000; MPS.BR, CMMI), metodologias ágeis e integração com RUP, PMBoK, entre outros. Cofundadora do SPIN-Sorocaba e Coordenadora do SPIN Campinas. 9

10 SMES 2014 Índice de Artigos Completos A Conceptual Model for Agile Practices Adoption 14 Amadeu Campanelli (Universidade FUMEC) Fernando Silva Parreiras (Universidade FUMEC) Aplicação de BDD e Ferramentas de Automação de Testes em um Processo de Desenvolvimento Ágil 24 Daniela Almeida (IGTI - Instituto de Gestão em Tecnologia da Informação) Priscila Souza (UFMG) Um Diagnóstico sobre a Gerência de Contratos em Projetos Ágeis de Belo Horizonte 33 Camila Andrade (PUC Minas) Jéssica Lopes (PUC Minas) Marcelo Barbosa (PUC Minas) Melissa Costa (Ministério Público do Estado de Minas Gerais) Avaliando Acoplamento em Atividades de Manutenção 43 Bruno Rodrigues (Universidade FUMEC) Daniel Souza (Universidade Federal de Minas Gerais) Eduardo Figueiredo (Universidade Federalde Minas Gerais) Uma Avaliação da Usabilidade de Controladores Java no Desenvolvimento de Aplicações para Redes Open Flow 53 Thiago N. Rodrigues (FAESA, Espírito Santo) Rafael P. Guimarães (FAESA, Espírito Santo) Uma Revisão Sistemática para Obtenção de Ferramentas de Identificação de Maus Cheiros em Código Fonte 62 Allan Brandl (Faculdade Metodista Granbery, Juiz de Fora) Evandro Pedro (Faculdade Metodista Granbery, Juiz de Fora) Ramon Silva (Faculdade Metodista Granbery, Juiz de Fora) Marco Antônio Pereira Araujo (IF Sudeste MG) GraphVCS: Uma Abordagem de Visualização para Apoio à Compreensão de Repositórios de Controle de Versão 72 Thiago Amorim Pereira (UERJ) Marcelo Schots (COPPE/UFRJ) 10

11 SMES 2014 Índice de Artigos de Seminários de Pesquisa em Engenharia de Software Uma Ferramenta para Priorização de Requisitos Baseada no Algoritmo do PageRank 82 Silvester Silva (PUC Minas) Marcelo Barbosa (PUC Minas) Análise de Dependência em Software Java Considerando Relacionamento com Banco de Dados 92 Jaqueline Moreira (CEFET-MG) Kécia Ferreira (CEFET-MG) Seleção e Aplicação de um Processo de Elicitação de Requisitos Baseadas na Análise de uma Revisão Sistemática da Literatura 101 Lucas Abreu (PUC Minas) Glívia Barbosa (PUC Minas) Uma Avaliação de Ferramentas de Modelagem de Software 109 Johnatan Oliveira (Universidade Federal de Minas Gerais) Priscila Souza (Universidade Federal de Minas Gerais) Eduardo Figueiredo (Universidade Federal de Minas Gerais ) Sistemas de Software Educacionais em Gerência de Projetos de Software - Uma Proposta de Avaliação utilizando Questionário 119 Ana Rosa Oliveira (Universidade Federal de Lavras) Heitor Costa (Universidade Federal de Lavras) Uma Revisão Sistemática sobre Práticas de Comunicação na Gerência de Projetos de Software - Estudos Primários 129 Vinícius Maretti (Universidade Federal de Lavras), Heitor Costa (Universidade Federal de Lavras) 11

12 SMES 2014 Engenharia de Software Baseada em Buscas: Uma Visão de Gestão de Projetos 139 Lucas Contreiro (Centro Federal de Educação Tecnológica de Minas Gerais) Daniela Kupsch (Centro Federal de Educação Tecnológica de Minas Gerais) Gerência de Projetos no Desenvolvimento Distribuído de Software - Desafios e Soluções 147 Wallace Moreno (Universidade Federal de Lavras), Heitor Costa (Universidade Federal de Lavras) Catálogo de Riscos em Gerência de Projetos de Software - Um Estudo Exploratório 157 Valeska Machado (Universidade Federal de Lavras) Heitor Costa (Universidade Federal de Lavras) Análise Comparativa de Tecnologias de Programação no Contexto de Linhas de Produtos de Software 167 José Natanael Reis (Universidade Federal de Lavras) Gustavo Vale (Universidade Federal de Minas Gerais) Heitor Costa (Universidade Federal de Lavras) Um Software Educacional para Manutenção de Software 177 Matheus Carvalho (Universidade Federal de Lavras) Heitor Costa (Universidade Federal de Lavras) Análise das Estratégias de Gamificação em Aplicativos Móveis Educacionais: Um Estudo de Caso do Aplicativo Duolingo 187 Júlio Silva (PUC Minas) Glívia Barbosa (PUC Minas) Apreciação da Usabilidade do Moodle para Complemento ao Ensino no Contexto do Nível Fundamental 197 Jéssica Penna (PUC Minas) Glívia Barbosa (PUC Minas) 12

13 SMES 2014 Análise Comparativa de Técnicas de Extração de Linhas de Produtos de Software 207 Patrícia Dias (Universidade Federal de Lavras) Gustavo Vale (Universidade Federal de Minas Gerais) Heitor Costa (Universidade Federal de Lavras) Implantação da Gerência de Configuração de Software em uma Empresa Privada de Desenvolvimento de Software 217 Déborah Helen S. Pinto (PUC Minas) Maria Augusta Vieira Nelson (PUC Minas) Um Processo para Melhoria de Processos para uma Empresa de Pequeno Porte - Um Estudo Introdutório 226 Vinícius Pereira (Universidade Federal de Lavras) Heitor Costa (Universidade Federal de Lavras) Confiabilidade das Estimativas de Tempo e Custo na Atividade de Teste, em Projetos de Software: Estudo de Caso na Empresa ETEG Tecnologia da Informação 236 Raphaella Priscilla Rodrigues da Silva (PUC Minas) Pedro Oliveira (PUC Minas) Apreciação da Usabilidade de Ferramentas para Gestão de Defeitos de Softwares: Um Estudo de Caso da Ferramenta Bugzilla 246 Lara Souza (PUC Minas) Magnum Dutra (PUC Minas) Glívia Barbosa (PUC Minas) 13

14 A Conceptual Model for Agile Practices Adoption Amadeu Silveira Campanelli, Fernando Silva Parreiras 1 LAIS Laboratory of Advanced Information Systems, FUMEC University Av. Afonso Pena Belo Horizonte MG Brazil Master s Thesis - Work in Progress Abstract. The software development industry has been adopting agile methods and practices instead of traditional software development methods because they are more flexible and can bring benefits such as handling requirements changes, productivity gains, frequent releases and business strategy focus. This work proposes a model for agile process data representation to show the relationships between agile components (principles, methods, practices, techniques, roles and work products) to allow organizations to define the strategy of agile practices adoption to achieve their business goals. Through competency questions the model has been validated using Scrum method data as the initial dataset. Future work includes the addition of more agile methods to the model repository and the validation of organization tailored methods using the model. Keywords: agile practices, agile adoption, practices selection, agile adoption model 1. Introduction Agile methods for software development have been increasingly used by the software industry based on a set of advantages such as accelerate time to market, quality and productivity increase, IT/business alignment improvement, welcoming changes and managing priorities reorganization compared to traditional software development methods [Nishijima and Dos Santos 2013, Qumer and Henderson-Sellers 2006b, Jyothi and Rao 2011, VersionOne 2013]. Even though the benefits of agile methods are worth and have been proved by scientific and market researches [Jyothi and Rao 2011, Moniruzzaman and Hossain 2013, Ahmed and Sidky 2009, VersionOne 2013] the complexity of adopting them is high because of organization culture, resistance to changes and need for upper management sponsorship and involvement [Sidky et al. 2007, VersionOne 2013]. Based on the current challenges of software development, agile approaches are interesting options to achieve quality, project budget control, align with organization s business strategy and deliver value frequently and continuously [Saleh 2013, VersionOne 2013, Nishijima and Dos Santos 2013]. The choice of the adoption strategy of agile approaches is a key component to success in order to get the organization to take advantage of the benefits brought by agility [Sidky et al. 2007, Soundararajan et al. 2012] and to overcome the common issues found on the adoption process and achieve the organization s business goals [Qumer and Henderson-Sellers 2008]. Research on agile adoption adoption normally try to tailor the agile method selecting practices to achieve the organization needs, since full agile method adoption can be an overkill for organizations or require lots of resources [Qumer and Henderson-Sellers 2008]. Some research analyze which agile practices were the most adopted ones based the literature and on industry surveys [Kurapati et al. 2012, Jalali and Wohlin 2010, 14

15 Abbas et al. 2010, Manyam and Kurapati 2012], others take into account which maturity level the organization wants to adopt to select the appropriate agile practices [Ahmed and Sidky 2009, Qumer and Henderson-Sellers 2008], some select agile practices to adopt based on project characteristics [Saleh 2013] and there are also research on practices selection based on strategy graphs representing the relationships between strategies at multiple organization levels [Esfahani et al. 2011]. This paper proposes a model to store information about agile principles, methods, practices and correlated information to allow organizations to understand their current practices versus agile practices and define the strategy of agile practices adoption to achieve the organization s goals. The remainder of this paper is structured as follows. Section 2 presents a literature review on agility, agile methods and related work regarding agile practices adoption strategies. On Section 3 the model is defined and on Section 4 the model is validated and discussed. Section 5 summarizes the findings, states limitations and opportunities for future work. 2. Related Work 2.1. Agile Manifesto The Agile Manifesto [Beck et al. 2001] has consolidated values and principles from existing agile methods and approaches and made the agile movement stronger and organized on the software development industry. Agile values are: individuals and interactions, working software, customer collaboration and responding to change. Agile principles are: Early and continuous delivery of valuable software; Change is welcome; Deliver frequently; People interaction (business and developers); Motivated people; Face-to-face communication; Working software is progress; Constant pace; Technical excellence and good design; Simplicity; Self-organized teams; Continuous improvement. Agile methods are in their essence based on values and principles defined on the Agile Manifesto [Beck et al. 2001] and composed by agile practices [Jalali and Wohlin 2010]. Agile practices should help accomplish the agile principles on a method and can be grouped into management practices, software process practices and software development practices [Lee and Yong 2013]. Example of agile practices are: pair programming, daily stand-up meetings, unit testing and open work area. The current mainstream agile methods are: extreme Programing (XP), Scrum [Schwaber and Sutherland 2011], Kanban, Lean e Feature-Driven Development (FDD). Scrum is currently the most adopted one [VersionOne 2013]. Each method focus on specific values and there is no standard on how a method should implement its agility. 15

16 Handling unstable requirements, delivering working software in short time frames, with high quality and under budget are the main characteristics of agile methods compared to traditional ones [Jyothi and Rao 2011]. Being agile is to be able to rapidly adapt to change in a flexible way [Qumer and Henderson-Sellers 2006b]. The capability is reflected by the attributes of flexibility, velocity, leanness, learning and response to change. According to [Qumer and Henderson-Sellers 2006b] agility can be defined as the ability to accommodate changes (expected or not) quickly in a dynamic environment being simple, economic and having quality in a short iteration strategy applying previous knowledge and generating new ones on this experience. Handling unstable requirements, delivering working software in short time frames, with high quality and under budget are the main characteristics of agile methods compared to traditional ones [Jyothi and Rao 2011] Agile Practices Adoption The problem of selecting agile practices to be adopted by organizations is a known problem and researchers have been working on it but there is still no definitive answer for the theme [Kurapati et al. 2012, Madi et al. 2011, Abbas et al. 2010, Esfahani et al. 2011, Ahmed and Sidky 2009]. Not all organizations are ready to implement agile in a full manner regarding to both on cultural and technical aspects [Qumer and Henderson-Sellers 2008]. Besides these changes demand a considerable financial investment and also have a big impact on the daily tasks performed by the teams. The agile adoption could be partial and also keep other practices the organization currently adopts in place and combined with the new set of practices to make the organization more successful. Agile methods are not always used completely in an organization because of specific needs and constraints. The agile practices selection allow organizations to best achieve their goals [Kurapati et al. 2012]. There is no final academic solution on how the practices selection should happen. Organizations can adopt agile in multiple ways, depending on their business goals, culture and resources [Abbas et al. 2010]. The agile practices adoption can also be unique per organization taking into account the areas of the development process the organization wants to improve. Normally organizations need help choosing the right combination of practices for their environment. The association/correspondence between agile values and the organization culture defines which set of practices could be followed by this organization [Madi et al. 2011]. A systematic review of the research literature on use of agile in global software engineering presented a list of agile practices used or referenced by the analyzed papers [Jalali and Wohlin 2010]. A survey on agile practices adoption proposed to understand which practices have been used by the software development industry [Kurapati et al. 2012]. This survey analysed practices adoption at the project and organization levels and also defined the association between practices. A work focused on the quality aspects of the agile practices showed the main agile practices associated with high quality of the software product [de Azevedo Santos et al. 2011]. Factor analysis was applied to group 58 agile practices and found 15 factors and checked the correlation between them finding application of quality assurance and iterative and incremental practices had a high success rate [Abbas et al. 2010]. 16

17 SAAP (Strategic Analysis for Agile Practices) framework [Esfahani et al. 2011] was proposed with the intent to associate business goals to the selection process for agile practices adoption. SAAP extended Situation Method Engineering and used concepts from Balanced Scorecard (BSC). This work linked the selection of agile practices to the organization s business goals. Sidky Agile Measurement Index (SAMI) [Ahmed and Sidky 2009] showed the adoption of agile practices based on an agile maturity model. SAMI is a 5-step road map to guide teams adopting based in 5 values considered essential to agility: enhancing communication and collaboration, delivering software early and continuously, developing high quality, working software in an efficient and integrated manner, respond to change through multiple levels of feedback and establishing an environment to sustain agility. SAMI is not based on any specific agile method such as XP, Scrum or Crystal, but instead, uses agile values and principles to define the path to agility. The analysis of papers and books from Agile Manifesto signatories using content analysis [Madi et al. 2011] identified the key agile values and how frequent they were mentioned on the literature. The agile key values obtained by this work were: Flexibility, Customer-centric, Working Software, Collaboration, Simplicity, Communication, Natural, Learning, Pragmatism and Adaptability. A methodology to select the best agile practices for projects based on the association between project s characteristics and the abilities of the agile practices has been defined [Saleh 2013] and the key project s areas analyzed in the work were team size, iteration duration and distributed teams. An empirical study identified common adopted practices, listed practices that normally are used together and correlated the customer satisfaction after adopting the practices [Manyam and Kurapati 2012]. This work also tried to identify adaptation by organizations on the adopted practices. 3. Conceptual Model Proposal Even though the benefits obtained of agile adoption have been proved by scientific and market researches [Jyothi and Rao 2011, Moniruzzaman and Hossain 2013, Ahmed and Sidky 2009, VersionOne 2013], the adoption process complexity cannot be forgotten since it requires lots of effort from the organization and teams, cultural adaptation, deals with egos and resistance to changes and demands upper management sponsorship [Abbas et al. 2010, VersionOne 2013]. Besides that, there are cases in which some of the practices available on the mainstream agile methods do not make sense for an organization. The value an agile practice (such as continuous integration or refactoring) aggregates to the organization development process also varies. Then adopting all the practices proposed by an agile method at once means that the organization needs to spend effort and resources adopting it and the value brought by this adoption varies and however there is no guarantee the investment made is maximized. These types of challenges motivated academic researches on agile practices adoption and practices selection in order to generate a custom/tailored software development process more consistent with the organization s values, culture, reality and strategies [Abbas et al. 2010]. This way the organization will only spend effort adopting the practices that aggregate value to the development process and help to achieve their business goals. 17

18 The agile practices adoption strategy seems to make the adoption process simpler and brings the benefits of being agile achievable by the organization earlier in the process [Sidky et al. 2007, Qumer and Henderson-Sellers 2008]. It can generate confidence on the teams and bring organizational support for further adoption and more process improvement initiatives Competency Questions In this context an organization needs to answer questions to help it to understand how agile methods or practices can be adopted, what is the strategy that better fits the organization s needs, which agile practices to adopt and how do the organization s currently practices fit on an agile structure (agile principles, methods and practices). Follow 4 questions an organization might ask when evaluating the adoption of agile practices. These questions are going to be used to validate the proposed model. Q1: Which are the agile practices an organization needs to adopt if their business goals focus on agile principle X? Q2: Which are the agile principles followed by an organization adopting method Y? Q3: Which are the agile principles followed by an organization using a set of agile practices Z? Q4: Which are the correlated agile practices that can be adopted by an organization currently using a set of agile practices W? 3.2. The Model The proposed conceptual model for agile process data representation for this work can be seen on Figure 1. The main goal of the model is to help organizations to understand and make decisions regarding agile practices adoption or selection and/or how evolve their current software development processes using agile practices. The idea represented by the model is the relationship between agile components (principles, methods, practices, techniques, roles and work products) in a way the existing agile methods or organization tailored software development processes can be mapped using it and analyzed based on the organization business goals point of view. Model components: Agile Principle: The agile principles have been the structure behind the Agile Manifesto [Beck et al. 2001], define what is to be agile and guide agile methods. The Agile Manifesto is based on 12 principles listed on Section 2. Agile principles should be used on the model to map set of practices to business goals the organizations want to achieve. Method: Agile methods are different ways to apply the agile philosophy and can share characteristics. Each method has own terminology, set of practices (some of them can be found on other methods), tactics, roles and coverage of the software development life cycle. Example of agile methods are: Scrum and XP. This entity should only represent the mainstream agile methods available on the literature and the model will use agile methods to provide a basis for comparison to the current software development processes on the organizations. 18

19 Figure 1. Entity-Relationship of proposed model to represent agile principles, methods, practices and related components. Practice: An agile practice is an activity used to help implement agile principles or values. Examples of practices are: daily standup, collective ownership, short releases and small teams. The relationship between agile principles and practices should allow organizations to choose which practices should be adopted based on the organizations business goals and how the practices correlate with each other to fulfill the defined goals. Role: The role is the person or group of people defined to execute or participate on a practice. For Scrum the roles are: product owner, scrum master and development team. Roles are associated with agile methods and practices and can provide guidance on how the organization should build teams for agile practices adoption. Technique: Technique is a way to execute a task for an agile practice. Different techniques can be applied to execute the same task and it can be defined by the agile method. Examples of techniques for the backlog prioritization agile practice are: Kano Analysis, Theme Screening and Relative Weighting. The technique of choice for an agile practice will depend on which will make more sense for the organization s culture, how the organization s software development process is structured and the learning curve of the technique versus existing knowledge on the organization. Work Product: Work product is an artifact generated by a technique in an agile practice or method. Examples of work products for Scrum are: Product Backlog, Sprint Backlog and Sprint Burndown Chart. Work products should provide guidance on which artifacts need to be created during the selected practices adoption. The model repository was implemented in a SQL database representing the model classes and their relationships. The repository is able to respond to queries based on the 19

20 data stored on the tables and the data collection to feed the model is going to be based of the review of literature on agile methods and practices and also reference web sites on the mainstream agile methods. 4. Discussion The model implementation at this stage of the research is a proof of concept and only Scrum data have been added to the model repository so far. The data has been loaded based on the Agile Manifesto [Beck et al. 2001] and on the literature on Scrum [Schwaber and Sutherland 2011, Deemer et al. 2010, Cohn 2009, Qumer and Henderson-Sellers 2006a] and adapted in order to be generalized and possible to be compared to other agile methods in the future. A sample of the data loaded into the repository can be seen on Figure 2. Figure 2. Agile principles and practices stored on the model repository for the proof of concept. In order to validate the proposed model the competency questions defined on Section 3.1 against the proof of concept repository. Follow a demonstration of the queries to retrieve information from the model repository and the results according to the proof of concept dataset. The proof of concept was implemented as a Windows console application to output the answers for the competency questions. The queries for the questions are represented on Table 1 and all the results are listed on Table 2. The agile principle considered for question Q1 was continuous improvement and the Scrum practices retrieved from the model repository were Daily StandUp, Iteration Review and Retrospective to follow the continuous improvement principle. In order to answer question Q2 Scrum was considered the adopted agile method and the result listed all practices used by Scrum. Question Q3 result showed that the practices daily standup, feature list, short releases are involved in 7 out of 12 agile principles. These practices can be a good initial choice for organizations seeking to be agile and wanting to start to understand how the agile principles work. The result for question Q4 showed practices are the ones involved on the same agile principles as small teams and daily standup. The practices listed should the the first choice for adoption if an organization currently adopts small teams and daily standup practices. 20

21 Question Q1: Which are the agile practices an organization needs to adopt if their business goals focus on agile principle Continuous Improvement? Q2: Which are the agile principles followed by an organization adopting method Scrum? Q3: Which are the agile principles followed by an organization using a set of agile practices: daily standup, feature list and short releases? Q4: Which are the correlated agile practices that can be adopted by an organization currently using a set of agile practices: iteration planning and small teams? Query SELECT P.Name FROM Practice AS P INNER JOIN PrinciplePractice AS PP on P.ID = PP.PracticeID INNER JOIN Principle AS Pr ON Pr.id = P.PrincipleID WHERE Pr.Name = Continuous improvement SELECT P.Name FROM Practice AS P INNER JOIN MethodPractice AS MP on P.ID = MP.PracticeID INNER JOIN Method AS M ON M.id = MP.MethodID WHERE M.Name = Scrum ORDER BY P.Name SELECT Pr.Name FROM Principle AS Pr INNER JOIN PrinciplePractice AS PP on Pr.ID = PP.PrincipleID IN- NER JOIN Practice AS P ON P.id = PP.PracticeID WHERE P.Name IN ( daily standup, feature list, short releases ) ORDER BY Pr.Name SELECT DISTINCT P.Name FROM Practice AS P INNER JOIN PrinciplePractice AS PP ON P.id = PP.PracticeID WHERE PP.PrincipleID IN ( SELECT Pr.ID FROM Principle AS Pr INNER JOIN PrinciplePractice AS PP ON Pr.ID = PP.PrincipleID INNER JOIN Practice AS P ON P.id = PP.PracticeID WHERE P.Name IN ( small teams, daily standup ) ) AND P.Name NOT IN ( small teams, daily standup ) ORDER BY P.Name Table 1. Queries for all the questions The answers for the competency questions demonstrated that the model can support organization to understand how agile components correlate to each other and how agile practices can be mapped to organizations existing practices and business goals. More than that, it showed the proposed model establishes relationships between important components of agile methods and practices that can be used to guide organizations on the decision of which agile practices to adopt considering their business goals and their current software development process or current agile practices already adopted. 5. Conclusion This paper proposed a model to store information about agile principles, methods, practices and correlated information to allow organizations to understand their current practices versus agile practices and define the strategy of agile practices adoption to achieve the organization s goals. The model was validated based on the competency questions defined providing answers to questions organizations ask or need to respond in order to decide how they should adopt agile practices and how their current method is compliant with agile principles and methods. This research is still in progress and there are several limitations including the interface to retrieve the data from the repository, the availability of only Scrum data on the model repository and the lack of real organization data to be validated against the model. Future work based on this paper can include the addition of more agile methods to be model, the model validation with organizations intending to adopt agile methods or practices and the model usage to check how organizations business goals map to agile 21

22 Question Q1 Q2 Q3 Q4 Answer Daily Standup, Iteration Review and Retrospective Daily Standup, Features List, Iteration Planning, Iteration Review, Retrospective, Short Releases and Small Teams Change is welcome, Continuous improvement, Deliver frequently, Early and continuous delivery of valuable software, Face-to-face communication, People interaction (business and developers) and Working software is progress Iteration Planning, Iteration Review, Retrospective Table 2. Answers for all the questions principles and practices. References Abbas, N., Gravell, A. M., and Wills, G. B. (2010). Using factor analysis to generate clusters of agile practices (a guide for agile process improvement). In Agile Conference (AGILE), 2010, pages IEEE. Ahmed, E.-M. and Sidky, A. (2009). 25 percent ahead of schedule and just at step 2 of the sami. In Agile Conference, AGILE 09., pages IEEE. Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C., Mellor, S., Schwaber, K., Sutherland, J., and Thomas, D. (2001). Manifesto for agile software development. Accessed: Cohn, M. (2009). Succeeding with agile: software development using scrum. Addison- Wesley Professional. ISBN de Azevedo Santos, M., de Souza Bermejo, P. H., de Oliveira, M. S., and Tonelli, A. O. (2011). Agile practices: An assessment of perception of value of professionals on the quality criteria in performance of projects. Journal of Software Engineering & Applications, 4(12). Deemer, P., Benefield, G., Larman, C., and Vodde, B. (2010). The scrum primer. 1/scrumprimer121.pdf. Accessed: Esfahani, H. C., Eric, S., and Annosi, M. C. (2011). Towards the strategic analysis of agile practices. In CAiSE Forum, pages Jalali, S. and Wohlin, C. (2010). Agile practices in global software engineering-a systematic map. In Global Software Engineering (ICGSE), th IEEE International Conference on, pages IEEE. Jyothi, V. E. and Rao, K. N. (2011). Effective implementation of agile practices ingenious and organized theoretical framework. IJACSA - International Journal of Advanced Computer Science and Applications, 2(3):

23 Kurapati, N., Manyam, V. S. C., and Petersen, K. (2012). Agile software development practice adoption survey. In Agile Processes in Software Engineering and Extreme Programming, pages Springer. Lee, S. and Yong, H.-S. (2013). Agile software development framework in a small project environment. Journal of Information Processing Systems, 9(1). Madi, T., Dahalin, Z., and Baharom, F. (2011). Content analysis on agile values: A perception from software practitioners. In Software Engineering (MySEC), th Malaysian Conference in, pages IEEE. Manyam, V. S. C. and Kurapati, N. (2012). Empirical investigation on adoption and adaptation of agile practices. Master s thesis, Blekinge Institute of Technology. Moniruzzaman, A. B. M. and Hossain, S. A. (2013). Comparative study on agile software development methodologies. CoRR. Nishijima, R. T. and Dos Santos, J. G. (2013). The challenge of implementing scrum agile methodology in a traditional development environment. INTERNATIONAL JOURNAL OF COMPUTERS & TECHNOLOGY, 5(2): Qumer, A. and Henderson-Sellers, B. (2006a). Comparative evaluation of xp and scrum using the 4d analytical tool (4-dat). In Proceedings of the European and Mediterranean conference on information systems, volume Qumer, A. and Henderson-Sellers, B. (2006b). Crystallization of agility back to basics. In Filipe, J., Shishkov, B., and Helfert, M., editors, ICSOFT (2), pages IN- STICC Press. Qumer, A. and Henderson-Sellers, B. (2008). A framework to support the evaluation, adoption and improvement of agile methods in practice. Journal of Systems and Software, 81(11): Saleh, M. H. (2013). Methodology for selection of agile practices. Master s thesis, American University of Sharjah. Schwaber, K. and Sutherland, J. (2011). The scrum guide. Accessed: Sidky, A., Arthur, J., and Bohner, S. (2007). A disciplined approach to adopting agile practices: the agile adoption framework. Innovations in systems and software engineering, 3(3): Soundararajan, S., Arthur, J. D., and Balci, O. (2012). A methodology for assessing agile software development methods. In Agile Conference (AGILE), 2012, pages IEEE. VersionOne (2013). 8th annual state of agile development survey. stateofagile.versionone.com. Accessed:

24 Aplicação de BDD e Ferramentas de Automação de Testes em um Processo de Desenvolvimento Ágil Daniela E. C. Almeida¹, Priscila P. Souza² Instituto de Gestão em Tecnologia da Informação (IGTI) Alameda do Ingá, nº88, 2º andar bairro Nova Lima - Belo Horizonte, MG Brasil danielaedvana@gmail.com, prof.priscilasouza@gmail.com Categoria: trabalho de conclusão de curso de especialização Estágio do trabalho: concluído Abstract - Producing software with quality without affecting aspects such as cost, time and productivity is a major concern in the area of Software Development. The tests activity can be used to help fulfill this purpose. This article describes a practical experience of implementing test automation tools together with Behavior Driven Development (BDD) methodology on a team that uses the Scrum agile development model. The results showed an improvement in the test process, such as: the defects were found soon, the repetition of a test scenario has become simpler, perform testing activities has become less arduous for testers and there was a decrease the runtime of the testing process, among other. Resumo. Produzir softwares com qualidade, sem afetar aspectos como custo e prazo é um grande desafio na área de desenvolvimento de software. A atividade de testes pode ser utilizada para ajudar a cumprir este propósito. Este artigo descreve uma experiência prática de implantação de ferramentas de automação de testes em conjunto com a metodologia Behavior Driven Development (BDD), em uma equipe de desenvolvimento ágil Scrum. Os resultados mostraram uma melhoria no processo de testes, tais como: os defeitos foram encontrados mais rapidamente, a repetição de um cenário de teste tornou-se mais simples, executar as atividades de teste passou a ser menos árdua para os testadores, houve uma diminuição no tempo de execução do processo de testes, dentre outros. 1. Introdução O advento da Internet e o aumento expressivo na utilização e construção de softwares incentivam a uma constante procura por ferramentas, técnicas e metodologias adequadas para a garantia da qualidade. Segundo Bernardo e Kon (2008), o controle da qualidade de software representa um grande desafio, pois envolve produtos de alta complexidade além de questões humanas, burocráticas, políticas e técnicas relacionadas ao processo de desenvolvimento. Dentro deste contexto uma das alternativas mais usadas e aconselhadas para garantir a 24

25 qualidade dos softwares de acordo com Myers (2004) é a realização de testes, uma vez que auxiliam a revelar a presença de defeitos. Os testes também podem ser definidos segundo o padrão IEEE como o processo capaz de analisar um item de software para detectar as diferenças entre as condições existentes e as requeridas (isto é, erros) e avaliar as características do item de software. Entretanto para Myers (2004) a realização de testes é uma atividade que exige tempo, planejamento, infraestrutura, conhecimento e uma equipe especializada. Dependendo do tipo de sistema a ser desenvolvido, segundo Pressman (2006) esta atividade pode ser responsável por mais de 50% dos custos do processo de desenvolvimento do software. Com intuito de amenizar estas questões e melhorar continuamente a qualidade dos softwares, sugere-se nesse trabalho, a implantação da metodologia Behavior Driven Development (BDD) em conjunto com a técnica de automação de testes de aceitação. Para ilustrar essa implantação, um estudo de caso foi realizado em uma organização que utiliza o processo de desenvolvimento ágil Scrum. A organização deste artigo apresenta-se da seguinte forma: a seção dois descreve o método ágil Scrum. A seção três cita alguns conceitos referentes à automação de testes e apresenta a ferramenta Selenium. Na seção quatro expõem-se os conceitos relacionados à metodologia BDD e apresenta a ferramenta Cucumber. A seção cinco detalha a metodologia utilizada para o desenvolvimento deste trabalho. A seção seis apresenta a análise dos resultados. E por fim, a seção sete apresenta as considerações finais, além de sugestões de trabalhos futuros. 2. Scrum Segundo Presman (2006), a metodologia ágil estimula a satisfação do cliente, entregas incrementais, equipes de projetos pequenas com alto grau de motivação, métodos informais, produtos de trabalho mínimos e simplicidade global do desenvolvimento. A metodologia ágil utilizada neste trabalho é o Scrum, desenvolvido por Jeff Sutherland durante a década de Para Presman (2006), o Scrum possui como princípios básicos: pequenas equipes de trabalho a fim de maximizar a comunicação e o compartilhamento de conhecimento e minimizar a supervisão, processo adaptável ao negócio e a modificações técnicas, produção frequentes de incrementos de software, elaboração de testes e documentos constante à medida que o produto é construído. De acordo com Schwaber (2004) o Scrum possui 3 papéis principais: Product Owner: representa os interesses de todos no projeto; Scrum Master: garante que todos sigam as regras e práticas do Scrum, ele é o responsável por remover os impedimentos do projeto; e o Time: responsável por desenvolver as funcionalidades do produto. Schwaber (2004) explica que um projeto no Scrum inicia-se com uma visão (características elabelecidas pelo cliente, premissas e retrições) do produto que será desenvolvido. Em seguida, cria-se o Product Backlog com a lista de todos os requisitos 25

26 conhecidos. O Product Backlog é então priorizado e dividido em releases. Todo o trabalho no Scrum é realizado em iterações chamadas de Sprints. Segundo Schwaber (2004) cada sprint começa com uma reunião de planejamento (Sprint Planning Meeting), na qual o Product Owner e o Time decidem em conjunto o que deverá ser implementado (Selected Product Backlog). Durante a execução das Sprints, diariamente o time faz uma reunião (Daily Scrum Meeting) de 15 minutos para acompanhar o progresso do trabalho. Na Daily Scrum Meeting de acordo com Schwaber (2004), cada membro do time responde a três perguntas básicas: O que eu fiz no projeto desde a última reunião? O que irei fazer até apróxima reunião? Quais são os impedimentos? Schwaber (2004) relata que no final da sprint é realizada a reunião de revisão (Sprint Review Meeting) para que o Time apresente o resultado alcançado na iteração. Neste momento, as funcionalidades são inspecionadas e adaptações do projeto podem ser realizadas. Em seguida, realiza-se uma reunião de retrospectiva (Sprint Retrospective Meeting) cujo objetivo é melhorar o processo/time e/ou produto para a próxima sprint. 3. Automação de Teste De acordo com Bernardo e Kon (2008) os testes automatizados são programas ou scripts capazes de exercitar as funcionalidades do sistema testado e fazer verificações automáticas nos efeitos colaterais obtidos. Para Tuschling (2008) o uso da automação de testes pode reduzir o esforço necessário para realizar os testes em um projeto de software, ou seja, é possível executar maiores quantidades de testes em tempo reduzido. Além da maior produtividade Bernardo (2011) ressalta outros benefícios da automação de testes: velocidade de execução, reprodutibilidade exata de um conjunto de ações, flexibilidade na quantidade e momento da execução das teses, possibilidade de execução paralela de testes. Apesar dos benefícios do teste automático segundo Molinari (2010), o teste manual não pode ser eliminado, ele deve ser reduzido ao máximo possível e focado naquilo que é muito caro automatizar. 3.1 Selenium O Selenium é uma ferramenta open source responsável por automatizar a execução de testes em sistemas web para qualquer navegador com suporte a Java Script. O Selenium é composto pelos seguintes módulos: Selenium-IDE: opera como plug-in do Firefox e provê interfaces para o desenvolvimento e execução de suítes de testes. Selenium WebDriver: permite a construção de lógicas de teste mais complexas, a partir do uso de uma linguagem de programação através de uma API (Application Programming Interface) e bibliotecas para as linguagens: HTML, Java, C#, Perl, PHP, Python, e Ruby 26

27 Selenium-Grid: permite distribuir os testes em múltiplas máquinas. É ideal para escalonar grandes suítes de testes. A figura 1 ilustra a tela de coleta de scripts da ferramenta IDE. Figura 1 Tela de captura de scripts do Selenium IDE Fonte: Próprio autor Dentre outras ferramentas de testes funcionais presentes no mercado tais como: Badboy Web Tool, Canoo, etc, a escolha da ferramenta Selenium para a realização deste estudo de caso foi influenciada pelos seguintes fatores: A ferramenta Selenium é uma ferramenta open source; Possui uma comunidade de usuários muito ampla ao redor do mundo; 27

28 Facilidade para encontrar documentação para consulta; A curva de aprendizagem para a utilização da ferramenta é baixa, pois ela é intuitiva e fácil de usar; O recurso de gravação das ações do usuário na página facilita e agiliza o processo de criação dos casos de teste. 4. Behavior Driven Development O Behavior Driven Development (BDD) ou desenvolvimento orientado a comportamento é uma técnica ágil para desenvolvimento de software que estimula a colaboração entre participantes não técnicos (relacionados ao negócio), desenvolvedores e testadores de um projeto de software. O BDD busca integrar o desenvolvimento com as regras de negócio, dando ênfase no comportamento e escrevendo os testes antes do código funcional. Além disso, tem como princípio uma comunicação universal, isto é, propõe que todos os envolvidos utilizem uma linguagem clara e natural (ubíqua), ou seja, não são utilizados termos técnicos e sim informações relevantes ao negócio. O BDD é considerado um aprimoramento de Test Driven Development (TDD). De acordo com Aniche (2012) o TDD é uma prática de desenvolvimento de software sugerida pelas metodologias ágeis. O TDD sugere que os desenvolvedores devem escrever testes automatizados constantemente e que estes testes sejam escritos antes mesmo da implementação. A principal diferença entre o TDD e o BDD é a mudança de foco: de teste para comportamento. Segundo Astels (2006) no TDD é escrito testes para verificar se um método faz o esperado, já no BDD o desenvolvedor escreve especificações descrevendo o comportamento que a funcionalidade deve possuir. O BDD visa minimizar a falha de comunicação entre os stakeholders envolvidos no projeto (cliente e equipe de desenvolvimento), uma vez que utilizando uma linguagem livre de termos típicos de teste. Os termos são comuns e unificados, propondo a descrição e atualização dos requisitos. Existem diversas ferramentas no mercado para apoiar o processo de BDD, para diferentes linguagens de programação, todas seguindo a mesma abordagem. Dentre elas estão: RSpec, JDave, BDoc, JBehave e a Cucumber que será utilizada neste artigo. 4.1 Cucumber Cucumber é um framework de apoio ao BDD que executa descrições funcionais escritas através de texto simples como testes automatizados. É escrito em Ruby, mas pode ser usado em conjunto com outras liguagens de programação como Java, C # e Python. O Cucumber lê as especificações a partir de arquivos de texto, chamados de recursos, escritos em uma linguagem clara e natural. Para que o Cucumber possa entender 28

29 esses arquivos de recursos, eles devem conter os seguintes termos básicos conforme apresentado na tabela 1: Tabela 1 Termos básicos usados no BDD Termo (inglês) Termo (português) Comportamento Given Como Fornece o contexto para o cenário de teste, o ponto em que ocorre o teste e todos os pré-requisitos necessários. When Quando acontecer algo Especifica o conjunto de ações que desencadeia o teste. Then Faça da seguinte forma Especifica o resultado esperado do teste. Fonte: Próprio autor Após analisar estes recursos, o Cucumber tranforma-os em cenários de teste que contém uma lista de passos a ser seguida e executa-os no software a ser testado. A ferramenta Cucumber foi escolhida para realização desse trabalho, dentre outras ferramentas como: JBehave, Concordion, Jbee, etc..., por apresentar as seguintes vantagens: Ampla documentação disponível para consulta; Possibilidade de integração do Cucumber com a ferramenta Selenium selecionada para realização deste trabalho; Possibilidade de criar testes com maior grau de abstração. Alguns aspectos técnicos também foram fundamentais na escolha desta ferramenta, tais como: flexibilidade ao passar parâmetros, flexibilidade de formatação, criação de relatórios, backgrounds e hooks, dentre outros. 5. Ambiente do Estudo de Caso O estudo de caso foi aplicado em uma fábrica de software especializada em transferência e aplicação do conhecimento das áreas de Comunicação Digital, Controle de Acesso, Stand Alone, Sistemas Embarcados, Smart Grid, Microeletrônica, Mobile, Radiofrequência, Tarifação, Testes, Sistemas Web, TV Digital. O processo de desenvolvimento utilizado é o Scrum. O desenvolvimento de software é interativo, ou seja, o trabalho é dividido em iterações (sprints). Cada sprint é dividido em ciclos de 2 semanas para desenvolvimento e 1 semana para testes. 29

30 As funcionalidades a serem implementadas no projeto são mantidas em uma lista (Product Backlog). No início de cada Sprint, faz-se um Sprint Planning Meeting, ou seja, uma reunião de planejamento na qual o Product Owner prioriza os itens do Product Backlog a serem desenvolvidos e a equipe seleciona as atividades que será capaz de implementar durante o sprint e as transfere do Product Backlog para o Sprint Backlog. A cada dia a equipe faz uma breve reunião (Daily Meeting) para disseminar o conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia. No final de um sprint, a equipe apresenta as funcionalidades implementadas, os impedimentos, os pontos positivos e os pontos de melhorias encontrados em uma Retrospective Meeting. 5.1 Projeto Piloto A aplicação da metodologia BDD em conjunto à automação de testes com a utilização das ferramentas Selenium e Cucumber foi utilizada em um projeto denominado Portal Telecom. O nome Portal Telecom é um nome fictício devido às restrições de sigilo e confidencialidade solicitada pela empresa onde esse estudo de caso foi realizado. O Portal Telecom é um projeto web, desenvolvido por uma equipe de 11 integrantes para uma empresa multinacional do ramo de telecomunicações. O Portal foi desenvolvido na linguagem Java com auxílio dos frameworks Maven, Spring e Hibernate, Primefaces e Java Server Faces. O projeto do Portal Telecom foi escolhido para realização deste piloto, pois, ele possui uma funcionalidade que é reutilizada em vários módulos, que é a realização de análises em redes de clientes a fim de encontrar problemas e pontos de melhorias. Dessa forma, mudanças nesta funcionalidade impactavam em várias outras, fator que contribuía muito para que o esforço com as atividades de testes fosse alto. 5.2 Aplicação das Ferramentas de Automação e BDD Para aplicar a automação de testes de aceitação no Portal Telecom primeiramente foram coletados os scripts de testes através da ferramenta Selenium IDE. Estes scripts possuem a finalidade de simular a interação de um usuário real com o Portal de Telecom. Os scripts por sua vez foram incorporados ao projeto de desenvolvimento através de 161 classes de testes que representam cada cenário do usuário a ser testado. Estas classes de testes utilizaram o framework JUnit para integrar e executar os scripts de testes à linguagem de programação Java, o framework Hibernate para realizar o mapeamento objetorelacional necessário à validação dos resultados do teste e o framework Spring responsável pela injeção de dependência, mecanismo de segurança e controle de transações nos testes. Os testes através do comportamento, proposta da metodologia BDD, foram também incluídos nas classes de testes através do framework Cucumber. Após a escrita de cada classe de teste, os testes foram executados para validar as funcionalidades do Portal Telecom. 30

31 As principais dificuldades encontradas para a aplicação da metodologia BDD em conjunto com a automação de testes de aceitação foram: a inexperiência de toda a equipe em relação à nova proposta, a constante mudança dos componentes de tela do Portal o que ocasionava um retrabalho para configuração dos scripts de testes e a pequena quantidade de fontes de referências técnicas encontradas que pudessem auxiliar na utilização em conjunto da API do Selenium para a linguagem Java e do framework Cucumber. 6. Análise dos Resultados Por meio da realização deste estudo de caso, podemos observar uma melhoria no processo de testes através da adoção da automação de testes, uma vez que os defeitos foram encontrados mais rapidamente, a repetição de um cenário de teste se tornou mais simples, a atividade de testar tornou-se menos árdua para os testadores, e houve uma diminuição no tempo total utilizado durante o processo de testes. Com a adoção da automação de testes o tempo para realizar todos os 161 casos de testes caiu de 5 dias para 2 dias. A adoção da metodologia BDD também trouxe benefícios para o processo de desenvolvimento de software, tais como: uma compreensão mais clara dos comportamentos desejados no software, diminuição dos erros de interpretação das estórias de usuário e uma melhoria na comunicação entre todos os envolvidos no projeto. 7. Conclusão e Próximos Passos Neste trabalho foi apresentada uma experiência prática da implantação de ferramentas de automação de testes em conjunto com a metodologia BDD em uma equipe que utiliza o modelo de desenvolvimento ágil Scrum. A partir da análise dos resultados foi possível notar que inicialmente, a automação de testes é mais custosa que a execução manual, entretanto ao longo das suas execuções, é possível obter um ganho considerável na agilidade dessa atividade. Além disso, a aplicação da metodologia BDD junto à automação de testes agregou diversos benefícios ao processo, dentre eles pode-se citar: facilidade de elaboração e entendimento dos cenários de testes por todo o time, redução de esforço com a execução de testes automatizados, os envolvidos conseguiram assimilar sem ambiguidade o que estava sendo desenvolvido, melhorando a comunicação e reduzindo os erros, proporcionou um alto índice de reaproveitamento na implementação dos cenários de testes, e facilitou a manutenção dos scripts gerados e realização de testes de regressão. Como trabalhos futuros, pretende-se adicionar a este estudo de caso, uma análise da cobertura dos testes de aceitação automatizados e uma medição do grau de satisfação dos clientes em relação à qualidade do software após a adoção da metodologia BDD em conjunto com a automação de testes. 8. Referências Aniche, Maurício Finavaro. (2012) Como a prática TDD influência o projeto de classes em sistemas orientado a objetos. Dissertação (Mestrado) - Universidadede São Paulo, Instituto de Matemática e Estatística. Programa de Mestrado em Ciência da 31

32 Computação. Disponível em /pt-br.php. Acesso em 01 março Astels, D. (2006). A new look at test-driven development. Disponível em: < > Acesso em em 12 março Bernardo, Paulo Cheque. Padrões de testes automatizados Dissertação (Mestrado) - Universidade São Paulo, Instituto de Matemática e Estatística. Programa de Mestrado em Ciência da Computação. Disponível em: < Acesso em 04 março Bernardo, P. e Kon, F. (2008). A Importância dos Testes Automatizados. Disponível em: < Acesso em em 10 janeiro Cucumber Making BDD fun (2014). Cucumber. Disponível em: < Acesso em: 10 janeiro [IEEE 1998] IEEE (1998). IEEE Standard for Software Test Documentation - IEEE Std IEEE Computer Society. Molinari, L. (2010) Inovação e Automação de Testes de Software. São Paulo. Myers, Glenford J. (2004) The Art of Software Testing. New York: John Wiley & Sons, 2 Edição. Pressman, R. (2006). Engenharia de Software. McGraw-Hill, 6 Edição. Schwaber, K. (2004) Agile Project Management with Scrum. Microsoft Press. Selenium HQ Browser Automation (2014). Selenium Documentation. Disponível em: < Acesso em: 10 janeiro Tuschling, O. (2008) Software Test Automation. Disponível em:< stfilen ame1%2epdf >. Acesso em 10 fevereiro de

33 Um Diagnóstico sobre a Gerência de Contratos em Projetos Ágeis de Belo Horizonte Camila Luana de Andrade¹, Jéssica Braga da Cruz Lopes 1, Marcelo Werneck Barbosa¹, Melissa Morgado Costa 2 ¹Instituto de Ciências Exatas e Informática Pontifícia Universidade Católica de Minas Gerais (PUC Minas) Belo Horizonte MG Brasil 2 Ministério Público do Estado de Minas Gerais Belo Horizonte MG Brasil camila.luana.andrade@outlook.com, jeh_moor@homail.com, mwerneck@pucminas.br, mmorgado@mp.mg.gov.br Resumo. Atualmente as fábricas de software têm buscado diversas alternativas de construção e gerenciamento de sistemas que tornem o processo de desenvolvimento cada vez mais simples, rápido e eficaz. Em virtude disso metodologias de desenvolvimento ágil são aplicadas com o intuito de aprimorar esses processos. O presente artigo busca identificar como as empresas em Belo Horizonte têm estabelecido e gerenciado contratos em projetos Scrum. O trabalho identificou que alguns princípios ágeis não têm sido utilizados, mas mostra uma preocupação das empresas com a qualidade do desenvolvimento de software. Abstract. Currently software factories have tried several alternatives for building and managing systems that make the development process simpler, faster and more effective. As a result, agile development methodologies are applied in order to enhance these processes. This paper seeks to identify how companies in Belo Horizonte have established and managed contracts in Scrum projects. The study identified that some agile principles have not been applied, but shows a business concern with software quality. 1. Introdução A cada dia aumenta a necessidade de se aprimorar o gerenciamento de projetos e são buscadas técnicas de construção de software que acelerem o desenvolvimento. As metodologias ágeis são utilizadas para alcançar esse tipo de objetivo utilizando os conceitos de rápido desenvolvimento agregando valor ao cliente. Uma destas metodologias é o Scrum [Pham; Pham, 2011]. Por se tratar de uma técnica de valores informais, os princípios Scrum valorizam mais o que é produzido sem se preocupar tanto com registros e documentação. Uma das premissas do Scrum é que seja fácil realizar mudanças no sistema caso o cliente deseje. Entretanto, essa maior flexibilização em relação às mudanças pode demandar algumas alterações na maneira como os contratos são gerenciados [Cohn, 2011]. Com esse trabalho, se pretende levantar quais são as práticas formais e informais de celebração de contratos e evidenciar as dificuldades encontradas no cumprimento dos 33

34 acordos contemplados entre o cliente e os responsáveis pelo projeto nas empresas. Como projetos ágeis trabalham com escopo variável, o trabalho procurou identificar na prática, como as empresas de Belo Horizonte celebram seus contratos e se os princípios ágeis são respeitados neles. Este artigo está organizado da seguinte forma. A Seção 2 apresenta conceitos relacionados a métodos ágeis em geral e à metodologia Scrum. A Seção 3 explica a proposta de aplicação deste trabalho enquanto a Seção 4 apresenta os resultados desta aplicação. A Seção 5 encerra o trabalho com suas conclusões e trabalhos futuros. 2. Métodos Ágeis e Scrum Em busca de práticas de gerenciamento e execução de projetos mais eficazes surgiu, em 2001, o Manifesto ágil de Desenvolvimento de Software, cujo objetivo foi reunir as melhores práticas de desenvolvimento utilizadas valorizando o funcionamento do software, relacionamento com cliente e a resposta às mudanças [Beck, 2001]. Para um desenvolvimento ser considerado ágil deve seguir algumas características importantes, como, constante incremento, cooperação, transparência, adaptabilidade, iteratividade, auto-organização, emergência, períodos de reflexão e introspecção, incorporação de feedback rápido, modularidade, restrição de prazo, parcimônia, convergência, orientação a pessoas, colaboração, equipes pequenas, testes constantes, equipes locais e cortesia [Abrantes; Travassos, 2007]. O método ágil Scrum emprega uma abordagem iterativa e incremental, construindo um produto gradativamente, possibilitando o aperfeiçoamento, a previsão de riscos e medidas de controle [Cohn, 2011]. O Time Scrum é formado pelo Product Owner, a Equipe de Desenvolvimento e o Scrum Master. A equipe é caracterizada por ser multifuncional e auto-organizável, ou seja, cada integrante possui autonomia e pode realizar diferentes atividades. O Product Owner representa o cliente e é o membro da equipe responsável pela visão do produto, pelos itens e também pela priorização do backlog no ponto de vista empresarial levando em consideração aspectos como valor, risco, prioridade e necessidade. O dono do produto deve ser disponível, comunicativo, determinado, deve responder com autoridade e ser especialista no negócio [Cohn, 2011]. Por sua vez, a Equipe de Desenvolvimento (Time Scrum) é responsável por todas as atividades de construção do software dentro de uma equipe Scrum, indo da redação de requisitos até o projeto, codificação e testes [Pham; Pham, 2011]. O Time Scrum trabalha integrado. Não há diferenciação entre os papéis desempenhados e não existe o tamanho ideal de uma equipe de desenvolvimento, basta ela ser pequena o suficiente para ser caracterizada ágil e grande o bastante para conseguir completar o trabalho [Schwaber; Sutherland, 2001]. O Scrum Master é o especialista na metodologia Scrum cuja responsabilidade é ajudar o restante da equipe e a empresa a entender e aplicar suas práticas no projeto. Entre seus deveres estão ajudar o Time a criar os itens do backlog, encontrar as melhores técnicas para o gerenciamento desses itens, treinar a equipe e ajudar a remover impedimentos [Pham; Pham, 2011]. O Scrum define conceitos importantes referentes à aplicação do processo no período do projeto. O backlog do Produto é um desses conceitos e consiste em uma lista 34

35 ordenada das exigências daquele produto. Ele é dinâmico e pode ser atualizado à medida que vão sendo cumpridos ou surgem novos requisitos. Durante o desenvolvimento dos itens do backlog existem períodos de tempo fixo onde o Time trabalha para entregar algo de valor ao cliente, o tempo determinado para essas entregas é denominado sprint [Cohn, 2011]. As sprints são iterações sequenciais e formam um ciclo fixo, durante o qual a equipe se compromete a transformar os requisitos selecionados para aquela entrega em um incremento do produto [Pham; Pham, 2011]. Em projetos ágeis existem algumas variáveis que devem ser consideradas antes da escolha do contrato. Algumas delas são o gerenciamento de necessidade de incrementos, a informalidade na definição das entregas, a abertura para a variação do escopo e as alterações incrementais [Pham; Pham, 2011]. 3. Proposta de estudo O foco do estudo foi as formas de contratações formais e informais adotadas pelas empresas de softwares e os principais acordos e exigências feitas tanto à equipe de desenvolvimento quanto ao cliente. Não foi possível ainda realizar a pesquisa em um universo de empresas que pudesse ser considerada representativa em termos estatísticos, porém, acreditamos que já foi possível identificar características importantes do atual cenário de contratação em Belo Horizonte. Inicialmente, foi elaborado um conjunto de perguntas abertas, que abordavam conteúdos específicos, com o objetivo de diagnosticar características relevantes do processo de contratação em empresas ágeis e com isso guiar a elaboração do formulário de questões final. A partir das respostas coletadas das empresas de software e com a ajuda de alguns profissionais da área, que aceitaram participar da pesquisa, foi elaborado um questionário piloto de perguntas fechadas com o objetivo de investigar como as empresas que utilizam o desenvolvimento Scrum celebram seus contratos e quais são suas características principais. Esse questionário foi enviado a uma gerente de projetos que participou da pesquisa opinando e validando as questões abordadas. Após o fechamento das perguntas o questionário foi disponibilizado na web através de uma ferramenta gratuita, o SurveyGizmo 1. Em paralelo, com o intuito de selecionar uma amostra de pesquisa, foi feito um levantamento das empresas públicas e privadas de desenvolvimento de software em Belo Horizonte que utilizam o Scrum em projetos internos ou que prestam serviços de desenvolvimento a terceiros. O contato com essas empresas foi feito via e telefone e a amostra escolhida foi baseada nas empresas que concordaram em realizar o estudo de caso. Durante 18 dias o formulário ficou disponível na web para coleta de respostas. Inicialmente 20 empresas foram convidadas a participar da pesquisa e ao final do período de coleta de dados foram obtidas 15 respostas, uma por empresa. O estudo foi baseado nas respostas de pessoas que conheciam o processo de contratação e que desempenhavam algum papel no desenvolvimento ágil. Após essa análise foi feito um diagnóstico das principais causas de problemas relacionados à gerência de contratos

36 4. Resultados 4.1 Perfil das Empresas Entrevistadas O estudo foi feito em 15 empresas da região de Belo Horizonte, sendo 2 públicas e 13 privadas. Entre as organizações analisadas constatou-se que 28,6% utilizam Scrum há mais de 3 anos, enquanto a grande maioria, cerca de 42,9%, ainda não completaram o primeiro ano de aplicação. Os gráficos exibidos na Figura 1 mostram o tempo de atuação no mercado e o período de adoção da metodologia nas organizações. Figura 1(a). Tempo da empresa no mercado. (b). Tempo com Scrum. As empresas selecionadas possuem um número satisfatório de clientes que são atendidos em projetos e equipes diferentes. Verificou-se que a grande maioria delas, 71,4%, desenvolvem software internamente, ou seja, atendem apenas suas próprias demandas e não possuem outras empresas como cliente. A menor parte, cerca de 28,6%, também desenvolvem internamente diante de suas próprias necessidades mas tem como foco atender ao cliente externo. Nenhuma das empresas avaliadas desenvolve exclusivamente para o mercado externo. A Figura 2 mostra o cargo e papel de cada respondente no Time Scrum. Figura 2(a). Cargo na empresa. (b). Papel no Scrum. 36

37 Além disso, em relação ao perfil do profissional entrevistado, foi possível verificar que 28,6% dos respondentes ainda não completou um ano de vivência com o desenvolvimento ágil. A maior parte das pessoas entrevistadas, cerca de 50%, trabalha com Scrum entre 1 e 2 anos, enquanto 14,3% atua com a metodologia entre 2 e 3 anos. Apenas 7,1% possuem mais de 3 anos de experiência. Os gráficos da Figura 3 comparam o tempo de experiência na empresa com o de Scrum dos respondentes. 4.2 Resultados Figura 3 (a). Tempo do profissional na empresa. (b). Tempo com Scrum. Foram analisados aspectos do comportamento do cliente nos projetos e verificou-se que pouco mais da metade deles não encontra muitas dificuldades em se comprometer com a metodologia Scrum, o equivalente a 53,9%. Para 23,1%, a dificuldade em se comprometer existe na maioria dos projetos enquanto 15,4% considera a metodologia complicada e difícil de ser seguida. Apenas uma empresa das pesquisadas possui parceiros com maior maturidade no desenvolvimento ágil e que não apresentam dificuldades em se comprometer com a metodologia. Entre as empresas consultadas percebe-se que na maioria dos casos o Product Owner é o especialista no negócio (38,5%). Em seguida vem o analista de TI, com 30,8%, e por último, com 23,1% dos entrevistados, o cliente. Com isso as empresas conseguem manter as partes interessadas um pouco mais próximas da evolução do projeto, participando principalmente das reuniões de planejamento, revisão e retrospectiva de sprint. Nas reuniões diárias, 38,5% dos Products Owners não participam enquanto apenas 7,7% estão pontualmente presentes. Quanto à escrita das estórias, na maior parte das empresas, 61,6%, o Product Owner participa da escrita juntamente com a equipe enquanto em 38,4% dos pesquisados, a equipe escreve as estórias sozinhas sem a intervenção do Product Owner. Esse aspecto reflete diretamente na priorização do backlog e na entrega dos artefatos. As empresas foram também questionadas sobre os itens de maior responsabilidade do Product Owner. A Figura 4 mostra que, com 84,6%, o comprometimento na priorização do backlog aparece em primeiro lugar. Em seguida com 76,9% é listada a disponibilidade do responsável pelo produto juntamente com sua agilidade no atendimento. 37

38 Figura 4. Responsabilidades mais importantes do Product Owner Analisando aspectos específicos relacionados a contratação foi possível perceber que 53% das empresas contratam por horas de desenvolvimento sem se comprometer com um escopo definido, o que funciona bem em projetos Scrum pois o escopo é a principal variável do projeto. O contrato por pontos de função é utilizado por 23,1% das empresas entrevistadas, enquanto 15,4% contrata por escopo e preço fixo. Cerca de 7,7% definem um escopo limitado deixando fixo o número de horas/recursos, desenvolvendo apenas os itens compreendidos entre esses limites. Na maioria das empresas, 79%, foi observado que tanto a equipe de desenvolvimento quanto o cliente são consultados durante a elaboração do contrato, porém em 21% dos casos apenas a área comercial participa da contratação não envolvendo as demais partes. A respeito da definição de datas para término do projeto, 53,9% definem data para término apenas com o decorrer do projeto quando os requisitos contratados vão sendo desenvolvidos; 30,8% dos entrevistados só considera o fim do projeto quando os requisitos são cumpridos e aceitos pelo cliente, enquanto em poucos casos (15,4%) a data é definida no momento da contratação. Foram verificados quais os principais itens restringidos em contratos ágeis. A Figura 5 apresenta como principais restrições as datas para entregas dos itens desenvolvidos em cada sprint e a autorização para uso de mão-de-obra terceirizada. Figura 5. Restrições estabelecidas em contratos 38

39 Apenas uma empresa não citou restrições sobre a equipe de desenvolvimento do projeto. Todas as outras alegaram que os clientes exigem no contrato critérios a respeito da equipe, sendo o principal item a experiência dos integrantes. Times que trabalham há um bom tempo juntos ou que tenham desenvolvido produtos com sucesso para o cliente são procurados e priorizados. Eles alegam que o relacionamento entre os integrantes é melhor e consequentemente a produtividade aumenta. A grande maioria das empresas, 46,2%, usam o mesmo time durante todo o projeto, em outros 23,1%, o time se mantém para vários produtos, enquanto em 30,8% delas o time sofre várias alterações dentro do mesmo projeto. O que normalmente ocasiona essas modificações é a experiência dos desenvolvedores, que são alocados para desenvolver itens que possuem maior domínio e posteriormente são realocados em outros projetos. Foram questionados os aspectos contratuais que determinam o tamanho e a característica das sprints. Pôde-se perceber que 38,5% dos projetos pesquisados incluem estórias na sprint durante seu andamento. A grande maioria, cerca de 53,9%, relataram que a inclusão pode ocorrer mas que são evitadas, portanto só acontecem em casos de grande necessidade. Para 7,7% das empresas as estórias podem sim ser incluídas desde que o projeto esteja nas fases iniciais. Quanto à normalização no tamanho das sprints, 23,1% das empresas adotam um tamanho único e padrão para os projetos e áreas, enquanto 46% delas tentam manter esse número fixo mas em situações especiais abrem exceções de modificação. Outros 30,8% não estipulam em contrato esse tipo de informação e permitem alterações ao longo do projeto à medida que seja necessário. Entre os principais problemas encontrados no não cumprimento do contrato em relação às entregas está o dimensionamento incorreto das estórias. A Figura 6 apresenta as principais razões encontradas para o problema nos cálculos.. Figura 6. Principais motivos do dimensionamento incorreto das estórias Observa-se ainda que 46,2% dos projetos não possuem grandes problemas com o detalhamento dos requisitos enquanto 15,4% apresentam retrabalho devido a requisitos mal detalhados e 38,5% se deparam com o problema, mas não em todos os projetos e áreas. O resultado apontou que os projetos que possuem pouco detalhamento dos requisitos na fase de conversação apresentam maiores evidências de retrabalho, isso 39

40 destaca a importância de aprofundar na apresentação e entendimento dos itens a serem desenvolvidos. Em relação ao conceito de artefato pronto, espera-se que os itens sejam entregues atendendo todos os requisitos do cliente. Verificou-se que 14,14% das empresas não avaliam a qualidade com que o artefato foi produzido para considerá-lo pronto. Outros 46,2% avaliam a qualidade, mas ele não é objeto principal de análise, podendo assim ser considerado concluído, caso o tempo de construção ou custo ultrapassem o planejado. No entanto 38,5% prezam primeiramente pela qualidade dos artefatos e não os considera concluídos até que sua qualidade seja satisfatória. Algumas das empresas pesquisadas levantaram a informação que os clientes muitas vezes procuram empresas de desenvolvimento de software que tenham um processo mais maduro e que utilizem diretrizes de acompanhamento. Foi diagnosticado que nem todas as empresas que utilizam Scrum possuem diretrizes que norteiem o desenvolvimento, algumas possuem, mas são informais, como mostra a Figura 7. Figura 7. Orientação sobre uso da metodologia ágil Até que o Time esteja totalmente integrado e que possua certa experiência no desenvolvimento ágil, verifica-se que pode haver atraso nas entregas dos artefatos desenvolvidos. A Figura 8 ilustra qual o comportamento do cliente caso o escopo planejado não seja entregue no prazo. Figura 8. Posicionamento do cliente perante escopo não entregue 40

41 Como critério de aceitação, as empresas foram questionadas sobre os aspectos que consideram mais importantes a serem tratados no momento da contratação, para que os itens mais críticos do projeto sejam assegurados e que seu desenvolvimento aconteça da melhor forma tanto para a equipe de desenvolvimento quanto para o cliente. A Figura 9 apresenta o resultado no qual o acompanhamento e feedback do cliente aparecem em primeiro lugar. Figura 9. Princípios considerados mais importantes durante a contratação 4.3 Análise dos Resultados Entre as principais características de projetos Scrum está a definição de um escopo variável. Em análise às formas de contratação adotadas, pode-se concluir que parte das empresas não utilizam algumas das características básicas do desenvolvimento ágil, definindo assim o escopo do projeto no momento da contratação. Esse comportamento afeta diretamente outros princípios da metodologia, pois alguns aspectos como a data para término e a priorização de um desenvolvimento focado nas necessidades do cliente deixam de ser itens principais para serem aspectos fechados e não dinâmicos do projeto. Não há um senso comum entre os itens garantidos nos contratos. Em alguns casos as empresas consideram importante manter alguns aspectos no acordo, mas os mesmos não são contemplados ou assegurados em seus contratos. Um exemplo disso é acompanhamento e feedback do cliente, que é listado em primeiro lugar no ranking dos itens essenciais a serem garantidos, mas que na realidade o Product Owner nem sempre está disponível para participar das reuniões principais. As empresas não costumam assegurar que a definição do tamanho das sprints seja feita no momento da contratação, pois acreditam que assim se tornam independentes e desenvolvem conforme suas necessidades. Percebe-se que ao contrário do que pensam esta não é uma boa prática. A falta de definição de um período de entrega padrão pode prejudicar o acompanhamento do projeto, a previsão de desenvolvimento, a medição do desempenho e prejudicar as estimativas para o próximo período. Nota-se a importância de se melhorar o processo de estimativas. Seu mal dimensionamento impacta diretamente na entrega dos artefatos, pois há retrabalho no 41

42 desenvolvimento. Uma sugestão para resolver esse desafio seria dedicar um maior tempo na etapa de conversação para o entendimento dos requisitos e trabalhar com equipes conhecidas, que se relacionam bem e apresentam alta produtividade. Um ponto interessante observado foi que a atenção para o desenvolvimento vem sendo focada na qualidade dos artefatos. Algumas empresas não consideram o artefato pronto até que sua qualidade seja satisfatória para suprir as necessidades do cliente. Essa medida deve ser adotada pelas empresas, pois um dos pilares do desenvolvimento ágil é desenvolver software de maneira simples, mas priorizando a qualidade. 5. Conclusão O objetivo deste trabalho foi diagnosticar como é regida a forma de contratação nos projetos ágeis, sejam elas firmadas formalmente ou não, e apresentar os principais problemas encontrados nas empresas em ações mal contratadas. Não foi identificado um resultado único ao tentar destinguir a característica considerada mais importante pelas empresas, porém grande parte delas apontou aspectos relevantes ao processo de contratação. Entre os principais resultados foram observados a preocupação com a qualidade dos artefatos desenvolvidos, os problemas com a falta de padronização das sprints, a necessidade de melhorar a estimativa de requisitos e algumas não-conformidades relacionadas aos princípios Scrum definidos no contrato. Como trabalhos futuros, pretende-se aumentar a amostra de empresas, aplicar o estudo em outras cidades e regiões brasileiras através de entrevistas e ainda buscar relações entre os tipos de contratos e o sucesso ou fracasso dos projetos estudados. 6. Referências ABRANTES, José Fortuna; TRAVASSOS, Guilherme Horta. Caracterização de métodos ágeis de desenvolvimento de software. In Primeiro Workshop de Desenvolvimento Rápido de Aplicações VI Simpósio Brasileiro de Qualidade de Software, Porto de Galinhas-PE, Brasil, BECK, Kent et al. Agile Manifesto. Disponível em Acesso em 01 Mai COHN, Mike. Desenvolvimento de Software com Srum: Aplicando Métodos Ágeis com Sucesso. Porto Alegre: Bookman, PHAM, Andrew; PHAM, Phuong-Van. Scrum em ação: gerenciamento de desenvolvimento ágil de projetos de software. 1. ed. São Paulo: Novatec, p. PMI. Conjunto de Conhecimentos em Gerenciamento de Projetos (PMBOK). Project Management Institute (PMI). 5ª ed SCHWABER, Ken; SUTHERLAND, Jeff. Um guia definitivo para o Scrum: As regras do jogo. Disponível em < %20Guides/Scrum_Guide.pdf#zoom=100>. Acesso em 20 Abr

43 Avaliando Acoplamento em Atividades de Manutenção Bruno Rodrigues, Daniel Souza, Eduardo Figueiredo Depto. de Ciência da Computação, Universidade Federal de Minas Gerais (UFMG) Fac. de Ciências Empresariais, Fundação Mineira de Educação e Cultura (FUMEC) {brunorodriguesti, danielpucplg}@hotmail.com, figueiredo@dcc.ufmg.br Categoria: Trabalho de Co - Concluído Abstract. Coupling metrics are commonly used to quantify the maintainability of object-oriented software systems. The higher the degree of coupling, the less maintainable a software system tends to be. However, the understanding of what coupling means may vary among different programmers. To address this issue, this paper presents a study with the goal of investigating how programmers rely on coupling to evaluate software maintainability. This study involved 30 programmers with different levels of experience who had to assess the degree of coupling in a software project. Based on the results, coupling metrics were related with programmers understanding of coupling in order to identify anomalies in a software project. Resumo. Métricas de acoplamento são comumente usadas para quantificar a manutenibilidade de sistemas orientados a objetos. Quanto maior o grau de acoplamento, menos manutenível um sistema de software tende a ser. Contudo, o entendimento de acoplamento pode variar entre os diferentes programadores. Para isso, este trabalho apresenta um estudo com o objetivo de investigar como os programadores usam acoplamento para avaliar a manutenção de software. Este estudo envolveu 30 programadores com diferentes níveis de experiência que tiveram de avaliar o grau de acoplamento em um projeto de software. Com base nos resultados, métricas de acoplamento foram relacionadas com a compreensão de acoplamento dos programadores para identificar as anomalias do projeto de software. 1. Introdução A programação orientada a objetos (POO) é uma técnica de programação consolidada no desenvolvimento de sistemas de software. Quando adequadamente empregada, POO proporciona um ritmo de desenvolvimento mais rápido e maior qualidade de software [15]. Um dos benefícios esperados pela adoção de POO é uma melhor manutenibilidade de software. Isso traz um ganho em economia de tempo e esforço, ajudando também os programadores a construírem sistemas mais confiáveis e eficientes. No entanto, alguns fatores, entre eles o alto acoplamento, podem interferir negativamente em potencias ganhos trazidos pelo emprego de POO [2]. A fim de apoiar a manutenção de sistemas de software orientados a objetos, a qualidade do projeto deve ser avaliada através de meios de quantificação adequados [16]. 43

44 O acoplamento é uma medida da força de associação estabelecida através de uma ligação a partir de uma entidade para outra [1, 17]. Esta associação pode criar um efeito cascata no qual o número de invocações entre objetos está relacionado à maior probabilidade de alterações em cadeia [2, 11]. Sistemas de software com baixo acoplamento tipicamente são mais fáceis de serem mantidos. Quanto mais dificuldade se tem para manter o software, maior o seu custo [2]. Assim, reduzir o acoplamento entre as classes do sistema pode facilitar as atividades de manutenção de software [14]. Uma variedade de métricas de software têm sido propostas [1, 6] para avaliar a manutenibilidade de sistemas de software. Por exemplo, trabalhos [15] investigam como estas métricas podem ser usadas para favorecer o desenvolvimento de software no paradigma orientado a objetos (OO). Para ajudar o engenheiro de software detectar e localizar problemas de design, este mecanismo de detecção pode ser definido de modo que os desvios dos princípios de bons padrões sejam quantificados e informados baseados nessas métricas [16]. Este trabalho, ao contrário dos citados, foca no entendimento de programadores a respeito de acoplamento e na relação deste entendimento com métricas de acoplamento. Através de um estudo exploratório, 30 programadores da academia e da indústria identificaram classes com alto acoplamento em um sistema OO, chamado API Apache Log4J [13], usando um diagrama de modelagem e o código fonte. Os programadores não tiveram acesso a nenhuma métrica durante a execução do estudo. Entretanto, eles tiveram de responder um questionário sobre o raciocínio adotado para identificar as classes altamente acopladas. O objetivo foi avaliar o entendimento dos programadores sobre acoplamento de software. Em um segundo momento, o presente trabalho coletou da literatura métricas de acoplamento comumente adotadas para avaliar manutenibilidade de software [1, 5]. Estas métricas de acoplamento foram relacionadas às respostas dos programadores; ou seja, o estudo buscou identificar as métricas que os programadores intuitivamente usaram para avaliar o sistema de software. Os resultados dos questionários foram cuidadosamente analisados. Por exemplo, puderam-se enumerar várias sugestões dos programadores para o uso de técnicas, como refatorações, com o objetivo de reduzir o acoplamento entre os objetos analisados. Algumas lições aprendidas neste trabalho refletem (i) o conhecimento do uso de interfaces e (ii) o melhor encapsulamento de objetos para minimizar o acoplamento. Além disso, técnicas de refatoração, como Extract Method e Move Method [12], bem como modelos de arquiteturas como Inversão de Controle e Injeção de Dependência [12], foram citadas pelos programadores por agregarem conhecimento para diminuir o acoplamento no software. O restante do artigo está organizado da seguinte forma. A Seção 2 apresenta o referencial teórico que fornece base para compreensão geral do artigo. A Seção 3 discute os objetivos da pesquisa, o sistema utilizado para análise do nível de acoplamento e a forma como foi conduzido o estudo. A Seção 4 apresenta os principais resultados do estudo e uma discussão destes resultados. Na Seção 5, as ameaças à validade são levantadas. A Seção 6 discute os trabalhos relacionados enquanto a Seção 7 conclui o artigo e aponta direções para trabalhos futuros. 44

45 2. Referencial Teórico Grande parte dos esforços de construção de um software é realizada em atividades de manutenção [1]. Quanto mais dificuldade se tem para manter o software, maior será o seu custo [2]. Estudos [2, 11] mostram que o alto grau de acoplamento do software impacta negativamente a manutenção causando efeitos colaterais como mudanças frequentes. Apesar de existirem diversas métricas de acoplamento disponíveis na literatura [1, 5], observa-se que os programadores raramente fazem uso destas métricas em projetos reais [6, 12]. Uma possível razão para isso é que as métricas podem não capturar o real entendimento dos programadores a respeito de acoplamento. Algumas das métricas de acoplamento bastante estudadas na literatura são discutidas a seguir. Algumas das métricas OO mais conhecidas pertencem ao conjunto de Chidamber e Kemerer [6]. Este conjunto inclui duas métricas de acoplamento: Acoplamento entre Objetos (CBO) e Respostas para uma Classe (RFC). CBO é uma métrica que quantifica o número de outras classes que são acopladas a classe corrente. A relação entre as classes pode ir de diversas maneiras. Os relacionamentos entre classes são considerados apenas uma vez, ou seja, múltiplos acessos à mesma classe via métodos ou atributos são contados como um único acesso [6]. Por outro lado, RFC é a contagem de métodos que são potencialmente invocados em resposta a uma mensagem recebida por um objeto de uma classe particular [6]. Isto é computado com a soma do número de métodos de uma classe e o número de métodos externos chamados por ele. Além das métricas de Chidamber e Kemerer, outras métricas de acoplamento usadas neste artigo são Acoplamento por Mensagens (MPC) [15], Acoplamento baseado em Fluxo de Informação (ICP) [1], Acoplamento baseado em Herança (IH-ICP) [1] e Acoplamento não baseado em Herança (NIH-ICP) [1]. MPC é definido como o número de chamadas únicas efetuadas em uma classe [15]. A contagem do valor de MPC é calculada por classes. Esta inclui chamadas para todos os métodos, funções e propriedades, sejam em classes ou outros módulos. Chamadas para definir a propriedade, i.e., métodos set e get, são contabilizadas separadamente [6]. O ICP é a soma de NIH-ICP e IH-ICP [1]. Ou seja, ICP contabiliza número de chamadas de método de uma classe, ponderadas pelo número de parâmetros, considerando também invocações de métodos da super-classe. 3. Configuração do Estudo Para fomentar o entendimento de acoplamento na manutenção de software, foi feito um estudo de caráter exploratório [19] com 30 programadores voluntários sobre acoplamento em um sistema de software. Destes programadores, 19 são profissionais que atuam na indústria de software - em uma empresa pública do estado de Minas Gerais. Os outros 11 programadores são alunos de pós-graduação de uma universidade federal brasileira. A pesquisa foi conduzida através da estratégia empírica survey. O survey é um modo de colher informações de/ou sobre pessoas para descrever, comparar ou explicar seus conhecimentos, atitudes e comportamentos [19]. Através deste conceito, pretendese inferir como diferentes programadores reconhecem alto acoplamento em sistemas orientados a objetos, e como pode ser melhorada sua possibilidade de sua manutenção. Com isso, são colhidas informações de diferentes pontos de vista sobre o acoplamento e 45

46 como este pode ser minimizado, melhorando a manutenibilidade do sistema, um dos atributos de qualidade de software. Os participantes tiveram orientação verbal sobre o preenchimento do formulário e lhes foram explicados o propósito da pesquisa. Para evitar qualquer transtorno os pesquisadores ocultaram a identificação dos participantes na divulgação dos resultados. Aos participantes foram disponibilizados o diagrama dos principais componentes da arquitetura do Log4J exibido na Figura 1 e seu código fonte através de uma interface Web. Em posse destes dados foi solicitado para que eles analisassem o projeto e respondessem a um formulário indicando quais as classes que consideraram estar mais acopladas, justificando o motivo de sua escolha. Entre as questões, também foi perguntado sobre a dificuldade que encontraram para descobrir o grau de acoplamento no projeto e como pode ser melhorada a manutenibilidade do projeto analisado de acordo com o nível de acoplamento encontrado Atividades do Estudo e Sistema Utilizado Neste estudo, foi proposta uma análise das principais classes da API Apache Log4J [13] através de um questionário aplicado a programadores com diversos níveis de experiência profissional. O Log4J é uma API Java que auxilia no registro de logs em sistemas. Os participantes tiveram acesso ao código fonte das classes do sistema e à um Diagrama de Classes simplificado, como mostra a Figura 1. Figura 1: Principais classes do Log4J Os participantes então responderam a um formulário indicando quais as classes consideraram estar mais acopladas, justificando o motivo de sua escolha e como a manutenibilidade do projeto poderia ser melhorada considerando o nível de acoplamento. Através das respostas dos programadores, foram identificadas as métricas de acoplamento que intuitivamente os programadores usam para avaliara a manutenibilidade de sistemas de software orientados a objetos Caracterização dos Participantes Para classificar os níveis de experiência dos programadores que participaram deste estudo, foi aplicado um questionário sobre sua experiência profissional. Deste modo obteve-se o conhecimento dos participantes em relação a (i) programação orientada a objetos e Java, (ii) participação em projetos de desenvolvimento de software, (iii) experiência em anos de desenvolvimento e (iv) os tipos dos projetos aos quais eles participaram. De acordo com o questionário respondido por estes, pode-se estimar sua experiência de desenvolvimento de software. Assim, o nível de experiência dos programadores pesquisados pode ser classificado de acordo com a Tabela 1. Os 46

47 participantes também indicaram seu entendimento a respeito de acoplamento por meio de uma pergunta sobre o que eles consideram acoplamento de software. Os dados completos do questionário aplicado estão disponíveis online Sistema Utilizado Tabela 1: Experiência em anos dos programadores Nível # de Programadores # de Programadores (anos em experiência) (conhecimento em POO e Java) Juniores 13 (1 a 3 anos) 6 (básico) Intermediários 10 (3 a 5 anos) 18 (intermediário) Experientes 7 (6 a 10 anos) 6 (avançado) O Log4J é uma API Java que auxilia no registro de logs em sistemas, seja ele em arquivo ou não. Segundo a documentação online do Apache Log4J, a API fornece componentes necessários para criação de um registro de log. A escolha do Log4J para este estudo de caso foi motivado por este ser um popular pacote para a linguagem de programação Java [13], sendo a linguagem de programação OO mais usada [20]. 4. Resultado e Discussão dos Resultados Os resultados do estudo apontaram que as classes Configuration e LoggerConfig do Log4J são as mais acopladas na visão dos programadores, conforme Tabela 2. Note que os participantes não tiveram acesso a nenhuma medição de acoplamento, tendo indicado tais classes por meio de inspeção de código e do diagrama das principais classes da API. Tabela 2: Classes identificadas como mais acopladas Classes Quantidade de Indicações Configuration 19 LoggerConfig 17 Logger 14 LoggerContext 12 Appender Identificação do Grau de Acoplamento pelos Programadores Dos componentes identificados como mais acoplados no sistema, alguns são interfaces. As interfaces estão anotadas com um asterisco na Figura 2. É sabido, entretanto, que o papel das interfaces é minimizar o grau de acoplamento do sistema [10]. As interfaces apóiam a modularidade de software porque elas podem ser facilmente testadas e mantidas [14]. Portanto, parece estranho o fato de programadores terem indicado interfaces como causadoras de alto acoplamento. Estas interfaces são na verdade úteis e, portanto, elas não afetam negativamente a manutenibilidade do sistema avaliado. Observa-se que os programadores juniores foram os mais cautelosos ao julgar que as interfaces podem causar um alto grau de acoplamento no sistema. Eles indicaram apenas duas interfaces. Por outro lado, programadores mais experientes indicaram três interfaces como responsáveis pelo acoplamento indesejado do sistema. 1 Resultados disponíveis em: 47

48 Figura 2: Classes mais acopladas agrupados pela experiência em programação Os dados da Figura 3 mostram que os programadores que se auto-estimaram com conhecimento avançado em Java e POO erroneamente indicaram várias interfaces relacionadas com o alto grau de acoplamento indesejado. Novamente, os participantes com menos conhecimento em OO foram bem mais cuidadosos em suas análises. Figura 3: Classes mais acopladas agrupados por conhecimento em Java e OO 4.2. Dificuldade de Identificação do Acoplamento A dificuldade encontrada pelos programadores para identificar classes com alto grau de acoplamento no sistema foi classificada como média por metade dos participantes pesquisados, como mostra a Figura 2. Percebe-se, entretanto, pela Figura 3, que apesar da dificuldade encontrada por profissionais juniores, eles tiveram maior acerto na identificação dos módulos problemáticos do sistema. Figura 2: Dificuldade de identificar o acoplamento Figura 3: Experiência de programação x dificuldade de encontrar acoplamento 4.3. Discussão sobre as Classes mais Acopladas Os participantes justificaram que conseguiram identificar as classes com alto nível de acoplamento levando em conta, por exemplo, seus relacionamentos e dependência entre classes ou módulos. Tais justificativas podem ser equiparadas às definições clássicas de acoplamento [6], tais como uso de métodos de outra classe, a instanciação de variáveis e uso de relacionamentos de herança. Através das justificativas dadas pelos 48

49 programadores, pode-se considerar que intuitivamente eles consideraram conceitos encontrados nas definições de quatro métricas de acoplamento referenciadas na literatura: CBO (Coupling between Object Classes), RFC (Response for Class), MPC (Message Passing Coupling) e ICP (Information-flow-based coupling) - apresentadas na Seção 2. Assim, este estudo conclui que estas quatro métricas aplicam os conceitos mais representativos para encontrar acoplamento no sistema Apache Log4J; e possivelmente em outros sistemas OO Melhorando a Capacidade de Manutenção do Sistema Para melhorar a capacidade de manutenção do sistema diminuindo o acoplamento prejudicial no sistema, os participantes pesquisados sugerem (i) transformar as classes mais acopladas em interfaces para diminuir o nível de acoplamento destas classes; (ii) aplicar refatoração Move Method e Move Field [12, 18] nas classes mais acopladas, movendo seus métodos e ou atributos para outras classes; (iii) dividir as classes mais acopladas em duas ou mais classes por meio da refatoração Extract Class e fazer uso da Injeção de Dependência e Inversão de Controle. A idéia básica de Injeção de Dependência é ter um objeto separado, um montador, que preenche um atributo/variável na classe de listagem com uma implementação apropriada para a interface usada [12]. Mesmo com a Injeção de Dependência executada, pode haver ainda acoplamento entre classes. Uma solução para isso é usar Inversão de Controle, a qual, trata-se de um container que armazena interfaces implementadas [12]. Com isso programa-se para interface, reduzindo o acoplamento e potencializando a qualidade do software. A interface fornece um limite entre as implementações de uma abstração e seus clientes, limita a quantidade de detalhes de implementação visível para os clientes e também especifica a funcionalidade que as implementações devem fornecer [5]. A interface então diminui o acoplamento de uma classe em relação à outra, tornando o código mais fácil de manter. 5. Ameaças à Validade da Pesquisa Alguns fatores podem comprometer o resultado do presente trabalho. Pode-se dizer que poucos programadores realizaram a análise e responderam ao questionário (30 programadores). Com base nas justificativas de encontrar as classes mais acopladas no Apache Log4J, três dos programadores não souberam responder como descobriram as classes mais acopladas. Desses trinta, doze não deram sugestões concretas e/ou não souberam responder como melhorar a capacidade de manutenção no sistema através da identificação do nível de acoplamento das classes. Além disso, 12 deles assinalaram pelo menos uma alternativa que não caracteriza acoplamento na questão sobre o que entendiam sobre acoplamento. Tais fatores podem comprometer a precisão da pesquisa. Para esta pesquisa apenas foram disponibilizados para análise o diagrama de com as principais classes da API Log4J com seus respectivos código fontes. Apesar de ser possível identificar as classes mais acopladas no sistema com estes artefatos, outras partes da documentação do projeto poderiam facilitar a identificação das classes mais acopladas. Devido à complexidade do sistema, decidiu-se restringir o estudo às suas principais classes. Também não foi utilizada nenhuma IDE ou ferramenta que facilitasse a análise do código fonte pelos participantes. O uso de uma IDE poderia deixar os 49

50 programadores mais confortáveis para a análise, facilitando sua leitura e navegação pelos arquivos. No entanto, nosso objetivo é avaliar apenas fatores humanos. Não foi realizada uma análise do código-fonte da API Log4J com ferramentas automatizadas para coletar seu índice de acoplamento e compará-la com os resultados obtidos com os participantes. De acordo com este trabalho o foco foi avaliar as métricas de acoplamento de acordo com a compreensão humana e relacioná-la as métricas disponíveis na literatura. É possível que escolha do sistema possa interferir nos resultados da pesquisa. Já que a API Log4J é um sistema limitado em relação à analise de acoplamento. Estudos com outros sistemas poderiam ter dado resultados diferentes. 6. Trabalhos Relacionados O uso de métricas para melhorar a qualidade e premeditar a manutenibilidade de projetos de software são temas bastante recorrentes em pesquisas [21, 15, 14]. Li e Henry [15] usaram as métricas de software com o intuito de analisar a manutenibilidade e qualidade de software. Eles avaliaram as métricas em dois sistemas comerciais orientado a objetos. Comparando as métricas procedurais com métricas OO, eles concluíram que existe uma forte relação entre métricas e o esforço de manutenção em sistemas orientado a objetos. Ou seja, o esforço de manutenção pode ser premeditado da combinação de métricas coletadas do código fonte [15]. Dallal [8] utlizou as métricas de coesão, acoplamento e tamanho para investigar as relações entre as classes e características de manutenção de três sistemas de código aberto escritos em Java. Utilizando a analise de regressão multivariada para construir modelos para prever a manutenibilidade das classes dos sistemas. Dubey e Rana[9] revisaram a literatura para propor um modelo de manutenibilidade baseda na relação das métricas orientada a objetos e manutenibilidade, onde explorou diversos atributos da manutenção de software. Dagpinar e Jahnke [7] realizaram um estudo de manutenibilidade de software OO analisando o histórico de versão de dois sistemas como base nas métricas orientados a objetos. Neste trabalho, os autores relacionam métricas como tamanho, herança, coesão e acoplamento buscando relação na manutenibilidade dos softwares. Os resultados indicam que as métricas de acoplamento de exportação não são bons indicadores de manutenção. Por outro lado, não houve nenhuma relação significativa entre as métricas de acoplamento indiretas e manutenção, já há a forte relação entre as métricas de importação direta de acoplamento e características manutenibilidade [7]. Briand et al. [3] apresentaram uma proposta de minimizar o acoplamento em projetos orientado a objetos, particularmente o uso da herança. Eles investigaram o impacto da qualidade de diferentes projetos em C++ [3]. Preocupados com os impactos do acoplamento sobre a manutenção do software, Burrows e outros [4] investigaram as métricas de acoplamento que fortemente impactam na qualidade de externa. Contrastando com o presente artigo, os autores exploraram o paradigma da Orientação a Aspectos. Observa-se que grande parte das métricas de acoplamento encontradas para Orientação a Aspectos são adaptações das métricas existentes da Orientação a Objetos. 50

51 7. Conclusão e Trabalhos Futuros Percebe-se neste trabalho que as métricas de acoplamento CBO, MPC, RFC, e ICP são úteis para identificar o acoplamento prejudicial a sistemas orientados a objeto. Estas métricas foram intuitivamente utilizadas pelos programadores para identificar alto nível de acoplamento no projeto avaliado neste estudo. Portanto, coletadas e quantificadas as medições das referidas métricas, caso o projetista tenha como intuito a diminuição do esforço na fase de manutenção do sistema, tenha estas métricas de acoplamento como foco à minimização dos valores medidos. Ressalta-se que o uso das interfaces deve ser fortemente aplicado nos projetos de software como mecanismo de polimorfismo e reuso, o que é excelente para a manutenção do software, quando usadas de maneira adequada a explorar os benefícios da orientação a objetos. Pela presente pesquisa, é fácil perceber que institivamente as interfaces podem ser confundidas como alta dependência causada pelo forte acoplamento. Ou seja, em um projeto de software as interfaces merecem maior atenção de seus desenvolvedores. Como maneira de se aplicar a redução do acoplamento citado acima, foram mencionadas pelos profissionais pesquisados técnicas de desenvolvimento de software, tal como o uso de interfaces, o uso de refatoração de código, tais como Extract Method e Move Method [12], injeção de dependência e inversão de controle. A qualidade do código deve ser mantido para garantir um software manutenível, para isso o bom uso da orientação a objeto e padrões de projeto devem ser aplicados. É interessante que a equipe desenvolvimento faça uma constante avaliação do nível de acoplamento do sistema através das métricas aqui relatadas, para que os esforços de refatoração sejam aplicados de maneira mais precisa. A facilidade de manutenção [2] em sistemas orientados a objetos não tem como único atributo o acoplamento. Para complementar este trabalho, um estudo sobre a coesão também deve ser feito em trabalhos futuros. A coesão pode ser definida como sendo uma medida de grau em que os elementos de um módulo permanecem juntos [2]. As arquiteturas com baixo acoplamento e alta coesão são mais fáceis de modificar, uma vez que os efeitos das alterações são mais locais se comparados com a ausência dessas qualidades. Agradecimentos Este trabalho teve apoio financeiro da FAPEMIG: Processos APQ e PPM Referências [1] Briand, L., Daly, J., Wüst, J. (1999) A Unified Framework for Coupling Measurement in Object-Oriented Systems. Transactions on Software Engineering. [2] Briand, L., Wüst, J., Lounis, H. (1999). Using Coupling Measurement for Impact Analysis in Object-Oriented Systems. In proceedings of the IEEE International Conference on Software Maintenance (ICSM). [3] Briand, L., Devanbu, P., Melo, W. (1997). An Investigation into Coupling Measures for C++. In proceedings of the 19th International Conference on Software Engineering (ICSE), pages , ACM New York, NY, USA. 51

52 [4] Burrows, R., Ferrari, F., Lemos, O., Garcia A., Taiani, F.(2010). The Impact of Coupling on the Fault-Proneness of Aspect-Oriented Programs: An Empirical Study. 21st International Symposium on Software Reliability Engineering [5] Canning, P., Cook, W., Hill, W., Olthoff, W. (1989). Interfaces for Strongly-Typed Object-Oriented Programming. In proceedings of the ACM Conference on Object- Oriented Programming, Systems, Languages and Applications (OOPSLA). [6] Chidamber S., Kemerer F. (1994) A Metrics Suite for Object Oriented Design. IEEE Transactions on Software Engineering, vol. 20, no. 6. [7] Dagpinar, M., Jahnke, J. H. (2003). Predicting Maintainability with Object-Oriented Metrics - An Empirical Comparison. In proceedings of the 10th Working Conference on Reverse Engineering (WCRE). [8] Dallal, J. (2013). Object-Oriented Class Maintainability Prediction Using Internal Quality Attributes. Journal Info. and Soft. Technology archive Vol 55 Issue 11, Nov [9] Dubey, S., Rana, A. (2011) Assessment of Maintainability Metrics for Object- Oriented Software System. ACM SIGSOFT Software Engineering Notes, Vol 36 N 5 [10] Du Bois, B., Demeyer, S., Verelst, J. (2004). Refactoring - Improving Coupling and Cohesion of Existing Code. In proceedings of the 11th Working Conference on Reverse Engineering (WCRE). pp [11] Figueiredo, E. et al. (2008) Evolving Software Product Lines with Aspects: An Empirical Study on Design Stability. In proceedings of the 30th International Conference on Software Engineering (ICSE), pp , Leipzig, Germany. [12] Fowler, M. (1999). Refactoring: Improving the Design of Existing Code, Addison- Wesley, 1th Edition. [13] Goers, R., Gregory G. (2013). Apache LOG4J, [14] Gui, G., Scott, P. (2009). Measuring Software Component Reusability by Coupling and Cohesion Metrics. Journal of Computers, vol. 4. [15] Li, W., Henry, S. (1993). Maintenance Metrics for the Object Oriented Paradigm. In proceedings of the 1st International Software Metrics Symposium. [16] Marinescu, R. (2005). Measurement and quality in object-oriented design. Software Maintenance. ICSM'05. Proceedings of the 21st IEEE International Conference on [17] Rosenberg, L. H., Hyatt, L. E. (1997). Software Quality Metrics for Object- Oriented Environments. Crosstalk Journal, April. [18] Tsantalis, N., Chatzigeorgiou, A. (2009). Identification of Move Method Refactoring Opportunities. IEEE Transactions on Software Engineering, v. 35, no. 3. [19] Wohlin, C., Runeson, P., Hös, M., Ohlsson, C. M., Regnell, B. Wesslén, A. (2012). Experimentation in Software Engineering, Springer. [20] Tiobe programming community index. Acessado em 23/06/ [21] Lanza, M., Marinescu, R. (2006). Object-Oriented Metrics in Practice. Springer Science & Business Media. 52

53 Uma Avaliação da Usabilidade de Controladores Java no Desenvolvimento de Aplicações para Redes OpenFlow Thiago N. Rodrigues 1, Rafael P. Guimarães 1 1 Centro de Pós-Graduação Faculdades Integradas Espírito-Santenses (FAESA) - Espírito Santo, ES {nascimenthiago,rguima}@gmail.com Abstract. OpenFlow networking controllers have been implemented by several parallel initiatives and on distinct programming languages. This diversity generates a potential impact on controllers usability as development platforms. This work presents a comparative analysis on the usability of different controllers which have been implemented through the Java programming language. The evaluation was conducted under the perspective of application development for the OpenFlow network. A set of usability aspects was defined and used as parameters by the analysis that was performed. Resumo. Controladores de redes OpenFlow vêm sendo implementados por meio de diversas iniciativas em paralelo e em distintas linguagens de programação. Essa diversidade gera um potencial impacto sobre a usabilidade dos controladores enquanto plataformas de desenvolvimento. Este trabalho apresenta uma análise comparativa da usabilidade de diferentes controladores implementados na linguagem Java. A avaliação foi feita sob a perspectiva do desenvolvimento de uma aplicação para rede OpenFlow. Um conjunto de critérios de usabilidade foi definido a fim de estabelecer os parâmetros da análise efetuada. 1. Introdução A introdução das redes definidas por software como novo paradigma para a arquitetura das redes de computadores tem ganhando grande projeção à medida que difunde a perspectiva de simplificação das tarefas de gerenciamento e provê uma interface de programação para a rede como um todo. Esse modelo de arquitetura baseia-se no desenvolvimento de aplicações responsáveis pela execução das diferentes tarefas de administração da rede, enquanto uma camada subjacente é responsável pela interação com o hardware (dispositivos de rede). Nesse cenário, o protocolo OpenFlow tem sido ativamente avaliado sobre aspectos como a programação de aplicações, taxa máxima de mensagens suportadas e máxima quantidade de fluxos processados por segundo. O elemento pivô dessa arquitetura - o controlador - vem sendo implementado por meio de diversas iniciativas em paralelo e em distintas plataformas de programação. Pesquisadores tem se dedicado principalmente ao aprimoramento do desempenho de controladores específicos e a demonstrarem as vantagens oferecidas por esses componentes OpenFlow sobre as clássicas switches L2 [Phemius and Bouet 2013]. 53

54 Contudo, a realidade é que cada controlador atende a necessidades independentes uns dos outros, à medida que incorporam um conjuntos similar de aspectos desejáveis a qualquer controlador. Isso resulta em esforços fragmentados de implementação de funcionalidades comuns, nas quais a principal distinção se dá sobre a linguagem de programação que suporta a escrita de aplicações. Naturalmente, essa diversidade de tecnologias e recursos disponibilizados tem impacto sobre a usabilidade dos controladores enquanto plataformas de desenvolvimento de aplicações para redes OpenFlow. Neste trabalho, diferentes controladores OpenFlow - todos implementados na linguagem de programação Java - são testados durante o processo de desenvolvimento de uma aplicação OpenFlow de referência. Um conjunto de critérios de usabilidade são elencados a fim de embasar a análise comparativa efetuada das plataformas de desenvolvimento disponibilizadas pelos controladores. 2. Controladores Java Muitas das interfaces de programação de dispositivos para redes OpenFlow foram definidas com um baixo nível de abstração em relação ao hardware básico. Logo, o atendimento de demandas comuns no âmbito da administração de rede - como prover serviços de roteamento, balanceamento de carga, monitoramento de tráfego e controle de acesso - tendem a gerar programas complexos e suscetíveis a erros. Nesse contexto, diferentes plataformas e linguagens de programação passaram a ser consideradas para a implementação de controladores OpenFlow de alto desempenho e com níveis de abstração que simplificassem o trabalho dos desenvolvedores. De acordo com [Erickson 2013], três atributos foram identificados como desejáveis para as linguagens analisadas: gerenciamento de memória, independência de plataforma e alto desempenho. Java foi uma das linguagens de programação identificadas como possível opção para o atendimento de tais requisitos. Alguns dos principais controladores implementados sobre a plataforma Java, e que serão analisados no presente trabalho, são: Beacon: controlador Java criado em 2010, amplamente usado no meio acadêmico para ensino e pesquisa e que serviu como base para a implementação do Floodlight [Erickson 2013]. Floodlight: controlador licenciado pela Apache Foundation e suportado pela comunidade de desenvolvedores, incluindo um grupo de engenheiros da Big Switch Networks [Govindraj et al. 2012]. Maestro: sistema operacional para o orquestramento de controladores de rede [Cai 2010]. Jaxon: controlador OpenFlow baseado em Java com uma interface dependente da plataforma NOX 1. IRIS: controlador OpenFlow recursivo criado pelo grupo de pesquisa do ETRI (Eletronics and Telecommunications Research Institute) [Lee 2013]. 3. Desenvolvimento com os controladores O cenário utilizado para a avaliação da usabilidade dos controladores como plataformas de desenvolvimento de aplicações, foi o de um ambiente de encaminhamento de mensagens 1 NOX é um controlador OpenFlow com suporte para as linguagens C++ e Python

55 ping, composto de 03 hosts, 01 switch e o próprio controlador analisado. À exceção do controlador OpenFlow, os demais dispositivos de rede foram emulados pela ferramenta Mininet 2 - versão em uma máquina virtual Ubuntu, de 32 bits, executando sobre o Oracle Virtual Box, versão A Figura 1 dá uma visão geral do ambiente preparado. Figura 1. Cenário de avaliação dos controladores A aplicação de referência implementada se trata de um MACTracker, que gera um log a cada endereço MAC recebido e desconhecido por ela. A Figura 2 apresenta a sequência de atividades executadas pela aplicação. Todas as implementações foram efetuadas utilizando-se o seguinte ambiente de desenvolvimento: IDE Eclipse for RCP and RAP Developers - Indigo Release Java Development Toolkit - versão Figura 2. Diagrama de atividades da aplicação MACTracker Foram definidas seis atividades para compor o processo de desenvolvimento da aplicação em cada uma das arquiteturas analisadas. Essas atividades visam dar um panorama da usabilidade dos controladores enquanto novas tecnologias de suporte à implementação de módulos para redes OpenFlow. Os seguintes passos ou atividades foram estabelecidos: 1. Importação do código do controlador para o ambiente de desenvolvimento integrado selecionado. 2 Mininet é uma plataforma de emulação de rede capaz de criar uma rede OpenFlow virtual - controladores, switches, hosts e links - em uma máquina física ou virtual. 55

56 2. Criação do novo módulo sobre a arquitetura do controlador. Nesta atividade foram elencados arquivos de configuração manipulados, classes estendidas e interfaces implementadas. 3. Configuração do log do módulo. Dado que é uma funcionalidade básica em qualquer sistema, foram identificados os arquivos de configuração necessários e as estruturas de código Java demandadas. 4. Configuração das dependências para compilação e execução tanto do controlador como do novo módulo. 5. Registro do novo módulo a fim de ser reconhecido e carregado pelo núcleo do controlador. 6. Implementação da manipulação das mensagens OpenFlow do tipo PACKET IN. 4. Avaliação dos Controladores A aplicação de referência MACTracker foi desenvolvida utilizando as arquiteturas dos cinco controladores analisados. Os critérios de avaliação elencados foram agrupados em três categorias: 1. Arquitetura: Foi feita uma análise com base nos aspectos arquiteturais necessários para o desenvolvimento de aplicações que detenham uma adequada engenharia de objetos. 2. Configuração: Avaliou-se o grau de dificuldade para configuração dos controladores num ambiente de desenvolvimento. 3. Documentação: Foi verificada a existência de documentação oficial, modelos e exemplos de implementação além de referências bibliográficas Arquitetura A análise da arquitetura dos controladores foi feita com base nos critérios propostos por [Zarras 2004]: Hierarquia: Foi feita uma análise da modelagem orientada a objetos das implementações buscando-se identificar se elementos de um mesmo nível hierárquico estão no mesmo nível de abstração. Encapsulamento: Foi verificado o isolamento do código do núcleo do controlador em relação ao novo módulo implementado. Nesse aspecto, considerou-se tanto a necessidade de modificação do núcleo para a inclusão do novo módulo, quanto o controle de acesso ao código do núcleo. Modularidade: Foi verificado se a arquitetura dos controladores é composta de elementos que fornecem serviços uns para os outros. Nesse caso, devem existir módulos autossuficientes caracterizados por alta coesão e baixo acoplamento de código. Abstração: Foi observado se os controladores implementam conceitos ou fazem uso de abordagens que abstraiam do desenvolvedor tarefas de mais baixo nível, como por exemplo a interação com a switch OpenFlow. Frameworks: A arquitetura dos controladores foi analisada quanto ao uso de frameworks que eximem os desenvolvedores de tarefas rotineiras e agregam ao código segurança e qualidade. 56

57 Esforço de registro: Foi analisado se o reconhecimento da aplicação como um módulo pelo controlador demanda a necessidade de implementação de código Java (Código de Registro), além da manipulação de arquivos de configuração (Configuração de Registro). A simples implementação de interfaces não foi contabilizada como esforço de registro. A Tabela 1 apresenta um comparativo da arquitetura dos controladores. Apesar de abstrair do desenvolvedor a interação com o código de baixo nível referente à troca de mensagens OpenFlow com a switch, e de não demandar qualquer esforço de registro do módulo no núcleo do controlador, a arquitetura do Jaxon não explora os princípios básicos do paradigma de orientação a objetos. Vale ressaltar que a complexidade de instalação de um novo módulo no Jaxon reside essencialmente na configuração da sua interação com o controlador NOX - tarefa essa facilitada pelos scripts agregados ao código. O Maestro também não faz pleno uso da modelagem orientada a objetos, contudo implementa uma hierarquia de classes no seu núcleo. Referente ao esforço de registro de novos módulos, ressalta-se o arquivo de configuração do DAG 3 demandado para a execução de qualquer aplicação no Maestro. Os controladores Beacon, Floodlight e IRIS apresentam implementações mais maduras quanto ao uso dos recursos de orientação a objetos. Embora Floodlight e IRIS não apresentem um nível de modularidade como o Beacon, a estrutura de pacotes do código permite uma visão modularizada das arquiteturas. O amplo uso de frameworks no núcleo dos controladores demanda um maior esforço para o registro de novos módulos - especialmente no caso do Beacon. Tabela 1. Comparativo das arquiteturas dos controladores Critérios de Usabilidade Beacon Floodlight Maestro Jaxon IRIS Hierarquia x x x x Encapsulamento x x x Modularidade x Abstração x x x x x Frameworks x x x Sem Código de Registro x x x 4.2. Configuração A análise dos aspectos de configuração dos controladores foi focada no esforço demandado para instalação, compilação e execução dos mesmos em um ambiente de desenvolvimento integrado. A Tabela 2 apresenta um comparativo dos aspectos listados a seguir, conforme proposto por [Valenti 2013]: Integração com IDE: Verificou-se a portabilidade do código para ambientes de desenvolvimento integrado. Neste trabalho, optou-se pela adoção da ferramenta Eclipse e foram analisados dois aspectos: se o projeto do código do controlador é nativamente reconhecível pela IDE (contém os arquivos de configuração) e se houve a necessidade de alterações na estrutura do projeto para possibilitar o desenvolvimento no ambiente integrado. 3 DAG (Directed Acyclic Graph) constitui uma abstração implementada pelo Maestro para a descrição das interações entre as aplicações controladas por ele. 57

58 Dependências: Avaliou-se a necessidade de inclusão de novas dependências externas para a compilação e execução tanto do controlador quanto do novo módulo. Além disso, foi verificada a presença de algum mecanismo para o gerenciamento das dependências. Logging: Considerou-se a complexidade envolvida na disponibilização dessa funcionalidade. Para tanto, três aspectos foram analisados: a existência de algum recurso ou estrutura de log, a necessidade de manipulação de arquivos de configuração e a necessidade de implementação de lógica em código Java para a utilização do mecanismo de log. Tabela 2. Comparativo do esforço de configuração dos controladores Critérios de Usabilidade Beacon Floodlight Maestro Jaxon IRIS Arquivos de config. da IDE x x Projeto inalterado x x x x x Sem dependências externas x x x x Gerenciador de dependências x Recurso de Log x x x Conf. Arq. Log desnecessária x x x x Os arquivos que configuram o projeto de código dos controladores no Eclipse estão presentes e preparados para uso apenas no caso dos controladores Beacon e IRIS. Logo, dentre os controladores analisados, ambos constituem os únicos com uma integração nativa com a IDE. Ainda que o Floodlight contenha um script para a geração dos arquivos descritores do código como um projeto Eclipse, a integração demanda esforço por parte do desenvolvedor, especialmente porque a geração desses arquivos pode ser executada apenas em ambiente Linux. Os códigos dos demais controladores, apesar de não conterem uma integração nativa com o Eclipse, também podem ser importados para a IDE sem qualquer esforço de configuração ou alteração na estrutura do projeto. Funcionalidades específicas da ferramenta possibilitam essa importação. Apenas o controlador Beacon contém um gerenciador de dependências - o Maven - o qual permite o adequado controle dos componentes e a automação do processo de compilação. Além disso, apenas ele faz uso de um framework OSGi (Open Service Gateway Initiative). As dependências dos demais controladores são manualmente gerenciadas, porém com as facilidades disponibilizadas por um ambiente de desenvolvimento integrado. Apenas o Jaxon demanda a inclusão de bibliotecas externas - o JNA (Java Native Access) - para que o código seja compilado, executado e utilizado no desenvolvimento de novos módulos. Beacon e Floodlight fazem uso de um framework para a disponibilização do recurso de log, o que exime o programador da necessidade de implementar código Java para o atendimento desse requisito. Embora não utilize nenhum framework disponível, o IRIS oferece sua própria implementação do mecanismo de log. Vale ressaltar que a arquitetura do Beacon demanda um esforço extra de configuração do nível de log para que, em tempo de desenvolvimento, as mensagens registradas possam ser exibidas. Maestro e Jaxon não apresentam nenhum recurso nesse sentido, exigindo o dispendioso trabalho de configurar um framework de log ou implementar a funcionalidade completa. 58

59 4.3. Documentação A avaliação da documentação dos controladores foi feita com base nos seguintes aspectos propostos por [Castro and Alves 2013]: API: Verificou-se a existência do Javadoc da API e de diagramas que disponibilizem uma visão geral da implementação do controlador. Sítio oficial: Foi verificada a existência de alguma página web oficial do controlador contendo informações básicas do projeto como: aspectos diferenciais do controlador, situações mais apropriadas para uso e contextos onde a prospecção de outras soluções seria mais adequada. Tutoriais e exemplos: Foi dada atenção à localização de modelos e exemplos de implementação, suporte oferecido por listas de discussão ou fóruns, além da existência de artigos ou livros que detalhem algum aspecto do controlador. A Tabela 3 apresenta um comparativo da documentação disponível sobre os controladores. De maneira geral, a documentação dos controladores oferece algum suporte em termos de tutoriais e exemplos para um desenvolvedor que está tendo os primeiros contatos com o código. Apesar do Beacon e Floodlight disponibilizarem o Javadoc de suas API, este contém poucas informações descritivas dos métodos, classes e interfaces. Boa parte dessa documentação é constituída apenas de uma apresentação da hieraquia de classes e das assinaturas dos métodos. Nesse aspecto, o IRIS contém um Javadoc mais explicativo. Os sítios oficiais do Beacon, Floodlight e IRIS contém exemplos detalhados de implementação e uso dos controladores. Contam ainda com o apoio das comunidades que usam e desenvolvem os controladores. Nesses aspectos, Maestro e Jaxon estão muito deficientes. A busca por artigos, livros e web sites dedicados a exemplificar os controladores revela que, especialmente nos casos dos Jaxon e IRIS, a única fonte de informação é o próprio sítio oficial. A bibliografia referente ao Maestro limita-se, basicamente, à produção acadêmica do próprio autor do controlador. Beacon e Floodlight já se encontram mais difundidos em outros trabalhos publicados. Especialmente o Floodlight conta com mais referências tratando do seu uso e funcionamento. Tabela 3. Comparativo da documentação disponível dos controladores Critérios de Usabilidade Beacon Floodlight Maestro Jaxon IRIS Javadoc da API x x x Diagramas de visão geral x x x x Sítio oficial x x x x x Modelos e exemplos x x x x x Listas e fórums x x x 5. Conclusão Diversas implementações de controladores OpenFlow já estão disponíveis nas mais diferentes plataformas. Além disso, o desempenho de uma gama significativa deles vem sendo analisado e as potencialidades de cada um, identificadas. Contudo, por se tratar do componente que agrega o caráter programável às redes definidas por software, os controladores 59

60 também demandam avaliações quanto a sua usabilidade por parte de desenvolvedores que farão extenso uso de suas arquiteturas de código. Os critérios definidos neste trabalho para a análise dos controladores, possibilitam a estruturação de uma proposta de gabarito voltada para a avaliação da usabilidade de controladores dentro do processo de desenvolvimento de aplicações para redes Open- Flow. Resulta dessa avaliação um subsídio para a seleção de controladores que mais se adequem a perfis de equipes de desenvolvedores de aplicações OpenFlow. Notadamente, por fazerem uso de um amplo conjunto de frameworks Java e por oferecerem uma arquitetura orientada a objetos, os controladores Beacon, Floodlight e IRIS oferecem um nível de usabilidade - enquanto plataformas de desenvolvimento - adequado a equipes capacitadas para explorar os recursos do Java em detrimento de uma codificação de mais baixo nível com o protocolo OpenFlow. Em contrapartida, por oferecerem uma implementação destituída de um modelo de objetos para abstração do protocolo, os controladores Maestro e Jaxon apresentam uma usabilidade orientada a desenvolvedores com capacitação para manipular as estruturas de código do OpenFlow. Finalmente, a avaliação da experiência de implementação sobre a infraestrutura de código dos controladores constitui um aporte à proposição de um modelo de arquitetura para aplicações OpenFlow construídas sobre a plataforma Java. De fato, dentre as arquiteturas analisadas, as três (Beacon, Floodlight e IRIS) - cujas implementações representam traduções de projetos de código mais elaborados - apresentam estritas semelhanças em aspectos fundamentais para uma arquitetura escalável e extensível - coesão na estrutura de pacotes, modelo hierárquico de classes e abstração das camadas de código de mais baixo nível (interação com as mensagens OpenFlow). Referências Cai, Z. (2010). Using and programming in maestro. Technical report, Rice University. Castro, L. F. S. and Alves, G. V. (2013). Análise e comparação de frameworks para edição e visualização de grafos. Anais SULCOMP, 6(1). Erickson, D. (2013). The beacon openflow controller. In Proceedings of the Second ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking, HotSDN 13, pages 13 18, New York, NY, USA. ACM. Govindraj, S., Jayaraman, A., Khanna, N., and Prakash, K. R. (2012). Openflow: Load balancing in enterprise networks using floodlight controller. Technical report, University of Colorado. Lee, B. (2013). Floodlight/IRIS Java Programming. In SDN Technology Research Division - ETRI, page 4. Phemius, K. and Bouet, M. (2013). Openflow: Why latency does matter. In Proceedings of the IFIP/IEEE International Symposium on Integrated Network Management, IM 2013, pages IEEE. Valenti, A. W. (2013). Ferramentas de desenvolvimento com boa usabilidade: é possível? In Conferência de Desenvolvimento de Software - DevCamp, pages

61 Zarras, A. (May-June 2004). A Comparison Framework for Middleware Infraestructures. Journal of Object Technology, 3(5):

62 Uma revisão sistemática para obtenção de ferramentas de identificação de maus cheiros em código fonte Allan H. M. Brandl, Evandro J. P. Pedro, Ramon S. Silva, Marco A. P. Araújo Bacharelado em Sistemas de Informação Faculdade Metodista Granbery Rua Batista de Oliveira, 1145 Juiz de Fora/MG Abstract: Refactoring is the process of changing a software system so that the external behavior of the code does not change, but its internal structure is improved. It is a disciplined way to improve the code to minimize the chance of introducing failures. In essence, when the refactoring is used the code design is improved after it was written. There are several techniques of detecting points to be refactored into a code called bad smells, and this detection can be done manually, semi-automatically or fully automatically. This work investigates some tools for identification of bad smells in source code developed in the Java language, with the goal of creating a tool for identification of bad smells in the source code. Resumo: Refatoração é o processo de alteração de um sistema de software de modo que o comportamento externo do código não mude, mas que sua estrutura interna seja melhorada. É uma maneira disciplinada de aperfeiçoar o código para minimizar a chance de introdução de falhas. Em essência, quando a refatoração é usada, o projeto do código é melhorado após ter sido escrito. Existem várias técnicas de detectar pontos a serem refatorados em um código, chamados de maus cheiros, e essa detecção pode ser feita de forma manual, semiautomática ou totalmente automatizada. Neste trabalho serão analisadas algumas ferramentas de identificação de maus cheiros em códigofonte desenvolvidos na linguagem em Java, com o objetivo de especificar e criar uma ferramenta própria. 1. Introdução Com a crescente demanda de softwares cada vez mais sofisticados com prazos e/ou recursos menores, torna-se comum encontrar software de baixa qualidade, uma vez que os mesmos muitas vezes apresentam defeitos em suas estruturas, dificultando o seu entendimento e manutenção. Para minimizar essa situação, técnicas de refatoração podem ser aplicadas no sentido de minimizar essas estruturas potencialmente problemáticas. Wangberg (2010) afirma que refatoração é um processo para modificar o código fonte para melhorar sua qualidade, sem afetar sua funcionalidade. Melhorar o código é uma tarefa importante, principalmente para redução dos custos envolvidos em manutenção de software. A identificação desses defeitos pode ser feita através da identificação de maus cheiros do código fonte, que são indícios de problemas nos mesmos. A atuação no sentido de reverter esses problemas deixa o código com uma 62

63 aparência mais limpa, facilitando seu entendimento e manutenção. Nesta pesquisa foram encontradas ferramentas que auxiliam na detecção desses maus cheiros e fornecem dicas para que técnicas de refatoração possam ser usadas na reestruturação do código fonte. Desta forma, foram selecionadas ferramentas que detectam esses maus cheiros em códigos desenvolvidos na linguagem Java. A identificação dessas ferramentas foi apoiada por uma revisão sistemática da literatura, e as ferramentas identificadas foram avaliadas para verificar o grau de cobertura aos tipos de maus cheiros indicados em Fowler (2004). Este trabalho objetiva, a partir deste estudo inicial, identificar ferramentas descritas na literatura técnica para apoio no diagnóstico de maus cheiros em código fonte na linguagem Java. Este trabalho é dividido em mais cinco seções além desta introdução. Na Seção 2 é apresentado o referencial teórico abordando ferramentas identificadas neste trabalho. A Seção 3 apresenta a revisão sistemática da literatura onde são abordados os critérios que foram utilizados para seleção dos materiais para esta pesquisa. Na Seção 4 são descritos os tipos maus cheiros em código fonte descritos na literatura técnica. Na Seção 5 são apresentadas as ferramentas encontradas e analisadas neste trabalho. Por fim, na Seção 6 são apresentadas as considerações finais e trabalhos futuros. 2. Trabalhos Relacionados Refatoração é o processo de alteração de um sistema de software de modo que o comportamento externo do código não muda, mas que sua estrutura interna seja melhorada. É uma maneira disciplinada de aperfeiçoar o código que minimiza a chance de introdução de falhas (Fowler, 2004). Glynn e Strooper (2006) indicam a falta de maturidade de ferramentas que detectam maus cheiros em código fonte, o que é confirmado por Griffith et al. (2013), que também afirmam que o processo de detecção de maus cheiros ainda é limitado e as intervenções manuais, mesmo que pequenas, são necessárias, sendo que as abordagens híbridas continuam a fornecer as melhores soluções. Para Liang (2011) a maioria das ferramentas de refatoração carecem de mecanismos que permitam ao programador especificar suas próprias pré-condições. Assim, a partir da aplicação de técnicas de revisão sistemática neste trabalho, foram identificadas diversas ferramentas relativas a técnicas de refatoração de software e, em particular, ferramentas que possibilitam a identificação de maus cheiros no código fonte, descritas a seguir. Murphy-Hill (2009) apresenta ferramentas que auxiliam na detecção de maus cheiros, com foco na análise da interface de ferramentas de refatoração, e utiliza a linguagem Java para apresentar suas análises. Em complemento, Katíc e Fertalj (2009) citam em seu trabalho critérios para avaliação de ferramentas de refatoração de código fonte, não sendo efetivamente o objetivo deste trabalho, que está focado em ferramentas de identificação de maus cheiros no código fonte. TrueRefactor (Griffith et al., 2011) é uma ferramenta de refatoração, trabalha com a linguagem Java, e seu objetivo é aumentar a compreensibilidade, manutenção e 63

64 reutilização do código-fonte do software. Por sua vez, Pessoa (2011) apresenta um plugin do Eclipse chamado SmellChecker que, através de métricas, detecta possíveis problemas em classes e maus cheiros dentre eles, como Método Longo, Lista de Parâmetro Longa, Código Duplicado, Generalidade Especulativa e Campo Temporário, dentre outros. O trabalho ainda apresenta uma funcionalidade para detectar a probabilidade de um desses maus cheiros ocorrerem no código em questão. A ferramenta JCodeCanine (Nongpong, 2012) detecta maus cheiros em programas, onde refatorações poderiam ajudar na melhoraria da qualidade do software em questão. O desenvolvedor tem opção de aplicar as refatorações sugeridas a partir da interface da própria ferramenta. Já Foster et al. (2012) apresentam a ferramenta de refatoração WitchDoctor, que detecta quando um processo de refatoração está em andamento ou completo, tendo sido avaliada junto a outras ferramentas open source. Por sua vez, PoLásek (2012) desenvolveu uma ferramenta que detecta maus cheiros através da comparação com uma base de dados pré-programada na ferramenta, possibilitando detectar maus cheiros como código duplicado e classe grande. Palomba et al. (2013) apresentam uma abordagem chamada HIST (Informações Históricas para Detecção de Cheiro), com o objetivo de detectar maus cheiros no código fonte baseado no histórico de mudanças extraídas de sistemas de controle de versões. Os tipos de maus cheiros identificados por essa ferramenta são Alteração Divergente, Cirurgia com Rifle e Hierarquias paralelas de herança. Por sua vez, Singh et al. (2013) indicam algumas ferramentas para detecção de maus cheiros em código fonte, baseados na literatura técnica. Também, Mens et al. (2013) propuseram a ferramenta Refactoring Browser of VisualWorks, um software de possibilitando ao desenvolvedor realizar análises para identificar quais refatorações seriam necessárias em uma aplicações na linguagem Smalltalk. Já Mahmoud e Niu (2013) utilizam métodos de rastreamento para identificar o desempenho de um grupo de técnicas de refatoração, identificando algum problemas como duplicações em artefatos de software. Mesmo tendo sido realizada uma revisão sistemática da literatura, descrita a seguir, não foi possível encontrar uma ferramenta de detecção de maus cheiros que seja totalmente abrangente em relação aos tipos de maus cheiros definidos por Fowler (2004) descritos mais adiante neste artigo. 3. Revisão Sistemática da Literatura A maioria das pesquisas científicas tem seu começo através de uma revisão de literatura executada de forma ad hoc. Uma revisão sistemática da literatura é uns dos meios existentes para identificar, avaliar e interpretar toda pesquisa pertinente a uma pergunta de pesquisa em particular (Kitchenham, 2004). Neste caso, relaciona-se a ferramentas de identificação de maus cheiros em código fonte Java. Questão de Pesquisa: Quais ferramentas são capazes de detectar e analisar maus cheiros em código fonte? Intervenção: trabalhos que apresentem ferramentas para identificação de maus cheiros em código fonte, voltadas para a melhoria do código fonte. 64

65 Controle: não definido. Efeito: auxiliar no desenvolvimento de uma ferramenta de refatoração. Medida de desfecho: ferramentas utilizadas para melhoria de código fonte apresentando mau cheiro. População: artigos relacionados com ferramentas de refatoração para melhor entendimento do código fonte. Problema: obter elementos para a construção de uma ferramenta para identificação de maus cheiros em código fonte, objetivando sua refatoração. Aplicação: construir uma ferramenta que possa auxiliar o desenvolvedor na melhoria da estrutura do código fonte. A Tabela 1 apresenta os critérios para a realização da revisão sistemática a partir da questão de pesquisa apresentada. Tabela 1. Critérios para a Revisão Sistemática Critério Descrição Seleção de Fontes Será fundamentada em bases de dados digitais, incluindo artigos e ferramentas de refatoração e identificação de maus cheiros. Palavras-chave Idioma dos Estudos Métodos de busca de fontes Listagem de fontes Tipo dos Artigos Critérios de Inclusão e Exclusão de Artigos Refactoring tool / Ferramenta de Refatoração; Code Smell / Cheiro de Código; Software Engineering / Engenharia de Software; Bad Smell / Mau Cheiro. Português e Inglês As fontes serão acessadas via web. No contexto dessa revisão não será considerada a busca manual Google Acadêmico Teórico, prático Os artigos devem estar disponíveis na web; devem considerar estudos de desenvolvimento e estudo de ferramentas de refatoração e identificação de maus cheiros em código fonte na linguagem Java. Processo de Seleção dos Estudos Preliminares Quatro pesquisadores aplicaram a estratégia de busca para a identificação de potenciais artigos. Os artigos identificados foram selecionados pelos mesmos pesquisadores através da leitura e verificação dos critérios de inclusão e exclusão estabelecidos. Feito isto, os pesquisadores entraram em consenso sobre a seleção dos artigos. Avaliação da Qualidade dos Estudos Primários Não foi definido um checklist para a avaliação da qualidade dos artigos. A abordagem para definição da qualidade está fundamentada na fonte para extração do material e na aplicação dos critérios de inclusão / exclusão dos estudos. Estratégia de Extração de Informação Para cada estudo selecionado, após a execução do processo de seleção, os pesquisadores extraíram os seguintes dados: Título do artigo; Autores; Fonte; Tipo de artigo; Categoria; Contexto e Tecnologia da Aplicação; Descrição das Ferramentas e Técnicas de Refatoração. 65

66 Sumarização de Resultados Os resultados foram tabulados e foram realizadas análises para definir os materiais que expliquem a revisão sistemática para identificação de ferramentas. Busca Foi necessário restringir o escopo das buscas. Essa restrição varia de acordo com a string de busca utilizada e considera o periódico no qual a busca é realizada, e o local onde as palavras chave serão procuradas (todo o texto ou abstract). A string de busca utilizada para a questão de pesquisa apresentada foi ( Refactoring tool <OR> Ferramenta de Refatoração ) <AND> ( Code Smell <OR> Cheiro de Código ) <AND> ( Software Engineering <OR> Engenharia de Software ) <AND> ( Bad Smell <OR> Mau Cheiro ). Como resultado da busca realizada no Google Acadêmico, definido na lista de fontes dos critérios para realização da Revisão Sistemática, foram encontrados 35 resultados que, após aplicados os critérios de inclusão e exclusão, 11 artigos foram selecionados. 4. Maus Cheiros Maus Cheiros, segundo Fowler (2004), são um indicativo que vale a pena examinar um possível problema no código fonte de uma aplicação, mas não indica que efetivamente exista algum problema. Existem 22 tipos de maus cheiros, descritos na Tabela 2. Tabela 2. Definição dos tipos de Maus Cheiros (Fowler, 2004) Tipos de Maus Cheiros 1. Código Duplicado: se existir código duplicado, deve-se encontrar um meio de unificálo; 2. Método Longo: método com muitas linhas de código fonte; 3. Classes Grandes: quando classes possuem muitas responsabilidades, tendem a ter muitos atributos, que tende a levar a código duplicado. 4. Lista de Parâmetro Longa: listas longas de parâmetros são difíceis de entender e usar; 5. Alteração Divergente: acontece quando uma única alteração precisa ser feita em mais de um ponto no sistema; 6. Cirurgia com Rifle: quando se faz uma alteração, fazem-se muitas pequenas mudanças em muitas classes diferentes; 7. Inveja dos Dados: métodos mais interessados em uma classe diferente daquela na qual ele se encontra; 8. Grupos de dados: dados que aparecem em conjunto deveriam ser criados em seu próprio objeto; 9. Obsessão Primitiva: presença de tipos registro; 10. Comandos Switch: código orientado a objetos normalmente não deveriam possuir comandos switch (ou case); 11. Hierarquias Paralelas de Herança: acontece ao criar uma subclasse de uma classe, também tem que criar uma subclasse em outra classe; 12. Classe Ociosa: uma classe que não tenha responsabilidades suficientes que a justifiquem, deve ser eliminada; 13. Generalidade Especulativa: presença de funcionalidades que ainda não são 66

67 necessárias; 14. Campo Temporário: atributos de objetos que recebem valores apenas em determinadas circunstâncias; 15. Cadeias de Mensagem: longa sequência de métodos entre objetos; 16. Intermediário: quando uma classe delega muitos de seus métodos para outra classe; 17. Intimidade Inadequada: classes que acessam muitas informações privadas de outras classes; 18. Classes Alternativas com Interfaces Diferentes: métodos que fazem a mesma coisa devem ter nomes (ou assinaturas) iguais; 19. Biblioteca de Classes Incompleta: representa funcionalidades disponíveis em bibliotecas de classes, mas ainda não implementadas; 20. Classes de Dados: classes que possuem apenas atributos e métodos de acesso aos atributos; 21. Herança Recusada: ocorre quando subclasses não precisam de todos os métodos e atributos herdados; 22. Comentários: excesso de comentários pode indicar um código ruim. 5. Ferramentas identificadas na literatura técnica Com base nos artigos obtidos na literatura técnica, podem-se encontrar algumas ferramentas para detecção de maus cheiros, tendo as mesmas sido utilizadas com o intuito de identificação dos tipos de maus cheiros que podem ser identificados pelas ferramentas. O resultado é apresentado na Tabela 3, considerando apenas as definições de tipos de maus cheiros descritas em Fowler (2004). Tabela 3. Ferramentas analisadas Ferramenta Tipo Linguagem Maus Cheiros Open Source JIdea IDE Java, Java Código Duplicado Sim Web JDeodorant Plugin Java Inveja dos dados, Método Longo, Sim PMD Software Java, JavaScript, XML XSL Classe Grande Código Duplicado, Método Longo, Classe Grande, Intimidade Inadequada, Classes de dados InFusion IDE Java, C, C++ Classe Grande, Classe de Dados, Código Duplicado, Inveja dos Dados e Cirurgia com Rifle InCode IDE Java, C, C++ Classe Grande, Classe de Dados, Código Duplicado e Inveja dos Dados Em seguida, procedeu-se uma análise dessas ferramentas, com o objetivo de avaliar seu funcionamento em situações reais envolvendo código fonte escrito na linguagem Java. Algumas ferramentas como TrueRefactor (Griffith et al., 2011), SmellChecker (Pessoa, 2011) e JCodeCanine (Nongpong, 2012), identificadas na revisão sistemática, tiveram que ser descartadas em função de não estarem disponíveis para uso, outros ambientes de desenvolvimento como os IDEs Eclipse e NetBeans também foram descartadas uma vez que, apesar de conterem métodos de fatoração automáticos, não detectam maus cheiros. A seguir são apresentadas as principais características das ferramentas JDeodorant (2014), PMD (2014), JIdea (Katíc e Fertalj, Sim Não Não 67

68 2009), InFusion (2014) e InCode (2014), por serem as ferramentas encontradas que mais maus cheiros se predispõem a encontrar. A partir da análise feita da ferramenta JDeodorant, pode-se observar que a ferramenta de refatoração pode ser utilizada de três maneiras no código fonte, atuando no projeto como um todo, apenas em um pacote de código fonte ou apenas em uma classe. A Figura 1 apresenta uma janela da ferramenta. Figura 1. Janela da ferramenta JDeodorant. Depois de selecionado escopo, a ferramenta busca detectar os maus cheiros no código. Depois de ter feito a varredura e detectado os maus cheiros, a ferramenta possibilita a análise do desenvolvedor que tem condição de fazer o levantamento através da ferramenta e explorar as causas dos maus cheiros identificados. Após feito o levantamento dos maus cheiros, a ferramenta possibilita a refatoração do código. Entretanto, a ferramenta identifica apenas quatro maus cheiros, sendo que apenas três são referentes aos tipos de maus cheiros definidos em Fowler (2004), que são: God Class (Classe Grande), Long Method (Metodo Longo) e Feature Envy (Inveja dos Dados). A segunda ferramenta analisada, PMD, tem a função de refatorar alguns maus cheiros, entre eles: Código Duplicado, Método Longo, Classe Grande, Intimidade Inadequada e Classes de dados. A Figura 2 exibe uma janela da ferramenta. Figura 2. Janela da ferramenta PMD. 68

69 A ferramenta é executada via prompt, indicando o caminho do código fonte a ser analisado, faz a varredura no mesmo e, em seguida, apresenta o arquivo report.html com os maus cheiros detectados e com um link onde o desenvolvedor pode analisar os problemas detectados. Como a ferramenta anterior, também não detecta um grande número de tipos de maus cheiros. A terceira ferramenta, incode, é executada diretamente de sua interface própria tendo a integração da IDE Eclipse, onde pode ser detectado dez tipos de maus cheiros mais comuns encontrados em um projeto de software. Assim, a incode (Figura 3) tem por objetivo detectar maus cheiros em projetos, incluindo Classe grande, Classe de Dados, Código Duplicado e Inveja dos Dados. Identifica, ainda, as refatorações adequadas para eliminar o problema e melhorar a qualidade do código. A ferramenta é capaz de calcular mais de cinquenta métricas de software, incluindo tamanho e complexidade, bem como medidas relacionadas a acoplamento, coesão e herança. Figura 3. Janela da ferramenta incode. A quarta ferramenta é a infusion, do mesmo desenvolvedor da ferramenta anterior, e apresenta vinte tipos de detecções de maus cheiros, incluindo Classe Grande, Classe de Dados, Código Duplicado, Inveja dos Dados e Cirurgia com Rifle. Essa ferramenta é mais completa e robusta, e apresenta mais de sessenta diferentes métricas de código, fornecendo interpretação a problemas reais, em vez de apenas sintomas de mau design, como a incode. As visões do infusion apresentam níveis de interatividade, o que facilita a compreensão do sistema (Figura 4). Figura 4. Janela da ferramenta infusion. 69

70 6. Considerações Finais e Trabalhos Futuros A partir da Revisão Sistemática da Literatura realizada, pôde-se ter uma compreensão melhor das aplicações de ferramentas de refatoração, tais ferramentas auxiliam na manutenção e organização do código fonte, tornando-o melhor e de fácil entendimento para programadores e analistas. Através da pesquisa realizada neste artigo foram encontrados poucos resultados, além de poucas ferramentas de refatoração de código disponíveis gratuitamente para uso ou ainda ativas, e menos ainda aquelas que identificam maus cheiros no código fonte. Como trabalhos futuros, dando continuidade a essa pesquisa, será desenvolvida uma ferramenta que detecte o um maior número de maus cheiros em código fonte Java, oferecendo ao desenvolvedor uma ferramenta que possa auxiliar na melhoria da estrutura do código fonte, auxiliando na identificação de problemas nessa estrutura. A pesquisa aqui apresentada servirá de subsídio para definição dos requisitos da ferramenta a ser construída. Agradecimentos Os autores agradecem à Faculdade Metodista Granbery pelo apoio ao desenvolvimento desta pesquisa. Referências Foster, R., Griswold, S., Griswold, G., Lerner, S. WitchDoctor: IDE Support for Real- Time Auto-Completion of Refactorings. Proceedings of the 34th International Conference on Software Engineering, Pages , Fowler, M. Refatoração - Aperfeiçoando o Projeto de Código Existente. Porto Alegre: Bookman, Glynn, E., Strooper, P. Evaluating Software Refactoring Tool Support, Proceedings of the 17th Australian Software Engineering Conference. Sydney, Australia, pp , Griffith, I., Wahl, S., Izurieta, C. TrueRefactor: An Automated Refactoring Tool to Improve Legacy System and Application Comprehensibility. ACM / IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM), Griffith, I., Izurieta, C. Design Pattern Decay: An Extended Taxonomy and Empirical Study of Grime and its Impact on Design Pattern Evolution. ACM / IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM), InCode. Disponível em Acessado em 12/07/2014. InFusion. Disponível em Acessado em 12/07/2014. JDeodorant. Disponível em Acessado em 14/05/

71 Katíc, M., Fertalj, K. Towards an Appropriate Software Refactoring Tool Support. Proceedings of the 9th WSEAS International Conference on Applied Computer Science, Kitchenham, B. Procedures for Performing Systematic Reviews, Keele Technical Report SE0401 and NICTA Technical Report T.1, Liang, Y. Code Refactoring Under Constraint, Department of Computer Science in the Graduate School of The University of Alabama Disponível em Mahmoud, A., Niu, N. Supporting Requirements Traceability through Refactoring. International Requirements Engineering Conference (RE), st IEEE, pages 32 41, Mens, T., Tourwe, T., Munoz, F. Beyond the Refactoring Browser: Advanced Tool Support for Software Refactoring. Proceedings Sixth International Workshop on Principles of Software Evolution, pages 39-44, Murphy-Hill, E. Programmer-Friendly Refactoring Tools. Disponível em Nongpong, K. Integrating Code Smells - Detection with Refactoring Tool Support, The University of Wisconsin-Milwaukee, Palomba, F., Bavota, G., Di Penta, M., Oliveto, R., De Lucia, A. Poshyvanyk, D. Detecting Bad Smells in Source Code Using Change History Information. 28th IEEE/ACM International Conference on Automated Software Engineering,pages , Pessoa, T. A Semi-automatic Approach to Code Smells Detection. Disponível em PMD. Disponível em Acessado em 14/05/2014. PoLásek, I. Anti-pattern Detection as a Knowledge Utilization. Disponível em Acessado em 14/05/2014. Singh, A., Naiya, Narayan, E. To improve the modularity of the software in the code smell using Aspect-Oriented Programming (AOP). International Journal of Advanced Research in Computer Engineering & Technology (IJARCET) Volume 2, Issue 4, Wangberg, R. A Literature Review on Code Smells and Refactoring. Disponível em

72 GraphVCS: Uma Abordagem de Visualização para Apoio à Compreensão de Repositórios de Controle de Versão Thiago Amorim Pereira 1, Marcelo Schots 1,2 1 Instituto de Matemática e Estatística Universidade do Estado do Rio de Janeiro Rua S. Francisco Xavier, 524, 6º andar Rio de Janeiro, RJ Brasil 2 Programa de Engenharia de Sistemas e Computação (PESC) COPPE/UFRJ Caixa Postal Rio de Janeiro, RJ Brasil thiagoainfo@gmail.com, schots@cos.ufrj.br Abstract. During the software lifecycle, especially in parallel/distributed development, there are several users working on a given project. In this scenario, it is common to use version control systems for a better control of software evolution. However, understanding how such evolution takes place is not a trivial task. The GraphVCS approach aims to provide a better comprehension of the evolution of versioned software projects, by using visualization resources and techniques. Such techniques facilitate the identification of potential problems and the execution of tasks that involve comprehension needs. For illustrating the use of the approach, an example scenario is presented. Resumo. Durante o ciclo de vida do software, especialmente no desenvolvimento paralelo/distribuído, há diversos usuários trabalhando sobre um determinado projeto. Neste cenário, é comum o uso de sistemas de controle de versão para um melhor controle da evolução do software. No entanto, compreender como esta evolução ocorre não é uma tarefa trivial. A abordagem GraphVCS objetiva prover uma melhor compreensão da evolução de projetos de software versionados, utilizando-se de recursos e técnicas de visualização. Tais técnicas facilitam a identificação de potenciais problemas e a realização de tarefas que envolvem necessidades de compreensão. Para ilustrar a utilização da abordagem, um cenário de exemplo é apresentado. 1. Introdução O desenvolvimento de software ocorre de maneira evolutiva e corretiva. Sendo assim, ocorrem mudanças durante o seu ciclo de vida. Quando artefatos de software são adicionados ou alterados, estes podem introduzir problemas no projeto, como perda de funcionalidades ou até interrupção total do serviço. A equipe de desenvolvedores de um software constantemente inclui novos artefatos de software ou altera os existentes, às vezes desfazendo alterações. Particularmente, quando há desenvolvedores trabalhando em um mesmo arquivo, a concorrência pode se tornar um problema [Tichy 1988]. Devido a isto, o uso de Sistemas de Controle de Versão (SCVs) é frequente no desenvolvimento de software, pois mantém o registro da evolução do projeto por meio do histórico das alterações [Conradi & Westfechtel 1998]. No entanto, algumas informações que podem ser relevantes para a compreensão da evolução e para análises post-mortem acabam ficando dispersas. Tal situação se agrava no cenário de 72

73 desenvolvimento paralelo/distribuído, no qual a gestão das informações geradas durante o processo de desenvolvimento requer um controle ainda maior. É comum que projetos de maior porte possuam grandes quantidades de operações de commit em SCVs, o que pode acarretar em uma sobrecarga de informação (information overloading). Sendo assim, faz-se necessário o uso de ferramentas e mecanismos complementares a fim de realizar o devido acompanhamento desta evolução, visando à representação de informações da evolução estrutural do projeto. Neste sentido, de forma a facilitar o entendimento e diminuir a sobrecarga de informações, pode-se fazer uso de conceitos e técnicas de visualização de software, que permitem expressar informações complexas por meio de abstrações visuais, reduzindo o esforço de compreensão por parte do usuário [Diehl 2007]. A partir de tais recursos, membros de equipes de desenvolvimento (gerentes de projeto, desenvolvedores, analistas de qualidade etc.) podem obter uma melhor compreensão de situações relacionadas à evolução do projeto. Algumas situações incluem verificar se um ramo é alvo de muitas operações de commit o que pode gerar um esforço razoável de junção, ou identificar não conformidades com relação aos planos de gerência de configuração. Neste contexto, foi apresentada em [Pereira & Schots 2011] uma versão preliminar (como trabalho em andamento) da abordagem GraphVCS, voltada para a visualização e compreensão da estrutura de repositórios de controle de versão. O presente artigo apresenta algumas evoluções decorrentes do andamento da pesquisa, e está organizado da seguinte forma: a Seção 2 apresenta alguns conceitos sobre SCVs e visualização de software. A Seção 3 aborda uma análise de trabalhos relacionados. A Seção 4 apresenta uma visão geral do GraphVCS, incluindo um exemplo de utilização. Por fim, a Seção 5 conclui o artigo, apresentando as considerações finais. 2. Contextualização 2.1. Sistemas de Controle de Versão A Gerência de Configuração de Software (GCS) introduz uma série de atividades e procedimentos aos ambientes de desenvolvimento de software, para que o desenvolvimento e evolução de sistemas grandes e complexos sejam gerenciados [Tichy 1988]. O objetivo da GCS é estabelecer e manter a integridade dos produtos de trabalho de um processo ou projeto e disponibilizá-los aos envolvidos [Softex 2011]. Os SCVs apoiam a GCS combinando procedimentos e ferramentas para gerenciar as diferentes versões de artefatos que são criados e modificados durante o ciclo de vida do software, possibilitando assim evoluir tais artefatos de forma controlada [Collins-Sussman et al. 2011]. Por este motivo, são considerados a parte mais importante da GCS [Conradi & Westfechtel 1998]. Os SCVs possuem algumas características que variam conforme cada implementação. Estas características estão relacionadas, por exemplo, à arquitetura, ao controle de concorrência e ao modelo de versionamento de arquivos, existindo assim várias soluções disponíveis com recursos de versionamento de arquivos. Uma análise detalhada destes recursos é apresentada em [Pereira 2014]. O entendimento dessas estruturas pode não ser trivial na medida em que o histórico do repositório cresce, trazendo dificuldades de análise e auditoria neste histórico. Com isso, a utilização de 73

74 técnicas de visualização aplicadas a essas estruturas pode trazer facilidades em termos de aumento da compreensão e auxílio em tarefas de auditoria Visualização de Software O desenvolvimento de software envolve um conjunto de artefatos cujas estruturas, comportamentos e evolução são usualmente complexos, o que requer a utilização de recursos que facilitem sua manipulação e entendimento. Técnicas da visualização visam facilitar estas tarefas, pois permitem expressar informações complexas por meio de abstrações visuais, reduzindo o esforço de compreensão por parte do usuário [Diehl 2007]. Existem diversas técnicas de visualização presentes na literatura e em sistemas de software. Uma sumarização destas técnicas pode ser vista em [Oliveira 2011]. Algumas técnicas pertinentes ao escopo deste trabalho são descritas a seguir. Uma técnica bastante comum é o zoom, que consiste em obter detalhes sob demanda, ampliando ou reduzindo os elementos visuais conforme a interação do usuário [Diehl, 2007]. Esta técnica se mostra particularmente útil quando o objeto visualizado está em escala muito pequena, dificultando a exploração de detalhes [Oliveira 2011]. Como forma complementar ao zoom, pode-se interagir com os objetos por meio de movimentações em escala constante (ou panning), normalmente acionada por recursos de arrastar e soltar (drag-and-drop) em visões panorâmicas, permitindo a movimentação de objetos para dentro e para fora da área de foco [Oliveira 2011]. Outra técnica, chamada drill-down, pode ser utilizada para a obtenção de detalhes adicionais sobre um determinado elemento conforme a interação do usuário. Diferentemente do zoom, tal técnica está associada usualmente a uma hierarquia. Para lidar com um grande volume de informação, a técnica de filtragem também pode ser utilizada, exibindo apenas o que é relevante ao contexto do usuário, facilitando a visualização e diminuindo a sobrecarga de informação. Esta técnica pode ocorrer por meio de um pré-processamento (desde que seja possível saber de antemão o que deve ser filtrado) ou sob demanda (em tempo real, normalmente utilizada no contexto de tarefas específicas) [Oliveira 2011]. Os critérios de filtragem podem ser obtidos, por exemplo, por meio de uma busca. Para destacar os resultados da busca, pode ser utilizado o realce (highlight), também considerado um tipo de filtragem. Outra técnica, visão geral + detalhe (overview + detail), é caracterizada pela exibição simultânea de uma visão geral (overview) e uma visão detalhada (detail) de um mesmo espaço de informação, sendo que cada visão ocupa um espaço de apresentação distinto [Cockburn et al. 2008]. Em função da separação física entre ambas as visões, os usuários interagem com cada uma delas separadamente; contudo, normalmente as ações em uma dada visão refletem imediatamente na outra [Oliveira 2011]. 3. Trabalhos Relacionados Os SCVs normalmente oferecem a opção de consulta ao histórico de mudanças dos itens de configuração versionados por meio de uma interface no formato de linha de comando, exigindo do usuário um nível avançado de conhecimento para o entendimento. Além disso, torna-se difícil e custoso analisar o histórico do repositório por meio de um grande volume de informações textuais, especialmente em projetos colaborativos e com muitas alterações. 74

75 Atualmente, existem diversos sistemas de software que fornecem uma interface visual (Graphical User Interface GUI) aos usuários de forma a permitir que estes possam interagir com os repositórios de SCVs. É possível efetuar operações de GCS (como commit, merge, checkout, entre outras) através da GUI de tais ferramentas, evitando que o usuário tenha que utilizar linhas de comando. Dentre essas ferramentas, algumas possuem recursos de visualização de repositórios, no qual o histórico dos repositórios é obtido e apresentado por uma abstração visual (grafo), permitindo uma compreensão visual da evolução do projeto. Algumas ferramentas encontradas em uma revisão da literatura são apresentadas na Tabela 1 em um quadro comparativo. Tabela 1 Quadro comparativo entre abordagens de visualização de repositórios de SCVs Funcionalidades / Abordagens Subversive Revtree Plugin Gitk Tortoise SVN Smart SVN KDE SVN GitHub Técnica de zoom Busca (por data, autor, revisão e mensagem de commit) Indicações de junções Técnica de panning / dragand-drop Técnica de highlighting Técnica de overview + detail Técnica de drill-down Legenda: Implementa Não implementa Implementa parcialmente Conforme este quadro, pode-se observar que somente o TortoiseSVN implementa a técnica de zoom, porém esta é limitada, pois é realizada através de opções de controle (na forma de botões) localizadas no painel superior do painel. Com isso, torna-se difícil focar em uma determinada área de interesse, sendo necessário aplicar o zoom por um botão e depois mover o grafo pela barra de rolagem, ou vice-versa. Tal forma de interação é trabalhosa especialmente em projetos com muitas revisões. Somente a ferramenta Revtree Plugin implementa a técnica de highlighting para filtragem; as outras abordagens somente ocultam os dados quando estes não atendem o critério de busca. Com isso, informações necessárias para o entendimento do contexto da evolução do projeto ficam ocultadas se não atendem o critério de busca, o que dificulta a compreensão da evolução. Outra observação é que somente duas ferramentas implementam a técnica de drag-and-drop; com isso, não é possível interagir com a 75

76 visualização das demais, que utilizam o recurso de barra de rolagem para exibir o restante das informações, existindo a limitação de não poder combinar com outras técnicas (como o zoom, por exemplo). Todas as ferramentas citadas implementam a técnica de overview + detail, sendo um recurso comumente requisitado para obter os detalhes de uma determinada revisão. Cabe ressaltar que duas das ferramentas, além de não implementarem o zoom, também não contêm uma ferramenta de busca, dificultando ainda mais a localização de revisões desejadas pelo usuário. As limitações apontadas motivaram o desenvolvimento da abordagem apresentada no presente trabalho, que utiliza técnicas de visualização de software para auxiliar equipes de desenvolvimento na compreensão do histórico de evolução do projeto. 4. A Abordagem GraphVCS A abordagem GraphVCS visa proporcionar uma representação gráfica da estrutura dos repositórios de SCV, a fim de facilitar a análise dos mesmos, bem como a realização de auditorias, complementando assim ferramentas clientes de SCVs com recursos que facilitem a compreensão. As estruturas dos repositórios são representadas na forma de grafo, onde cada operação de commit é representada como um vértice, enquanto as arestas representam os ancestrais diretos das revisões (direcionadas para a versão consecutiva). A ferramenta (homônima) concretiza e implementa a abordagem proposta. A Figura 1 demonstra a tela exibindo o histórico do repositório e outras opções, dividida em três áreas principais: (1) área de exibição do grafo, (2) área de busca e (3) gráfico de atividades no decorrer do tempo. Todas estas áreas são passíveis de redimensionamento, a fim de se ajustarem ao objetivo de análise do usuário. Figura 1 - Tela principal do GraphVCS Na tela principal, é possível observar o grafo de revisões, no qual cada vértice representa um commit realizado. O grafo é organizado de forma que cada ramo e os commits pertencentes a ele são associados a uma posição X (horizontal) e Y (vertical) na área de exibição. A ordem da esquerda para direita é de acordo com a data e sequência do commit. A fim de identificar a que ramo ou marco de projeto (tag) estão 76

77 associadas as revisões, o nome do ramo é exibido no primeiro vértice de cada linha de desenvolvimento. Na Figura 1 é possível observar um vértice de nome trunk, representando a linha principal em repositórios SVN. As cores nos vértices são utilizadas para diferenciar os três tipos de ramos existentes: a cor verde representa o ramo principal, a cor azul indica os ramos de desenvolvimento paralelo, a cor amarela ilustra os marcos de projetos e a cor avermelhada representa a exclusão de um ramo, como pode ser observado na Figura 2. Figura 2 Representação de ramos e marcos no GraphVCS Como não é possível exibir de forma clara o histórico completo na área de exibição do grafo, o GraphVCS permite que o usuário interaja utilizando recursos de panning (via drag-and-drop) e zoom, exibindo mais arestas existentes. A Figura 3 demonstra o resultado da utilização da técnica drag-and-drop, tendo arrastado a visualização exibida na Figura 1 para o lado esquerdo (com isso, exibindo a continuidade do histórico). Também é possível observar a existência de um ramo chamado test, criado a partir da revisão identificada pelo número 9. Figura 3 - Resultado da utilização da técnica de drag-and-drop Em SCVs, para cada operação de commit realizada, é possível adicionar um comentário para informar o que foi modificado. Além disso, a cada revisão, são associados o autor, a data da operação e a lista de arquivos alterados. Para acessar essas informações no GraphVCS, é necessário posicionar o dispositivo de interação (e.g., mouse) sobre a revisão desejada. Com isso, essas informações são exibidas em um painel abaixo da área do grafo. Na Figura 4, é possível observar o usuário posicionando 77

78 o mouse sobre a revisão 6, sendo exibidas as informações da revisão. A técnica de drilldown é utilizada para navegar para a exibição do conteúdo do arquivo alterado, permitindo uma visão de detalhes conforme a necessidade do usuário. Figura 4 - Exibição de detalhes de uma revisão Em algumas situações, é necessário saber em qual revisão ocorreu um determinado evento (por exemplo, uma correção de bug). Com o intuito de facilitar esta identificação, o GraphVCS implementa uma ferramenta de busca, permitindo ao usuário filtrar a exibição de informações conforme sua relevância, utilizando-se de filtros como busca por mensagem de commit; por usuário e por intervalo de data ou de revisões. A busca por intervalo de revisões pode ser utilizada na tela inicial da aplicação, por meio da tela de login ou durante a exibição do grafo. A Figura 5 ilustra um exemplo de utilização da ferramenta de busca, no qual o usuário informa a palavra linux no campo de texto para buscas por mensagem de commit, destacando assim as revisões que possuem esse comentário associado. Para destacar as revisões encontradas pela ferramenta de busca, a ferramenta permite que o usuário utilize dois tipos de destaque (individual ou simultaneamente): Realce (Highlight), o qual diferencia as revisões encontradas colorindo os vértices em tonalidade avermelhada, e Busca Visível (Visible Search), que oculta as revisões que não atendem aos critérios de busca. Para ativar os destaques, as opções estão localizadas no menu superior, chamado Filters. Figura 5 - Demonstração do filtro de destaque Highlight O GraphVCS possui um gráfico que representa o volume de atividades efetuadas no repositório, em termos do número de operações de commit realizados no decorrer do tempo. Este gráfico (ilustrado no canto direito da Figura 5) é atualizado de forma consistente com a área de exibição do grafo (implementando a técnica overview + 78

79 detail), de forma que apenas o intervalo sendo exibido nesta é representado no gráfico em questão. Por meio deste gráfico, é possível, por exemplo, que um gerente de configuração verifique se os usuários estão utilizando o SCV de forma inadequada por exemplo, identificando um projeto em que um desenvolvedor permanece por um longo período sem realizar a operação de commit, e em um dado momento, o mesmo efetua um commit com uma grande quantidade de arquivos (e, potencialmente, diversas alterações). Tal cenário é descrito em [Werner et al. 2010] Exemplo de utilização Para ilustrar um exemplo de utilização da ferramenta GraphVCS, foi utilizado o repositório do projeto de código-aberto Ruby 1, que utiliza o SVN como sistema de controle de versão. O repositório contém revisões, 207 tags, 32 ramos e 104,276 MB. Para fins de ilustração neste artigo, é considerada uma equipe fictícia, da qual fazem parte uma analista de qualidade e dois desenvolvedores, que seguem um plano de GCS em suas atividades. Outros exemplos são descritos em [Pereira 2014]. Cabe ressaltar que os dados utilizados nos exemplos são reais, porém os cenários são fictícios. Portanto, os participantes mencionados não tomaram as decisões descritas nos exemplos. Apesar de serem cenários fictícios, estes representam situações que podem ocorrer em alguns projetos, especialmente quando existe um programa de gerência de configuração bem estabelecido. Além disso, tais cenários são considerados simples, sendo apresentados apenas para fins de ilustração, mas assumindo-se que representam situações em que as tarefas apresentadas seriam de alta complexidade. A analista de qualidade, ao analisar o resultado dos testes de liberação, identificou que uma solicitação de correção não havia sido realizada, apesar de registrada no sistema de controle de mudanças como resolvida. Visando identificar o que teria ocorrido, utiliza-se o GraphVCS como ferramenta de apoio. A partir da solicitação da analista, um desenvolvedor optou por utilizar a busca para identificar em qual ramo (branch) ocorreu a mudança. Com isso, ele filtrou a busca pelo desenvolvedor responsável (ksbt) e informou o código do pedido de alteração #263 gerado pelo sistema de controle de mudanças 3, como ilustrado na Figura 6. Figura 6 - Utilização da busca por autor e por mensagem de commit O desenvolvedor optou por utilizar o recurso Visibility Search para ocultar as revisões que não atendem aos critérios de busca. Após efetuar a busca, o desenvolvedor Instância do repositório no dia 08/04/ Neste cenário, assume-se que o plano de GCS estabelece que o desenvolvedor deve informar na mensagem de commit o código do pedido de alteração. 79

80 executou a ação de zoom-out para obter uma visão geral das revisões que atendem o critério de busca, como ilustrado na Figura 7. Figura 7 - Utilização do zoom-out após a realização da busca Após o desenvolvedor localizar a revisão desejada, ele selecionou o arquivo modificado na revisão; com isso, por meio da ação de drill-down, o GraphVCS exibe o conteúdo do arquivo. O desenvolvedor pode observar que o autor do commit não realizou todas as mudanças necessárias para atender ao pedido de alteração, e pode assim solicitar uma ação corretiva. 5. Considerações Finais A abordagem GraphVCS visa utilizar técnicas de visualização para prover maior interação com o usuário, evitando sobrecarga cognitiva. A visualização provida pela ferramenta serve como apoio a tarefas específicas relacionadas ao entendimento da evolução de projetos versionados em SCVs. Algumas limitações atuais identificadas são listadas a seguir: Lentidão em projetos com muitas revisões: apesar de a ferramenta não apresentar falhas no teste realizado com o projeto Ruby, houve casos em que foram necessários mais de 10 minutos para construir o grafo, devido à quantidade de revisões do projeto; isto pode ser parcialmente contornado configurando a busca por um intervalo menor de revisões; Ausência de agrupamentos de revisões: se o repositório contiver um grande intervalo de ramos, os usuários terão que realizar muitas ações de drag-anddrop, o que pode ser evitado por meio de agrupamentos (clustering) 4 ; Dificuldades de visualização em alguns casos de junção em repositórios SVN: a ferramenta realiza o mapeamento do intervalo das revisões (através de metadados associados às pastas) que participaram da junção; assim, em alguns repositórios, há uma grande quantidade de arestas, o que dificulta a visualização; Com base nas limitações e nas observações no decorrer da utilização do GraphVCS, algumas informações relevantes para a melhoria da ferramenta devem ser consideradas como trabalhos futuros, a saber: (i) estender o suporte a outros SCVs; (ii) 4 Esta técnica consiste em dividir os dados em um número de subconjuntos ou grupos, de acordo com determinadas medidas de similaridade [Oliveira 2011]. 80

81 prover suporte a busca por expressões regulares; (iii) implementar a técnica de agrupamento, para atender aos casos em que existe um grande intervalo de revisões; e (iv) diminuir o tempo de resposta da aplicação para obter os dados do repositório, com utilização de cache. Além disso, pretende-se avaliar a abordagem utilizando projetos industriais ou de código aberto, com o intuito de verificar se houve vantagens na utilização da ferramenta em termos de tempo (e.g., diminuição da curva de aprendizagem) e identificação de problemas em auditoria, com base na execução de tarefas por parte de potenciais usuários. Por meio da avaliação, pode ser possível também observar se diferentes perfis de desenvolvedores estão relacionados à utilização de diferentes recursos do GraphVCS ou ao tempo empregado em tarefas associadas a compreensão. Referências Cockburn, A., Karlson, A., Bederson, B. B. (2008). A review of overview+detail, zooming, and focus + context interfaces, ACM Computing Surveys (CSUR), v. 41, n. 1, 31p. Collins-Sussman, B., Fitzpatrick, B. W., Pilato, C. M. (2011). Version Control with Subversion, Conradi, R., Westfechtel, B. (1998). Version Models for Software Configuration Management, ACM Computing Surveys, v. 30, June, pp Diehl, S. (2007). Software Visualization: Visualizing the Structure, Behaviour, and Evolution of Software, Springer. Oliveira, M. S. (2011). PREVIA: Uma abordagem para Visualização da Evolução de Modelos de Software, Tese de Mestrado, COPPE/UFRJ, Rio de Janeiro, Brasil. Pereira, T. A. (2014). GraphVCS: Uma Abordagem para a Visualização e Compreensão de Repositórios de Controle de Versão, Projeto Final de Curso, Universidade do Estado do Rio de Janeiro (UERJ). Pereira, T., Schots, M. (2011). GraphVCS: Uma Abordagem para a Visualização e Compreensão de Repositórios de Controle de Versão, Workshop Brasileiro de Visualização de Software (WBVS 2011), Congresso Brasileiro de Software: Teoria e Prática (CBSoft 2011), São Paulo, Brasil, Setembro, pp Softex (2011). Guia de Implementação Parte 2: Fundamentação para Implementação do Nível F do MR-MPS, MPS.BR Melhoria de Processo do Software Brasileiro, n. 2011, Julho. Tichy, W. F. (1988). Tools for Software Configuration Management, International Workshop on Software Version and Configuration Control, Grassau, Germany, January, pp Werner, C., Corrêa, C., Santos, R., Schots, M., Murta, L., Lyra, F. (2010). Adoption of Configuration Management in the Industry: Strategies and Lessons Learned, CLEI Electronic Journal, 13, 2, pp

82 Uma ferramenta para priorização de requisitos baseada no algoritmo de PageRank Silvester Emanoel da Silva 1, Marcelo Werneck Barbosa 1 1 Instituto de Ciências Exatas e Informática Pontifícia Universidade Católica de Minas Gerais. Belo Horizonte. Minas Gerais silvester_silva@hotmail.com, mwerneck@pucminas.br Abstract. Prioritizing requirements is one of the Requirements Engineering activities. The activity consists of ranking requirements according to their priorities in order to make decisions related to the project s total scope, inconsistencies among requirements and yet support project planning. Different prioritization approaches exist. This work presents the implementation of a requirements prioritization tool based on an adaptation of the PageRank algorithm. Results show that the tool leads to prioritization in few iterations and generates few and acceptable invalid positions. Resumo. Priorizar requisitos é uma das atividades da Engenharia de Requisitos. A atividade consiste em ordenar os requisitos de acordo com sua prioridade para decidir em relação ao escopo total do projeto, inconsistências entre requisitos e ainda apoiar o planejamento do projeto. Diferentes abordagens de priorização existem. Este trabalho apresenta a implementação de uma ferramenta de priorização de requisitos baseada em uma adaptação do algoritmo de PageRank. Os resultados dos testes mostram que a ferramenta alcança priorização em poucas iterações e com número de posições inválidas aceitáveis. Aluno: Silvester Emanoel da Silva Orientador: Marcelo Werneck Barbosa Categoria: Trabalho de Conclusão de Curso de Graduação Estágio do Trabalho: Concluído 1. Introdução Com o aumento da complexidade dos softwares, tornou-se necessário mudar a maneira como eles são construídos. As compreensões das atividades envolvidas no desenvolvimento de sistemas tiveram de que se tornar melhores e mais amplas (Alencar, 2012). O conceito de Engenharia de software foi inicialmente proposto em uma conferência que discutia a crise de software. O desenvolvimento de tecnologias e os recursos de hardware possibilitavam o desenvolvimento de produtos de software muito mais complexos do que eram produzidos. Pressman (1995) diz que uma primeira definição de engenharia de software foi proposta por Fritz Bauer na primeira grande conferência (NAU69) dedicada ao assunto: O estabelecimento e uso de sólidos princípios de engenharia para que se possa obter 82

83 economicamente um software que seja confiável e que funcione eficientemente em máquinas reais. Segundo Sommerville (2007), talvez o maior problema que é enfrentado no desenvolvimento de sistemas de software grandes e complexos, seja o da Engenharia de Requisitos. Ela está associada com a definição do que o sistema deve fazer suas propriedades emergentes desejáveis e essenciais e as restrições quanto à operação do sistema e quanto aos processos de desenvolvimento de software. Por ser uma atividade executada manualmente pelos stakeholders, Firesmith (2004) explicita que a priorização de requisitos é um processo subjetivo e tendencioso e Davis (2003) menciona que possíveis incoerências de planejamento no projeto são consequências de uma má priorização que pode resultar em perda de investimento. Uma das atividades da Engenharia de Requisitos é a priorização. (Karlsson, Wohlin e Regnell, 1998) aconselham definir o fator de relevância que priorizará os requisitos. A questão é, sobretudo, definir por onde começar o software. O que é mais importante? O que será feito primeiro? Quais as interdependências entre os requisitos de software? Em projetos de software complexos há centenas de requisitos, e muitas vezes as partes interessadas tem opiniões diferentes sobre quais requisitos são mais importantes e por onde o projeto deve iniciar. Por ser uma atividade executada manualmente pelos envolvidos, (Firesmith, 2004) explicita que a priorização de requisitos é um processo subjetivo e tendencioso. (Davis, 2003) menciona que possíveis incoerências de planejamento no projeto são consequências de uma má priorização que pode resultar em perda de investimento. O algoritmo do PageRank (Page et. al, 1999) foi criado pelos fundadores do Google, Larry Page e Sergey Brin. Este algoritmo faz uma análise da rede e dá pesos numéricos para cada elemento de acordo com os elementos que ele aponta e é apontado. O PageRank é baseado em algumas ideias básicas: se uma página é apontada por muitas páginas, então esta página provavelmente é importante; se uma página é apontada por páginas importantes, mesmo que ela não seja apontada, provavelmente ela é importante; a importância de uma página uniformemente e propagada pelas páginas apontadas por ela. Assim como ocorre na web, a especificação de requisitos pode ter uma abordagem similar no que tange à priorização dos requisitos. O objetivo geral deste trabalho foi implementar a ferramenta REPRIS (REquirements PRIoritization System) para priorização de requisitos baseado no algoritmo de PageRank. O restante deste artigo está organizado da seguinte maneira. A Seção 2 descreve os conceitos relacionados à priorização de requisitos e o algoritmo de PageRank, bem como apresenta a utilização deste algoritmo no contexto de priorização de requisitos. A Seção 3 apresenta a ferramenta REPRIS. A Seção 4 descreve os resultados obtidos enquanto a Seção 5 apresenta os trabalhos futuros e conclusões. 83

84 2. Referencial Teórico 2.1. Priorização de Requisitos A elicitação e análise de requisitos são atividades em que engenheiros de software trabalham com clientes e usuários finais do sistema para aprender sobre o domínio da aplicação, quais serviços o sistema deve fornecer o desempenho esperado do sistema, restrições de hardware etc (Sommerville, 2011). Na Figura 1, é apresentado um modelo generico de um processo de elicitação e análise de requisitos. As atividades de processo são: Figura 1 Exemplo Matriz de Rastreabilidade 1. Obtenção de requisitos: é a coleta dos requisitos através da iteração com os stakeholders; 2. Classificação e organização de requisitos: esta atividade agrupa os requisitos relacionados e os organiza em conjuntos coerentes; 3. Priorização e negociação de requisitos: esta atividade está relacionada à priorização dos requisitos, ou seja, organiza-los de maneira hieraquica de acordo com sua importãncia e procura à resolução de conflitos por meio de negociação; 4. Documentação de requisitos: os requsitos são documentados e colocados na próxima volta do expiral. 84

85 Na Figura 1, é possível ver que o processo de elicitação e análise de requisitos é um processo ciclico com realimentação continua a cada iteração entre uma atividade e outra. Todas as atividades deste processo são de extrema importância no processo de desenvolvimento de software, no entanto neste trabalho será focado apenas à atividade de priorização de requisitos Priorização de Requisitos Segundo (Sommerville, 2011), inevitavelmente quando várias partes interessadas estão envolvidas, os requisitos entram em conflito. A priorização dos requisitos é uma das atividades da Engenharia de Requisitos e consiste em ordenar os requisitos para determinar prioridades, resolver conflitos e ainda, auxiliar o planejamento do projeto. Conforme (Paula Filho, 2009), um enunciado dos requisitos é priorizado se cada requisito é classificado de acordo com a respectiva importância e estabilidade. A estabilidade estima a probabilidade de que o requisito venha a ser alterado no decorrer do projeto, com base na experiência em projetos correlatos. Os requisitos podem ser classificados de acordo com um dos seguintes graus: Requisito essencial: Requisito o qual não for atentido, o produto torna-se inaceitavel; Requisito desejável: requisito que aumenta o valor do produto e sua ausência pode ser relevante em caso de necessidade; Requisito opcional: requisito que será atendido apenas se houver disponibilidade de recursos (prazo, orçamento, etc.), e será atendido após o atendimento dos demais requisitos. Uma das atividades de priorização adotada pelas empresas é a comparação em pares, que consiste em formar pares com todos os requisitos existentes no sistema e, em seguida, comparar se um requisito tem ou não maior prioridade sobre seu par. Essa comparação deve ser realizada com todos os pares de requisitos existentes e pode demandar muito tempo PERT/CPM Segundo a descrição de Kerzner (2009), a rede PERT/CPM é a representação gráfica de uma sequência lógica do planejamento, na qual são exibidas as dependências das atividades do projeto e o tempo estimado para que cada uma delas seja concluída. Essa representação gráfica é realizada por meio de um grafo que consiste em nós ou blocos, e arestas ou linhas orientadas. Nesse grafo, os nós representam as atividades e as arestas representam as relações de dependência entre essas atividades. O tempo estimado de cada atividade é representado com um número localizado em cada uma de suas arestas. De acordo com essa estrutura de grafo, se uma atividade A aponta para uma atividade B, 15 significa que B é a próxima atividade a ser executada após a conclusão de A (Silva, 2011), como pode ser visto na Figura 2. 85

86 2.4. Algoritmo de Page Rank Figura 2 Rede Pert/COM O algoritmo do PageRank foi proposto por (Page et al, 1999) para medir a importância relativa das páginas web, como um método para calcular a classificação das páginas, com base no grafo da web. Quando foi proposto o algoritmo do PageRank, havia uma estimativa que o grafo da web, possuía cerca de 150 milhões de nós (páginas) e 1,7 bilhões de bordas (links). Cada uma dessas páginas aponta para outros links (outedges) e há links que apontam para ela (inedges). Figura 3 Estrutura de links da web Há uma grande variação entre as páginas web em relação ao número de páginas que apontam para elas. Geralmente as páginas que possuem muitos apontamentos, são mais importantes do que as páginas que possuem menos. O PageRank provê um método sofisticado para contagem de apontamentos. Um aspecto interessante é que apenas o número de apontamentos que uma página possui não indica o grau de importância desta página. O algoritmo também considera se a página é apontada por outra páginaimportante Algoritmo de Page Rank Conforme descrito no trabalho de Page et al. (1999), o PageRank, pode ser calculado pela seguinte fórmula: 86

87 Onde pode ser descrita da seguinte maneira: PR(P) é o PageRank da página P; d é o fator de amortecimento que indica a probabilidade de usuário que está clicando nos links, se cansar e mudar de página. Seu valor pode variar entre 0 e 1. Normalmente, usa-se o seu valor igual a 0,85; PR(Pi) é o rank da página Pi que aponta para a página P; C(Pi) é a quantidade de páginas que a página Pi aponta; PR(Pn) é o rank da enésima página que aponta para a página P; C(Pn) é quantidade de páginas que a enésima página aponta. Este é um algoritmo recursivo, que computa o rank de todas as páginas a cada iteração. O PageRank é finalizado quando o fator de convergência for um valor pouco significativo, ou seja a diferença entre o rank atual e o rank anterior, for um valor praticamente nulo. Conforme experimentos do trabalho de Page et al. (1999), com uma base possuindo em média 322 milhões de links convergindo, há uma tolerância de 52 iterações para se ter uma fator de convergência razoável. O gráfico da Figura 4 mostra o fator de convergência de acordo com o número de iterações para uma base de 161 e 322 milhões de links. Figura 4 Relação da taxa de convergência e quantidade de iterações para milhões de links 2.5. Trabalhos relacionados Em (Silva, 2011), é apresentada uma abordagem para reduzir o empirismo existente durante a priorização de requisitos, aplicando o algoritmo PageRank em um grafo representativo das dependências entre requisitos. Um estudo de caso foi apresentado e 87

88 comparações foram realizadas entre as abordagens de priorização por votação acumulativa, com o uso de PERT/CPM e por meio do PageRank. Após comparar os resultados dessas técnicas, foi concluído que o PageRank efetua a priorização consistentemente e permite que os envolvidos realizem ajustes nas prioridades dos requisitos, diferentemente das outras duas técnicas. 3. A Ferramenta de Priorização Implementada Neste trabalho, foi criada uma ferramenta que realize a priorização de requisitos em uma plataforma Web. Para isto, foi escolihida a plataforma Asp.net, framework 4.5, linguagem de programação C# e como IDE de desenvolvimento, o Visual Studio Apesar de este trabalho ser baseado no trabalho de (Silva, 2011), esta é uma nova implementação que possui como base o algortimo do PageRank e tem o trabalho de (Silva, 2011) apenas como refêrencia para comparações, com implementações distintas. O trabalho de (Silva, 2011) foi feito na linguagem Java utilizando a IDE de desenvolvimento Eclipse e possui uma interface menos intuitiva de ser utilizada. A entrada para a ferramenta é uma matriz de rastreabilidade de requisitos. A matriz é uma planilha na qual os requisitos são dispostos nas linhas e colunas. Para que o usuário não tenha que construi este padrão, foi desenvolvido um template desta matriz, que pode ser baixado na própria ferramenta. O preenchimento desta planilha é bem simples. A matriz de responsabilidades funciona identificando a relação entre os requisitos. O valor 1 representa a relação entre o requisito de uma linha e o requisito de uma coluna. O valor 0 indica que não há relação entre os requisitos. A Figura 5 exibe uma matriz sendo preenchida. Figura 5 Exemplo Matriz de Rastreabilidade Após o preenchimento da matriz de rastreabilidade de requisitos, a mesma deve ser submetida ao algoritmo PageRank implementado na ferramenta. O usuário o faz através de uma interface de upload de arquivo. Após a ferramenta executar os cálculos, é exibida uma tabela com os requisitos priorizados e sua respectiva pontuação, e no final da página a quantidade de iterações que foram necessárias para execução dos cálculos para esse conjunto de requisitos, conforme exibido na Figura 6. 88

89 Figura 6 Resultado da Priorização na Ferramenta 4. Resultados e testes Foram feitos testes com base nos dados do trabalho de (Silva, 2011). Este trabalho contou com um estudo de caso baseado em um sistema de Petshop online, para o qual foi feita a priorização de requisitos utilizando os métodos PERT/CPM, Votação Cumulativa, implementação do PageRank na linguagem Java. As diferenças entre este trabalho e o descrito em (Silva, 2011) são: a implementação da ferramenta com uma interface gráfica, a possibilidade de uso de um template de matriz de rastreabilidade como entrada para a ferramenta e a visualização dos dados de maneira mais agradável, enquanto (Silva, 2011), a entrada de dados é feita por um arquivo no formato.txt. Com relação ao algoritmo, (Silva,2011) usou uma estrutura de matrizes para armazenar a relação entre os requisitos e também as pontuações. Já neste trabalho foi criada uma classe que possui o identificador do Requisito e uma lista com os requisitos que o mesmo aponta. Pra armazenar as pontuções, foi utilizada a estrutura Dictionary do C#, em que a chave é o identificador do requisito e o objeto é outra classe que possui a pontuação inicial e atual do requisito. Em resumo, a criação desta ferramenta consiste em traduzir uma matriz de rastreabilidade no excel, em um grafo e executar os cálulos do PageRank baseado neste grafo. O critério para avaliar a eficiência dos métodos foi o número de posições inválidas. Entende-se por posição inválida aquela em que o requisito ficou em uma posição antecessora a algum requisito que o mesmo depende, pois, um requisito não pode ser codificado antes que suas dependências estejam prontas. Sendo assim, no trabalho de (Silva, 2011), o método PERT/CPM não apresentou nenhuma posição inválida. A implementação do PageRank apresentou 4 posições inválidas e o método de Votação Cumulativa apresentou 14 posições inválidas. Nos testes realizados neste trabalho, a ferramenta criada apresentou 5 posições inválidas para os mesmos requisitos, no entanto, os resultados foram bastante semelhantes aos resultados do metodo PERT/CPM, e com um próximidade maior desses resultados do que a implementação realizada por (Silva, 2011), mas divergiram 89

90 bastante da implementação de (Silva, 2011), como pode ser visto na Tabela 1. Em contrapartida, para o algortimo implementado nesta ferramenta, foram necessárias apenas 8 iterações para se chegar ao resultado final, enquanto no trabalho de (Silva, 2011), foram necessárias 12 iterações, ou seja, 50% a mais de iterações. A Tabela 1 ilustra os resultados da priorização, com os três métodos testados. PageRank(Mirna) PERT/COM PageRank(Silvester) Posição Requisito Pontuação Posição Requisito Posição Requisito Pontuação 1º R27 5,993 1º R27 1º REQ27 1,683 2º R19 2,418 2º R19 2º REQ19 0,924 3º R25 2,218 3º R25 3º REQ25 0,575 4º R28 1,469 4º R28 4º REQ28 0,563 5º R26 1,433 5º R05 5º REQ05 0,470 6º R09 1,420 6º R09 6º REQ26 0,418 7º R07 1,420 7º R07 7º REQ09 0,410 8º R11 1,307 8º R26 8º REQ11 0,391 9º R13 1,247 9º R10 9º REQ15 0,370 10º R10 1,240 10º R08 10º REQ14 0,370 11º R08 1,240 11º R12 11º REQ13 0,341 12º R05 1,161 12º R11 12º REQ07 0,322 13º R15 1,127 13º R13 13º REQ10 0,309 14º R14 1,127 14º R14 14º REQ08 0,309 15º R12 0,966 15º R15 15º REQ16 0,260 16º R16 0,790 16º R16 16º REQ18 0,247 17º R18 0,247 17º R17 17º REQ12 0,240 18º R24 0,183 18º R18 18º REQ24 0,184 19º R17 0,180 19º R21 19º REQ17 0,180 20º R06 0,178 20º R22 20º REQ06 0,179 21º R21 0,174 21º R06 21º REQ21 0,175 22º R22 0,173 22º R20 22º REQ20 0,173 23º R20 0,173 23º R04 23º REQ22 0,173 24º R04 0,165 24º R23 24º REQ04 0,166 25º R23 0,157 25º R24 25º REQ23 0,157 26º R03 0,150 26º R03 26º REQ01 0,150 27º R02 0,150 27º R01 27º REQ03 0,150 28º R01 0,150 28º R02 28º REQ02 0,150 Tabela 1 Comparação dos resultados dos métodos avaliados Os itens marcados em vermelho são as posições inválidas. Ao observar a quantidade de posições inválidas em cada método, conclui-se que o método PageRank implementado em (Silva, 2011) teve 14,3% de posições inválidas, já o método PageRank implementado neste artigo teve 17,86% de posições inválidas. 5. Conclusões e Trabalhos Futuros O objetivo geral deste trabalho foi criar uma ferramenta para priorização de requisitos baseado no algoritmo de PageRank. Em comparação com outro trabalho (Silva, 2011), o 90

91 trabalho apresentou bons resultados, pois foram necessárias menos iterações para alcançar o resultado final. Como trabalhos futuros, pretende-se: Realizar estudos para reduzir ou eliminar as posições inválidas; Acrescentar mais funcionalidades que contemplem outros processos da Engenharia de Requisitos à ferramenta, como o registro de mais informações referentes a requisitos que sejam relacionadas à priorização; Melhorar a interface com o usuário; 6. Referências Davis, A. The art of requirements triage. Computer, IEEE, v. 36, n. 3, p. 42{49, 2003 Firesmith, D. Prioritizing requirements. Technology, Citeseer, v. 3, n. 8, p , 2004 Karlsson, Joachim (1997). A Systematic Approach for Prioritizing Software Requirements. Linköping Studies in Science and Technology Dissertation No Karlsson, J.; Wohlin, C.; Regnell, B. An evaluation of methods for prioritizing software requirements. Information and Software Technology, Elsevier, v. 39, n , p.939{947, ISSN Page, Lawrence and Brin, Sergey and Motwani, Rajeev and Winograd, Terry (1999) The PageRank Citation Ranking: Bringing Order to the Web. Technical Report. Stanford InfoLab. Paolo Boldi, Massimo Santini, Sebastiano Vigna, PageRank as a function of the damping factor, Proceeding WWW '05 Proceedings of the 14th international conference on World Wide Web, Pages , 2005 Pfleeger, Shari Lawrence. Engenharia de Software: Teoria e Prática, 2ª edição. São Paulo, Brasil : Prentice Hall, Pressman, Roger S. Engenharia de Software, 7ª edição. São Paulo, Brasil: Makron Books, Silva, Mirna Paula. Uso do Algoritmo PageRank para Priorização de Requisitos de Software. Trabalho de diplomação entregue ao Departamento de Ciência da Computação da Pontíficia Universidade Católica de Minas Gerais, Dezembro 2011 Sommerville, Ian. Engenharia de Software, 8ª edição. São Paulo, Brasil: Prentice Hall,

92 Análise de Dependência em Software Java Considerando Relacionamento com Banco de Dados Jaqueline A. Moreira 1, Kecia A. M. Ferreira 1 1 Centro Federal de Educação Tecnológica de Minas Gerais Departamento de Computação Av. Amazonas, 7675, Nova Gameleira - Belo Horizonte-MG jaquelinecomp@gmail.com; kecia@decom.cefetmg.br Abstract. The assessment of the change impact in software systems require the dependency analysis, that is a non-trivial task. Existing works propose methods and tools for dependency analysis in software systems. However, most of them considers only the dependences among software modules, and disconsider the dependences among the software modules and the databases that they use. This is an important limitation to apply those proposals in real scenarios of Software Engineering. This paper presents a work that aims to contribute in this context, extending a tool, called Connecta so that it will be able to perform the dependence analysis in Java software systems by considering the dependences among classes and tables of MySQL databases. We have proposed and tested a method to detect the usage of tables of MySQL databases by classes of Java programs, by automatically inspecting their bytecodes. The algorithm was introduced in Connecta so that the resulting tool reports the nature of dependences among classes of the system, including those that are due to use of a common table of a database. Resumo. A avaliação do impacto de modificação em software demanda analisar as dependências existentes entre os módulos do software, o que não é uma tarefa trivial. Trabalhos prévios propõem recursos para análise de dependência em sistemas de software. Todavia, a maioria deles considera somente as dependências entre módulos de software, desconsiderando as dependências entre os módulos de software e as tabelas em bancos de dados que elas usam. Esta é uma limitação importante para aplicar esses métodos e ferramentas previamente propostas em cenários reais de Engenharia de Software. Este artigo apresenta um trabalho que visa contribuir nesse contexto, estendendo uma ferramenta, denominada Connecta, para que ele seja capaz de realizar a análise da dependência em software Java, considerando as dependências entre classes e tabelas de bancos de dados MySQL. Um método foi desenvolvido e testado para detectar o uso de tabelas de banco de dados MySQL por classes de programas Java, inspecionando automaticamente seus bytecodes. O algoritmo foi incluído em Connecta de modo que a ferramenta reporta a natureza das dependências entre as classes do sistema, incluindo aquelas decorrentes da utilização de uma tabela em comum de uma base de dados. Aluna: Jaqueline A. Moreira Orientadora: Kecia A. M. Ferreira Categoria: Trabalho de Conclusão de Curso de Graduação em desenvolvimento 92

93 1. Introdução A manutenção de software é a fase do ciclo de vida de um software que é iniciada a partir da entrada em produção, ou seja, quando o cliente já está utilizando o produto. Essa fase tem como objetivo incluir ou modificar funcionalidades, melhorar a usabilidade ou corrigir defeitos que não foram identificados durante a fase de desenvolvimento [Sommerville et al. 2003]. Sustentar um sistema funcionando em perfeitas condições e sem erros é um desafio para as empresas, pois a atividade de manutenção é a mais onerosa do ciclo de vida de um software, sendo um dos problemas mais críticos da Engenharia de Software [Meyer 1988]. Realizar manutenção em grandes sistemas é uma tarefa complexa, pois o trabalho envolve um conhecimento amplo da aplicação, tais como requisitos e arquitetura, além das competências técnicas nas ferramentas utilizadas em sua construção. Normalmente, softwares de grande porte possuem uma alta variedade de aplicações e integrações com outros softwares. Conhecer como as aplicações se interrelacionam e suas dependências, por exemplo com banco de dados, é essencial para realizar a manutenção, pois a modificação de um módulo do sistema pode gerar impactos em outras partes. Entender essas relações é uma tarefa que consome tempo. Atualmente, existem algumas ferramentas de apoio à análise de dependências em softwares. Essas ferramentas têm como objetivo explorar e analisar como as classes, pacotes e aplicações se relacionam, permitindo a visualização e a extração de informações sobre essas dependências. Alguns exemplos dessas ferramentas são Dependency Finder [Finder 2008], Dependency Analysis [Analysis 2014], Connecta [Ferreira et al. 2006] e Analizo [Terceiro et al. 2010]. Entretanto, tais ferramentas não analisam a dependência entre uma aplicação e seu acesso ao banco de dados. Esse tipo de análise é útil para a realização das tarefas manutenção de software em cenários reais, pois a alteração de uma classe que usa uma determinada tabela do banco de dados pode afetar o funcionamento de outras classes que utilizem a mesma tabela. Este trabalho propõe o projeto e implementação de um algoritmo capaz de analisar as dependências que existem entre as classes de softwares Java considerando o acesso a banco de dados MySQL 1 e que utilizam a API JDBC 2. Esse algoritmo foi acrescentado à ferramenta Connecta [Ferreira et al. 2006], que atualmente analisa conectividade em software Java, porém não considera relacionamento com banco de dados. Este artigo está organizado da seguinte forma: Seção 2 apresenta os trabalhos relacionados, abordando as principais ferramentas existentes para análise de dependência em software, bem como pesquisas realizadas anteriormente que definem métodos para análise de dependência; Seção 3 apresenta o método proposto para identificar a dependência entre classes pelo uso de tabelas em comum em banco de dados MySQL; Seção 4 relata os resultados obtidos até então; Seção 5 traz as conclusões, as etapas seguintes necessárias para a conclusão do trabalho e a indicação de trabalhos futuros

94 2. Trabalhos Relacionados A manutenção de software é a atividade de melhoria e correção de problemas de um sistema já desenvolvido. Essa atividade envolve tanto a mudança no software para correção de defeitos quanto a implementação de novas funcionalidades. De acordo com Sommerville [Sommerville et al. 2003], existem três tipos de manutenção: Manutenção para reparos de defeitos do software: consiste na correção dos defeitos dos sistemas. Esses defeitos podem ser técnicos ou de regras de negócio. Em geral, a correção de erros relativos aos requisitos são mais caras pois envolve conhecimento do sistema ou reestruturação do código. Manutenção para adaptar o software a um ambiente operacional diferente: é necessário quando algum aspecto do ambiente é alterado, como por exemplo, o hardware ou o sistema operacional. Nesse caso, é necessário modificar o software para que ele se torne adequado ao novo ambiente. Manutenção para adicionar funcionalidade ao sistema ou modificá-la: ocorre quando há alteração nos requisitos ou novas funcionalidades são agregadas ao sistema. É o tipo de manutenção mais realizada em software em geral. Seja qual for o tipo de manutenção realizada, ela pode gerar impactos em várias partes do software. Visando contornar a complexidade da tarefa de análise de dependências e de estimativa de impacto de modificações em software, alguns trabalhos têm sido desenvolvidos. Li et al[li et al. 2010] definiram um método para avaliar a propagação de mudança em software orientados a objetos baseado em simulação de impacto de mudanças. A execução do método proposto requer a construção de um grafo, o qual representa as relações de dependência entre as classes. Desta forma, eles mostram que para avaliar as propagações de mudança é necessário obter as relações de dependências de um sistema. Geipel e Schweitzer [Geipel and Schweitzer 2012] realizaram um estudo empírico de que classes fortemente dependentes aumentam os riscos de ocorrerem mudanças simultâneas. Ferreira [Ferreira et al. 2011] definiu um modelo de predição de amplitude da propagação de modificações em software. O modelo utiliza a análise de dependência para determinar a propagação de mudanças, considerando os aspectos arquiteturais do software e número de módulos que serão inicialmente modificados. Existem também ferramentas que realizam analise estrutural de dependência em software, dentre elas as seguintes: Dependency Finder: é um software livre que efetua análise de código Java compilado. É formado por um conjunto de ferramentas que têm como objetivo efetuar análise de dependência, coletar métricas e comparar diferença entre versões [Finder 2008]. Code Pro Analytix: foi desenvolvido pelo Google Developer Groups e tem por objetivo fornecer recursos que auxiliam na qualidade e manutenção do software [Analysis 2014]. Um dos recursos da ferramenta que está relacionado a esse trabalho é o Dependency Analysis, que é uma ferramenta de análise de 94

95 dependência em software Java. Dependency Analysis exibe os relacionamento de várias formas: dependências entre projetos, pacotes, tipos ou os três níveis simultaneamente. A visão de dependência pode ser usada também para escolher o tipo de análise e gerenciar a lista dos projetos. Analizo: é uma ferramenta livre que permite a análise de dependência e a coleta de métricas de software [Terceiro et al. 2010]. Essa ferramenta é multi-linguagem, pois analisa codigo fonte em C, C++ e Java. Connecta: é uma ferramenta para análise de softwares desenvolvidos em Java. Essa ferramenta implementa o modelo MACSOO (Modelo de Avaliação de Conectividade em Sistemas Orientados por Objetos) proposto por Ferreira et. al [Ferreira et al. 2006]. Esse modelo que visa avaliar a conectividade em sistemas orientados a objetos e conta com a coleta de métricas específicas relacionadas a estabilidade, conectividade, herança, dentre outras. Connecta também realiza uma análise em pontos de impacto do sistema, como o ocultamento de informação, acoplamento e coesão entre as classes. Esses trabalhos prévios propõem métodos e ferramentas que realizam uma análise estática do código fonte. Porém, essa análise não considera as dependências existentes com um elemento externo e que também esteja acoplado ao sistema, como por exemplo o banco de dados. Grande parte dos softwares comerciais utilizam banco de dados, portanto conhecer as dependências entre um sistema e seu acesso ao banco de dados também é importante para a avaliação de impactos de modificações em software. O presenta trabalho trabalho visa avançar os recursos de análise de dependência em software, considerando acesso do software a um elemento externo, nesse caso o banco de dados. Baseando-se no algoritmo de conectividade de Connecta [Ferreira et al. 2006], foi desenvolvido um novo algoritmo capaz de identificar a conectividade entre classes Java e seus acessos a uma instância de banco de dados MySQL. 3. Detecção de Dependência entre Classes pelo Uso de Banco de Dados A proposta deste trabalho é a construção de um algoritmo que seja capaz de capturar dependências entre classes Java que acessam as mesmas tabelas de um mesmo banco de dados.a análise de dependência realizada pelo algoritmo se baseia na ideia de que classes que acessam a mesma tabela, seja por consulta, inserção, alteração ou exclusão de registros, são consideradas dependentes, pois acessam os mesmos dados. Por exemplo, caso uma classe insira um registro inválido, as classes dependentes também estarão acessando esse mesmo registro podendo levar a um erro no sistema. Desta forma, considerando o esquema mostrado na Figura 1, há uma dependência da classe A para a classe B, porque A usa diretamente um recurso de B. As classes B e C usam a Tabela 1 em comum de uma instância de um banco de dados. Uma modificação em uma dessas classes, então, pode causar uma modificação na outra quando a modificação inicial causar impacto no dados compartilhados por elas via tabela do banco de dados. O objetivo do método proposto neste trabalho é identificar esses tipos de dependências indiretas. Em geral, nas tarefas de manutenção de software, identificar a causa de erros dessa natureza é uma das tarefas da equipe de manutenção de software. Essa atividade exige uma análise do código fonte para identificar essas dependências com o objetivo de indicar 95

96 Figura 1. Esquema de dependência entre classes. a classe responsável pela alteração ou inserção do registro. A análise de dependência consiste em uma prática frequente para identificar causas de erros em software. O algoritmo desenvolvido neste trabalho foi criado para análise de classes que utilizam conexão ao banco de dados MySQL com a API JDBC. Esse algoritmo será incluído na ferramenta Connecta [Ferreira et al. 2006] que atualmente realiza análise de dependência em software orientado a objetos, entretanto não considera acesso ao banco de dados. O motivo da escolha de Connecta [Ferreira et al. 2006] foi porque essa ferramenta realiza análise de código fonte Java e também possui uma arquitetura bem documentada e flexível a modificações. Nesta seção será descrito a lógica e a tecnologia utilizada para a implementação do algoritmo Algoritmo de Análise de Dependências O algoritmo proposto foi implementado na linguagem Java, utilizando-se a IDE Netbeans 3 versão O algoritmo baseia-se na análise diretamente do bytecode da classe. A escolha dessa implementação se deve ao fato de fornecer maior portabilidade em relação as versões Java e também por existir bibliotecas que auxiliam a manipulação de bytecodes. Para a implementação foi utilizado a biblioteca Apache Commons BCEL (Byte Code Engineering Library) 4 que fornece uma API simples para se decompor, analisar, criar e manipular bytecodes Funcionamento O algoritmo recebe como entrada uma lista de classes a serem analisadas e realiza uma triagem das classes. A triagem consiste em verificar se a classe é persistente, ou seja, se possui comandos de inserção, seleção, alteração ou exclusão no banco de dados. Caso ela seja persistente, o algoritmo prossegue a análise, caso contrário, essa classe é descartada e passa-se, então, para a próxima classe da lista. A análise consiste em obter os métodos da classe em uma lista, que é fornecida por BCEL. Cada método é percorrido com o objetivo de se encontrar as tabelas acessadas por ele. Antes de percorrer o método, o algoritmo verifica se ele é persistente. Caso positivo, análise prossegue. Caso contrário, ele é descartado e obtém-se o próximo método da lista. O método é percorrido analisando-se as strings contidas no seu corpo até encontrar comandos de acesso ao banco de dados. Para obter as tabelas acessadas pelo método,

97 Tabela 1. Formatos de consultas interpretados pelo algoritmo. Formato Exemplos Consultas simples sem cláusula where select * from tabela; ou select * from tabela order by data desc; Consultas simples com cláusula where select * from tabela where id=1 order by data desc; ou com álias select * from tabela t1 where id=1 order by data desc; Consultas com cruzamento de tabelas select * from tabela1 t1, tabela2 t2,tabela3 where t1.id = t2.id and t2.id=tabela3.id order by data desc; Consultas utilizando inner join select * from tabela1 t1 inner join tabela t2 on t1.id=t2.id inner join tabela3 t3 on t3.id=t2.id order by data desc; verifica-se qual tipo de acesso o método realiza ao banco. Os acessos podem ser de seleção, inserção, alteração ou exclusão. Existem muitas formas de realizar comandos de select em um banco de dados. O algoritmo é capaz de capturar grande parte das dependências pelo comando de seleção. As consultas devem estar no formato em que o algoritmo seja capaz de interpretar. Neste trabalho, o algoritmo desenvolvido é capaz de capturar nos formatos mostrados na Tabela 1. O algoritmo é capaz de capturar dependências em qualquer comando de inserção, alteração e exclusão. As tabelas acessadas pelas classes analisadas são mapeadas em uma estrutura de dados que relaciona a tabela com as classes que a acessam. A estrutura de dados escolhida foi uma HashMap onde a chave é o nome da tabela do banco de dados e cada chave mapeia uma listas com as classes que acessam essa tabela. No final do processamento, o conteúdo da estrutura de dados é exibida com as relações da tabela e as classes que são dependentes por acessar o mesma informação. O Algoritmo 1 mostra a estrutura de implementação e lógica adotada para o desenvolvimento da análise de dependência entre classes considerando o uso de banco de dados. 4. Resultados Preliminares Para avaliação do algoritmo, utilizou-se um software Java com acesso ao banco de dados MySQL para a realização da análise de dependência. Esse software foi desenvolvido como trabalho acadêmico pela autora durante uma disciplina de Programação Orientada a Objetos. O sistema denominado Icebook consiste em uma rede de relacionamento social onde cada usuário pode adicionar e visualizar amigos, enviar recados, entre outras funcionalidades. Além disso o sistema conta com um administrador responsável por gerenciar o cadastro de usuários e fornecer permissões de acesso. Os relacionamentos 97

98 Algorithm 1: Algoritmo para detecção de dependências entre classes que acessam a mesma tabela Input: lista de classes a serem analisadas Output: Estrutura de dados com as classes dependentes por tabela for classe listaclasses(v) do if classe é persistente then listam etodos obterm etodos for metodo listam etodos(v) do tabela encontradependencia() adiciona relação da tabela com a classe na estrutura de dados end end end existentes entre as tabelas do banco de dados e o software são os seguintes: A tabela usuario é acessada pelas classes AmigoBD e UsuarioBD; A tabela pessoa é acessada pelas classes AmigoBD, UsuarioBD e LoginBD; A tabela administrador é acessada pelas classes UsuarioBD e LoginBD; A tabela recado é acessada pela classe RecadoBD; A tabela amizade é acessada pela classe AmigoBD e UsuarioBD. Essas classes foram analisadas pelo algoritmo desenvolvido nesse trabalho e o resultado da análise é exibido na Figura 2. O diagrama da Figura 3 mostra o relacionamento entre as classes do software e as tabelas do banco de dados. O diagrama das tabelas foi extraído via engenharia reversa para prover uma melhor comparação com os resultados reportados pelo algoritmo. Neste teste, o algoritmo atingiu o objetivo esperado, pois foi possível mapear as dependências entre as classes do software Icebook com as respectivas tabelas do banco de dados. Atualmente, o trabalho está em desenvolvimento, em fase final. Foi realizado outro teste com um sistema maior, no qual também observamos o perfeito funcionamento do algoritmo. A ferramenta Connecta foi estendida com a inclusão do algoritmo, passando a ser capaz de apoiar a análise de dependência entre classes de software Java e tabelas de banco de dados MySQL. Figura 2. Relacionamento de dependência extraído pelo algoritmo 98

99 Figura 3. Esquema de dependência entre classes. 5. Conclusão O problema de análise de dependência de módulos em software tem sido objeto de estudo de muitos trabalhos. Algumas ferramentas têm sido também desenvolvidas com o propósito de fornecer recursos que possam facilitar a análise de dependências. Solucionar o problema de análise de dependências é importante porque isso pode contribuir significativamente para redução do custo de manutenção de software, uma vez que essa análise é essencial para, por exemplo, estimar e gerenciar os impactos de modificações em software. A maior parte desses trabalhos considera as dependências estáticas e diretas entre os módulos. Todavia, muitos softwares comerciais e de grande porte fazem uso de banco de dados, e os usos que os módulos dos softwares fazem das tabelas em banco de dados podem também influenciar o impacto de modificação. Desta forma, é importante que análise de dependências considere também esses tipos de relacionamentos. Visando contribuir nesse contexto, o presente trabalho propõe um método para identificar as dependências entre as classes programas Java que são decorrentes do uso 99

100 que as classes fazem de tabelas em comum em instâncias de banco de dados MySQL. O método foi incluído na ferramenta Connecta, que já faz a análise de dependências estáticas e diretas entre classes de software Java, mas não considerava o relacionamento do software com banco de dados. No atual estágio do trabalho, o método foi desenvolvido e testado, e a extensão da ferramenta Connecta foi realizada. Este artigo descreveu o método proposto e parte dos testes realizados. Este trabalho concentra-se na linguagem Java e no banco de dados MySQL. A escolha de Java se deu por ela ser uma linguagem amplamente utilizada na indústria para o desenvolvimendo de software. Optou-se por analisar uso de banco de dados MySQL por ele ser também popular e por seu uso ser livre. Como trabalhos futuros, é importante estender o escopo do trabalho realizado para capturar dependências em sistemas que utilizam framework de persistência e também a extensão para outras linguagens. A ferramenta resultado deste trabalho poderá também ser utilizada no meio acadêmico para estudos experimentais de caracterização de software. Referências Analysis, D. (2014). Disponível em: Ferreira, K. A. M., Bigonha, M. A. S., and Bigonha, R. S. (2006). Avaliação de Conectividade em Sistemas Orientados por Objetos. PhD thesis, Master Thesis-Federal University of Minas Gerais. Belo Horizonte, Brazil. Ferreira, K. A. M., Bigonha, M. A. S., and Bigonha, R. S. (2011). Um modelo de prediçãoo de amplitude da propagação de modificações contratuais em software orientado a objetos. PhD thesis, Phd Thesis-Federal University of Minas Gerais. Belo Horizonte, Brazil. Finder, D. (2008). Disponível em: acesso em julho de Geipel, M. M. and Schweitzer, F. (2012). The link between dependency and cochange: Empirical evidence. Software Engineering, IEEE Transactions on, 38(6): Li, L., Zhang, L., Lu, L., and Fan, Z. (2010). Assessing object-oriented software systems based on change impact simulation. In Computer and Information Technology (CIT), 2010 IEEE 10th International Conference on, pages IEEE. Meyer, B. (1988). Object-oriented software construction, volume 2. Prentice hall New York. Sommerville, I., Melnikoff, S. S. S., Arakaki, R., and de Andrade Barbosa, E. (2003). Engenharia de software, volume 6. Addison Wesley São Paulo. Terceiro, A., Costa, J., Miranda, J., Meirelles, P., Rios, L. R., Almeida, L., Chavez, C., and Kon, F. (2010). Analizo: an extensible multi-language source code analysis and visualization toolkit. SBES - Simpósio Brasileiro de Engenharia de Software - Sessão de Ferramentas, page

101 Seleção e aplicação de um processo de elicitação de requisitos baseadas na análise de uma revisão sistemática da literatura Lucas Ferreira de Abreu, Glívia Angélica Rodrigues Barbosa Instituto de Ciências Exatas e Informática Pontifícia Universidade Católica de Minas Gerais (PUC Minas) Belo Horizonte MG Brasil lucasferreira@outlook.com, gliviaangelica@gmail.com Abstract. This paper aims to analyze the status of studies related to software requirements elicitation and deployment of one of the processes involved in a software development company. The methodology consists of performing a systematic literature review using as databases conferences sponsored or supported by the Brazilian Computer Society (SBC), that way will be possible to present the current state of art related to proposed elicitation process in Brazil, and then choose a process for deployment, make possible adjustments and analyze the results. Because the project is ongoing, the results will be generated later. Keywords: Processes for Requirements Elicitation, Systematic Literature Review. Resumo. Este trabalho visa analisar o panorama atual dos estudos relacionados à elicitação de requisitos de software e a implantação de um dos processos analisados em uma empresa de desenvolvimento de software. A metodologia adotada consiste em realizar uma revisão sistemática da literatura utilizando como bases de dados as conferências de software promovidas ou apoiadas pela Sociedade Brasileira de Computação (SBC), dessa forma será possível apresentar o estado da arte atual relacionado aos processos de elicitação propostos no Brasil, e posteriormente, selecionar um processo para implantação, efetuar possíveis adaptações e analisar os resultados obtidos. Como o projeto está em andamento, os resultados serão gerados e avaliados posteriormente. Palavras-chave: Processos de Elicitação de Requisitos, Revisão Sistemática da Literatura. Categoria: Trabalho de Conclusão de Curso Estágio: Em andamento 101

102 1. Introdução As empresas de desenvolvimento de software enfrentam diversos desafios no processo de construção de seus produtos. Com usuários cada vez mais exigentes, esforços estão sendo direcionados para detectar gargalos e prover melhorias nos processos de desenvolvimento. Estudos mostram que a maioria dos problemas em projetos de software são procedentes da má condução dos processos relacionados à Engenharia de Requisitos. Requisitos bem definidos são insumos fundamentais à construção de um software capaz de atender às necessidades dos usuários [Freitas, Borges e Araújo 2007], o que motiva a implantação de processos de elicitação eficazes para obter usuários satisfeitos com o produto final. Motivado por este cenário, este estudo busca avaliar os processos de elicitação de requisitos já existentes e implantar um deles em uma empresa de desenvolvimento de software, visando a melhoria do processo atual e a diminuição de erros causados pela má condução desta atividade. A partir de sua implementação, será possível avaliar sua consolidação e identificar suas limitações. Para alcançar o objetivo proposto, será realizada uma revisão sistemática da literatura para identificar os processos de elicitação existentes e classificá-los de acordo com sua qualidade. A partir desta análise, um dos processos será selecionado e implantado na empresa caso necessário, adaptações no processo proposto serão realizadas e a efetividade desta implantação será discutida. 2. Referencial Teórico A construção de um software é um trabalho dependente de vários fatores. Desde a identificação de um problema até a concepção propriamente dita, os envolvidos devem estar atentos para que a solução seja construída da melhor forma possível e que o problema seja tratado de maneira eficaz [Barbosa 2009]. A Engenharia de Software visa à criação de produtos de software que atendam às necessidades de pessoas e instituições [Spínola 2007], contribuindo positivamente para os processos de desenvolvimento. Uma das disciplinas da Engenharia de Software é a Engenharia de Requisitos, que contempla as atividades relacionadas à desenvolvimento e gerência dos requisitos [Pfleeger 2004]. Dentre as fases de Engenharia de Requisitos, está a fase de elicitação, considerada crítica e fonte de diversos problemas na construção dos softwares atuais. A elicitação consiste em um trabalho com os futuros usuários do sistema para detectar suas necessidades, envolvendo métodos psicológicos, sociológicos e um grande domínio da aplicação. [Dorfman 1997]. Visando propor uma melhoria a um processo de elicitação, será realizada uma Revisão Sistemática da Literatura, analisando o panorama atual dos estudos de processos de levantamento de requisitos e selecionando um processo para aprimoramento. Uma Revisão Sistemática da Literatura é um meio de identificar, avaliar e interpretar todas as pesquisas disponíveis relevantes para uma questão de pesquisa específica, ou área temática, ou fenômeno de interesse [Kitchenham 2004]. 102

103 3. Trabalhos Relacionados Nesta seção, serão apresentados trabalhos realizados com o objetivo de propor ou demonstrar a implantação de um processo de elicitação de requisitos em domínios variados. Nóbrega (2010) define um processo genérico de elicitação de requisitos com abordagem de Linha de Produto de Software (Software Product Line, SPL). Utilizandose de diagramas UML, este tipo de abordagem tem um custo inicial de projeto maior devido sua complexidade. Este fato também faz com que a validação dos requisitos elicitados seja de responsabilidade do setor de desenvolvimento. O autor propões a aplicação de engenharia de conhecimento à esta abordagem, visando amenizar este custo extra no início do projeto. Fernandes (2011) propõe um processo genérico, acrescentando árvores de características ao processo de elicitação. O autor também utiliza da abordagem de Linha de Produto, combinado com Redes Petri para maior entendimento dos requisitos elicitados. Arantes (2011) faz um estudo de caso da construção de um website multidisciplinar. O processo tem uma forte tendência ao Design Participativo e à Semiótica Organizacional, posicionando os stakeholders como parte fundamental do desenvolvimento do software. Foram realizados workshops tanto para elicitação dos requisitos quanto na validação dos mesmos, proporcionando uma maior comunicação entre os stakeholders e uma melhor análise do impacto da implantação do software. Soledade (2013) utiliza-se da estratégia de Design Thinking durante a elicitação. O processo foi aplicado no contexto educacional, no processo de desenvolvimento de um LMS (Learning Management System) usando como base a plataforma Moodle 2.2. Foram utilizados formulários durante a elicitação, e os próprios estudantes fizeram a validação dos requisitos elicitados. Barbosa (2009) propõe um processo focado na escolha do método de elicitação. Podemos classifica-lo como genérico, pois nada impede que o processo seja utilizado em diversos domínios. O processo proposto foi aplicado durante o desenvolvimento de três sistemas em contextos distintos, confirmando a afirmação anterior. Oliveira (2010) também propôs o uso de árvores de características durante a fase de elicitação. O processo proposto foi aplicado no contexto educacional, durante a construção de um software educativo. Os stakeholders foram envolvidos, elaborando esboços de árvores. O processo de elicitação a ser proposto e validado neste estudo será baseado em um dos estudos citados acima, com possíveis alterações, possibilitando a adaptação do método de elicitação ao domínio da empresa em que será implantado. 4. Metodologia A metodologia para execução da proposta será dividida em três fases: levantamento do panorama atual de processos de elicitação no brasil, implantação de um processo de elicitação e validação do processo implantado. Na fase de levantamento, será realizada uma SLR (Systematic Literature Review, Revisão Sistemática da Literatura) para analisar o panorama atual das pesquisas em 103

104 processos de elicitação de requisitos de software, e a partir dos artigos extraídos da coleta de dados, um dos processos estudados será selecionado. A SLR garante a qualidade e a validade dos resultados obtidos na pesquisa Na fase de implantação de um processo de elicitação, o processo selecionado será estudado e implantado na empresa. Caso necessário, serão feitas adaptações e complementações ao processo. Na fase de validação, serão comparados os resultados de dois processos de elicitação de requisitos: um com o processo implantado e outro sem o processo implantado. Após a finalização das três fases, será feita uma análise dos resultados obtidos e serão dadas sugestões de mudanças para o processo implantado. 5. Resultados esperados e contribuições Este artigo contribui com o meio acadêmico através da revisão de literatura, que provê um panorama atualizado das pesquisas sobre processos de elicitação de software e incentiva a condução de estudos relacionados a este tema. Outro resultado esperado é a implantação de um processo de elicitação que poderá ser utilizado por empresas com objetivos similares à que o processo será implantado, ou poderá ser adaptado para implantação em outros domínios. 6. Cronograma Etapa Revisão Sistemática da Literatura Implantação do Processo Selecionado Validação do Processo Análise dos Resultados Tabela 1. Cronograma de Atividades Previstas Atividade Analisar o panorama atual dos processos de elicitação de requisitos de software no Brasil Definir o processo a ser implantado Realizar adaptações necessárias ao processo 2014 Mar Abr Mai Jun Jul Ago Set Out Nov X X X Implantar o processo X X X Comparar uma elicitação com o processo e uma elicitação sem o processo proposto Analisar os resultados com base na comparação na etapa anterior X X X X X X 104

105 7. Proposta para análise do panorama de pesquisa em processos de elicitação de requisitos de software no Brasil no período entre :uma revisão sistemática Nesta seção, a revisão sistemática a ser realizada será detalhada através da definição de seu protocolo Objetivo da pesquisa Esta revisão tem como objetivo principal analisar o panorama atual de estudos e pesquisas relacionadas à processos de elicitação de requisitos de software no período entre 2004 e Serão considerados apenas artigos publicados em conferências promovidas/apoiadas pela SBC (Sociedade Brasileira de Computação). Uma vez que, segundo pesquisa divulgada pelo The Standish Group (2011), nos últimos 10 anos não houveram melhorias significativas que garantem o sucesso do software construído, visamos demonstrar quais esforços foram realizados nesse período em relação a elicitação de requisitos, buscando as razões pela qual tais melhorias não foram propostas Questões de pesquisa Questão de pesquisa: o [QP] Qual o panorama de pesquisa em processos de elicitação de requisitos de software no Brasil nos últimos 10 anos? Questões Específicas: o [QE1] Qual o volume de artigos relacionados à Processos de Elicitação de Requisitos publicados nos últimos 10 anos nas conferências da SBC? o [QE2] Em quais domínios os processos foram aplicados? o [QE3] Qual o volume de processos propostos que foram validados em um contexto real de elicitação de requisitos? o [QE4] Qual o volume de processos de elicitação que são adaptações de processos anteriores? 7.3. Identificação da String de Pesquisa Para a realização de uma revisão da literatura é extremamente importante que a string de pesquisa (SP) seja bem definida. Após identificar possíveis SPs, testes são realizados a fim de definir qual das SPs melhor permite a busca de artigos relevantes. A string definida foi: processos de requisitos OR requisitos OR elicitação de requisitos OR requisitos de software OR levantamento de requisitos OR requirements elicitation OR requirements OR software requirements 105

106 7.4. Teste da String de Pesquisa Conferências e Pesquisas com a String Tabela 2. Conferências, método de busca e total retornado Conferência Período Biblioteca Como buscar Total retornado Enacomp Anais Pesquisa manual 4 Encosis 2012 Anais Pesquisa manual 1 SBSI BDBComp Analisar todos os títulos que estão na biblioteca para o 10 evento nesse período CSBC Anais Pesquisa Manual 3 SBQS BDBComp Analisar todos os títulos que estão na biblioteca para o 10 evento nesse período SBIE Anais Pesquisa manual 14 WIW Anais Pesquisa manual Metodologia de Pesquisa A pesquisa será realizada em cinco etapas, conforme apresentado na Figura 1: Seleção através do Título Seleção através do Resumo Seleção através de Leitura Diagonal Coleta dos Dados Análise da Pesquisa Figura 1: Etapas da pesquisa Etapa 1 Seleção através do Título Nesta etapa será realizada a leitura do título dos artigos selecionados e serão removidos os artigos considerados irrelevantes e duplicados. Critérios de Exclusão: Deverão ser excluídos apenas artigos que não são relacionados a elicitação de requisitos. Os artigos duplicados deverão ser excluídos nesta etapa. Artigos que não possuírem título em inglês ou português deveram ser excluídos. Nesta etapa ainda não devemos observar as questões de pesquisa. Em caso de dúvida, ler as palavras-chaves e resumo do artigo Etapa 2 Seleção através do Resumo Será lido o resumo e palavras-chaves de todos os artigos selecionados para esta etapa., verificando se de acordo com o resumo o artigo está relacionado às questões de pesquisa. Critérios de Inclusão/Exclusão: Nesta etapa serão excluídos os artigos que não estiverem dentro do escopo das questões de pesquisa. Não serão considerados os artigos que não possuírem resumo em inglês ou português. 106

107 Etapa 3 Seleção através de Leitura Diagonal Será feita uma leitura diagonal (introdução, principais tópicos e conclusão) dos artigos selecionados para esta etapa, verificando se o artigo está relacionado às questões de pesquisa. Critério de Inclusão/Exclusão: Nesta etapa serão excluídos os artigos que não estiverem dentro do escopo das questões de pesquisa Etapa 4 Coleta dos Dados Será feita a leitura dos artigos selecionados para esta etapa, pontuando-os acordo com os critérios de qualidade a seguir: O estudo define claramente o objetivo da pesquisa (define questão de pesquisa)? O artigo responde as questões de pesquisa definidas? O estudo discute os trabalhos relacionados? O estudo menciona o domínio no qual o processo de elicitação foi aplicado? O trabalho é relevante para responder as questões de pesquisa desta SLR? O trabalho recomenda possíveis trabalhos futuros? Critérios de Inclusão/Exclusão: Para cada questão de qualidade o estudo é avaliado como "Sim" ou "Não". A pontuação qualidade mínima será de 4 Sim (aproximadamente 67%) Análise da Pesquisa Nesta etapa deverá ser realizada a análise da pesquisa respondendo as questões de pesquisas através das informações coletadas na etapa anterior. 8. Referências ARANTES, Flávia Linhalis. (2011) Organizational Semiotics and Participatory Design to Requirements Elicitation A Case Study, In: Simpósio Brasileiro de Sistemas de Informação, Campinas. BARBOSA, Glívia; et al. (2009) Um processo de elicitação de requisitos com foco na seleção da técnica de elicitação, In: Simpósio Brasileiro de Qualidade de Software, Belo Horizonte. DORFMAN, Merlin, THAYER H. (1997) Software Requirements Engineering, 2 nd edition. p FERNANDES, Carla Ferreira; VALE, Liliane do Nascimento. (2011) Verificação e Refinamento de Requisitos em Árvores Características usando Linhas de Produtos de Requisitos e Redes de Petri, In: Encontro Anual de Computação, Catalão. FREITAS, Danilo Pestana de; BORGES, Marcos R. S; ARAÚJO, Renata Mendes de. (2007) Colaboração e Negociação na Elicitação de Requisitos, In: Workshop Ibero-americano de Ingeniería de Requisitos y Ambientes de Software, Isla de Margarita. KITCHENHAM, Barbara. (2004) Procedures for Performing Systematic Reviews, Keele. 107

108 NÓBREGA, Fernando Antônio Asevedo. (2010) Aplicação de Lógica Descritiva para Validação de Requisitos em Linha de Produto de Software, In: Encontro Anual de Computação, Catalão. OLIVEIRA, Carvalho Cíntia; et al. (2010) Árvore de Características de Software Educativo: Uma Proposta para Elicitação de Requisitos pelo Usuário, In: Simpósio Brasileiro de Informática na Educação, Uberlândia. PFLEEGER, Shari Lawrence. (2004) Engenharia de software: teoria e prática. Identificando Requisitos, Prentice Hall, 2 nd edition, São Paulo, p SOLEDADE JR., Marcos P. da; et al. (2011) Experimenting with Design Thinking in Requirements Refinement for a Learning Management System, In: Simpósio Brasileiro de Sistemas de Informação, São Paulo. SPÍNOLA, Rodrigo Oliveira. (2007) Introdução à Engenharia de Requisitos. In: Revista Engenharia de Software, DevMedia, Year 1-1 th edition, May. 108

109 Uma Avaliação de Ferramentas de Modelagem de Software Johnatan Alves de Oliveira, Priscila Pereira de Souza, Eduardo Figueiredo Laboratório de Engenharia de Software (LabSoft), Universidade Federal de Minas Gerais (UFMG), Belo Horizonte -MG Categoria: Iniciação Científica Estágio do trabalho: Concluído Resumo. Ferramentas de modelagem servem para orientar e disciplinar o processo de desenvolvimento de software durante a fase de projeto. Entretanto, tais ferramentas não são totalmente exploradas do ponto de vista funcional, seja por complexidade do assunto abordado ou pela usabilidade das mesmas. Este artigo se propõe a avaliar o uso de duas ferramentas de modelagem de software, sendo uma delas no formato online e outra em desktop, por meio de um experimento realizado na Universidade Federal de Minas Gerais com alunos de graduação e pós-graduação. O objetivo do estudo foi avaliar a usabilidade das duas ferramentas open source, ArgoUml e Gliffy, que permitem a modelagem de software utilizando a notação da UML. São apresentados estudos referentes aos níveis de aceitação e de utilização das ferramentas investigadas. Palavras chaves: experimento, ferramenta, UML, usabilidade 1. Introdução Segundo Booch et al. (2005), a UML (Unified Modeling Language) trata de uma linguagem gráfica padrão no fornecimento de especificação, visualização, construção e documentações de artefatos de um sistema de software. A UML incorpora vários diagramas para a modelagem de sistemas de software, que apresentam resultados na compreensão entre cliente e desenvolvedor, facilitando as fases de análise, projeto e implementação do sistema de software. Para usufruir dos benefícios dos diagramas é necessário o uso das ferramentas CASE (Computer Aided Software Engineering) que fornecem suporte para as diversas fases do projeto de software ou gerenciamento deste projeto (Monteiro, 2004). É inquestionável que as ferramentas CASE fornecem suporte às atividades relacionadas a desenvolvimento de software. Porém, os usuários das ferramentas por muitas vezes, deixam de utilizar suficientemente dos seus recursos por falha na interação entre usuário e ferramenta. Segundo Pressman (2002), a interface é considerada um dos elementos mais interessantes em relação ao comportamento homem-computador, pois envolve a manipulação das ferramentas pelos usuários podendo influenciar na realização de tarefas. As ferramentas avaliadas neste experimento foram a ArgoUml e a Gliffy. A ferramenta ArgoUml foi desenvolvida em JAVA pela Universidade da Califórnia em Berkeley. É uma ferramenta open source capaz de ser executada em diversas plataformas desktops, gerando código para várias linguagens como: PHP, C++ e JAVA. 109

110 A ferramenta Gliffy também é uma ferramenta open source, porém utilizada online, permitindo a colaboração em tempo real de outros usuários. Essa ferramenta foi desenvolvida em tecnologia Flash, permitindo a modelagem de diversos diagramas além da UML. O presente trabalho, busca apresentar através de um experimento, a avaliação de usabilidade destas duas ferramentas CASE, que fornecem suporte no desenvolvimento de software. As ferramentas ArgoUml e Gliffy foram escolhidas de acordo com análise prévia executada pela equipe do experimento. Buscamos uma ferramenta desktop com maior reconhecimento no meio acadêmico/profissional e outra online pouco conhecida. Além desses pontos, a ArgoUml foi escolhida por ser bem completa, se tornando possivelmente complexa de manipular. Já a ferramenta Gliffy, foi proposta por ser em formato online de caráter gratuito com grande gama de diagramas disponíveis além dos diagramas UML. O restante do artigo está estruturado da seguinte forma. A Seção 2 apresenta o embasamento e planejamento do experimento. A Seção 3 discute a execução do experimento, apresentando a forma na qual o experimento foi executado e o perfil dos alunos participantes. Na Seção 4 é analisado os dados gerados pelos participantes do experimento ao desempenharem as tarefas do experimento utilizando as ferramentas. A Seção 5 apresenta as ameaças a validade e a Seção 6 discute os trabalhos relacionados. Finalmente, a Seção 7 resume as principais lições aprendidas e conclui o trabalho. 2. Planejamento do Experimento O planejamento desse experimento foi realizado seguindo as etapas do processo proposto por Wohlin et al (2012). 2.1 Objetivo Geral Pelo o modelo proposto por Wohlin et al (2012), foi definido que este experimento possui por objetivo avaliar as ferramentas ArgoUml e Gliffy referente a usabilidade do ponto de vista dos alunos de graduação e pós-graduação no contexto da disciplina de Engenharia de Software Experimental da Universidade Federal de Minas Gerais Seleção do Contexto O experimento foi executado em dois laboratórios, equipados com 20 máquinas idênticas em cada um, na Universidade Federal de Minas Gerais (UFMG) Formulação das Hipóteses Para definir as hipóteses foram introduzidos alguns símbolos que representam as métricas coletadas no experimento. TD - Tempo Gasto para Elaborar os Diagramas QE - Quantidade de Erros Cometidos DI - Número de Diagramas Incompletos GA - Quantidade de vezes que o grupo foi Acionado Como existem dois objetos no experimento, as variáveis dependentes possuem duas variações para cada uma das ferramentas utilizadas, como seguem abaixo: TDA - Tempo gasto para elaborar os diagramas na ferramenta ArgoUml; 110

111 TDG - Tempo gasto para elaborar os diagramas na ferramenta Gliffy; QEA - Quantidade de erros cometidos pelos alunos na ferramenta ArgoUML; QEG - Quantidade de erros cometidos pelos alunos na ferramenta Gliffy; DIA - Número de diagramas incompletos na ferramenta ArgoUml; DIG- Número de diagramas incompletos na ferramenta Gliffy; GAA Número de vezes que os integrantes do grupo foram acionados para sanar dúvidas de utilização da ferramenta ArgoUml; GAG - Número de vezes que os integrantes do grupo foram acionados para sanar dúvidas de utilização da ferramenta Gliffy. A partir do experimento, foi possível analisar a validade das hipóteses abaixo descritas. H1a: TDA < TDG H1b: QEA < QEG H1c: DIA < DIG H1d: GAA < GAG As hipóteses alternativas do experimento foram enumeradas da seguinte maneira. H2a: TDA > TDG H2b: QEA > QEG H2c: DIA > DIG H2d: GAA > GAG Não houve nenhuma obrigatoriedade para que as hipóteses alternativas se comportassem de forma conjunta, ou seja, não era necessário que todas as hipóteses fossem confirmadas. Poderia haver a confirmação de, por exemplo, duas hipóteses do primeiro grupo e 3 hipóteses do outro grupo Seleção das Variáveis As seguintes variáveis independentes foram consideradas no estudo. Estrutura e ambiente físico onde será aplicado o experimento: O experimento será executado nos laboratórios 2011 e 2012, na Universidade Federal de Minas Gerais. Embora cada sujeito utilize máquinas diferentes, acreditamos que todas as máquinas estejam configuradas da mesma maneira; Tempo gasto para elaborar os diagramas; Quantidade de erros cometidos pelos sujeitos nas ferramentas; Número de diagramas incompletos; Quantidade de vezes que o grupo responsável pelo experimento foi acionado para tirar dúvidas dos sujeitos com relação a ferramenta. Por outro lado, a variável dependente pesquisada foi definida como a experiência de interação e usabilidade no uso das ferramentas ArgoUml e Gliffy pelos participantes Seleção dos Sujeitos Os participantes desse experimento, foram os alunos de graduação e pós-graduação da disciplina de Engenharia de Software Experimental da UFMG. No total, foram 18 participantes divididos em nove duplas. A separação em duplas foi necessária para que houvesse o nivelamento do conhecimento, visto que de alguma forma a falta de conhecimento em UML poderia interferir na execução das tarefas do experimento. 111

112 2.5. Instrumentação A instrumentação deste experimento inclui os seguintes elementos. Formulário de caracterização dos alunos: Este formulário visa a avaliação do perfil acadêmico e profissional do sujeito, seu nível de conhecimento em UML e o grau de satisfação com relação às ferramentas abordadas no experimento. Estudos de caso: Descrição das funcionalidades de um sistema para elaboração dos diagramas de caso de uso e de classes. ArgoUml: É uma ferramenta open source que usa UML para modelagem de sistemas de software. Gliffy: É uma ferramenta open source online que usa UML para modelagem sistemas de software 3. Execução O experimento foi executado com alunos da disciplina de Engenharia de Software Experimental da UFMG. Para a boa realização do experimento, foi feito um resumo para os participantes das principais notações dos diagramas UML que seriam usados. O objetivo é que todos os participantes estivessem no mesmo nível de conhecimento para a execução do experimento. O experimento foi executado em um só dia: 31/03/2014. A turma foi dividida em duplas, sendo um integrante do curso de graduação e o outro do curso de pósgraduação. A metade da turma utilizou a ferramenta ArgoUml e a outra metade a ferramenta Gliffy. A Tabela 1 apresenta a configuração do experimento, indicando o agrupamento das duplas por ferramenta avaliada. Sujeito Ferramenta Laboratório Turma A 5 Duplas ArgoUml Sala 1 Turma B 4 Duplas Gliffy Sala 2 Tabela 01 - Divisão e Alocação dos Sujeitos Foi entregue a cada dupla, o enunciado do experimento que exigia a modelagem de um software usando dois diagramas da UML: Diagrama de Casos de Uso e Diagrama de Classes. Os participantes tiveram que elaborá-los nas ferramentas definidas aleatoriamente para cada dupla. Uma das duplas do laboratório de ArgoUml (Sala 1) teve problemas com o computador utilizado que reiniciou durante o experimento, prejudicando assim o término dos diagramas. Os dados de tempo desta dupla foram descartados durante a análise dos dados obtidos. 4. Análise dos Resultados A análise dos dados coletados foi iniciada pelo questionário de caracterização dos sujeitos. Um dos pontos avaliados foi o conhecimento em UML que foi categoricamente separado em: alto, médio e baixo. Dentre os 18 participantes, 14 deles relataram possuir conhecimento médio em UML e 4 relataram possuírem baixo conhecimento. Nenhum participante relatou ter um alto conhecimento. Devido a homogeneidade dos participantes (grande maioria com conhecimento médio), esta informação não foi utilizada no agrupamento dos mesmo em duplas. Entretanto, tal informação foi útil para manter balanceadas as turmas A (ArgoUml) e B (Gliffy). 112

113 Outro ponto analisado foi referente a experiência profissional em relação a modelagem de software utilizando diagramas UML. Nesta análise, 10 participantes informaram que possuíam experiência profissional em UML e 8 relataram que não possuíam. Assim, como supracitado os participantes do experimento foram randomicamente alocados para utilizarem duas ferramentas distintas: ArgoUml e Gliffy. Os 8 participantes que utilizaram a ferramenta Gliffy, relataram que nunca haviam utilizado essa ferramenta, e dentre os 10 sujeitos que utilizaram a ArgoUml, 4 já a haviam utilizado em outras ocasiões. Uma das métricas avaliadas foi o tempo gasto para modelar os diagramas. A informação de horário de início e término para elaborar cada diagrama foi anotado pelos próprios participantes em um campo específico no enunciado do experimento. A Figura 1 ilustra o tempo gasto por cada dupla para conclusão da modelagem, separados por cada diagrama. Figura 1: Tempo gasto para conclusão dos diagramas em cada ferramenta O gráfico da Figura 1 mostra que o tempo gasto para modelar o Diagrama de Classes e o Diagrama de Casos de Uso foi geralmente maior na ferramenta ArgoUml do que na ferramenta Gliffy. Por exemplo, 3 duplas que usaram a ferramenta ArgoUml gastaram mais de 40 minutos para concluir o Diagrama de Classes nesta ferramenta. Por outro lado, nenhum dos participantes que utilizaram a ferramenta Gliffy demoraram este tempo de 40 minutos em nenhum dos diagramas. Este resultado sugere que o tempo gasto para a conclusão da modelagem em ArgoUml foi maior do que na ferramenta Gliffy, sendo verdadeira a hipótese 1 : H2a: TDA > TDG. Os diagramas desenvolvidos pelos participantes do experimento foram avaliados com base em requisitos básicos que deveriam ser alcançados para categorizar se o Diagrama de Classes e o Diagrama de Casos de Uso estariam ou não completos. Como base para esta análise dos diagramas, foi utilizado os diagramas resolvidos por um analista de requisitos experiente. Os requisitos mínimos que deveriam ser alcançados nos Diagramas de Classes foram: quantidade de classes essenciais no domínio do problema, como cliente, produto e funcionário. No Diagrama de Casos de Uso, os componentes básicos foram os atores clientes e funcionários e os casos de uso básicos, como aluguel e reserva de fita. Sustentado nesses critérios, os dados foram analisados e 1 Devido ao tamanho reduzido da amostra, não foi aplicado teste estatístico para confirmar ou refutar as hipóteses deste experimento. 113

114 pesos foram atribuídos às falhas cometidas. No gráfico da Figura 2, cada coluna representa uma dupla e sua distribuição de pesos agregados de 0 a 30. Valores mais altos indicam maior incidência de falhas na modelagem. Figura 2: Quantidade de diagramas incompletos modelados Fundamentado nestes dados, a ferramenta que obteve menos diagramas incompletos foi a ArgoUML. Estes resultados sugerem que a hipótese verdadeira nesse caso foi H1d: DIA < DIG dado que a média de diagramas incompletos no ArgoUml alcançou 20 pontos de penalidades e na Gliffy 25, em média. Outra métrica avaliada nesse experimento foi a quantidade de componentes inadequados utilizados na elaboração dos diagramas. Como exemplo de dados coletados, podemos citar a utilização de quadrados no lugar de elipse nos Diagramas de Caso de Uso elaborados na Gliffy. A hipótese que obteve critério verdadeiro, foi que os sujeitos obtiveram mais erros no Gliffy do que na ArgoUML apoiando a hipótese: H1b: QEA < QEG em razão de que o total de recursos utilizados incorretamente no Gliffy, alcançou 2 erros e na ArgoUML apenas 1 erro. Para esta hipótese, pode-se afirmar que em virtude de dominarem menos a ferramenta Gliffy, e esta ferramenta não possuir divisão sistêmica dos itens dos diagramas, os sujeitos utilizaram mais componentes inadequados como mostra o gráfico da Figura 3. Figura 3: Uso inadequado de componentes das ferramentas 114

115 As ações dos participantes diante das ferramentas de modelagem, foram observadas pelo grupo que aplicou o experimento. Todas as observações relevantes foram anotadas, bem como a quantidade de vezes que os participantes acionaram um dos integrantes para sanar dúvidas sobre as ferramentas. Com base nesses dados, a ferramenta que provocou mais dúvidas nos participantes envolvidos foi a ArgoUML, como pode ser observada no gráfico da Figura 4. Estes dados sugerem que a hipótese verdadeira é: H2e: GAA > GAG, uma vez que as duplas de ArgoUML, acionaram a equipe do experimento por 5 vezes e da Gliffy requisitaram por 2 vezes. Figura 4: Quantidade de vezes que o grupo foi acionado pelos sujeitos Através das anotações realizadas ao longo das observação do grupo e do relato dos sujeitos no questionário aplicado, analisamos a métrica grau de dificuldade de utilização das ferramentas. O grau de dificuldade foi categorizado em alto, médio e baixo. De acordo com os dados coletados, apenas 1 participante teve dificuldade de aprendizado alto na ferramenta Gliffy. Nenhum dos participantes a pontuaram em grau médio e no grau baixo. A ferramenta obteve avaliação por 7 participantes que à categorizaram como baixo grau de dificuldade de aprendizado. Na ArgoUML, nenhum participante à classificaram como grau de dificuldade alto. Quatro participantes a classificaram com grau médio e 6 como grau baixo. É possível identificas estas dificuldades, analisando os resultados demonstrados no gráfico da Figura 5. Figura 5 :Grau de dificuldade de aprendizado nas ferramentas utilizadas 115

116 Analisando o questionário aplicado após a utilização das ferramentas, os participantes envolvidos no experimento foram indagados referente a ferramenta que foi utilizada por sua dupla. Essa indagação era classificada pelo grau de bom, razoável e ruim. Como pode ser observado na Figura 6, a ferramenta ArgoUml foi classificada como ruim por 2 participantes, razoável por 4 participantes e outros 4 participantes a classificaram como boa facilidade de utilização. Já no caso da ferramenta Gliffy, não obteve classificação ruim, foi classificada como razoável por 5 participantes e bom por 3 participantes. Figura 6: Classificação de facilidade de utilização das ferramentas no experimento. A satisfação em relação a ferramenta, foi analisada através de questionamentos aos envolvidos quanto a recomendação ou utilização da ferramenta. A verificação foi realizada através de duas alternativas, sim ou não, que podem ser visualizadas no gráfico da Figura 7. Todos os envolvidos na modelagem utilizando a ferramenta Gliffy, nos informaram que usaria novamente ou recomendaria a ferramenta. Já dos 10 participantes que modelaram com a ArgoUml, 6 deles nos informaram que usariam novamente ou recomendaria a ferramenta e 4 relataram que não usariam novamente ou a recomendaria a ferramenta. Figura 7: Sujeitos que usariam novamente a ferramenta ou recomendariam 116

117 5. Ameaças à Validade do Experimento As possíveis ameaças a validade do experimento são discutidas em quatro dimensões (Wohlin, 2012): validade interna, validade de conclusão, validade de construção e validade externa. Validade Interna. Conhecimento da notação: A notação utilizada na execução do experimento foi a UML, por ser a notação mais utilizada no mercado e suportada pelas ferramentas avaliadas. Os sujeitos poderiam não ter conhecimento da notação em questão, o que certamente comprometeria a avaliação da usabilidade das ferramentas. Para mitigar essa ameaça, os sujeitos realizaram o trabalho em duplas, composta por um aluno de graduação e um de pós-graduação para equilibrar o conhecimento. Validade de Conclusão. Quanto ao perfil dos sujeitos: A heterogeneidade dos sujeitos poderia afetar a validade do experimento. Sujeitos que já possuíssem amplo conhecimento referente à modelagem utilizando as ferramentas ArgoUml ou Gliffy, poderiam concluir os diagramas em menos tempo, com menor número de perguntas aos integrantes do grupo e com bem menos erros do que sujeitos que não possuíssem experiência nessas ferramentas. E isso poderia fazer com que os resultados do experimento fossem em favor de uma ferramenta em particular. Essa informação foi identificada através da aplicação do formulário de caracterização dos sujeitos para ser considerada no momento da análise dos dados. Quanto ao funcionamento dos softwares e das máquinas: Durante a execução do experimento poderia haver mal funcionamento tanto por parte dos softwares instalados quanto por parte das máquinas, o que poderia comprometer o término do experimento. Validade de Construção. Modelagem dos diagramas: A modelagem dos diagramas poderia ter interpretações diferentes, sendo assim, tentamos descrever as funcionalidades do sistema da melhor maneira possível (sem ambiguidades) para impedir que os sujeitos elaborassem um mesmo diagrama de forma muito discrepante, visto que isto poderia afetar a validade do experimento. Para avaliar os erros e acertos dos sujeitos, seguimos como referência para comparação, os diagramas previamente elaborados por um analista de requisitos experiente. 6. Trabalhos Relacionados Em um trabalho relacionado, Shumba (2005) realizou estudos sobre duas ferramentas de modelagem: Rational Rose (Rose) e Microsoft Visio (Visio). O objetivo do estudo foi avaliar a usabilidade dessas duas ferramentas no ambiente do curso de Engenharia de Software na Indiana University of Pennsylvania (IUP). O autor fez esta avaliação através de um survey com o intuito de coletar dados sobre opiniões dos estudantes que utilizaram as duas ferramentas no decorrer do curso. Este trabalho diferencia-se do trabalho de Shumba (2005) por ter realizado um experimento controlado. Pereira et al. (2013) realizou um experimento controlado para avaliar duas ferramentas de modelagem. O objetivo foi verificar as vantagens e desvantagens de cada ferramenta no desenvolvimento de linha de produtos de software (Figueiredo et al., 2008). Em nosso estudo, foi coletado dados no momento da utilização das ferramentas através da observação dos sujeitos envolvidos no experimento. Além disso, foram seguidas as diretrizes para a análise de usabilidade na execução de tarefas e observado o comportamento dos usuários diante das ferramentas envolvidas. 117

118 7. Conclusão e Próximos Passos Podemos concluir, com base nos resultados preliminares deste experimento, que a ferramenta Gliffy possui melhor usabilidade que a ferramenta ArgoUml, visto que ela apresentou uma maior facilidade de aprendizado. Ou seja, os participantes rapidamente conseguiram explorar o sistema e elaborar os diagramas em um tempo menor que na ferramenta ArgoUml. Além disso, os usuários da ferramenta Gliffy acionaram menos vezes o grupo de avaliadores para tirar dúvidas. Além disso, nossa conclusão é de que este experimento deva ser realizado novamente, com um quantitativo maior de participantes e/ou de ferramentas UML para que possa trazer um resultado mais significativo e seguro. Um métrica que gostaríamos de adicionar na próxima execução, é a quantidade de cliques acionados pelos participantes para elaborar cada diagrama. Agradecimentos Este trabalho teve apoio financeiro da FAPEMIG: Processos APQ e PPM Referências BASILI, V., SHULL, F., LANUBILE, F. (1999) Building Knowledge through Families of Experiments. IEEE Transactions on Software Engineering, 25(4): BOOCH, Grady; RUMBAUCH, James; JACOBSON, Ivar. UML: Guia do Usuário. Rio de Janeiro: 2 Edição. Elsevier, FIGUEIREDO, E. et al. (2008) Evolving Software Product Lines with Aspects: An Empirical Study on Design Stability. International Conference on Software Engineering (ICSE), pp Leipzig, Germany. FOWLER, Martin. (2000) UML Essencial, 2a Edição. Bookmann. KITCHENHAM, B.A. (1996) Evaluating Software Engineering Methods and Tools, SIGSoft Software Engineering Notes, ACM Press, pp KOSCIANSKI, M e SOARES, M. (2006) Qualidade de Software, 2ª Edição. Novatec. MELO, Ana Cristina. (2004) Desenvolvendo aplicações com UML 2.0: do conceitual à Implementação. 2. ed. Rio de Janeiro: Brasport. MONTEIRO, Emilio Soares. (2004) Projeto de sistemas e bancos de dados. Rio de Janeio: Brasport. PEREIRA, J., SOUZA, C., FIGUEIREDO, E., ABILIO, R., VALE, G., COSTA, H. (2013) Software Variability Management: An Exploratory Study with Two Feature Modeling Tools. Brazilian Symposium on Software Components, Architectures and Reuse (SBCARS). Brasilia, Brazil. SOMMERVILLE, Ian. (2011) Engenharia de Software, 9a. Edição. SHUMBA, R. (2005) Usability of Rational Rose and Visio in a software engineering course. SIGCSE Bulletin 37(2): WOHLIN, C. et al. (2012) Experimentation in Software Engineering, Springer. 118

119 Sistemas de Software Educacionais em Gerência de Projetos de Software - Uma Proposta de Avaliação utilizando Questionário Ana Rosa Oliveira, Heitor Costa Departamento Ciência da Computação - Universidade Federal de Lavras Caixa Postal CEP Lavras - MG - Brasil ana_rosa@sistemas.ufla.br, heitor@dcc.ufla.br Abstract. In education, technologies have been added to traditional education to differentiate the form of student interaction with knowledge. The use of software is constantly in the teaching-learning process. This type of system is called educational software. Concepts of software project management are present in some educational software system, which add practical experience in the training of many professionals. Besides, these systems must have for entertaining and playful enable learning user aspects. One of the ways to identify such features is to use a questionnaire. In this work, the goal is to present a draft questionnaire. This questionnaire was based on literature, where desirable features can be found within educational software. Resumo. Na educação, as tecnologias foram adicionadas às estruturas tradicionais de ensino com intuito de diferenciar a forma de interação do aluno com o conhecimento. Cada vez mais, o uso de sistemas de software é constante no processo de ensino-aprendizagem. Esse tipo de sistema é chamado de sistema de software educacional. Conceitos de gerência de projetos de software estão presentes em alguns desses sistemas, os quais acrescentam experiência prática na formação de diversos profissionais. Além do aspecto de aprendizagem, esses sistemas devem ter aspectos lúdicos para entreter e permitir o aprendizado do usuário. Uma das formas para identificar esses aspectos é por meio de um questionário de avaliação. Neste trabalho, o objetivo é elaborar e apresentar uma proposta de questionário. A elaboração desse questionário foi baseada na literatura, em que podem ser encontradas características desejáveis a um software educacional. Aluno: Ana Rosa Aparecida de Oliveira Orientador: Heitor Augustus Xavier Costa Categoria: Trabalho de Conclusão de Curso de Graduação Estágio do Trabalho: Em Desenvolvimento 1. Introdução O ensino de temas em Engenharia de Software tende a ser árduo, pois a estrutura educacional tradicional é centrada no professor (aulas expositivas), impedindo aos alunos a oportunidade de aplicação prática dos conceitos vistos em sala de aula. Com isso, existe uma lacuna entre teoria e prática [Savi; Wangenheim, 2011]. Em especial, 119

120 isso acontece ao ser ministrado o tema "Gerência de Projetos de Software", pois a capacitação do futuro profissional é realizada, basicamente, por aulas expositivas, o que contribui pouco para a aplicação prática de conceitos e impossibilita aos estudantes vivenciarem na prática situações reais das empresas de software [Paludo; Raabe, 2010]. Por outro lado, há a utilização crescente do computador na educação em que sistemas de software educacionais podem ser utilizados para suprir essa falha na formação dos estudantes. Esses sistemas podem ser utilizados em larga escala para apoiar o processo de ensino-aprendizagem em Engenharia de Software. Contudo, alguns desses sistemas são desenvolvidos focando apenas a parte técnica, com enfoque no conteúdo tendo pouca atenção às características lúdicas e educacionais/pedagógicas [Elissavet; Economides 2000]. Assim, há necessidade de avaliá-lo para garantir a integração de elementos importantes e atingir o objetivo pré-definido. Para realizar essas avaliações, podem ser utilizadas várias ferramentas, entre elas, um questionário. Essa avaliação precisa de ferramentas e de recursos para simplificar o processo de avaliação tornando-o prático e objetivo [Webber et al., 2009], pois, na diversidade de sistemas educacionais, há sistemas para o ensino do tema Gerência de Projetos de Software, que devem ser adequadamente escolhidos e utilizados para garantir a assimilação dos conceitos. Porém, a avaliação da utilidade de sistemas de software educacionais é limitada (ou inexistente); em alguns casos, a decisão em utilizar determinados sistemas é baseada em suposições [Savi; Wangenheim, 2011]. Assim, a elaboração de um questionário de avaliação pode contribuir na sua qualidade, no auxílio aos professores na seleção dos sistemas para apoiar suas atividades educacionais e na utilização para proporcionar melhor nível de aprendizado. Neste trabalho, o objetivo é apresentar um questionário de avaliação da utilidade de sistemas de software educacionais para apoiar o processo de ensino-aprendizagem do tema Gerência de Projetos de Software, avaliando características específicas da disciplina, aspectos lúdicos e de aprendizado focado nos usuários (alunos). Esse questionário é destinado aos usuários dos sistemas de software educacionais. O restante do artigo está organizado da seguinte forma. Aspectos de informática na educação, sistemas de software educacionais e métodos de avaliação são descritos na Seção 2. Uma proposta de questionário para realizar a avaliação de sistemas de software educacionais para apoiar o processo de ensino-aprendizagem é apresentada na Seção 3. Trabalhos relacionados são relatados na Seção 4. Conclusões e sugestões de trabalhos futuros são apresentadas na Seção Fundamentação Teórica 2.1. Informática na Educação Em meados da década de 50, os computadores eram utilizados para transmitir informação; atualmente, seu uso é diversificado, interessante e desafiador ao aluno. O professor precisa ter a capacidade de intercalar técnicas tradicionais de aprendizagem e atividades que utilizam tecnologias para reforçar ou incentivar o aluno a construir o aprendizado [Freire et al., 1999]. No Brasil, o uso do computador na educação teve início na década de 70 em pesquisas nas universidades. No início da década de 80, diversas iniciativas de informática na educação no Brasil estimularam a adoção de programas educacionais baseados na informática [Nascimento, 2007]. 120

121 A implantação da informática na educação tem características específicas, problemas, soluções, vantagens e desvantagens. A informática na educação sendo inclusa no aprendizado começa com desafios [Freire et al., 1998]. Ocorre uma mudança no papel do professor, pois não é mais entregador da informação, mas consultor do aluno que deve buscar informações para melhorar seu conhecimento. Com o papel das novas tecnologias, a informática assume duas funções na escola: i) facilitar a comunicação entre os profissionais e colaboradores externos; e ii) ser utilizada na realização de pedagogia que proporcione a formação do aluno Sistemas de Software Educacionais No processo educacional, para garantir efetividade e utilidade, os sistemas de software educacionais devem apresentar aspectos que o professor deve estar atento, por exemplo, apresentar situações desafiadoras aos alunos, permitir feedback em relação ao desempenho e desenvolver a sensação de que aprender é divertido por causa do aspecto lúdico e do desafio [Moratori, 2003]. A finalidade pedagógica incentiva o processo de ensino-aprendizagem e o conhecimento por meio de atividades lúdicas, desenvolvendo motivação. Esses sistemas podem propiciar objetivos indiretos [Moratori, 2003], por exemplo, estimulo à memória, orientação no tempo e no espaço, promoção da coordenação motora, percepção auditiva e visual, raciocínio, expressão linguística oral e escrita e planejamento e organização. Os sistemas de software educacionais baseiam-se em uma abordagem autodirigida, em que o usuário aprende sozinho, por meio da descoberta e da interação. O professor é o mediador do processo, orientando e selecionando sistemas de software adequados e relacionado com a prática pedagógica [Tarouco et al., 2004]. Na literatura, vários sistemas de software educacionais para apoiar o processo de ensinoaprendizagem de Gerência de Projetos de Software podem ser encontrados, por exemplo: The Incredible Manager [Dantas, 2003]; Planager [Kieling; Rosa, 2006]; ProMEG (Project Management Educational Game) [Mira et al., 2012]; Scrumming [Isotton, 2008]; SESAM (Software Engineering Simulation by Animated Models) [Drappa; Ludewig 2000]; Card Game [Baker et al., 2005]; Kallango [Campos et al., 2011]; SE RPG [Molléri, 2006]; SimulES (Simulador de Uso da Engenharia de Software) [Figueiredo et al., 2006]; e SimSE [Navarro; Hoek, 2005]. Os sistemas de software educacionais incentivam o processo de ensino-aprendizagem e o conhecimento utilizando atividades lúdicas, desenvolvendo motivação e contribuindo com os alunos sobre o ensino prático de Gerência de Projetos como um diferencial em sua formação Métodos de Avaliação Com a rápida evolução e a inserção dos sistemas de software educacionais em diversas disciplinas e níveis de ensino, a expectativa é a ajuda na assimilação dos conceitos pelos alunos. Mas, para certificar o grau de sua contribuição, é necessário utilizar métodos de avaliação que possam afirmar esse grau de forma padronizada. O Método de Reeves propõe uma metodologia definindo duas abordagens para avaliar software educacional baseadas em 14 critérios; esse método pode ser considerado uma mistura de checklist com avaliação heurística e ensaio de interação [Andres; Cybis, 2000]. A Taxonomia de Bloom auxilia na identificação e na declaração dos objetivos ligados ao desenvolvimento cognitivo, cujo objetivo é ajudar no planejamento, na organização e no controle dos objetivos de aprendizagem. A revisão 121

122 dessa taxonomia é flexível e possibilita intercalar categorias do processo cognitivo, pois determinados conteúdos podem ser assimilados facilmente com estímulo pertencente a categorias mais complexas. [Rodrigues; Santos, 2013]. O modelo RETAIN (Relevance, Embedding, Transfer, Adaptation, Immersion e Naturalization) [Zhang et al., 2010] é utilizado por professores e designers instrucionais para avaliar comparativamente qualquer software educacional para o uso em salas de aula. O modelo consiste em seis partes: i) relevância; ii) incorporação; iii) transferência; iv) adaptação; v) imersão; e vi) naturalização. É baseado nos princípios do Modelo ARCS de Keller, nos eventos de Gagne e nos princípios da Taxonomia de Bloom. Na literatura, há muitos modelos e técnicas de avaliação. O Modelo ARCS avalia a motivação de acordo com a atenção, a relevância, a confiança e a satisfação dos alunos [Keller, 2009]. A Técnica de Mucchielli avalia a eficácia do software de forma global [Andres; Cybis, 2000]. O Modelo de Avaliação de treinamentos de Kirkpatrick [Kirkpatrick, 1994] é baseado em quatro níveis: i) reação; ii) aprendizagem; iii) comportamento; e iv) resultados. 3. Questionário de Avaliação A etapa de avaliação de sistemas de software é necessária para identificar se é utilizável e se está de acordo com o que o usuário precisa. A avaliação durante o processo de desenvolvimento de software educacional deve considerar as necessidades, a facilidade de aprendizado, a eficácia, a segurança e o desafio de uma maneira adequada e que influencie a criatividade [Webber et al., 2009]. Algumas características devem ser analisadas e observadas durante avaliação de software educacional [Webber et al. 2009], por exemplo, características pedagógicas, facilidade de uso, interface, adaptabilidade, documentação, portabilidade e retorno de investimento. Na literatura, em alguns artigos, é evidenciada a importância da avaliação de sistemas educacionais, são sugeridas categorias de avaliação e são propostas questões a serem analisadas. Assim, a escolha das categorias utilizadas no questionário proposto teve o intuito de deixá-lo fácil e rápido de aplicar e foram baseadas em alguns estudos: 8 categorias [Tsihouridis, 2011]: Compatibilidade de conteúdo, Documentação científica do conteúdo, Adequação do conteúdo, Ativação da motivação dos alunos, Ambiente bem projetado, Facilitação do uso, Extensão da interação entre o usuário e software e Compreensão do conteúdo; 4 categorias [Elissavet, 2000]: Conteúdo, Apresentação e organização do conteúdo, Suporte técnico e processo de atualização e Avaliação da aprendizagem; 4 categorias [Omar, 2009]: Questões de interface, pedagógicas, de multimídia e de jogabilidade; 7 categorias [Webber, 2009]: Características pedagógicas, Facilidade de uso, Características da interface, Adaptabilidade, Documentação, Portabilidade e Retorno do investimento; 16 categorias [Medeiros, 2012]: Classificação, Avaliação, Manutenibilidade, Portabilidade, Funcionalidade, Confiabilidade, Usabilidade, Eficiência, Afetividade, Layout favorável, Efeitos sonoros agradáveis, Clareza de conteúdo, Público alvo, Motivação, Favorecimento da aprendizagem, Adequabilidade psicopedagógica e Didática; 122

123 3 categorias [Savi, 2010]: Motivação dos usuários a usarem o jogo como método de aprendizado, Evidência de boa experiência nos usuários e Geração de sensação de utilidade educacional (alunos percebem que aprendem); 11 categorias [Gomes, 2002]: Idioma, Conteúdo abordado, Documentação (ficha técnica clara e objetiva, manual do professor, ajuda on-line), Público alvo, Aspectos pedagógicos (facilidade no acesso às informações, adequação a faixa etária, clareza nas informações, tipo de exercícios), Interface (facilidade de uso, interatividade, qualidade de áudio, gráficos e animação, recursos de avançar e recuar, adaptação), Conteúdo (fidelidade ao objeto, coerência de apresentação do conteúdo, correção dos exercícios, organização do conteúdo, promoção da criatividade, motivação dos usuários), Feedback (forma e qualidade da motivação), Aspectos técnicos (instalação, manipulação, apresentação visual, controle dos comandos), Avaliação (forma de avaliação, tempo destinado às respostas, forma de correção e de orientação) e Aspectos gerais (alcança os objetos propostos, contribui para a aprendizagem, preço compatível); 4 categorias [Morais, 2003]: Interação aluno-software educacional-professor, Fundamentação pedagógica, Conteúdo e Programação; 5 categorias [Hora, 2010]: Documentação, Questões operacionais, Questões relacionadas a características pedagógicas gerais, Questões relacionadas a propostas curriculares e Questões relativas a proposta pedagógica privilegiada no software; 3 categorias [Savi, 2011]: Capacidade de motivação dos jogos, Experiência do usuário e Melhoria da aprendizagem. Assim, três categorias foram escolhidas para elaborar o questionário e avaliar o ensino-aprendizagem, a motivação do aluno e a experiência adequada: Características específicas sobre Gerência de Projetos (conceito/conteúdo). A habilidade e o conhecimento tácito adquiridos em diversos projetos permitem ao gerente de projetos adquirir experiência, proporcionando melhores reações quando a tomada de decisão é necessária. Assim, sistemas de software educacionais podem preparar futuros profissionais em um ambiente virtual sem o risco de prejuízos. São aspectos importantes para a formação do profissional e para as exigências do mercado de trabalho [Zhang et al. 2010]; Aspectos lúdicos (Motivação). A maximização da eficiência da aprendizagem ocorre quando os usuários estão imersos na fantasia, nos aspectos lúdicos [Zhang et al. 2010]. O sistema de software educacional deve motivar os alunos, ser atrativo, despertar interesse pelo conteúdo, promover desafios e garantir a facilitação da aprendizagem. Essa categoria visa à avaliação de características que despertam, mantenham e direcionam o comportamento e a atenção dos usuários; Aprendizado focado nos usuários (Alunos). O aprendizado do conteúdo direcionado permite aos usuários aplicar o conhecimento aprendido em diversos contextos, efetivando o aprendizado [Zhang et al. 2010]. O aprendizado pode ser facilitado se o sistema for fácil de aprender, eficiente e agradável de usar, fácil para lembrar, adequado e regrado por uma disciplina específica. O conteúdo repassado deve ser claro e simples e erros/acertos devem favorecer a compreensão para o aluno interpretar a sua resposta anterior em novas perspectivas facilitando o aprendizado. A escala Likert foi adotada no questionário proposto por ser uma das mais conhecidas e utilizadas para registrar o nível de concordância dos respondentes. As opções de resposta variam de [Rodrigues; Santos, 2013] Concordo Fortemente, 123

124 Concordo, Indeciso, Discordo e Discordo Fortemente. As questões que compõem o questionário e a justificativa dessas questões são apresentadas de acordo com as categorias na Tabela 1, na Tabela 2 e na Tabela 3, respectivamente. Tabela 1 - Questões Específicas sobre Gerência de Projetos de Software O conteúdo de Gerência de Projetos é bem organizado e fácil de entender no software Questão 1 educacional. Essa questão analisa a adequação da organização e a facilidade do conteúdo de Gerência Justificativa de projetos. O software educacional facilita a construção do conhecimento e da habilidade de gerentes Questão 2 de projetos de software exemplificadas em aula. Permite avaliar o quanto o software intensifica o conhecimento e a habilidade Justificativa exemplificados em sala de aula. A teoria repassada em aula de Gerência de Projetos de Software é reforçada no software Questão 3 educacional. Determinar se o software educacional reforça/trabalha com a teoria sobre gerência de Justificativa projetos de software ensinada em aula pelo professor. Os meios utilizados para apresentar as informações no software educacional aumentam a Questão 4 compreensão do conteúdo. Permite avaliar como a forma de apresentação das informações pode influenciar na Justificativa compreensão do conteúdo. Questão 5 O software educacional é apropriado para os estudos de Gerência de Projetos de Software. Evidenciar o quanto o software é apropriado para o ensino de gerência de projetos de Justificativa software. O software educacional fornece conceitos/conteúdo e contribuição úteis para a construção Questão 6 de habilidades de Gerência de Projetos de Software. Avaliar a contribuição do software para a construção de habilidades sobre gerência de Justificativa projetos de software. Será que o software forneceu boa contribuição para o usuário? O software educacional facilita a assimilação de conceitos como: funções, estrutura Questão 7 organizacional de Gerência de Projetos de Software, ciclo de vida de projetos, planejamento, avaliação de projetos. Justificativa Avaliar o aprendizado de alguns conceitos sobre gerência de projetos de software. No projeto apresentado no software educacional, fico confiante em tomar iniciativa em Questão 8 questões que precisam de decisões importantes. Em determinadas situações do software educacional, o usuário sente confiança em tomar Justificativa decisões. O resultado final do software educacional foi satisfatório e refletiu minhas ações realizadas Questão 9 durante o jogo. Justificativa No final, o resultado refletiu as boas e as más decisões do usuário. Tabela 2 - Questões Específicas sobre Ludicidade Questão 1 A interface do software educacional é atraente e mantém a minha atenção. Identificar erros na interface que possam diminuir a motivação do usuário em utilizar o Justificativa software. A facilidade ajuda na utilização do software como material complementar a disciplina de Questão 2 Gerência de Projetos de Software. Identificar facilidade de utilização do software educacional na motivação para o usuário ter Justificativa confiança em utilizá-lo como material complementar ao aprendizado. Questão 3 Os aspectos de som, de texto, de imagem incentivam a utilizar o software educacional. Justificativa Avaliar o quanto os aspetos estéticos do software motivam os usuários a utilizá-lo. Ao completar o software educacional, senti-se realizado, satisfeito e com a certeza de que Questão 4 acrescentou conhecimento. Evidenciar o quanto o usuário está satisfeito com o software educacional e como essa Justificativa satisfação pode gerar motivação. Questão 5 Eu aprendi "aspectos" surpreendentes ou inesperados com o software educacional. Identificar motivação no aluno ao ser surpreendido com aspectos inesperados e tornando-o Justificativa satisfeito com a situação. O desafio proporcionado pelo software educacional manteve minha motivação para Questão 6 continuar jogando e aplicando os conceitos. 124

125 Tabela 2 - Questões Específicas sobre Ludicidade (cont.) Identificar o quanto o desafio é adequado e motivador aos usuários continuarem utilizando Justificativa o software educacional. O software educacional evolui em um ritmo adequado e não fica monótono - oferece novos Questão 7 obstáculos, situações ou variações de atividades. Identificar se software educacional não permite que o ambiente torne-se monótono, Justificativa promovendo constantemente a motivação. Questão 8 O software educacional é interativo e tem níveis de dificuldade. Identificar se software educacional ajuda na motivação proporcionando interatividade nas Justificativa atividades propostas e incluindo níveis de dificuldades em que o aluno possa evoluir. Questão 9 Fiquei muito entusiasmado com o software educacional. Justificativa Identificar incentivo a motivação/entusiasmo aos participantes a alcançarem seus objetivos. Tabela 3 - Questões Específicas sobre Sentimento do Usuário O software educacional proporcionou concentração nas ações sobre Gerência de Projetos Questão 1 de Software permitindo auxiliar no aprendizado. Justificativa Identificar se o software educacional proporciona concentração e auxilia no aprendizado. Questão 2 A interação com outros usuários permitiu simular interação em equipe. Identificar se existe interação entre usuários, pois gerentes de projetos de software Justificativa necessitam de trabalho em equipe para bom desenvolvimento do projeto. Questão 3 A quantidade de informações por tela do software educacional é adequada. Identificar se o volume de informações é adequado, considerando o tempo de leitura do Justificativa usuário e o quanto essa informação é relevante para o aprendizado. As funções básicas do software educacional são fáceis de usar, promovendo a interação e Questão 4 o aprendizado do usuário. Justificativa Determinar se a facilidade funcional do software educacional melhora o aprendizado. No software educacional, há situações-problema que envolveram a formulação de Questão 5 hipóteses, a investigação e/ou a comparação. Evidenciar o quanto as situações propostas pelo software educacional influenciam no Justificativa aprendizado e na forma de pensar do usuário. O feedback oferecido pelo software educacional auxiliou no entendimento das atividades e Questão 6 na melhora do aprendizado. O feedback auxilia na correção de erros cometidos pelo usuário, proporcionando confiança, Justificativa entendimento e aprendizado. Depois de utilizar o software educacional, compreendo e aplico melhor os temas Questão 7 apresentados e relacionados com Gerência de Projetos de Software. Justificativa O quanto o conhecimento gerado pelo software educacional foi internalizado pelo usuário. Questão 8 Após utilizar o software educacional, meu aprendizado educacional foi excelente. Justificativa Identificar o sentimento do usuário quanto ao aprendizado adquirido. Questão 9 O software educacional oferece manual do usuário. Identificar se existe manual e se está bem elaborado para auxiliar o usuário em suas Justificativa dúvidas. 4. Trabalhos Relacionados SimSE é um ambiente educacional interativo e gráfico para construção e simulação de processos em Engenharia de Software. A avaliação foi por meio de um questionário em que os jogadores relataram seus pensamentos, a opinião sobre a eficácia pedagógica do ensino e sobre sua formação educacional e profissional em Engenharia de Software [Navarro e Hoek 2005]. Foi proposta uma avaliação multiangular: avaliação in-class, avaliação com estudo comparativo, e avaliação com estudo observacional, os alunos jogaram SimSE por duas horas e preencheram um questionário [Navarro; Hoek, 2007]. Como a avaliação é limitada e às vezes inexistente, em um estudo [Savi; Wangenheim, 2011; Savi et al., 2010], foi utilizado um modelo para avaliar a utilidade de sistemas de software educacionais em Engenharia de Software, abrangendo a capacidade de 125

126 motivação, a experiência do usuário e a melhoria da aprendizagem. As questões foram selecionadas a partir de vários questionários. Em outro trabalho [Silva 2009], foi utilizado um conjunto de características avaliativas a serem observadas em um software educacional (funcionalidade, usabilidade, confiabilidade, eficiência, manutenibilidade e portabilidade) que podem integrar outros subcritérios mais detalhados a depender de cada software. Em outro estudo [Zhang et al. 2010], o modelo proposto foi baseado em princípios de design instrucional sistemático, consiste em seis partes divididas em níveis com pontuação: i) Relevância; ii) Incorporação; iii) Transferência; iv) Adaptação; v) Imersão; e vi) Naturalização. Em outro estudo [Medeiros e Costa, 2012], são apresentados métodos para avaliação de software educacional por visão psicopedagógica focando no processo de ensino-aprendizagem. O primeiro passo foi classificar o software como: instrução programada, tutorial, programação, aplicativos, exercícios e práticas, demonstração, simulação, software educativo e multimídia e internet. Depois, são recomendados critérios com nota de 0 a 10 e, no final, a média aritmética é calculada. Esses trabalhos buscam avaliar o software educacional com foco principalmente nas questões de ludicidade e motivação dos alunos (usuários), limitando a questão instrucional e os conceitos transmitidos. Alguns desses trabalhos utilizaram várias formas de avaliação, como questionários, entrevistas e filmagens. Este trabalho diferencia-se, pois seu objetivo é uma forma de avaliação, o questionário, com intenção de elaborá-lo de modo eficiente e com qualidade. O questionário proposto inclui questões de diversos tipos, abrangendo a avaliação de conceitos específicos de Engenharia de Software, com foco em Gerência de Projetos de Software, os aspectos lúdicos e o aprendizado. 5. Considerações Finais Anualmente, a quantidade de problemas em gerenciamento de projetos de sooftware é relativamente alta. Uma das possíveis causas pode ser o desconhecimento de práticas e de técnicas. Para a prevenção dessas situações, a utilização de estratégias diferentes de ensino pode auxiliar, sendo uma os sistemas de software educacionais para preparar os futuros gerentes de projetos. Esses sistemas incentivam o processo de ensinoaprendizagem e o conhecimento utilizando atividades lúdicas, motivação, contribuição com o ensino prático de Gerência de Projetos desenvolvendo diferencial na formação acadêmica. Os sistemas de software educacionais em que o conteúdo de aprendizagem é embutido na fantasia e na ludicidade, os usuários podem dominar os objetivos e aprender novos conhecimentos, dominar regras e aplicá-las em níveis elevados com facilidade [Zhang et al. 2010]. Os usuários são a categoria de avaliadores mais significativa, portanto a opinião deles é importante e auxilia na escolha de software educacional interessante, agradável e adequado ao ensino [Tsihouridis et al. 2011]. As categorias e as questões elaboradas para o questionário proposto foram pensadas para contribuir com a avaliação de sistemas de software educacionais, ajudando no desenvolvimento e na escolha adequada desses sistemas pelos professores. Esse feedback oferecido pelos usuários pode fornecer melhorias e opiniões adequadas. Como sugestões para a continuidade deste trabalho são identificar técnicas e métodos para avaliar e evidenciar características do questionário de avaliação que 126

127 permitam afirmar sua efetividade, sua eficácia e sua elaboração correta para avaliar os softwares educacionais, realizar testes e fazer comparação a outros questionários. Referências Andres, D.; Cybis, W. Um Estudo Teórico sobre as Técnicas de Avaliação de Software Educacional. In: VI Congreso Argentino de Ciencias de la Computación, Baker, A.; Navarro, E.; Hoek A. An Experimental Card Game for Teaching Software Engineering Processes. In: Journal of Systems and Software, v.75. pp. 3-16, Campos, A.; Signoretti, A.; Lima, P.; Luis, L.; Fontes, M.; Dantas, K. Um Jogo Voltado à Prática de Gerenciamento de Projetos. In: XXII SBIE - XVII WIE Aracaju, Dantas, A. R. Jogos de Simulação no Treinamento de Gerentes de Projetos de Software. Tese de Doutorado. Engenharia da UFRJ Drappa, A., Ludewig, J. Simulation in Software Engineering Training. In: International Conference on Software Engineering. pp Elissavet, G.; Economides, A. Evaluation Factors of Educational Software. In: International Workshop on Advanced Learning Technologies. pp Figueiredo, E.; Lobato, C. A.; Dias, K.; Leite, J. C. S. P.; Lucena, C. J. P. SimulES: Um Jogo para o Ensino de Engenharia de Software. Relatório Técnico. 38p Freire, F. M. P.; Rocha, H. V. da; Valente, J. A.; d'abreu, J. V. V.; Baranauskas; M. C. C.; Martins, M. C.; Prado; M. E. B. B. O Computador na Sociedade do Conhecimento. Ministério da Educação. ProInfo - Programa Nacional Informática na Educação, Freire, F.; Prado, M.; Martins, M.; Sidericoudes, O. A Implantação da Informática no Espaço Escolar: Questões Emergentes ao Longo do Processo. In: Revista Brasileira de Informática na Educação. pp Gomes, A. S.; Castro Filho, J. A.; Gitirana, V.; Spinillo, A.; Alves, M.; Melo, M., Ximenes, J. Avaliação de Software Educativo para o Ensino de Matemática. In: Workshop de Informática na Educação, Hora, H. R. M.; Monteiro, G. T. R.; Arica, J. Confiabilidade em Questionários para Qualidade: Um Estudo com o Coeficiente Alfa de Cronbach. In: Produto & Produção, vol. 11, n. 2, pp , Isotton, E. Scrumming - Ferramenta Educacional para Ensino de Práticas de SCRUM. Trabalho de Conclusão de Curso. Graduação em Bacharelado em Sistemas de Informação. Pontifícia Universidade Católica do Rio Grande do Sul Keller, J. M. Motivational Design for Learning and Performance: The ARCS Model Approach. Springer, Kieling, E.; Rosa, R. Planager - Um Jogo para Apoio ao Ensino de Conceitos de Gerência de Projetos de Software. Trabalho de Conclusão do Curso de Bacharelado em Ciência da Computação. FACIN. PUCRS Kirkpatrick, D. L. Evaluating Training Programs - The Four Levels. Berrett-Koehler Publishers, Inc, Medeiros F., F.; Costa, R. A. Uma Proposta de Método para a Avaliação de Softwares Educacionais através de uma Visão Psicopedagógica. In: Revista Tecnologias na Educação. Ano 4. N

128 Mira, S.; Santos, R.; Costa, H. ProMEG: Um Jogo para Ensino de Gerência de Projetos com Foco na Gerência de Recursos Humanos. In: Fórum de Educação em Engenharia de Software Molléri, J. Utilizando o RPG como Ferramenta de Aprendizado para o Processo de Desenvolvimento de Software. Trabalho de Conclusão de Curso. Curso de Ciência da Computação. UNIVALI Morais, R. X. T. Software Educacional: A Importância de sua Avaliação e do seu Uso nas Salas de Aula. Fortaleza, Moratori, P. Por Que Utilizar Jogos Educativos no Processo de Ensino Aprendizagem? Universidade Federal do Rio de Janeiro, RJ, Nascimento, J. K. F. Informática Aplicada à Educação. Curso Técnico de Formação para os Funcionários da Educação Navarro, E.; Hoek, A. Comprehensive Evaluation of an Educational Software Engineering Simulation Environment. In: Conference on Software Engineering Education & Training. pp Navarro, E.; Hoek, A. Design and Evaluation of an Educational Software Process Simulation Environment and Associated Model. In: Conference on Software Engineering Education & Training. pp , Omar, H.; Jaafar, A. Conceptual Framework for a Heuristics Based Methodology for Interface Evaluation of Educational Games. In: International Conference on Computer Technology and Development, Paludo, L.; Raabe, A. Análise de Jogos Educativos de Computador para Gerência de Projetos de Software. In: Workshop sobre Educação em Computação Rodrigues, A. N.; Santos, S. C. Aplicando a Taxonomia de Bloom Revisada para Gerenciar Processos de Ensino em Sistemas de Aprendizagem Baseada em Problemas. In: Revista Brasileira de Informática na Educação. V. 21. N. 1, Savi, R.; Wangenheim, C. A Model for the Evaluation of Educational Games for Teaching Software Engineering. In: Brazilian Symposium on Software Engineering. pp Savi, R.; Wangenheim, C.; Ulbricht, V. Vanzin, T. Proposta de um Modelo de Avaliação de Jogos Educacionais. In: RENOTE - Revista Novas Tecnologias na Educação. UFRGS Silva, R. Avaliação de Software Educacional: Critérios para Definição da Qualidade do Produto. In: Simpósio Nacional ABCiber Tarouco, L.; Roland, L; Fabre, MC; Konrath, M. Jogos Educacionais. In: Novas Tecnologias na Educação. V. 2. N Tsihouridis, C.; Batsila, M.; Vavougios, D.; Ioannidis, G. Enhancing and Assisting Laboratory Teaching of Electrical Circuits using ICT: An Evaluation of Educational Software. In: International Conference on Interactive Collaborative Learning. pp Webber, C.; Boff, E.; Bono, F. Ferramenta Especialista para Avaliação de Software Educacional. In: Simpósio Brasileiro de Informática na Educação, Zhang, H.; Fan, X.; Xing, H. Research on the Design and Evaluation of Educational Games Based on the RETAIN Model. In: International Symposium on Knowledge Acquisition and Modeling. pp

129 Uma Revisão Sistemática sobre Práticas de Comunicação na Gerência de Projetos de Software - Estudos Primários Vinícius Maretti, Heitor Costa Departamento Ciência da Computação - Universidade Federal de Lavras Caixa Postal CEP Lavras - MG - Brasil vimaretti@sistemas.ufla.br, heitor@dcc.ufla.br Abstract. Communication is a critical factor that directly influences on project s success, no matter its type or the industry type it is within. However, many IT professionals end up ignoring its importance and focusing on technical skills. Taking in consideration the lack of material and its dissemination amongst the various other scientific works, in this paper, we presented a compilation of resulting papers of a systematic literature review that treating of Communication Management in Software Project Management. After the review, 804 papers were identified, but only 33 papers met inclusion and exclusion criteria. Resumo. A comunicação é um dos fatores críticos que influenciam diretamente no (in)sucesso de um projeto independentemente do seu tipo ou da indústria em que é desenvolvido. Mesmo sendo indispensável, esse fator ainda é negligenciado por profissionais da área de Tecnologia da Informação, que optam por dar foco aos elementos técnicos. Considerando a falta de material de apoio e sua disseminação em vários projetos e trabalhos científicos, neste trabalho, é apresentada uma compilação de trabalhos resultantes de uma revisão sistemática de literatura que abordam Gerência de Comunicação na Gerência de Projetos de Software. Com essa revisão, foram identificados 804 estudos, dos quais 33 estudos atenderam os critérios de inclusão e exclusão. Aluno: Vinícius Benitez Maretti Orientador: Heitor Augustus Xavier Costa Categoria: Trabalho de Conclusão de Curso de Graduação Estágio do Trabalho: Em Desenvolvimento 1. Introdução Projetos de software, independente do seu tamanho, complexidade ou indústria, necessitam de regras e de princípios para serem gerenciados corretamente e concluídos com sucesso. Por ser um processo iterativo, a gerência de projetos pode ser considerada uma sequência de atividades que envolvem aplicação de conhecimento, de habilidades, 129

130 de ferramentas e de técnicas a serem empregados para o projeto atender/exceder as expectativas e as necessidades das partes interessadas [Rehman; Hussain, 2007]. Diferentes estratégias competitivas e de negócios levam a diferentes tipos de gerência de projetos [Milosevic; Srivannaboon, 2006]. Porém, o gerente de projetos deve ter a capacidade de coordenar atividades e processos para que, ao final, as necessidades sejam totalmente atendidas. Um bom gerente de projetos deve possuir [Ndhlovu; Weeks, 2013] habilidades mensuráveis (técnica de programação, financeira, gerenciamento de tempo, gerenciamento de risco e cálculo de desempenho), qualificação e habilidades não mensuráveis (perspectiva, negociação, solução de problemas, calma em circunstâncias de pressão e comunicação). Apesar da crescente sofisticação das técnicas, dos métodos e das ferramentas, o desenvolvimento de projetos de software permanece não confiável na perspectiva da indústria, o que pode ser consequência da negligência de fatores humanos, por exemplo, a comunicação [Hall et al., 2007], apontada como a habilidade mais importante em qualquer disciplina. Em Engenharia de Software, a capacidade comunicativa tem sido citada como um dos problemas mais enfrentados, resultando em projetos falhos e causando insatisfação de usuários e clientes [Muller, 2003]. Assim, definir uma maneira para resolver esse gap e identificar qual a técnica de comunicação mais adequada tornase indispensável aos profissionais da área. Neste artigo, o objetivo é apresentar um estudo inicial (estudos primários) de trabalhos científicos que documentam práticas e técnicas de comunicação utilizadas nas empresas no contexto de gerência de projeto de software. Por tratar de um estudo de técnicas relacionadas à comunicação, os gerentes de projetos e estudiosos da área podem utilizar esse trabalho na fase de planejamento e no auxílio nas tomadas de decisão, não precisando recorrer a diferentes fontes científicas para extrair informações relevantes. O restante do artigo está organizado da seguinte forma. Conceitos de gerência de projetos e de gerência de comunicação e a técnica de Revisão Sistemática da Literatura (RSL) são brevemente destacados na Seção 2. Seleção de estudos primários é apresentada na Seção 3. Trabalhos relacionados estão resumidos na Seção 4. Conclusões e sugestões de trabalhos futuros são apresentadas na Seção Background Nesta seção, são apresentados conceitos de gerência de projetos de software, a importância da comunicação em projetos de software e a protocolo de execução de uma Revisão Sistemática de Literatura Gerência de Projetos Um projeto é um esforço temporário para criar um produto, serviço ou resultado único. Temporário significa que os projetos possuem início e término definidos. O término é alcançado quando os objetivos tiverem sido atingidos e o projeto for encerrado, quando um projeto é cancelado ou quando a necessidade do projeto não existe mais. Temporário não significa necessariamente de curta duração, pois projetos podem durar anos para serem concluídos [PMBoK, 2013]. PMBoK (Project Management Body of Knowledge) é um guia, amplamente utilizado por vários setores da indústria, inclusive pela indústria de software, criado e mantido pelo Project Management Institute, que consiste na 130

131 junção das melhores práticas de gerenciamento de projetos disponíveis no mercado. As boas práticas no PMBoK são aplicáveis a projetos e tem-se consenso sobre o seu valor e sua usabilidade, pois têm sido alimentadas pelos próprios praticantes da área [Deshpande et al., 2013]. No PMBoK, são sugeridos 47 processos organizados em cinco grupos de processos [PMBoK, 2013; Gaffo; Barros, 2012]: i) processos de iniciação; ii) processos de planejamento; iii) processos de execução; iv) processos de monitoramento e controle; e v) processos de encerramento. Além disso, esses processos estão organizados em dez áreas de conhecimento [PMBoK, 2013; Scofano et al., 2013]: i) gerenciamento de integração; ii) gerenciamento de escopo; iii) gerenciamento de tempo; iv) gerenciamento de custos; v) gerenciamento de qualidade; vi) gerenciamento de recursos humanos; vii) gerenciamento de comunicações; viii) gerenciamento de riscos; ix) gerenciamento de aquisições; e x) gerenciamento de partes interessadas. Apesar da crescente sofisticação de técnicas, de métodos e ferramentas, o desenvolvimento de projetos de software permanece não confiável na perspectiva da indústria, o que pode ser consequência da negligência de fatores humanos, por exemplo, comunicação [Hall et al., 2007]. As dificuldades dos projetos estão em manter seu custo, sua agenda e sua qualidade. Pobre gerenciamento pode aumentar o custo dos projetos mais rapidamente que qualquer outro fator [Merrill; Collofello, 1997] Comunicação em Projetos de Software Um dos principais personagens em um projeto de software é o gerente de projetos, que deve demandar maior parte do seu tempo tornando a comunicação efetiva entre os membros do time e as partes interessadas. Ele deve ser capaz de integrar e de avaliar a comunicação de acordo com os diferentes pontos de vista além de planejar, de organizar e de controlar o processo de desenvolvimento de software [Wang; Zhen-hua, 2010]. Em projetos de software, nem sempre as partes envolvidas possuem a mesma cultura. Desenvolvedores, clientes e gerentes podem ter diferentes princípios éticos, hábitos linguísticos e habilidades comunicativas. Essas diferenças podem tornar a comunicação e a colaboração entre os membros da equipe difícil ou impedir o desenvolvimento do sentimento mútuo de confiança [Tarawneh et al., 2008]. Muitos pesquisadores sugerem que boas habilidades comunicativas em projetos de software são fatores críticos de sucesso. Sua importância começa na obtenção de requisitos, em que pobre comunicação pode levar ao descumprimento dos objetivos do projeto ou indicar requisitos não solicitados pelos clientes [Hall et al., 2007]. No gerenciamento de comunicações, há processos necessários para assegurar que as informações do projeto sejam geradas, coletadas, distribuídas, armazenadas, recuperadas e organizadas oportuna e apropriadamente [PMBoK, 2013]: i) planejar a gerência de comunicações; ii) gerenciar comunicações; e iii) controlar comunicações Revisão Sistemática da Literatura A Revisão Sistemática da Literatura (RSL) é uma técnica para identificar, avaliar e interpretar estudos ou pesquisas disponíveis e relevantes para uma questão de pesquisa específica, área temática ou fenômeno de interesse. Os estudos individuais empíricos diretamente relacionados à questão em pesquisa são chamados estudos primários. Estudos secundários visam revisar, investigar e sintetizar as evidências identificadas nos 131

132 estudos primários [Kitchenham, 2004]. Dessa forma, a RSL pode ser considerada um estudo secundário e sua aplicação segue um roteiro com estratégias e critérios prédefinidos de seleção e de análise de documentos [Kitchenham, 2004; Hall et al. 2012; Atallah; Castro, 1997; Zhang; Babar, 2011; Kitchenham, 2007]: Fase Planejamento. O motivo da realização da RSL é estabelecido. Seus tópicos são: i) Descrição da Pesquisa: motivações e objetivos para a pesquisa; ii) Definição de Questões de Pesquisa: questões relacionadas às motivações da pesquisa; iii) Desenvolvimento do Protocolo: protocolo a ser aplicado às buscas; e iv) Avaliação do Protocolo: avaliação da aplicação da RSL; Fase Execução. A investigação em fontes definidas na fase anterior é realizada. O estudo e a classificação dos trabalhos encontrados podem ser feitos, guiados pelos critérios de inclusão e de exclusão. Seus tópicos são: i) Obtenção das Pesquisas: busca nas fontes definidas, organizando os resultados por algum critério para facilitar as próximas etapas; ii) Seleção Primária: primeira seleção dos resultados obtidos; iii) Seleção Secundária: segunda seleção realizada, cujo objetivo é eliminar resultados não apropriados. Os artigos são lidos e verificados quanto ao atendimento dos critérios; e iv) Organização dos Resultados: artigos selecionados são organizados para serem analisados; Fase Análise dos Resultados. A coleta e a organização dos dados extraídos dos artigos selecionados. O resultado é analisado de maneira global, gerando melhor planejamento. Seus tópicos são: i) Coleta e Organização dos Dados: resultados obtidos na Seleção Secundária são lidos e interpretados. Os dados são extraídos e organizados em forma de um relatório, cujo conteúdo responde as questões de pesquisa definidas no protocolo; e ii) Avaliação dos Resultados: relatório é revisado para buscar a publicação dos resultados. 3. Seleção de Estudos Primários 3.1. Questões de Pesquisa O objetivo é identificar estudos sobre técnicas de comunicação utilizadas no contexto de gerência de projetos de software. A seguinte questão de pesquisa foi formulada: Quais são as técnicas utilizadas para tratar a comunicação entre as partes interessadas no contexto de gerência de projetos de software? 3.2. Seleção de Fontes e String de Busca Para execução da RSL, foram selecionadas como fontes de busca, ferramentas de busca na web, destinadas a busca extensiva de textos científicos completos e metadados. A seleção das fontes foi conduzida seguindo os critérios: i) deveria conter a opção de pesquisa avançada com utilização de palavras-chave; ii) filtragem dos resultados por ano de publicação e área e/ou tipo de publicação; e iii) exportação do resultado da consulta em formato BibTex. Essas máquinas deveriam apresentar invariabilidade no resultado da busca quando utilizado o mesmo conjunto de palavras-chave. A partir dessas condições, foram escolhidas as seguintes fontes de pesquisa: i) IEEE ( ii) Scopus ( e iii) Elsevier ( 132

133 Dentre as fontes de busca pré-selecionadas, inicialmente a ACM Digital Library foi considerada como repositório a ser utilizado. Porém, apresentou navegabilidade insatisfatória e não disponibiliza opção de exportação do resultado da consulta. A sua máquina de busca disponibiliza opção de exportação por resultado, mas a exportação de alguns documentos possuem falhas como falta do resumo (abstract) e arquivos vazios. Em um estudo realizado sobre as máquinas de busca [Bailey et al., 2007], constatou-se que resultados fornecidos pela máquina de busca da ACM são inconsistentes em algumas situações. Para realizar as buscas, foi utilizada a string de busca, construída com base nas palavras-chave e nos sinônimos definidos no protocolo da pesquisa: (("communication management" OR "project communication management" OR "communication structures" OR "human communication") AND ("project management" OR "information technology project management" OR "software development management" OR "information systems management" OR "software management")) 3.3. Critérios de Inclusão e Exclusão Como critérios de inclusão, foram considerados: i) artigos completos publicados; ii) ser da área de ciência da computação; iii) ter sido publicado entre 2000 e 2014; iv) ser artigo de Journal ou Conference Paper; v) ter sido publicado no idioma Inglês; e, vi) apresentar estudo sobre a utilização de boas práticas de comunicação no contexto de gerência de projetos de software. Como critérios de exclusão, foram desconsiderados: i) texto de acesso restrito; ii) textos incompletos; iii) artigos In press (ainda não publicados efetivamente); iv) não artigos (por exemplo, Table of contents, Index e Standards); v) textos duplicados; e, vi) não atendem o critério de inclusão Resultados Preliminares Nesta seção, os resultados da RSL são apresentados (Tabela 1). Para cada fonte de pesquisa, a mesma string de busca construída foi utilizada, adequando-a as suas restrições. Foram encontradas 868 referências distribuídas em 374 referências no IEEE (43,1%), 253 referências no Elsevier (29.1%) e 241 referências no Scopus (27,8%). Tabela 1 - Seleção Primária Fontes Total Seleção Primária Não Artigos Repetidos Excluídos Incluídos IEEE Elsevier Scopus Total A maior quantidade de referências foi obtida no IEEE, sendo 16 referências do tipo Table of Contents, Index e Standards (4,3%), nenhuma referência repetida e 339 referências irrelevantes (90,6%). Ao final, o resultado foi de apenas 19 referências (artigos) relevantes (5,1%). No repositório da IEEE, a busca pode ser filtrada pelo tipo de publicação (Conference Publications, Journals & Magazines e Standards), ano de publicação e tópicos, mas não possibilita a seleção das opções simultaneamente. A seleção das opções, segundo os critérios de inclusão, foi feita manualmente e os resultados foram atualizados conforme a aplicação de cada filtro estabelecido. 133

134 No Scopus, a máquina de busca retornou 7 referências do tipo Table of Contents, Index e Standards (2,9%), 6 referências repetidas (2,5%), 225 referências irrelevantes (93,3%) e 3 referências (artigos) relevantes (1,3%). Os filtros utilizados na máquina foram: Year (com publicação igual ou superior a 2000); Subject Area (com valor Computer Science), Document Type (com valores Conference Paper e Articles), Source Type (com valores Conference Proceedings e Journals) e Language (com o valor English). A busca no Elsevier foi realizada na opção Expert Search, selecionando a opção Journals. O campo Articles in press foi desmarcado. Foram usados os filtros Sources (com valor All Journals), Subject (com valor Computer Science), Limit by document type (com valores Articles, Review Article e Short Survey), Date Range (com período de "2000 a 2014", inclusive) e Topic (com valores software, computer science, information system). A máquina de busca retornou 1 referência repetida (0,1%), 240 referências irrelevantes (95,0%) e 11 referências (artigos) relevantes (4,8%). Na Tabela 2, são apresentados ano, título e fonte dos 33 artigos selecionados (4,1%) como estudos primários. Os artigos nessa tabela estão em ordem alfabética de suas fontes, ano de publicação e ordem alfabética de título. Tabela 2 - Estudos Primários # Ano Título Autores Fonte Determinants for external communications of IT project Müller, R. Elsevier managers Virtuality, communication, and new product team creativity: a social network perspective Communication skills importance and proficiency: perception differences between IS staff and IS users Cultural differences in project management capabilities: A field study The impact of principal-agent relationship and contract type on communication between project owner and manager Managing cross-cultural communication in multicultural construction project teams: The case of Kenya and UK Do project managers practice what they preach, and does it matter to project success? Projects as communicating systems: Creating a culture of innovation and performance Exploring the impact of communication effectiveness on service quality, trust and relationship commitment in IT services Internal communication: Definition, parameters, and the future The impact of a call centre on communication in a programme and its projects On Inter-Organizational EC Collaboration.The impact of Inter- Cultural Communication Apprehension Leenders, R. Th. A. J. Engelen, J. M. L. van Kratzer, J. Chena, H. H. G. Millerb, R. Jianga, J. J. Kleind, G. Zwikaela, O. Shimizub, K. Globersonc, S. Müllera, R. Turnerb, J. R. Ochienga, E. G. Priceb, A. D. F. Papke-Shields, K. E. Beise, C. Quan, J. Johannessena, J-A. Olsenb, B. Parka, J. Leea, J. Leea, H. Truexb, D. Verčiča, A. T. Verčičb, D. Srirameshc, K. Bond-Barnarda, T. J. Steyna, H. Fabris-Rotellib, I. Kwok, R. C.-W. Lee, M. Turban, E. Elsevier Elsevier Elsevier Elsevier Elsevier Elsevier Elsevier Elsevier Elsevier Elsevier IEEE 134

135 Tabela 2 - Estudos Primários (cont.) # Ano Título Autores Fonte Leaders, Managers and Producers: Repositioning Technical Williams, S. D. IEEE Communication for the Creative Economy Managing Collaboration: Adding Communication and Feinberg, S Documentation Environment (CDE) to a Product Development IEEE Batson, L. Cycle Improving Group Communication Outcomes with Collaborative Software: The Impact of Group Size, Media Richness, and Social Presence The Role of Cultural Factors in Software Projects Development Effective Communication for Software Professionals Relationship Research Between Communication Activities and Success Indexes in Small and Medium Software Projects Effects of Project Manager s Competency on Project Success Roberts, T. L. Lowry, P. B. Cheney, P. H. Hightower, R. T. Tarawneh, M. AL-Tarawneh, H. Elsheikh, A. Sethuraman, C. Srivatsa, S. K. Lu, X. Liu, L. Liu, L. Ehsan, N. Waheed, K. Z. Asghar, U. Nawaz, M. T. Mirza, E. Sarwar, S. Z Project Suggestions Planning Process Bejestani, H. S. IEEE Research on Multi-Perspective Communication Management of Qian, W Software Development Project Based on Theory of Project IEEE Zhen-hua, S. Management Leadership Research for Delivery Project Manger Based on Theory of Project Management Learning to Work in Partially Distributed Teams: An Analysis of Emergent Communication Structures and Technology Appropriation Wang, H. Ocker, R. J. Webb, H. C. Hiltz, S. R. Brown, I. D Project Sustainability by Communicating Opportunity Bejestani, H. S. IEEE Farias Junior, I. H Silva, D. S. M. Elicitation of Communication Inherent Risks in Distributed Azevedo, R. R. Software Development Noura, H. P. de IEEE Impact of Communication Structure on System Design: Towards a Controlled Test of Conway s Law The Change Announcement: Implications for Communicating Change using Organizational Culture The Role of Domain Knowledge and Cross-Functional Communication in Socio-Technical Coordination Towards a Communication Maturity Model For Distributed Software Development Using the PMBOK Guide to frame GSD Coordination Strategies The Impact of Communication Structure on New Product Development Outcomes Blatter, K. L. Gledhill, T. J. Krein, J. L. Knutson, C. D. Broillet, A. Barchilon, M. Kampf, C. Damian, D. Helms, R.; Kwan; I. Marczak, S. Koelewijn, B. Farias Junior, I. H. Moura, H. P. de Marczak, S. Deshpande, S. Beecham, S. Richardson, I. Cataldo, M. Ehrlich, K. IEEE IEEE IEEE IEEE IEEE IEEE IEEE IEEE IEEE IEEE IEEE IEEE Scopus 135

136 Tabela 2 - Estudos Primários (cont.) # Ano Título Autores Fonte Chen, Q.-L A model for project communication medium evaluation and Wei, C.-S. selection Huang, M.-Y. Scopus Wei, C.-C. Hummel, M The Role of Communication in Agile Systems Development Rosenkranz, C. Holten, R. Scopus 4. Trabalhos Relacionados Os trabalhos relacionados escolhidos por serem similares ao tema de pesquisa, sendo de utilidade para verificar os resultados obtidos e possíveis limitações, apresentam críticas sobre as atuais práticas de comunicação na área de gerência de projetos, por exemplo, o modelo Shannon-Weaver. Além disso, eles apresentam um novo modelo conceitual para comunicação em Tecnologia da Informação. Em outros, é considerado o impacto da comunicação na qualidade de um projeto de software e, com estudos de caso, pode ser comprovado o impacto significante no andamento e no gerenciamento do projeto de software quando as equipes conversam mais e da maneira correta. Em um trabalho [McKay et al., 2014], foi realizado um estudo sobre o conhecimento existente na prática do gerenciamento de projetos e propostas de mudanças na maneira que os projetos são conceituados, retirando o foco da entrega do produto e transferindo-o para entrega de valor. O objetivo foi comprovar que a comunicação é vital na prática de gerência de projetos e deve estar embutida e integrada em outros processos para que haja melhora no ambiente de Tecnologia da Informação de uma empresa. Após um estudo sobre os modelos de Shannon-Weaver e Galle, o resultado foi uma proposta de nova metodologia baseada nas suas limitações, em que os aspectos produtivos e interpretativos da comunicação são destacados, levando em consideração as partes interessadas e as diferentes dificuldades de comunicação. Em outro trabalho [Damian et al., 2013], foi estudado o fluxo de informação entre diferentes cargos em dois projetos de software com diferentes estruturas de comunicação. Com a utilização de técnicas como observação, entrevistas e pesquisas, foi observado como os diferentes papéis de um projeto (gerente, desenvolvedor, etc.) coordenaram sua comunicação em tarefas dependentes. Em um mesmo projeto, há pessoas com diferentes conhecimentos de domínio. Quando for designar tarefas, cabe ao gerente de projetos balancear as habilidades técnicas e de domínio das pessoas e estabelecer uma relação de comunicação, geográfica e funcional entre os diversos setores do projeto. Dessa maneira, foi identificada a necessidade de atentar para a comunicação que surge de tarefas designadas e de reuniões informais e inesperadas. Este trabalho e os trabalhos relacionados diferem-se em algumas abordagens adotadas, por exemplo, (i) a utilização da técnica Revisão Sistemática da Literatura, (ii) o agrupamento de técnicas mais e menos eficientes de comunicação na gerência de projetos (difere deste trabalho, pois geralmente considera apenas determinado contexto) e (iii) o estudo mais aprofundado da comunicação dentro do PMBoK. Podem ser destacadas algumas similaridades, por exemplo, (i) o estabelecimento de diretrizes apoiadas por estudos de caso de terceiros, (ii) a centralização da comunicação como um dos principais ativos de um projeto, (iii) a discussão sobre os diferentes tipos de 136

137 personalidade e perspectivas dentro de um time e (iv) o foco no contexto de gerência de projetos. 6. Considerações Finais A comunicação é um dos fatores mais importantes no contexto de gerência de projetos de software. No entanto, muitas vezes, habilidades técnicas são sobrepostas às habilidades comunicativas, levando ao insucesso de muitas empreitadas. Lado a lado com sua importância, está sua complexidade, pois há fatores, como cultura, linguagem e localização, que podem influenciar de maneira positiva e/ou negativa na aplicação de um plano de comunicação. Apoiado por tal premissa, este trabalho apresenta uma revisão sistemática feita na área engenharia de software e é útil para que os profissionais do ramo possam utilizálo como um guia para futuras referências ou como apoio a tomadas de decisão em assuntos relacionados à comunicação em gerência de projetos de software. Nesse contexto, seu objetivo é apresentar um levantamento de trabalhos científicos que documentam as práticas e técnicas de comunicação definidas por outros estudos. Como sugestões de trabalhos futuros, espera-se identificar técnicas, ferramentas e dificuldades encontradas ao desenvolver um plano de comunicação, classificar as técnicas encontradas de acordo com sua maior relevância para o mercado de trabalho e para os profissionais da área e, em seguida, realizar uma análise mais profunda por meio de estudos de caso nos quais elas foram utilizadas como solução para problemas de comunicação em projetos de software. Referências Atallah, N. A.; Castro, A. A. (1997) Revisões Sistemáticas da Literatura e Metanálise: A Melhor Forma de Evidência para Tomada de Decisão em Saúde e a Maneira mais Rápida de Atualização Terapêutica. Diagnóstico & Tratamento. v.2, n.2, p Bailey, J.; Zhang, C.; Budgen, D.; Charters, S.; Turner, M. (2007) Search Engine Overlaps: Do they agree or disagree? Second International Workshop on Realising Evidence-Based Software Engineering, pp Damian, D.; Helms, R.; Kwan, I.; Marczak, S.; Koelewijn, B. (2013). The Role of Domain Knowledge and Cross-Functional Communication in Socio-Technical Coordination. In: International Conference on Software Engineering. pp Deshpande, S.; Beecham, S.; Richardson, I. (2013). Using the PMBOK Guide to Frame GSD Coordination Strategies. In: International Conference on Global Software Engineering. pp Gaffo, F. H.; Barros, R. M. D. (2012) GAIA Risks - A Service-Based Framework to Manage Project Risks. In: XXXVIII Conferencia Latinoamericana, pp Hall, T.; Beecham, S.; Bowes, D.; Gray, D.; Counsell S. (2012). A Systematic Literature Review on Fault Prediction Performance in Software Engineering. Transaction Software Engineering. 38, 6. pp

138 Hall, T.; Wilson, D.; Rainer, A.; Jagielska, D. (2007). The Neglected Technical Skill? In: Conference on Computer Personnel Research: The Global Information Technology Workforce. pp Kitchenham, B. A. (2007) Guidelines for Performing Systematic Literature Review in Software Engineering. EBSE Technical Report, 2.3, Keele University. Kitchenham, B. A. (2004) Procedures for Undertaking Systematic Reviews. Joint Technical Report. Computer Science Department. Keele University (TR/SE-0401) and National ICT Australia Ltd. ( T.1). McKay, J.; Marshall, P.; Grainger, N. (2014). Rethinking Communication in IT Project Management. In: International Conference on System Science. pp Merrill, D.; Collofello, J. (1997). Improving Software Project Management Skills Using a Software Project Simulator. Arizona State University, Department of Computer Science and Engineering. Milosevic, D.; Srivannaboon, S. (2006). A Theoretical Framework for Aligning Project Management with Business Strategy. In: Project Management Journal. pp Muller, R. (2003). Determinants for external communications of IT project managers. International Journal of Project Management 21. pp Ndhlovu, P.; Weeks, R. (2013). Analysis of the Career Path and Skills Required by Project Managers: An Energy Sector Perspective. In: Technology Management in the IT-Driven Services. pp of Information Management. pp PMBoK. (2013) A Guide to the Project Management Body of Knowledge, Project Management Institute. Ed. 5, Newtown Square, Pennsylvania, USA. Rehman, A. U.; Hussain, R. (2007). Software Project Management Methodologies/Frameworks Dynamics - A Comparative Approach. In: International Conference on Information and Emerging Technologies. pp Scofano, C. R. F.; Abraham, E. de F.; Silva, L. de S.; Teixeira, M. A. (2013) Gestão de Risco em Projetos: Análise das Etapas do PMI-PMBok (Project Management Institute). In: X Congresso Online de Administração. Tarawneh, M. M.; Al-Tarawneh, H.; Elsheikh, A. (2008). The Role of Cultural Factors in Software Projects Development. In: IEEE. pp Wang, Q.; Zhen-hua, S. (2010). Research on Multi-Perspective Communication Management of Software Development Project Based on Theory of Project Management. In: International Conference on Signal Processing Systems. pp Zhang, H.; Babar, M. A. (2011). An Empirical Investigation of Systematic Reviews in Software Engineering. International Symposium on Empirical Software Engineering and Measurement. pp

139 Engenharia de Software Baseada em Buscas: Uma Visão de Gestão de Projetos Aluno:Lucas Barbosa Contreiro, Orientadora: Daniela Cristina Cascini Peixoto Categoria: Trabalho de Conclusão de Curso Estágio: Em Desenvolvimento Centro Federal de Educação Tecnológica de Minas Gerais (CEFET-MG) Caixa Postal Belo Horizonte MG Brasil Abstract. Search-based Software Engineering (SBSE) applies search-based optimization techniques in order to solve complex Software Engineering problems. In the recent years there has been a dramatic increase in the number of SBSE applications in areas such as Software Test, Requirements Engineering and Project Planning. Our focus is on problems related to Project Management, specifically, the elaboration of a conceptual model that covers important aspects of the resource and scheduling problem. This model is based on the best practices of Software Engineering, on concepts defined in previous researches and on our experience. The goal is to help project managers during the planning elaboration. Resumo. Engenharia de Software Baseada em Buscas (SBSE) aplica técnicas de otimização com o objetivo de resolver problemas complexos de Engenharia de Software. Nos últimos anos houve um aumento dramático no número de aplicações de SBSE em áreas como Testes de Software, Engenharia de Requisitos e Planejamento de Projetos. Nosso foco está em problemas relacionados com a Gestão de Projetos, especificamente, na elaboração de um modelo conceitual que cobre aspectos importantes da alocação de recursos e escalonamento de tarefas. Este modelo baseia-se nas melhores práticas de Engenharia de Software, nos conceitos identificados na literatura e na nossa experiência. O objetivo é ajudar o gerente de projeto durante a elaboração do cronograma. 1. Introdução As organizações desenvolvedoras de software operam em um mercado bastante competitivo em que os produtos gerados são obtidos a partir do esforço da equipe de projeto. Para construir os produtos de software, as organizações geralmente seguem um processo definido em que o esforço de desenvolvimento é dividido em atividades [Sommerville 2011], [Pressman 2011]. Cada uma dessas atividades possui características específicas para execução, como conhecimento, experiência, produtos de trabalho consumidos e resultantes. O lucro dessas organizações é obtido a partir da conversão do esforço de execução das atividades em produtos de software. A definição da equipe de um projeto torna-se uma questão central, em que se espera alocar 139

140 atividades para a equipe de desenvolvimento de forma a maximizar o lucro. Neste contexto, o gerente de projetos exerce um papel fundamental para a escolha da equipe e elaboração do cronograma de acordo com as restrições do projeto e da organização. Existem diversos modelos, ferramentas e métodos que auxiliam o gerente de projetos durante a execução de suas atividades, como por exemplo, MS Project [Microsoft 2013], Gnome Planner [Gnome 2010] e OpenProj [OpenProj 2012]. Embora esses modelos, ferramentas e métodos sejam de conhecimento geral, eles não tiram do gerente de projetos a responsabilidade de obtenção de uma solução de qualidade que atenda aos objetivos da organização e do mercado. Além disso, as técnicas de gerenciamento de projetos apresentam limitações ao tratar a natureza dinâmica dos projetos de software [Chang 2008], principalmente no que se refere a recursos humanos. Dentre as atividades de planejamento do gerente de projetos, a alocação de recursos e o sequenciamento das tarefas tornam-se um problema complexo tendo em vista a quantidade de possibilidades de soluções e também pela existência de conflitos entre os objetivos [Freitas 2009]. Durante a alocação de recursos, define-se quais pessoas vão estar alocadas para quais atividades, levando em consideração um conjunto de restrições como habilidades, preferências, custos, e prazos [PMI 2008]. O sequenciamento de tarefas é comumente ilustrado através de diagramas de redes e consiste no processo de identificação e documentação das dependências entre as tarefas [PMI 2008]. Usualmente, os gerentes de projetos não são capazes de avaliar todas as combinações, por isso eles utilizam abordagens ad hoc para a elaboração do cronograma, em que, a solução é baseada no conhecimento, experiência e na intuição. O desenvolvimento do software envolve tempo, dinheiro e talento. Portanto, o uso adequado dos recursos disponíveis é essencial. O problema de elaboração do cronograma tem sido tratado por um novo ramo de pesquisa denominado Engenharia de Software Baseada em Buscas (em inglês Seach-Based Software Engineering - SBSE). Nesse ramo, o problema é modelado como da área de otimização para ser resolvido por técnicas derivadas do campo de Pesquisa Operacional, como programação linear e linear inteira, e metaheurísticas, como algoritmos genéticos, evolutivos e construtivos [Colanzi 2013]. A resolução de um problema passa a ser vista como a busca por uma solução suficientemente boa entre as suas possíveis soluções, de acordo com uma, ou mais, métricas de adequação [Harman 2009], [Harman 2012]. Assim, essa metodologia fornece um mecanismo de apoio ao engenheiro de software para a tomada de decisão [Colares 2010]. Esse trabalho tem como objetivo principal auxiliar os gerentes de projetos de software na tomada de decisões durante a elaboração do cronograma. O foco deste projeto consiste na elaboração conceitual do problema de alocação de recursos e escalonamento de tarefas (Staffing and Scheduling problem - RSP). Assim, uma primeira contribuição deste trabalho consiste na elaboração de um modelo conceitual que poderá ser utilizado como referência para a solução do problema de alocação e escalonamento de tarefas. O trabalho de Peixoto e outros [Peixoto 2014] mostra que conceitos importantes relacionados à Gestão de Projetos não foram considerados na elaboração e implementação de algoritmos de otimização relatados na literatura. Por exemplo, poucos trabalhos consideraram a produtividade da equipe nas soluções propostas. Na indústria, mesmo que intuitivamente, os gerentes de projeto consideram esta informação. Desta forma, uma outra contribuição deste trabalho consiste em melhorar 140

141 essa ligação entre a teoria e a prática. Serão abordados os conceitos fundamentais para o gerenciamento de projetos, dando um embasamento teórico ao assunto. Este documento está estruturado da seguinte forma: a Seção 2 apresenta os trabalhos relacionados a esta pesquisa. A Seção 3 apresenta a metodologia de estudo. A Seção 4 apresenta o modelo conceitual que estamos trabalhando. A Seção 5 apresenta o detalhamento do estágio atual da pesquisa. A Seção 6 conclui este documento. 2. Trabalhos Relacionados Na área de gerenciamento de projetos, os trabalhos de SBSE podem ser classificados basicamente em duas categorias [Harman 2012]: trabalhos que tratam de questões de planejamento e modelos preditivos de estimativas de custos e outras métricas. Como o escopo deste trabalho aborda a elaboração do cronograma, abaixo serão apresentados os trabalhos relacionados a esta atividade de planejamento. O escopo deste trabalho foi inspirado no trabalho de Colares (2010), o qual aborda o problema de gerenciamento de projetos utilizando técnicas de otimização computacional, com o objetivo de contornar limitações atuais através de uma abordagem automatizada. Este trabalho utiliza vários conceitos importantes na elaboração do modelo conceitual como, por exemplo, prazo, interdependência entre tarefas, custo, e recursos humanos. Apesar de dispor de um modelo mais elaborado, a implementação correspondente não reflete o que foi proposto. Assim, os resultados deste trabalho apenas mostram indícios da aplicabilidade da abordagem. Nóbrega (2013) implementa uma versão do modelo conceitual do trabalho de Colares (2010) utilizando diferentes técnicas de otimização. O projeto é baseado em otimização multiobjetivo de um modelo matemático utilizando metaheurísticas. Este trabalho utiliza a metaheurística GRASP-MOVNS (Greed Randomized Adaptative Search Procedure - Multiobjective Variable Neighborhood Search) [Nóbrega 2013] como principal algoritmo, que se baseia no processo de busca local realizada com mudanças sistemáticas de estruturas de vizinhanças [Nóbrega 2013]. O resultado desse algoritmo foi comparado aos resultados obtidos na implementação do algoritmo que foi proposto por Colares (2010). Foram feitas adaptações ao modelo matemático, deixando-o mais simples, de forma a melhorar o desempenho do algoritmo proposto e trabalhando somente com soluções válidas para o problema. O objetivo geral do trabalho foi atingido pois o algoritmo multiobjetivo obteve melhores resultados do que o desenvolvido por Colares (2010). No trabalho de Barreto e outros [Barreto 2008] o problema de alocação de recursos é formulado como um Constraint Satisfaction Problem [Kumar 1992]. Diversos aspectos são considerados na modelagem do problema, como equipes mais qualificadas, menos qualificadas, equipes de menor custo ou mais velozes. Uma ferramenta de apoio foi desenvolvida e validada com experimentos. Análises qualitativas indicaram que ganhos podem ser obtidos com o uso da ferramenta desenvolvida. Apesar dos pontos positivos, o trabalho apresenta algumas limitações em relação a sua formulação, que considera, por exemplo, que cada tarefa é executada individualmente, e não por equipes. Chang e outros (2008) propõem o conceito de linha de tempo para representar os efeitos de diversas ações que são realizadas no decorrer do projeto, como, por exemplo, 141

142 o efeito da curva de aprendizado após a execução de um treinamento. Entretanto, essa dimensão de tempo torna o modelo bastante complexo, impactando, assim, no desempenho da solução. O trabalho de Antoniol e outros [Antoniol 2004] analisa o problema da alocação de equipes em projetos de manutenção de software. Este trabalho avalia fatores importantes como erros de estimativas, retrabalho, e abandono do projeto. Por outro lado, o trabalho apresenta algumas limitações, como o fato de ser voltado para projetos de manutenção e também de desconsiderar aspectos importantes como experiências e habilidades individuais e a interdependência entre tarefas. Uma versão multiobjetivo para o problema foi proposta por Alba e Chicano [Alba 2007] com o objetivo de minimizar duas metas que são conflitantes entre si: o tempo e o custo do projeto. Os autores utilizam a abordagem de algoritmos genéticos, combinando os dois objetivos em uma única função de soma ponderada. A formulação considera aspectos importantes, como habilidades individuais dos recursos, salário e hora extra. Peixoto e outros (2014) realizaram uma revisão sistemática da literatura com o objetivo de avaliar os aspectos positivos e negativos para a adoção de soluções de otimização em organizações desenvolvedoras de software. Foram analisados 52 artigos. Os autores observaram que apenas os conceitos mais simples foram representados nesses trabalhos e que as soluções propostas não são fáceis de serem usadas e de serem adotadas nas organizações desenvolvedoras de software. Entretanto, as soluções de otimização apresentaram resultados melhores do que as sugeridas por gerentes de projetos durante os experimentos executados. Como pode ser observado, os trabalhos não consideram de forma sistemática os fatores que usualmente ocorrem em organizações desenvolvedoras de software como, por exemplo, mudanças no comportamento da equipe, diferenças individuais e de produtividade. Seja pela dificuldade de identificar e modelar esses elementos, ou pela dificuldade de obter uma massa de dados para os testes. Desta forma, os algoritmos elaborados apresentam restrições de aplicabilidade em projetos reais, o que gera insegurança no gerente de projetos em adotar esta ferramenta como suporte à tomada de decisão. Neste contexto, o enfoque do nosso trabalho é criar um modelo que seja amplo o suficiente para incorporar questões importantes do cotidiano dos gerentes de projetos. O detalhamento deste modelo deverá permitir que o algoritmo de otimização elaborado reflita de uma forma mais fiel a realidade das organizações desenvolvedoras de software. 3. Metodologia O processo desta pesquisa consiste de uma metodologia para a exploração, aplicação e consolidação do conhecimento. O processo será observado nas etapas de caracterização, desenvolvimento e validação do modelo. Serão executados ciclos de iteração e a cada iteração haverá avaliação dos resultados obtidos até aquele momento. Na fase de caracterização são avaliadas e estudadas as principais questões, ou requisitos, para a elaboração do modelo conceitual. Primeiramente, foi realizado um levantamento bibliográfico dos conceitos a serem modelados e o seu contexto de uso. Os trabalhos de Colares (2010) e Nóbrega (2013) serviram de base para a realização das 142

143 atividades desta fase. As teses de Navarro (2006) e Kupsch (2012) também serviram como importantes referências para a identificação de regras de boas práticas relacionadas à gestão de projetos. Posteriormente, realizamos o mapeamento destas regras para os conceitos representados no modelo. Além destes trabalhos, foi utilizado como base para a elaboração do modelo conceitual os resultados descritos no trabalho de Peixoto e outros (2014). Com base na bibliografia selecionada, foi possível identificar importantes conceitos de Engenharia de Software para a execução do trabalho. Na fase de desenvolvimento é criado o modelo conceitual. Para cada conceito e restrição identificados até o momento foi criada uma representação conceitual. Após finalizarmos a relação dos conceitos, etapa atual deste trabalho, a próxima meta é concluir o diagrama de classes que evidencia como esses conceitos se relacionam, melhorando o entendimento do trabalho e facilitando a visualização geral do projeto a ser otimizado. A ideia é termos um modelo de referência para a solução do problema de alocação de recursos e escalonamento de tarefas. Após finalizado o modelo conceitual, será criada uma representação matemática que reflita de forma mais fiel possível o contexto estudado. Na fase de validação são validados os modelos conceitual e matemático. Uma forma de verificação do modelo conceitual consiste na realização de pesquisas e questionários com os gerentes de projeto com o objetivo de identificar se os aspectos considerados por eles foram representados no modelo. O modelo matemático será validado através da implementação utilizando ferramentas comerciais de otimização como, por exemplo, CPLEX [IBM 2013]. 4. Modelo Conceitual O modelo conceitual apresenta os principais conceitos identificados para o problema de alocação de recursos e escalonamento de tarefas. O modelo base para o nosso estudo é o apresentado na Figura 1. Este modelo apresenta os conceitos básicos utilizados na solução do problema de alocação de recursos e escalonamento de tarefas relatados na literatura [Peixoto 2014]. Nós estamos melhorando este modelo, através da coleta e análise de regras de boas práticas de Engenharia de Software [Glass 2002]. Essas regras serão refinadas em conceitos e atributos, ou seja, cada regra relacionada ao problema será mapeada para os conceitos e atributos correspondentes. Por exemplo: The average assimilation delay, the period of time it takes for a new employee to become fully productive, is 80 days [Abdel-Hamid 1991]. A regra acima foi mapeada para o conceito recurso e dois atributos: curva de aprendizado e produtividade. 143

144 Figura 1. Modelo de alocação de recursos e escalonamento de tarefas. Fonte: [Peixoto 2014] Até este momento, já conseguimos identificar conceitos importantes que não constam neste modelo, como produtividade, overhead de comunicação, risco, curva de aprendizado dos colaboradores e horas extras. Pessoas não são como máquinas e possuem variações no seu desempenho de acordo com seu humor, seu ambiente de trabalho, com o que acontece ao seu redor, etc. Além disso, as organizações, normalmente, disponibilizam para seus funcionários especializações e cursos sobre novas ferramentas que serão utilizadas no processo de desenvolvimento de software ou sobre como aumentar o desempenho do próprio empregado, de forma a melhorar a produtividade da equipe [Glass 2002]. Os modelos estudados não abordam de forma abrangente tais fatores que são importantes e ocorrem frequentemente nas organizações desenvolvedoras de software. 5. Estágio Atual da Pesquisa A pesquisa está no estágio de conclusão do levantamento dos conceitos e regras para a finalização do modelo conceitual. Conforme apresentado na seção anterior, foi realizado um mapeamento das informações coletadas nas regras de Engenharia de Software com as áreas de conhecimento e os atributos relacionados. O enfoque do nosso trabalho é criar um modelo que seja amplo o suficiente para incorporar questões importantes do cotidiano dos gerentes de projetos. O detalhamento deste modelo deverá permitir que o algoritmo de otimização elaborado reflita de uma forma mais fiel a realidade das organizações desenvolvedoras de software. 6. Conclusão A elaboração do cronograma em projetos de software, que compreende a alocação de recursos e definição do sequenciamento das tarefas, é reconhecida como uma atividade 144

145 tão importante quanto complexa. Abordagens ad hoc possuem várias desvantagens, grande parte advinda do fato do desenvolvimento se tornar dependente de indivíduos e não do processo. Visando auxiliar o gerente de projetos através de uma abordagem automatizada, esse trabalho trata do problema de elaboração do cronograma utilizando técnicas de otimização computacional. No estágio atual desta pesquisa, iremos finalizar o modelo conceitual. Em seguida, iremos elaborar o modelo matemático e implementá-lo utilizando uma ferramenta comercial. O objetivo é a criação de um modelo que seja mais próximo da realidade das organizações desenvolvedoras de software. Dessa forma, esperamos encontrar resultados que possam auxiliar um gerente de projetos a criar uma solução que seja a mais adequada para o panorama da sua empresa. Assim, do ponto de vista da pesquisa, este projeto trará como resultado imediato a criação de um modelo conceitual, um modelo matemático e sua validação. Os resultados poderão servir de base para a formulação de outros problemas de SBSE e permitirão que os algoritmos criados possam trazer resultados mais significativos para a Engenharia de Software. Referências Abdel-Hamid, T. and Madnick, S. E. Software Project Dynamics: an Integrated Approach. 1991, Upper Saddle River, NJ: Prentice-Hall, Inc. Alba, E.; Chicano, J. F. Software Project Management with GAs. Information Sciences, 177(11): , June Antoniol, G.; Penta, M. D.; Harman, M. A Robust Search-Based Approach to Project Management in the Presence of Abandonment, Rework, Error and Uncertainty. In Proceedings of the 10th International Symposium on Software Metrics, METRICS 04, pages , Chicago, Illinois, USA, Barreto, A.; Barros, M. O.; Werner, C. M. L. Staffing a software project: A constraint satisfaction and optimization-based approach. Computers & Operations Research, 35(10): , Chang, C. K.; Jiang, H. Yi, Di, Y.; Zhu, D.; GE, Y. Time Line Based Model For Software Project Scheduling with Genetic Algorithms. Information and Software Technology, v. 50, p , Colanzi, T. E.; Vergilio, S. R.; Assunção, W., and Pozo, A. Search Based Software Engineering: Review and analysis of the field in Brazil. Journal of Systems and Software, 86(4): , Colares, F. Alocação de Equipes e Desenvolvimento de Cronogramas em Projetos de Software Utilizando Otimização. Dissertação (Mestrado) Universidade Federal de Minas Gerais, Freitas, F. G.; Maia C. L. B.; Coutinho D. P.; Campos, G. A. L.; and Souza, T. J. Aplicação de Metaheurísticas em Engenharia de Software: Revisão de Literatura. In Anais do II Congresso Tecnológico InfoBrasil, InfoBrasil 09, Fortaleza, Ceará, Brasil,

146 Glass, R. L. Facts and Fallacies of Software Engineering. ISBN: [S.I.]: Addison Wesley, Gnome Project. Gnome planner Acessado em 22 de abril de Harman, M.; Mansouri, S. A.; and Zhang Y. Search based software engineering: A comprehensive analysis and review of trends techniques and applications. Technical Report TR-09-03, King s College London, Harman, M.; Mansouri, S. A.; and Zhang, Y. Search-based Software Engineering: Trends, Techniques and Applications. ACM Computing Surveys, 45(1):11:1 11:61, December IBM. CPLEX Optimizer Disponível em: < 01.ibm.com/software/commerce/optimization/cplex-optimizer/>. Acessado em 15 de maio de Kumar, V. Algorithms for constraint-satisfaction problems: A survey. AI Magazine, 13(1):32 44, abril, Kupsch, D. C. C. Spial: Uma Ferramenta de Apoio ao Aprendizado de Melhoria de Processos de Software. Tese (Doutorado) Universidade Federal de Minas Gerais, Microsoft. Microsoft Project Disponível em: < Acessado em 22 de abril de Navarro, E. SimSE: A Software Engineering Simulation Environment for Software Process Education. Tese (Doutorado) University of California, Irvine, Nóbrega, S. Desenvolvimento de Cronogramas de Projetos de Software Utilizando Otimização Heurística. Dissertação (Mestrado) Centro Federal de Educação Tecnológica de Minas Gerais, OpenProj. OpenProj - Project Management Acessado em 22 de abril de Peixoto, D. C. C; Mateus, G. R.; Resende, R. F. The Issues of Solving Staffing and Scheduling Problems in Sofware Development Projects In: 38th Annual International Computers, Software & Applicantions Conference, COMPSAC 14, Västerås, Sweden, July, PMI. A Guide to the Project Management Body of Knowledge(PMBOK Guides). 4 ed [S.I.]: Project Management Institute, Pressman, R. S. Engenharia de Software Uma Abordagem Profisional. 7 ed [S.I.]: McGraw Hill, Sommerville, I. Software Engineering. Addison-Wesley, 9th edition,

147 Gerência de Projetos no Desenvolvimento Distribuído de Software - Desafios e Soluções Wallace Moreno, Heitor Costa Departamento Ciência da Computação - Universidade Federal de Lavras Caixa Postal CEP Lavras - MG - Brasil wsmorenop4@gmail.com, heitor@dcc.ufla.br Abstract. The challenge of developing software has increased because of several factors, e.g. complexity of these systems and lack of skilled available professional next of development companies. Thus, they should seek alternatives; one of them is global software development. So, software project management should adapt to this reality and resolve challenges not previously found in the "traditional" management. In this paper, we present an initial list of challenges in project management in the context of global software development and solutions proposed by researchers and project managers to try to solve these challenges. Resumo. O desafio de desenvolver sistemas de software tem cada vez mais aumentado por causa de diversos fatores, por exemplo, a complexidade desses sistemas e a falta de mão de obra especializada disponível próxima das empresas desenvolvedoras. Assim, essas empresas devem buscar alternativas, sendo uma delas o desenvolvimento distribuído de software. Com isso, a gerência de projetos de software deve adaptar-se a essa realidade e solucionar desafios anteriormente não encontrados na gerência "tradicional". Neste trabalho, é apresentada uma relação inicial dos possíveis desafios enfrentados na gerência de projetos no contexto de desenvolvimento de software distribuído e soluções propostas por pesquisadores e gerentes de projetos para tentar solucionar esses desafios. Aluno: Wallace Streitenberger Moreno Orientador: Heitor Augustus Xavier Costa Categoria: Trabalho de Conclusão de Curso de Graduação Estágio do Trabalho: Em Desenvolvimento 1. Introdução Organizações cada vez mais procuram adaptarem-se às mudanças do mercado, fazendo com que o tempo esteja a favor de seus negócios e visando ao lucro e à eficiência para atender seus clientes. Sendo assim, cada vez mais está tornando aplicável a prática de Desenvolvimento Distribuído de Software (DDS) que possibilita as empresas expandirem seus processos de desenvolvimento em lugares distintos geograficamente. Com isso, suas equipes trabalham de forma distribuída, não sendo possível realizar reuniões presenciais frequentemente. A tarefa de gerenciar projetos de desenvolvimento tem se tornado cada vez mais complexa. Não apenas por causa do crescimento dos projetos, mas por existir essa distribuição de tempo e de espaço. As principais implicações no DDS estão relacionadas à sinergia cultural, ao mercado global, à escola, ao tempo para mercado, ao rigor, à experiência, à demanda e aos custos. 147

148 Mesmo em projetos desenvolvidos em contexto nacional e intraorganizacional, em que a priori a linguagem, a cultura e a organização seriam as mesmas, há dificuldades de controle, de comunicação e de coordenação. No DDS, a distância geográfica, temporal e sócio-cultural são fatores que acentuam essas dificuldades e constituem-se em desafios a serem resolvidos [Lindqvist et al., 2006]. Neste trabalho, o objetivo foi apresentar um catálogo inicial no qual forneça registros a respeito das práticas relatadas sobre o DDS como seus desafios e soluções para esses desafios no contexto de gerenciamento de projetos de software. O restante do artigo está organizado da seguinte forma. Áreas de Conhecimento do PMBoK estão resumidas na Seção 2. Desenvolvimento distribuído de software é abordado brevemente na Seção 3. Desafios e soluções identificadas na literatura são apresentados na Seção 4. Alguns trabalhos relacionados estão resumidamente descritos na Seção 5. Conclusão e sugestões de trabalhos futuros são apresentadas na Seção Project Management Body of Knowledge (PMBoK) Project Management Body of Knowledge (PMBoK) é um guia amplamente utilizado por vários setores da indústria e criado e mantido pelo Project Management Institute (PMI). Nesse guia, estão reunidas as melhores práticas de gerenciamento de projetos [Gaffo; Barros, 2012] com descrição de normas, de métodos, de processos e de práticas estabelecidos para gerenciar projetos de qualquer natureza [Andrade; Tait, 2012]. PMBoK incorpora processos e atividades que suprem necessidades das etapas ou das fases do ciclo de vida de um projeto [Andrade; Tait, 2012] e existe consenso sobre o seu valor e sua usabilidade [Matos et al., 2010]. Esse guia organiza os 47 processos em 10 áreas de conhecimento [Romano, 2012; Gaffo; Barros, 2012; PMBoK, 2013]: Gerenciamento de Integração. Há 6 processos referentes à descrição dos processos e das atividades que integram os elementos do gerenciamento de projetos identificados, definidos, combinados, unificados e coordenados nos grupos de processos de gerenciamento de projetos; Gerenciamento de Escopo. Há 6 processos referentes à verificação de que o projeto inclui o trabalho necessário, apenas o necessário, para que seja concluído com sucesso; Gerenciamento de Tempo. Há 7 processos referentes ao término do projeto no prazo correto; Gerenciamento de Custos. Há 4 processos referentes ao planejamento, à estimativa, ao orçamento e ao controle de custos, de modo que o projeto termine dentro do orçamento aprovado; Gerenciamento de Qualidade. Há 3 processos referentes à garantia de que o projeto irá satisfazer os objetivos para os quais foi realizado; Gerenciamento de Recursos Humanos. Há 4 processos referentes à organização e à gerência da equipe do projeto; Gerenciamento de Comunicações. Há 3 processos referentes à geração, à coleta, à disseminação, ao armazenamento e à destinação final das informações do projeto de forma oportuna e adequada; Gerenciamento de Riscos. Há 6 processos referentes à realização do gerenciamento de riscos em um projeto; Gerenciamento de Aquisições: Há 4 processos referentes à compra e/ou à aquisição de produtos, serviços ou resultados, além dos processos de gerenciamento de contratos; 148

149 Gerenciamento de Partes Interessadas. Há 4 processos referentes à comunicação, envolvendo diálogo contínuo para atingir necessidades e expectativas. 3. Desenvolvimento Distribuído De Software O desenvolvimento de software não está limitado a uma equipe trabalhando lado-a-lado em um escritório. É possível unir pessoas em diversas localidades, seja em diferentes bairros ou em diferentes países, para realizar o desenvolvimento em conjunto de sistemas de software. A esse desenvolvimento realizado por pessoas separadas espacial e temporalmente é dado o nome de Desenvolvimento Distribuído de Software (DDS) [Siqueira, 2005]. Além do desenvolvimento de baixo custo, as empresas buscam investir em DDS, buscando possibilidades de maior qualidade no processo de desenvolvimento, de obtenção de recursos em âmbito global, de aumento da produtividade e de diminuição dos riscos [Audy, 2007]. Alguns fatores contribuíram significativamente para acelerar o seu surgimento e a sua aceitação, por exemplo, [Carmel; Tija, 2005; Audy, 2007] a necessidade de recursos globais para uso a qualquer hora, a proximidade com o mercado local, os incentivos fiscais, as soluções globais, o Time-to-market e o Follow-the-sun. De acordo com a globalização dos negócios, o software tem se tornado uma ferramenta estratégica em sua formação, especialmente na área de Engenharia de Software, onde mercados nacionais tem se tornado mercados globais, criando novos mercados novas formas de cooperação e competição que vão além das fronteiras dos países [Herbsleb; Moitra, 2001]. Observou-se grande investimento na conversão de mercados nacionais em mercados globais, criando novas formas de competição e de colaboração. O mercado global de software tem passado por diversas crises. Por um lado, há falhas em muitos projetos; por outro, há crescente demanda, atingida pela escassez de recursos capacitados. Nesse ambiente, muitas organizações encontraram no DDS uma alternativa, experimentando o desenvolvimento em locais remotos [Prikladnicki; Audy, 2004]. As equipes situadas em diferentes localizações geográficas, podendo estar inclusive no exterior, colaboraram usando tecnologias de comunicação em que pode ser observado o desenvolvimento de módulos de software inter-relacionados e integrados em espaços de trabalho de projeto compartilhados. O processo de design de software envolve ciclos iterativos de desenvolvimento antes de chegar a uma entrega o que pode ser implantado em um servidor de produção para uso dos clientes. Qualquer inconsistência na etapa do desenvolvimento pode ter um impacto sobre o projeto gerenciado podendo haver consequências desagradáveis. Além disso, quaisquer anomalias encontradas após o lançamento do produto de software podem ter ramificações graves para a reputação das organizações. Por esse motivo, é importante analisar os processos envolvidos no desenvolvimento [Mathrani; Mathrani, 2013]. As características do DDS são provenientes de três categorias principais: i) a forma de separação dos grupos (agrupamento, distância física e separação temporal); ii) as regiões envolvidas (culturas regionais, idiomas e diferenças dos locais); e iii) as organizações participantes (culturas organizacionais, infraestrutura e relação legal) [Pilatti; Audy 2006]. Estas e outras características: Agrupamento: uma característica fundamental do DDS é possuir equipes dispersas com pequena quantidade de pessoas agrupadas e encarregadas por determinadas tarefas do processo global de desenvolvimento [Prikladnicki et al., 2003]; 149

150 Distância Física: Apesar da era das telecomunicações via internet e aviões a jato, ainda pode levar tempo para um especialista chegar ao local do problema tecnológico em um lugar remoto [O Brien, 2011]. Além disso, há problemas de comunicação de tempo real e de boa qualidade. É difícil encontrar pessoal qualificado em certos países ou incentivar especialistas para viverem ou trabalharem nesses países. Nos diferentes países, há problemas e oportunidades, relacionados com diferenças de custo de vida e de mão-de-obra. A dispersão geográfica, além de dificultar as reuniões presenciais, pode afetar a comunicação entre os grupos, por causa da defasagem na transmissão de informações, que pode atrapalhar comunicações por telefone e as reuniões por videoconferência. Embora a tecnologia de comunicação tenha avançado significativamente, ela causa expressivo impacto social e psicológico se comparado com a interação face a face [Damian, 2002]. No entanto, ferramentas de colaboração e de comunicação provêm ajuda às atividades de desenvolvimento de software [Lanubile, 2009]. A distância torna mais difícil a comunicação (dificultando a realização de encontros de formação e reuniões presenciais), a coordenação (redução do contato informal) e o controle (visão estratégica dificultada) no DDS [Carmel; Agarwal, 2001]; Separação Temporal: diferenças no fuso horário das equipes envolvidas pode dificultar o trabalho, por exemplo, troca de informações síncronas e aumento dos custos de coordenação [Carmel; Agarwal, 2001]; Culturas Regionais: podem existir grupos com diversidades de comportamento entre as pessoas por causa de suas diferentes culturas. Isso pode gerar diferenças, por exemplo, no planejamento do trabalho, no processo decisório, no estilo de argumentação, no fluxo da conversa e nas práticas de trabalho incompatíveis [Carmel; Agarwal, 2001; Olson; Olson, 2004]; Idioma: caso grupos de trabalho não adotem idioma padrão para comunicarem-se, pode não ser possível o desenvolvimento do projeto. Mesmo utilizando idioma comum, por causa da falta de proficiência de alguns membros e por divergentes interpretações semânticas causadas por diferente educação cultural, alguns problemas continuam a acontecer [Mockus; Herbsleb, 2001]; Diferenças dos Locais: o aspecto jurídico é um dos problemas entre locais distintos. Grupos podem estar sujeitos a diferentes legislações, sejam elas comerciais, civis, trabalhistas, etc. Essa diversidade afeta o desenvolvimento de diversas formas; Culturas Organizacionais: Alguns desafios culturais referem-se ao estilo de trabalho e relações comerciais, por exemplo, deve-se despender tempo para evitar erros ou apressar para que algo seja feito mais cedo? Agir por conta própria ou trabalhar cooperativamente? O mais experiente deve liderar ou a liderança deve ser distribuída? As respostas a essas perguntas dependem das diferenças culturais que existem no mercado globalizado [O Brien, 2011; Carmel; Agarwal, 2001]; Infraestrutura das Organizações: hardware, software, técnicas, ferramentas, padrões e instalações envolvidas no desenvolvimento, na operação e na manutenção de produtos de software fazem parte da infraestrutura de uma organização. Independente da organização estar ou não voltada para o DDS, ela precisa ter uma infraestrutura adequada para permitir o trabalho das pessoas envolvidas. No entanto, a organização é forçada a ter heterogeneidade de ferramentas por causa de restrições locais como licença de exportação e suporte técnico disponível [Lings et al., 2007]; Relação de Negócio: uma organização pode não achar interessante compartilhar determinada informação que possa ser importante para o projeto, por causa dela considerar-se proprietária dessa informação. Com base nisso, a relação de negócio 150

151 influi diretamente na passagem de conhecimento entre as partes [Kobitzsch et al., 2001]; Processo Decisório: É uma característica que não aparece de forma explicita nas organizações. No entanto, ele fica evidente quando as decisões são tomadas em um único local e impostas às demais equipes. Esse tipo de atitude acaba em frustração por parte dos demais envolvidos [Kiel, 2003]. 4. Desafios x Soluções Em uma pesquisa inicial na literatura, foram identificados alguns desafios e soluções propostas para minimizar o impacto desses desafios na gerência de projetos de software no contexto de DDS. Esses desafios e essas soluções são apresentados na Tabela 1. Tabela 1 - Desafios e Soluções da Gerência de Projetos de Software no Contexto de Desenvolvimento Distribuído de Software Desafios Soluções Referências - Conscientizar o grupo das atividades desenvolvidas. - Realizar esforços consideráveis no estudo das equipes de Damian, 2002 Awareness projeto. Endsley, Desenvolver técnicas de redes sociais (networks). Kobylinski et al., Desenvolver awareness automatizados para facilitar os Rocha et al., 2008 trabalhos das equipes distribuídas. Estilo de Comunicação Fusos Horários Confiança Espírito de Equipe Telecomunicações Dispersão Física e Temporal Formas de Comunicação Conflitos - Evitar múltiplas interpretações ao falar sobre determinado assunto em uma reunião ou vídeo conferência. - Utilizar estilo de comunicação mais impessoal. - Utilizar mecanismos parecidos de comunicação. - Disponibilizar sistema de Intranet. - Sincronizar tarefas a partir do sistema de Intranet. - Estabelecer medidas de trabalho e período de trabalho. - Realizar encontros de kick-off e marcos do projeto para estabelecer forma de construção de confiança. - Marcar reunião da equipe para alguns dias de trabalho e socialização no início do ciclo de desenvolvimento. - Aumentar a confiança e o espírito de equipe, além de endereçar diferenças culturais, acelerando comunicações posteriores, por meio de incentivo e bom relacionamento. - Ter tamanho passível de ser gerenciado em um cenário distribuído. - Fazer com que o projeto seja impulsionado por atributos da equipe e dificuldades do projeto (tamanho, esforço e complexidade). - Necessidade de reuniões presenciais. - Analisar a infraestrutura de telecomunicações para verificar se atende as necessidades impostas. - Ter estrutura de telecomunicações. - Realizar viagens necessárias para encontro da equipe. - Ter tecnologias de comunicação. - Realizar reuniões por vídeo conferencia em tempo real. - Realizar ligações telefônicas, mas realizar reuniões presenciais, pois são importantes. - Preocupar-se com modelos de comunicação, que possam gerar informações ambíguas. - Estabelecer contatos em que informações sejam passadas claramente. - Realizar reuniões presenciais caso o assunto seja de máxima importância. - Informações dispostas a todo grupo da melhor maneira de entendimento e compreensão com relatórios. - Ser criada uma autoridade central do projeto. - Assumir responsabilidades e automaticamente responder por elas. - Especificar direitos e deveres. - Definir agenda e divisões de responsabilidades. - Assumir tarefas não previstas. Al-Asmari; Yu, 2006 Vanzin et al., 2005 Weissleder; Schlingloff, 2008 Audy, 2007 Bazman, 2007 Kiel, 2003 Audy; Prikladnicki, 2008 Vanzin et al., 2005 Dantas, 2003 Carmel, 1999 Rocha et al., 2008 Cockburn, 2002 Lipnack; Stamps, 1997 Kiel, 2003 Damina; Zowghi, 2003 Haywood, 2000 Cockburn, 2002 McGrath, 1990 apud Herbsleb; Mockus, 2003 Damian; Zouvigh, 2003 Rocha et al., 2008 Damian, 2002 Hofstede, 1996 Dantas, 2003 Rocha et al.,

152 Tabela 1 - Desafios e Soluções da Gerência de Projetos de Software no Contexto de Desenvolvimento Distribuído de Software (cont.) Desafios Soluções Referências - Entender diferentes expectativas envolvidas em um ambiente multicultural. Haywood, Ser gerenciado de melhor maneira possível o modo com Carmel, 1999 Diferenças que cada cultura trata fatores como hierarquia, senso de Damian, 2002 Culturais tempo e estilos de comunicação. Layman et al., Criar cultura, em equipe (minicultura). Haywood, Criar liaison, pessoa que desenvolve papel de ponte entre duas ou mais culturas. Liderança Processo de Desenvolvimento Coordenação, Controle e Interdependência Modelos de Negócio Seleção e Alocação de Projetos - Implantar hierarquia clara baseada em status, como família, idade, sexo ou títulos. - Encorajar subordinados a expressarem suas opiniões. - Tratar a equipe como grande respeito às diversidades e tempos de respostas. - Usar metodologia de desenvolvimento de software para impor rigor à equipe. - Demandar disciplina maior que a comum a maioria das organizações. - Utilizar métodos de governança. - Usar soluções integradas nos níveis de decisão, por exemplo, Six Sigma, ITIL e Cobit. - Criar coordenações por critérios de união, de sequenciamento e de reciprocidade. - Ter modelos de comunicação claros e/ou disponíveis quanto à comunicação presencial. - Ter planejamento. - Estudar locais para estabelecer unidades distribuídas ou parcerias com outras empresas. - Ter atividades de análise de projetos. - Ter atividades de alocação de projetos. - Ter atividades de seleção de projetos. Kroll et al., 2003 Mullick et al., 2006 Dantas, 2003 Jiménez et al., 2009 Damian; Lanubile, 2004 Rocha et al., 2008 Audy, 2007 Dantas, 2003 Weissleder; Schlingloff, 2008 Rocha et al., 2008 Kobitzsch et al., 2001 Weissleder; Schlingloff, Trabalhos Relacionados Em um trabalho [Karolak, 1998], é proposto um modelo para desenvolver projetos de DDS abrangendo um conjunto de atividades que devem ocorrer ao longo do ciclo de vida de um projeto e as características essenciais de cada uma. O modelo considera atividades desde a estratégia a ser adotada para atuar em DDS (empresas globais, parcerias estratégicas, entre outros) a manutenção do software desenvolvido, mas não se aprofunda na análise de como implementar cada uma. São discutidos conceitos envolvidos, sugestões de atividades e dificuldades. Em outro trabalho [Carmel, 1999], é abordada a formação de equipes globais de desenvolvimento de software e os principais fatores que devem ser considerados ao montar uma equipe para um projeto distribuído. Nesse trabalho, são sugeridas categorias que podem levar uma equipe distribuída ao fracasso (comunicação ineficiente, falta de coordenação, dispersão geográfica, perda do espírito de equipe e diferenças culturais), chamadas de forças centrífugas. Além disso, são sugeridos fatores que podem levar a equipe ao sucesso (infraestrutura de comunicação, arquitetura do produto, construção de uma equipe, metodologia de desenvolvimento, tecnologia de colaboração e técnicas de gerência), chamados de forças centrípetas. No terceiro trabalho [Evaristo, 2000], são apresentadas dimensões no contexto de equipes de projetos distribuídos. Essas dimensões auxiliam no entendimento dos problemas e nas vantagens e nas desvantagens desse tipo de ambiente e afetam diretamente o desempenho desses projetos. O trabalho é aplicável a qualquer tipo de projeto. 152

153 Em um trabalho mais recente [Mathrani; Mathrani, 2013], foram efetivados projetos em DDS nos países Nova Zelândia, Austrália e Índia, foi feita uma análise nos processos de validação para verificar a qualidade, a segurança e a rastreabilidade dos projetos desenvolvidos em locais distribuídos. Testando os estudos sobre a dispersão do conhecimento e integração no contexto de desenvolvimento de software distribuído foram analisadas para entender como as práticas de teste são incorporados em diversos configurações organizacionais. Além disso, a investigação reconhece o suporte de ferramentas para criar espaços de trabalho seguros e restringir o acesso de dados confidenciais dos clientes para o pessoal-chave. Ferramentas de monitoramento são embutidos em espaços de trabalho compartilhados para monitorar o desenvolvimento e teste atividades por equipes distribuídas durante as diferentes fases do ciclo de vida do desenvolvimento de software. Em outro trabalho [Taxén, 2006], é apresentada uma abordagem para DDS, que é baseado em dois fundamentos. O primeiro é um processo de engenharia centrada integração, que visa a gestão de dependências cruciais em projetos de DDS. O segundo fundamento é uma estratégia para operacionalizar a coordenação do processo de engenharia. O objetivo desta estratégia é fornecer simultaneamente suporte global sistema de informação para a coordenação e obter um entendimento comum sobre o que deve ser coordenada e como. A abordagem tem sido utilizada com sucesso na Ericsson, um dos principais fornecedores de sistemas de telecomunicações em todo o mundo, para a coordenação de projetos complexos de desenvolvimento. Apesar de muitos obstáculos têm de ser abordados, os resultados indicam que a abordagem é um caminho viável para gerenciar DSD durante circunstâncias muito exigentes. Este trabalho tem como diferencial não relatar apenas casos específicos de projetos no contexto de DDS, mas sim uma análise mais ampla fazendo uma identificação nos pontos mais relevantes, e com isso agregando informação não só para o meio acadêmico, mas para as organizações que podem a vir utilizar esse modelo e necessitem gerenciar seus projetos. À medida que é implantado o DDS, cada estrutura e o direcionamento de tarefas pode ser imprescindível para que o projeto tenha sucesso, é de extrema importância a observação e o registro dos acontecimentos para que a cada nova experiência seja bem sucedida. 6. Considerações Finais O desenvolvimento de software é uma atividade complexa. Existem problemas e desafios inerentes ao processo [Prikladnicki, 2002]. Assim como o processo de desenvolvimento de software tem se tornado cada vez mais complexo, a distribuição das equipes no tempo e no espaço tem tornado os projetos distribuídos cada vez mais comuns. Projetos centralizados permitem, muitas vezes, gerência por meio de observação, tendo desvantagens tais como a comunicação informal. Por outro lado, a distribuição possui suas vantagens, entre elas, a existência de grupos propensos à inovação e maior formalismo nas tarefas e nas ações. Ao acrescentar fatores como dispersão geográfica, dispersão temporal e diferenças culturais, o DDS acentuou alguns dos desafios existentes e acrescentou novos desafios ao processo de desenvolvimento. Entre esses desafios, podem ser citadas questões estratégicas, questões culturais, gestão do conhecimento e gerência de riscos. Por isso, o trabalho em ambientes de DDS podem propiciar situações inesperadas, o que não era comum nos ambientes centralizados. O valor da interação social não deve ser subestimado. A construção de confiança entre as equipes distribuídas deve ser facilitada 153

154 [Carmel, 1999; Kiel, 2003; Marquardt; Horvath, 2001]. Além disso, os riscos técnicos e os tecnológicos estão constantemente presentes. Estudos relacionados com os fatores técnicos têm sido amplamente divulgados [Altmann; Weinreich, 1998; Damina, 2002; Herbsleb, 1999; Karolak, 1998]. Por isso, o trabalho na prevenção de dificuldades e problemas decorrentes tanto dos fatores técnicos como dos não técnicos deve ser sempre valorizado. Como sugestão de trabalhos futuros, tem-se a o acréscimo da lista dos desafios e, consequentemente, das soluções sugeridas. Além disso, pretende-se analisar empresas que adotam o DDS para verificar a sua realidade de desafios e de soluções com desafios. Referências Al-Asmari, K.; Yu, L. Experiences in Distributed Software Development with Wiki. In: International Conference on Software Engineering Research and Practice. pp Altmann, J.; Weinreich, R. An Environment for Cooperative Software Development Realization and Implications. In: Hawaii International Conference on System Sciences. pp Andrade, S. C. D.; Tait, T. F. C. Uma aplicação do guia PMBOK na gestão de projetos de software. In: Revista Brasileira de Computação Aplicada, v 4(1), pp. 2-11, Audy, J.; Prikladnicki, R. Desenvolvimento Distribuído de Software: Desenvolvimento de Software com Equipes Distribuídas. Elsevier. 232p Bazman. The Benefits of Outsourced Testing Disponível em: < Acessado em: 07/05/2014. Carmel, E. Global Software Teams: Collaborating Across Borders and Time Zones. Prentice Hall. 269p Carmel, E.; Agarwal, R. Tactical Approaches for Alleviating Distance in Global Software Development. In: IEEE Software. v.18. n.2. pp Carmel, E.; Tija, P. Offshoring Information Technology: Sourcing and Outsourcing to a Global Workforce. Cambridge University Express. 282p Cockburn, A. Agile Software Development. Addison Wesley. 304p Damian, D. The Study of Requirements Engineering in Global Software Development: As Challenging As Important. In: International Workshop on Global Software Development Damian, D.; Lanubile, F. The 3rd International Workshop on Global Software Development. In: International Conference on Software Engineering. pp Damian, D.; Zowghi, D. An Insight into the Interplay Between Culture, Conflict and Distance in Globally Distributed Requirements Negotiations. In: Hawaii International Conference on Systems Sciences Endsley, M. R. Toward a Theory of Situation Awareness in Dynamic Systems. In: Human Factors The Journal of the Human Factors and Ergonomics Society. 37(1), pp ,

155 Evaristo, R. J.; Scudder, R. Geographically Distributed Project Teams: A Dimensional Analysis. In: Hawaii International Conference on System Sciences. V Gaffo, F. H.; Barros, R. M. D. GAIA risks-a service-based framework to manage project risks. In: XXXVIII Conferencia Latinoamericana, pp. 1-10, Haywood, M. Managing Virtual Teams: Practical Techniques for High Technology Project Managers. Artech House Publishers. 220p Haywood, M. Working in Virtual Teams: A Tale of Two Projects and Many Cities. IT Professional, v.2, n.2, p Herbsleb, J. D.; Grinter, R. Splitting the Organization and Integrating the Code: Conway's Law Revisited. In: International Conference on Software Engineering pp Herbsleb, J. D.; Mockus, A. An Empirical Study of Speed and Communication in Globally Distributed Software Development. In: Transactions on Software Engineering. v. 29, n. 6, pp Herbsleb, J. D.; Moitra, D. Global Software Development. In: IEEE Software. 18(2), pp Hofstede, G. Cultures and Organizations, Software of the Mind, Intercultural Cooperation and Its Importance for Survival. McGraw-Hill. 279p Karolak, D. W. Global Software Development - Managing Virtual Teams and Environments. Wiley. 172p Kiel, L. Experiences in Distributed Development: A Case Study. In: International Workshop on Global Software Development. pp Kobitzsch, W.; Rombach, D.; Feldmann, R. L. Outsourcing in India. In: IEEE Software. v. 18, n. 2, pp Kobylinski, R.; Creighton, O.; Dutoit, A. H.; Bruegge, B. Building Awareness in Global Software Engineering Projects: Using Issues as Context. In: International Workshop on Global Software Development Kroll, P.; Kruchten, P. Booch, G. The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP: A Practitioner's Guide to the RUP. Addison-Wesley. 464p Lanubile, F. Collaboration in Distributed Software Development. In: Springer-Verlag Berlin Heidelberg. pp , Layman, L., Williams, L., Damian, D., Bures, H. Essential communication practices for extreme programming in a global software development team. Information and Software Technology, 48(9): Lipnack, J.; Stamps, J. Virtual Teams: Reaching Across Space, Time and Organizations with Technology. John Wiley & Sons. 288p Marquardt, M. J.; Horvath, L. Global Teams: How Top Multinationals Span Boundaries and Cultures with High-Speed Teamwork. Davies-Black Publishing. 246p Mathrani, A.; Mathrani S. Test Strategies in Distributed Software Developement Environments. In: Computers in Industry. pp

156 Matos, P. M.; Bermejo, P. H. S.; Júnior, J. F. S. Gerência de riscos em projetos de software: Baseada nos Modelos de Processos de Referência PMBOK, CMMI, MPS.BR, TenStep e ISSO Ed. 1, editora Ciência Moderna Ltda., 68p, Mockus, A.; Herbsleb, J. Challenges of Global Software Development In: International Software Metrics Symposium. pp Mullick, N.; Bass, M.; Houda, Z.; Paulish, P.; Cataldo, M. Siemens Global Studio Project: Experiences Adopting an Integrated GSD Infrastructure. In: International Conference on Global Software Engineering. pp O Brien, J. A. Sistemas de Informação e as Decisões Gerenciais na Era da Internet. Saraiva. 492p Olson, J. S.; Olson, G. M. Culture Surprise in Remote Software Development Teams. In: Queue Focus: Distributed Development. v. 1, n. 9, pp Pilatti, L.; Audy J. Características do Desenvolvimento Global de Software em Ambientes Offshore in Sourcing: Lições Aprendidas de um Estudo de Caso. In: Workshop Um Olhar Sociotécnico sobre a Engenharia de Software PMBoK. A Guide to the Project Management Body of Knowledge. Project Management Institute. Ed. 5, Newtown Square, Pennsylvania, USA, Prikladnicki, R. Problemas, Desafios e Abordagens do Processo de Desenvolvimento de Software. 69p Prikladnicki, R.; Audy, J. MuNDDoS - Um Modelo de Referência para Desenvolvimento Distribuído de Software. In: Simpósio Brasileiro de Engenharia de Software Prikladnicki, R.; Audy, J.; Evaristo, R. Requirements Management in Global Software Development: Preliminary Findings from a Case Study in a SWCMM Context. In: II International Workshop on Global Software Development Rocha, R.; Arcoverde, D.; Brito, R.; Arôxa, B.; Costa, C.; Silva, F. Q. B. da; Albuquerque, J.; Meira, S. R. de L. Uma Experiência na Adaptação do RUP em Pequenas Equipes de Desenvolvimento Distribuído. In: Workshop de Desenvolvimento Distribuído de Software. pp Romano, F. V. Modelo de referência para o Gerenciamento do Processo de Projeto Integrado de Edificações. 326p, Taxén, L. An integration centric approach for the coordination of distributed software development projects. In: Department of Science and Technology, Campus Norrko ping, Linko ping University, Norrko ping, Sweden. Março Vanzin, M.; Ribeiro, M.; Prikladnicki, R.; Ceccato, I.; Antunes, D. Global Software Processes Definition in a Distributed Environment. In: Software Engineering. pp Weissleder, S.; Schlingloff, B.-H. Quality of Automatically Generated Test Cases Based on OCL Expressions. In: International Conference on Software Testing, Verification, and Validation. pp,

157 Catálogo de Riscos em Gerência de Projetos de Software Um Estudo Exploratório Valeska Machado, Heitor Costa Departamento Ciência da Computação - Universidade Federal de Lavras Caixa Postal CEP Lavras - MG - Brasil valeska2010@sistemas.ufla.br, heitor@dcc.ufla.br Abstract. The software industry is constantly growing; the growing use of technology for the development and provision of services in this industry has required complex and risky projects. These projects are in uncertain conditions and when there is a potential source to cause positive or negative effect on the project is called risk. Poor risk management can lead to project failure. Therefore, risk management in software project is crucial to its success. Knowing this, in this work, through research in the literature, catalogs risks that may occur during the development of software projects are presented. Resumo. A indústria de software está em constante crescimento, o crescente uso de tecnologia para o desenvolvimento e a prestação de serviços tem exigido dessa indústria projetos complexos e arriscados. Esses projetos estão em condições incertas e quando há fonte potencial para provocar efeito positivo ou negativo no projeto é chamado risco. Má gerência de riscos pode levar ao fracasso do projeto. Portanto, o gerenciamento de risco em projeto de software é crucial para seu sucesso. Sabendo disto, neste trabalho, por meio de pesquisa na literatura, são apresentados catálogos de riscos que podem ocorrer durante o desenvolvimento de projetos de software. Aluno: Valeska Alves Nunes Mahcado Orientador: Heitor Augustus Xavier Costa Categoria: Trabalho de Conclusão de Curso de Graduação Estágio do Trabalho: Em Desenvolvimento 1. Introdução A indústria de software é a que mais cresce [Hu et al., 2013]. A crescente utilização de tecnologia para desenvolvimento e para prestação de serviços têm exigido dessa indústria projetos complexos e arriscados [Carvalho et al., 2013]. Esses projetos exigem a realização antecipada de atividades, efetuadas por pessoas e meios materiais [Fang et al., 2012] e tais projetos precisam ser planejados para terem mais chances de sucesso [Orth; Prikladnicki, 2009]. Mas, muitas vezes, os projetos falham ou não atingem o resultado esperado [Molinari, 2010], pois não são planejados com as informações necessárias, mas com as disponíveis. Por esse motivo, cria-se um ambiente de incertezas e/ou indefinições [Orth; Prikladnicki, 2009] que podem levar a falhas e comprometer a realização bem sucedida do projeto em vários parâmetros, tais como, tempo, custo, escopo, qualidade, segurança, saúde e meio ambiente [Fang et al., 2012]. Tais 157

158 incertezas, quando há potencial de dano/perda ou ganho, podem ser chamadas de riscos [Aven; Zio, 2011]. Para solucionar dificuldades encontradas na realização de projetos de software que atendam escopo, prazo, custo e qualidade e satisfaçam necessidades e expectativas das pessoas envolvidas/afetadas pelas atividades do projeto, as organizações têm procurado cada vez mais a gerência de projetos de software [Orth; Prikladnicki, 2009]. Nessa gerência, a gerência de risco é fundamental e indispensável para o sucesso dos projetos, para dar garantia de sucesso e conforto aos participantes do projeto ou, pelo menos, avisá-los sobre potenciais problemas/desastres [Fang; Marle, 2012]. Os gerentes de projetos de software têm que administrar os riscos de forma eficaz e eficiente. Isso significa realizar a gestão de riscos, identificando, avaliando e planejando ações a serem realizadas e monitorando continuamente os riscos de seus projetos [López; Salmeron, 2012]. Essa gestão pode levar a benefícios organizacionais [Bannerman, 2008], incluindo identificação de cursos alternativos favoráveis de ação, aumento da confiança na realização dos objetivos do projeto, melhores chances de sucesso, surpresas reduzidas, estimativas precisas e diminuição de esforços. Neste artigo, o objetivo é apresentar riscos que podem ocorrer em projetos de software. Para isso, catálogos de riscos que podem ocorrer ao longo da gerência de projetos de software foram elaborados e são apresentados, apontando os mais riscos frequentes e em quais trabalhos científicos esses riscos foram encontrados. O restante do artigo está organizado da seguinte forma. Conceitos de gerência de projetos e de gerência de riscos são brevemente destacados na Seção 2. Catálogos iniciais de riscos são apresentados na Seção 3. Trabalhos relacionados estão resumidos na Seção 4. Conclusões e sugestões de trabalhos futuros são apresentadas na Seção Referencial Teórico 2.1. Gerência de Projetos Um projeto é um esforço temporário para criar um produto, serviço ou resultado único. Temporário significa que os projetos possuem início e término definidos. O término é alcançado quando os objetivos tiverem sido atingidos e o projeto for encerrado, quando um projeto é cancelado ou quando a necessidade do projeto não existe mais. Temporário não significa necessariamente de curta duração, pois projetos podem durar anos para serem concluídos [PMBoK, 2013]. Para que um projeto de software seja bem sucedido, é necessário analisar alguns fatores, por exemplo, o escopo do software, os riscos envolvidos e os recursos necessários. Analisar esses fatores é função do gerente de projetos que inicia antes do trabalho técnico e prossegue à medida que o software é desenvolvido para formar um produto [Matos et al., 2010]. A gerência de projetos é a aplicação de conhecimentos, de habilidades, de ferramentas e de técnicas às atividades do projeto para alcançar os objetivos do projeto [PMBoK, 2013] que consiste em estabelecer e manter planos que definem as atividades, os recursos e as responsabilidades do projeto [SOFTEX, 2009]. O Project Management Body of Knowledge (PMBoK) é um guia, amplamente utilizado por vários setores da indústria, criado e mantido pelo Project Management Institute PMI, que consiste na junção das melhores práticas de gerenciamento de projetos disponíveis no mercado [PMBoK, 2013; Gaffo; Barros, 2012]. Uma boa prática não significa que deve ser 158

159 sempre aplicado uniformemente nos projetos; a equipe de projetos é responsável por determinar o que é adequado para um projeto específico [Filho; Alves, 2010]. No PMBoK, são sugeridos 47 processos organizados em cinco grupos de processos [PMBoK, 2013; Gaffo; Barros, 2012]: i) processos de iniciação; ii) processos de planejamento; iii) processos de execução; iv) processos de monitoramento e controle; e v) processos de encerramento. Além disso, esses processos estão organizados em dez áreas de conhecimento [PMBoK, 2013; Scofano et al., 2013]: i) gerenciamento de integração; ii) gerenciamento de escopo; iii) gerenciamento de tempo; iv) gerenciamento de custos; v) gerenciamento de qualidade; vi) gerenciamento de recursos humanos; vii) gerenciamento de comunicações; viii) gerenciamento de riscos; ix) gerenciamento de aquisições; e x) gerenciamento de partes interessadas. A gerência de projetos é importante para as organizações, pois é entendido como um ativo estratégico, base para o crescimento e a sobrevivência em longo prazo. Isso significa que os projetos para as organizações estão associados à sua sobrevivência e podem maximizar o valor para os negócios, viabilizar o retorno sobre os investimentos, minimizar os riscos, permitir o alcance de objetivos estratégicos e aumentar a satisfação dos clientes [Silveira et al., 2013]. Assim, gerenciar projetos de forma eficiente e eficaz é fator importante para o sucesso do projeto, em que as organizações necessitam ter visão e mover-se para a melhoria da capacidade em gerenciamento de projetos com esforços direcionados. De fato, as organizações que se dedicam a desenvolver com propriedade o gerenciamento de projetos podem atingir melhores resultados em termos de resultados empresariais [Kerzner, 2001] Gerência de Riscos Em qualquer fase do ciclo de vida, um projeto é "atormentado" com vários riscos por causa da sua natureza complexa e dinâmica [Zhao et al., 2010]. Tais riscos são inerentes a qualquer projeto, sendo específicos a cada tipo de projeto [Scofano et al., 2013]. O risco é definido como elementos incertos às expectativas, "aquilo" que age em pelo menos um dos objetivos do projeto (qualidade, custo e tempo), as metas e os meios estratégicos (pessoas, processos, informação e comunicação), influenciando o ambiente e provocando prejuízos [Baraldi, 2010]. No gerenciamento de riscos, são tratadas as incertezas dos projetos, sendo o principal objetivo contribuir para diminuir efeitos negativos (ameaças) e potencializar efeitos positivos (oportunidades) de forma sistemática e por todo o ciclo de vida do projeto [Scofano et al., 2013]. Há seis processos, cada um ocorre pelo menos uma vez [PMBoK, 2013; Matos et al., 2010]: i) Planejar Gerenciamento de Riscos; ii) Identificar Riscos; iii) Realizar Análise Quantitativa dos Riscos; iv) Realizar Análise Qualitativa dos Riscos; v) Planejar Respostas aos Riscos; e vi) Monitorar e Controlar Riscos. O papel fundamental da gerência de risco é transformar riscos em vantagem competitiva; portanto, os riscos, por mais sérios que possam ser e com mais consequências negativas que possam ter, podem e devem ser tratados de forma a gerar consequências positivas, transformando-o em vantagem competitiva para a empresa [Scofano et al., 2013]. No gerenciamento de risco, há benefícios por conduzir o gerente de projetos em escolher melhores saídas para os eventos negativos e aproveitar melhor os eventos positivos [Scofano et al., 2013]. Além disso, outros benefícios podem ser alcançados, por exemplo, a obtenção de sucesso no desenvolvimento do projeto, a preservação de 159

160 bens e de vidas humanas, a permanência da empresa no mercado, a motivação de colaboradores da empresa e o aumento da produção e da competitividade [Hahn; Mozzaquatro, 2011]. Gerenciar riscos de projetos de software contribui de forma ampla para a qualidade do produto final. Além desses benefícios, há aumento da probabilidade de entregar um produto confiável e de qualidade ao cliente [Hahn; Mozzaquatro, 2011]. 3. Riscos em Projetos de Software Em uma pesquisa na literatura, foram identificados riscos que podem ser encontrados em projetos de software, que totalizam 36 riscos. Para identificá-los foram selecionados os seguintes trabalhos: Foi desenvolvida uma classificação alternativa de fatores abrangentes de riscos com base em análise fatorial exploratória, utilizando o método PCA (Principal Component Analysis) na área de projeto de software [Leopoldino et al., 2011]. Nessa classificação, os riscos foram categorizados por meio de fatores identificados na avaliação de riscos de gerentes de projeto e de desenvolvedores, considerando a probabilidade de ocorrência e a gravidade potencial das variáveis de riscos na obtenção dos fatores de riscos. Com a utilização do PCA, foram obtidos sete fatores a partir de 32 variáveis de risco. Cada fator foi visto como uma forma abrangente de classificar/entender/trabalhar com um conjunto maior de riscos utilizando quantidade menor de grandes componentes; Em um estudo [López; Salmeron, 2012], são apresentados riscos que afetam o sucesso de projetos em Sistemas de Informação/Tecnologia da Informação. Para realização do trabalho, foi utilizada a abordagem IPA (Importance-Performance Analysis) para identificar os riscos. Ao final, foram identificados 46 riscos. Especialistas estimaram a probabilidade e o impacto dos riscos identificados e, com o resultado, uma matriz com quatro quadrantes foi proposta (Quadrante 1: riscos com alto impacto e alta probabilidade; Quadrante 2: riscos com alto impacto e baixa probabilidade; Quadrante 3: riscos com baixo impacto e baixa probabilidade; Quadrante 4: riscos com baixo impacto e alta probabilidade); Em outro estudo [Arnuphaptrairong, 2011], o objetivo foi identificar riscos mais comuns em projetos de software. Para isso, foi realizada uma pesquisa na literatura e os resultados foram 10 listas de riscos em projetos de software. Alguns requisitos foram considerados, tais como, tempo em que a pesquisa foi realizada, a cultura (país onde os riscos formam encontrados), método de investigação (método de coleta de dados) e temas e questões utilizadas na pesquisa. Como conclusão do estudo, sete riscos em comum foram encontrados nas 10 listas; Em mais um trabalho [Fontoura et al., 2004], foram identificados riscos na literatura, classificando-os em riscos de clientes, de requisitos, de planejamento e de execução. Além disso, foram identificadas ações na literatura para minimizar tais riscos e GQM foi utilizado para monitorá-los; Em uma pesquisa [Huang; Han, 2008], foram identificados 27 riscos em trabalhos, concluídos em 2005, e em entrevistas, cujos entrevistados forneceram características de seus projetos. A exposição ao risco foi definida como a probabilidade de ocorrência de um fator de risco multiplicado pelo impacto sobre o cronograma do projeto. Um método de análise de cluster foi utilizado para classificar os projetos de acordo com sua duração. Como resultados, a exposição de riscos associados ao usuário, ao planejamento e controle, à exigência e à equipe foram afetados pela 160

161 duração do projeto. Por outro lado, as exposições de riscos, a complexidade do projeto e o ambiente organizacional não foram significativamente afetados pela duração do projeto; Foram investigados riscos no desenvolvimento de software terceirizado [Nakatsu; Iacovou, 2009]. Esses riscos foram colocados em listas de fatores e foi considerado o que poderia mudar nesses riscos dependendo do contexto. Foram realizadas pesquisas para identificar importantes fatores de riscos em alguns contextos. Como resultado, foram encontrados três fatores de riscos em comum nas listas; Riscos foram organizados em seis categorias [Wallace et al., 2004]. Foi feita uma análise para identificar projetos de baixo, médio e alto risco. Como resultado, foi mostrado que o escopo do projeto afeta as categorias dos riscos, ao passo que as práticas de abastecimento e de orientação estratégica tiveram impacto mais limitado. Os riscos identificados são apresentados em sete catálogos com os seguintes elementos: i) ID, indicador único para cada risco; ii) Riscos, riscos identificados na literatura; iii) Referências, trabalhos em que os riscos foram encontrados; e iv) Componente, categoria para facilitar compreensão e entendimento de onde o risco pode ser encontrado. Os riscos identificados, suas siglas e suas referências foram colocados em sete catálogos e separados em sete componentes [Leopoldino et al., 2011]: Gerência de Projetos (Tabela 1). Envolve as funções dos gerentes de projetos. Algumas responsabilidades do gerente de projetos são cuidar dos custos, estimar prazos e tempo para a execução das tarefas, definir papéis e responsabilidades e controlar e planejar o projeto de software. O gerente de projetos deve possuir atributos como experiência e habilidades para que o projeto tenha sucesso; Equipe de Desenvolvimento (Tabela 2). Depende da interação das pessoas envolvidas no projeto para o trabalho ser eficiente e eficaz e da interação da equipe. Portanto, equipe desmotivada, conflitos e falta de cooperação entre membros, falta de ferramentas e recursos adequados, testes e desempenho inadequados do sistema, falta de comunicação, alta rotatividade de pessoas, pessoal insuficiente/excesso, membros treinados inadequadamente e falta de compromisso da equipe de desenvolvimento com o projeto dificilmente podem ser eficientes e eficazes; Escopo e Requisitos (Tabela 3). É pouco estável, pois, por exemplo, falhas no levantamento de requisitos, mudanças organizacionais e novas solicitações dos clientes geram mudanças no escopo e nos requisitos em um projeto de software; Conhecimento e Incerteza Tecnológica (Tabela 4). É frequente em projetos de software. Envolve tecnologia, projetos de múltiplos fornecedores e conhecimento e/ou habilidades para o projeto. A falta de conhecimento e/ou habilidades para o projeto podem ser minimizadas por meio de aprendizagem sobre a lógica do negócio, metodologias e/ou tecnologias de implementação; Relacionamento com o Ambiente Externo (Tabela 5). Destaca as decisões tomadas no ambiente externo, em que gerente deve cuidar do relacionamento dos clientes com a alta gerência; Relacionamento com o Cliente/Usuário (Tabela 6). Destaca o entrosamento e a cooperação entre os usuários e o envolvimento do usuário com o projeto; Valor/Importância Atribuído ao Projeto (Tabela 7). Destaca a importância que os envolvidos no projeto dão a ele. Ou seja, expectativas do usuário final durante o desenvolvimento do projeto, se o projeto está sendo acompanhado, se o projeto é viável e atende a realidade em que está inserido. Portanto, as expectativas a respeito 161

162 do projeto não devem ser exageradas, nem ficar abaixo do prometido para o projeto, pois pode gerar decepção ou a não adoção do produto. Tabela 1 - Catálogo de Riscos em Projetos de Software - Componente Gerência de Projetos Gerência de Projetos ID Riscos Referências GP1 Definição inadequada de funções e de responsabilidades. [Leopoldino et al., 2011; López; Salmeron, 2012] GP2 GP3 GP4 GP5 GP6 GP7 GP8 Falta de estabelecimento de processos/procedimentos/metodologia/planejamento do projeto. Controle pobre ou inexistente. Estimativa inadequada dos recursos necessários. Principais gestores tomam decisões sem consultar os demais participantes do projeto. Cronograma irreal. Projeto extenso/complexo. Gerente de projetos inexperiente/sem habilidades necessárias. [Leopoldino et al., 2011; López; Salmeron, 2012; Arnuphaptrairong, 2011; Fontoura et al., 2004; Huang; Han, 2008; Nakatsu; Iacovou, 2009] [Leopoldino et al., 2011; López; Salmeron, 2012; Nakatsu; Iacovou, 2009] [Leopoldino et al., 2011; López; Salmeron, 2012; Fontoura et al., 2004; Huang; Han, 2008; Nakatsu; Iacovou, 2009] [López; Salmeron, 2012] [Leopoldino et al., 2011; López; Salmeron, 2012; Fontoura et al., 2004; Nakatsu; Iacovou, 2009] [López; Salmeron, 2012; Huang; Han, 2008; Wallace et al., 2004] [Leopoldino et al., 2011; López; Salmeron, 2012; Huang; Han, 2008] Tabela 2 - Catálogo de Riscos em Projetos de Software - Componente Equipe de Desenvolvimento Equipe de Desenvolvimento ID Riscos Referências ED1 Alta rotatividade da equipe. [López; Salmeron, 2012; Nakatsu; Iacovou, 2009; Wallace et al., 2004] ED2 Pessoal insuficiente/excesso de pessoal/pessoal [Leopoldino et al., 2011; López; Salmeron, 2012; inapropriado na equipe de projeto. Fontoura et al., 2004] ED3 Falhas na comunicação. [López; Salmeron, 2012; Huang; Han, 2008; Nakatsu; Iacovou, 2009] ED4 Membros da equipe treinados inadequadamente. [Huang; Han, 2008; Wallace et al., 2004] ED5 Conflito e falta cooperação entre os membros da equipe. [López; Salmeron, 2012; Nakatsu; Iacovou, 2009; Wallace et al., 2004] ED6 Membros da equipe desmotivados. [Leopoldino et al., 2011; López; Salmeron, 2012; Nakatsu; Iacovou, 2009] ED7 Falta de testes adequados ao sistema. [López; Salmeron, 2012] ED8 Falta de compromisso da equipe de desenvolvimento com o projeto. [Wallace et al., 2004] ED9 Ferramentas/recursos impróprios para o desenvolvimento. [Leopoldino et al., 2011; Fontoura et al., 2004] ED10 Desempenho do sistema inadequado (falta de integração [López; Salmeron, 2012; Fontoura et al., 2004; entre os sistemas/sistemas altamente sincronizados, entre Nakatsu; Iacovou, 2009] outros). Tabela 3 - Catálogo de Riscos em Projetos de Software - Componente Escopo e Requisitos Escopo e Requisitos ID Riscos Referências ER1 Especificações de requisitos/objetivos mal definidos. [Leopoldino et al., 2011; López; Salmeron, 2012; Arnuphaptrairong, 2011; Fontoura et al., 2004; Huang; Han, 2008; Nakatsu; Iacovou, 2009; Wallace et al., 2004] ER2 Mudança nos requisitos/objetivos. [Leopoldino et al., 2011; López; Salmeron, 2012; Arnuphaptrairong, 2011; Fontoura et al., 2004; Huang; Han, 2008; Nakatsu; Iacovou, 2009; Wallace et al., 2004] 162

163 Tabela 4 - Catálogo de Riscos em Projetos de Software - Componente Conhecimento e Incerteza Tecnológica Conhecimento e Incerteza Tecnológica ID Riscos Referências CI1 CI2 Tecnologia nova/imatura/não familiar para usuários e membros da equipe do projeto. Falta de conhecimento/habilidades necessárias no projeto. [Leopoldino et al., 2011; López; Salmeron, 2012; Fontoura et al., 2004; Huang; Han, 2008; Nakatsu; Iacovou, 2009; Wallace et al., 2004] [Leopoldino et al., 2011; López; Salmeron, 2012; Fontoura et al., 2004; Huang; Han, 2008; Nakatsu; Iacovou, 2009; Wallace et al., 2004] CI3 Projeto de múltiplos fornecedores. [Leopoldino et al., 2011; Wallace et al., 2004] Tabela 5 - Catálogo de Riscos em Projetos de Software - Componente Relacionamento com o Ambiente Externo Relacionamento com o Ambiente Externo ID Riscos Referências RA1 Falha em obter comprometimento do cliente com o projeto. [Leopoldino et al., 2011; López; Salmeron, 2012; Arnuphaptrairong, 2011] RA2 Falta de comprometimento da alta direção com o projeto. [Leopoldino et al., 2011; López; Salmeron, 2012; Arnuphaptrairong, 2011; Fontoura et al., 2004; Nakatsu; Iacovou, 2009; Wallace et al., 2004] RA3 Falta de poderes para o gerenciamento de projetos. [Leopoldino et al., 2011] RA4 Subcontratação (tarefas/componentes desenvolvidos externamente). [Fontoura et al., 2004] RA5 Gerenciamento impróprio de mudanças. [Leopoldino et al., 2011; López; Salmeron, 2012; Fontoura et al., 2004] Tabela 6 - Catálogo de Riscos em Projetos de Software - Componente Relacionamento com o Cliente/Usuário Relacionamento com o Cliente/Usuário ID Riscos Referências RC1 Usuários resistentes às mudanças. [López; Salmeron, 2012; Huang; Han, 2008] RC2 Conflito e falta cooperação entre os usuários. [Leopoldino et al., 2011; López; Salmeron, 2012; Fontoura et al., 2004; Huang; Han, 2008; Nakatsu; Iacovou, 2009] RC3 Usuários solicitando alterações constantemente. [López; Salmeron, 2012] RC4 Falta de envolvimento/apoio adequado do usuário. [Leopoldino et al., 2011; López; Salmeron, 2012; Arnuphaptrairong, 2011; Fontoura et al., 2004; Nakatsu; Iacovou, 2009] Tabela 7 - Catálogo de Riscos em Projetos de Software - Componente Valor/Importância Atribuído ao Projeto Valor/Importância Atribuído ao Projeto ID Riscos Referências VP1 Falha em gerenciar expectativas do usuário final. [Leopoldino et al., 2011; López; Salmeron, 2012; Arnuphaptrairong, 2011; Fontoura et al., 2004; Nakatsu; Iacovou, 2009] VP2 Projeto não acompanhado de perto o suficiente. [López; Salmeron, 2012; Huang; Han, 2008] VP3 Resultado do projeto irrealista/inviável. [López; Salmeron, 2012; Fontoura et al., 2004] VP4 Mudança de propriedade/gestão/prioridade organizacional. [López; Salmeron, 2012; Huang; Han, 2008; Wallace et al., 2004] 4. Trabalhos Relacionados Uma revisão sistemática foi apresentada sobre gerenciamento de riscos em projetos de software [Carvalho et al., 2013], cujo objetivo foi coletar informações sobre trabalhos de gerenciamento de riscos feitos no Brasil. Nessa revisão, foram utilizadas pesquisas manual e automática. A pesquisa manual foi por eventos científicos em Engenharia de Software realizados no Brasil. Posteriormente, os eventos científicos selecionados foram restringidos ao período de 2002 a Com a leitura dos títulos das publicações, foram escolhidos artigos que mencionavam riscos, gerenciamento de riscos ou ameaças em desenvolvimento de software. Em seguida, com a leitura do resumo, foi obtida uma 163

164 nova lista de artigos e, por meio da leitura completa desses artigos, oito artigos foram escolhidos. O critério de escolha foi artigos que utilizam gerenciamento de riscos em projetos de software com abordagens e ferramentas destinadas a atividade desse gerenciamento. A busca automática foi por strings de busca, combinando palavraschave com os operadores lógicos AND e OR para selecionar a relevância das publicações. Para avaliação da qualidade dos artigos, foram utilizadas pontuações para selecionar os artigos com mais destaque. Uma dificuldade para a gerência de riscos em projetos de software é a existência de diversas visões parciais sobre esse domínio [Gusmão, 2007]. Cada visão carrega um vocabulário e valores próprios, dificultando a integração entre os diversos profissionais pela ausência de padronização. Esse problema pode ser minimizado se a conceituação envolvida no domínio da gerência de riscos for, pelo menos parcialmente, explicitada, o que pode ser feito por meio de uma ontologia de domínio. Uma ontologia de riscos, com o intuito de minimizar esse problema foi desenvolvida [Falbo, 2010]. Para desenvolver a ontologia de gerência de riscos, foi adotado o método SABiO (Systematic Approach for Building Ontologies) [Falbo et al., 2004]. A ontologia foi desenvolvida de forma modular, considerando os aspectos Riscos e Fontes e Categorias de Riscos, Riscos de um Projeto de Software e suas Avaliações, Gerência de Riscos de um Projeto de Software e Processo da Gerência de Riscos. Essa ontologia pode ser utilizada como referência em um vocabulário comum sobre esse domínio e como uma especificação reutilizável para a construção de ferramentas de apoio ao Gerenciamento de Riscos. Um modelo de avaliação de riscos em projetos de software com base na teoria fuzzy é proposto para avaliar consequências e perdas que riscos podem proporcionar ao projeto de software [Tang; Wang, 2012]. Com esse modelo, foram avaliados riscos individuais, conjuntos de riscos e suas consequências para o projeto de software e houve contribuição para diminuir incertezas criadas com a avaliação de especialistas, aumentar a previsão e a capacidade de resposta ao risco, reduzir a probabilidade de risco e aumentar a taxa de sucesso de projetos de software. Um estudo de caso com propósito exploratório foi realizado [Souza et al., 2010] para conhecer a relação entre compartilhamento do conhecimento e gerenciamento de riscos em projetos de software utilizando análise não probabilística. A pesquisa de campo foi realizada em duas empresas de Belo Horizonte/MG, cuja atividade é desenvolver sistemas de software. Foram coletadas e analisadas percepções e opiniões dos participantes da pesquisa sobre suas práticas nas empresas em que atuam referentes ao gerenciamento de riscos, ao compartilhamento do conhecimento em projetos de software e a relação entre os dois temas. Como resultado, certos instrumentos (construções de cenário, protótipos e simulações sobre situações de riscos) podem determinar ações adequadas para eliminar riscos. A experiência das pessoas sobre diferentes fontes de conhecimento e visões sobre o assunto pode ser importante para potencializar a execução da atividade de análise dos riscos. Assim, esses resultados contribuem para compartilhar conhecimento sobre riscos a fim de minimizá-los e garantir o sucesso do projeto de software. 5. Considerações Finais Um projeto de software bem sucedido necessita de estratégias eficazes de gerenciamento de risco. Portanto, os gerentes de projetos de software devem selecionar 164

165 uma estratégia para saber lidar com tais riscos. Sabendo disso, neste trabalho, foram identificados riscos que podem ocorrer com mais frequência em um projeto de software. Com os riscos que podem ocorrer em qualquer projeto de software, os gerentes de projetos podem estar preparados caso esses riscos ocorreram em seus projetos e saibam melhor lidar com tais riscos para aumentar suas oportunidades e diminuir os riscos, buscando a qualidade do projeto e a satisfação do cliente. Como sugestão de trabalhos futuros, pretende-se continuar a identificação de riscos elencados na literatura. Além disso, almeja elaborar/identificar medidas para avaliar o impacto da ocorrência de riscos em projetos de software; para isso, será utilizado o método GQM (Goal/Question/Metric). Referências Arnuphaptrairong, T. (2011) Top Ten Lists of Software Project Risks: Evidence from the Literature Survey. In: International MultiConference of Engineers and Computer Scientists, v.1, pp Aven, T.; Zio, E. (2011) Some Considerations on the Treatment of Uncertainties in Risk Assessment for Practical Decision Making. In: Realiability Engineering & System Safety, v. 96, pp Bannerman, P. (2008) Risk and Risk Management in Software Projects: A Reassessment. In: Journal of Systems and Software, v. 81, pp Baraldi, P. (2010) Gerenciamento de Riscos Empresariais. Campus - RJ, 360p. Carvalho, L.; Andrade, H.; Lobato, L. (2013) Um Breve Estudo sobre Gerenciamento de Riscos em Projetos de Software no Brasil. In: X Encontro Anual de Computação. Falbo, R. A. (2010) Uma Ontologia de Riscos de Software. In: IX Simpósio Brasileiro de Qualidade de Software, pp Falbo, R. A.; Ruy, F. B.; Bertollo, G.; Togneri, D. F. (2004) Learning How to Manage Risks Using Organizational Knowledge. In: International Workshop on Advances in Learning Software Organizations, v. 3096, pp Fang, C.; Marle, F. (2012) A Simulation-Based Risk Network Model for Decision Support in Project Risk Management. In: Decision Support Systems, v. 52, pp Fang, C.; Marle, F.; Zio, E.; Bocquet, J. (2012) Network Theory-Based Analysis of Risk Interactions in Large Engineering Projects. In: Reliability Engineering & System Safety, v. 106, pp Filho, A. C. O. da.; Alves, A. L. (2010) Proposta de Processo SCRUM Utilizando Conceitos da Gestão do Tempo Definida pelo PMBOK. In: V Mostra de Produção Científica. Fontoura, L. M.; Price, R. T.; Phil, D. (2004) Usando gqm para gerenciar riscos em projetos de software. In: 18º Simpósio Brasileiro de Engenharia de Software, JF de Castro, editor, v.18, pp Gaffo, F. H.; Barros, R. M. D. (2012) GAIA Risks - A Service-Based Framework to Manage Project Risks. In: XXXVIII Conferencia Latinoamericana, pp Gusmão, C. M. G. (2007) Um Modelo de Processo de Gestão de Riscos para Ambientes de Múltiplos Projetos de Desenvolvimento de Software. Tese de Doutorado. Centro de Informática, Universidade Federal de Pernambuco. 165

166 Hahn, A. F.; Mozzaquatro, P. M. (2011) Gerência de Riscos do Projeto de Software. In: II Mostra de Iniciação Científica da Ciência da Computação. Hu, Y.; Zhang, X.; Ngai, E.; Cai, R.; Liu, M. (2013) Software Project Risk Analysis Using Bayesian Networks with Causality Constraints. In: Decision Support Systems, v. 56, pp Huang, S. J.; Han, W. M. ()2008 Exploring the relationship between software project duration and risk exposure: A cluster analysis. In: Information & Management, v. 45(3), pp Kerzner, H. (2001) Project Management: A Systems Approach to Planning, Scheduling, and Controlling. John Wiley & Sons, 1040p. Leopoldino, C.; Borenstein, D. (2011) Componentes de Risco para a Gestão de Projetos de Software. In: Revista Eletrônica de Administração, v. 17(3), pp López, C.; Salmeron, J. (2012) Risks Response Strategies for Supporting Practitioners Decision-Making in Software Projects. In: Procedia Technology, v. 5, pp Matos, P. M.; Bermejo, P. H. S.; Júnior, J. F. S. (2010) Gerência de Riscos em Projetos de Software: Baseada nos Modelos de Processos de Referência PMBOK, CMMI, MPS.BR, TenStep e ISSO Ciência Moderna, 68p. Molinari, L. (2010) Gestão de Projetos: Técnicas e Práticas com Ênfase em Web. Érica, 384p. Nakatsu, R. T.; Iacovou, C. L. (2009) A comparative study of important risk factors involved in offshore and domestic outsourcing of software development projects: A two-panel Delphi study. In: Information & Management, v. 46(1), pp Orth, A. I.; Prikladnicki, R. (2009) Planejamento e Gerência de Projetos. EdiPUCRS, 179p. PMBoK. (2013) A Guide to the Project Management Body of Knowledge, Project Management Institute. Ed. 5, Newtown Square, Pennsylvania, USA. Scofano, C. R. F.; Abraham, E. de F.; Silva, L. de S.; Teixeira, M. A. (2013) Gestão de Risco em Projetos: Análise das Etapas do PMI-PMBok (Project Management Institute). In: X Congresso Online de Administração. Silveira, G. A. de.; Sbragia, R.; Kruglianskas, I. (2013) Fatores Condicionantes do Nível de Maturidade em Gerenciamento de Projetos: Um Estudo Empírico em Empresas Brasileiras. In: Revista de Administração da Universidade de São Paulo, v. 48(3), pp Softex (2009) MPS. BR - Guia de Implementação - Parte 8. Souza, Y.; Vasconcelos, M.; Judice, V.; Jamil, G. A. (2010) Contribuição do Compartilhamento do Conhecimento para o Gerenciamento de Riscos em Projetos: Um Estudo na Indústria de Software. In: Journal of Information Systems and Technology Management, v. 7, n. 1, pp Tang, A. G.; Wang, R. L. (2010) Software Project Risk Assessment Model Based on Fuzzy Theory. In: Computer and Communication Technologies in Agriculture Engineering, v. 2, pp Wallace, L.; Keil, M.; Rai, A. (2004) Understanding software project risk: a cluster analysis. In: Information & Management, v. 42(1), pp Zhao, Z. Y.; Lv, Q. L.; Zuo, J.; Zillante, G. Prediction System for Change Management in Construction Project. In: Journal of Construction Engineering Management, v. 136 (6), pp

167 Análise Comparativa de Tecnologias de Programação no Contexto de Linhas de Produtos de Software José Natanael Reis 1, Gustavo Vale 2, Heitor Costa 1 1 Departamento Ciência da Computação - Universidade Federal de Lavras Lavras - MG - Brasil 2 Departamento de Ciência da Computação - Universidade Federal de Minas Gerais Belo Horizonte, MG - Brasil jnatanael@computacao.ufla.br, gustavovale@dcc.ufmg.br, heitor@dcc.ufla.br Abstract. In the context of Software Product Line (SPL) is aimed at the systematic and large-scale reuse. Maintainability of SPL should be high, since the change in a module can impact on various other products. Therefore, figuring out which technology/language has greater maintainability can help companies working with systems that require constant changes to choose the technology development. The objective of this study is to evaluate the maintainability of two equivalent SPLs implemented with Feature-Oriented Programming using AHEAD and Aspect-Oriented Programming using AspectJ. As result, in this study, the SPL implemented using AspectJ, having evidence that has better maintainability than the SPL using AHEAD. Resumo. No contexto de Linha de Produtos de Software (LPS), é visado o reúso sistemático e em larga escala. A capacidade de manutenção da LPS deve ser elevada, pois a mudança em um módulo pode impactar em vários outros produtos. Dessa forma, descobrir qual tecnologia/linguagem possui maior manutenibilidade, pode ajudar empresas desenvolvedoras de software, que necessitam de constantes alterações, a escolher a tecnologia de desenvolvimento. Neste trabalho, o objetivo é avaliar a manutenibilidade de duas Linhas de Produtos de Software equivalentes implementadas com Programação Orientada a Características utilizando AHEAD e com Programação Orientada a Aspectos utilizando AspectJ. Como resultado, neste estudo, a LPS implementada em AspectJ se destacou, possuindo melhor manutenibilidade que a LPS implementada em AHEAD. Aluno: José Natanael Reis Coorientador: Gustavo Andrade do Vale Orientador: Heitor Augustus Xavier Costa Categoria: Trabalho de Conclusão de Curso de Graduação Estágio do Trabalho: Em Desenvolvimento 1. Introdução A maneira artesanal como os bens de consumo eram produzidos anteriormente ao século XX atendia as necessidades de pessoas individualmente. A adoção do capitalismo e o 167

168 aumento no consumo fizeram com que a quantidade de pedidos aumentasse. Com isso, para atender essa demanda, os bens passaram a ser produzidos em série, aumentando a quantidade de bens e reduzindo o grau de customização. Na área da Computação, produtos encomendados e produtos genéricos podem ser identificados, ambos com suas peculiaridades. Os produtos encomendados geralmente são mais caros que os produtos genéricos, pois exigem mais esforços no desenvolvimento e possuem funções específicas para determinado cliente. Em contra partida, sistemas genéricos são mais baratos; no entanto, eles podem ter funções desnecessárias para determinado cliente e não possuir funções específicas que atendam suas necessidades. Um dos objetivos na Engenharia de Software é gerenciar e controlar a complexidade de sistemas [Pereira, 2012]. Para atender as necessidades de clientes, os sistemas estão se tornando cada vez mais complexos, o que dificulta o seu gerenciamento. Além disso, o reúso de (partes de) módulos de sistemas, quando não ordenados, pode comprometer a eficiência do desenvolvimento, tornando-o mais custoso que o desenvolvimento a partir do zero. Para melhorar o gerenciamento de artefatos de código, principalmente artefatos reutilizados, algumas técnicas foram elaboradas, entre elas destaca-se a estratégia de desenvolvimento em Linha de Produtos de Software (LPS). Uma LPS consiste em um conjunto de sistemas de software que possuem e compartilham características (features) comuns para satisfazer as necessidades de um domínio. Ela é desenvolvida a partir de um conjunto comum de ativos base de uma forma prescrita [Batory, 2003]. Uma LPS é fundamentada em uma estratégia para projeto e para implementação de sistemas, cujo objetivo é promover o reúso sistemático e em larga escala de componentes [Northrop, 2002]. Esses componentes são chamados características, as quais permitem diferenciar os produtos presentes na LPS que apresentam funções comuns e diferenciadas, conhecidas como variabilidade. Uma vez que o sistema pode ser decomposto em características, pode-se ter diferentes versões dele mediante a (re)combinação de certas características [Boucher et al., 2010]. Para o desenvolvimento de LPSs, podem ser utilizadas diferentes abordagens, por exemplo, tecnologias baseadas em composição. Dentre as tecnologias baseadas em composição podem ser citadas a Programação Orientada a Características (POC) e a Programação Orientada a Aspectos POA. Em POC, pode ser utilizado AHEAD (Algebric Hierarchial Equations for Application Design) e, em POA, AspectJ; ambas são baseadas em Java. A estratégia de LPS difere do modelo tradicional de desenvolvimento de software, pois combina desenvolvimento genérico e desenvolvimento customizado, o que resulta em sistemas desenvolvidos em larga escala com a possibilidade de obter um produto customizado [Vale, 2013]. Além disso, com o alto índice de reúso e gerenciamento preciso, custos e prazos podem ser reduzidos e o lucro pode ser aumentado. Como essa estratégia visa ao reúso sistemático e em larga escala, a capacidade de manutenção da LPS deve ser elevada, pois realizar manutenções em uma LPS é mais complexo do que em sistemas únicos, pois a alteração em um módulo pode impactar em vários outros produtos [Vale, 2013]. Assim, descobrir qual tecnologia/linguagem possui maior manutenibilidade pode ajudar empresas desenvolvedoras de software a escolher a tecnologia de desenvolvimento apropriado ao 168

169 seu contexto. Neste trabalho, o objetivo é avaliar a manutenibilidade de duas LPSs equivalentes implementadas com POC utilizando AHEAD e com POA utilizando AspectJ, respectivamente. Para realizar essa avaliação são utilizadas cinco medidas que abrangem tamanho, complexidade, acoplamento e coesão. O restante do artigo está organizado da seguinte forma. As duas tecnologias e as respectivas linguagens utilizadas neste trabalho são brevemente explicadas na Seção 2. Os procedimentos de medição e as medidas escolhidas são mostrados na Seção 3. O resultado da análise é apresentado na Seção 4. Alguns trabalhos relacionados estão resumidos na Seção 5. Conclusões e sugestões de trabalhos futuros são discutidas na Seção Tecnologias para Desenvolvimento de Linhas de Produtos de Software Nesta seção, são apresentados conceitos de Programação Orientada a Características e Programação Orientada a Aspectos. Esses conceitos são importantes, pois destacam as peculiaridades de cada tecnologia com foco principal nas linguagens utilizadas neste trabalho Programação Orientada a Características POC foi criada para síntese de sistemas de software em LPSs, na qual características são utilizadas para distinguir os sistemas de uma mesma família de produtos. Portanto, os produtos devem ser implementados em unidades de modularização sintaticamente independentes [Batory, 2003]. Um dos alicerces de POC é o refinamento sucessivo, que encapsula a implementação de uma característica. Esse conceito de refinamento sucessivo é simples e antigo na Engenharia de Software, em que programas complexos devem ser desenvolvidos a partir de partes simples. Essas partes são as características do produto complexo gerado a partir da LPS [Junior, 2008]. Os módulos criados em POC podem ser refinados de modo incremental, inserindo ou modificando métodos, atributos ou modificando a hierarquia de tipos Programação Orientada a Aspectos Em POA, é oferecido suporte a mecanismos de abstração e de composição para alcançar melhor separação de interesses na implementação. Com POA, é possível realizar a separação de interesses introduzindo nova unidade modular, denominada aspecto, para a modularização dos interesses transversais [Kiczales et al., 2001]. Aspectos são utilizados para implementar interesses transversais e são capazes de entrecortar pontos bem definidos no fluxo de execução de um programa [Junior, 2008]. AspectJ é uma linguagem de programação para orientação a aspectos aceita e com popularidade na comunidade de desenvolvedores Java. POA possui suporte a mecanismos de abstração e de composição para alcançar melhor separação de interesses no nível da implementação. Com isso, torna-se possível expressar os programas que envolvem tais aspectos, como promover a separação de interesses ao introduzir nova unidade modular, incluindo o isolamento adequado, composição e reúso do código de aspecto [Kiczales et al., 1997]. 169

170 3. Procedimentos Metodológicos Nesta seção, são apresentados a LPS em estudo, o conjunto de medidas utilizado, as dificuldades e as lições aprendidas no desenvolvimento da LPS em AspectJ e os procedimentos para realizar a medição LPS TankWar A LPS TankWar é um jogo de tanques de guerra desenvolvido em AHEAD por estudantes da Universidade de Magdeburg. Essa pode ser executada em computadores ou telefones celulares [Schulze et al., 2012]. Uma caracterização da LPS TankWar foi feita para conhecê-la/medi-la e auxiliar na comparação com as novas versões a serem geradas (Tabela 1). A LPS TankWar possui linhas, sendo que 86,3% de código fonte, 1,9% comentários de documentação e 11,9% de linhas gerais e em branco. Tabela 1 - Informações sobre a LPS TankWar (Fonte: [Vale, 2013]) Medidas Quantidade Código Linhas de Comentários de Documentação 44 Comentários Gerais 61 Classes (Constantes) 29 Interfaces (Constantes) 1 Refinamentos de Classes 56 Abstratas 6 Características Concretas 31 Produtos de Software Classes 88 Entre as variações dos produtos dessa LPS estão idioma (Inglês ou Alemão), nível de dificuldade (fácil ou difícil), escolha da quantidade de tipos de tanque para escolha do usuário (1, 2 ou 3), escolha de ferramentas para incorporar ao tanque (de 0 a 6) e possibilidade de armazenar resultados em um ranking. Ela foi escolhida por causa do seu tamanho e por tem sido utilizada em outros estudos [Apel; Beyer, 2011; Schulze et al., 2012; Schulze et al., 2010]. Essa LPS possui modelo de características com 37 características (6 abstratas e 31 concretas) [Schulze et al., 2012], podendo gerar produtos, possuir 88 classes e linhas (linhas de código, de comentários e em branco) e ter sido desenvolvida com AHEAD Medidas Contemporâneas Uma das dificuldades na Engenharia de Software é como medir a qualidade de um sistema de software. Para ajudar a minimizar essa dificuldade, normas foram elaboradas, nas quais a qualidade de produtos é divida em características, dentre elas a manutenibilidade é explorada neste trabalho. Manutenibilidade de software é a facilidade com que um sistema ou componente de software é modificado para corrigir falhas ou melhorar o desempenho [ISO/IEC 25000, 2005]. Diversas maneiras para avaliar a manutenibilidade de um sistema foram propostas na literatura, por exemplo, índice de manutenibilidade e conjuntos de medidas ou de experimentos no qual pessoas realizam a avaliação. Além disso, a manutenibilidade de um sistema pode ser determinada como um todo, por componentes (por exemplo, classes e aspectos) ou por operações (por exemplo, métodos). Como o objetivo deste trabalho é comparar a 170

171 manutenibilidade de diferentes tecnologias/linguagens, optou-se por trabalhar com componentes. Para este trabalho, um conjunto de cinco medidas foi escolhido de forma que abrangessem os atributos de tamanho, de acoplamento, de coesão e de complexidade. As medidas escolhidas foram: i) Número de Linhas de Código (Lines of Code - LOC); ii) Falta de Coesão entre Métodos (Lack of Cohesion of Methods - LCOM); iii) Profundidade da Árvore de Herança (Depth of Inheriance Tree - DIT); iv) Complexidade Ciclomática (Cyclomatic Complexity - CC); e v) Métodos Ponderados por Classe (Weighted Methods per Class - WMC). As três primeiras medidas são de tamanho, coesão e acoplamento, respectivamente. As duas últimas são de complexidade. Essas medidas foram escolhidas por estarem presente em uma Revisão Sistemática da Literatura [Riaz et al., 2009] e estarem dentre as mais citadas Desenvolvimento da Linha de Produtos de Software em AspectJ Um diferencial do AspectJ em relação às demais linguagens de programação é o fato de não ser possível implementar programas utilizando somente AspectJ, sendo necessário utilizar a linguagem de programação Java. A priori, isso vem da ideia da Orientação a Aspectos, utilizada para customizar produtos desenvolvidos em Java, solucionando problemas da Orientação a Objetos. As dificuldades encontradas para a implementação da LPS em AspecJ foram entender como seriam os Pontos de Junção (join points) de cada aspecto referente a LPS e como poderia ser implementado os refinamentos que a LPS continha na versão em AHEAD. Durante a implementação, algumas conversões foram diretas, pois algumas características não precisavam de refinamentos. Assim, ao converter para AspectJ, não foi preciso preocupar-se com os pontos de junção. Outra questão importante a ser lembrada é a lógica da LPS legada não ter sido alterada Procedimentos de Medição Com a finalidade de deixar o código-fonte das LPSs mais parecidos e tornar a comparação entre as medidas mais realista, foi realizada normalização no código-fonte. Essa normalização seguiu os padrões de codificação Java, pois ambas as linguagens em estudo são baseadas em Java. Em seguida, foi realizado o processo de medição. Para coletar o valor das cinco medidas utilizando os plug-ins do Eclipse: i) VizzAnalyzer 1, para medir LOC, LCOM, DIT, e WMC; e ii) Code Pro Analytix 2, para medir CC. Na primeira coluna da Tabela 2, estão os componentes por ordem alfabética e o valor das medidas está nas colunas seguintes. Para facilitar a comparação, cada medida da LPS TankWar em AHEAD foi disposta ao lado da medida correspondente da LPS TankWar em AspectJ. Por exemplo, o componente Beschleunigung na primeira linha da Tabela 2 possui valores 70; 2,6; 17; 0 e 11 na LPS TankWar em AHEAD e 50; 2,66; 7; 0 e 6 na LPS TankWar em AspectJ para as medidas LOC, CC, LCOM, DIT e WMC, respectivamente

172 Tabela 2 - Medidas dos Componentes da LPS TankWar em AHEAD e da LPS TankWar em AspectJ Componente LOC1 LOC2 CC1 CC2 LCOM1 LCOM2 DIT1 DIT2 WMC1 WMC2 Beschleunigung Bombe ChinaType DE Easy einfrieren EN Energie explodieren , ExplodierenEffekt Feuerkraft fuerhandy fuerpc GameManager GameObject GermanyLeopard Handy Hard Image IMGtool InfoPanel KeyMonitor M M M Maler MalerZeit MapInfo Mars Menu MIDlet Missile NameChar NameTextField Note_Handy Note_PC Option PC Record Discussão Nesta seção, é apresentada uma comparação entre a LPS TankWar em AHEAD e a LPS TankWar em AspectJ. Para análise e discussão de qual LPS é melhor, a comparação foi feita utilizando a Média (M), Mediana (MD) e Desvio Padrão (DP). Na Tabela 3, são apresentados os valores de obtidos na medição. Por exemplo, na primeira linha, a medida LOC da LPS TankWar em AHEAD possui M = 97,236, MD = 68 e DP = 107,666. Pode-se observar que DP da medida LOC da LPS TankWar em AHEAD possui valor menor do que o da LPS TankWar em AspectJ, o que mostra variação maior existente na LPS TankWar em AspectJ, tal como pode ser observado na MD da LPS TankWar em AspectJ, o quão distante MD está distante da M. Para a medida CC, ocorre 172

173 o oposto, DP da LPS TankWar em AHEAD é maior do que o da LPS TankWar em AspectJ. Portanto, a variação em torno de M é maior na LPS TankWar em AHEAD. Tabela 3 - Análise das Medidas das Classes da LPS TankWar em AHEAD e da LPS TankWar em AspectJ Medida Média Mediana Desvio Padrão LOC1 97,236 68,0 107,666 LOC2 91,364 51,0 109,163 CC1 4,967 2,6 9,652 CC2 2,167 1,1 2,223 LCOM1 27,236 3,0 103,037 LCOM2 37,073 1,0 105,901 DIT1 0,109 0,0 0,312 DIT2 0,109 0,0 0,312 WMC1 15,582 11,0 22,583 WMC2 9,782 4,0 15,352 Em relação à medida LCOM, as diferenças entre DP da LPS TankWar em AHEAD e da LPS TankWar em AspectJ são pequenas com ~2,9 de diferença. A LPS TankWar em AspectJ possui maior variação, comprovada pela comparação entre M e MD, na qual possui maior diferença na LPS TankWar em AspectJ. Para as medidas DIT e CC, não há diferenças significativas entre os valores obtidos. A medida WMC apresenta a maior diferença entre seus DP, sendo que para LPS TankWar em AHEAD é o maior valor, mesmo com valores próximos para M e MD. No gráfico da Figura 1, pode-se observar visualmente o efeito dessas medidas. Figura 1 - Valores das Medidas da LPS TankWar em AHEAD e da LPS TankWar em AspectJ Os resultados obtidos com as medidas LOC, CC, LCOM, DIT e WMC possuem outros fatores que interferem na comparação das LPSs. Como ocorre na medida LOC, a peculiaridade é AspectJ necessitar de funções de Java. Assim, ocorre aumento na quantidade de linhas de códigos. As demais medidas não são afetadas. Os resultados obtidos sugerem que cada tecnologia possui pontos positivos e pontos negativos. AHEAD consegue pontos positivos em LOC e LCOM. Assim, quando se tem a quantidade de linhas de código e a coesão entre métodos, a LPS TankWar em AHEAD comportou-se melhor. 173

174 Em AspectJ, as medidas CC e WMC obtiveram melhores resultados, concluindo que a complexidade dos métodos em AspectJ são menores. A medida DIT não teve diferenças significativas neste estudo para mostrar qual LPS é melhor; esse fato é em decorrência da lógica das LPSs serem as mesmas. Portanto, considerando quanto menor os valores dessas medidas, mais manutenível é a LPS, a LPS TankWar em AspectJ obteve melhor resultado, comparando M e MD das medidas; apenas a medida LCOM possui valor maior, mas com diferença pequena. 5. Trabalhos Relacionados Como a avaliação da manutenibilidade de software é subjetiva e difícil de mensurar, vários trabalhos foram desenvolvidos para tentar facilitar o processo de medição e/ou minimizar a subjetividade. Dessa forma, quatro trabalhos relacionados foram escolhidos. No primeiro [Aldekoa et al., 2008], é realizada a medição da manutenibilidade de uma LPS orientada a características. O índice de manutenibilidade (IM) foi utilizado para medição da LPS MUKalk e da LPS Graph Product Line. Como procedimento, foi calculado o IM de cada produto das LPSs e, em seguida, foi extraída a influência de cada característica. No segundo [Ali et al., 2010], os autores realizaram uma Revisão Sistemática da Literatura (RSL) para encontrar trabalhos que fizeram comparações entre POA e não POA. Nessa RSL, foram encontrados trabalhos que utilizavam linguagens de programação como Java, C, C++, AspectJ, EjFlow, CaesarJ, AspectC++ e GLuonJ. A maioria dos estudos encontrados utilizaram Java/AspectJ. Para avaliação, foram considerados sete atributos/características de qualidade (performance, tamanho de código, modularidade, capacidade de evolução, cognição e mecanismo da linguagem e tratamento de exceção). Como resultado, a qualidade dos sistemas desenvolvidos com POA foi considerada elevada em relação aos desenvolvidos sem POA. No terceiro trabalho [Abílio et al., 2012], uma RSL sobre medidas contemporâneas relacionadas à manutenibilidade de sistemas de software desenvolvidos em tecnologias de POC e POA foi realizada. Os resultados sugerem a existência de um conjunto extenso de medidas relacionadas à orientação a aspectos (OA) e de um conjunto mais restrito à orientação a características (OC). No total de 111 medidas encontradas, 33 estão relacionadas a OC e 78 estão relacionadas a OA. Além disso, observando a não-uniformidade na utilização dos termos "aspectos" e "característica" na definição ou na utilização das medidas apresentadas, pode levar a confusão quanto a qual medida utilizar. No quarto trabalho [Gaia, 2013], foi feita uma avaliação quantitativa entre de LPSs desenvolvidas com POC, POA e POO utilizando a abordagem de Módulos de Características Aspectuais (MCA). Nesse estudo, foram calculadas medidas de estabilidade em propagação de mudanças, na qual é considerada a quantidade de inserções, de alterações e de remoções realizadas na LPS de estudo. Além disso, foram analisados diversos tipos de granularidade, como componentes, métodos e linhas de código-fonte. Os resultados obtidos revelam que a utilização de MCA e POC tendem a ser mais estáveis que outras abordagens; no entanto, POC não "lida bem" quando interesses transversais devem ser utilizados, sendo assim a utilização de MCA é uma melhor opção em relação a propagação de mudanças. 174

175 Este trabalho difere dos demais por realizar uma comparação entre tecnologias/linguagens utilizadas para implementar LPSs orientadas a aspectos e características e por não utilizar uma única medida ou determinar um valor absoluto para a manutenibilidade das LPSs. Além disso, é considerada a abrangência das medidas que, apesar de ser uma quantidade limitada, englobam atributos de tamanho, de acoplamento, de coesão e de complexidade, mostrando um comparativo de qual tecnologia/linguagem destaca-se nesses atributos. 6. Considerações Finais Ao comparar duas LPSs desenvolvidas com tecnologias diferentes, Programação Orientada a Características (AHEAD) e Programação Orientada a Aspectos (AspectJ), observa-se que cada uma possui pontos positivos e pontos negativos. Neste estudo, AspectJ destacou-se, obtendo melhores medidas (valores menores) com relação as medidas analisadas (LOC, CC, LCOM, DIT e WMC). Nesse caso, a LPS TankWar em AspectJ apresenta indícios que tenha maior manutenibilidade do que a LPS TankWar em AHEAD. As contribuições deste trabalho são mostrar qual tecnologia a ser utilizada para implementar uma LPS e o conjunto de medidas que abrangem tamanho, acoplamento, coesão e complexidade ajudam a identificar qual linguagem é mais indicada em cada um desses atributos. Algumas limitações encontradas foram o estudo de caso único, a dificuldade para conclusões genéricas a respeito da manutenibilidade da LPS, a escolha das medidas utilizadas pode não ser as mais indicadas para definir se uma LPS é manutenível e a não existência de ferramentas computacionais específicas para medir LPSs desenvolvidas com AspectJ e AHEAD. Como trabalhos futuros, pretende-se repetir o estudo com outras linguagens e/ou tecnologias de programação, realizar o estudo com mais de uma LPS, verificar se os resultados são replicáveis para outros domínios e ampliar o conjunto de medidas utilizadas para medir a manutenibilidade de LPS. Referências Aldekoa, G.; Trujillo, S.; Sagardui, G.; Diaz, O. (2008) Quantifying Maintainability in Feature Oriented Product Lines. In: European Conference on Software Maintenance and Reengineering, pp Ali, M.; Babar, M. A.; Chen, L.; Stol, K.-J. (2010) A Systematic Review of Comparative Evidence of Aspect-Oriented Programming. In: Journal Information and Software Technology, v.52, n.9, pp Apel, S.; Beyer, D. (2011) Feature Cohesion in Software Product Lines: An Exploratory Study. In: International Conference on Software Engineering, pp Batory, D. (2003) A Tutorial on Feature Oriented Programming and Product-Lines. In: International Conference on Software Engineering. p

176 Boucher, Q.; Classen, A.; Faber, P.; Heymans, P. (2010) Introducing TVL, a Text-Based Feature Modelling Language. In: International Workshop on Variability Modelling of Software-intensive Systems. pp Gaia, F. N. Uma Avaliação Quantitativa de Módulos de características Aspectuais para Evolução de Linhas de Produtos de Software. Dissertação de Mestrado Faculdade de Computção da Universidade Federal de Uberlândia ISO/IEC (2005) Software Engineering - Software Product Quality requirements and Evaluation (SQuaRE) - Guide to SQuaRE, p. 35. Junior, C. A. de F. P. (2008) Geração de Aplicações para Linhas de Produtos Orientadas a Aspectos com Apoio da Ferramenta Captor-AO. Dissertação de Mestrado em Ciências de Computação e Matemática Computacional - Instituto de Ciências Matemáticas e de Computação, Universidade de São Paulo, 120p. Kiczales, G.; Hilsdale, E.; Hugunin, J.; Kersten, M.; Palm, J.; Griswold, W. G. (2001) An Overview of Aspect. In: European Conference on Object-Oriented Programming. pp Kiczales, G.; Lamping, J.; Mendhekar, A.; Maeda, C.; Lopes, C.; Loingtier, J. M.; Irwin, J. (1997) Aspect-Oriented Programming. In: ECOOP. pp Northrop, L. (2002) Sei s Software Product Line Tenets. In: IEEE Software, v. 19, n. 4, pp Pereira, R. R. (2012) Uma Abordagem para Desenvolvimento de Linhas de Produtos de Software Orientada a Características e Dirigida por Modelos. Dissertação de Mestrado - Faculdade de Computação, Universidade Federal de Uberlândia, 125p. Riaz, M.; Mendes, E.; Tempero, E. (2009) A Systematic Review of Software Maintainability Prediction and Metrics. In: International Symposium Empirical Software Engineering and Measurement, p Schulze, S.; Apel, S.; Kastner, C. (2010) Code Clones in Feature-Oriented Software Product Lines. In: International Conference on Generative Programming, pp Schulze, S.; Thüm, T.; Kuhlemann, M.; Saake, G. (2012) Variant-Preserving Refactoring in Feature-Oriented Software Product Lines. In: Workshop on Variability Modeling of Software-Intensive Systems, pp Vale, G. A. (2013) Avaliação da Manutenibilidade de Sistemas de Software Derivados de Linhas de Produto de Software. Monografia de Graduação em Sistemas de Informação, Universidade Federal de Lavras, 79p. 176

177 Um Software Educacional para Manutenção de Software Matheus Carvalho, Heitor Costa Departamento de Ciência da Computação - Universidade Federal de Lavras Caixa Postal CEP Lavras - MG - Brasil scott.matheus@computacao.ufla.br, heitor@dcc.ufla.br Abstract. Nowadays, there are alternatives to improve teaching-learning process in various fields of study. Although these alternatives is important advancement, Software Engineering still presents deficit in number of options available to assist students who want to acquire knowledge about this area. This work presents MaintES (Maintenance Educational Software), computational 3D educational software that seeks to involve students an challenger and interactive environment related to Software Maintenance. MaintES attempts to contribute to learning on Maintenance Software. Resumo. Atualmente, há alternativas para melhorar o processo de ensinoaprendizagem em várias áreas de estudo. Embora isso seja um importante avanço, a Engenharia de Software ainda apresenta déficit na quantidade de opções disponíveis para auxiliar os estudantes que procuram adquirir conhecimento. Com isso, esse trabalho apresenta o MaintES (Maintenance Educational Software), um software educacional computacional 3D para envolver o estudante em um ambiente interativo e estimulador, repleto de desafios relacionados à Manutenção de Software. O MaintES busca contribuir para melhor aprendizagem do conteúdo de Manutenção de Software. Aluno: Matheus Moreira de Carvalho Orientador: Heitor Augustus Xavier Costa Categoria: Trabalho de Conclusão de Curso de Graduação Estágio do Trabalho: Em Desenvolvimento 1. Introdução Na sociedade atual, cada vez mais empresas desenvolvedoras de software exigem que profissionais tenham formação qualificada, melhorando, evoluindo e aperfeiçoando sua capacitação profissional. Uma das preocupações das Instituições de Ensino Superior é formar profissionais capacitados e aptos para a realização de suas funções. Em muitas dessas instituições, são utilizadas amplamente aulas expositivas. Um fator negativo nessas aulas é estar ativo apenas o sentido da visão e da audição. Uma alternativa é o uso de eventos simulados e atividades vivenciadas, que permitem assimilar diversas 177

178 situações de forma prática e interativa. O envolvimento de um indivíduo com determinada atividade prática resulta em melhores resultados, pois ele torna-se responsável por tomadas de decisões, de ações, de escolhas e de rumo que a atividade seguirá [Prikladnicki et al., 2009]. Na Engenharia de Software não é diferente. Prender a atenção do aluno e proporcionar vontade de aprender tendem a ser maneiras eficazes de aprimorar o processo de ensino-aprendizagem. Em confronto a essa ideia, há as massivas aulas teóricas em que expressiva quantidade de informações é passada aos alunos de forma exclusivamente expositiva, sem aplicação prática, o que causa aos alunos desmotivação e dificuldade na fixação do conteúdo apresentado. Com isso, o processo de ensinoaprendizagem na área Engenharia de Software, em especial o assunto Manutenção de Software, sofre por utilizar esses padrões tradicionais de ensino. Dessa forma, uma alternativa é a utilização de jogos computacionais voltados para a educação, uma vez que se apresentam com o objetivo de auxiliar na aprendizagem dos discentes, utilizando fundamentos como regras, metas/objetivos, estratégias e competição. A realização deste trabalho foi motivada pelo fato da transferência do conhecimento do assunto Manutenção de Software ter se dado por ministração de aulas expositivas. Essas aulas são cansativas para alunos e para professores e podem não promover total aprendizado do conteúdo. Isso pode ser creditado a muitos fatores, um deles é a apresentação vários métodos, técnicas, processos, tecnologias, metodologias, paradigmas, procedimentos, entre outros conceitos sem aplicações práticas, o que dificulta sua fixação. Portanto, o processo de ensino-aprendizagem precisa ter alternativas válidas, visto a importância dos profissionais terem conhecimento e experiência necessários para realizar suas funções e não ficar limitado apenas às aulas exclusivamente expositivas e teóricas. Com isso, neste trabalho, o objetivo é apresentar uma proposta de software educacional (jogo) dedicado ao apoio do processo de ensino-aprendizagem sobre Manutenção de Software, cuja missão é reduzir impactos negativos trazidos pelas formas tradicionais de ensino. Espera-se que esse software possa auxiliar os estudantes a assimilar, consolidar e fixar informações pertinentes ao assunto abordado. O restante do artigo está organizado da seguinte forma. A importância de utilizar jogos educacionais na educação e a importância da manutenção de software é apresentada brevemente na Seção 2. O software educacional MaintES é apresentado na Seção 3. Alguns trabalhos relacionados estão resumidamente descritos na Seção 4. Conclusão e sugestões de trabalhos futuros são apresentadas na Seção Fundamentação Teórica 2.1. Jogos Educacionais Com a crescente exigência do mercado por profissionais capacitados e preparados, há preocupação sobre os métodos e as técnicas utilizados no processo de ensinoaprendizagem para garantir a excelência desses profissionais. Em razão disso, a utilização de jogos na educação mostra-se interessante e promissora, uma vez que possuem potencial para auxiliar os processos de aprendizagem [Silva, 2008]. 178

179 Com a utilização de jogos educativos em ambientes escolares, os professores podem estimular seus alunos a aprenderem o conteúdo. Isso auxilia, otimiza e aperfeiçoa o trabalho do professor para transmitir o conteúdo, pois, uma vez que os alunos estão em contato com o objeto de estudo, o professor pode dedicar-se a tirar dúvidas individualmente. Por outro lado, a dinâmica do jogo proporciona aos estudantes a compreensão de regras, fixação do objeto de estudo e, inclusive, o desenvolvimento de habilidades e aspectos sociais entre os alunos [Feitosa; Campos, 2010]. O uso de jogos como ferramenta de apoio ao processo de ensino-aprendizagem apresenta vantagens, tais como, concentração, cooperação, motivação, competição e interação [Borges, 2005]. A utilização desses jogos na educação, principalmente aqueles que proporcionam aos jogadores a simulação de situações e ambientes, tem gerado resultados positivos em termos de motivação e de concentração dos estudantes, mesmo quando empregado em diversas áreas de conhecimento [Catapan et al., 1999]. Os jogos computacionais educacionais são excelentes ferramentas para instruir os alunos, a ideia de motivar enquanto se diverte é uma combinação interessante para estimulá-los e aumentar sua capacidade de retenção do que foi ensinado, pois esses jogos passam a exercitar mais funções cognitivas e intelectuais do jogador [Tarouco et al., 2004]. O avanço e o desenvolvimento contínuo de novas tecnologias ajudam na criação e na disponibilização de novas alternativas que apoiem a educação e o ensino. Desse modo, os jogos educacionais fazem parte dessas novas alternativas disponíveis e podem colaborar significativamente na educação. As características que os jogos proporcionam aos jogadores despertam a motivação Manutenção de Software Para iniciar o desenvolvimento de um software, é necessário realizar o levantamento de requisitos. Porém, isso inclui a necessidade de realizar manutenções para garantir que o software continue funcional e eficiente por mais tempo [Silva et al., 2010]. A concepção, a seleção e a adaptação de processos em paralelo com as ferramentas e os métodos, visando à qualidade do software, contribuem para que os projetos e os processos de manutenção sejam bem sucedidos, pois permite a utilização metódica das práticas de Engenharia de Software [Pressman, 2009]. Manutenção de Software é definida como um conjunto de atividades para o provimento de suporte a um sistema de software, minimizando esforços e custos. As atividades são executadas antes, na forma de planejamento, e após o software ser entregue ao cliente, na forma de correção de erros, adição de novas funções ou realização de adaptações [Pigoski, 1996]. As atividades de manutenção de software estão relacionadas ao processo de mudança de um software após ter sido entregue ao cliente. Tais mudanças incluem correção de defeitos, melhoria de desempenho ou adaptação para novos ambientes e/ou novas necessidades [Pressman, 2009]. 3. MaintES - Maintenance Educational Software 3.1. Especificações No MaintES, o jogador assume o papel de estudante que busca vencer torneios de perguntas, em três diferentes níveis, relacionadas à Manutenção de Software. O estudante inicia o jogo no nível Iniciante, sem pontos e pequena quantidade de 179

180 dinheiro. Com isso, ele pode testar seu conhecimento, respondendo perguntas referentes às matérias do seu nível, para ganhar dinheiro e aumentar sua pontuação. Dessa forma, quando determinada quantia de pontos for alcançada e o jogador possuir dinheiro suficiente para pagar a sua inscrição no torneio, ele poderá participar de um torneio. Por outro lado, o dinheiro acumulado pode ser utilizado na contratação de membros para sua equipe. A equipe é importante, pois o estudante pode utilizar esses membros para eliminar alternativas falsas das perguntas dos torneios, facilitando a conquista. Assim, a evolução de nível acontece quando o jogador tenha conquistado o torneio de seu nível atual e apresente a pontuação requerida para o nível seguinte. O sucesso no jogo acontece quando o jogador vence os três torneios e acumula pontuação suficiente para alcançar o nível Master Funcionamento O MaintES é um jogo computacional educacional, em que um jogador assume o papel de um estudante de Engenharia de Software que busca melhorar seu nível de conhecimento sobre o assunto Manutenção de Software. Com isso, o conhecimento do estudante é testado com torneios de perguntas, em que o jogador deve responder a todas as perguntas sem errar para ter sucesso. O MaintES é composto por dois módulo: Módulo Administrador. Esse módulo permite que os administradores alterem dados dos jogadores e de outros administradores, bem como realizem manutenção nas perguntas e nas configurações gerais do MaintES; Módulo Jogador. Esse módulo permite que os jogadores façam alteração em seus dados cadastrais, acessem o rank e a ajuda. Ainda, permite que joguem, estudando, respondendo perguntas e contratando membros para sua equipe Módulo Administrador Para acessar o MaintES como Administrador, deve-se preencher os campos Login e Senha e selecionar a opção Administrador para efetuar a autenticação (Figura 1). Em seguida, a tela principal de administrador é mostrada, contendo as ações possíveis de um Administrador: i) Gerenciar Jogadores; ii) Gerenciar Administradores; iii) Gerenciar Perguntas; iv) Configurações; e v) Sair. Nas opções Gerenciar Jogadores e Gerenciar Administradores, há as ações básicas de manutenção de cadastro. Na opção Gerenciar Perguntas (Figura 2), o Administrador realiza as ações básicas de manutenção de cadastro escolhendo nível (Iniciante, Amador ou Profissional) do treinamento e do torneio. Para o correto cadastramento de perguntas, o administrador precisa preencher o campo Pergunta, os campos referentes a cada alternativa e selecionar a alternativa correta. É importante lembrar que, ao inserir/modificar uma pergunta, os campos não podem estar vazio. Na opção Configurações, é apresentada uma tela com informações sobre Configurações Gerais, do Treinamento e do Torneio (Figura 3). Caso o jogador selecione a aba Configurações Gerais, ele pode modificar as faixas de níveis, alterando os pontos de cada nível. Além disso, ele pode modificar o custo de contração de membros da equipe e alterar a porcentagem do valor recebido pelo jogador, caso demita algum membro de sua equipe. Após as alterações, o Administrador pode salvá-las ou retornar ao padrão de valores sugerido pelo jogo. 180

181 Figura 1 - Tela de Autenticação Figura 2 - Gerenciamento das Perguntas no MaintES Na aba Treinamento, o Administrador é capaz de realizar modificações nos valores ganhos e perdidos de dinheiro e de pontos dos três níveis. Na aba Torneio, o Administrador consegue alterar os pontos requeridos e o valor da inscrição dos níveis dos torneios e o total de perguntas de cada torneio. Além disso, ele pode modificar a porcentagem de pontos que o jogador perde ao errar uma pergunta e definir a probabilidade de ser sorteada uma pergunta do nível Iniciante ou Amador em um Torneio Amador. Analogamente, ele pode definir a probabilidade de ser sorteada uma pergunta do nível Iniciante, Amador ou Profissional em um Torneio Profissional. 181

182 Módulo Jogador Figura 3 - Configurações dos Torneios do MaintES Para poder jogar o MaintES, o Jogador precisa realizar sua autenticação, fornecendo seu login e senha, previamente cadastrados pelo Administrador (Figura 1). Assim, o Jogador é direcionado para a tela apropriada para escolher: i) Jogar; ii) Regras; iii) Atualizar Dados; iv) Rank; e v) Sair. Caso ele opte Jogar, é direcionado para o cenário do jogo onde ocorrem as ações do jogo (Figura 4). Para consultar as regras e esclarecer dúvidas, o Jogador deve escolher Regras. Para modificar dados cadastrais, o Jogador deve escolher Atualizar Dados. O Jogador pode escolher Rank para consultar as 5 maiores pontuações no MaintES. Ao iniciar o jogo, o Jogador é livre para escolher: i) Estudar; ii) Participar do Treinamento; iii) Participar do Torneio; iv) Verificar suas Conquistas; v) Salvar; vi) Gerenciar sua Equipe; e vii) Consultar a Ajuda do MaintES. No canto superior esquerdo, há informações de (i) nome do jogador, (ii) nível atual, (iii) quantidade de dinheiro e (iv) chance que o jogador possui de concluir o torneio com sucesso. Ao escolher Estudar, o Jogador é "levado" até a Prateleira de Livros, sendo direcionado para a tela de estudos, em que tem acesso a textos resumos de cada nível. O Jogador pode (re)ler um resumo, sempre que julgar necessário. É importante lembrar que, quanto mais preparado ele estiver para enfrentar o Treinamento e os desafios dos Torneios, menos pontos ele perde; consequentemente, melhor é seu desempenho. Ao escolher Treinamento (Figura 5), o Jogador é desafiado a responder perguntas pertencentes ao seu nível. Ele responde as perguntas, selecionando a alternativa que julgar correta. Caso acerte, ele recebe pontos e dinheiro; caso contrário, ele perde pontos e dinheiro. Em ambas as situações, a quantidade de pontos e de dinheiro é definida pelo Administrador. Ao escolher Treinamento, o Jogador deve ir até a Mesa de Estudos. 182

183 Figura 4 - Início do Jogo e Ambiente Principal Figura 5 - Treinamento Nível Iniciante O Jogador pode consultar suas conquistas. As conquistas são metas prédeterminadas que servem de incentivo. Quando o Jogador alcança uma meta, ele recebe uma recompensa na forma de pontos e de dinheiro (Tabela 1). Uma meta pode ser alcançada apenas uma vez, com exceção dos Torneios. O acesso às conquistas é feito quando o Jogador é levado até a prateleira de Troféus. Um dos recursos que o jogador dispõe para auxiliá-lo durante os Torneios é a Equipe (Figura 6) composta por três tipos de membros: i) Aprendiz; ii) Técnico; e iii) Gerente. A Equipe pode possuir vários membros de cada tipo, em que cada um pode ser "utilizado" apenas uma vez. Cada membro pode eliminar alternativas falsas: i) Aprendiz: Elimina uma alternativa falsa; ii) Técnico: Elimina duas alternativas falsas; e iii) Gerente: Elimina três alternativas falsas. 183

184 Ao escolher a opção Equipe, o Jogador é direcionado para a tela de gerenciamento da Equipe, na qual ele pode contratar e/ou demitir membros. Os preços de contratação de cada membro são por padrão: i) Aprendiz: 250 reais; ii) Técnico: 500 reais; e iii) Gerente: 750 reais. Ao demitir um membro, uma porcentagem do valor gasto na contratação desse empregado é reembolsada. Tabela 1 - Recompensas por Alcançar uma Meta Reais Recompensas Pontos Recompensas Acertos Recompensas 200 reais 5 pontos e 10 reais 50 pontos 5 pontos e 10 reais 5 acertos 5 pontos e 10 reais 400 reais 8 pontos e 15 reais 100 pontos 10 pontos e 20 reais 10 acertos 10 pontos e 20 reais 600 reais 15 pontos e 25 reais 250 pontos 20 pontos e 40 reais 20 acertos 20 pontos e 40 reais 800 reais 25 pontos e 40 reais 500 pontos 50 pontos e 80 reais 50 acertos 40 pontos e 80 reais reais 25 pontos e 40 reais 750 pontos 80 pontos e 160 reais reais 80 pontos e 150 reais pontos 160 pontos e 320 reais reais 150 pontos e 200 reais pontos 320 pontos e 640 reais Figura 6 - Torneio Nível Iniciante e Janela da Equipe O principal objetivo desse jogo é alcançar o nível Master. Para isso, o Jogador precisa alcançar pontos, que pode ser alterado pelo Administrador e vencer os Torneios nos três níveis de dificuldade. Para poder participar de um Torneio, o Jogador precisa possuir determinada quantidade pontos e possuir dinheiro suficiente para pagar a inscrição. Os requisitos são: i) Torneio Nível Iniciante: 100 pontos - Valor da Inscrição: 100 reais; ii) Torneio Nível Amador: 200 pontos - Valor da Inscrição: 200 reais; e iii) Torneio Nível Profissional: 500 pontos - Valor da Inscrição: 500 reais. Para vencer um torneio, o Jogador deve responder as perguntas sem errar. Para isso, ele conta com a ajuda dos membros de sua Equipe, que eliminam alternativas falsas. Ao vencer um Torneio, o Jogador recebe prêmio e a conquista correspondente ao nível disputado. Os prêmios são: i) Nível Iniciante: 80 pontos, 200 reais e troféu; ii) Nível Amador: 200 pontos, 500 reais e troféu; iii) Nível Profissional: 400 pontos,

185 reais e troféu. Caso o Jogador erre uma pergunta, ele é eliminado e perde uma porcentagem de seus pontos: i) 20% do Torneio Nível Iniciante; ii) 30% do Torneio Nível Amador; e iii) 40% do Torneio Nível Profissional. A entrada do Torneio acontece quando o jogador é levado até a Mesa de Computador. Para auxiliar o Jogador, o MaintES possui uma tela de ajuda com as regras e as informações sobre os componentes do jogo. Assim, ele pode consultá-la quando precisar tirar alguma dúvida e/ou obter informações sobre o MaintES. O acesso a essa tela pode ser: i) no painel principal do jogador; ii) no menu principal do jogador; iii) na entrada do Treinamento; e iv) na entrada do Torneio. O fim do jogo acontece quando o Jogador vencer o jogo (ao alcançar o Nível Master) ou perder o jogo (caso fique com 0 pontos e dinheiro negativo). 4. Trabalhos Relacionados Nesta seção, são apresentados dois trabalhos relacionados escolhidos por assimilaremse ao tema abordado. Eles abordam Jogos Computacionais na área Engenharia de Software e apoiam o processo de ensino-aprendizagem. SPARSE (Software Project semi-automated Tool for Software Engineering) [Souza et al., 2010] é um jogo de simulação baseado em regras em que o jogador é capaz de interagir com vários ambientes relacionados à Engenharia de Software. As atividades enfrentadas pelos jogadores são: i) modelo de processo; ii) projeto de software; iii) gerente de projetos; iv) desenvolvedores; e v) ferramentas. As suas regras foram criadas baseadas no conjunto de boas práticas da Engenharia de Software. Durante o jogo, há eventos disparados aleatoriamente, em que o jogador depara-se com situações novas e desafiadoras. O objetivo é completar o desenvolvimento do projeto, preservando prazos e custos definidos com o cliente, atentando à qualidade do software. No jogo SimSE [Navarro; Hoek, 2009], o objetivo é complementar a aprendizagem de alunos de Engenharia de Software. É um jogo educativo de simulação de processos de Engenharia de Software, em que o jogador tem a oportunidade de exercer o papel de gerente de projetos. A função do jogador é delegar atividades aos integrantes da equipe, monitorar os processos, utilizar as ferramentas disponíveis, contratar e demitir pessoal e seguir prazos. Ao decorrer do jogo, o jogador deve tomar decisões, as quais irão influenciar positiva ou negativamente no resultado final do projeto. Por fim, o jogador recebe pontuação e o desempenho final obtido no jogo. O jogo MaintES se difere desses trabalhos pois, além de ser um jogo educacional computacional, envolve conhecimentos sobre a área de Manutenção de Software e simula um ambiente doméstico em que um estudante busca aprimorar seus conhecimentos. Dessa forma, o conhecimento do jogador é testado por meio de desafios, como responder perguntas dos Treinamentos e enfrentar Torneios de Perguntas. O jogador evolui de nível e aumenta sua pontuação até alcançar o nível Master e concluir o jogo com sucesso. 5. Considerações Finais Percebe-se que o uso de jogos computacionais educativos no ambiente escolar é promissor, visto as deficiências e as dificuldades encontradas nas técnicas de ensino 185

186 tradicionais e os benefícios advindos do uso desses softwares na educação. Dessa forma, o software educativo MaintES pode ser um importante reforço para a transmissão do conhecimento no assunto Manutenção do Software. O MaintES tenta sanar fraquezas encontradas nos métodos tradicionais do processo ensino-aprendizagem e serve como alternativa para estudantes que buscam aprimorar seus conhecimentos. Como trabalhos futuros, sugere-se o aperfeiçoamento do MaintES com a implementação de novas funções como novos recursos, desafios e premiações. Além disso, é importante evoluir o MaintES para uma versão multiplayer que servirá de apoio a jogadores desenvolverem habilidades de trabalho em equipe. Referências Borges, C. J. O Lúdico nas Interfaces das Relações Educativas. In: Revista de Pedagogia, v Catapan, A. H.; Plínio, C. F.; Souza, A. C.; Thomé, Z. R. C.; Cybis, W. D. A. Ergonomia em Software Educacional: A Possível Integração entre Usabilidade e Aprendizagem. In: Workshop sobre Fatores Humanos em Sistemas Computacionais Feitosa, A. C.; Campos, G. M. M. AprendES: Um Jogo Educacional para Auxiliar o Processo de Ensino-Aprendizagem da Engenharia de Software. In: Simpósio Brasileiro de Informática na Educação Navarro, E.; Hoek, A. Multi-Site Evaluation of SimSE. In: Technical Symposium on Computer Science Education. pp Pigoski, T. M. Practical Software Maintenance: Best Practices for Managing Your Software Investment. John Wiley. 384p Pressman, R. S. Software Engineering: A Practitioner's Approach. McGraw-Hill. 928p Prikladnicki, R.; Albuquerque, A. B.; Wangenheim, C. G.; Cabral, R. Ensino de Engenharia de Software: Desafios, Estratégias de Ensino e Lições Aprendidas. In: Fórum de Educação em Engenharia de Software Silva, G. M. O Uso do Computador na Educação, Aliada a Softwares Educativos no Auxílio ao Ensino e Aprendizagem Disponível em: < Acessado em 19/11/2013. Silva, R. A.; Matos, S. N.; Souza, J. U. F.; Moura, L. F. A Manutenção de Software nas Empresas. In: Congresso Internacional de Administração Souza, M. M.; Resende, R. F.; Prado, L. S.; Fonseca, E. F.; Carvalho, F. A.; Rodrigues, A. D. SPARSE: Um Ambiente de Ensino e Aprendizagem de Engenharia de Software Baseado em Jogos e Simulação. In: Simpósio Brasileiro de Informática na Educação Tarouco, L. M. R.; Roland, L. C.; Fabre, M. J. M.; Konrath, M. L. P. Jogos Educacionais. In: RENOTE - Novas Tecnologias na Educação, v. 2, n

187 Análise das Estratégias de Gamificação em Aplicativos Móveis Educacionais: Um Estudo de Caso do Aplicativo Duolingo Júlio César Rosa da Silva, Glivia Angélica Rodrigues Barbosa Instituto de Ciências Exatas e Informática Pontifícia Universidade Católica de Minas Gerais (PUC Minas) Belo Horizonte MG Brasil si.juliocesar@gmail.com, gliviaangelica@gmail.com Abstract. In the current days a new generation of learners is presented, where the media and digital technologies has great influence in performing their tasks. From this phenomenon new strategies are being explored in order to meet the needs of this new audience. Among them, gamification appears which has contributed considerably for area of education. In this sense this work is to analyze the strategies of gamification in Duolingo application of qualitative way through Semiotic Inspection Method (SIM). Subsequently, a questionnaire with users of the application will be applied to check whether they feel motivated in its use. The results that will be obtained will observe whether the strategies used by the designer of the interface are indeed appropriate in relation to the proposed Duolingo aimed at teaching languages. Resumo. Nos dias atuais uma nova geração de aprendizes se apresenta, onde as mídias e tecnologias digitais tem grande influência na realização de suas tarefas. A partir desse fenômeno novas estratégias estão sendo exploradas a fim de atender as necessidades desse novo público. Dentre elas aparece a gamificação que tem colaborado consideravelmente para a área da educação. Neste sentido este trabalho busca analisar as estratégias de gamificação no aplicativo Duolingo de forma qualitativa através do Método de Inspeção Semiótica (MIS). Posteriormente, será aplicado um questionário aos usuários da aplicação para verificar se eles se sentem motivados no uso da mesma. Os resultados que serão obtidos permitirão observar se as estratégias utilizadas pelo projetista da interface são de fato adequadas em relação à proposta do Duolingo que visa o ensino de idiomas. Aluno: Júlio César R. da Silva Orientador: Glivia Angélica R. Barbosa Categoria: Trabalho de Conclusão de Curso de Graduação Estágio do Trabalho: Em Desenvolvimento 1. Introdução A utilização de aplicativos móveis no contexto educacional vem crescendo e junto com esse crescimento surgem desafios de como motivar o usuário ao uso contínuo dessas aplicações contribuindo para seu aprendizado. O uso de técnicas de gamificação nestes aplicativos pode ajudar no envolvimento do aluno com o conteúdo estudado, e com isso, colaborar para o sucesso da aplicação [Kapp, 2012]. 187

188 A Gamificação se define na utilização dos princípios de design de jogos, como interação e colaboração, a um contexto que não trata especificamente de um jogo. Segundo [Zichermann; Cunningham, 2011] a gamificação consiste em aplicar a forma de pensar e as mecânicas de jogos a fim de envolver os usuários e resolver problemas. Segundo [Prensky, 2011] os estudantes de hoje não são mais as pessoas para as quais nosso sistema educacional foi desenvolvido para ensinar. Eles passaram grande parte de suas vidas cercados e usando computadores, videogames, music players, câmeras digitais, celulares e outros brinquedos e ferramentas da era digital. Sendo assim, a gamificação encontra na educação uma área que necessita de novas estratégias para motivar indivíduos que estão cada vez mais inseridos no contexto das tecnologias digitais e se mostram desinteressados pelos métodos de ensino e aprendizagem tradicionais utilizados na maioria das instituições de ensino. Motivados por esse cenário, o objetivo desse trabalho consiste em identificar as estratégias de gamificação que têm sido adotadas em aplicativos móveis educacionais. Para isso será apresentado um estudo de caso no aplicativo Duolingo classificado como o melhor aplicativo móvel pela Apple e Google Play no ano de 2013 [Itunes e Google Play, 2013] Por ter sido bem avaliado pelos dois maiores repositórios de aplicativos existentes atualmente, buscamos verificar se o uso de recursos de gamificação pode ter contribuído de forma significativa para o sucesso do aplicativo. A metodologia adotada para realização do trabalho é de caráter qualitativo e consiste em aplicar o Método de Inspeção Semiótica (MIS) para identificar e apresentar as estratégias de gamificação propostas pelo projetista de interface da aplicação. Posteriormente essas estratégias serão comparadas com diretrizes de gamificação disponíveis na literatura a fim de verificar o grau de adequação da proposta do projetista do Duolingo. É importante esclarecer que não será avaliada a eficácia do aplicativo em termos de aprendizagem, mas sim as técnicas de gamificação comunicadas por sua interface para motivação ao uso continuo da aplicação. Este trabalho está organizado da seguinte forma, a seguir apresentamos o referencial teórico, na sequência descrevemos alguns trabalhos relacionados com o tema abordado. Na seção seguinte será explicada a metodologia utilizada e por fim, são descritos os resultados esperados e contribuições da pesquisa. 2. Referencial teórico Nesta seção serão apresentados os principais conceitos relacionados ao trabalho. Será apresentado a concepção do termo gamificação e a relação do seu uso na educação. Em seguida será fornecida uma descrição geral do aplicativo Duolingo que é nosso objeto de estudo, e por fim, será citada a importância da avaliação de interfaces bem como a definição em linhas gerais do Método de Inspeção Semiótica que será utilizado para alcançar o objetivo do trabalho Softwares/Aplicativos Educacionais Ambientes educacionais têm por objetivo apoiar o ensino e aprendizado de um conteúdo. Os sistemas podem se destinar a oferecer material instrucional àqueles que estão fisicamente remotos ou ainda complementar o ensino sendo feito em sala de aula. [Prates e Barbosa, 2003] 188

189 De acordo com [Costa e Oliveira, 2004] software educacional é um tipo de programa desenvolvido especialmente para atividades de ensino, com o objetivo principal de permitir que alunos desenvolvam a aprendizagem de determinado conteúdo. Segundo [Jucá, 2004] a qualidade de um software educativo está relacionada com a capacidade com que este mesmo software, como mediador didático, tem de obter satisfação e êxito dos usuários na aprendizagem de um conteúdo ou habilidade. Cada Software oferece uma maneira de contribuir com o processo educacional, alguns priorizando a memorização, onde esta se faz necessária; outros favorecendo desafios, testes, análise de dados, levantamento de hipóteses, não exigindo muito a intervenção do professor. O que confere a um software o caráter educacional é a sua aplicação no processo de ensino-aprendizagem, sendo assim um software pode ser considerado educacional quando é corretamente utilizado em uma relação de ensinoaprendizagem. [Fialho e Matos, 2010]. As tecnologias da comunicação e da informação estão cada dia mais inseridas em nosso cotidiano e aos poucos vêm sendo inseridas no domínio educacional. Através de tecnologias associadas é possível potencializar o processo de ensino-aprendizagem. [Fialho e Matos, 2010]. Embora os artefatos tecnológicos providos nos softwares educacionais sejam de grande relevância e promovam contribuições já comprovadas no processo de ensino [Ribeiro, Mendonça Gilda e Mendonça Alzino, 2007], [Ribeiro, 2008], ainda existem possibilidades de agregação de novos recursos visando potencializar a motivação dos usuários para uso contínuo desses softwares. Dentre eles destaca-se neste estudo o uso de técnicas de gamificação Gamificação A gamificação ainda não possui um conceito definitivo e exato, mas vem sido compreendida por teóricos e desenvolvedores como a aplicação de mecanismos de jogos no contexto fora do jogo. Tais mecanismos podem facilitar a solução de problemas originalmente tidos como entediantes de uma forma mais prazerosa, com participação de usuários mais engajados e motivados[navarro, 2013]. A ideia da gamificação é atender algumas das necessidades básicas dos usuários não alcançadas ao longo de tarefas cotidianas. Ao agregar elementos de jogos nas mais diversas áreas supre-se a busca por feedback, reconhecimento, status e de se fazer parte de algo coletivo [Zichermann e Cunningham, 2012]. Observando bem, a ideia de gamificação está presente em nosso cotidiano há mais tempo do que se imagina. Basta tomar como exemplo os programas de fidelidade das companhias aéreas ou cartões de crédito, que passam a ideia de um jogo onde o objetivo é acumular pontos para alcançar realizações, que podem ser recompensadas com prêmios ou mudança de status com relação aos demais participantes [Vianna Ysmar, Vianna Maurício, Medina e Tanaka, 2013]. A gamificação se apresenta em constante crescimento com muitas potencialidades de aplicação em diversas áreas como saúde, educação e negócios. Esse fenômeno se dá pelo fato da linguagem e metodologia dos games serem bastantes populares e aceitas naturalmente pelas atuais gerações que cresceram em meio a essa era digital [Fardo, 2013]. 189

190 Atualmente, a gamificação encontra na educação uma área bastante fértil para a sua aplicação, pois lá ela encontra indivíduos que carregam consigo muitas experiências adquiridas das interações com os jogos. É importante entender que a gamificação não consiste na criação ou utilização de jogos com fins educativos, mas na utilização de elementos de jogos tais como recompensas, medalhas e níveis, em um contexto que não é de jogo com o objetivo de envolver e motivar o usuário; no caso desta investigação, o aluno [Pimenta e Starling, 2013]. Portanto, se a gamificação é a aplicação de dinâmicas de jogos fora do domínio do jogo e seu objetivo é motivar e influenciar o comportamento de pessoas, torna-se totalmente relevante sua aplicação na área da educação. De acordo com [FREIRE, 1996, p. 25] ensinar não é apenas transferir conhecimento, mas criar possibilidades para a sua produção ou a sua construção. Entendese que as atividades desenvolvidas com a gamificação podem desenvolver práticas educacionais criativas e colaborativas capazes de promover valores como o conhecimento crítico, a autonomia do pensamento, a criatividade e habilidade para o desempenho de funções que se renovam a cada momento Duolingo Avaliado em 2013 pela Apple como o aplicativo do ano e pela Google Play como O melhor do melhor [Itunes e Google Play, 2013], o Duolingo é referência como aplicativo de ensino de idiomas. A Figura 1 apresenta a interface do aplicativo Duolingo no sistema IOS do iphone. Figura 1. Interface do Duolingo O Duolingo é um aplicativo que provê o aprendizado gratuito de um novo idioma. Voltado para aulas de inglês para os brasileiros, o aplicativo traz lições que vão desde o nível básico até o nível avançado. As tarefas envolvem traduzir termos básicos, reconhecer imagens-palavras (i.e., descobrir o significado de uma palavra em inglês através de imagens relacionadas ao próprio termo), entender e praticar a pronúncia de palavras e montar frases, sempre de acordo com o nível escolhido pelo usuário. Dessa 190

191 forma, se o usuário escolher um nível simples, encontrará desafios mais simples, e assim por diante [Gusmão, 2013]. Em cada lição, o Duolingo oferece ao usuário três vidas, que é a quantidade de vezes em que é possível errar. Caso o usuário ultrapasse essa quantidade, será necessário começar o exercício novamente. Conforme o usuário avança no aprendizado, novos níveis são desbloqueados e quando todos os níveis de uma categoria são completados, uma nova categoria é habilitada, com lições mais complexas. O aplicativo permite também que o usuário reforce suas habilidades desafiando seus amigos ou outros estudantes para um duelo, ou caso preferir, poderá também jogar contra o robô Duobot ou mesmo sozinho. [Gusmão, 2013] Avaliação de Interfaces Durante o processo de design, a avaliação da interface é importante, afinal é através dela que é possível verificar o sucesso ou insucesso da concepção do designer em relação a solução que ele está propondo em termos de funcionalidade e interação. Os processos de avaliação são essenciais à medida que o desenvolvimento de interfaces digitais apresenta enormes desafios em termos de metodologias de projeto, necessários para ajudar cada ciclo de vida de um sistema [Bertini et al., 2009]. Além disso, a avaliação contribui para tornar as interfaces mais agradáveis e atraentes. Existem diferentes métodos de avaliação de interfaces existentes. Conforme [Barbosa e Silva. 2010] esses métodos de avaliação podem ser classificados como: Avaliação por meio de investigação, onde o avaliador coleta a impressão dos usuários por meio de questionários ou entrevistas por exemplo; Avaliação por meio de inspeção, onde o avaliador busca se colocar no lugar do usuário enquanto examina o sistema; E por fim, Avaliação por observação, onde o avaliador coleta dados com usuários em situações reais de uso, buscando identificar problemas que ocorreram. Neste trabalho será apresentada a avaliação por meio de inspeção, na qual o Método de Inspeção Semiótica (MIS) está inserido. A seguir será explicado mais detalhes sobre esse método e a teoria em que ele se fundamenta Método de Inspeção Semiótica O Método de Inspeção Semiótica (MIS) é um fundamentado na Teoria da Engenharia Semiótica. A Engenharia Semiótica (EngSem) [de Souza 2005] é uma teoria explicativa de Interação Humano Computador (IHC), ou seja, uma teoria que nos permite entender os fenômenos envolvidos no design, uso e avaliação de um sistema interativo [PRATES, R. O. e BARBOSA, Simone D. J. 2007]. A EngSem oferece explicações para os fenômenos que ocorrem no design, uso e avaliação de um sistema interativo e foca no processo de comunicação entre o designer e o usuário por meio da interface do sistema. O objetivo do MIS é identificar se existem rupturas de comunicação e permitir que o(s) avaliador(es) reconstruam a mensagem que o designer transmite ao usuário. Essa mensagem é conhecida como metamensagem, que é compreendida pelo usuário à medida que vai interagindo com a interface. Na EngSem, a interface de um sistema é vista como um caso de metacomunicação (i.e., a comunicação entre a interface e o usuário), onde é comunicado ao usuário através dessa interface a visão do projetista em relação a quem se destina essa interface, quais 191

192 problemas ela pode resolver e como interagir com ela. Segundo [de Souza 95:84] a interface de um sistema é uma mensagem do designer para o usuário cujo conteúdo é: Esta é a minha interpretação sobre quem você é, o que eu entendi que você quer ou precisa fazer, de que formas prefere fazê-lo e por quê. Eis, portanto, o sistema que consequentemente concebi para você, o qual você pode ou deve usar assim, a fim de realizar uma série de objetivos associados com esta (minha) visão A metamensagem que o designer emite ao usuário é composta por signos, que são os elementos da interface. Na perspectiva da EngSem um signo é tudo aquilo que significa algo para alguém [Houser & Kloesel ( )]. A EngSem identifica três tipos de signos: os de metalinguísticos, os estáticos e os dinâmicos. Os signos de metalinguísticos são aqueles que se referem a outros signos da interface e são usados pelos designers para comunicar aos usuários os significados codificados no sistema e a forma de utilizá-los (e.g., documentação e sistema de ajuda do sistema). Os signos estáticos são aqueles que expressam o estado do sistema. Eles podem ser interpretados apenas olhando-se para a interface (e.g., botões que permitam o fechamento ou minimização de uma janela, ícone de uma pasta na área de trabalho e desenho de uma lupa no campo pesquisar em um browser). Já os signos dinâmicos expressam o comportamento do sistema e só podem ser percebidos a medida que o usuário interage com o sistema. (e.g., botão excluir torna-se habilitado quando seleciono um no outlook). Para avaliar uma interface o MIS propõe 5 etapas que devem ser seguidas pelo avaliador: (1) inspeção dos signos metalinguísticos; (2) inspeção dos signos estáticos; (3) inspeção dos signos dinâmicos; (4) contraste e comparação entre as mensagens identificadas em cada uma das inspeções e (5) apreciação da qualidade da metacomunicação. Durante as 3 primeiras etapas o avaliador deve reconstruir a metamensagem do designer e é sugerido o uso da paráfrase citada no início deste tópico como template. Na quarta etapa é feita uma comparação entre as mensagens de metacomunicação geradas pelo avaliador nos passos anteriores. E finalmente na última etapa se faz uma avaliação da comunicabilidade do sistema inspecionado. Assim, a aplicação do MIS para avaliar o aplicativo Duolingo permitirá, por meio da reconstrução da metamensagem do designer, identificar estratégias de gamificação utilizadas por ele para motivar os usuários a utilizar o aplicativo continuamente, e consequentemente, contribuir para o processo de aprendizado. 3. Trabalhos Relacionados Durante a revisão bibliográfica foi possível identificar alguns trabalhos que apresentaram o uso da gamificação em ambientes de aprendizagem. Em [Fardo, 2013] é apresentada algumas linhas gerais para a aplicação de gamificação no âmbito do ensino. O autor conclui que a gamificação pode ser vista como mais um dos caminhos em busca das soluções que a educação do século XXI demanda. O artigo apresentado por [Bomfoco e Azevedo, 2012] mostra as contribuições dos jogos eletrônicos para a aprendizagem na visão de James Paul Gee 1.Para isso eles enfocam os princípios de aprendizagem propostos e desenvolvidos por Gee. Para o autor, 1 Gee é pesquisador de letramento (literacystudies, em inglês) na Universidade Estadual do Arizona (EUA) e desenvolve trabalho original sobre Jogos eletrônicos e aprendizagem. 192

193 a teoria de aprendizagem existente nos bons jogos eletrônicos se adapta melhor ao mundo globalizado de alta tecnologia em que vivem as crianças e os adolescentes do que as teorias e as práticas de aprendizagem com as quais elas interagem na escola [Gee, 2004, p.7]. O trabalho apresentado por [Roque, Geiss, Santos e Silva, 2013] demonstra um estudo de caso no Ambiente Virtual de Aprendizagem (AVA) Moodle onde é proposto o GameLearning um bloco para ser incorporado ao ambiente Moodle que promove a competição entre os usuários através de técnicas de gamificação como níveis, rankings e barra de progresso. Para isso se propõe a implementação deste bloco no ambiente Moodle usando tais técnicas.com o novo bloco gamificado foi possível proporcionar aos usuários atividades de competição e para os autores fica evidente que a utilização de gamificação atende os princípios de ensino e aprendizagem. Os trabalhos apresentados nesta seção buscaram demonstrar como o uso de gamificação podem apoiar o processo de ensino e aprendizagem, mas, nenhum deles, procurou avaliar as técnicas de gamificação utilizadas e como o uso dessas técnicas podem motivar os usuários no uso contínuo da aplicação. De acordo com Mark White (2012), da empresa de consultoria inglesa Delloite, a gamificação está no ranking das dez tendências tecnológicas em Sendo assim, entender o uso de técnicas de gamificação no contexto de aprendizagem se torna um estudo relevante, tendo em vista que os resultados desse estudo podem apontar boas práticas no uso dessas técnicas de forma a colaborar no desenvolvimento de aplicativos no âmbito do ensino. 4. Metodologia Tendo em vista a questão que guia esse trabalho: Quais as estratégias de gamificação utilizadas pelo Duolingo que motivam os usuários no uso continuo da aplicação?, a metodologia utilizada para responder essa questão é ilustrada a seguir. 193

194 Revisão da Literatura Levantamento Bibliográfico dos trabalhos relacionados Definição do(s) método(s) qualitativo(s) a serem utilizados no trabalho Identificar diretrizes de gamificação utilizadas em sistemas de apoio ao aprendizado Identificação de Estratégias de Gamificação no Duolingo Definir as interfaces do Duolingo que serão inspecionadas. Examinar o aplicativo identificando estratégias de gamificação comunicadas por sua interface com base no Método de Inspeção Semiótica. Comparação das Estratégias de Gamificação identificadas Contrastar as estratégias de gamificação utilizadas no Duolingo com diretrizes de gamificação disponíveis na literatura Coleta de Dados com Usuários Definir o questionário de avaliação dos usuários com base nas estratégias de gamificação do Duolingo Aplicar o questionário em usuários do Duolingo para verificar se eles se sentem motivados pelos recursos de gamificação propostos em sua interface. Analisar os resultados a partir dos dados coletados no questionário Análise das Estratégias de Gamificação do Duolingo Verificar a adequação das técnicas de Gamificação propostas pelo projetista de interface do Duolingo com base no estudo das técnicas utilizadas e nos resultados dos dados coletados dos usuários do aplicativo Figura 2. Metodologia proposta para realização do trabalho Em linhas gerais, a metodologia consiste em inicialmente, fazer a revisão da literatura onde o objetivo é definir os métodos qualitativos que irão guiar o estudo e apontar diretrizes de gamificação empregadas em sistemas de apoio ao aprendizado. Em seguida pretende-se determinar as interfaces do aplicativo Duolingo que serão exploradas e identificar as estratégias de gamificação utilizadas nestas interfaces de forma qualitativa através do MIS, que foi adotado por poder ser utilizado para avaliar propriedades de outros contextos além da comunicabilidade [Reis e Prates, 2011]. A etapa seguinte se baseia na comparação das estratégias de gamificação identificadas na etapa anterior com as apresentadas na literatura. Logo após pretende-se verificar a eficiência no uso dessas estratégias a partir de avaliações com usuários do aplicativo. Para isso, será definido um questionário de avaliação com base nas técnicas de gamificação do Duolingo e em seguida será feita a aplicação deste questionário aos usuários buscando verificar se eles se sentem motivados pelos recursos de gamificação dispostos na interface do aplicativo. Por fim, será feita a análise dos dados coletados no questionário e nos resultados obtidos através do MIS para constatar se as técnicas de gamificação utilizadas no Duolingo são adequadas em relação à proposta do projetista de interface. 194

195 5. Resultados esperados e Contribuições São resultados esperados com a realização deste trabalho: Identificação e apresentação das estratégias de gamificação do aplicativo Duolingo. Caracterização da aplicabilidade dessas estratégias como elemento motivacional para o ambiente de aprendizagem ao qual o aplicativo está inserido. Em termos de contribuições, esse trabalho é relevante, pois investiga como a gamificação pode estimular o aprendizado, e além disso, os resultados obtidos neste trabalho podem servir como incentivo do uso de técnicas de gamificação por outros desenvolvedores a fim de apoiar na melhoria e desenvolvimento de aplicações no contexto de aprendizagem. 6. Cronograma Esta seção apresenta o cronograma a ser seguido para realização do trabalho Tabela 1. Cronograma de Atividades Previstas 2014 Etapa Atividade Mar Abr Mai Jun Jul Ago Set Out Nov Revisão da Literatura Identificação de Estratégias de Gamificação do Duolingo Comparação das Estratégias identificadas Coleta de Dados com Usuários Análise das Estratégias de Gamificação do Duolingo Levantar trabalhos relacionados X X Definir o(s) método(s) quantitativo(s) X X Identificar diretrizes de Gamificação X X Definir interfaces que serão examinadas X X Aplicar o MIS identificando técnicas de Gamificação Comparar estratégias identificadas no Duolingo com as utilizadas na literatura Definir o questionário de avaliação Aplicar o questionário em usuários do Duolingo Analisar os resultados com base nos dados coletados no questionário Verificar a adequação das técnicas propostas pelo projetista do Duolingo X X X X X X X X X X X X Escrever o artigo X X X X X X Referências BARBOSA, G. A. R., SANTOS, G. E. PEREIRA, V. M. O. (2013). Caracterização qualitativa da sociabilidade no Facebook. In: Simpósio Brasileiro de Fatores Humanos dm Sistemas Computacionais, Porto Alegre. BOMFOCO, M. A.; AZEVEDO, V. A. (2012). Os jogos eletrônicos e suas contribuições para a aprendizagem na visão de J. P. Gee. Revista Novas Tecnologias na Educação, Porto Alegre, v. 10, n. 3, p FARDO, L. M. A. (2013). Gamificação aplicada em ambientes de aprendizagem. Revista Novas Tecnologias na Educação, Porto Alegre, v. 11, n. 1, p

196 FEIJÓ, V.C., GONÇALVEZ, B.S., GOMEZ, L. S. R. (2013). Heurística para avaliação de usabilidade em interfaces de aplicativos smartphones: Utilidade, produtividade e imersão, 5. Rio Grande do Sul. FIALHO, N. N., MATOS, E. L. M. (2010). A arte de envolver o aluno na aprendizagem de ciências utilizando softwares educacionais, Curitiba. GOOGLE PLAY (2014). Duolingo, GUSMÃO, G. A. (2013). Avaliação Info - Duolingo". /ios/duolingo. ITUNES (2014). Duolingo, JUCÁ, S. C. S. (2009). A Relevância dos Softwares Educativos na Educação Profissional, Ceará. KAPP, Karl. (2012). The Gamification of Learning and Instruction: Game-based Methods and Strategies for Training and Education. Pfeiffer. NAVARRO, G. (2013). Gamificação: a transformação do conceito do termo jogo no contexto da pós-modernidade, São Paulo NOBREGA, A. T. B., GONÇALVES, H. L. (2013). Método de avaliação de comunicabilidade da engenharia semiótica: Um estudo de caso em um sistema web. Brasília. PRATES, R. O., BARBOSA, S. D. J. (2003). Avaliação de Interfaces de Usuário Conceitos e Métodos. In: Congresso Nacional da Sociedade Brasileira de Computação. Rio de Janeiro. REIS, S. d. S.; PRATES, R. O. (2011). Applicability of the semiotic inspection method: a systematic literature review. In: Proceedings of the X Symposium on Human Factors in Computing Systems and V Latin American Conference on Human Computer Interaction. Porto Alegre. ROQUE, A. S., GEISS, C. P. S., SILVA, D. R. (2013). Técnicas de gameficação em AVAs: Um estudo de caso no ambiente virtual de aprendizagem Moodle. Rio Grande do Sul. ROQUE, A. S., SANTOS, C. P., GEISS, E. (2013). GameLearning e suas Contribuições ao Ambiente Virtual de Aprendizagem Moodle, Rio Grande do Sul PRATES, R. O.; BARBOSA, S. D. J. (2007). Introdução à Teoria e Prática da Interação Humano Computador fundamentada na Engenharia Semiótica. In: T.Kowaltowski e K. K. Breitman (Org.). Jornada de Atualização em Informática do Congresso da Sociedade Brasileira de Computação. SBC. Rio de Janeiro. 196

197 Apreciação da Usabilidade do Moodle para Complemento ao Ensino no Contexto do Nível Fundamental Jéssica Tamires da Costa Penna 1, Glívia Angélica Rodrigues Barbosa 1 1 Instituto de Ciências Exatas e Informática Pontifícia Universidade Católica de Minas Gerais (PUC-MG), Av. Afonso Vaz de Melo, Barreiro de Baixo - Belo Horizonte, CEP Belo Horizonte MG Brasil jessica.penna@sga.pucminas.br, gliviaangelica@gmail.com Abstract. Virtual environments supporting education provide students and other users a range of resources and tools to be used. The usability of these system is one of the main features that should be considered when dealing with educational tools. This paper propose to evaluate the usability in Moodle system from the perspective of students who attend high school through heuristic evaluation and assessment with users. Later results and improvements will be generated. Resumo. Os ambientes virtuais de apoio ao ensino proporcionam aos alunos e demais usuários uma gama de recursos e ferramentas a serem utilizadas. A usabilidade do sistema é uma das principais características que deve ser considerada quando é feita a abordagem de ferramentas educacionais. Neste trabalho será apresentada a proposta da avaliação de usabilidade no sistema Moodle, na perspectiva de alunos que cursam o ensino fundamental, através da avaliação heurística e da avaliação com usuários. Posteriormente serão gerados resultados e melhorias para o mesmo. Aluno: Jéssica Tamires da Costa Penna Orientador: Glívia Angélica Rodrigues Barbosa Categoria: Trabalho de conclusão de curso de graduação. Estágio: Em desenvolvimento. 1. Introdução A educação e o ensino vêm sofrendo alterações nos seus padrões pedagógicos e de aprendizagem. O tradicional ambiente escolar que era constituído de professor, alunos e livros está sofrendo mudanças no decorrer dos últimos anos. Com a inclusão digital as pessoas têm diferentes possibilidades de acesso as tecnologias da informação e comunicação, esse avanço tecnológico tem influenciado as instituições a remodelarem e buscarem novas práticas de ensino, para proporcionar uma maior eficiência e eficácia no aprendizado [Moran 2002]. 197

198 As escolas estão adotando como ferramentas tecnológicas o uso de tablets, computadores, livros digitais, e a internet. Essa última surgiu como mais uma ferramenta utilizada na educação, devido o seu ambiente se estender além dos limites territoriais, econômicos e sócio-culturais. A comunidade científica notou a existência de algumas peculiaridades na internet que podiam auxiliar nas atividades inerentes ao processo de aprendizagem e ensino. Através deste espectro foi desenvolvida a ideia onde a internet seria uma rede onde as informações estariam disponíveis a todo indivíduo que pudesse acessá-la, iniciando-se assim uma nova forma de tratar o processo de aprendizagem a distância [Ferreira e Marques 2007]. Os Ambientes Virtuais de Aprendizagem (AVA) são sistemas web que possuem diversos recursos e funcionalidades. São utilizados na Educação a Distancia (Ead), e como ferramenta pedagógica no complemento do contexto escolar. Segundo Carvalho (2007) utilizar uma ferramenta de apoio e complemento à aprendizagem, em aulas presenciais, é uma nova estratégia pedagógica para mediar as relações existentes entre professor, aluno e conhecimento. Dentre as ferramentas utilizadas é possível citar o Moodle. O Moodle é um ambiente virtual de aprendizagem que vem sendo utilizado em diversos ambientes escolares, como universidades, cursos técnicos, disciplinas a distância e no ensino fundamental [Messa 2010]. O objetivo geral deste trabalho é realizar uma análise da usabilidade da plataforma Moodle como uma ferramenta de complemento à aprendizagem em aulas presenciais dos alunos do ensino fundamental (i.e., alunos de 1º ao 9º ano), uma vez que não foram identificadas apreciações semelhantes. Para isso será apresentado um estudo de caso do uso dessa plataforma no Colégio Master. Para alcançar o objetivo proposto a metodologia adotada consiste em realizar o levantamento bibliográfico de trabalhos relacionados, fazer a avaliação por inspeção, usando a avaliação heurística e posteriormente, comparar resultados obtidos com a perspectiva do usuário sobre a usabilidade da ferramenta. Esse trabalho é relevante porque poderá orientar os projetistas do Moodle a melhorar sua interface, além de fornecer indicadores que devem ser considerados durante a construção de um sistema de apoio ao ensino de forma a maximizar a usabilidade e consequentemente a satisfação, eficiência e produtividade dos usuários. 2. Referencial Teórico Os professores e alunos estão sendo desafiados com um novo modelo de aprendizado. O espaço e o tempo de interação do professor e aluno não ficam restritos a sala de aula. Novas situações estão sendo formadas com a Educação à Distância que é definida como (...) processo de ensino-aprendizagem, mediado por tecnologias, onde professores e alunos estão separados espacial e/ou temporalmente. É ensino/aprendizagem onde professores e alunos não estão normalmente juntos, fisicamente, mas podem estar conectados, interligados por tecnologias, principalmente as telemáticas, como a Internet. Mas também podem ser utilizados o correio, o rádio, a televisão, o vídeo, o CD-ROM, o telefone, o fax e tecnologias semelhantes [Moran 2002]. 198

199 No Brasil a EaD vem crescendo a cada dia e ganhando cada vez mais adeptos. De acordo com Gonçalves e Facundes (2012), em relação às políticas educacionais para a Educação a Distância, o primeiro marco legal foi o Artigo 80 da LDB, que reconhece a modalidade de educação à distância como processo positivo de formação do cidadão brasileiro. Esse artigo ainda determinou que a EAD no Brasil tivesse uma regulamentação própria e que o credenciamento das instituições que desejassem trabalhar com essa modalidade seria feito pela União. A EaD utiliza principalmente a web como forma de organizar e disponibilizar conteúdos para os usuários. Nesse sentido Carvalho (2007) explica que uma plataforma de EAD, ou seja, um ambiente virtual de aprendizagem (AVA), pode ser usado perfeitamente como ferramenta de apoio e complemento à aprendizagem em aulas presenciais. Ambiente Virtual de Aprendizagem é um sistema web que proporciona interação aos participantes do curso. A maioria das plataformas oferece diversas funcionalidades. Os AVAs exploram recursos da web e da educação a distância (EAD), integrando as tecnologias de informação e comunicação à educação através de mídias variadas (vídeos, imagens, textos, animações) e ferramentas para comunicação e interação como: chat ou bate-papo, fórum de discussão, envio de tarefas, dentre outros [Litto e Formiga 2007]. De acordo com a Associação Brasileira de Educação a Distância (Abed) a partir de 2000, a EAD cresceu espantosos 4500% em número de alunos no país [Martins e Moço 2009]. Esse crescimento tem motivado a realização de pesquisas focadas nesse contexto. Dentre os Ambientes Virtuais de Aprendizagem utilizados atualmente estão o Redu, Teleduc, Amadeus e Moodle. Cada um possui suas especificidades, recursos e ferramentas. Conceitualmente o sistema Moodle, denominação advinda originalmente do acróstico: Modular Object-Oriented Dynamic Learning Environment (...) é um ambiente virtual de código aberto, livre e gratuito e um dos sistemas de E-Learning mais utilizados no meio educacional, capaz de administrar atividades educacionais, criando comunidades on-line e ambientes virtuais destinados à aprendizagem [Ferreira e Marques 2007]. Diversas avaliações são feitas no Moodle com o objetivo de melhorar sua interface, aprimorar suas funcionalidades e garantir o melhor aproveitamento dos usuários, por exemplo: [Ferreira e Marques 2007], [Magalhães e Gomes 2010] e [Capelão e Coutinho 2011]. A usabilidade de um sistema é de vital importância para seu sucesso. Nielsen (1993), citado por [Lima 2007] afirma que usabilidade está relacionada com facilidade de aprendizado, eficiência, facilidade de memorização, quantidade de erros e satisfação do usuário. Segundo as normas da Internacional Standard Organization (ISO/IEC), a ISO 9126 diz que a a usabilidade refere-se à capacidade de um software de ser compreendido, aprendido, utilizado e ser atrativo para o utilizador, em condições específicas de utilização. Uma das formas de analisar a usabilidade de um sistema é realizar a avaliação heurística que é uma das mais utilizadas, por apresentar melhores resultados práticos, 199

200 facilidade de aprendizagem, além de ter a uma excelente relação custo beneficio [Ferreira e Marques 2007] Avaliação Heurística Jakob Nielsen (1993) apresentou, em seu livro Usability Engineering, dez diretrizes de usabilidade para a construção de interfaces gráficas com o usuário. Essas diretrizes, de acordo com ele, serviriam para qualquer tipo de produto interativo. Pouco tempo depois, em função da expansão da World Wide Web, Nielsen (1994) reescreveu suas diretrizes para atender também às necessidades desse novo ambiente Tornar o estado do sistema visível O sistema deve informar ao usuário continuamente sobre o que está sendo feito e como a entrada do usuário está sendo interpretada. O retorno do sistema não deve esperar até que um erro ocorra, mas deve prosseguir paralelamente à entrada de informação Correspondência entre o sistema e o mundo real Os diálogos com o usuário devem ser expressos em uma linguagem clara, por meio de palavras, expressões e conceitos familiares à comunidade de usuários, não em termos técnicos orientados ao sistema. Deve-se sempre adotar a perspectiva do usuário Usuário controla e exerce o livre arbítrio Durante toda sua interação com o sistema, o usuário deve se sentir no controle. Para exercer esse controle, o usuário precisa de segurança. Na Web, outro elemento de controle é o link para a página inicial que deve aparecer em todas as páginas. Por meio desse link, os usuários sempre podem "reiniciar" suas tarefas a qualquer momento Consistência a aderência as normas Os usuários não devem ficar em dúvida se diferentes palavras, situações ou ações significam ou não a mesma coisa. A consistência é um dos princípios mais básicos de usabilidade. Se os usuários souberem que o mesmo comando ou a mesma ação terá sempre o mesmo efeito, eles se sentirão mais confiantes e o aprendizado do sistema ficará mais fácil visto que, a cada nova etapa, uma parte do conhecimento necessário já estará disponível Prevenção de erros Além de apresentar uma mensagem de erro, é necessário evitar que o usuário experimente a situação que gerou o erro. Geralmente é possível identificar os pontos em que os erros são mais prováveis e os sistemas podem ser adaptados de forma a contornar essas situações Reconhecimento em vez de lembrança O usuário não deve ser forçado a memorizar informações ao passar de uma parte do diálogo a outra. Quando o sistema exigir que os usuários insiram dados em formato 200

201 especial, o sistema deve descrever o formato esperado (caracteres separadores, faixa de valores válidos) e, se possível, prover um exemplo válido. Deste modo, o sistema deve mostrar, em todas as páginas, onde exatamente ele está, como ele chegou até ali, além de orientá-lo, caso queira voltar Flexibilidade e eficiência O sistema precisa ser fácil para usuários leigos, mas flexível o bastante para se tornar ágil à usuários avançados. Essa flexibilidade pode ser conseguida com a permissão de teclas de atalhos, por exemplo Projeto de telas estético e minimalista A interface com o usuário deve ser tão simples quanto possível. A informação que o usuário necessita deve ser oferecida exatamente no tempo e local de sua demanda e apenas a informação relevante para uma determinada tarefa do usuário deve aparecer na tela correspondente Reconhecimento e recuperação de erros Situações de erro em um sistema devem ser tratadas com especial atenção por duas razões. Primeiro, elas representam, por definição, um ponto em que o usuário teve problemas e potencialmente será impedido de atingir o seu objetivo original. Segundo, elas apresentam uma oportunidade de ensinar o usuário, pois ele estará motivado a prestar atenção na mensagem apresentada, já que, nesses casos, o sistema geralmente tem a informação do que causou o problema. As mensagens de erro do sistema devem possuir uma redação simples e clara que ao invés de intimidar o usuário com o erro, recomendam uma saída ou possível solução Documentação e ajuda Um bom conjunto de documentação e ajuda deve ser utilizada para orientar o usuário em caso de dúvida. Deve ser visível, facilmente acessada, e oferecer uma ferramenta de busca na ajuda. O uso de técnicas como ajuda on-line dependente do contexto (ponteiros dos elementos de diálogo para o sistema de ajuda) e microajuda (um pequeno texto descritivo aparece quando o usuário pausa o cursor sobre um elemento de diálogo) são altamente recomendáveis. 3. Trabalhos Relacionados No artigo de Capelão e Coutinho (2011) se faz a investigação do Moodle utilizando os métodos Método de Inspeção Semiótica (MIS) e o Método de Avaliação de Comunicabilidade (MAC) com o objetivo de avaliar a qualidade da comunicabilidade da plataforma e incluir acessibilidade digital para alunos surdos e ouvintes. Como resultados encontrados eles obtiveram a descrição do uso do MIS e do MAC para avaliação de surdos e ouvintes em diferentes contextos, problemas sobre o uso do sistema e geração de melhorias. 201

202 O artigo de Magalhães e Gomes (2010) faz uma avaliação de usabilidade no Moodle IFAM (Instituto Federal de Educação Ciência e Tecnologia Amazonas) aplicando o percurso cognitivo e o MAC. Concluiu-se que os problemas apresentados podem ser resolvidos dependendo das habilidades dos administradores do Moodle. E de trabalhos futuros sugeriram explorar as restrições de configuração da ferramenta sem restringir sua flexibilidade aos usuários. O artigo de Resende (2007) media as interações do deficiente visual no Ambiente virtual de aprendizagem Moodle com o software Easy e enfatiza a necessidade de desenvolvimento de softwares de apoio para as pessoas com algum tipo de deficiência, em especial os sujeitos com limitação visual. O artigo retrata sobre tecnologias assistivas e da acessibilidade dos ambientes virtuais de aprendizagem. Concluiu-se que a ferramenta interagiu de forma satisfatória no Moodle. No artigo de Ferreira e Marques (2007) é aplicada a avaliação heurística sobre a interface do Ava para verificar o nível de usabilidade e buscar melhorias. A pesquisa foi aplicada no IESAM (Instituto de estudos superiores da Amazônia). São apresentados gráficos da pesquisa de acordo com cada heurística proposta na avaliação e são feitas sugestões de melhoria para o design, o layout e as atividades que são propostas. Os resultados indicaram um nível de severidade simples para a interface do ambiente virtual de aprendizagem Moodle/IESAM. Os problemas constatados na sua interface são classificados como imperfeições de baixa prioridade de resolução, não necessitando de reparos imediatos. Embora ocorra a inexistência de urgência de correção, tais problemas com suas devidas especificações foram submetidas a melhorias. O objetivo de estudo de Nunes e Torres (2012) consistiu em identificar e descrever quais recursos e características do AVA Moodle, enquanto sistema que agrupa diferentes tecnologias de informação e comunicação que podem contribuir no processo de aquisição, distribuição, interpretação e armazenamento de informação propostos por Huber (1991). Trata-se de uma pesquisa exploratória e documental. Constatou-se que a Aprendizagem Organizacional pode ser apoiada nos recursos do AVA Moodle e concluiu-se que o Moodle da UFSC (Universidade Federal de Santa Catarina), vem sendo utilizado tanto para dar apoio a cursos presenciais e condução de cursos oferecidos na modalidade a distância, quanto para capacitar recursos humanos que atuam na instituição, para o uso das ferramentas no AVA. O projeto de Carvalho (2007) visa analisar e quantificar, do ponto de vista dos alunos, a influência da utilização de uma plataforma de apoio e complemento à aprendizagem em aulas presenciais. É feita a verificação e a aceitação da ferramenta Moodle pelos estudantes da UNB (Universidade de Brasília), principal ferramenta de ensino a distância da Universidade. O autor afirma que a cada dia mais faz-se necessário integrar as ferramentas da tecnologia e comunicação com a didática escolar e de aprendizado. A metodologia utilizada foi a elaboração de um questionário de 37 perguntas pertinentes a educação a distância. Foi feita a análise de dados quantitativos e gerou-se uma tabela para cada informação recebida. Concluiu-se a partir dos dados analisados que o Moodle dentro da universidade deve ser disseminado e ampliado, uma vez que a aceitação dos alunos é boa. Para trabalhos futuros deve ser feito o levantamento de atividades para conseguir utilizar em larga escala o Moodle como ferramenta de apoio e complemento à aprendizagem. 202

203 4. Metodologia A metodologia para a execução do trabalho compreende estudar e pesquisar a usabilidade da plataforma Moodle, aplicando a avaliação heurística e realizando testes com os usuários. Os usuários são alunos que cursam o ensino fundamental (i.e., alunos de 1º ao 9º ano) do Colégio Master. Após feito os estudos e os testes, serão explicados os resultados e propostos sugestões de melhoria. A Figura 01 representa a metodologia sugerida. Figura 01. Metodologia proposta para a realização do Trabalho A metodologia é dividida em fases, a primeira apresenta a revisão de literatura onde foi feito o levantamento e o estudo bibliográfico, e definido qual seria a aplicação do método. A fase de inspeção consiste no estudo e pesquisa da plataforma Moodle, definição e preparação para a realização da avaliação heurística e a aplicação da mesma. Na fase de pesquisa com os usuários serão feitos levantamento de necessidades e utilização dos recursos e posteriormente realizados os testes e as experiências com os usuários. A finalização consiste em analisar os resultados e caracterizá-los sugerindo também mudanças para o contexto estudado. 203

204 5. Cronograma e Andamento das Atividades Previstas Essa seção apresenta a proposta do cronograma a ser seguido para a realização do trabalho e a situação das atividades previstas. Tabela 01. Cronograma de Atividades Previstas ANO 2014 ETAPA REVISÃO DE LITERATURA ATIVIDADE Levantamento Bibliográfico dos trabalhos relacionados Estudo dos métodos de Usabilidade Definição e estudo da avaliação heurística MÊS FEV MAR ABR MAI JUN JUL AGO SET OUT NOV DEZ X X X X X X X X INSPEÇÃO NO AMBIENTE MOODLE PESQUISA COM USUÁRIOS DO MOODLE ANÁLISE DOS RESULTADOS Definição e organização da turma no Moodle para avaliação Inspecionar o Moodle e as funcionalidades, utilizadas pelos alunos Aplicar a avaliação heurística no contexto utilizado Realizar um levantamento das necessidades, preferências e dificuldades dos alunos que utilizam a plataforma Realizar testes com os alunos e identificar as dificuldades encontradas Com base nas avaliações realizadas, caracterizar a interação dos alunos com o Moodle e identificar as falhas de usabilidade A partir dos resultados encontrados, oferecer sugestões de melhoria X X X X X X X X X X X X 5.1. Atividades em Andamento Dentre as atividades previstas, esta seção lista aquelas que estão em andamento Revisão de Literatura Essa atividade abrange os estudos do ambiente virtual de aprendizagem Moodle voltado para o contexto do ensino fundamental e para melhorar a interação dos usuários que a utilizam. Serão pesquisados trabalhos que avaliam ambientes virtuais de aprendizagem em diferentes contextos e diferentes tipos de usuários, trabalhos específicos da plataforma Moodle e que propõe melhorias para a mesma, e trabalhos que fazem a abordagem de 204

205 usabilidade principalmente a avaliação heurística. Também estão sendo realizados estudos sobre a pesquisa e avaliação heurísticas de Usabilidade segundo Jacob Nielsen Atividades a Executar Essa seção apresenta as atividades que deverão ser feitas ao longo do Cronograma, para a realização do trabalho proposto Inspeção no Ambiente Moodle Essa atividade consiste em inspecionar o ambiente Moodle utilizado pelos alunos. O objetivo é definir e organizar uma turma específica para a execução das avaliações e fazer uma pesquisa das funcionalidades e artefatos utilizados pelos usuários. Feito isso, será aplicado a avaliação de usabilidade baseado nas heurísticas. A partir desta inspeção serão obtidos os pontos positivos e negativos uma vez que o resultado de uma avaliação heurística é uma lista de problemas de usabilidade constatados na interface, acompanhada de referências aos princípios que cada problema viola Pesquisa com usuários do Moodle Esta tarefa consiste em realizar uma pesquisa de campo com os alunos do Colégio Master no intuito de identificar suas dificuldades, necessidades e preferências durante a interação com o ambiente virtual de aprendizagem Moodle. Para a realização dos testes será necessária a escolha correta das tarefas que representem fielmente as que são executadas no dia a dia do alunoo planejamento deve ser feito antes do início dos testes. Os testes podem ser formativos (que avaliam um aspecto da interface durante o desenvolvimento do software) ou somativos (que avaliam toda a interface e dá uma nota para a mesma) Análise dos Resultados A partir das avaliações feitas e dos resultados computados, será possível notar as necessidades e dificuldades que o usuário terá, serão identificadas as falhas na usabilidade e propostas melhorias na interface. 6. Resultados e Contribuições Esperadas Esse trabalho contribui no aprofundamento do conhecimento em relação ao ensino e pesquisa sobre ambientes virtuais de aprendizagem e usabilidade, o trabalho detém seu escopo na avaliação da usabilidade aplicada à interface do Ava Moodle do Colégio Master. Será feito o uso de técnicas de inspeção da usabilidade segundo o método de avaliação heurística, que propõe uma averiguação da interface do sistema através de questionários e checklists. Visto que o mercado tecnológico tem se tornado extremamente exigente, e tem se expandido em diversas áreas inclusive na educação, é importante focar-se no software para que o relacionamento com o usuário se desenvolva de forma clara e objetiva e que as necessidades do mesmo sejam supridas. 205

206 7. Referencias Capelão, L., Coutinho, F., et. al. (2011). Uma avaliação da qualidade de uso do Moodle na UFMG por alunos surdos e ouvintes., Faculdade de Letras, Departamento de Ciência da Computação, Laboratório de Ciência da Computação, Escola de Belas Artes e Universidade Federal de Minas Gerais (UFMG). Belo Horizonte. Carvalho, E. A. C. (2007). O Moodle como ferramenta de apoio e complemento à aprendizagem: uma comparação entre a utilização e não-utilização de uma plataforma de ensino em aulas presenciais., Universidade de Brasília, Instituto de Ciências Exatas, Departamento de Ciência da Computação. Ferreira, A. S. Q., Marques W. C.(2007). Análise da usabilidade no ambiente virtual de aprendizagem Moodle., Instituto de estudos superiores da Amazônia curso de engenharia da computação. Belém. Gonçalves, L. M., Facundes, M. H. S. (2012). Avaliando o Currículo: a contribuição das salas ambiente na formação dos coordenadores pedagógicos., Revista Coordenação Pedagógica: experiências e desafios na formação continuada a distância. UFT - Universidade Federal do Tocantins. Goiás: Editora PUC. Litto, F. M.; Formiga, M. (2007). A educação a distância: o estado da arte., São Paulo: Pearson Education. Magalhães, E., Gomes, V., et. al. (2010). Impacto da Usabilidade na Educação a Distância: Um Estudo de Caso no Moodle IFAM., Simpósio de Fatores Humanos em Sistemas Computacionais. Belo Horizonte. Martins, A. R., Moço, A. (2009). Educação à distância: Vale à pena entrar nessa?, Nova Escola. Nº227. Setembro. São Paulo: Editora Abril. Messa, W. C. (2010). Utilização de Ambientes Virtuais de Aprendizagem - AVAS: A Busca por uma Aprendizagem Significativa., Revista Brasileira de Aprendizagem Aberta e a Distância. Vol.9. São Paulo. Moran, J., Masetto, M., Behrens, M. (2002). Novas tecnologias e mediação pedagógica., 3. ed. Campinas: Papirus, São Paulo. Moran, J. (2002) O que é educação a distância - Novos caminhos do ensino a distância., CEAD - Centro de Educação a Distância. SENAI, Rio de Janeiro, ano 1, n.5, out-dez, pag 1-3. Nielsen, Jakob. (1994). Heurístic evaluation., In Nielsen, J., and Mack, R.L. (Eds), Usability Inspection Methods, John Wiley & Sons, New York, NY, Nunes, C. S., Torres, M. K. L., et. al. (2012). O ambiente virtual de aprendizagem Moodle: recursos para os processos de Aprendizagem Organizacional., Simpósio Brasileiro de Informática na Educação. Rio de Janeiro. Rezende, A. L. A. (2007). Easy: Mediando as interações dos deficientes visuais com o ambiente virtual de aprendizagem Moodle., In CIEEE 07: Anais do VII Congresso Iberoamericano de Informática Educativa Especial. Silva, R. S. Moodle para Autores e Tutores., São Paulo: Novatec Editora,

207 Análise Comparativa de Técnicas de Extração de Linhas de Produtos de Software Patrícia Dias 1, Gustavo Vale 2, Heitor Costa 1 1 Departamento de Ciência da Computação - Universidade Federal de Lavras 2 Departamento de Ciência da Computação - Universidade Federal de Minas Gerais patty@sistemas.ufla.br, gustavovale@dcc.ufmg.br, heitor@dcc.ufla.br Abstract. Due to advancement of technologies, software development market has become more competitive and demanding. To meet this demand, new approaches in software development have been studied; one of them Product Line Software (SPL). SPL consists of developing software from a common platform to systems. Although a relatively new approach, studies show that meets expectations of the software development fast, efficient and standardized way. However, implementation of this approach is not an easy task, identifying the need to find ways to assist in this implementation, extraction techniques for SPLs were developed. Defined as procedures and standards used to identify products of a SPL. In this work, we discussed some techniques for extracting, identifying criteria for characterization and a comparison among them is presented. Resumo. Com o avanço das tecnologias, o mercado de desenvolvimento de software tornou-se mais competitivo e exigente. Para atender essa demanda, novas abordagens no desenvolvimento de software vêm sendo estudadas; uma delas é Linha de Produtos de Software (LPS). Uma LPS consiste no desenvolvimento de software a partir de uma plataforma comum aos sistemas. Estudos mostram que essa abordagem atende as expectativas quanto ao desenvolvimento de software de maneira rápida, eficiente e padronizada. Porém, a implantação dessa abordagem não é uma tarefa fácil, identificando a necessidade de encontrar maneiras que auxiliam nessa implantação, foram desenvolvidas técnicas de extração de LPSs. Definidas como procedimentos e padrões utilizados para identificar os produtos de uma LPS. Nesse trabalho, são abordadas algumas técnicas de extração, identificando seus critérios de caracterização e, ao final, é apresentada uma comparação entre elas. Aluno: Patrícia de Paula Dias de Oliveira Colaborador: Gustavo Andrade do Vale Orientador: Heitor Augustus Xavier Costa Categoria: Trabalho de Conclusão de Curso de Graduação Estágio do Trabalho: Em Desenvolvimento 207

208 1. Introdução A busca por redução de custos e aumento da produtividade na construção de sistemas de software é constante. Desde a década de 60, vários estudos vêm sendo feitos na Engenharia de Software, permitindo a criação de sistemas de software mais complexos [Gaia, 2013]. Consequentemente, há o crescimento da preocupação com o reúso de software que evoluiu de forma simples ao reúso sistemático, em que há planejamento prévio e entendimento do sistema. O conceito de Linha de Produtos de Software (LPS) surgiu como uma abordagem emergente para projeto e implementação de sistemas que promovem reúso sistemático de componentes de software por meio de compartilhamento de um núcleo comum aos produtos da LPS [Gaia, 2013; Couto et al., 2011]. O objetivo é desenvolver novos sistemas a partir de um conjunto de componentes e artefatos comuns. Além desses componentes, uma LPS inclui componentes responsáveis pela implementação de variabilidades necessárias para determinar o domínio ou ambientes de uso [Gacek; Anastasopoulos, 2001]. O gerenciamento da variabilidade é feito por características que modelam o domínio utilizando modelos de características. Um produto resultante de uma LPS é composto por características comuns ao domínio e características particulares (não comuns a todos os produtos) [Knodel et al., 2006]. Com a criação de técnicas, de ferramentas e de tecnologias de desenvolvimento, a utilização de LPSs torna-se viável e prática. Isso deve ao fato da academia direcionar esforços e empresas perceberem a viabilidade da estratégia. Como empresas possuem vários sistemas previamente desenvolvidos, a necessidade de metodologias para migrar da prática convencional de desenvolvimento para a estratégia de LPSs motivou a realização deste trabalho. A fim de ajudar empresas na escolha de qual técnica utilizar, muitos trabalhos foram desenvolvidos, porém existem dificuldades em identificar a técnica mais adequada para cada empresa. Neste artigo, o objetivo foi realizar uma análise comparativa de cinco técnicas de extração de uma LPS: i) Compilação Condicional; ii) Coloração de Código; iii) Programação Orientada a Aspectos; iv) Programação Orientada a Características; e v) Módulos de Características Aspectuais. O restante do artigo está organizado da seguinte forma. A apresentação do conceito de LPSs está na Seção 2. Cinco técnicas para extração de LPSs são brevemente apresentadas na Seção 3. Uma análise comparativa das técnicas é mostrada na Seção 4. Trabalhos relacionados são resumidamente apresentados na Seção 5. Conclusões, contribuições e sugestões de trabalhos futuros são discutidas na Seção Linha de Produtos de Software O mercado de desenvolvimento de software precisa de produtos com qualidade elevada, custos reduzidos, adaptáveis às mudanças de mercado e construídos em tempo recorde de forma eficaz. Visando a essas expectativas, vários esforços em criar processos e arquiteturas de sistemas têm sido realizados ao longo dos anos. Seguindo esse caminho, uma abordagem para reutilização de software tem ganhado atenção da indústria e da academia conhecida como Linha de Produtos de Software (LPS). 208

209 A implantação e a institucionalização de uma LPS são custosas e, em consequência, demanda cuidado e planejamento [Durscki et al., 2004]. Portanto, para adotar essa estratégia, é importante que o administrador conheça a metodologia e, acima de tudo, realize estudo criterioso para avaliar a viabilidade de sua aplicação na empresa. As dificuldades de implantação de uma LPS são diversas e podem provir de várias fontes. A resistência organizacional, gerencial e dos desenvolvedores, a falta de recursos, desconfianças com o tamanho do investimento, dentre outras são alguns exemplos [Cohen, 2003]. Os benefícios são consistentes e maiores em relação às dificuldades quando o gerenciamento da LPS é feito minuciosamente. Dentre os principais benefícios, destacamse [Durscki et al., 2004]: i) ganho em produtividade; ii) melhor qualidade do produto; iii) redução de custo de produção; iv) redução no tempo de entrega do produto; e v) aumento da satisfação dos clientes. O processo de desenvolvimento de uma LPS é dividido em duas fases [Pohl, 2005]: Engenharia de Domínio e Engenharia de Aplicação. A Engenharia de Domínio é responsável por estabelecer a plataforma de reutilização, definir comunalidade e a variabilidade da LPS. A plataforma consiste nos tipos de artefatos de software (requisitos, design, testes, etc.) chamados de ativos-base. A Engenharia de Aplicação é responsável por derivar aplicações concretas a partir da plataforma estabelecida na engenharia de domínio. Ela explora a variabilidade da LPS e assegura sua correta instanciação de acordo com as necessidades específicas das aplicações finais (produtos). 3. Técnicas de Extração de Linhas de Produtos de Software Na implantação de LPSs, além da preocupação com a escolha do modelo de construção de LPS é importante identificar o mecanismo para o gerenciamento e para a extração de características que mais se adapta ao escopo da organização [Chen et al., 2006]. Neste trabalho, qualquer tecnologia/mecanismo capaz de compor/extrair características e desenvolver LPSs é considerada técnica de extração. Na literatura, podem ser identificadas técnicas de extração de LPSs organizadas em dois grupos [Ahmed et al., 2009]: i) baseadas em anotação; e ii) baseadas em composição. Técnicas Baseadas em Anotação propõem que o código fonte das características da LPS mantenha-se entrelaçado ao código base do sistema, sendo a identificação dessas características feita por meio de anotações explícitas. Anotações explícitas são aquelas em que há a necessidade de acrescentar metainformações diretamente no código fonte do sistema para delimitar o código a ser analisado por um pré-processador [Gaia, 2013; Couto et al., 2011]. Técnicas Baseadas em Composição propõem que cada característica seja implementada em um módulo distinto, promovendo a separação física entre o código base do sistema e o código que implementa cada característica. Assim, na composição do sistema, os desenvolvedores devem escolher os módulos a serem incluídos em determinado produto. Esse processo geralmente ocorre em tempo de compilação ou em tempo de implantação, o que permite manter o código base separado do código das características [Couto et al., 2011]. Dentre as cinco técnicas a serem apresentadas nesta seção, as duas primeiras (Textuais e Visuais) são baseadas em anotação, as outras três (Programação Orientada a 209

210 Aspectos, Programação Orientada a Características e Módulos de Características Aspectuais) são baseadas em composição. 1 Textuais [Santos; Valente, 2008]. São aquelas em que o código fonte é anotado por meio da utilização de diretivas especiais entendidas pelo pré-processador, tais como, #ifdef e #endif, utilizadas pelas linguagens C/C++. Assim, um pré-processador é informado de quais trechos de código devem ser incluídos/excluídos da compilação do sistema. Essas diretivas correspondem a linhas de código não compiladas, sendo dirigidas ao pré-processador que modifica o programa fonte, entregando ao compilador um programa modificado de acordo com as diretivas analisadas nesse processo. Compilação Condicional é um mecanismo de implementação e de gerenciamento de variabilidades em LPSs que utiliza anotação de código. Pode-se destacar que esse mecanismo não extrai fisicamente o código das características, pois as anotações são feitas no próprio código fonte, dificultando a visualização e a identificação das características e a legibilidade do código. A vantagem é o código ser marcado em diferentes granularidades, desde uma linha a um arquivo inteiro. 2 Visuais [Kästner; Apel, 2009; Kästner et al., 2008, Oliveira; Valente, 2009]. São aquelas em que há a utilização da camada de visualização de uma IDE para a anotação do código a ser pré-processado. Essa técnica advoga que anotações devem ser inseridas em trechos de código que possuam valor sintático. Para que funcione, deve haver um mecanismo que permita que os desenvolvedores anotem apenas os elementos dessa estrutura. Isto requer esforço extra, pois apenas anotações baseadas na estrutura sintática do programa são aceitas. Sem uma ferramenta para controlar as anotações, essa técnica tornase inviável. A coloração de código tem por finalidade implementar uma abordagem para anotações em código fonte, associando cores de fundo a trechos de código que implementam características. Possui as mesmas vantagens de Compilação Condicional (CC), mas evita a poluição do código-fonte. Contudo, por ser uma abordagem anotativa, os desenvolvedores não extraem fisicamente o código das características, apenas anotam os fragmentos de código no próprio código-fonte original do sistema e utilizam uma ferramenta de suporte para ter diferentes visões do código e para navegar entre as características. 3 Programação Orientada a Aspectos (POA) [Kiczales et al., 1997; Kiczales et al., 2001; Kästner et al., 2008]. É uma tecnologia para separação de interesses transversais presentes no desenvolvimento de sistemas. Interesses transversais são interesses espalhados e entrelaçados em diversos módulos do sistema, que implementam funções e podem afetar diferentes partes do sistema. Alguns autores incluem a programação orientada a aspectos nas abordagens composicional e anotativa. O motivo é, embora aspectos encontrem-se fisicamente separados do código fonte do sistema base, eles frequentemente utilizam anotações implícitas para funcionarem corretamente. 4 Programação Orientada a Características (POC) [Batory, 2004; Batory et al., 2003; Liu et al., 2006]. É uma técnica moderna para modularização e separação de características que "defende" que sistemas devem ser sistematicamente construídos por meio de definição e de composição de características. É uma tecnologia criada para síntese de produtos em LPSs, na qual características são utilizadas para distinguir os sistemas de uma mesma família de produtos. 210

211 5 Módulos de Características Aspectuais (MCA) [Gaia, 2013, Santos; Valente, 2008, Apel et al., 2008]. É uma técnica de programação que integra módulos e aspectos, cujo objetivo é implementar uma relação entre a programação orientada a características e a programação orientada a aspectos. Os conceitos de módulos de características aspectuais estendem a notação de módulo tradicional integrando aspectos, classes e refinamentos, pois é realizado o encapsulamento de funções de colaboração de classes e os aspectos que contribuem para uma característica. 4. Comparação e Discussão Sobre Técnicas de Extração Os critérios de caracterização permitem que sejam observadas semelhanças e diferenças entre as técnicas analisadas. Os critérios de caracterização são importantes para o estudo, pois expõe um conjunto de características desejáveis para as técnicas abordadas e são utilizados para realizar a análise comparativa. De acordo com análises de peculiaridades de cada técnica, os seguintes critérios foram identificados: Baseia-se em Atividades. A extração da LPS é realizada em fases, cada fase é composta por um conjunto de atividades que devem ser seguidas para a extração ser da melhor maneira possível; Permite coloração em código. As características são identificadas e coloridas de maneira que o código se torne mais legível. O mesmo mecanismo utilizado em anotação de código, porém utilizando coloração do código fonte; Suporta criação de módulos. Ocorre a separação das características do código fonte. Isso é possível utilizando a implementação de uma metodologia baseada em módulos. Ao contrário de anotação em código, é uma técnica que separa módulos de características do código fonte; Utiliza diretivas de pré-processamento. Diretivas de pré-processamento são utilizadas para delimitar linhas do código fonte que devem ser (ou não) incluídas em uma determinada versão de um sistema [Gaia, 2013; Santos; Valente, 2008]. Na Tabela 1, é apresentada uma comparação constando as técnicas abordadas, sua classificação em relação aos critérios identificados e a justificativa de tal classificação. As técnicas estão posicionadas na horizontal e os critérios na vertical. A comparação recebeu três opções de classificação: Atende: quando a técnica está de acordo com o critério analisado; Atende parcialmente: quando a técnica possui particularidades que atendem o critério analisado, porém não é seu foco; Não atende: quando a técnica não está de acordo com o critério analisado. Com a tabela apresentada, pode-se identificar que CC, por ser uma técnica baseada em anotação textual, atende apenas ao último critério avaliado (Utiliza diretivas de pré-processamento). Observa-se também que POC, POA e MCA, por serem baseadas em modularização de código, atendem apenas ao terceiro critério (Suporta criação de módulos). Coloração de código possui as mesmas vantagens de CC; dessa forma, atende ao mesmo critério, porém esse mecanismo não insere diretivas de pré-processamento diretamente no código, utiliza a coloração de código 211

212 Critérios para aumentar a legibilidade do código. Também atende ao segundo critério (Permite coloração em código), porém, por se basear principalmente em coloração de código e não em atividades, atende parcialmente ao primeiro critério (Baseia-se em atividades). Tabela 1 - Comparação das Técnicas de Extração de Linhas de Produtos de Software Técnicas Baseia-se em atividades Permite coloração em Código Suporta criação de módulos Utiliza diretivas de préprocessamento Baseadas em Anotação Compilação Condicional Não atende Essa técnica está baseada principalmente em anotação de código Coloração de Código Atende parcialmente A técnica possui algumas atividades, porém está baseada principalmente em coloração de código. Programação Orientada a Características Baseadas em Composição Programação Orientada a Aspectos Módulos de Características Aspectuais Não atende Não atende Não atende A técnica está baseada principalmente em extração de módulos de características. A técnica está baseada principalmente em extração de módulos de interesses transversais. A técnica está baseada principalmente em extração de módulos de características. Não atende Atende Não atende Não atende Não atende Como são Como são Módulos são As ferramentas extraídos extraídos extraídos que auxiliam na módulos, não se módulos, não se utilizando extração não --- faz necessária faz necessária ferramentas que suportam coloração em coloração em não suportam coloração. código. código. coloração. Não atende Não atende Atende Atende Atende As características A anotação é do código fonte feita no próprio são coloridas código fonte. sem que haja modularização Atende Atende parcialmente Não atende Não atende Não atende Como módulos são extraídos, não se faz necessária a utilização de diretivas de préprocessamento. Como módulos são extraídos, não se faz necessária a utilização de diretivas de préprocessamento. Como módulos são extraídos, não se faz necessária a utilização de diretivas de préprocessamento. Ainda na Tabela 1, são destacadas particularidades de cada técnica com a finalidade de ajudar desenvolvedores a escolher aquela que melhor se adequa a sua empresa. Essa adequação pode provir do conhecimento (prévio) da equipe de desenvolvimento e/ou de pontos fortes de uma técnica. Com os dados apresentados, pouco pode ser dito e concluído, pois não é realizada uma comparação entre características de qualidade, tais como, manutenibilidade, testabilidade, usabilidade e eficiência de desempenho, definidas na ISO/IEC [ISO/IEC 25000, 2005]. Essa comparação não faz parte do objetivo deste trabalho, pois para realizar uma discussão fundamentada, um estudo de caso, com as cinco técnicas seria necessário. Com o conhecimento adquirido com a revisão da literatura, alguns pontos merecerem ser destacados, entre eles: 212

213 As técnicas composicionais são melhores quanto à legibilidade, à testabilidade, à evolutibilidade e à manutenibilidade. Isso pode ser afirmado, pois diretivas de préprocessamento, vistas em técnicas baseadas em anotações, são conhecidas por sua capacidade de poluir o código-fonte, tornando-o menos legível, consequentemente, mais difícil de entender, de manter e de evoluir, além de introduzir erros de difícil detecção em uma inspeção manual [Bram et al., 2009; Kästner; Apel, 2009]; Em contra partida, de forma geral, as técnicas baseadas em anotações são mais próximas da programação orientada a objetos; muitas vezes, as características são extraídas do próprio código orientado a objeto. Enquanto, para utilizar técnicas baseadas em composições, como POC e POA, é necessário mudar a forma de pensar, por exemplo, deixar a orientação a objetos de lado e utilizar a orientação a características e aspectos, respectivamente. Dessa forma, a migração para técnicas baseadas em anotações tendem a ser mais simplista e menos custosa; Projetos de MCA e POC tendem a ser mais estáveis que CC e POA (coloração não foi avaliada) [Gaia, 2013]; Adição de características utilizando mecanismos de CC geralmente provoca aumento do entrelaçamento e do espalhamento das características quando a evolução da LPS é considerada [Gaia, 2013]. 5. Trabalhos Relacionados Nesta seção, são apresentados três trabalhos considerados relacionados por realizar comparações entre técnicas de extração de LPSs ou termos similares, como mecanismos para controle da variabilidade. Como pode ser percebido, existe diferença entre os anos de publicação dos artigos (2001, 2008 e 2013) a qual motiva a realização deste trabalho, pois mostra ser um tópico "difícil" de ser avaliado e estar aberto para novas análises. Em um artigo [Santos; Valente, 2008], foram descritas e comparadas tecnologias para implantação de variabilidades na área de jogos para celulares. Inicialmente, foram abordados assuntos referentes ao desenvolvimento de jogos para dispositivos móveis e apresentadas as tecnologias nas quais o trabalho está baseado, tais como, CC, POA e POC. Além disso, um estudo de caso é realizado e as tecnologias foram avaliadas de acordo os seguintes critérios: i) configurabilidade; ii) modularidade; iii) reusabilidade; iv) simplicidade e facilidade de aprendizagem; e v) tamanho do código. Essa avaliação permitiu concluir que tecnologias modernas de implementação de variabilidades, como POA e POC, oferecem ganhos importantes em relação a tecnologias mais tradicionais, como CC. Em outro artigo [Gacek; Anastasopoulos, 2001], é tratada a questão da variabilidade na LPS no nível de código. Para isso, foram analisadas onze técnicas de implementação de variabilidades: i) agregação/delegação; ii) herança; iii) parametrização; iv) sobrecarga; v) (Delphi) propriedades; vi) carregando classe dinâmica; vii) bibliotecas estáticas; viii) bibliotecas de ligação dinâmica; ix) CC; x) frames; e xi) POA. Com isso, foram identificados requisitos para implementação de apoio para as variabilidades encontradas no contexto de LPSs. As características de implementação de variabilidade são discutidas, 213

214 descritas e identificadas. Ao final, é apresentada uma matriz de comparação das técnicas de acordo com os seguintes critérios: i) interface; ii) implementação; iii) inicialização; e iv) tempo. Alguns exemplos de implantação das técnicas abordadas foram apresentados e pode ser concluído que a escolha da abordagem depende do problema em questão e que a combinação de técnicas disponíveis é algo que deve ser considerado. Em um trabalho de dissertação de mestrado [Gaia, 2013], foram realizados dois estudos de caso envolvendo duas LPSs (WebStore e MobileMedia). O objetivo foi avaliar quantitativamente como os mecanismos de gerenciamento de variabilidade se comportam em relação à propagação de mudanças de modularidade durante a evolução de uma LPS, utilizando quatro mecanismos de variabilidade (técnicas de extração) diferentes (CC, POC, POA e MCA). Como resultados, MCA foi a técnica que se "saiu melhor", seguida de POC, POA e CC. MCA e POC comportaram-se melhor quanto à estabilidade da LPS; no entanto, MCA destacou-se quando interesses transversais são considerados. CC apresentou problemas de modularidade de características quando a evolução de LPSs é considerada. Os trabalhos mencionados assemelham-se a esse artigo no que diz respeito a um estudo comparativo de implementações/técnicas de extração de LPSs. No primeiro trabalho, são descritas e comparadas ferramentas de extração de variabilidades na área de jogos para celulares, utilizando um estudo de caso aplicando cada ferramenta. Neste artigo, não é utilizado um estudo de caso e as técnicas foram analisadas e comparadas de acordo com critérios pré-definidos. No segundo trabalho, são analisados pontos específicos de técnicas de extração, como herança e sobrecarga e técnicas de extração como CC e POA; neste trabalho, apenas técnicas de extração são comparadas. Além disso, a avaliação considera diferentes critérios que necessitam de exemplos para deixar as diferenças explicitas. O terceiro trabalho realiza um estudo de caso com intuito de comparar a evolução de LPSs utilizando quatro técnicas de extração, enquanto este artigo utiliza cinco técnicas, não apresenta um estudo de caso e destaca as particularidades de cada técnica com a finalidade de facilitar a escolha e não apontar a melhor técnica. 6. Considerações Finais Nesse trabalho, foram apresentadas cinco técnicas de extração de LPSs e seus critérios de caracterização. Essas técnicas foram analisadas com base em critérios de caracterização definidos considerando particularidades entre as técnicas. Como resultado, foi elaborada uma tabela com os critérios avaliados em: "Atende", "Atende parcialmente" e "Não Atende" e a justificativa dessa avaliação. Nessa tabela, o objetivo não é apontar qual técnica de extração é melhor, mas apontar particularidades de cada técnica para os desenvolvedores escolherem a técnica que mais se adéqua as necessidades de sua empresa. Com a revisão da literatura, pode-se observar que POC e MCA destacaram-se positivamente entre as técnicas analisadas. Além disso, pode-se observar que os estudos realizados sobre LPSs estão, em grande parte, focados na elaboração de ferramentas que auxiliam na extração das características dos sistemas atuais, poucos abordam técnicas utilizadas na extração de LPSs. Esse fato contribuiu de forma positiva e negativa para a realização deste trabalho. Positivamente, por identificar possibilidades de pesquisa nessa 214

215 área; negativamente, pois dificulta a definição das técnicas de extração e a busca por informações sobre elas. Pretende-se com esse trabalho contribuir com as pesquisas realizadas atualmente, bem como auxiliar na escolha da técnica de extração e facilitar a transição de desenvolvimento de software tradicional para a abordagem de LPSs. Como trabalhos futuros, pretende-se identificar novas técnicas de extração e critérios de caracterização. Além disso, será utilizada uma das técnicas para extrair uma LPS e medições serão realizadas no resultado da extração. Referências Ahmed, F.; Campbell, P.; Lagharid, M. S. (2009) Cognitive Factors in Software Product Line Engineering. In: International Conference on Computer Modelling and Simulation. pp Apel, S.; Leich, T.; Saake, G. (2008) Aspectual Feature Modules. In: Transactions on Software Engineering. V. 34, I. 2, pp Batory, D. (2004) Feature-Oriented Programming and the Ahead Tool Suite. In: International Conference on Software Engineering. pp Batory, D.; Sarvela, J. N.; Rauschmayer, A. (2003) Scaling Step-Wise Refinement. In: International Conference on Software Engineering. pp Bram A.; Wolfgang, D. M.; Herman T.; Ahmed E. H. (2009) Can we refactor conditional compilation into aspects? In: 8th ACM International Conference on Aspect-Oriented Software Development (AOSD). pp Chen, Y.; Gannod, G. C.; Collofello, J. S. (2006) A Software Product Line Process Simulator. In: Software Process: Improvement and Practice, pp Cohen, S. (2003) Predicting when Software Product Lines Pays. In: Software Engineering Institute. 34 p. Couto, M. V.; Valente, M. T.; Figueiredo, E. (2011) Extracting Software Product Lines: A Case Study Using Conditional Compilation. In: European Conference on Software Maintenance and Reengineering. pp Durscki, R. C.; Spinola, M. M.; Burnett, R. C.; Reinehr, S. S. (2004) Linhas de Produto de Software: Riscos e Vantagens de sua Implantação. In: Simpósio Internacional de Melhoria de Processos de Software, pp Gacek, C.; Anastasopoulos, M. (2001) Implementing Product Line Variabilities. In: Symposium on Software Reusability: Putting Software Reuse in Context. pp Gaia, F. N. (2013) Uma Avaliação Quantitativa de Módulos de Características Aspectuais para Evolução de Linhas de Produto de Software. Dissertação de Mestrado. Universidade Federal de Uberlândia. 62 p. ISO/IEC (2005). Software Engineering - Software Product Quality Requirements and Evaluation (SQuaRE) - Guide to SquaRE. 215

216 Kästner, C.; Apel, S. (2009) Virtual Separation of Concerns - A Second Chance for Preprocessors. In: Journal of Object Technology, pp Kästner, C.; Apel, S.; Kuhlemann, M. (2008) Granularity in Software Product Lines. In: International Conference on Software Engineering. pp Kiczales, G.; Hilsdale, E.; Hugunin, J.; Kersten, M.; Palm, J.; Griswold, W. G. (2001) An Overview of Aspect. In: European Conference on Object-Oriented Programming. pp Kiczales, G.; Lamping, J.; Mendhekar, A.; Maeda, C.; Lopes, C.; Loingtier, J. M.; Irwin, J. (1997) Aspect-Oriented Programming. In: European Conference on Object-Oriented Programming, v. 1241, pp Knodel, J.; Lindvall, M.; Muthing, D.; Naab, M. (2006) Static Evaluation of Software Architectures. In: European Conference on Software Maintenance and Reengineering, pp Liu, J.; Batory, D.; Lengauer, C. (2006) Feature Oriented Refactoring of Legacy Applications. In: International Conference on Software Engineering. pp Oliveira, V. B. de; Valente, M. T. (2009) Coloração Automática de Variabilidades em Linhas de Produtos de Software. In: Simpósio Brasileiro de Componentes, Arquiteturas e Reutilização de Software. pp Pohl, K.; Böckle, G.; Frank, J. van der Linden (2005) Software Product Line Engineering: Foundations, Principles and Techniques. In: Springer-Verlag New York, Inc., Secaucus, NJ, USA 468 p. Santos, R. C; Valente, M. T. (2013) Uma Comparação Preliminar entre Tecnologias para Implementação de Variabilidades em Jogos para Celulares. Instituto de Informática, PUC Minas. Disponível em: Acesso em: 17/03/ p. 216

217 Implantação da gerência de configuração de software em uma empresa privada de desenvolvimento de software Déborah Helen S. Pinto 1, Maria Augusta V. Nelson 1 1 Instituto de Ciências Exatas e Informática Pontifícia Universidade Católica de Minas Gerais (PUC-MG), Av. Afonso Vaz de Melo, Barreiro de Baixo - Belo Horizonte, CEP Belo Horizonte MG Brasil deborahhelen.s@gmail.com, guta@pucminas.br Abstract. This paper aims to implement the activities of configuration management with emphasis on version management and change request in a private software development company. The methodology consists of the elaboration of a configuration management manual, deployment of supporting tools, and the discovery of the software development process in the company before and after carrying out the activities of configuration management. As a result, we intend to achieve improvements in the software development process, maintaining the traceability of changes made to the system and avoid the problems that occur without version management. Resumo. Este trabalho tem como objetivo implantar as atividades da gestão de configuração com ênfase no gerenciamento de versão e solicitação de mudanças em uma empresa privada de desenvolvimento de software. A metodologia consiste na elaboração do manual de gestão de configuração, implantação das ferramentas de apoio e do levantamento do processo de desenvolvimento de software antes e após a empresa executar as atividades da gestão de configuração. Como resultado, pretende-se alcançar melhorias no processo de desenvolvimento de software, manter a rastreabilidade das mudanças realizadas no sistema e evitar os problemas que ocorrem sem o gerenciamento de versão. Aluna: Déborah Helen S. Pinto. Orientadora: Maria Augusta Vieira Nelson. Categoria: Trabalho de conclusão de curso de graduação. Estágio: Em desenvolvimento com conclusão prevista para novembro de Introdução Devido à constante evolução do software e um mercado cada vez mais exigente, as empresas de software buscam aprimorar o seu processo de desenvolvimento controlando todas as modificações realizadas em seus artefatos de software. Na construção de um software é produzido um grande conjunto de informações, como arquivos de código fonte, dados, arquivos de documentação, entre outros que sofrem 217

218 modificações por diversos fatores. Por isso é de grande importância manter o controle e a integridade do software durante todo seu ciclo de vida. Diante dessa necessidade, diversas metodologias de desenvolvimento de software são elaboradas para manter o controle de todas as informações produzidas ao longo de todo o processo de construção. Segundo Pressman (2011), a Gerência de Configuração de Software (GCS) é uma área da Engenharia de Software que consiste de um conjunto de atividades de rastreamento e controle iniciadas quando um projeto de engenharia de software começa e termina apenas quando o software sai de operação. Com base nesse contexto, é possível perceber que as empresas de pequeno ou grande porte que não utilizam a gestão de configuração de software, estão sujeitas a enfrentar diversos problemas durante o seu processo de desenvolvimento, como manter a rastreabilidade de artefatos de um software, identificar a versão vigente ou voltar a uma versão anterior, modificar concorrentemente o artefato sendo que os desenvolvedores podem estar geograficamente distribuídos, perder funcionalidades que foram implementadas, tratar a solicitação de mudanças para projetos em andamento, entre outros. Esses problemas resultam na desorganização das atividades de desenvolvimento e influenciam diretamente na qualidade final do produto. Este trabalho tem como objetivo definir e implantar as atividades da gerência de configuração de software em uma empresa privada, que não possui uma política de GCS implementada, com o intuito de controlar as alterações realizadas no software e manter a integridade do produto. As atividades serão definidas com base nos padrões de gestão de configuração propostos por Berczuk e Appleton (2002). Serão utilizadas ferramentas open source de apoio à GCS para auxiliar o processo de desenvolvimento do software da empresa. As atividades a serem definidas terão ênfase no gerenciamento de versão e solicitação de mudanças. Gerenciamento de construção (builds) não será considerado nesse trabalho. Os objetivos específicos traçados para este projeto são: Elaborar o manual de gestão de configuração Criar o template de plano de gestão de configuração com base no template do RUP. Criar o formulário de solicitação de mudanças. Selecionar ferramenta(s) livre(s) para a apoiar a gestão de configuração. Disponibilizar e implantar as ferramentas para o gerenciamento de versão. Disponibilizar através da ferramenta EPF (eclipse process framework) o processo a ser realizado no controle de versão e solicitação de mudanças tomando como base os padrões de gestão de configuração propostos por Berczuk e Appleton (2002). Realizar treinamento com os envolvidos nas atividades de GCS. Identificar os prós e contras após as atividades de GCS serem implementadas e realizar uma análise do processo de desenvolvimento de software antes e após a gestão de configuração. 218

219 Este trabalho está organizado da seguinte forma. A Seção 2 apresenta a contextualização do problema. A Seção 3 fornece o embasamento teórico enquanto os trabalhos relacionados são analisados na Seção 4. A Seção 5 apresenta a metodologia do trabalho e descreve o estágio em que se encontra. 2. Contextualização As atividades de gestão de configuração serão implantadas em uma empresa privada de desenvolvimento de software, que atua no mercado desde 2003 na cidade de Contagem e que tem como o principal produto um sistema integrado de Enterprise Resource Planning (ERP) voltado para indústrias de usinagem. Atualmente a empresa possui aproximadamente 105 clientes onde cada um possui seu código fonte separado. Além da quantidade de versões existentes do sistema, percebe-se também uma demanda muito alta de alterações devido ao diferencial que a empresa oferece aos clientes de customizar o sistema de acordo com suas regras de negócio. Diante deste cenário de diferentes versões do sistema, diversas modificações solicitadas por cada cliente e com a ausência de uma ferramenta para o gerenciamento de versão, problemas como perda de funcionalidades implementadas, dificuldade de identificar a versão em produção, voltar a uma versão anterior, rastrear mudanças que foram solicitadas durante o processo desenvolvimento ou manutenção do sistema e até mesmo a opção dos programadores desenvolverem paralelamente o mesmo código se tornam empecilhos que dificultam manter a qualidade final do produto. 3. Referencial Teórico Esta seção apresenta conceitos de gestão de configuração, características das ferramentas de gestão de configuração bem como os padrões de gestão de configuração apresentados na literatura Gestão de Configuração Para manter a integridade e a qualidade de um software é preciso acompanhar toda sua evolução, pois os componentes que constituem um software sofrem diversas modificações no decorrer de seu ciclo de vida. Segundo Pressman (2011), mudanças no software podem comprometer a qualidade do produto já que a grande tendência é que junto com as alterações sejam inseridos erros ou criados efeitos colaterais. Sendo assim, para que a qualidade do software seja mantida diante de diversas modificações é primordial o uso da Gestão de Configuração do Software. A gestão de configuração de software (GCS) pode ser definida como a arte de identificar, organizar e controlar modificações no software que está sendo construído por uma equipe de desenvolvimento segundo Molinari (2007). De acordo com o SWEBOK (2014), a gestão de configuração é formalmente definida como: Disciplina que impõe orientação e supervisão técnica e administrativa para: identificar e documentar as características funcionais e físicas de um item de configuração, controlar mudanças nestas características, gravando e relatando o status de processamento e implementação das mudanças, e verificando conformidade com os requisitos especificados. (SWEBOK, 2014, 6-1). 219

220 Segundo Pressman (2011), a gestão de configuração é dividida em três funções principais: gerenciamento de versões que é responsável por gerenciar o processo de mudanças dos componentes do software e seus respectivos relacionamentos; gerenciamento de mudanças responsável por avaliar, armazenar e rastrear todas as mudanças que ocorreram na evolução do sistema; gerenciamento de construção que de acordo com um conjunto de artefatos estabelecidos, facilita a construção de diferentes versões de um sistema. Para garantir que um software seja desenvolvido de acordo com suas especificações e de forma íntegra, a GCS possui um conjunto de atividades que são realizadas durante sua evolução. Segundo o SWEBOK (2014) estas atividades são: Gerência e planejamento dos processos de GCS, identificação e configuração de software, controle de configuração de software, estimativa do status da configuração de software, auditoria da configuração de software, e a gestão de lançamento e entrega do software. Para obter uma gestão de configuração bem sucedida, é necessário que o planejamento dos processos de GCS seja realizado cautelosamente. Nessa atividade, é desenvolvido um plano de gestão de configuração que é mantido e atualizado de acordo com o ciclo de vida do sistema, e que contém todas as atividades da GCS, tais como identificação de itens de configuração, definição de ferramentas que auxiliem a GCS, gerenciamento da GCS como organização, responsabilidades, autoridades, políticas aplicadas, entre outras que após serem implementadas, passam por uma auditoria para garantir que toda as atividades estão sendo realizadas com o intuito de garantir a integridade e a qualidade do software. Na etapa de identificação de itens de configuração, é definido cada elemento criado durante o desenvolvimento de um software que precisa ser controlado e mantido. Segundo Molinari (2007), um item de configuração é o menor item de controle em um processo de gestão de configuração. Diante destes itens de configuração estabelecidos, em certos momentos do ciclo de vida do software são definidas as baselines que são um conjunto de itens de configuração relacionados e que estabelece um marco ou uma versão do software. Sendo assim, para manter as baselines ou os itens relacionados em diversas versões é necessário o uso de um repositório que é um conjunto de mecanismos e estruturas que permite a uma equipe de software gerir modificações de modo efetivo. O controle de configuração de software está voltado para o gerenciamento de modificações durante o ciclo de vida do sistema. Neste controle são definidos os processos para determinar as mudanças que irão ocorrer, responsáveis por aprovar e autorizar estas mudanças e apoio para implementar tais mudanças abordadas. A atividade de estimar o status da configuração do software é realizada para registrar toda a comunicação de informações necessárias para uma gestão eficaz da configuração de software. Para garantir que todas as atividades estão sendo realizadas conforme o esperado, é executada a auditoria de software que é uma atividade realizada de forma independente para avaliar a conformidade de produtos de software e processos de regulamentos, normas, diretrizes, planos e procedimentos conforme a norma IEEE para revisões e auditorias de software referenciada no SWEBOK (2014). 220

221 3.2. Ferramentas de Gestão de Configuração Segundo Pressman (2011), quanto maior o software maior será o número de itens de configuração que o constitui. Além da dificuldade de controlar software com uma quantidade maior de itens de configuração, outro problema que as organizações encontram ao controlar a evolução de seu software são as equipes que se encontram geograficamente distribuídas e precisam trabalhar sobre os mesmos artefatos. Como os artefatos de um software sofrem diversas modificações ao longo de seu ciclo de vida, para auxiliar essa evolução existem diversas ferramentas disponíveis para apoiar a GCS. Segundo Koscianski e Soares (2007), é necessário o uso de uma ferramenta para manter o controle de versões dos artefatos do sistema. Dentre as ferramentas comerciais que disponibilizam diversas funcionalidades, Dantas (2008) cita a IBM Rational Clear Case que é um sistema de gerenciamento de configuração desenvolvido pela própria IBM e a Microsoft Visual SourceSafe (VSS) que é um sistema que além de controlar software, também controla documentos e imagens entre outros artefatos. As ferramentas open source oferecem diversas funcionalidades que auxiliam a GCS. As mais conhecidas segundo Dantas (2008) são as CVS (Concurrent Version System) e o SVN (Subversion) (2014). O CVS é um sistema de controle de versão que permite que as equipes de desenvolvimento trabalhem com diversas versões de um sistema em um repositório remoto ou local e o SVN que também é um sistema de controle de versão, porém foi desenvolvido com o intuito de substituir o CVS devido a algumas limitações que ele possuía. Além destas ferramentas, temos o GitHub e o Mercurial que também são ferramentas de controle de versão que trabalham de forma distribuída e possuem versões gratuitas e pagas segundo Freitas (2010). Além das soluções apresentadas para auxiliar o controle de versão, existem ferramentas que também apoiam outras atividades da GCS. Dentre as soluções para auxiliar o controle de mudanças, existem as ferramentas open source Mantis (2014) e Bugzilla (2014) que são sistemas de controle de mudanças que registram todas as modificações solicitadas no decorrer do ciclo de vida do software Padrões de Gestão de Configuração Sabendo que um processo de desenvolvimento de software envolve diversas pessoas trabalhando em paralelo para desenvolver determinado artefato, é essencial aplicar padrões no contexto de desenvolvimento de software para que o produto final esteja de acordo com o especificado. Como as organizações estão cada vez mais preocupadas com a evolução de seu software, é possível aplicar padrões de gestão de configuração que são independentes de ferramentas para auxiliar durante todo o processo de desenvolvimento. Berczuk e Appleton (2002) descreveram padrões de gestão de configuração que auxiliam as organizações a resolver diversos problemas comuns que enfrentam ao implementar a GCS. Eles definiram os seguintes padrões: Mainline com o desenvolvimento paralelo de um software, este padrão permite trabalhar com uma codeline central e descreve como gerenciá-la para minimizar os esforços que a integração de branching e merging requerem. 221

222 Active Development Line em um ambiente de desenvolvimento de software onde vários colaboradores estão realizando modificações nos artefatos que podem vir a conflitar, este padrão ajuda a manter a evolução do software sobre a Mainline. Private Workspace este padrão descreve a utilização de um espaço privado para os colaboradores do desenvolvimento software, com o intuito de minimizar os problemas de integração entre os artefatos. Repository quando é necessário realizar uma modificação no software, é necessário uma área para acomodar a versão correta dele e assim realizar as mudanças necessárias de forma isolada. Para isso, este padrão mostra como configurar um repositório local para que este trabalho seja realizado sem afetar a versão atual do software. Task Commit Level como existem diversas mudanças no software, este padrão permite organizar e rastrear estas mudanças por unidades orientadas a tarefas de trabalho. Codeline Policy este padrão descreve como estabelecer políticas de cada codeline, pois é necessário que os desenvolvedores saibam como tratar cada uma delas de acordo com seu propósito. Smoke Test mesmo utilizando padrões para verificar se o build do sistema está correto, este padrão verifica também se o sistema continua funcionando após as mudanças realizadas durante o processo de desenvolvimento. Unit Testing além do padrão Smoke Test que pode ser insuficiente para averiguar o funcionamento do software após uma mudança, este padrão mostra como testar de forma detalhada as mudanças realizadas e assim manter a codeline. Regression Test quando um erro é corrigido no software ou quando é realizada qualquer mudança, existe uma probabilidade alta de inserir outros erros. Este padrão é utilizado para certificar que o código atual do sistema não piore à medida que estas mudanças e correções ocorrerem. Private Versions a medida que o desenvolvimento de software ocorre, os desenvolvedores tem a necessidade de avaliar se uma mudança pode quebrar ou não um build do sistema. Diante disso, este padrão permite utilizar versões privadas para que o desenvolvedor experimente as mudanças realizadas localmente sem afetar a codeline principal. Release line durante o ciclo de desenvolvimento e manutenção de software, são disponibilizadas várias versões dele. Porém, com a necessidade de controlar estas versões em produção e continuar evoluindo o software para uma nova versão, este padrão mostra como realizar mudanças sobre as releases existentes sem afetar o desenvolvimento da release atual. Task Branch este padrão descrever como os desenvolvedores podem trabalhar em ramos de tarefas em projetos que demandam um tempo maior, garantindo a consistência e a integridade da Mainline que está sendo desenvolvida. 222

223 4. Trabalhos relacionados Durante a revisão bibliográfica foi possível identificar alguns trabalhos que relatam experiências de implantação de processos de gestão de configuração. Werner e outros (2010) apresentaram um processo de implantação da gestão de configuração para as indústrias de software visando obter o conhecimento do produto e evitar negligência na condução de mudanças no software. Baseado na utilização de práticas e ferramentas e levando em consideração a cultura organizacional de desenvolvimento de software, o processo de gestão de configuração foi implantado em uma indústria de software que auxiliou na padronização das atividades e dos artefatos por elas gerados. O trabalho realizado por Pereira (2008) apresentou um processo de gestão de configuração com procedimentos, políticas e artefatos padrões visando atingir os resultados esperados do processo GCO do nível F do MPS.BR. Utilizando a ferramenta Subversion, o estudo de caso foi aplicado em uma empresa de médio porte que mesmo sem uma avaliação formal, devido a implantação do processo estar ainda na fase inicial, foi possível identificar o ganho da produtividade nas atividades realizadas durante o desenvolvimento do software e as melhorias obtidas no controle de inúmeros itens de configuração que eram produzidos e alterados durante o ciclo de vida do software. O estudo apresentado por Fernandes (2011) identificou que as organizações brasileiras enfrentam uma grande dificuldade em adotar conceitos e práticas para a implantação da gestão de configuração devido à complexidade das atividades envolvidas neste processo, como a definição de uma abordagem adequada e a utilização de uma ferramenta de apoio. Diante disso, o autor propôs uma estratégia em 4 fases (Iniciação, Planejamento, Implantação e Encerramento) para auxiliar a adoção das práticas da gestão de configuração e assim reduzir os custos e a complexidade envolvidos na implantação da gestão de configuração. Embora os trabalhos apresentados nesta seção descrevam processos de implantação da gestão de configuração, o diferencial desse trabalho é o foco da definição do processo estar baseada nos padrões de gestão de configuração propostos por Berczuk e Appleton (2002). Os padrões descrevem soluções que serão implementadas ao se identificar os problemas da falta de gestão de configuração e sua necessidade para o controle da qualidade do produto final. Acredita-se que a prática de reutilizar soluções e estratégias maduras que foram documentadas através de padrões trará benefícios para a empresa em questão. 5. Metodologia A metodologia proposta para a realização deste trabalho compreende implantar as atividades da gestão de configuração de software, com foco em gerenciamento de versão e solicitação de mudanças, em uma empresa privada de desenvolvimento de software. A Figura 01 ilustra as etapas da metodologia proposta. 223

224 Figura 01: Atividades a serem realizadas para conclusão do trabalho Conforme apresentado na Figura 01 a primeira etapa da metodologia visa a elaboração do manual de acordo com a definição do processo de mudança e de gestão de configuração baseado no IEEE Std1042 (1997) e baseado em padrões a serem utilizados na empresa e no processo atual de desenvolvimento de software adotado pela empresa. A segunda etapa consiste na implantação das ferramentas de apoio à gestão de configuração e consequentemente a realização de um treinamento das ferramentas implantadas para os envolvidos nas atividades de GCS. Após a implantação das atividades na empresa, será realizado um levantamento dos principais pontos positivos e negativos que foram identificados e também avaliar o processo de desenvolvimento de software antes e após a gestão de configuração. O trabalho se encontra na primeira etapa do desenvolvimento e estará concluído em Novembro de Referências Bibliográficas BERCZUK, Steve; APPLETON, Brad. Software Configuration Management Patterns: Effective Teamwork, Practical Integration. Addison-Wesley Professional, ISBN: Bugzilla. Disponível em < Acesso em 21 abr BURQUE, Pierre; FAIRLEY, Richard. SWEBOK. Guide to the Software Engineering Body of Knowledge. IEEE Computer Society, Version 3.0,

225 DANTAS, Cristiane. Gerencia de configuração de software: Desenvolvendo software de forma eficiente e disciplinada. Revista engenharia de software magazine, Rio de de Software em Empresas de médio porte. Dissertação de Mestrado Profissional em Computação Aplicada, Universidade Estadual do Ceará, convênio com a Universidade Federal do Rio de Janeiro. Rio de Janeiro Disponível em < dissertacao81>. Acesso em 14 maio FREITAS, Daniel. Análise Comparativa entre Sistemas de Controle de Versões. Trabalho de Conclusão de Curso UFJF, Juiz de Fora, IEEE (1997). Guide to Software Configuration Management, ANSI/IEEE Std1042. KOSCIANSKI, André; SOARES, Michel dos Santos. Qualidade de software: Aprenda as metodologias e técnicas mais modernas para o desenvolvimento de software. São Paulo: Novatec, ed. 395p. ISBN: Mantis Bug Tracker. Disponível em < >. Acesso em 21 abr MOLINARI, L. Gerência de Configuração: técnicas e práticas no desenvolvimento de software. Florianopolis: Visual Books, MPS.BR - Melhoria de Processo do Software Brasileiro. Disponível em < pdf />. Acesso em 20 mar PEREIRA, Carolina. Implantando gerência de configuração com o apoio da ferramenta subversion (SVN) para atingir os resultados esperados do processo GCO do nível F do MPS.BR. Trabalho de Conclusão de Curso UFLA, Lavras, PRESSMAN, R.S. Engenharia de Software. 7ª ed. São Paulo, Pearson Education do Brasil, SVN. Disponível em < >. Acesso em 30 mar WERNER, C., MURTA, L., CORREA C., SANTOS, R., SCHOTS M., CEPEDA, R., FERNANDES, P., PRUDÊNCIO, J., LYRA, F. Um processo de implantação de gerência de configuração na Indústria. 7º Workshop de Manutenção de Software Moderna - WMSWM'10/IX Simpósio Brasileiro de Qualidade de Software, Belém, junho 2010, pp

226 Um Processo para Melhoria de Processos para uma Empresa de Pequeno Porte - Um Estudo Introdutório Vinícius Pereira, Heitor Costa Departamento Ciência da Computação - Universidade Federal de Lavras Caixa Postal CEP Lavras - MG - Brasil vinicusallesp@computacao.ufla.br, heitor@dcc.ufla.br Abstract. This paper presents a proposal of process model to improvement of quality for small software companies. In this paper, we used concepts for implementing software, highlighting the use of Six Sigma and Empirical Engineering of Software. The result of this paper is a model of a process to improvement of quality that describes tasks that can be used for the enhancement of the process of small companies. Resumo. Este artigo apresenta uma proposta de modelo de processo de melhoria da qualidade de processos para empresas de pequeno porte desenvolvedoras de software. Este trabalho reúne um conjunto de conceitos relacionados ao desenvolvimento de software, destacando o uso de Seis Sigma e Engenharia de Software Experimental. O produto deste trabalho é um modelo de um processo de melhoria da qualidade que descreve atividades que podem ser utilizados para a melhoria dos processos de pequenas empresas. Aluno: Vinícius Sales Pereira Orientador: Heitor Augustus Xavier Costa Categoria: Trabalho de Conclusão de Curso de Graduação Estágio do Trabalho: Em Desenvolvimento 1. Introdução Por causa da competitividade, empresas buscam cada vez mais aperfeiçoar a qualidade de seus produtos. Para isso, elas utilizam metodologias que realizam melhorias em seus processos e produtos. Essas metodologias são guias para seguir, não tendo explícitos nem simplificados os passos para realizar a melhoria de qualidade. A aplicação dessa melhoria em empresas desenvolvedoras de software é diferenciada das empresas de outros setores, em que a baixa qualidade de um produto pode ser vista e mais facilmente inspecionada. Defeitos em sistemas de software podem ser encontrados na realização de testes, mesmo que não estejam livres de erros. A diferenciação da implementação da melhoria em processos de empresas de pequeno porte não é uma escolha, mas obrigação para competir com empresas maiores que implementam a melhoria da qualidade em seus processos. A deficiência em empresas de pequeno porte muitas das vezes é a falta de estrutura, sendo a mão de obra especializada contida nessa falta, pois, muitas vezes, um integrante da equipe de desenvolvimento pode desempenhar mais do que um papel, sendo esta uma limitação observada. Nesse cenário de diferenciação entre empresas de pequeno e grande porte, é necessário descrever atividades de um processo tendo a preocupação de alinhar 226

227 competências de desenvolvimento de uma pequena empresa com as atividades necessárias para aplicar a melhoria da qualidade. Neste artigo, o objetivo foi elaborar um processo inicial de melhoria da qualidade que define atividades necessárias para aplicação da qualidade, a fim de facilitar o entendimento e ser utilizado em empresas de pequeno porte desenvolvedoras de software, utilizando conceitos de Engenharia de Software Experimental, Modelos de Qualidade de Processos e Seis Sigma. O restante do artigo está organizado da seguinte forma. Breve resumo sobre Seis Sigma, Engenharia de Software Experimental e Melhoria de processos é apresentado na Seção 2. Sugestão inicial de um processo de melhoria da qualidade para software é abordada na Seção 3. Alguns trabalhos relacionados estão resumidos na Seção 4. Conclusões e sugestões de trabalhos futuros são apresentadas na Seção Referencial Teórico 2.1 Seis Sigma Seis Sigma é um conjunto de práticas utilizadas com o objetivo de melhorar a qualidade de processos empresariais com base fundamentada na estatística. Ele surgiu como resposta à estratégia japonesa, chamada TQM (Total Quality Manager) no início dos anos 90, para melhoria da qualidade de processos [Shcheuermann, 1997; Pfeifer, 2004]. Além de utilizar estatística, Seis Sigma tem destaque pelo comportamento exigido das equipes de projetos que estabelece diferentes níveis de gerência empresarial. Em Seis Sigma, o nível de qualidade de um processo é medido com a quantidade de erros desse processo com a utilização de escala de defeitos a cada milhão de oportunidades, sendo que o padrão desejável é chegar ao máximo de 3,4 erros a cada milhão. O que leva as empresas a escolher Seis Sigma como metodologia de melhoria da qualidade [Harry; Schroeder, 2000]: i) necessidade de traduzir as ações para linguagem financeira; ii) melhoria nos fatores humanos (por exemplo, treinamento dos funcionários, mudança cultural e foco nas necessidades do cliente) e melhoria nos fatores de processo (por exemplo, diminuição da taxa de variação, estabilidade dos processos e aumento da capacidade operacional); iii) uso do método DMAIC (Definir, Medir, Analisar, Implementar e Controlar) para garantir o planejamento do tratamento de defeitos e sua aplicabilidade utilizando medições, sendo realizado de forma iterativa o que proporciona a melhoria contínua; e iv) estrutura de formação para capacitar funcionários para desenvolver suas atividades. O DMAIC é um método construído com base no PDCA para o Seis Sigma, sendo utilizado para melhorar um produto existente, o que justifica sua utilização. As suas etapas do DMAIC são: Define (Definir). São feitas buscas para identificar as causas raiz do problema identificado, tendo a preocupação de verificar o que causou o problema, a abrangência do problema, o tempo de ocorrência, o inicio da ocorrência e os envolvidos. É necessário rigor ao descobrir essas causas para propor tratamento adequado ao problema; uma técnica comumente utilizada é a de perguntas sucessivas até ter a visão ampla do problema; Measure (Medir). É realizada a medição do problema, pois, sabendo que existe um problema, é necessário medir o quanto ele afeta a produção. Nessa etapa, são utilizados testes estatísticos para definir a gravidade do problema no produto e a porcentagem de produtos afetados por esse problema; 227

228 Analyse (Analisar). São analisados os dados obtidos pela etapa de medição para verificar se as causas raiz do problema tendo em mãos o paralelo do que seriam os valores ideais de saída com os valores obtidos. Com essa analise, é possível verificar qual o fator que originou o problema; Improve (Melhorar). É realizado o planejamento, sendo configurado para um tratamento compatível com o problema verificado no produto. Esse planejamento deve informar como está o estado atual e como o produto ficará após a aplicação do tratamento, qual é a quantidade máxima de produtos afetados pela persistência do problema e qual é a gravidade máxima observada em um produto após o tratamento. Todo tratamento proposto tem grau de liberdade que deve ser estimado, pois possivelmente a melhoria não ira remover o defeito em 100%, mas reduzirá a probabilidade de ocorrência e o impacto ao produto. Alem da redução do defeito, é necessário descrever o ganho com a realização da alteração, pois, se existe uma alteração sendo proposta a um produto, deve-se compreender o motivo e o ganho dessa alteração; Control (Controlar). É realizada verificação constante dos resultados obtidos após o tratamento do problema, tendo a possibilidade do tratamento ter criado outro problema o que viabiliza a reaplicação do método DMAIC no processo. Caso haja sucesso na aplicação do tratamento, o método pode ser utilizado pra reduzir o nível de defeitos persistentes Engenharia de Software Experimental Engenharia de Software Experimental (ESE) pode ser entendida como uma ferramenta para execução de experimentos em processos de software [Travassos, 2002]. O seu objetivo é conseguir identificar e descrever fenômenos que acontecem na aplicação em que, durante o planejamento, seria difícil ter a visão de tais fenômenos ou impossível prevê-los. A ESE não obrigatoriamente é aplicada em um experimento; podem ser utilizados questionários para identificar comportamento ou realizados estudos de caso para identificar causas de fenômenos em relatos. A ESE pode ser realizada em [Travassos; Biolchini, 2007]: i) in vivo, realização do experimento no ambiente real; ii) in vitro, realização do experimento com pessoas reais e ambiente controlado; iii) in virtuo, agentes e ambiente são virtuais; e iv) in silico, ambiente e agentes são programados em um sistema que opera automaticamente. A construção do resultado do experimento é dependente de testes estatísticos de hipóteses. Dois tipos de hipóteses são utilizados: i) hipótese alternativa, a qual deseja alcançar com o experimento; e ii) hipótese nula, a qual mostra que a hipótese alternativa é falsa. Os testes de hipóteses vão dizer se a hipótese nula deve ou não ser rejeitada. A aceitação é dada em porcentagem, geralmente 5% ou 1%, sendo que, ao escolher aceitação de 5% e a hipótese nula obtiver índice igual ou maior a 5% de probabilidade de ocorrência, a hipótese nula não pode ser descartada; caso contrário, a hipótese nula pode ser descartar [Malhotra, 2004; Travassos et al., 2002]. A ESE pode ser útil para melhorar a qualidade dos processos empresariais, permitindo compreender fenômenos antes da instalação e ajudando a empresa a reduzir custos caso o planejado não seja um tratamento adequado. Existem três tipos de experimentos distintos. Os tipos de experimento são classificados como: i) survey, um estudo em que se aplica um questionário para observação de um comportamento humano; ii) estudo de caso, um estudo realizado após 228

229 o acontecimento de um evento; e iii) experimento, aplicação da teoria em prática. Com Survey, pode-se verificar a aderência de um sistema, a motivação da equipe e suas dificuldades de adaptação, mas sua desvantagem é a facilidade de manipulação dos resultados e o "medo de repressão" dos participantes. Com estudo de caso, busca-se identificar causas raiz de um evento; sua desvantagem é a possibilidade de perder dados importantes para conclusão da análise, sendo necessário aceitar relatos de envolvidos como parte da identificação das causas raiz. Com experimento, pode-se verificar teoria aplicando na prática e sua desvantagem é a necessidade de existir um planejamento de como realizar o experimento e ter custo mais elevado de sua aplicação Melhoria da Qualidade dos Processos A sobrevivência das organizações vai além da busca por novos clientes, estando relacionada com fatores que determinam sucesso ou fracasso. Melhorar os processos da organização é fator crítico para o sucesso de qualquer organização, seja pública ou privada, desde que realizada de forma sistematizada e entendida por todos na organização. O objetivo de realizar a melhoria de processos é agregar valor aos produtos e aos serviços que as organizações prestam aos seus clientes [Scartezini, 2009]. Com o objetivo de melhorar a qualidade de seus processos, as empresas passam a aderir modelos de maturidade, que sistematicamente certificam a melhoria de organização. CMMI (Capability and Maturity Model Integration) é um modelo de maturidade para melhoria de processo, destinado ao desenvolvimento de produtos e serviços, e composto por melhores práticas associadas a atividades de desenvolvimento e de manutenção que cobrem o ciclo de vida do produto desde a concepção até a entrega e manutenção [CMMI, 2006]. CMMI tem cinco níveis de melhoria, em que cada nível possui um conjunto de processos associados. MPS é o modelo brasileiro para melhoria de processo criado pela Softex [Softex, 2012] com sete níveis de maturidade. Cada nível possui um conjunto de processos associados. 3. Proposta de Processo de Melhoria da Qualidade As etapas do processo proposto são apresentadas na Figura 1. Apesar de ser um processo iterativo, é necessária a representação do inicio e do fim de uma iteração, o que significa que, ao final das quatro etapas, haverá melhoria em, pelo menos, um processo empresarial. Inicialmente, o modelo de processo de melhoria da qualidade foi criado de maneira macro, ou seja, em uma visão ampla das necessidades de melhoria da qualidade. Com base nas pesquisas em Seis Sigma, Engenharia de Software Experimental, técnica SWOT (Strengths, Weaknesses, Opportunities e Threats - Forças, Fraquezas, Oportunidades e Ameaças), modelos de qualidade MPS (Melhoria de Processos de Software) e CMMI e PMBoK (Project Management Body of Knowledge), foram criadas quatro etapas para o processo. Posteriormente, foram definidas atividades necessárias para atingir os objetivos de cada etapa. O Seis Sigma foi utilizado aplicação de melhorias incrementais, que possibilita melhoria gradual do processo. A ESE foi utilizada por causa da possibilidade de realizar experimentos comprobatórios a respeito de possíveis tratamentos a erros encontrados. A técnica SWOT foi utilizada por possibilitar a empresa a identificar fatores como os Pontos Fortes, Pontos Fracos, Oportunidades e Ameaças, que possibilitam a empresa 229

230 realizar seus objetivos e traçar objetivos sólidos. O MPS e CMMI foram utilizados por definirem objetivos de processos e áreas de processo para a melhoria da qualidade empresarial, o CMMI sugere à pequenas empresas a não criar um grupo especifico para melhoria da qualidade dos processos. Assim, as atividades descritas neste trabalho são de maneira que possa ser realizada por papéis encontrados em empresas de pequeno porte, acatando a recomendação do CMMI. O PMBoK foi utilizado por sugerir boas práticas de gerência. Figura 1 - Processo de Melhoria da Qualidade Durante o período de elaboração de modelos de melhoria de qualidade, algumas metodologias buscavam identificar fraquezas e riscos em áreas chaves [Gonçalves, 2006]. Por ser importante essa identificação, julgou-se relevante essa atividade ser contemplada neste trabalho. Além disso, a atividade proposta identifica pontos fortes e oportunidades, facilitando a orientação da empresa a seguir e alcançar seus objetivos. Para a análise dos pontos fortes e pontos fracos, foi utilizada a representação da técnica de analise SWOT. A primeira etapa definida no processo foi denominada Análise do Ambiente, em que a empresa busca situar-se segundo seus objetivos. Por identificar os riscos que afetam a empresa, a etapa Análise do Ambiente deixa uma pendência a ser resolvida, pois o risco não é algo que afeta a empresa no presente, mas é um potencial e um impacto previsto caso ele venha a tornar-se uma realidade. Portanto, mesmo que essa etapa não realize o tratamento dos riscos, ela realiza a descrição deles para serem tratados. A segunda etapa do processo é denominada Controle de Risco. Após realizar as duas primeiras etapas, a empresa compreende que seus objetivos estão alinhados e os riscos que podem acontecer estão tratados, entretanto seus processos ainda podem ser executados com baixa qualidade. Isso pode acontecer caso seus processos de produção sejam realizados de forma incorreta com relação à maneira que deveriam operar, seja por estar em divergência com a maneira de operabilidade documentada seja pela documentação estar descrita de maneira errada em relação à funcionalidade do processo. A etapa Gerência do Produto dos Processos tem o objetivo de analisar as saídas de cada processo buscando identificar anormalidades nos produtos, oriundas de reflexo de um erro do processo de produção. Essa etapa é responsável por identificar e relatar o erro. Somente identificar um erro não é o suficiente para que seja tratado. Existem variáveis que o cercam e podem contribuir para que o erro identificado possa ser 230

231 agravado. Assim, é necessário realizar uma busca pela causa raiz da ocorrência do erro. Essa busca considera o tempo (quando foi identificado e desde quando esse problema afeta a qualidade), o ambiente, os envolvidos e as hipóteses. Dessa forma, podem ser identificadas as causas raiz para realizar o planejamento de um tratamento, mas deve garantir que o planejamento resultou em um tratamento para o processo; caso contrário, o investimento aplicado à resolução do problema pode ser perdido e aumentar o defeito ou criar outros defeitos ao processo. Com isso, para existir confiabilidade, pode ser realizado um experimento para verificar a aplicabilidade do tratamento. O experimento deve ser bem definido e expressar o ambiente real do processo e, após o experimento, são realizados testes estatísticos com a finalidade de certificar que o experimento realmente teve resultado satisfatório. Dessa forma, de processo em processo, pode ser feita a melhoria da qualidade dos processos e pode ser refeita a etapa Análise do Ambiente para identificar novos objetivos. Foram definidas 44 atividades e distribuídas nas quatro etapas do processo. Essas atividades são apresentadas na Tabela 1, que contém um identificador, a etapa que a atividade pertence, a atividade e breve descrição da atividade. O identificador AA, CR, GPP e CQP correspondem às etapas Análise do Ambiente, Controle de Risco, Gerência do Produto dos Processos e Controle da Qualidade do Processo, respectivamente. A atividade Identificar Inconformidades está presente nas etapas Controle de Risco e Gerência do Produto dos Processos, sendo a única a estar em duas etapas, até o momento. Tabela 1 - Atividades do Processo # Etapa Atividade Descrição 1 CQP Aplicar Experimento Colocar em prática o experimento planejado e aprovado anteriormente. Consiste em um estudo sobre os riscos identificados que agridem a 2 CR melhore a qualidade da empresa. Avaliar e Defender a empresa, tendo o objetivo de inverter o risco, transformando um Qualidade fator que afeta a empresa negativamente para um fator que Verificar, dentre as oportunidades enumeradas na reunião, qual pode ser implantada pela empresa. Verificar possibilidades de 3 AA Aproveitar Oportunidade mercado, verificar possibilidade de aproveitar oportunidades em conjunto. Realiza estudo sobre pontos positivos e negativos das oportunidades. Tomar decisão de quais oportunidades podem ser aproveitadas realmente. 4 CR Combater as Planejar meios de proteger pontos vulneráveis da empresa de 5 CQP Vulnerabilidades Criar Unidade de Implantação 6 AA Criar Guia de Reunião 7 CR 8 CR Criar Plano de Contingência Definir Ações Contra Ameaças 9 CQP Definir Materiais 10 CQP 11 CR Desenvolver Plano de Aceitação do Produto Desenvolver Plano de Gerenciamento de Risco maneira a eliminar tais vulnerabilidades. Definir o passo a passo de como transcrevera a implantação do tratamento. Reunir informações importantes a respeito dos assuntos a serem abordados na reunião com a finalidade de servir de apoio a reunião. Os riscos que não foram tratados proativamente devem ser tratados reativamente e descritos no plano de contingência, definindo o que será realizado caso o risco aconteça e quem responsável por realizar tal ação. Identificar as Ameaças e definir meios de eliminá-las. Definir os recursos necessários para implantar o tratamento a ser realizado. Estabelecer o nível de aceitação do produto final e do produto de cada processo. Criar documento que descreva as ações tomadas em relação ao risco. 231

232 Tabela 1 - Atividades do Processo (cont.) # Etapa Atividade Descrição 12 CQP Desenvolver Plano de Iteração 13 CR Desenvolver Plano de Medidas 14 CQP 15 CR Desenvolver Plano de Mudança Desenvolver Soluções de Problemas 16 CQP Elaborar Experimento 17 CQP 18 CQP 19 AA Escrever Plano de Gerenciamento Configuração Estabelecer Processo de Controle de Mudança Executar Técnica de Análise do Ambiente 20 AA Identificar Riscos 21 CR GPP 22 CR Identificar Inconformidades Identificar Padrões de Segurança 23 CR Impor Normas 24 AA Iniciar Projeto 25 CQP Liberar Mudança 26 AA Melhorar Pontos Fortes 27 CQP Monitorar Status 28 CQP Planejar Implementação 29 CQP 30 GPP 31 CQP Realizar Análise da Inconformidade Realizar Análise das Informações e Documentos Realizar Análise de Pedido de Auditoria 32 CQP Realizar Análise Externa Criar documento que defini novos objetos de estudo para realização da melhoria iterativa dos processos empresarial. Descrever como deve ser realizado o plano contingência. Criar um documento detalhando as alterações, ressaltando o antes e o depois do processo, para ter o entendimento da satisfação do resultado obtido. Planejar um tratamento ao problema encontrado. Criar um experimento que possa simular a aplicação deste reparo, tendo como base o planejamento do reparo Definir como deve ser o ambiente do experimento para que o experimento realizado tenha um resultado em conformidade com o ambiente real. Verificar a aplicação da mudança utilizando como guia a configuração aplicada no experimento e o planejamento que descreve o modo como o experimento aconteceu. Assim, se o experimento teve resultado positivo, a implantação prática seguirá os mesmos moldes. Realizar busca para identificar a técnica mais adequada para identificar, pontos fortes, oportunidades e riscos da empresa. Descrever quais são os riscos em que empresa esta exposta e definir um paralelo de probabilidade e impacto do risco, considerando uma base de informações a respeito da empresa. Realizar uma comparação entre o produto gerado do processo real com o produto descrito na documentação deste processo. Identificar qual tipo de segurança pode ser utilizado. Definir quais medidas serão tomadas de forma reativa ao risco, descrever medidas e responsáveis pela aplicação delas. Aceitar a responsabilidade de realizar o ciclo de melhorias do projeto. Analisar a mudança proposta em relação aos riscos e probabilidade de sucesso de implantação. Analisar os fatores definidos como fortes para a empresa, verificando o motivo que os fazem fortes, verificando se existem outros fatores que podem ser somados a esse fator para fortalecer ainda mais este fator observado. Verificar constantemente a saída do processo tratado tentando verificar se existe alguma anomalia que pode somente ser observada a longo prazo. Realizar levantamento das necessidades para a implementação bem como a forma como ela será realizada. Analisar a procedência das informações recebidas realizando uma busca em documentos presentes na empresa verificando a causa da inconformidade. Reunir uma coleção de documentos referentes à empresa, buscando identificar quatro fatores a serem discutidos na reunião: pontos fracos, pontos fortes, ameaças e oportunidades. Revisar o documento de pedido de auditoria. Atividade necessária, pois, para realização auditoria pode ser necessário parar o processo envolvido para identificar o erro existente. Repassar documento a terceiros para visão externa à reunião, o revisor tem função de verificar se alguma anomalia no documento criado. 33 CQP Realizar Auditoria Verificar as causas raízes do problema encontrado. 34 CR Relatar Status Comunicar o estado do risco da empresa. 232

233 Tabela 1 - Atividades do Processo (cont.) # Etapa Atividade Descrição 35 CQP Relatar Status de Configuração 36 AA Realizar Reunião 37 CQP 38 CQP 39 GPP 40 AA 41 CQP 42 CQP 43 CR 44 CR Revisar Aprovação do Projeto Revisar Controle de Mudança Revisar Documento de Especificação do Processo Revisar Documento de Reunião Comunicar a equipe como foi configurado o ambiente de experimento e qual a função de cada um dentro do experimento. Depois da aplicação do experimento, comunicar como será realizada a implantação final do tratamento. Estabelecer quatro fatores Pontos fracos, Pontos fortes, Ameaças e Oportunidades. Identificar erros não vistos anteriormente após aplicar o reparo aprovado em forma de experimento. Verificar documento que define como será realizada a mudança e buscar verificar a existência de falhas não identificadas anteriormente. Verificar em documentos da empresa o modelo de funcionamento correto do processo. Verificar o nível de aceitação da qualidade do produto deste processo. Verificar o documento obtido a partir da reunião, verificar e corrigir erros. Buscar em todo planejamento pontos falhos não identificados no Revisar Planejamento do Projeto planejamento. Revisar Plano de Verificar o plano de iteração se existem fatores falhos não Iteração identificados. Verificar a Confiabilidade Medir a chance de sucesso da aplicação das ações corretivas. das Ações Corretivas Verificar a Confiabilidade das Ações Reativas Medir a chance de sucesso da aplicação das ações reativas. Propostas Na etapa Análise do Ambiente, o objetivo é verificar o alinhamento do trabalho da empresa com seus objetivos e se seus objetivos são cumpridos da maneira com que a empresa executa seus processos. É importante que, dentre os objetivos da empresa, contenha um objetivo que explicite a necessidade de desenvolver um produto que atenda os requisitos dos clientes, atendendo uma das definições de qualidade. Na etapa Controle de Riscos, o objetivo é agir sobre os riscos identificados na etapa Análise do Ambiente, eliminando ou reduzindo ameaças e vulnerabilidades existentes. Na etapa Gerencia do Produto dos Processos, a empresa deve ter um objetivo de trabalho definido e ter um plano de controle de riscos em vigor; assim, o objetivo passa ser a busca por inconformidades existentes durante a execução de cada um dos processos da empresa. Na etapa Controle da Qualidade do Processo, o objetivo é identificar as causas raiz de um problema encontrado em um processo identificado na etapa anterior, propor tratamento ao problema identificado, verificar e revisar tratamento, realizar experimento ao tratamento, analisar resultado de experimento, aplicar tratamento e controlar resultado. Após executar as quatro etapas do processo proposto, outras iterações podem ser realizadas para mitigar a quantidade de erros encontrados em cada processo da empresa e fortalecer e orientar o foco de trabalho. Esse processo pode auxiliar a empresa a melhorar a qualidade de seus processos de desenvolvimento de produtos. 4. Trabalhos Relacionados Em um dos trabalhos [Alet et al., 2013], foi realizada uma pesquisa fundamentada na literatura. O problema de pesquisa era identificar atributos de qualidade para otimização de métodos utilizando as etapas Definição do Problema, Concepção do Problema e Aplicação. Assim, é reforçada a necessidade de definir o problema mesmo que não acentue a necessidade de buscar causas raiz, característica de Seis Sigma. Outro fator 233

234 utilizado pelo autor é a otimização da solução, uma necessidade real para o emprego da melhor solução possível. A diferença deste trabalho é a não existência de uma ênfase na aplicação iterativa do método em que a melhoria é realizada constantemente com o objetivo de reduzir sistematicamente a variabilidade dos resultados, sendo que a melhoria iterativa é aplicada na construção do tratamento ao problema encontrado. Em outro trabalho [Martin; Raffo, 2001], é apresentado o conceito de simulação híbrida de processos, que busca resolver problemas na modificação de fatores do processo. Para isso, é utilizada estimativa estatística para definir a quantidade de modificações que a mudança no processo pode trazer. No trabalho, essa estimativa é aplicada em três fatores. Esse artigo serve como exemplo da aplicabilidade da utilização dos métodos estatísticos para mensurar e comparar resultados na área de desenvolvimento de software. A diferença deste trabalho é os resultados não serem puramente estimados, pois são primeiramente obtidos por meio de experimentação o que possivelmente aproxima mais dos valores obtidos com o valor real. Porém, durante a estatística de previsão, é utilizada para verificar se o gasto em um tratamento compensa a qualidade e o lucro obtido por esta modificação. Mesmo depois de construído o produto, necessita-se receber a melhoria da sua qualidade, em outro trabalho [Gao et al., 2011], é apresentado um processo de melhoria do produto chamado Evolução do Software. Esse processo acontece utilizando o feedback do cliente que somente pode acontecer após o uso do produto por conta do cliente. Assim, não existe evolução do produto durante a sua criação; para evoluir um produto, ele deve existir de fato. Depois que o cliente testa o produto, a empresa recebe o feedback e busca identificar requisitos para a evolução. Depois de identificar os requisitos, são enquadrados os requisitos em um modelo denominado CDPN (Colored Dual-transitions Petri Net). Nesse modelo, existe um conjunto de atributos que podem ser modificados para adequar melhor o produto ao cliente. Para realizar a modificação, é necessário utilizar contínuas iterações em diferentes partes do processo de modificação. As alterações são realizadas gradualmente e consequência de um feedback. O processo de evolução do software é necessidade de qualquer empresa desenvolvedora de software, mas existem empresas que utilizam esse processo para tratar a má qualidade dos seus produtos. Este trabalho é diferenciado por buscar a melhoria da qualidade em processos utilizando a metodologia de unificação de conceitos encontrados na literatura, objetivando a criação de um processo que pode ser aplicado a empresas desenvolvedoras de software de pequeno porte. 5. Considerações Finais Foi proposto um processo de melhoria de qualidade de processos com base em modelos, processos, padrões e normas amplamente conhecidas e aprovadas. Entendesse que esse processo pode satisfazer seu objetivo de facilitar o entendimento do modo que pode se aplicar um processo de melhoria da qualidade em empresas pequenas. Este trabalho pode cumprir o objetivo ao descrever as atividades para aplicação do processo, pois estas atividades tem origem de outros conceitos já apresentados, e por existir atividades que auxiliam na verificação da aplicabilidade da melhoria qualidade. Uma possível contribuição deste trabalho é reunir aspectos de Engenharia de Software Experimental, Seis Sigma e melhoria da qualidade de processo, não tendo identificado outro estudo anterior abordando-os em conjunto. Isso torna este trabalho 234

235 pioneiro na pesquisa e criação de um processo com a unificação desses conceitos. Quanto à limitação, existe a necessidade de aplica o processo proposto na prática, ou seja, em uma empresa. Isso impede de afirmar a sua aplicabilidade. Como trabalhos futuros, pode-se mencionar a definição de papéis e artefatos para o processo, sendo necessário realizar interpolação das responsabilidades para cada papel junto às atividades que cada papel deve executar. Além disso, podem ser definidos artefatos de entrada e saída das etapas de processo. Por fim, realizar a implantação e a avaliação do processo proposto em piloto em uma empresa. Referências Aleti, A.; Buhnova, B.; Grunske, L.; Koziolek A. Software Architecture Optimization Methods: A Systematic Literature Review. In: IEEE Transactions on Software Engineering, v.39, n.5, CMMI. Carnegie Mellon Software Engineering Institute. CMMI para Desenvolvimento versão Gao, T.; Li, T.; Xie, Z.; Xu, J.; Qian Y. A Process Model of Software Evolution Requirement Based on Feedback. In: International Conference of Information Technology, Computer Engineering and Management Sciences, Gonçalves, T. S.; Marcos, A. L. V.; Bezerra, S. R. O. Análise da Conversão de Processos de Software a partir de Modelos/Normas de Qualidade. Universidade Federal de Pernambuco Centro de Informática (UFPE), Harry, M.; Schroeder R. The Breakthrough Management Strategy Revolutionizing the World s Top Corporations. In: Concentrated Knowledg for the Busy Executive, v.22, n.11, Martin, R.; Raffo, D. A Process Model to a Software Development Project. In: The Journal of System and Software, n.59, Pfeifer, T.; Reissiger, W.; Canales, C. Integrating Six Sigma with Quality Management Systems. In: The TQM Magazine, v.16, n.4, Scartezini, L. M. B. Análise e Melhoria de Processos Scheuermann, L. Zhu. TQM Success Efforts: Use More Quantitative or Qualitative Tools? In: Industrial Management e Data Systems, v.97, n.7, Softex. Associação para Promoção da Excelência do Software Brasileiro. MPS.BR - Guia Geral MPS de Software. Disponível em: < Acessado em: 22 de novembro de Travassos, G. H.; Biolchini, J. Revisões Sistemáticas Aplicadas a Engenharia de Software. Programa de Engenharia de Sistemas e Computação Travassos, G. H.; Gurov, D.; Gurgel, E. A. A. Introdução à Engenharia de Software Experimental. Programa de Engenharia de Sistemas e Computação

236 1 Confiabilidade das estimativas de tempo e custo na atividade de teste, em projetos de software: Estudo de caso na empresa ETEG Tecnologia da Informação Raphaella Priscilla Rodrigues da Silva¹, Pedro Alves de Oliveira² ¹Sistemas de Informação Pontifícia Universidade Católica de Minas Gerais Caixa Postal Belo Horizonte MG Brazil ²Pontifícia Universidade Católica de Minas Gerais raphaella.rodrigues@sga.pucminas.br, pedroalves@pucminas.br Abstract. The lack of reliability in time and cost estimation is a classical problem of Software Engineering. This article describes a case study in the software development company ETEG Tecnologia da Informação, which analyzes the measurement of the time being spent in activities related to Software Testing. In this study we used a combination of two techniques for estimating: PERT and Planning Poker, coupled with challenges of gamification. Considering the peculiarities of each task, it was possible to conduct duration evaluations for the project activities with greater assertiveness. By using the proposed metrics, the reliability of the time measurements was increased, providing cost savings in the testing area account of the company, as we could observe in the measurements carried out in the period April to December Resumo. A falta de confiabilidade nas estimativas de tempo e custo de projetos é um problema clássico da Engenharia de Software. Este artigo descreve um estudo de caso realizado na empresa de desenvolvimento de software ETEG Tecnologia da Informação, no qual se analisa a mensuração do tempo a ser gasto nas atividades de Testes de Software. Neste estudo utilizouse uma combinação de duas técnicas de estimativa: PERT e Planning Poker, aliado a desafios de gamification. Considerando as peculiaridades de cada tarefa, tornou-se possível realizar avaliações de duração das atividades e do projeto com maior assertividade. A confiabilidade das métricas relacionadas à mensuração do tempo, a partir da associação das novas técnicas citadas, apresentou-se como fator determinante para a redução dos custos da área de testes da empresa estudada, conforme comprovado pelas medições realizadas no período de abril a dezembro de Introdução O gerenciamento do tempo num projeto de software apresenta uma importância muito além do aspecto comercial, constituindo um dos fatores diretamente responsáveis pelo sucesso do projeto como um todo. De fato, o atendimento em tempo hábil aos requisitos definidos pelo cliente depende da correta definição do tempo para o desenvolvimento 236

237 2 das atividades do projeto. Caso contrário haverá um impacto nas condições préestabelecidas pelo cliente, podendo abalar a imagem da organização contratada em seu mercado de atuação [Defeo e Araújo 2012]. Outro fator relevante para o sucesso de um projeto é a garantia de qualidade e do correto funcionamento do produto pela área de testes. Se o tempo para realização dos testes é reduzido meramente para o cumprimento do prazo de entrega acordado do produto, isto influencia negativamente na qualidade final obtida [Bastos 2007]. O gerenciamento do tempo de um projeto de software é um fator de sucesso deste, pois determina e mensura o período em que as atividades traçadas serão realizadas. Cada empresa utiliza uma forma distinta de realizar o cálculo do tempo a ser gasto em cada tarefa. Seja por base histórica ou por algum tipo de técnica de parametrização, se calculados incorretamente, esses lapsos temporais podem influenciar de maneira direta na qualidade do produto desejado pelo cliente [Pmbok 2012]. Neste artigo, realizou-se um estudo de caso na empresa ETEG Tecnologia da Informação, mais especificamente na Célula de Testes que apresentava, durante o período de abril a maio de 2013, um quadro negativo de produtividade, afetando os resultados dos projetos. Por conseguinte, atrasos na execução das atividades e dificuldades no cumprimento das metas eram situações comuns. Visando solucionar esse problema, a empresa implantou um plano de ação baseado na combinação de duas práticas de planejamento (PERT e Planning Poker) inerentes à definição da duração das atividades da célula, objetivando realizá-las no tempo estimado e sem perder a qualidade ambicionada. Com base nisso, foi realizada uma análise do cenário do setor em relação aos impactos produzidos neste, em decorrência do novo método de realização de estimativas das tarefas. Portanto, o objetivo deste artigo foi analisar as melhorias trazidas pela mudança de paradigma para estimativas de atividades ligadas à área de testes de software da empresa ETEG Tecnologia da Informação. Nas seções seguintes são abordadas as referências teóricas utilizadas como embasamento na concepção do artigo, a metodologia utilizada para a nova forma de estimativa de tarefas aplicada ao setor de testes de software da empresa ETEG e os resultados obtidos através da utilização dessa nova abordagem. 2. Estimativas de tempo em projetos Um projeto pode ser definido como um esforço temporário com a finalidade de dar origem a um determinado produto, serviço ou resultado. Assim, o gerente de projetos deve definir as estratégias, cronograma, processos, responsabilidades e prazos para o projeto, com base em áreas predefinidas, no intuito de atender às necessidades do cliente [Pmbok 2012]. As áreas de gerência de projetos descrevem práticas, entradas, saídas, ferramentas e técnicas utilizadas para se obter sucesso na gestão de um projeto. O Pmbok reconhece a existência de dez áreas de gerenciamento de projetos: Escopo, Integração, Tempo, Custos, Qualidade, Recursos Humanos, Riscos, Comunicações, Aquisições e Partes Interessadas (Stakeholders) do Projeto. Ainda que, para a gestão completa de um projeto, sejam necessárias todas as áreas descritas, este artigo se sustenta em apenas duas delas: Qualidade e Tempo [Pmbok 2012]. 237

238 3 Apesar de atrair bastante atenção das empresas atualmente, a qualidade é uma disciplina historicamente muito antiga. Um dos marcos dessa área de conhecimento foi a moderna visão da qualidade, iniciada no final dos anos 1920 [Aildefonso 2006]. Dentro dessa visão, a qualidade está diretamente relacionada à satisfação do cliente com o produto. Em relação à área de TI, problemas diagnosticados há mais de 30 anos, tais como: inobservância de cronogramas, abandono de projetos de alta complexidade, descarte de programas pelo nível de dificuldade de utilização, programas que não realizam o esperado, dentre outras dificuldades, ainda perduram [Kocianski e Soares 2006]. O processo de qualidade é estruturado levando-se em consideração três fatores: oportunidade, custo e completude (planejamento de atividades voltadas à detecção de falhas). Estas propriedades são avaliadas durante todo o ciclo de vida do projeto e podem afetar diversas áreas de conhecimento que compõem este planejamento. Diversas atividades são consideradas pertinentes em relação à garantia da qualidade e podem intercalar-se com as atividades praticadas pela equipe de desenvolvimento de software. Nesse cenário, merece destaque a área de teste de software [Pezzè e Young 2008]. A área de teste de software é responsável pela análise e avaliação da conformidade dos requisitos requeridos pelo cliente em relação ao sistema desenvolvido. Esta similaridade é analisada a partir de estratégias que buscam uma combinação adequada entre as despesas planejadas e a qualidade esperada pelo cliente, sem ultrapassar os custos estabelecidos. Antes mal vista e ignorada pelas empresas de TI, esta área é agora um dos setores mais importantes dentro do ciclo de vida de um projeto. Tomando por base esta conjuntura e levando em consideração que esta prática é uma das mais caras dentro da proposta do projeto, o tempo para realização das atividades pode influenciar positiva ou negativamente, no tempo do projeto e nas demais variáveis que compõem o triângulo das restrições - tempo, custo e qualidade [Bastos 2007] [Monteiro 2008]. A gestão do tempo do projeto oferece métodos visando ao equilíbrio das demais variáveis que compreendem o triângulo das restrições de um projeto. Para tal, é necessário definir as atividades específicas do cronograma, identificar suas dependências, estimar os recursos para realização do projeto, contabilizar o número de períodos de trabalho gastos e desenvolver e controlar o cronograma [Pmbok 2012]. As atividades definidas no cronograma necessitam de estimativas precisas, fundamentando-se na quantidade de horas planejadas do projeto para o êxito de sua realização. Assim, quanto mais próximo da realidade estiver o tempo estabelecido para a realização destas atividades, menor será a divergência na entrega do produto dentro do prazo acordado com o cliente [Pmbok 2012]. Sendo o tempo uma variável tão relevante num projeto, existem diferentes técnicas e métodos que auxiliam na realização das estimativas de duração de tarefas. Este artigo baseia-se em dois métodos de estimativa: PERT e Planning Poker. Program Evaluation and Review Technique (PERT) é uma técnica criada na década de 1950, a partir da observação de um padrão de comportamento das atividades. A técnica estima o tempo de execução das tarefas baseado nas suas durações otimista, pessimista e mais provável. O PERT oferece algumas vantagens na mensuração dos prazos, num projeto de software [Moura 2013], tais como: avaliar a incerteza associada à atividade e ao projeto, permitir maior envolvimento da equipe ao incentivar cada um de seus membros a compreender melhor a atividade e a compartilhar as informações, 238

239 4 reduzir o incentivo para inflacionar as estimativas, reduzir a influência que os padrões de otimismo e pessimismo têm sobre a estimativa. Planning Poker é uma técnica de estimativa em equipe, que pode ser aplicada na forma de um jogo. Nesse jogo, os membros da equipe recebem um conjunto de cartas com uma sequência numérica (geralmente utiliza-se a sequência de Fibonacci). Munidos de cartas de baralho, de acordo com o grau de dificuldade dos itens a serem estimados, cada membro seleciona uma carta com o valor que melhor representa o tempo a ser gasto na execução dessa atividade. Após selecionarem suas cartas, estas são exibidas ao mesmo tempo. Caso haja alguma discrepância nos tempos apresentados, busca-se o consenso geral entre os membros, visando determinar o tempo que será considerado para a realização da tarefa em questão [Pereira, Torreão e Marçal 2007]. Outro método que pode ser relacionado à gestão do tempo de um projeto é o gamification. Essa estratégia corresponde ao uso de mecanismos guiados a resolver problemas práticos ou despertar engajamento entre um público específico. Tem sido utilizado em projetos com o objetivo de estimular as pessoas a participarem, rompendo a relação fria em processos de abordagem tradicional [Vianna et al 2013]. 3. Estudo de Caso A ETEG Tecnologia da Informação é uma empresa da área de TI que desenvolve sistemas sob demanda há mais de 12 anos. A organização procura uma prática equilibrada baseada na adoção de estimativas confiáveis, cujo foco é a entrega de um software de qualidade aos seus clientes. Fundada em 2001, no contexto do programa de incubação da Sociedade Mineira de Software (Fumsoft) por três estudantes de ciência da computação, a empresa conta atualmente com mais de 80 colaboradores. A ETEG entrou, em 2012, para a lista das pequenas empresas que mais crescem no Brasil, de acordo com estudo da Deloitte e da revista Exame PME. Em 2013, a empresa criou o programa RELAX um jogo em estilo de equipes com colaboração entre elas baseado na técnica de gamification, no intuito de experimentar alguns conceitos de benefícios obtidos mediante resultados alcançados a partir da definição de metas para cada um dos setores da empresa (Figura 1). Figura 1. Alvo de metas das equipes no programa Relax Fonte: Dados da pesquisa. 239

240 5 A partir da atualização semanal do quadro em formato de alvo, pendurado em local visível dentro da empresa, os colaboradores envolvidos acompanhavam a aproximação de suas equipes do centro do alvo, que representava o ganho de dois dias de folga adicionais no final do ano. Visando aumentar a sua produtividade, melhorar a disseminação de informações e gerar um espírito colaborativo entre os seus funcionários, o programa proporcionou recuperação de receita e lucros de projetos e contribuiu no espírito motivacional na realização das tarefas [Paiva 2013]. Tal cenário, analisado neste trabalho, mostra uma empresa que, apesar de possuir um processo bem definido, possuía dificuldades com estimativas de atividades a serem realizadas na área de testes da ETEG. 4. Metodologia A célula de testes detém a responsabilidade de determinadas funções referentes ao ciclo de vida de um projeto de software, conforme apresentado no diagrama de atividades a seguir (Figura 2): Figura 2. Diagrama de Atividades Célula de Testes. Fonte: Elaborado pela autora. As atividades da Célula de Testes eram estimadas tomando por base o tempo a ser gasto pela pessoa mais experiente do setor, neste caso, o gerente. Em consequência, 240

241 6 levando em consideração a recente contratação de novos profissionais, o tempo gasto nas tarefas era muito maior do que o tempo pré-definido para a realização destas. Além de ultrapassar o prazo mensurado para realização das atividades, os custos para o projeto eram superiores aos acordados junto ao cliente. Com o intuito de superar as dificuldades enfrentadas pela área de testes da empresa, foi definida uma nova maneira de estimar o tempo a ser gasto em cada uma das atividades inerentes ao setor. Esta nova abordagem baseia-se na junção das técnicas de Planning Poker e PERT. Com base nesta nova abordagem, a equipe de testes formada foi composta por sete membros, sendo: quatro estagiários (recentemente contratados), dois analistas e a gerente do setor. Eles passaram a participar em conjunto na definição do tempo a ser gasto em cada uma das atividades pertinentes ao setor. Assim, a estimativa passou a ficar mais próxima da realidade, independente de quem realize as atividades. Munidos de um baralho adaptado às necessidades da área de testes, os membros do setor realizavam as estimativas das atividades jogando as cartas para os casos mais provável, otimista e pessimista, de acordo com o grau de dificuldade da tarefa. Os valores obtidos são organizados em uma planilha do Excel que, a partir dos dados informados, realiza o cálculo do valor estimado para cada uma das atividades, de um determinado requisito, colocadas em votação. SISTEMAS ALFA BETA CARTEIRA DE PROJETOS Abril a Dezembro de 2013 ITERAÇÕES TEMPO DE TESTES em Horas QTDE NOME 1 Iteração ALFA I 191,95 2 Iteração ALFA II 323,57 3 Iteração ALFA III 262,02 4 Iteração ALFA IV 30,03 5 Iteração ALFA V 91,15 1 Iteração BETA I 104,85 2 Iteração BETA II 55,33 DELTA 1 Iteração DELTA I 205,6 1 Iteração GAMA I 80,68 GAMA 2 Iteração GAMA II 111,62 QUEBEC YANKEE 2 Iteração QUEBEC I 102,27 3 Iteração QUEBEC II 240,03 4 Iteração QUEBEC III 75,28 5 Iteração QUEBEC IV 32,07 1 Iteração YANKEE I 88,18 2 Iteração YANKEE II 94,93 3 Iteração YANKEE III 101,73 4 Iteração YANKEE IV 45,32 Tabela 1. Projetos submetidos à célula de testes Fonte: Dados da Pesquisa Nesse novo contexto, o levantamento quantitativo dos elementos para a presente análise baseou-se no método estatístico, utilizando a coleta e organização dos dados de 241

242 7 cada uma das atividades pertinentes à área de testes em determinadas iterações de alguns sistemas (Tabela 1). Os nomes utilizados para designar os projetos, assim como as iterações, são fictícios, visando garantir o sigilo empresarial. Durante o período de coleta e observação dos dados apresentados nesta análise, realizaram-se testes funcionais do tipo caixa preta, retestes de bugs e descrição de casos de teste na célula de testes (localizada dentro da sede da empresa em estudo) nos sistemas descritos na Tabela 1. Ao mesmo tempo, o programa RELAX proporcionou o engajamento dos membros da equipe na realização das atividades dentro do tempo estimado e, consequentemente, a redução dos custos do setor, aumentando a motivação na realização das tarefas. A partir dos testes concebidos nas iterações apresentadas (Tabela 1) e da contribuição promovida pelo programa RELAX, foram coletados valores quantitativos que fundamentam a análise realizada neste artigo. 5. Resultados Nesta seção, são analisados os resultados obtidos nas medições realizadas na empresa em estudo, conforme descrito na metodologia. Tomaram-se por base os valores observados e coletados durante o período de abril a dezembro de 2013 o mês de Junho não foi considerado na análise, pois foi o período em que realizou-se a mudança de paradigma para as estimativas de tarefas. No período analisado foi possível constatar uma redução significativa de tempo e de custo na realização das atividades de teste (Tabela2, Tabela 3). Tabela 2. Variação do tempo antes e após as estimativas em grupo (abr. a dez. 2013). Fonte: dados da pesquisa. 242