Anais. WTDSoft Congresso Brasileiro de Software: Teoria e Prática 28 de setembro a 03 de outubro de 2014 Maceió/AL

Transcrição

1 Congresso Brasileiro de Software: Teoria e Prática 28 de setembro a 03 de outubro de 2014 Maceió/AL IV WORKSHOP DE TESES E DISSERTAÇÕES DO CBSOFT WTDSoft 2014 Anais

2 Anais Volume 02 ISSN WTDSoft 2014 IV WORKSHOP DE TESES E DISSERTAÇÕES DO CBSOFT COORDENADOR DO COMITÊ DE PROGRAMA Eduardo Santana de Almeida - Universidade Federal da Bahia (UFBA) COORDENAÇÃO DO CBSOFT 2014 Baldoino Fonseca - Universidade Federal de Alagoas (UFAL) Leandro Dias da Silva - Universidade Federal de Alagoas (UFAL) Márcio Ribeiro - Universidade Federal de Alagoas (UFAL) REALIZAÇÃO Universidade Federal de Alagoas (UFAL) Instituto de Computação (IC/UFAL) PROMOÇÃO Sociedade Brasileira de Computação (SBC) PATROCÍNIO CAPES, CNPq, INES, Google APOIO Instituto Federal de Alagoas, Aloo Telecom, Springer, Secretaria de Estado do Turismo AL, Maceió Convention & Visitors Bureau, Centro Universitário CESMAC e Mix Cópia 2

3 PROCEEDINGS Volume 02 ISSN WTDSoft 2014 IV WORKSHOP DE TESES E DISSERTAÇÕES DO CBSOFT PROGRAM CHAIR Eduardo Santana de Almeida - Universidade Federal da Bahia (UFBA) CBSOFT 2014 GENERAL CHAIRS Baldoino Fonseca - Universidade Federal de Alagoas (UFAL) Leandro Dias da Silva - Universidade Federal de Alagoas (UFAL) Márcio Ribeiro - Universidade Federal de Alagoas (UFAL) ORGANIZATION Universidade Federal de Alagoas (UFAL) Instituto de Computação (IC/UFAL) PROMOTION Sociedade Brasileira de Computação (SBC) SPONSORS CAPES, CNPq, INES, Google SUPPORT Instituto Federal de Alagoas, Aloo Telecom, Springer, Secretaria de Estado do Turismo - AL, Maceió Convention & Visitors Bureau, Centro Universitário CESMAC and Mix Cópia 3

4 Autorizo a reprodução parcial ou total desta obra, para fins acadêmicos, desde que citada a fonte 4

5 Apresentação É com grande satisfação que, em nome do Comitê de Programa e da Comissão Organizadora, saudamos os participantes do IV Workshop de Teses e Dissertações do CBSoft (WTDSoft 2014). O WTDSoft é um evento promovido anualmente pelo CBSoft e este ano conta com uma série de artigos referentes a trabalhos de mestrado e doutorado na área. Foram submetidos 39 artigos ao WTDSoft, dos quais foram selecionados 18 para apresentação durante o evento e publicação em seus anais. O processo de avaliação garantiu que cada artigo tivesse três avaliações, sendo também utilizada uma fase de discussão para minimizar discrepâncias nas avaliações. Gostaríamos de agradecer a todos que contribuíram para a realização deste evento. A qualidade deste programa é resultado da dedicação dos membros do Comitê de Programa e avaliadores. Somos também, imensamente gratos aos professores convidados, aos participantes e todos os autores pelos trabalhos submetidos. Finalmente, desejamos a todos um excelente evento! Salvador, Setembro de Eduardo Santana de Almeida Coordenador do WTDSoft 5

6 Comitês Técnicos / Program Committee Comitê do programa / Program Committee Adolfo Duran - Universidade Federal da Bahia (UFBA) Alessandro Garcia - Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) Alexandre Alvaro - Universidade Federal de São Carlos (UFSCar) Auri Marcelo Rizzo Vincenzi - Universidade Federal de Goiás (UFG) Christina Chavez - Universidade Federal da Bahia (UFBA) Dalton Serey - Universidade Federal de Campina Grande (UFCG) Daniel Lucrédio - (Universidade Federal de São Carlos (UFSCar) Eduardo Figueiredo - Universidade Federal de Minas Gerais (UFMG) Elisa Yumi Nakagawa - Universidade de São Paulo (USP) Fernando Quintao Pereira - Universidade Federal de Minas Gerais (UFMG) Francisco Carvalho-Junior - Universidade Federal do Ceará (UFC) Genaina Rodrigues - Universidade de Brasília (UnB) Gledson Elias - Universidade Federal da Paraíba (UFPB) Ivonei Freitas da Silva - Universidade Estadual do Oeste do Paraná (Unioeste) Leila Ribeiro - Universidade Federal do Rio Grande do Sul (UFRS) Leila Silva - Universidade Federal de Sergipe (UFS) Leonardo Murta - Universidade Federal Fluminense (UFF) Martin Musicante - Universidade Federal do Rio Grande do Norte (UFRN) Patricia Machado - Universidade Federal de Campina Grande (UFCG) Raul Wazlawick - Universidade Federal de Santa Catarina (UFSC) Rita Suzana Maciel - Universidade Federal da Bahia (UFBA) Roberta Coelho - Universidade Federal do Rio Grande do Norte (UFRN) Rodrigo Bonifacio - Universidade de Brasília (UnB) Rodrigo Reis - Universidade Federal do Paraná (UFPR) Rohit Gheyi - Universidade Federal de Campina Grande (UFCG) Rosângela Penteado - Universidade Federal de São Carlos (UFSCar) Silvia Vergilio - Universidade Federal do Paraná (UFPR) Tayana Conte - Universidade Federal do Amazonas (UFAM) Thais Vasconcelos Batista - Universidade Federal do Rio Grande do Norte (UFRN) Toacy Oliveira - Universidade Federal do Rio de Janeiro (UFRJ) Uirá Kulesza - Universidade Federal do Rio Grande do Norte (UFRN) Vander Alves - Universidade de Brasília (UnB) Vinicius Cardoso Garcia - Universidade Federal de Pernambuco (UFPE) 6

7 Comitê organizador / Organizing Committee COORDENAÇÃO GERAL Baldoino Fonseca - Universidade Federal de Alagoas (UFAL) Leandro Dias da Silva - Universidade Federal de Alagoas (UFAL) Márcio Ribeiro - Universidade Federal de Alagoas (UFAL) COMITÊ LOCAL Adilson Santos - Centro Universitário Cesmac (CESMAC) Elvys Soares - Instituto Federal de Alagoas (IFAL) Francisco Dalton Barbosa Dias - Universidade Federal de Alagoas (UFAL) COORDENADOR DO WTDSoft 2014 Eduardo Santana de Almeida - Universidade Federal da Bahia (UFBA) 7

8 Índice / Table of Contents Mestrado / MSc Uma Abordagem para Checagem de Conformidade Arquitetural na Modernização Apoiada por Modelos Fernando Chagas, Valter Vieira de Camargo Uma Abordagem Baseada em Padrões para Interoperação de Especificações de Workflows Científicos Bruno Fernandes Bastos, Regina Maria Maciel Braga, Antônio Tadeu Azevedo Gomes Adaptação dos critérios de teste de programas concorrentes para o teste de integração de robôs móveis Marcos Pereira dos Santos, Simone do Rocio Senger de Souza Avaliação de Arquiteturas Recuperadas com base em Métodos de Avaliação Precoce Mateus Passos Soares Cardoso, Christina von Flach G. Chavez, Crescencio Lima Um estudo comparativo sobre sínteses de estudos de métodos mistos na Engenharia de Software Danilo Monteiro Ribeiro, Fábio Queda Bueno da Silva, Cesar França EvolTrack-Process: Uma ferramenta para visualização e acompanhamento da colaboração em processos de software Francisco Werther Silva de Santana Júnior, Cláudia Maria Lima Werner, Andréa Magalhães Magdaleno Execução Paralela de Programas como suporte ao teste de mutação Stevão Alves de Andrade, Márcio Eduardo Delamaro Um estudo sobre geração de testes com BETA: Avaliação e aperfeiçoamento João Batista de Souza Neto, Anamaria Martins Moreira O Impacto dos Fatores Humanos em Metodologias Ágeis Aline Chagas Rodrigues Marques, Alexandre Marcos Lins de Vasconcelos, Célio Andrade de Santana Júnior Um Método de Extração de Valores Referência para Métricas de Softwares Orientados por Objetos Tarcísio G. S. Filó, Mariza A. S. Bigonha, Kecia Aline Marques Ferreira

9 Um Modelo Conceitual para Caracterização da Qualidade Interna de Sistemas de Software Open-Source Orientados a Objeto gestão de projetos Mariana Santos, Paulo Bermejo, Heitor Costa Análise da Qualidade de Experimentos da Computação em Nuvem Helaine Solange Lins, Vinicius Cardoso Garcia, Sérgio Castelo Branco Soares Doutorado / PhD Definição de um Framework para Avaliação Sistemática de Técnicas de Teste no Contexto de Programação Concorrente Silvana Morita Melo, Simone do Rocio Senger de Souza Integração de Práticas Ágeis: Uma abordagem para melhorar a qualidade de especificações de software em projetos mobile Juliana Dantas Ribeiro Viana de Medeiros, Alexandre Marcos Lins de Vasconcelos, Carla Taciana Lima Lourenco Silva Schuenemann Alocação de Participantes no Merge de Ramos Catarina de Souza Costa, Leonardo Gresta Paulino Murta A Meta-Process Oriented to Software Product Quality Based on ISO/IEC and Compliant with CMMI-DEV and MR-MPS-SW Models Carlos dos Santos Portela, Alexandre Marcos Lins de Vasconcelos, Sandro Ronaldo Bezerra Oliveira, Marco Paulo Amorim Vieira Search-Based Mutation Testing para Programas Concorrentes Rodolfo Adamshuk Silva, Simone do Rocio Senger de Souza Constructing a Theory of Agile Governance: a step towards Business Agility Alexandre J. H. de O. Luna, Philippe Kruchten, Hermano Moura

10 Uma Abordagem para Checagem de Conformidade Arquitetural na Modernização Apoiada por Modelos Aluno: Fernando Chagas 1 Orientador: Valter Vieira de Camargo 1 1 Programa de Pós-Graduação em Ciência da Computação Departamento de Computação Universidade Federal de São Carlos (UFSCar) Caixa Postal São Carlos SP Brazil fernando.chagas@dc.ufscar.br, valter@dc.ufscar.br Resumo. Em geral, a arquitetura de sistemas legados apresenta inconsistências em relação à arquitetura de referência. Uma alternativa para isso é conduzir uma modernização apoiada por modelos (Architecture-Driven Modernization - ADM), que é um processo proposto pela OMG com o objetivo de reestruturar sistemas existentes com base em metamodelos padrão ISO. O principal metamodelo da ADM é o KDM, que objetiva representar um sistema legado em vários níveis de abstração, inclusive o arquitetural. Entretanto, apesar da ADM fornecer todos os conceitos para a condução de modernizações, não foram encontradas propostas para Checagem de Conformidade Arquitetural (CCA). Embora existam várias propostas que atuam em nível de código-fonte, o mesmo não ocorre em nível de modelos, como o KDM. Portanto, deverá ser desenvolvida uma abordagem e uma ferramenta para apoiar a CCA no contexto da ADM. Objetiva-se comparar falsos positivos e negativos da CCA baseada em modelos com abordagens tradicionais e também investigar cenários em que esse tipo de checagem apresenta benefícios. Nível: Mestrado Ano de Ingresso: 2013 Época prevista de conclusão: 04/2015 Data de aprovação da proposta de dissertação: 25/04/2014 Evento Relacionado: SBES Palavras-chave: arquitetura de software, checagem de conformidade arquitetural, adm, kdm 10

11 1. Caracterização do Problema Modificações tardias na fase de implementação e conflitos nos requisitos de qualidade resultam na incompatibilidade entre arquitetura planejada e implementada. Como alternativa para verificação dessas inconsistências, surgiu a Checagem de Corformidade Arquitetural (CCA), que é uma técnica que preenche a ponte entre os modelos de alto nível do projeto arquitetural e código-fonte [Knodel and Popescu 2007]. A Modernização Apoiada por Modelos (ADM) [OMG 2003], defende a realização do processo de modernização considerando os princípios do desenvolvimento dirigido a modelos. A ADM define vários metamodelos para auxiliarem nas modernizações, dentre eles o Knowledge Discovery Metamodel (KDM), que torna possível a recuperação dos artefatos de software por meio de técnicas de engenharia reversa, em diferentes níveis de abstração [Perez-Castillo et al. 2011]. Um pacote importante do KDM no contexto deste trabalho é o de Estrutura (Structure), que permite representar elementos arquiteturais de um sistema. Vários grupos de pesquisa tem atuado na linha de checagem de conformidade, propondo diferentes técnicas ([Rahimi and Khosravi 2010], [Maffort et al. 2013], [Deiters et al. 2009], [Terra and Valente 2009], [Bittencourt et al. 2010]). No entanto, nenhum desses trabalhos apresenta um estudo sobre a viabilidade de realização da CCA no contexto da ADM. Outro fator importante, é verificar a qualidade do KDM em representar conceitos arquiteturais, já que não foi encontrado nenhum trabalho voltado para a camada de abstrações do KDM, que é responsável por representar o sistema legado em alto nível. Portanto, uma CCA no contexto da ADM, mais especificamente no metamodelo KDM, se torna uma boa alternativa para a verificação de desvios arquiteturais. É importante ressaltar que o KDM é padrão ISO e pouco estudado até o momento desta pesquisa, fator importante para a motivação deste trabalho, pois não foram encontradas abordagens que realizem modernizações por meio de padrões, o que impacta na dificuldade de reuso, portabilidade e interoperabilidade de aplicações. Deste modo, o objetivo desta pesquisa é criar uma abordagem para a CCA no contexto da ADM. Assim, pretende-se apontar as vantagens e desvantagens de se utilizar esse metamodelo para realizar tal checagem e se necessário, indicar modificações no KDM no sentido de permitir uma checagem de conformidade mais adequada. 2. Fundamentação Teórica Knodel e Popescu (2007) descrevem a CCA como uma atividade chave para o controle de qualidade de software. O objetivo é revelar diferenças entre a arquitetura planejada e a atual do sistema. Uma atividade importante dentro da CCA é averiguar as restrições entre elementos arquiteturais, para isso, Terra e Valente (2009) propuseram uma linguagem de domínio específico. Na abordagem, é possível restringir dependências originadas a partir do acesso a atributos e métodos, declaração de variáveis, criação de objetos, extensão de classes, implementação de interfaces, ativação de exceções e uso de anotações. Uma maneira de conduzir processos de reengenharia é por meio da Modernização Apoiada por Modelos (ADM), que facilita a formalização de transformações por meio de princípios de desenvolvimento dirigido a modelos. Um dos metamodelos especificados pela ADM, O KDM, é fragmentado em quatro camadas correspondentes aos artefatos físicos e lógicos e é capaz de representar todo o sistema [Perez-Castillo et al. 2011]. Neste trabalho serão investigados interesses relacionados a CCA em KDM, por- 11

12 tanto, o pacote Structure se torna importante para o desenvolvimento deste projeto. O pacote Structure define elementos de metamodelo que representam componentes de arquitetura de sistemas de software existentes, tais como subsistemas, camadas, pacotes, etc. Na Figura 1 é apresentado o diagrama de classes do pacote Structure. Figura 1. Pacote StructureModel da Camada de Abstração no KDM A classe StructureModel representa uma agregação de elementos arquiteturais, como subsistemas, componentes, camadas, sistemas e visões arquiteturais. Note-se também que o auto relacionamento existente na classe AbstractStructureModel denota a possibilidade desses elementos serem compostos por outros elementos subordinados. A classe KDMEntity representa uma entidade de baixo nível do KDM, como classes, pacotes, métodos, etc. Os relacionamentos são representados por uma classe concreta filha de AbstractStructureRelationship. Os relacionamentos representados pela classe StructureRelationship possuem dois atributos, que é o elemento arquitetural de origem e o de destino, que caracterizam a relação. 3. Caracterização da Contribuição Na Figura 2 são apresentados os passos esperados da abordagem proposta. No passo A, o engenheiro de software precisa fornecer uma especificação da arquitetura planejada que deve conter os elementos arquiteturais e as regras de restrição de acesso entre eles. Os elementos arquiteturais serão descritos de acordo com os elementos presentes no pacote Structure do KDM, isto é, camadas, componentes, etc. As regras regulam os relacionamentos permitidos ou não entre os elementos. Até o momento, pretende-se utilizar as regras de acesso propostas por Terra e Valente [2009]. O formato dessas regras não foi definido ainda, entretanto, acredita-se que elas podem ser representadas por meio dos relacionamentos existentes no pacote Structure do KDM. A saída desse passo é a arquitetura planejada representada na forma de uma instância do pacote Structure do KDM. Figura 2. Passos da abordagem proposta 12

13 No passo B deve ser obtido um panorama atual do sistema legado, aqui, deverá ser utilizada uma ferramenta chamada MoDisco 1, que será responsável por extrair as informações do sistema e representar por meio de uma instância do metamodelo KDM. No passo C o engenheiro de software deve criar um artefato de mapeamento que relaciona os elementos arquiteturais presentes na arquitetura planejada com elementos de código-fonte presentes na instância do KDM legado. A criação desse artefato deverá possuir apoio ferramental para facilitar a visualização e a criação dos relacionamentos. Por exemplo, pode ser que três pacotes (java packages) existentes no KDM legado representem a camada de modelo existente na arquitetura. Ao final desse passo, o KDM legado deverá ser transformado no sentido de incluir uma instância do pacote Structure contendo uma visão arquitetural ainda sem os relacionamentos entre seus elementos. No passo D, o objetivo é gerar um KDM em que o pacote Structure represente a arquitetura atual, contendo todos os relacionamentos existentes entre seus elementos. Para isso, um algoritmo deverá analisar o KDM modificado para identificar todos os relacionamentos existentes entre elementos de mais baixo nível (classes, interfaces, métodos) e criar relacionamentos de mais alto nível entre os elementos arquiteturais. Vislumbra-se a possibilidade de definir tipos mais específicos de relacionamentos entre os elementos arquiteturais de forma a identificar chamada de métodos, acesso a variáveis, implementação de interfaces, etc [Terra and Valente 2009]. Os passos C e D estão sendo planejados de forma separada para permitir que o engenheiro de software possa modificar o mapeamento fornecido caso ele tenha informado erroneamente alguma relação. Isso evita que a tarefa de geração da arquitetura atual (passo D) seja feita repetidas vezes em caso de erros de mapeamento, já que o passo D demanda uma quantidade significativa de processamento. Por fim, no passo E será feita a checagem de conformidade, para isso, as representações da arquitetura deverão ser comparadas. Como saída, espera-se que sejam apontados indícios de desvios arquiteturais, que são as diferenças encontradas entre as representações fornecidas. O resultado da checagem será fornecido por meio de um arquivo de texto simples que aponta as oportunidades ou por anotações na instância do KDM. Note-se que neste projeto optamos por gerar uma representação da arquitetura atual por meio do passo D. Isso deverá facilitar a comparação com a arquitetura planejada, já que as duas representações estarão no mesmo nível de abstração. Outra alternativa poderia ser não gerar a arquitetura atual e realizar as comparações entre os elementos de baixo nível e a arquitetura planejada. Assim sendo, o principal objetivo neste projeto é desenvolver uma abordagem de CCA usando o metamodelo KDM fornecido pela ADM. Outra contribuição será desenvolver uma técnica de conversão do pacote code/kdm para o pacote structure/kdm, pois atualmente nenhuma ferramenta dá suporte para a representação de informações estruturais do sistema. Também será investigado a adequabilidade do metamodelo KDM para realização de CCA. Por fim, serão caracterizados cenários em que a checagem de conformidade apoiada por modelos é mais viável do que em código-fonte. 4. Estado Atual do Trabalho Até o momento foi feito um estudo do metamodelo KDM e de técnicas de ACC. Foram verificadas maneiras de representar as regras de acesso entre elementos arquiteturais, e

14 dentre os trabalhos estudados, as regras definidas por Terra e Valente (2009) foram escolhidas como base e deverão ser consideradas neste trabalho. Foram criadas três instâncias KDM representando sistemas com diferentes características arquiteturais (MVC, Tubos e Filtros e Camadas). Esses sistemas foram modificados e desvios arquiteturais foram inseridos propositalmente para que fosse feita uma investigação sobre como os desvios arquiteturais são representados no KDM. Na Figura 3 é mostrado um exemplo de desvio arquitetural inserido em um sistema. Figura 3. Exemplo de chamada ilegal A classe SellCar (Figura 3a) pertence a camada de visão do sistema e é representa informações manipuladas na classe CarController, da camada de controle, que por sua vez utiliza a classe Car (camada modelo) para realizar operações de controle. Qualquer outro tipo de relação entre estas camadas não é permitido, porém, são feitos acessos da classe SellCar a classe Car, correspondendo a um indicio de desvio arquitetural. Para que esse indicio seja encontrado, consideramos a recuperação da arquitetura atual, na qual todas as relações são apresentadas no pacote Structure do KDM (Figura 3b). A arquitetura planejada é definida pelo engenheiro de software e representada no mesmo nível de abstração que a atual (Figura 3c). Dessa maneira, as duas representações são comparadas e verificadas as diferenças, que são possíveis indícios de desvios arquiteturais. Foi realizada uma investigação em que foi averiguada se a metaclasse AggregatedRelationship, do KDM, poderia ser utilizada para representar regras arquiteturais. Ao que tudo indica, com o uso de estereótipos (Stereotype), essa metaclasse pode ser uma possível alternativa para a especificação das regras de acesso a elementos arquiteturais. Os estereótipos deverão representar cada tipo de relação existente de acordo com os tipos de restrições entre elementos arquiteturais definidos por Terra e Valente (2009). 5. Trabalhos relacionados Maffort entre outros (2013) apresentam heurísticas para descoberta de violações arquiteturais. A entrada da ferramenta proposta possui uma especificação dos componentes em alto nível e o histórico de revisões do sistema. Ela identifica dependências suspeitas em código-fonte, baseando-se em hipóteses de frequência e correções feitas no passado nessas dependências. Deiters entre outros (2009) propõem uma abordagem para ACC baseada em regras. A descrição arquitetural é representada em fatos e regras lógicas. Os fatos representam os elementos existentes arquiteturais, as regras definem as restrições. A CCA é realizada executando as regras arquiteturais como queries sobre a união das bases de conhecimento. Rahimi e Khosravi (2010) apresentam uma abordagem capaz de realizar CCA entre múltiplas linguagens de programação. A abordagem é dividida em duas 14

15 etapas, primeiro são criados transformadores de código-fonte em modelos de alto nível e em seguida as linguagens são comparadas em um mesmo nível de abstração. Maffort entre outros (2013) destaca a realização da CCA por meio da análise estática e histórica de código-fonte, enquanto que a abordagem aqui proposta objetiva realizar análise estática em modelos. Deiters entre outros (2010) se aproxima da proposta deste trabalho por demonstrar o uso de regras de relação de conformidade para realização da CCA, neste projeto, foi escolhida utilizar regras que sejam aplicadas no contexto da ADM. Rahimi e Khosravi (2010) não trabalham com padrões para a realização da CCA enquanto que uma das motivações da nossa abordagem é utilizar o KDM, que é padrão ISO. 6. Avaliação dos Resultados Para a avaliação do trabalho proposto, serão realizados estudos experimentais que tem como objetivo investigar a adequabilidade de se realizar CCA arquitetural usando o metamodelo KDM. Mais especificamente, pretende-se i) apontar as vantagens e desvantagens de se utilizar esse metamodelo para realizar tal checagem e ii) se necessário, indicar modificações no KDM no sentido de permitir uma checagem de conformidade mais adequada. Também será avaliada se a atividade de checagem no KDM é capaz de ser considerada ótima, essa análise será feita por meio da contagem de falsos positivos e negativos, em que a ausência deles contempla uma boa atividade de verificação. Referências Bittencourt, R., Jansen de Souza Santos, G., Guerrero, D., and Murphy, G. (2010). Improving automated mapping in reflexion models using information retrieval techniques. In Reverse Engineering (WCRE), th Working Conference on, pages Deiters, C., Dohrmann, P., Herold, S., and Rausch, A. (2009). Rule-based architectural compliance checks for enterprise architecture management. In Enterprise Distributed Object Computing Conference, EDOC 09. IEEE International, pages Knodel, J. and Popescu, D. (2007). A comparison of static architecture compliance checking approaches. In Software Architecture, WICSA 07. The Working IEEE/IFIP Conference on, pages Maffort, C., Valente, M., Bigonha, M., Anquetil, N., and Hora, A. (2013). Heuristics for discovering architectural violations. In Reverse Engineering (WCRE), th Working Conference on, pages OMG (2003). Model Driven Architecture (MDA) Guide. OMG doc. ab/ Perez-Castillo, R., De Guzman, I.-R., and Piattini, M. (2011). Knowledge discovery metamodel-iso/iec 19506: A standard to modernize legacy systems. Computer Standards and Interfaces, 33(6): Rahimi, R. and Khosravi, R. (2010). Architecture conformance checking of multilanguage applications. In Computer Systems and Applications (AICCSA), 2010 IEEE/ACS International Conference on, pages 1 8. Terra, R. and Valente, M. T. (2009). A dependency constraint language to manage objectoriented software architectures. Softw. Pract. Exper., 39(12):

16 Uma Abordagem Baseada em Padrões para Interoperação de Especificações de Workflows Científicos Bruno Fernandes Bastos¹,² Orientadores Regina Maria Maciel Braga¹ Antônio Tadeu Azevedo Gomes² 1 Universidade Federal de Juiz de Fora (UFJF) 2 Laboratório Nacional de Computação Científica (LNCC) Mestrado Programa de Pós-Graduação em Ciência da Computação UFJF Ano de ingresso: 2013 Época prevista de conclusão: 2015 Resumo. Workflows científicos vêm sendo utilizados para resolver problemas complexos em diferentes áreas, utilizando diferentes recursos computacionais. Sistemas Gerenciadores de Workflows Científicos (SGWfCs) são utilizados para a construção desses workflows, porém, cada SGWfC possui características particulares e uma linguagem de especificação de workflows própria, dificultando seu reuso. O uso de uma linguagem específica para interoperação de workflows científicos traz ganhos para o reuso de workflows desenvolvidos em diferentes SGWfCs, porém, não impede que haja perda de informação semântica durante um processo de transformação de especificações entre esses SGWfCs. A existência de padrões de workflows científicos pode ajudar a explicitar as informações semânticas mais importantes para a construção desses workflows. A proposta desse trabalho é oferecer uma abordagem baseada em padrões para a interoperação de workflows científicos, empregando uma linguagem extensível com suporte a informações semânticas obtidas através da descrição dos padrões. Palavras-chave: Workflows Científicos, Interoperação, Padrões em Workflows Científicos Eventos relacionados: SBES, SBCARS 16

17 1. Caracterização do Problema Workflows científicos vêm sendo utilizados para resolver problemas complexos em diversas áreas. Para a modelagem e controle da execução desses workflows, vários Sistemas Gerenciadores de Workflows Científicos (SGWfCs) foram criados. Cada SGWfC possui funcionalidades específicas e linguagem própria para especificação dos workflows, muitas vezes enfocando uma área particular. Neste contexto, o reuso de workflows científicos especificados em diferentes SGWfCs é um desafio. Este reuso de workflows, no entanto, adquire cada vez mais importância no cenário de experimentos científicos, uma vez que possibilita a integração entre diferentes grupos de pesquisa e reforça a ideia dos chamados "laboratórios colaborativos" [Olson 2009]. Com o número crescente de SGWfCs disponíveis e a heterogeneidade entre eles, soluções para a interoperação desses workflows são importantes. A interoperação de diferentes SGWfCs possibilita o reuso de especificações de workflows científicos desenvolvidas por diferentes grupos de pesquisa, independente do SGWfC utilizado. Porém, identificar de que forma um tipo de informação presente em uma especificação de workflow deve ser processada, considerando a interoperação, é um desafio. Essa identificação depende fundamentalmente da semântica associada a cada diferente tipo de informação e, em alguns cenários, um mapeamento imediato dessa semântica entre diferentes SGWfCs não é possível. Um exemplo simples é o de uma funcionalidade em um SGWfC específico que não é diretamente mapeável em outros SGWfCs. Neste contexto, o uso de padrões (patterns) em workflows científicos [Yildiz et al. 2009] pode ajudar a explicitar as informações semânticas mais importantes para a construção desses workflows. Em um cenário em que padrões fossem empregados no auxílio à interoperação, uma vez que fosse identificada a existência de um determinado padrão em uma especificação de workflow científico, a informação semântica associada poderia ser automaticamente capturada. Neste contexto, a hipótese deste trabalho a ser validada é de que uma linguagem de interoperação baseada em padrões ofereceria mais segurança em garantir o comportamento esperado em um SGWfC de uma especificação de workflow gerada a partir de um processo de transformação de uma especificação feita em qualquer outro SGWfC. A proposta desse trabalho é, portanto, especificar uma linguagem para interoperação de workflows científicos baseada em padrões e validar a hipótese pontuada acima. 2. Fundamentação Teórica Em [Muehlen e Klein 2000] o conceito de interoperação de workflows de negócio utilizando uma linguagem intermediária baseada em XML é bem explorado e com ganhos significativos. Em workflows científicos não existe um arcabouço semântico comum adotado por todos os SGWfCs, o que dificulta a interoperação. Embora existam abstrações básicas presentes em todos os workflows (tanto de negócio quanto científicos), como tarefas, portas e conexões, workflows científicos geralmente empregam abstrações mais complexas, como varreduras de parâmetros e estruturas de repetições, que dificultam a interoperação. Essas abstrações mais complexas estão em geral relacionadas ao fato de que workflows científicos são principalmente orientados a dados, enquanto workflows de negócio são orientados a controle. Uma abordagem possível de interoperação de workflows científicos é a transformação direta entre especificações de diferentes SGWfCs. Um problema nesse cenário é que o 17

18 número de transformações necessárias para a interoperação de N diferentes SGWfCs cresce de forma quadrática com o valor de N, além da possibilidade de não ser possível o mapeamento de semânticas específicas diretamente entre um e outro. Nesse sentido, o uso de uma linguagem específica para interoperação de workflows científicos, tal como a proposta em [Plankensteiner et al. 2013], traz ganhos, pois uma vez que um SGWfC possa ter suas especificações transformadas nessa linguagem (e vice-versa), torna-se possível a interoperação desse SGWfC com outros SGWfCs que também tenham suas especificações transformáveis na linguagem para interoperação. Contudo, o uso de uma linguagem para interoperação por si só não impede que haja perda de informação semântica durante um processo de transformação. 3. Contribuições Este trabalho objetiva abordar a interoperação de SGWfCs por meio de uma linguagem intermediária em conjunto com o uso de padrões em workflows científicos para mitigar a perda de informação semântica nessa interoperação. Esses padrões são utilizados na especificação da linguagem para armazenar a semântica comportamental de um workflow e possibilitar sua reprodução em outro SGWfC. Assim, embora a construção desses padrões possa ser diferente em cada SGWfC, seu comportamento se dará de acordo com a semântica associada a cada padrão. Uma vez que a especificação de um workflow em um determinado SGWfC de origem é convertida para a linguagem intermediária proposta neste trabalho, sua informação semântica, baseada na identificação de um conjunto de padrões presentes nesse workflow, deve ser preservada. Assumindo que o SGWfC de destino dê suporte aos padrões encontrados no workflow original, mesmo que sua construção não seja nativa no SGWfC de destino, a especificação desse workflow na linguagem intermediária permite reproduzir corretamente seu comportamento no SGWfC de destino. A linguagem de descrição de arquitetura (ADL) Acme [Garlan et al. 1997] foi escolhida neste trabalho para descrever formalmente a estrutura da linguagem de interoperação em termos de conjuntos de padrões de workflows científicos. O uso de Acme permite estabelecer regras de formação de instâncias desses padrões, bem como adicionar funcionalidades importantes e que não são encontradas em todos os SGWfCs, como o tratamento de requisitos não-funcionais [Medeiros e Gomes 2013] (vide Seção 6). O suporte à tipagem múltipla de instâncias de elementos arquiteturais em Acme também possibilita a composição de estruturas prescritas pelos tipos sem a necessidade de criação de subtipos. Esse atributo de Acme torna-a mais qualificada para descrever uma linguagem intermediária devido a heterogeneidade encontrada nos SGWfCs. Um mecanismo de transformações é necessário para converter as especificações que estão na linguagem nativa de cada SGWfC, sendo um resultado esperado deste trabalho. Em alguns SGWfCs onde uma linguagem textual está disponível, é possível realizar transformações baseadas em templates+metamodelos [Stahl et al. 2006]. Nos SGWfCs sem uma linguagem textual, as APIs desses SGWfCs podem ser utilizadas. 4. Estado Atual do Trabalho Inicialmente foi feita uma primeira análise dos padrões propostos na iniciativa Workflow Patterns 1 e de workflows presentes no repositório myexperiment. 2 A partir

19 dessa análise, os padrões Sequence, Parallel Split, Synchronization, Exclusive Choice e Simple Merge, apresentados na iniciativa Workflows Patterns, foram incluídos na linguagem intermediária proposta, mas levando em consideração o comportamento orientado a dados, típico dos workflows científicos. A estrutura de repetição For Each, embora não presente na iniciativa Workflow Patterns, foi proposta como um padrão adicional cuja função é iterar sobre uma coleção recebida por uma porta de entrada. Como pode ser visto na Figura 1, emprega-se o conceito de família presente na ADL Acme para especificar os padrões. Uma família define um conjunto de tipos de elementos de modelagem arquitetural (componentes e portas, conectores e papéis) e regras de composição entre instâncias desses tipos. Na linguagem especificada neste trabalho, os tipos definidos na família Acme (vide Figura 1(a)) descrevem os padrões como conexões (conectores e papéis) entre tarefas de um workflow, pois, uma vez que workflows científicos são em geral orientados a dados, seu comportamento é observável no momento em que dados são trocados entre as portas das tarefas. (b) Regras do padrão Parallel Split (a) Família de padrões Figura 1. Linguagem intermediária baseada na ADL ACME. Para garantir a estrutura e o comportamento esperados desses padrões, regras de formação foram adicionadas para cada um deles. Essas regras podem restringir o número de conexões presentes em um padrão e o tipo de dado que cada padrão espera receber. A Figura 1(b) ilustra uma regra simples para o padrão Parallel Split, estabelecendo que instâncias desse padrão devem ter somente uma porta de entrada e ao menos duas de saída. Uma regra semelhante pode ser definida para o padrão Exclusive Choice; o que diferencia esses dois padrões é a informação semântica que cada um desses padrões carrega consigo, e que está associada ao comportamento das conexões (conectores e papéis) que definem esses padrões. Uma vez que regras restrinjam a estrutura e o comportamento de um determinado padrão, é possível validar se sua construção está correta. Uma especificação de workflow científico descrita nessa linguagem intermediária garante o comportamento

20 que um padrão deve ter em um determinado trecho do workflow, sem detalhamento de quais recursos serão utilizados para atingir esse comportamento. Em alguns SGWfCs, é possível que a implementação de um padrão seja nativa a partir de uma tarefa ou conexão pré-definida no SGWfC, enquanto em outros pode ser necessária a composição de várias funcionalidades. Porém, ao utilizar padrões e regras que restrinjam essas composições, é possível garantir que esse workflow terá o mesmo comportamento em qualquer SGWfC que implemente esses padrões. 5. Comparação com Trabalhos Relacionados Uma solução para a interoperação de especificações de workflows científicos é a transformação direta entre duas especificações de SGWfCs, como a oferecida pela ferramenta Taverna-Galaxy. 3 Essa abordagem, contudo, pode requerer demasiado esforço de desenvolvimento caso queira se dar suporte a outros SGWfCs. Em [Plankensteiner et al. 2013] é apresentada uma solução para a interoperação de workflows científicos através de uma linguagem intermediária chamada IWIR. Essa solução, contudo, apresenta limitações. Como um exemplo, IWIR não oferece um construtor que implemente o padrão Exclusive Choice mencionado na Seção 4; esse padrão pode ser no entanto reproduzido em IWIR por meio de condicionais (construtores do tipo if ) aninhados. O problema é que a transformação desses condicionais aninhados para a linguagem de um SGWfC de destino levará a condicionais aninhados, mesmo que a linguagem desse sistema dê suporte direto ao padrão Exclusive Choice. Em [Abouelhoda et al. 2012] é apresentada uma estratégia de interoperação baseada em padrões que pode interoperar os SGWfCs Taverna e Galaxy. Um problema nessa interoperação é que cientistas teriam que aprender a lidar com um novo SGWfC, uma vez que esta estratégia não foi projetada como uma ferramenta de interoperação e sim como um novo SGWfC em si. 6. Avaliação dos Resultados Existem várias soluções possíveis para a interoperação de workflows científicos desenvolvidos em diferentes SGWfCs. A inexistência de um arcabouço semântico comum para especificações de workflows científicos pode ser um problema para o reuso e interoperação dessas especificações, pois sempre existirão construções que possuam estruturas diferentes para um mesmo comportamento ou estruturas iguais para comportamentos diferentes em alguns SGWfCs. Uma linguagem intermediária baseada em padrões parece ser uma das abordagens interessantes a ser investigada, pois as informações semânticas já estariam, em tese, contidas nos padrões. A proposta desse trabalho é definir uma linguagem intermediária baseada em padrões utilizando a ADL Acme como base. O número de padrões incorporados a essa linguagem deve crescer de acordo com o número de SGWfCs estudados e de acordo com seus padrões comportamentais. Alguns padrões básicos e comumente encontrados em workflows científicos já foram adicionados à linguagem. O uso de uma ADL como Acme para descrever uma nova linguagem se mostra eficaz, tanto pelo seu suporte a definição de regras de formação, como também pela sua

21 capacidade de composição de tipos. Pretendemos como trabalho futuro explorar esta última característica de Acme a de composição de tipos para a adição de suporte ao tratamento de requisitos não-funcionais na interoperação, na linha do que foi proposto em [Medeiros e Gomes, 2013]. Também como trabalho futuro, visamos investigar a interoperação de informações relacionadas ao comportamento das tarefas de workflows científicos. A interoperação dessas informações não é trivial, visto que muitos SGWfCs possuem scripts nativos que são utilizados como tarefas de um workflow. Em cenários como o repositório myexperiment, onde tarefas têm seu comportamento interno implementado como Web Services, essa interoperação é mais simples. Porém, em casos onde sejam usadas tarefas que são nativas de um SGWfC, essa tarefa também deve ser tratada, garantindo assim o comportamento esperado para o workflow. É importante também ressaltar que um estudo experimental, com o objetivo de validar a abordagem, está sendo conduzido. Esse estudo utiliza o repositório myexperiment e busca transformar diferentes especificações de workflows na linguagem intermediária baseada em padrões, mantendo a semântica dos workflows, e vice versa. Referências [Abouelhoda et al. 2012] Abouelhoda, M., Issa, S., e Ghanem, M. (2012). Tavaxy: Integrating taverna and galaxy workflows with cloud computing support. BMC Bioinformatics, 13:77. [Garlan et al. 1997] David Garlan, Robert Monroe, and David Wile Acme: an architecture description interchange language. In Proceedings of the 1997 conference of the Centre for Advanced Studies on Collaborative research (CASCON '97), J. Howard Johnson (Ed.).IBM Press 7-. [Hayes et al ] James G. Hayes, Effat, Peyrovian, Sunil Sarin, Marc-Thomas Schmidt, Keith D. Swenson, and Rainer Weber. Workflow Interoperability Standards for the Internet. IEEE Internet Computing, pág [Medeiros e Gomes 2013] Medeiros, V. e Gomes, A. T. A. (2013). Expressando atributos nãofuncionais em workflows científicos. CoRR, abs/ [Muehlen e Klein 2000] Muehlen, M. Z. e Klein, F. (2000). Africa: Workflow interoperability based on xml-messages. In Proceedings of CAiSE 00 workshop on Infrastructures for Dynamic Business-to- Business Service Outsourcing (IDSO 00) pág [Oinn et al. 2004] Oinn, T., Addis, M., Ferris, J., Marvin, D., Carver, T., Pocock, M. R., e Wipat, A. (2004).Taverna: A tool for the composition and enactment of bioinformatics workflows Bioinformatics, 20:2004. [Olson 2009] Olson, G. M. (2009). The next generation of science collaboratories.in Proceedings of the International Symposium on Collaborative Technologies and Systems (CTS 09). IEEE Computer Society, Washington, DC, USA. [Plankensteiner et al. 2013] Plankensteiner, K., Prodan, R., Janetschek, M., Montagnat, J., Rogers, D., Harvey, I., Taylor, I., Ákos, Balaskó, e Kacsuk, P. (2013). Fine-grain interoperability of scientific workflows in distributed computing infrastructures. Journal of Grid Computing. [Stahl et al. 2006] Thomas Stahl, Markus Voelter, and Krzysztof Czarnecki Model-Driven Software Development: Technology, Engineering, Management. John Wiley & Sons. [Yildiz et al. 2009] Yildiz, U., Guabtni, A., e Ngu, A. H. H. (2009). Towards scientific workflow patterns.in Proceedings of the 4th Workshop on Workflows in Support of Large-Scale Science, WORKS 09, pág. 13:1 13:10, New York, NY, USA. 21

22 Adaptação de critérios de teste de programas concorrentes para o teste de integração de robôs móveis Marcos Pereira dos Santos 1, Simone R. S. Souza 1 1 Instituto de Ciências Matemáticas e de Computação (ICMC) Universidade de São Paulo (ICMC/USP) Caixa Postal São Carlos SP Brasil {mpereira,srocio}@icmc.usp.br Abstract. This paper presents a master s project under development whose goal is to adapt concurrent program coverage testing criteria to the context of mobile robots, mapping these coverage criteria to deal with errors related to the communication among the components of the mobile robots systems. The proposed approach should be incorporated into the ROS framework, that has been used to support the development of mobile robots. Another objective of this project is conducting an experimental study to compare the applicability of the coverage testing criteria considering other environments to develop mobile robots. Resumo. Este artigo apresenta um projeto de mestrado em andamento cujo objetivo é a adaptação de critérios de teste de programas concorrentes para o contexto de robôs móveis, adaptando-os para tratar erros relacionados à comunicação entre os componentes de um sistema para robôs móveis. A abordagem proposta deve ser incorporada ao framework ROS, que vem sendo utilizado para apoiar o desenvolvimento de robôs móveis. Outro objetivo deste projeto é realizar estudos comparativos para avaliar a aplicabilidade dos critérios de teste considerando outros ambientes de desenvolvimento de robôs móveis. 1. Introdução A atividade de teste de software é uma análise dinâmica do produto de software e tem por objetivo encontrar os defeitos presentes no mesmo. Para isso, técnicas e critérios de teste são propostos, os quais devem ser aplicados nas diferentes fases do processo de desenvolvimento. O teste de integração é uma atividade sistemática aplicada durante a integração das subpartes que compõem o programa com o objetivo de descobrir erros associados às interfaces entre os módulos. O objetivo é, a partir dos elementos testados no nível de unidade, construir a estrutura do programa de acordo com o definido no projeto do software [Delamaro et al. 2007]. A programação concorrente está cada vez mais sendo utilizada no desenvolvimento de diversos tipos de sistemas para áreas como: financeira, científica, comercial, redes de sensores, computação ubíqua, entre outras. Um programa concorrente é formado por dois ou mais processos ou threads que trabalham juntos para realizar uma tarefa, sendo que essa interação pode ocorrer de forma sincronizada ou não e os processos podem ou não concorrerem aos mesmos recursos computacionais [Andrews 2000]. Esse paradigma de programação permite o desenvolvimento de algoritmos que quando 22

23 executados originam novos processos que podem executar concorrentemente e interagirem entre si [Pacheco 2011]. Diferentes execuções de um programa concorrente com a mesma entrada podem produzir diferentes saídas em razão das diferentes sincronizações executadas. O desafio do teste de software nesse contexto é identificar todas as possíveis sincronizações para verificar se as saídas obtidas são as esperadas [Taylor et al. 1992, Wong et al. 2005, Souza et al. 2012]. Um sistema robótico em razão da sua própria natureza, constituído por diversos componentes interagindo, apresentam um certo nível de similaridade com programas concorrentes. Um robô móvel autônomo deve ser capaz de interagir com o ambiente, aprender e tomar decisões corretas para que suas tarefas sejam executadas com êxito. Para o desenvolvimento de robôs móveis são utilizados ambientes que permitem simular o comportamento dos robôs à medida são sendo desenvolvidos. Exemplos destes ambientes são: ROS, Player, Ária, Carmen, Microsoft Robotics Studio, dentre diversos outros [Wolf et al. 2009]. Dentre estes ambientes de desenvolvimento de robôs móveis pode-se destacar o ROS 1, o qual oferece bibliotecas e um conjunto de ferramentas para auxiliar os desenvolvedores de aplicações para robôs, possibilitando abstrair o hardware e drivers de dispositivo, de modo a simular o funcionamento da aplicação. Este projeto de mestrado visa a contribuir nesse cenário, em que o objetivo é a investigação e adaptação dos critérios de teste estruturais de programas concorrentes [Souza et al. 2008] para o contexto de sistemas embarcados robóticos, realizando um estudo comparativo desses critérios, considerando o ambiente ROS e outros utilizados para o desenvolvimento desses sistemas. 2. Caracterização do Problema No contexto de programas sequenciais foram definidos ao longo dos anos várias técnicas e critérios de teste de software. O teste de aplicações concorrentes comparado ao teste de programas sequenciais é mais complicado, pois além das dificuldades inerentes à atividade de teste, novos desafios são impostos principalmente devido ao comportamento não determinístico em que diferentes sequências de sincronização podem ser obtidas com a utilização de uma mesma entrada de teste, e por isso, faz-se necessário avaliar se o comportamento das saídas é o esperado ou não. Uma das linhas de pesquisa do grupo de Engenharia de Software do ICMC/USP está relacionada ao teste de programas concorrentes e diversas são as contribuições neste sentido [Souza et al. 2005, Hausen et al. 2007, Souza et al. 2008, Sarmanho et al. 2008, Souza et al. 2012]. Partindo para o teste de sistemas para robôs móveis, um dos desafios é testar se as informações vindas dos sensores e componentes do sistema. É de suma importância que o robô preserve a sua integridade, bem como também os elementos presentes em seu ambiente como seres humanos, objetos, utensílios, etc. A ação de um robô deve ocorrer de modo ativo sobre um determinado objeto alvo, se realmente for prevista a sua ação sobre este objeto [Wolf et al. 2009]. Observa-se que muitos aspectos presentes em programas concorrentes são semelhantes aos encontrados em sistemas para robôs móveis, os quais precisam interagir com o meio e com as partes que o compõem. Entre as principais semelhanças encontradas entre programas concorrentes e sistemas embarcados para robôs móveis pode-se destacar a comunicação e sincronização de tarefas. Um sistema para 1 ROS

24 robô móvel é composto por diversos dispositivos como sensores, atuadores e programa de controle central que interagem e executam código de forma paralela. A comunicação e sincronização entre as tarefas desempenhadas por cada um dos dispositivos, muitas vezes, é não determinística, assim como em programas concorrentes, em que há diversos processos/threads executando de forma concorrente. Considerando esses aspectos, surgiu a motivação de investigar o teste de integração em sistemas embarcados para robôs móveis, buscando explorar questões que vêm sendo tratadas no teste de programas concorrentes. Para ilustrar as definições apresentadas, considere o grafo da Figura 1. Este aplicação apresentada representa um exemplo de comunicação entre componentes de um sistema para robôs móveis autônomos, desenvolvida utilizando o ROS. O mesmo é constituído por três nós (componentes executáveis) que são: /sensor,/actuator e /gps e pelos tópicos (mecanismo utilizado para troca de mensagens): /info e /localization. Figura 1. Exemplo de aplicação para sistemas de robôs móveis. O nó /sensor publica informações no tópico /info. Esta mensagem publicada é assinada pelos componentes /actuator e /gps. O componente /gps publica mensagens no tópico /localization e esta mensagem é subscrita pelo componente /actuator. Desta maneira ocorre a comunicação e interação entre os componentes deste sistema, assim pretende-se explorar as similaridades destes sistemas com programas concorrentes para adptação dos critérios de teste. 3. Caracterização da Contribuição O desenvolvimento deste projeto de mestrado irá contribuir para o estado da arte na área de VV&T (Verificação, Validação e Testes) de robôs móveis. Pretende-se com esse projeto contribuir com o cenário nacional e internacional no que tange a melhoria de qualidade de sistemas para robôs móveis, apresentando critérios de teste de integração para robôs móveis. Assim, espera-se contribuir com a atividade de teste aplicado a sistemas para robôs móveis, por meio da adaptação de critérios de testes de programas concorrentes para robôs móveis. Outra contribuição é apresentar uma proposta de adaptação de critérios de teste para programas concorrentes do nível de unidade para o nível de integração. Desse modo, a adaptação dos critérios de teste ocorre em duas diferentes dimensões: de programas concorrentes para sistemas embarcados robóticos, e do nível de unidade para o nível de integração. Espera-se também gerar resultados sobre a comparação entre diferentes ambientes de desenvolvimento de robótica móvel em relação ao esforço e efetividade da atividade de teste, buscando identificar os desafios impostos ao teste nesses ambientes de desenvolvimento. 4. Estado Atual do Trabalho Este projeto está vinculado a um doutorado em andamento, o qual explora um modelo para o teste de integração desses sistemas [Brito 2013], contribuindo com a melhoria da qualidade dos sistemas embarcados que vem sendo desenvolvidos no Instituto Nacional de Ciência e Tecnologia (INCT/SEC), com a utilização de técnicas de teste de software. 24

25 A etapa atual deste projeto, consiste no estudo sobre o modelo de teste de integração para sistemas embarcados críticos em desenvolvimento pelo grupo de Engenharia de Software do ICMC [Brito 2013]. Também está sendo realizado um estudo dos critérios para teste de programas concorrentes, em que são observados os critérios relacionados à comunicação e sincronização. Outra etapa que está sendo realizada é a adaptação dos critérios definidos para o teste de programas concorrentes para o contexto de sistemas para robôs móveis. Nessa fase estão sendo definidos e implementados os recursos necessários para que esses critérios possam ser utilizados nos ambientes de desenvolvimento de robôs móveis. 5. Trabalhos Relacionados Na literatura são encontrados trabalhos que propõem critérios de teste de integração para sistemas embarcados [Hossain and Lee 2013, Belli et al. 2009, Lee et al. 2002, Seo et al. 2007, Sung et al. 2011]. A maioria dos estudos apresentam critérios no nível de integração entre unidades que compõe estes sistemas como classes, métodos, funções, etc. A proposta deste projeto possui como objetivo a proposição de critérios de teste de integração para sistemas robóticos móveis considerando características de comunicação entre os componentes. Nos trabalhos relacionados, não foram encontrados estudos que descrevem a utilização dos critérios de teste propostos e sua aplicabilidade para sistemas para robôs móveis ou sistemas mais complexos como sistemas embarcados críticos. Os trabalhos apresentam estudos de caso, no geral, para sistemas embarcados que não são de natureza crítica como celulares, televisão, robôs não autônomos, dentre outros. Algumas característics encontradas em sistemas para robôs móveis autônomos devem ser levadas em consideração na aplicação dos critérios de teste para estes sistemas, as quais não são encontradas nos demais sistemas, como em progrmas concorrentes. Algumas destas características são: capacidade de percepção, capacidade de agir, robustez e inteligência [Wolf et al. 2009]. Desta maneira, requer que os critérios de teste para programas concorrentes sejam estudados e adaptados verificando-se também estas características. 6. Avaliação dos Resultados Até esta fase do projeto foram obtidos alguns resultados. Foi realizado um mapeamento sistemático sobre teste de integração para sistemas embarcados críticos e está sendo escrito um artigo que será submetido a conferências. Após a adaptação/implementação dos critérios, os mesmos serão validados com a realização de experimentos, os quais deverão englobar como estudos de caso os sistemas desenvolvidos tanto pelo INCT/SEC como CaRINA 2, visando avaliar a aplicabilidade da proposta. Os experimentos serão conduzidos com base no processo experimental proposto por Wohlin [Wohlin et al. 2000]. Agradecimento Os autores gostariam de agradecer a Capes, pelo apoio financeiro. Referências Andrews, G. (2000). Foundations of Multithreaded, Parallel, and Distributed Programming. Addison-Wesley. 2 CaRINA

26 Belli, F., Hollmann, A., and Padberg, S. (2009). Communication sequence graphs for mutation-oriented integration testing. In Secure Software Integration and Reliability Improvement. SSIRI. Third IEEE International Conference on, pages Brito, M. A. S. (2013). Estudo e definio do teste de integrao de software para o contexto de sistemas embarcados crticos. ICMC/USP - Projeto de doutorado em andamento. Delamaro, M. E., Maldonado, J., and Jino, M. (2007). Introdução ao Teste de Software. Rio de Janeiro: Elsevier (Editora Campus), 1a edition. Hausen, A. C., Verglio, S. R., Souza, S. R. S., Souza, P. S. L., and Simão, A. S. (2007). A tool for structural testing of MPI programs. In LAtin-American Test Workshop - LATW, volume 1, Cuzco. Hossain, M. I. and Lee, W. J. (2013). A scalable integration testing approach considering independent usage pattern of global variables. International Journal of Software Engineering and Its Applications, pages Lee, N. H., Kim, T. H., and Cha, S. D. (2002). Construction of global finite state machine for testing task interactions written in message sequence charts. In Proceedings of the 14th international conference on Software engineering and knowledge engineering, SEKE 02, pages , New York, NY, USA. ACM. Pacheco, P. (2011). An Introduction to Parallel Programming. Elsevier. Sarmanho, F. S., Souza, P. S. L., Souza, S. R. S., and ao, A. S. S. (2008). Structural testing for semaphore-based multithread programs. In International Conference on Computational Science, volume 5101, pages , Krakow. Springer-Verlag. Seo, J., Sung, A., Choi, B., and Kang, S. (2007). Automating embedded software testing on an emulated target board. In Proceedings of the Second International Workshop on Automation of Software Test, AST 07, Washington, DC, USA. IEEE Computer Society. Souza, P. S. L., Souza, S. R. S., and Zaluska, E. (2012). Structural testing for messagepassing concurrent programs: an extended test model. Concurrency and Computation. Souza, S. R. S., Vergilio, S. R., Souza, P. S. L., Simão, T. G. Bliscosque, A. M. L. A. S., and Hausen, A. C. (2005). Valipar: A testing tool for message-passing parallel programs. pages Souza, S. R. S., Vergilio, S. R., Souza, P. S. L., Simão, A. S., and Hausen, A. C. (2008). Structural testing criteria for message-passing parallel programs. Concurr. Comput. : Pract. Exper., 20(16): Sung, A., Choi, B., Wong, W. E., and Debroy, V. (2011). Mutant generation for embedded systems using kernel-based software and hardware fault simulation. Information and Software Technology, 53(10): Taylor, R. N., Levine, D. L., and Kelly, C. D. (1992). Structural testing of concurrent programs. IEEE Trans. Softw. Eng., 18(3): Wohlin, C., Runeson, P., Hst, M., Ohlsson, M. C., Regnell, B., and Wessln, A. (2000). Experimentation in Software Engineering: An Introduction. Kluwer Academic Publishers. Wolf, D. F., Osório, F. S., Simões, E., and Trindade Jr., O. (2009). Robótica inteligente: Da simulação às aplicações no mundo real. 1: Wong, W., Lei, Y., and Ma, X. (2005). Effective generation of test sequences for structural testing of concurrent programs. In Engineering of Complex Computer Systems, ICECCS Proceedings. 10th IEEE International Conference on, pages

27 Avaliação de Arquiteturas Recuperadas com base em Métodos de Avaliação Precoce Mateus Passos Soares Cardoso 1, Christina von Flach G. Chavez 1, Crescencio Lima 1 1 Programa Multiinstitucional de Pós-Graduação em Ciência da Computação - PMCC Universidade Federal da Bahia - UFBA {mateuspsc,flach,crescencio}@dcc.ufba.br Resumo. Em geral, a documentação de arquitetura de sistemas de software não existe ou está desatualizada. Ferramentas de recuperação de arquitetura automatizam parte do processo de obtenção da arquitetura a partir do código-fonte do sistema de software e apoiam a criação ou atualização da documentação. Entretanto, há pontos em aberto relacionados à avaliação das arquiteturas extraídas por tais ferramentas. Por exemplo, como avaliar a qualidade de uma ou mais arquiteturas extraídas se não houver arquitetura conceitual documentada ou se os arquitetos que originalmente projetaram o sistema não estiverem disponíveis? Esta proposta apresenta uma abordagem para avaliar a qualidade de arquiteturas de software extraídas por ferramentas de recuperação com base em métodos de avaliação precoce de arquitetura. Ferramentas de recuperação serão usadas para obter modelos de arquitetura de software e os métodos de avaliação por exemplo, Software Architecture Analysis Method (SAAM) e Architecture Tradeoff Analysis Method (ATAM) serão usados para avaliar a qualidade das arquiteturas extraídas e riscos associados. Espera-se que a abordagem proposta contribua para a melhorar a compreensão e a documentação de arquitetura em sistemas de software existentes. Palavras - Chave. Arquitetura de Software, Avaliação de Arquitetura, SAAM, ATAM, SAR. Recuperação de Arquitetura, Ano de Ingresso no Programa:2013 Época prevista para conclusão: Maio de 2015 Data de Aprovação da proposta de tese/dissertação(qualificação):abril de 2014 Eventos Relacionados:SBCARS, SBES 27

28 1. Caracterização do Problema Ferramentas de recuperação de arquitetura fornecem mecanismos para arquitetos e desenvolvedores recuperarem a arquitetura de um software a partir de representações do código, de modo a remediar problemas comuns que ocorrem durante o desenvolvimento do sistema, por exemplo, erosão, documentação incompleta, inconsistência entre arquitetura documentada e a arquitetura implementada, entre outros [Pollet et al. 2007]. Normalmente, a avaliação da qualidade da arquitetura extraída é feita por comparação com a arquitetura conceitual documentada ou por meio de análise apoiada por arquitetos ou desenvolvedores do software implementado [Chardigny et al. 2008, Mancoridis et al., Terceiro et al. 2010, Pinzger 2005]. Nesse contexto, métodos de avaliação tardia de arquitetura podem ser utilizados. Entretanto, para alguns sistemas de software, a arquitetura conceitual não está disponível nem os arquitetos ou desenvolvedores que participaram de sua construção. Como então avaliar a qualidade da arquitetura extraída a partir de um sistema de software? Uma possível solução para esse problema é utilizar métodos de avaliação precoce de arquitetura [Kazman et al. 2000, Clements et al. 2001]. Os métodos de avaliação precoce por exemplo, SAAM (Scenario-Based Software Architecture Analysis Method) [Clements et al. 2001] e ATAM (Architecture based Tradeoff Analysis Method) [Kazman et al. 2000] têm como objetivo definir se uma arquitetura é apropriada ou não para um sistema de software antes desta ser escolhida como a arquitetura definitiva [Roy and Graham 2008] e certamente antes da implementação do sistema. O método SAAM [Clements et al. 2001] busca avaliar se determinado conjunto de arquiteturas é apropriado para um determinado sistema. O método ATAM [Kazman et al. 2000] serve como uma extensão e avalia os possíveis riscos que uma arquitetura candidata pode trazer para o sistema. Entretanto, estes dois métodos de avaliação não são simples de usar e deve-se investigar com cuidado a viabilidade de seu uso no contexto da avaliação de arquiteturas extraídas a partir do sistema implementado. Este trabalho tem como objetivo explorar a viabilidade do uso de métodos de avaliação precoce de arquitetura para avaliar a qualidade de arquiteturas extraídas com o apoio de ferramentas de recuperação. Os objetos de estudo serão sistemas de software de código aberto, cuja arquitetura documentada seja inexistente. Pretende-se utilizar os métodos de avaliação de arquitetura precoce SAAM e ATAM como base para a definição de uma técnica de avaliação de arquiteturas recuperadas com apoio de ferramentas de recuperação e seus riscos associados. 2. Fundamentação Teórica Nesta seção, são apresentados conceitos relacionados a recuperação de arquitetura de software, com ênfase em ferramentas de recuperação (Seção 2.1) e a avaliação de arquitetura de software, com ênfase em métodos (Seção 2.2) Recuperação de Arquitetura de Software Recuperação de arquitetura de software (Software Architecture Recovery SAR) é o processo de determinar a arquitetura de um sistema de software a partir de seu códigofonte ou outros artefatos de implementação. A recuperação de arquitetura permite a 28

29 identificação e a extração de representação de alto nível de sistemas de software existentes [Eixelsberger et al. 1996]. Há várias abordagens para recuperação de arquitetura do software (SAR). A ideia geral é trabalhar com a arquitetura de software recuperada a partir do sistema implementado, que reflita com acurácia as decisões de design implementadas. Ducasse e Pollet [Pollet et al. 2007] realizaram um levantamento de diversas ferramentas existentes e as classificaram de acordo com seus (i) Objetivos (documentação, reuso, migração, etc.), (ii) Processos (bottom-up, top-down ou híbrido), (iii) Dados de Entrada (código-fonte, documentos, etc.), (iv) Técnicas (quase-manual, semiautomática, quase-automática) e (v) Dados de Saída (representação visual da arquitetura, texto, etc.). Neste trabalho, usamos algumas destas dimensões para guiar a escolha de ferramentas para análise Avaliação de Arquitetura de Software A avaliação da arquitetura de um sistema de software é um processo que reune stakeholders com o objetivo de analisar documentos arquiteturais em busca de possíveis problemas [Clements et al. 2001] e para verificar se requisitos de qualidade foram atendidos no projeto. Há diversas abordagens para avaliação de arquitetura de software [Barcelos and Travassos 2006]. De modo geral, a avaliação de arquitetura pode ser feita em dois momentos: antes da arquitetura do sistema estar pronta (avaliação precoce) ou após a arquitetura do sistema e o próprio sistema estarem prontos (avaliação tardia) [Clements et al. 2001]. Neste trabalho, serão utilizados dois métodos de avaliação precoce: SAAM [Clements et al. 2001] e ATAM [Kazman et al. 2000]. Os dois são métodos baseados em cenários, uma categoria considerada bastante madura [Babar et al. 2004]. O SAAM (Scenario-Based Software Architecture Analysis Method) [Roy and Graham 2008] é um método de avaliação precoce da arquitetura de sistemas de software. Sua análise verifica suposições a respeito da arquitetura (por exemplo, se uma arquitetura é adequada ao sistema em questão) em confronto com os documentos que descrevem a arquitetura. A análise busca encontrar problemas na arquitetura do software, por exemplo, conflitos ou design incompleto da arquitetura. Além disso, o SAAM ajuda a comparar arquiteturas candidatas de um sistema. Como informação necessária para análise da arquitetura, o SAAM utiliza a arquitetura candidata e os requisitos do sistema [Roy and Graham 2008]. Como resultado, o SAAM produz cenários sensíveis a qualidade do sistema, o mapeamento entre os cenários e os componentes arquiteturais e o esforço necessário para realizar estes cenários na arquitetura. O processo de análise é composto de seis etapas: Especificação dos requisitos do sistema, descrição da arquitetura, extração de cenários, priorização de cenários, avaliação da arquitetura em relação aos cenários, interpretação e apresentação dos resultados. O ATAM (Architecture based Tradeoff Analysis Method) [Kazman et al. 2000] é uma extensão do SAAM que cobre pontos na avaliação arquitetural que não eram cobertos anteriormente, como os tradeoffs da arquitetura, ou seja, decisões arquiteturais que podem afetar atributos de qualidade do sistema (por exemplo: adquirir mais servidores para a aplicação aumentaria o desempenho e a disponibilidade, o que poderia deixar o sistema mais suscetível a ataques) [Roy and Graham 2008]. 29

30 O ATAM é composto por nove atividades estruturadas e mais complexas do que as do SAAM: apresentação do ATAM, apresentação das regras de negócio, apresentação da arquitetura, identificação de abordagens arquiteturais, geração de árvore de utilidade, análise das abordagens arquiteturais, priorização de cenários, segunda análise da abordagens arquiteturais, apresentação dos resultados. Algumas atividades podem ocorrer em paralelo. 3. Objetivos e Contribuições Este trabalho de mestrado tem como objetivo principal apresentar uma abordagem baseada em métodos de avaliação precoce de arquitetura para apoiar a avaliação da qualidade de uma ou mais arquiteturas de software extraídas automaticamente com ferramentas de recuperação a partir de um sistema implementado. As práticas de métodos de avaliação precoce usadas em situações em que os sistemas já estão implementados podem ajudar em tarefas de redocumentação. São objetivos específicos deste trabalho: Definir critérios para seleção, análise e comparação de ferramentas de recuperação de arquitetura, de forma a subsidiar a escolha das mais adequadas para uso. Analisar a viabilidade do uso de métodos de avaliação baseados em cenários (SAAM) e cenários / atributos (ATAM) para situações em que os sistemas de software estão implementados, buscando também identificar atividades ou práticas que possam ser aplicáveis. Propor uma abordagem de avaliação de arquiteturas recuperadas, com práticas adaptadas de métodos de avaliação precoce baseados em cenários e/ou atributos, para ser usada em sistemas de software implementados. Avaliar empiricamente a abordagem proposta. São contribuições esperadas deste trabalho: Um conjunto de critérios de avaliação de ferramentas de recuperação de arquitetura; Uma abordagem de avaliação precoce de arquitetura que poderá ser usada em casos onde apenas métodos tardios são adotados, e Uso de métodos de avaliação de arquitetura ainda pouco difundidos em ambientes de desenvolvimento de software de código aberto. 4. Cronograma e Estado Atual do Trabalho A Tabela 1 apresenta o cronograma de atividades previstas para o ano de Algumas das atividades representadas neste cronograma estão associadas aos objetivos apresentados na seção 3. Atualmente, o trabalho se encontra na fase de análise das ferramentas de recuperação e parte do resultado desta análise pode ser encontrado em: 5. Trabalhos Relacionados Durante a fase de revisão de literatura, alguns trabalhos onde os autores buscaram avaliar as técnicas de recuperação de arquitetura e sua eficácia foram encontrados, a saber, [Wu et al. 2005], [Maqbool and Babri 2007] e[garcia et al. 2013]. 30

31 Tabela 1. Cronograma 2014 Atividade JAN/FEV MAR/ABR MAI/JUN JUL/AGO SET/OUT NOV/DEZ Revisão da Literatura Análise das Ferramentas de Recuperação Análise dos Métodos de Avaliação Definição da Abordagem de Avaliação Avaliação da Abordagem Desenvolvida Apresentação dos Resultados Em seu trabalho, Wu [Wu et al. 2005] selecionou e aplicou seis algoritmos de clusterização em 6 sistemas distintos. Os algoritmos de clusterização foram avaliados em três aspectos: estabilidade, competência e distribuição dos clusters. Para realização da avaliação, a arquitetura recuperada foi comparada com a arquitetura original destes sistemas. Nos trabalhos de [Maqbool and Babri 2007] e [Garcia et al. 2013] foram escolhidas ferramentas de recuperação que usam algoritmos de clusterização 8 ferramentas no estudo de [Maqbool and Babri 2007] e 6 ferramentas no estudo de [Garcia et al. 2013]. Para a avaliação das arquiteturas recuperadas, experts foram escolhidos para produzir arquiteturas para os sistemas que seriam analisados pelas ferramentas. Ao final do processo de recuperação, a arquitetura obtida pelas ferramentas foi comparada com a arquitetura produzida pelos experts. 6. Avaliação dos Resultados A viabilidade do uso de SAAM e ATAM para avaliação de arquiteturas será analisada por meio de um experimento-piloto. As arquiteturas recuperadas pelas ferramentas de recuperação servirão como entrada e serão apresentadas aos subjects do experimento. Uma ou mais visões arquiteturais poderão ser fornecidas. Os subjects serão divididos em dois grupos: um grupo irá avaliar as arquiteturas de acordo com as práticas do SAAM enquanto que o outro grupo irá avaliar de acordo as práticas do ATAM. Como resultado dos métodos, serão definidos cenários sensíveis a qualidade que servirão como base para avaliação das arquiteturas recuperadas. Após o experimento, os participantes serão entrevistados sobre questões relacionadas a abordagem de avaliação utilizada. A depender dos resultados obtidos, outros estudos experimentais poderão ser definidos para avaliação da abordagem proposta. Referências Babar, M. A., Zhu, L., and Jeffery, R. (2004). A framework for classifying and comparing software architecture evaluation methods. In ASWEC2004. Barcelos, R. and Travassos, G. (2006). Evaluation approaches for software architectural documents: a systematic review. In IDEAS. Chardigny, S., Seriai, A., Oussalah, M., and Tamzalit, D. (2008). Extraction of Component-Based Architecture from Object-Oriented Systems. Seventh Working IEEE/IFIP Conference on Software Architecture (WICSA 2008), pages Clements, P., Kazman, R., and Klein, M. (2001). Evaluating Software Architectures: Methods and Case Studies. Addison-Wesley Professional, 1 edition. 31

32 Eixelsberger, W., Warholm, L., and Klösch, R. (1996). A Framework for Software Architecture Recovery. International Workshop on Development and Evolution of Software Architectures for Product Families. Garcia, J., Ivkovic, I., and Medvidovic, N. (2013). A comparative analysis of software architecture recovery techniques th IEEE/ACM International Conference on Automated Software Engineering (ASE), pages Kazman, R., Klein, M., and Clements, P. (2000). Atam: Method for architecture evaluation. Technical report, Carnegie-Mellon Univ Pittsburgh PA Software Engineering Inst. Mancoridis, S., Mitchell, B., Rorres, C., Chen, Y., and Gansner, E. Using automatic clustering to produce high-level system organizations of source code. Proceedings. 6th International Workshop on Program Comprehension. IWPC 98 (Cat. No.98TB100242), pages Maqbool, O. and Babri, H. A. (2007). Hierarchical clustering for software architecture recovery. Software Engineering, IEEE Transactions on, 33(11): Pinzger, M. (2005). ArchView - Analyzing Evolutionary Aspects of Complex Software Systems Supervisors :. PhD thesis, Vienna University of Technology. Pollet, D., Ducasse, S., Poyet, L., Alloui, I., Cimpan, S., and Verjus, H. (2007). Towards A Process-Oriented Software Architecture Reconstruction Taxonomy. In 11th European Conference on Software Maintenance and Reengineering (CSMR 07), pages IEEE. Roy, B. and Graham, T. N. (2008). Methods for evaluating software architecture: A survey. School of Computing TR, 545:82. Terceiro, A., Costa, J., and Miranda, J. (2010). Analizo: an extensible multi-language source code analysis and visualization toolkit. Brazilian Conference on Software: Theory and Practice (CBSoft) Tools, pages 1 6. Wu, J., a.e. Hassan, and Holt, R. (2005). Comparison of clustering algorithms in the context of software evolution. 21st IEEE International Conference on Software Maintenance (ICSM 05), pages

33 Um estudo comparativo sobre sínteses de estudos de métodos mistos na Engenharia de Software Aluno: Danilo Monteiro Ribeiro 1, Orientador: Fábio Queda Bueno da Silva 1 Co-orientador: Cesar França 2 1 Centro de Informática Universidade Federal de Pernambuco (UFPE) Pernambuco, PE Brasil 2 Centro de Estudos Avançados de Recife (C.E.S.A.R) Pernambuco, PE Brasil {dmr,fabio}@cin.ufpe.br, franca@cesar.org.br Nível: Mestrado Ano de Ingresso: Março de Previsão de Conclusão: Março de 2015 Aprovação da Proposta: não qualificado Evento: SBES Resumo.Contexto A Engenharia de Software Baseada em Evidência é um importante paradigma que auxilia a pesquisa na Engenharia de Software, uma vez que ela busca sintetizar os resultados de diversos estudos empíricos em um só. No entanto, existem problemas relacionados a qualidade destas sínteses, visto que existe uma utilização maior de métodos de menor poder interpretativo, o que pode trazer uma menor qualidade da síntese. Métodos de maior qualidade interpretativa podem, por outro lado, consumir mais recursos (como tempo e esforço). Portanto existe a necessidade de clarificar pontos fortes e fracos de cada método de síntese. Objetivo Este trabalho tem como objetivo realizar um estudo comparativo com métodos de síntese de estudos mistos (qualitativos e quantitativos) de maior e menor qualidades interpretativas, para identificar pontos fortes e fracos destes métodos e em quais situações cada método pode ser melhor utilizado de acordo com os recursos existentes. Método A primeira fase foi uma revisão sistemática manual para encontrar os artigos que serão sintetizados, depois disso será realizada uma pesquisa de campo com pesquisadores que já realizaram revisões sistemáticas com o objetivo de identificar quais são os critérios mais importantes para escolha do método de síntese, a partir de um conjunto de critérios já apresentados por Dixon-Woods. Com os critérios estabelecidos, serão realizadas quatro sínteses com pesquisadores distintos que já realizaram revisões sistemáticas e ao final do processo serão comparados os resultados de cada síntese. Contribuições Esperadas Este trabalho tem como principais contribuições: (i) Apresentar um passo-a-passo de um conjunto de métodos de sínteses de pesquisa, (ii) Avaliar métodos que ainda não são largamente utilizados na Engenharia de Software, (iii) Expor um conjunto de critérios para a seleção de métodos de sínteses de pesquisa, (iv) Comparar os resultados das sínteses e esclarecer as vantagens e desvantagens de cada método. Palavras chaves: Engenharia de Software Baseada em Evidência, sínteses, revisão sistemática. 33

34 1. Caracterização do problema A Engenharia de Software Baseada em Evidência (ESBE) foi apresentada à comunidade por [Kitchenham 2007], a partir de conceitos utilizados com sucesso em outras áreas de pesquisa, como a medicina por exemplo. O paradigma baseado em evidências consiste na coleta e análise sistemáticas de dados empíricos disponíveis sobre um determinado fenômeno, a fim de obter uma perspectiva mais ampla e mais completa do que seria obtido a partir de um estudo individual [Kitchenham 2007], e tem como ferramenta para auxílio à revisão sistemática da literatura. Métodos de síntese de pesquisa são utilizados para resumir, integrar, combinar e comparar resultados de diferentes artigos sobre determinado tópico ou questão de pesquisa com o objetivo de apresentar novas interpretações, argumentos, teorias, e identificar áreas que precisam de uma concentração maior de esforços na resolução dos seus problemas [Dixon-Woods et al. 2005; Noblit e Hare 1988; Cruzes e Dyba 2011]. Apesar das revisões sistemáticas apresentarem resultados importantes para a Engenharia de Software, [Silva et al. 2011] acredita que as sínteses de estudos primários frequentemente não estão sendo conduzidos de maneira adequada. Além disso, um estudo executado por [Cruzes e Dyba 2011] aponta que 83,7% dos estudos realizados na Engenharia de Software utilizam algum método com pouca ou razoável qualidade interpretativa (estudo de escopo 49%, síntese temática 16,3% e síntese narrativa 18,4%) de acordo com a classificação de qualidade interpretativa proposta por [Sandelowski e Barroso 2006 ], enquanto que cerca de 8,1% ( Meta-análise 4,1%, Meta-etnografia 2% e Case Survey 2%) dos estudos utilizam um método de síntese com uma maior qualidade interpretativa ou integrativa. Apesar de já existirem esforços para melhorar a qualidade das sínteses e apresentar novos métodos [Cruzes e Dyba 2010; Cruzes e Dyba 2011; Silva et al. 2013], ainda é observado que existem dificuldades nas escolhas e suas utilizações corretas. Portanto, o objetivo deste trabalho é realizar um estudo comparativo com um conjunto de métodos de sínteses de maior e menor qualidade interpretativa para clarificar em quais situações cada tipo de método pode ser considerado adequado, de acordo com as necessidades e limitações dos pesquisadores. 2. Fundamentação Téorica 2.1. Engenharia de Software Baseada em Evidência De acordo [Kitchenham 2004], a ESBE é relevante para a Engenharia de Software, pois fornece os insumos necessários que podem ajudar os engenheiros de software na busca das melhores práticas, usando as tecnologias apropriadas e por consequência evitando as tecnologias inadequadas. [Budgen et al. 2007] afirmam que devido a sua essência, a ESBE tem o potencial de criar uma base muito mais sólida para os padrões, políticas e práticas o que também pode gerar uma melhor qualidade do software, resultado em benefícios para clientes e usuários. As Revisões Sistemáticas de Literatura são métodos utilizados pela ESBE que tem como objetivo aplicar uma abordagem baseada em evidência na pesquisa em Engenharia de Software. Revisões sistemáticas devem prover meios de executar revisões na literatura com uma maior qualidade devido às mesmas buscarem ser mais 34

35 abrangentes e menos tendenciosas, produzindo resultados com maior valor científico, de acordo com [Travassos e Biolchini 2007]. Para realizar isso, a revisão sistemática é dividida em três passos: (i) Planejamento da revisão, onde a revisão é estruturada e o protocolo é desenvolvido; (ii) Condução da revisão, onde os estudos primários são selecionados e lidos e (iii) Resultados da pesquisa, onde os dados extraídos devem ser integrados ou interpretados e uma síntese dos mesmos deve ser realizada [Miranda 2011] Sínteses na Engenharia de Software Baseada em Evidência [Noblit e Hare 1988] classificam sínteses de pesquisa em integrativa e interpretativa. A síntese de pesquisa integrativa visa analisar a combinação de um conjunto de dados de estudos primários que são semelhantes com relação a intervenções e variáveis quantitativas. Este tipo de síntese é bastante usado na área de saúde, e tem como principal método a meta-análise. Já a síntese interpretativa visa avaliar os estudos, que podem ser heterogêneos, e fornecer explicações interpretativas sobre eles, criando assim uma teoria que agrega diversos conceitos provenientes dos estudos primários. Exemplos de métodos interpretativos são: meta-etnografia, meta-sumário qualitativo e metasíntese qualitativa. De acordo com [Cruzes e Dyba 2011], os estudos na Engenharia de Software são frequentemente muito heterogêneos para permitir uma relação estatística e, portanto o uso de meta-análise, por isso os métodos de síntese qualitativos e mistos são necessários para um melhor entendimento da área. 3. Contribuições Esta dissertação tem quatro contribuições principais para ESBE, são elas: Apresentar um passo-a-passo de um conjunto de métodos de sínteses de pesquisa; uma vez que vamos utilizar 4 métodos (meta-sumário qualitativo, meta-síntese qualitativa, análise de conteúdo e síntese narrativa), a dissertação poderá ser usada por outros pesquisadores como guia para realizar suas sínteses. Avaliar métodos que ainda não são largamente utilizados na Engenharia de Software, como meta-sumário qualitativo e meta-síntese qualitativa, mas que são utilizados em outras áreas, de maneira que além de produzir o passo-a-passo de sua utilização sejam também entendidos seus pontos fortes e fracos, semelhante ao trabalho realizado por [Silva et al. 2013] na meta-etnografia. Expor um conjunto de critérios para a seleção de métodos de sínteses de pesquisa: Uma vez que exista um conjunto de critérios para seleção do método de síntese, se tornará mais claro como escolher o mais adequado para a situação. Comparar os resultados das sínteses e esclarecer as vantagens e desvantagens de cada método de maneira que outros pesquisadores estejam cientes deles quando escolherem utilizá-los. Os resultados desta dissertação poderão auxiliar na escolha do método de síntese de acordo com a necessidade dos pesquisadores, esclarecendo também que aquela escolha poderá acarretar, por exemplo, que uma síntese tenha um maior ou menor grau de interpretatividade, ou mesmo tenha um maior ou menor grau de complexidade na sua realização. 35

36 4. Estado atual do trabalho Uma vez que a pesquisa é sobre métodos de sínteses, foi necessário obter um conjunto de artigos para serem sintetizados. Por isso, foi realizada uma revisão sistemática manual em quatro revisões sistemáticas [Cardozo 2012; Cruz et al. 2011; França et al. 2011; Miranda 2011] realizadas pelo grupo HASE (Human Aspects in Software Engineering) o qual os pesquisadores fazem parte. Estas revisões apresentaram um total de 281 artigos que tiveram seus títulos, resumos e métodos lidos por uma dupla de pesquisadores. Vale salientar que o principal objetivo da pesquisa é avaliar os métodos de sínteses e não utilizar os resultados provenientes da aplicação das mesmas para formação de uma teoria real sobre o que afeta a performance na Engenharia de Software. Por isso, uma vez que era necessário diminuir a quantidade de artigos para viabilizar a avaliação dos métodos de síntese propostos, foram selecionados apenas 15 artigos que apresentavam evidências sobre antecedentes de performance em equipes de software. A partir daí foram extraídos métodos, coleta de dados e resultados. Já foi realizado um estudo com os 15 artigos [Ribeiro et al. 2014] utilizando meta-sumário qualitativo em que foi observado que o método pode ajudar a Engenharia de Software Baseada em Evidência, pois seus resultados trazem uma maior interpretatividade devido aos passos recomendados no método, no entanto, não são tão poderosos quanto o da meta-etnografia que por sua vez é mais complexa e leva mais tempo para ser realizada. Além disso, já foi retirado de [Dixon-Woods et al. 2005] um conjunto de critérios (possibilidade de utilização de grande base de evidências, possiblidade de aceitar evidências de tipos diferentes, flexibilidade, possibilidade para ser usado na construção de teoria, buscar teorias de ordem superior, possiblidade de ser auditável por revisores, software disponíveis para sua realização, complexidade e sistematização) que serão analisados e deverão passar por um conjunto de pesquisadores que já realizaram sínteses em revisões sistemáticas para que seja avaliados quais critérios recebem maior consideração quando um pesquisador escolhe seus métodos de síntese. Por fim, a nossa pesquisa ainda irá selecionar pesquisadores para utilizar diferentes métodos de sínteses, para que assim possam ser avaliadas suas utilizações. O cronograma pode ser observado em: 5. Comparações com trabalhos relacionados Cruzes e Dyba [Cruzes e Dyba 2010, Cruzes e Dyba 2011] identificaram os métodos de síntese mais utilizados na Engenharia de Software e apresentam uma pequena descrição dos mesmos e um conjunto de desafios e forças dos métodos proveniente da pesquisa realizada na área de saúde por [Dixon-Woods et al. 2005]. O nosso trabalho se diferencia dos trabalhos realizados por Cruzes e Dyba, pois iremos conduzir uma avaliação experimental de cada método. Ele também difere do trabalho realizado por [Dixon-Woods et al. 2005] porque será realizado pela ótica da Engenharia de Software. O artigo desenvolvido por [Silva et al. 2013] sugere um passo-a-passo para utilizar meta-etnografia e apresenta o resultado de sua síntese como um exemplo de sua utilização. Os autores ainda fazem uma análise dos pontos fortes e fracos de sua utilização baseada nas dificuldades que tiveram. Nosso estudo será realizado de maneira semelhante a esse trabalho, no entanto utilizará outros métodos de síntese, e tentará classificar de acordo com os critérios observados por Dixon-Woods. Por fim, iremos 36

37 comparar os resultados de todas as sínteses desta etapa. Além desses, outros trabalhos que tentam melhorar a qualidade da ESBE também serão utilizados [Kitchenham et al. 2011; Kitchenham et al. 2012]. 6. Avaliações dos resultados Para definir quais critérios são mais interessantes para os pesquisadores, será realizado uma pesquisa de campo com os autores das 120 revisões sistemáticas identificados nos estudos terciários [Kitchenham et al. 2010; Silva et al. 2011]. Após essa etapa, esperase identificar quais fatores os pesquisadores levaram em consideração para realizar a sua síntese e quais são os mais importantes. Por fim, o primeiro pesquisador irá realizar um treinamento com outros pesquisadores sobre meta-síntese qualitativa, análise de conteúdo e síntese narrativa para que esses pesquisadores possam aplicar um desses métodos e o primeiro pesquisador possa avaliar a utilização deles de acordo com os fatores identificados. Estes métodos foram escolhidos devido a sua pouca utilização na ESBE (metasumário qualitativo e meta-síntese qualitativa) ou sua larga utilização (síntese narrativa e análise de conteúdo) e suas qualidades interpretativas [Cruzes e Dyba 2011, Sandelowski 2006]. Com isso o autor poderá comparar os resultados, criando um quadro comparativo com os pesos extraídos da pesquisa de campo, tentando explicar assim suas vantagens e desvantagens para a Engenharia de Software. 7. Agradecimentos Fabio Q. B. da Silva recebe uma bolsa de pesquisa do CNPq, processo #314523/ Danilo Monteiro Ribeiro recebe uma bolsa de pesquisa do CNPq, processo #132554/ Referências Budgen, D., Turner, M., Brereton, P., Kitchenham, B. (2007) Using Mapping Studies in Software Engineering, Cardozo, E. (2012). Mapeamento Sistemático sobre o uso do Autogerenciamento em Equipes de Desenvolvimento de Software. Pós-Graduação em Ciência da Computação. Centro de Informática. Universidade Federal de Pernambuco. Dissertação de Mestrado. Cruz, S., Silva, F., Monteiro, C., Santos, P., Santos, I. (2011) Personality in software engineering: Preliminary findings from a systematic literature review. In: 15th International Conference on Evaluation and Assessment in Software Engineering, Durham, p 1-10 Cruzes, D., and Dyba, T. (2011), Research synthesis in software engineering: A tertiary study. Information and Software Technology, Volume 53, Issue 5, May, 2011 p Cruzes, D., and Dyba, T. (2010), Synthesizing evidence in software engineering research. In 4th International Symposium on Empirical Software Engineering and Measurement (ESEM'10), pages 1-10, Bolzano/Bozen, Italy, Sept ACM. Dixon-Woods, M.,Agarwal,S.,Jones, D., Young,B. Sutton, A. (2005) Synthesising qualitative and quantitative evidence: a review of possible methods, J. Health Ser. 37

38 Res. Policy 10 (1) p Dyba, T.; Dingsøyr, T. (2008) Empirical studies of agile software development : A systematic review. Information and Software Technology. Volume 50, Issue 9-10,p França, C., Gouveia, T., Santos, P., Santana, C., Silva, F. (2011) Motivation in Software Engineering: a Systematic Review Update In: 15th International Conference on Evaluation and Assessment in Software Engineering, Durham, p Kitchenham, B. (2007) Guidelines for Performing Systematic Literature Reviews in Software Engineering. Technical Report, Department of Computer Science, University of Durham, Kitchenham, B. Brereton P., and Budgen D (2012) Mapping study completeness and reliability a case study Evaluation and Assessment in Software Engineering EASE, p Kitchenham, B., Brereton P., and Budgen D (2011) Using mapping studies as the basis for further research A participant-observercase study Information & Software Technology Volume 53, Issue 6, p Kitchenham, B., Pretorius, R., Budgen, D., Brereton, O., Tuner, M., Niazi, M., Linkman, S.(2010) Literature reviews in software engineering a tertiary study, Information and Software Technology, Volume 52, Issues 8, p Miranda, R. (2011) Uma Revisão Sistemática Sobre Equipes de Desenvolvimento de Software: Tipologia, Características e Critérios de Formação" Dissertação de mestrado, Universidade Federal de Pernambuco Noblit, G.W and Hare G.W.(1988), Meta-ethnography: Synthesizing Qualitative Studies, Sage. Ribeiro, D., França, C., Silva, F., Cardoso, M. (2014) Using Qualitative Metasummary to Synthesize Empirical Findings in Literature Reviews In International Symposium on Empirical Software Engineering and Measurement (ESEM) Silva, F., Santos, A., Soares., S França, C., Monteiro, C., Maciel, F. (2011) Six years of systematic literature reviews in software engineering: An updated tertiary study. In Information and Software Technology, Volume 53, p Silva, F., Cruz, S., Gouveia, T., and Capretz, L. (2013) Using meta-ethnography to synthesize research: A worked example of the relations between personality. International Symposium on Empirical Software Engineering and Measurement (ESEM), Issue 7, p

39 EvolTrack-Process: Uma ferramenta para visualização e acompanhamento da colaboração em processos de software Francisco Werther Silva de Santana Júnior Orientadores: Cláudia Maria Lima Werner, Andréa Magalhães Magdaleno Programa de Pós-Graduação em Engenharia de Sistemas e Computação COPPE/UFRJ Caixa Postal CEP Rio de Janeiro, RJ {fwsantana, werner, andrea}@cos.ufrj.br Nível: Mestrado Ano de Ingresso: 2012 Previsão de conclusão: Março/2015 Aprovação da Proposta: Julho de 2013 Eventos Relacionados: SBES Resumo. Embora reconhecida como essencial para o desenvolvimento de software, a colaboração é pouco explorada no contexto de processos de software, tida em geral como um elemento que surge naturalmente e que não pode ser previsto ou planejado. Lidar com a colaboração de forma mais explícita pode oferecer melhorias para processos, conferindo maior eficiência ao desenvolvimento e qualidade ao produto final. Esta dissertação de mestrado tem como objetivo oferecer mecanismos para explicitar e acompanhar a colaboração em processos de software, propondo para isso a utilização de técnicas de visualização interativas aplicadas aos processos através de uma ferramenta denominada EvolTrack-Process. Palavras-chave: processos de software; colaboração; técnicas de visualização. 39

40 1. Caracterização do Problema Para conseguir uma maior chance de sucesso no desenvolvimento de software, um processo independentemente do seu nível de formalidade deve ser definido e seguido [Fuggetta 2000]. Ainda de acordo com essas pesquisas, melhorias na qualidade do processo podem refletir na qualidade do produto desenvolvido, bem como auxiliar empresas a atingir seus objetivos e cumprir os seus prazos em um negócio onde o tempo de mercado pode ser decisivo. Além de tarefas, artefatos e agentes, processos de software também definem outros elementos e características fundamentais para o desenvolvimento de sistemas que não são imediatamente reconhecidos em diagramas e modelos, como por exemplo a colaboração entre os envolvidos na sua produção. Uma vez que o desenvolvimento de software não-trivial é um exemplo típico de trabalho colaborativo, no qual diferentes agentes assumem diversos papeis e executam tarefas interdependentes, a colaboração é essencial para a produção de software, quer esse desenvolvimento ocorra em um mesmo local ou em um ambiente distribuído [Herbsleb et al., 2005, de Souza et al., 2011]. Apesar de sua importância, a colaboração é muitas vezes negligenciada durante a definição do processo, sendo tipicamente considerada como algo que surge naturalmente e não pode ser prevista, muito menos planejada [Magdaleno 2013]. Com relação às ferramentas, apesar de existirem várias abordagens para enfrentar as dificuldades e desafios em matéria de processos entre essas soluções, Process-centered Software Engineering Environments (PSEEs) e Business Process Management Systems (BPMS) a colaboração não é seu foco e acaba restrita à alocação de agentes. Nesse cenário, se torna difícil entender e acompanhar como ocorre a colaboração entre os agentes nos processos de software sem ferramental de apoio dedicado, dando origem a seguinte questão de pesquisa: Como explicitar e acompanhar a colaboração em processos de software?. A hipótese considerada é de que técnicas de visualização podem auxiliar nessa compreensão e acompanhamento da colaboração, e que as mesmas técnicas gerais aplicadas na visualização de software também podem ser úteis no contexto de processsos. O objetivo dessa dissertação de mestrado é construir uma ferramenta para visualizar e monitorar a colaboração em processos de software, visando auxiliar na gestão e evolução de processos a partir do acompanhamento de execuções em andamento ou de instâncias de processo previamente executadas. 2. Fundamentação Teórica Os trabalhos que motivam e fundamentam a proposta desse trabalho são aqueles que abordam colaboração em processos (Seção 2.1) e técnicas de visualização (Seção 2.2) Colaboração em Processos A colaboração é foco de diversos estudos de processos, tanto no cenário de software como também em processos de negócio em geral. Essas propostas incluem a definição de processos de software que lidam mais explicitamente com colaboração, como o Collaborative Software Process [Williams 2000], um modelo de processo composto por 40

41 uma série de formulários, checklists e atividades adaptadas para a prática de desenvolvimento em pares, visando ampliar a percepção de desenvolvedores e facilitar o trabalho em equipe. Voltada para processos de negócios, existe a iniciativa BPM4People [Brambilla et al., 2012], que propôs uma extensão da Business Process Model and Notation (BPMN), incluindo novas representações de caráter colaborativo, como por exemplo a noção de atividades onde os agentes que a realizarão serão convidados durante a execução. Em outra linha de trabalhos, alguns pesquisadores propuseram modelos de maturidade e sistemáticas voltados explicitamente para colaboração [Magdaleno et al., 2011]. Os modelos de maturidade atuam como um roteiro, definindo um conjunto ordenado de práticas para a melhoria incremental, comparação ou avaliação da situação atual das organizações, apresentando etapas e guias para colocar a empresa em um caminho evolutivo, partindo de um processo caótico ad-hoc até um ambiente controlado e mais disciplinado. Há ainda a COMPOOTIM [Magdaleno 2013], uma sistemática para gestão da colaboração nos processos compostos para projetos de software, com propósito de apoiar gerentes de projeto. É importante notar que esses modelos de processo e maturidade reconhecem que algumas de suas práticas são difíceis de cumprir sem o apoio de ferramentas apropriadas, reforçando a importância de iniciativas como a ferramenta proposta por essa dissertação Técnicas de Visualização Técnicas de visualização da informação têm sido empregadas com sucesso por pesquisadores que tentam entender as características de um software, especialmente aqueles relacionados à estrutura, comportamento e evolução, dando origem a subárea de visualização de software [Diehl 2007]. A motivação geral para a utilização de técnicas de visualização de software está na facilidade para a detecção de padrões e estruturas, difíceis de serem analisados sob a forma de dados brutos sem representações gráficas associadas. No contexto de processos, o uso de visualizações é reconhecidamente importante para a avaliação, representação e comunicação dos estados de um processo, sendo um desafio o desenvolvimento de técnicas e novos paradigmas para transmitir informações de um processo de forma intuitiva [Fugetta & Nitto, 2014]. Em nosso trabalho em particular, é esperado que o uso de visualizações facilite a avaliação da colaboração medida nos processos, apresentando informações tipicamente difíceis de serem interpretadas em conjunto sob uma forma visual integrada interativa e mais intuitiva. 3. Contribuições A principal contribuição dessa proposta é a criacão de uma ferramenta, denominada EvolTrack-Process. A ferramenta está inserida dentro do projeto EvolTrack, que tem por objetivo o rastreamento e visualização da evolução de projetos de software sob diferentes perspectivas [Cepeda et al., 2010]. A ideia é criar novas perspectivas na infraestrutura oferecida pelo EvolTrack, oferecendo aos usuários uma coleta de dados automatizada e visualizações interativas acerca de processos de software com foco em colaboração. Dentre as possibilidades de uso da EvolTrack-Process, destacam-se: 41

42 A visualização de redes de colaboração entre agentes envolvidos na execução das atividades dos processos, incluindo dados da localização geográfica; A visualização de informações relacionadas às atividades de processos, incluindo a comparação do tempo gasto para sua realização em outras instâncias e informações sobre atores que já desempenharam as atividades na organização através de gráficos de área empilhada e de linha; A visualização de como um processo foi evoluindo e se modificando ao longo do tempo através da comparação simultânea de várias instâncias, possibilitando a identificação de desvios na execução do processo e de agentes que são alocados com frequência para as atividades através da reconstrução de vários modelos do mesmo processo apresentados de forma integrada; A interação com as visualizações, possibilitando, por exemplo, a obtenção de informações mais detalhadas sobre uma determinada atividade do processo durante a análise de um modelo, mostrando diferenças de tempo de execução da atividade nas suas execuções. Uma vez concluída, essa ferramenta poderá contribuir para a gestão e evolução de processos de software, conferindo à organização uma maior compreensão de seus processos, facilitando, por exemplo, a alocação de recursos humanos para as atividades, ou o reconhecimento de problemas durante a execução de uma instância em particular. Outra contribuição importante desse trabalho está na avaliação do uso de visualizações para acompanhar a colaboração em processos de software. Embora a utilização de visualizações aplicadas em processos não seja uma novidade desse trabalho, a coleta de indícios sobre a eficácia do uso de visualização no apoio aquilo que se propõem auxiliar não era uma preocupação desses estudos anteriores, dificultando a escolha de técnicas adequadas para apresentação das informações de processos. Dessa forma, uma vez concluídos os estudos planejados para o protótipo, será possível coletar indícios sobre a utilização das visualizações adotadas nessa proposta, avaliar se são apropriadas para outros trabalhos que tenham objetivos similares ou reforçar a necessidade do desenvolvimento de novas técnicas de visualização mais específicas. 4. Estado Atual Foram propostas as seguintes atividades para esse trabalho: duas revisões informais da literatura, uma com foco em indicadores de colaboração e outra em técnicas de visualizações de processo; a elaboração do projeto técnico e implementação da ferramenta proposta; e, finalmente, o planejamento e execução da avaliação da solução, bem como a análise de seus resultados. Dentre essas atividades, ambas as revisões informais da literatura já foram realizadas, identificando diversos trabalhos e técnicas importantes para a proposta. Em relação ao desenvolvimento da ferramenta, o projeto técnico de alguns módulos já foi finalizado e um protótipo está em desenvolvimento. Atualmente, estão sendo escolhidas as técnicas de visualização de software que serão utilizadas, incluindo grafos para retratar a interação sociotécnica entre os atores, 42

43 acrescentado de um mapa mostrando a distribuição geográfica dos mesmos, a representação do processo usando o metamodelo definido pelo Software & System Process Engineering Meta-Model (SPEM) uma notação proposta especificamente para o contexto de software, definida como padrão pelo Object Management Group (OMG), e outras técnicas de visualização mais tradicionais, como gráficos de área empilhada e diagramas de caixa para dados com possível relevância estatística. 5. Avaliação dos Resultados A avaliação planejada para o trabalho se dará sobre a ferramenta desenvolvida, a partir de estudos com objetivo de caracterizar a aplicabilidade de técnicas de visualização de software para a visualização e acompanhamento da colaboração em processos. Para tanto, foi planejado o uso de dois questionários diferentes aplicados a duas populações distintas: uma composta por participantes advindos da indústria de software, usando dados de instâncias de seus próprios processos; e outro usando a comunidade acadêmica, envolvendo a utilização de dados de processos fictícios criados para ilustrar cenários de utilização da ferramenta. Esse tipo de estudo foi escolhido diante da dificuldade para a realização de experimentos na área de processos de software, onde os custos e riscos associado ao acompanhamento ao longo de todo o processo de desenvolvimento de um sistema, inserindo dois tratamentos, com e sem a ferramenta proposta nesse trabalho, torna o método inviável. Com essa pesquisa, espera-se obter dados do potencial de uso da ferramenta proposta e, consequentemente, da utilidade de visualizações para o acompanhamento da colaboração em processos de software. 6. Comparação com Trabalhos Relacionados Assim como essa proposta, outros trabalhos foram realizados com o objetivo de enriquecer a percepção de usuários acerca de processos de software. Os trabalhos de visualização de software com foco em processo, tal como [Rilling et al., 2007], têm como objetivo a representação de elementos de processos de software, desenvolvendo suas próprias metáforas visuais ou usando técnicas já existentes. Esses trabalhos podem servir como inspiração para algumas visualizações utilizadas em nossa proposta, mas nenhum deles tem um foco específico em colaboração em processos de software. Os trabalhos de mineração de processos, tal como [van der Aalst et al., 2007], têm como objetivo a identificação automática de relações a partir de logs de execução de processos. Embora grande parte dessas ferramentas utilize técnicas que também são importantes para essa proposta, sobretudo relacionadas à coleta de dados de processos, os objetivo são diferentes: enquanto ferramentas de mineração visam extrair relações relevantes automaticamente, nossa proposta tem como intenção oferecer visualizações para que o usuário tome conclusões com base em sua experiência, além de poder ser utilizada sem a necessidade de um grande volume de execuções de processos anteriores. Finalmente, as ferramentas que promovem colaboração, como as discutidas em [Costa et al., 2011], têm como objetivo oferecer aos usuários facilidades para trabalhar em equipe, através da ampliação da percepção de suas atividades, por facilitar a 43

44 coordenação de suas atividades, entre outros aspectos associados a colaboração. Todavia, essas ferramentas tipicamente têm foco voltado para os desenvolvedores de software, apresentando informações advindas de lista de mensagens e repositórios de controle de versão, deixando de lado elementos de processos. Referências van der Aalst, W. M. P., Reijers, H. A., Weijters, A. J., van Dongen, B. F., de Medeiros, A. K., Song, M. Verbeek, H. M. (2007). Business process mining: An industrial application. Inf. Syst. 32, 5, pp Brambilla, M., Fraternali, P., Vaca, C., Butti, S. (2012). Combining Social Web and BPM for Improving Enterprise Performances: the BPM4People Approach to Social BPM, WWW2012 Conference, European-projects track, Lyon, France, pp Cepeda, R. S. V., Magdaleno, A. M., Murta, L. G. P., Werner, C. M. L. (2010). EvolTrack: improving design evolution awareness in software development, Journal of the Brazilian Computer Society, v. 16, pp Costa, J. M., Cataldo, M., de Souza, C. R. B. (2011). The scale and evolution of coordination needs in large-scale distributed projects: implications for the future generation of collaborative tools. Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI '11), Vancouver, BC, pp Diehl, S. (2007). Software Visualization: Visualizing the Structure, Behaviour, and Evolution of Software, Springer Press. Fuggetta, A. (2000). "Software process: a roadmap". In: Proceedings of the Conference on The Future of Software Engineering, pp , Limerick, Ireland. Fuggetta, A., Nitto, E. (2014). Software process. In: Proceedings of the on Future of Software Engineering (FOSE 2014). ACM, New York, NY, USA, pp Herbsleb, J. D., Paulish, D. J., and Bass, M. (2005). Global software development at siemens: experience from nine projects. Proceedings of the 27th international conference on Software engineering, St. Louis, MO, USA: ACM, pp Magdaleno, A. M., de Araujo, R. M., Werner, C. M. L. (2011). A roadmap to the Collaboration Maturity Model (CollabMM) evolution 15th International Conference on Computer Supported Cooperative Work in Design (CSCWD), Lausanne, Switzerland, vol. 105, no. 112, pp Magdaleno, A. M. (2013). Compootim: em direção ao planejamento, acompanhamento e otimização da colaboração na definição de processos de software. PhD dissertation, COPPE, UFRJ. Rilling, J., Meng, W.J., Fuzhi C., Charland, P. (2007) Software Visualization - A Process Perspective, IEEE International Workshop on Visualizing Software for Understanding and Analysis, VISSOFT 2007, Alberta, Canada, pp de Souza, C. R. B., Marczak, S., Prikladnicki, R. 2011, Desenvolvimento colaborativo de software, Sistemas Colaborativos, Rio de Janeiro, RJ, Brasil: Elsevier. Williams, L. (2000). The Collaborative Software Process. PhD dissertation, The University of Utah. 44

45 Execução paralela de programas como suporte ao teste de mutação Stevão Alves de Andrade 1, Orientador: Márcio Eduardo Delamaro 1 1 Instituto de Ciências Matemáticas e de Computação (ICMC) Universidade de São Paulo (ICMC/USP) Caixa Postal São Carlos SP Brasil {stevao,delamaro}@icmc.usp.br Abstract. This paper presents a Master s Degree project under development that aims to propose a solution for decreasing the computational cost involved in applying mutation testing. There are being investigated alternatives for parallelization of test run by applying techniques of concurrent programming. Thus, studies are being conducted aiming to identify phases of testing that require a greater cost during its execution, in order to improve efficiency when applying a solution with use of parallelization techniques. Resumo. Este artigo apresenta um projeto de mestrado em desenvolvimento que tem como objetivo propor uma solução para a redução do custo computacional envolvido na aplicação do teste de mutação. Estão sendo investigadas alternativas para paralelização da execução do teste aplicando técnicas de programação concorrente. Neste sentido, estudos vêm sendo conduzidos com objetivo de identificar as fases do teste que exigem maior custo durante sua execução, com intuito de melhorar sua eficiência ao aplicar uma solução com uso de técnicas de paralelização. 1. Introdução Dentre as técnicas de verificação e validação de software, a atividade de teste é uma das mais utilizadas, constituindo-se em uma técnica para fornecer evidências da confiabilidade de um produto, consistindo em uma análise dinâmica do produto [Delamaro et al. 2007]. Em geral, os critérios de teste de software são estabelecidos a partir de três técnicas: a funcional, a estrutural e a baseada em erros. Na técnica baseada em erros, que é o foco deste trabalho, os critérios e requisitos de teste são derivados a partir dos erros típicos cometidos no processo de desenvolvimento de software [Myers et al. 2004]. Um dos critérios baseados em erros é o Teste de Mutação. Esse critério surgiu com o objetivo de avaliar a efetividade/qualidade de um conjunto de casos de teste. Os erros típicos de um domínio ou paradigma de desenvolvimento são caracterizados e desenvolvidos como operadores de mutação que, durante a atividade de teste, geram versões modificadas (mutantes) do programa em teste. A intenção, com isso, é auxiliar na seleção de casos de teste que demonstrem que os erros modelados pelos operadores de mutação não estão presentes no programa em teste [Delamaro and Maldonado 1999]. Além de ser uma técnica eficaz quando aplicada para testar um programa, essa técnica tem sido amplamente utilizada para avaliar a eficácia de outras técnicas de validação 45

46 em revelar defeitos. Experimentos são conduzidos para avaliar o quanto que uma técnica ou critério de teste é capaz de revelar defeitos modelados pelos operadores de mutação. A vantagem do uso de teste de mutação nesse contexto é o fato dessa abordagem apresentar um processo bem definido e preciso para semear os defeitos no produto a ser avaliado. Isso facilita a replicação dos resultados em outros experimentos [Andrews et al. 2005]. 2. Caracterização do Problema Um dos maiores problemas para a aplicação do teste de mutação está relacionado ao seu alto custo computacional, uma vez que o número de mutantes gerados, mesmo para pequenos programas, pode ser muito grande. Esse custo está relacionado ao tempo de análise dos mutantes, normalmente realizado manualmente [Delamaro et al. 2007] e com o tempo necessário para executar os mutantes gerados, representado pela seguinte equação [Mateo and Usaola 2013]: Mt = Gt * Nm + Et * Nt * (Nm + 1) Onde Mt é o tempo total da aplicação da técnica, Gt é o tempo para a geração de um único mutante, Et é o tempo de execução para um caso de teste, Ntc é o número total de casos de teste e Nm o número de mutantes gerados. Abordagens como a geração automática de casos de testes possibilitam a verificação do sistema de maneira intensiva. A geração de dados de teste é um processo de identificação de dados do domínio de entrada válidos para um programa de acordo com os critérios de teste e é utilizada com objetivo de verificar se uma dada implementação contém falhas [Korel 1990]. Quando aplicada em conjunto ao teste de mutação, os mutantes gerados precisam ser executados diversas vezes com um número elevado de casos de teste, o que faz com que a eficiência na execução do critério se torne ainda mais importante. Além disso, avaliações experimentais necessitam que mutantes gerados sejam executados com todo o domínio de casos de teste disponíveis, para que os dados referentes ao processo possam ser colhidos para análise. Várias estratégias foram desenvolvidas com o objetivo de reduzir esses custos, dentre as quais se destacam a utilização de arquiteturas de hardware avançadas para reduzir o tempo de execução dos mutantes [Choi and Mathur 1993], a determinação de um conjunto reduzido e efetivo de operadores de mutação[barbosa 1998, Mathur and Wong 1993, Offutt et al. 1996] e abordagens para reduzir o número de mutantes gerados com uso de análise estatística de anomalias de fluxo de dados [Marshall et al. 1990]. Uma importante técnica para redução de custo é a execução paralela, a qual é amplamente explorada em outros contextos, como previsão de tempo, dinâmica de fluídos, processamento de imagens, química quântica entre outros [Quinn 2004]. Em [Jia and Harman 2011] é apresentado um survey sobre o teste de mutação e são descritas técnicas para a paralelização da execução do teste de mutação. Em geral as abordagens concentram-se em explorar diferentes arquiteturas computacionais disponíveis na época. Com os avanços computacionais atuais, novas abordagens podem ser exploradas visando aperfeiçoar essa paralelização, incluindo o uso de clusters. 46

47 3. Caracterização da Contribuição O objetivo deste trabalho é propor uma alternativa para melhorar a eficiência da aplicação do teste de mutação reduindo o tempo de resposta envolvido na aplicação da técnica. Pretende-se desenvolver um modelo para a aplicação do teste de mutação utilizando técnicas de programação concorrente com objetivo de aperfeiçoar os recursos computacionais utilizados durante essa atividade, considerando questões fundamentais como disponibilidade e escalabilidade. Com base nos objetivos do projeto e nas atividades a serem realizadas durante a sua condução, esperam-se que os seguintes resultados sejam atingidos: Contribuir com a atividade de teste de mutação, por meio da definição de um modelo para a aplicação do teste de mutação adaptado aos moldes de programas concorrentes; Instanciar para a ferramenta Proteum [Delamaro 1993] o modelo proposto, objetivando aumentara eficiência da aplicabilidade do critério; Viabilizar a aplicação do teste de mutação em conjunto com outras abordagens como, por exemplo, geração automática de dados de teste, de forma a tornar uma alternativa prática para verificação intensiva do produto em teste; Gerar resultados e discussões com base na experimentação dos resultados obtidos e comparar com outras abordagens existentes. 4. Estado Atual do Trabalho Para fornecer os subsídios teóricos necessários para a conclusão dos objetivos deste projeto, inicialmente foi realizada uma investigação de conceitos básicos relacionados à área de engenharia de software e programação concorrente. Entre as atividades que estão sendo desenvolvidas, pode-se destacar: Decomposição da atividade do teste de mutação em pequenas porções com objetivo de identificar quais atividades podem ser executadas de maneira concorrente ou em paralelo; Criação do grafo de dependência entre de tarefas identificadas. Com base na decomposição das atividades, o objetivo é identificar as porções de trabalho que são dependentes entre si; Mapear as tarefas que podem ser executadas em diferentes processadores; Implementação dos algoritmos de balanceamento de carga apresentados em [Mateo and Usaola 2013]; Adequação da ferramenta de teste de mutação Proteum [Delamaro 1993] para execução em paralelo, fazendo uso dos algoritmos de balanceamento de carga. 5. Trabalhos Relacionados Existem diversos trabalhos na literatura que tratam sobre a execução paralela de mutantes. Em um survey sobre mutação [Jia and Harman 2011] identificaram três linhas de investigação: (i) execução de mutantes em máquinas de única instrução e múltiplos dados (SIMD), (ii) execução de mutantes em máquinas de múltiplas instruções e múltiplos dados (MIMD) e (iii) uso de algoritmos seriais otimizados. Além dessas abordagens, também 47

48 é possível destacar o trabalho apresentado em [Mateo and Usaola 2013], que versa sobre algoritmos de balanceamento de carga. Esses trabalhos se relacionam com este trabalho de Mestrado por apresentarem abordagens semelhantes a qual está sendo desenvolvida neste. No entanto, diferenciam-se por serem abordagens aplicadas em contextos diferentes. Esses trabalhos, em sua maioria, servem como base para adaptação de padrões e criação de métricas que vêm sido desenvolvidos neste projeto de Mestrado. 6. Avaliação dos Resultados Pretende-se avaliar os resultados obtidos aplicando métricas de avaliação de desempenho. A avaliação de desempenho tem como objetivo avaliar e analisar o desempenho do software, com intuito de entender melhor o seu comportamento. Além disso, fornece informações importantes para tomadas de decisões de projeto e implementação, necessárias para a melhoria de um produto. Nesse sentido, entende-se que é a abordagem mais apropriada a ser utilizada para validar os resutados obtidos por meio de experimentos. Dentre as avaliações que pretende-se realizar, destacam-se: Instanciar a abordagem de execução paralela do teste de mutação, proposta na ferramenta de teste de mutação Proteum; Avaliar, por meio de experimentos científicos, o ganho em eficiência (speedup) da versão paralela da ferramenta Proteum em relação à versão sequencial existente; Realizar estudo comparativo à abordagem apresentada em [Mateo and Usaola 2013], com intuito de verificar o comportamento dos algoritmos de balanceamento de carga apresentados, quando aplicados à ferramenta de teste de mutação Proteum. Referências Andrews, J., Briand, L., and Labiche, Y. (2005). Is mutation an appropriate tool for testing experiments? In International Conference on Software Engineering (ICSE/ 05), pages 15 21, St. Louis, Missouri, USA. Barbosa, E. F. (1998). Uma contribuição para a determinação de um conjunto essencial de operadores de mutação no teste de programas C. Master s thesis, ICMC-USP, São Carlos, SP. Choi, B. J. and Mathur, A. P. (1993). High-performance mutation testing. The Journal of Systems and Software, 1(20): Delamaro, M. E. (1993). Proteum - um ambiente de teste baseado na análise de mutantes. Master s thesis, Instituto de Ciências Matemáticas e de Computação da Universidade de São Paulo (ICMC/USP), São Carlos, SP. Delamaro, M. E. and Maldonado, J. C. (1999). Interface mutation: Assessing testing quality at interprocedural level. In International Conference of the Chile an Computer Science Society (19th SCCC), pages Delamaro, M. E., Maldonado, J. C., and Jino, M. (2007). Introdução ao teste de software. In Delamaro, M. E., Jino, M., and Maldonado, J. C., editors, Introdução ao Teste de Software, pages 1 7. Elsevier. Jia, Y. and Harman, M. (2011). An analysis and survey of the development of mutation testing. IEEE Transactions on Software Engineering, 37(5):

49 Korel, B. (1990). Automated software test data generation. IEEE Trans. Softw. Eng., 16(8): Marshall, A., Hedley, D., Riddell, I., and Hennell, M. (1990). Static dataflow-aided weak mutation analysis (sdawm). Information and Software Technology, 32(1): Special Issue on Software Quality Assurance. Mateo, P. R. and Usaola, M. P. (2013). Parallel mutation testing. Software Testing, Verification and Reliability, 23(4): Mathur, A. P. and Wong, W. E. (1993). Evaluation of the cost alternate mutation strategies. In VII Simpósio Brasileiro de Engenharia de Software (VII SBES), pages , Rio de Janeiro, RJ. Myers, G., Sandler, C., Badgett, T., and Thomas, T. (2004). The Art of Software Testing. Business Data Processing: A Wiley Series. Wiley. Offutt, A. J., Rothermel, A. J., Untch, R. H., and Zapf, C. (1996). An experimental determination of sufficient mutant operators. ACM Transactions on Software Engineering Methodology, 5(2): Quinn, M. (2004). Parallel Programming in C with MPI and OpenMP. McGraw-Hill Higher Education. McGraw-Hill Higher Education. 49

50 Um estudo sobre geração de testes com BETA: Avaliação e aperfeiçoamento João Batista de Souza Neto, Anamaria Martins Moreira (Orientadora) 1 Programa de Pós-Graduação em Sistemas e Computação (PPgSC) Departamento de Informática e Matemática Aplicada (DIMAp) Universidade Federal do Rio Grande do Norte (UFRN) jbsneto@ppgsc.ufrn.br, anamaria@dimap.ufrn.br Nível: Mestrado Ano de ingresso: 2013 Previsão de qualificação: agosto/2014 Previsão de conclusão: fevereiro/2015 Resumo. Das várias formas de se buscar qualidade de software, Teste de Software e Métodos Formais são duas que merecem destaque. Vários esforços vem sendo feitos pela comunidade para unir essas duas metodologias, que podem se complementar e trazer mais qualidade para o software. Um desses esforços foi a criação da abordagem e ferramenta BETA (B Based Testing Approach), que gera casos de teste a partir de especificações formais na notação do Método B. O presente trabalho tem o objetivo de aplicar BETA em novos estudos de caso com o intuito de fazer um estudo mais aprofundado sobre a abordagem e ferramenta, identificando seus problemas e limitações, assim como propor e implementar melhorias, contribuindo para o seu aperfeiçoamento. Eventos do CBSoft relacionados: SBES, SBMF Este trabalho recebe apoio financeiro da CAPES e CNPq (Instituto Nacional de Ciência e Tecnologia para Engenharia de Software INES, processo /2008-4) 50

51 1. Introdução e Caracterização do Problema O software passou a ser essencial para a vida moderna, estando presente nos principais afazeres do cotidiano. Esse fato faz com que a preocupação em se desenvolver software de qualidade cresça a cada dia. Teste de Software e Métodos Formais são duas das disciplinas que visam a qualidade no desenvolvimento de um software. Métodos formais fazem uso de um formalismo matemático para descrever informações de uma forma completa, consistente e não-ambígua. Por conta disso, fornecem informações mais precisas sobre os requisitos do software, que podem ser de grande auxílio na criação de testes. Neste sentido, existem várias iniciativas que buscam unir essas duas metodologias. Uma importante iniciativa pode ser encontrada em [Satpathy et al. 2007], que apresenta o ProTest, uma ferramenta que cria testes para uma especificação formal na notação do Método B [Abrial 2005]. Outra iniciativa também pode ser vista em [Aydal et al. 2009], que apresenta uma abordagem de criação de testes a partir de especificações escritas em Alloy [Jackson 2012]. Estas são apenas duas das várias iniciativas que unem métodos formais e teste de software, mostrando que esta é uma área de estudo bastante ativa. Em [Matos and Moreira 2012, Matos and Moreira 2013] é apresentada a abordagem e ferramenta BETA (B Based Testing Approach) 1. Nesta abordagem, casos de teste de unidade são gerados a partir de especificações formais escritas na notação do Método B. Fazendo uso de particionamento do espaço de entrada [Ammann and Offutt 2008], a abordagem gera casos de teste positivos, que respeitam as restrições da especificação, e negativos, que desrespeitam as restrições da especificação, exercitando ações não esperadas pelo software. As experiências realizadas em [Matos and Moreira 2012, Matos and Moreira 2013] foram importantes para uma validação inicial da abordagem e da ferramenta, entretanto, se limitaram apenas ao projeto de casos de teste, não tendo sido realizadas a implementação e execução dos mesmos. Além disso, a ferramenta continua em desenvolvimento, o que faz com que novas avaliações sejam necessárias. Neste contexto, a proposta do presente trabalho é aplicar a abordagem e ferramenta BETA em novos estudos de caso, de modo a avaliar o comportamento de BETA em situações mais complexas, assim como realizar todo processo de projeto, implementação e execução de testes. Com isso, este trabalho pretende explorar BETA, identificando suas limitações e qualidades, além de propor e implementar melhorias. O restante deste trabalho está organizado da seguinte forma: na Seção 2 são apresentados alguns conceitos relacionados a Método B e Teste de Software; na Seção 3 é apresentada a abordagem e ferramenta BETA; na Seção 4 são apresentados os objetivos e contribuições deste trabalho; a Seção 5 descreve o estado atual do trabalho; na Seção 6 são apresentados os resultados que serão esperados com esta pesquisa. 2. Fundamentação Teórica Nesta seção serão apresentados os principais conceitos que embasam esta pesquisa. Será apresentado uma breve introdução ao Método B e, em seguida, serão apresentados alguns conceito relacionados a teste de software. 1 Informações e detalhes técnicos sobre a abordagem e ferramenta BETA podem ser encontrados no site onde a ferramenta pode ser baixada. 51

52 2.1. Método B O Método B é uma metodologia formal para especificação, projeto e codificação de sistemas [Abrial 2005]. Utilizando conceitos da teoria dos conjuntos, lógica de primeira ordem, aritmética de inteiros e substituições generalizadas (transformadores de predicados), o processo do Método B se inicia com a criação de um módulo abstrato, chamado máquina abstrata, que especifica o comportamento do sistema. A partir de um processo contínuo, a máquina abstrata vai sendo refinada de modo a chegar a uma forma mais concreta. O último passo do método B é a implementação, que é o nível mais concreto da especificação, de modo que o código do sistema pode ser gerado automaticamente. Os principais componentes de um módulo do Método B são as variáveis de estado, o invariante, que especifica a validade e restrições para o estado, e as operações, que modificam e consultam o estado. As operações são definidas em termos de substituições generalizadas e possuem pré-condições, que devem ser satisfeitas para que as operações possam ser executadas sem inconsistências. A coerência da máquina é garantida através das obrigações de prova, que são expressões lógicas geradas a partir da especificação, que devem ser provadas com o auxílio de um provador de teoremas Teste de Software O Teste de Software é uma das abordagens que buscam aumentar a qualidade do software, pois tem o objetivo de identificar os seus defeitos. Neste trabalho são considerados os testes funcionais, classicamente chamados de testes de caixa preta, projetados a partir da especificação do sistema. Os testes também podem ser classificados de acordo com a atividade do processo de desenvolvimento a que estão relacionados. Os testes de unidade, que estão relacionados à atividade de implementação e verificam cada unidade (um método ou operação, por exemplo) do sistema de forma isolada, são considerados neste trabalho. Um conceito importante em teste de software é o de critério de cobertura, que em [Ammann and Offutt 2008] é definido como uma regra ou conjunto de regras que definem requisitos de teste para um conjunto de teste. Critérios de cobertura são importantes porque estabelecem limites na quantidade de testes a serem criados, mantendo ainda uma boa qualidade. Existem vários tipos de critérios de cobertura, dentre os quais se destacam a cobertura de grafos, cobertura lógica, particionamento do espaço de entrada e testes baseados em sintaxe. Outro conceito importante é o de oráculo de teste, que é o mecanismo responsável por determinar o sucesso ou falha de um teste. Em [Li and Offutt 2014] são apresentadas algumas estratégias de oráculo de teste, que consistem em fazer verificações no estado interno do software, variáveis e invariante de estado, e nos resultados das operações, entre outras verificações. 3. BETA É uma abordagem e ferramenta para geração de casos de teste de unidade a partir de especificações formais em B, apresentada em [Matos and Moreira 2012, Matos and Moreira 2013]. Utilizando como tipo de critério de cobertura o particionamento do espaço de entrada [Ammann and Offutt 2008], BETA gera casos de teste positivos e negativos para uma unidade (operação) de uma máquina abstrata B. A Figura 1 apresenta uma visão geral 52

53 Figura 1. Visão geral da abordagem BETA. da abordagem BETA. Os quadros brancos representam os artefatos utilizados e produzidos durante o processo e os quadros cinzas representam as etapas da abordagem. Na etapa (1), é preciso caracterizar o espaço de entrada da operação sob teste, que consiste em identificar as variáveis do domínio de entrada da operação e suas características, que são obtidas a partir do invariante de estado da máquina e pré-condição da operação. Em (2), o espaço é particionado em blocos disjuntos correspondentes a cada característica. Feito o particionamento, os blocos são combinados em (3) resultando em um conjunto de fórmulas. Cada fórmula estabelece restrições para o domínio de entrada e representa um caso de teste. Na etapa (4) são obtidos valores para as variáveis do espaço de entrada que satisfazem as restrições impostas pelas fórmulas. Para a obtenção desses valores, a abordagem sugere o uso de um solucionador de restrições 2. De posse desses valores, é criada uma especificação contendo os dados de teste. Outro elemento importante em um teste, além dos dados de entrada, é o oráculo que determina seu sucesso ou falha, por isso, na etapa (5) são definidos os oráculos de teste. A abordagem apresenta um método para a geração de oráculos para testes positivos. A última etapa da abordagem (6), consiste na implementação dos testes concretos, que leva em consideração a especificação e os oráculos gerados nas etapas anteriores. Atualmente, a ferramenta BETA automatiza os passos (1) ao (4) da abordagem, já os passos (5) e (6) ainda são feitos de forma manual. 4. Objetivos e Contribuições Este trabalho tem o objetivo de aplicar BETA em dois novos estudos de caso com o intuito de fazer um estudo mais aprofundado sobre a abordagem e ferramenta, identificando seus defeitos e possíveis melhorias, assim como contribuir para o seu aperfeiçoamento. O primeiro estudo de caso consiste em desenvolver testes para a API da linguagem de programação Lua [Ierusalimschy 2012] a partir da especificação criada em [Moreira and Ierusalimschy 2013]. Com esse estudo, este trabalho pretende validar a especificação verificando se os testes criados a partir dela são condizentes com a API real, ou seja, pretendese verificar se o comportamento real da API foi especificado corretamente. Além disso, 2 O solucionador de restrições utilizado pela ferramenta BETA é o ProB, uma ferramenta para verificação de modelo e execução de especificações B 53

54 a especificação da API possui um grande número de operações e utiliza muitos recursos do Método B, o que permitirá aplicar BETA em situações mais complexas até então não exploradas, que é o nosso principal objetivo. O segundo estudo de caso consiste em utilizar BETA para contribuir com a validação do compilador B2LLVM [Déharbe and Medeiros Jr. 2013], que gera código LLVM [Lattner and Adve 2004] a partir de implementações B. O código gerado pelo B2LLVM será testado com os casos de teste gerados por BETA a partir da especificação B que originou o código. Ao verificar que o código LLVM gerado segue a especificação, pode-se ter uma maior segurança que o B2LLVM está gerando o código corretamente. Além dos estudos de caso, este trabalho pretende trazer contribuições para as duas últimas etapas de BETA. A forma de obtenção dos oráculos de teste apresentada na penúltima etapa da abordagem é fixa e foca apenas em testes positivos, não abordando testes negativos. Por esse motivo, serão propostas estratégias de oráculo de teste para diminuir essas deficiências da abordagem. Além disso, será desenvolvido um gerador de guias de teste para a ferramenta com o intuito de automatizar parte da implementação dos testes concretos, diminuindo o esforço gasto na última etapa da abordagem. 5. Estado Atual do Trabalho Para contribuir com a penúltima etapa da abordagem, este trabalho está propondo quatro estratégias de oráculo de teste baseadas nas estratégias apresentadas em [Li and Offutt 2014]. As estratégias consistem em: 1) verificar a ocorrência de exceções; 2) verificar o invariante de estado após a execução da operação; 3) verificar os valores das variáveis de estado após a execução da operação; 4) verificar o retorno da operação. As estratégias de oráculo podem ser combinadas para uma melhor verificação, provendo uma melhor flexibilidade, inclusive em testes negativos. Para diminuir o trabalho realizado na última etapa da abordagem, foi desenvolvido um gerador de guias de teste. O gerador traduz os dados da especificação de casos de teste gerada por BETA para um guia de teste em Java e C, utilizando as notações de teste JUnit 3 e CuTest 4, respectivamente. O guia contém parte do código do teste concreto e precisa ser adaptado pelo desenvolvedor para poder ser executado. O gerador também automatiza parte da criação dos oráculos de teste com base nas estratégias propostas. Os dois estudos de caso propostos neste trabalho já foram iniciados. No primeiro estudo de caso, a especificação da API de Lua foi aplicada na ferramenta BETA. Inicialmente, a ferramenta não conseguiu gerar casos de teste para nenhuma operação da especificação. Ao investigar o motivo, foi detectado que o solucionador de restrições utilizado pela ferramenta, o ProB, não estava conseguindo gerar valores para as variáveis da especificação devido ao grande número de tipos de Lua considerados, que gerou uma explosão combinatória. Dada esta limitação, este trabalho optou por diminuir o escopo da especificação ao reduzir o número de operações e tipos de Lua que estavam sendo considerados. Com a redução, BETA conseguiu gerar a especificação de casos de teste para algumas operações da API. Os testes concretos serão implementados com o auxílio do gerador de guias de teste. 3 JUnit é um framework de testes para Java 4 CuTest é um framework de testes para C 54

55 Para o segundo estudo de caso, foi escolhido um pequeno conjunto de máquinas abstratas e suas implementações B. As implementações foram aplicadas no B2LLVM, que gerou códigos LLVM correspondentes. As máquinas abstratas foram aplicadas na ferramenta BETA, que gerou as especificações de casos de teste. Os testes concretos foram implementados em C com o auxílio do gerador desenvolvido neste trabalho, sendo necessário apenas algumas adaptações. Os primeiros resultados da execução dos testes foram positivos. 6. Resultados Esperados Os resultados deste trabalho serão importantes para contribuir com o aperfeiçoamento da abordagem e ferramenta BETA. Em um primeiro momento, este trabalho conseguiu mostrar que a abordagem e ferramenta são aplicáveis em situações reais, além da identificação de algumas limitações, relacionadas ao solucionador de restrições utilizado pela ferramenta, algo que será alvo de um futuro estudo (fora do escopo deste trabalho). Além disso, este trabalho trouxe contribuições para BETA com a proposta de estratégias de oráculo de teste e o gerador de guias de teste, que já estão sendo utilizados nos estudos de caso em andamento. Referências Abrial, J. (2005). The B-Book: Assigning Programs to Meanings. Cambridge U. Press. Ammann, P. and Offutt, J. (2008). Introduction to Software Testing. Cambridge U. Press. Aydal, E., Paige, R., Utting, M., and Woodcock, J. (2009). Putting formal specifications under the magnifying glass: Model-based testing for validation. In International Conference on Software Testing, Verification and Validation, 2009, pages Déharbe, D. and Medeiros Jr., V. (2013). Proposal: Translation of B Implementations to LLVM-IR. Brazilian Symposium on Formal Methods. Ierusalimschy, R. (2012). Programming in Lua, Third Edition. Lua.org. Jackson, D. (2012). Software Abstractions: Logic, Language, and Analysis. MIT Press. Lattner, C. and Adve, V. (2004). LLVM: A Compilation Framework for Lifelong Program Analysis & Transformation. In Proceedings of the 2004 International Symposium on Code Generation and Optimization (CGO 04), pages Li, N. and Offutt, J. (2014). An Empirical Analysis of Test Oracle Strategies for Modelbased Testing. IEEE 7th Int. Conf. on Software Testing, Verification and Validation. Matos, E. C. B. and Moreira, A. M. (2012). BETA: A B Based Testing Approach. In Formal Methods: Foundations and Applications, pages Springer. Matos, E. C. B. and Moreira, A. M. (2013). BETA: a tool for test case generation based on B specifications. In Proceedings of Congresso Brasileiro de Software: Teoria e Prática, CBSoft Tools, Brasília - DF. Moreira, A. M. and Ierusalimschy, R. (2013). Modeling the Lua API in B. Draft. Satpathy, M., Butler, M., Leuschel, M., and Ramesh, S. (2007). Automatic testing from formal specifications. In Tests and Proofs, pages Springer. 55

56 O Impacto dos Fatores Humanos em Metodologias Ágeis Aluna Aline Chagas Rodrigues Marques Orientador Prof. Alexandre Marcos Lins de Vasconcelos Co-orientador Prof. Célio Andrade de Santana Júnior Pós-graduação em Ciência da Computação - Centro de Informática (CIn) Universidade Federal de Pernambuco (UFPE) Pernambuco, PE Brasil. {acrm2, amlv, casj}@cin.ufpe.br Nível: Mestrado Ano de Ingresso: março de 2013 Previsão de Conclusão: fevereiro de 2015 Aprovação da Proposta: não qualificado Evento: SBES Resumo. Fatores humanos têm um grande impacto nas etapas da construção de software, seja na linha tradicional ou ágil de desenvolvimento. Pesquisas considerando estes fatores no desenvolvimento de software ainda são escassas. Esta dissertação visa realizar um estudo qualitativo sobre o impacto dos fatores humanos no desenvolvimento ágil de software. Para isto, será realizada uma revisão sistemática da literatura e uma pesquisa qualitativa através de entrevistas, aplicando Teoria Fundamentada em Dados. Assim, espera-se obter dados empíricos sobre o contexto desta pesquisa e contribuir para a melhoria dos projetos de desenvolvimento de software das empresas sediadas no Porto Digital de Pernambuco. Palavras - Chaves: Fatores Humanos, Metodologias Ágeis. 56

57 1. Caracterização do Problema Segundo Pirzadeh (2010) o desenvolvimento de software é um processo centrado no ser humano e desta forma, considera-se que fatores humanos têm um grande impacto nas etapas da construção de software, ou seja, de acordo com o papel desempenhado pelos stakeholders, o processo de desenvolvimento de software pode ser afetado de diferentes formas, podendo variar de fatores organizacionais e interpessoais para características individuais. Por exemplo, se o papel exercido por um dos stakeholders for um desenvolvedor, o qual está motivado, pode influenciar as fases de construção de software aumentando os níveis de produtividade, já um gerente pode impactar fortemente sobre o desempenho e o sucesso do processo de desenvolvimento. O desenvolvimento ágil de software valoriza a interação humana no processo de desenvolvimento, conforme se pode observar no manifesto ágil quando se fala em "Indivíduos e interação" e "Colaboração com o cliente". Esta importância dada aos fatores humanos também pode ser observada nos princípios citados no manifesto quando descreve que o método mais eficiente para transmissão de informações entre o time, é a conversa face-to-face, valorizando assim a comunicação entre a equipe de desenvolvimento (MANIFESTO ÁGIL, 2014). Porém, pesquisas considerando os fatores humanos no processo de desenvolvimento de software são escassas (PIRZADEH, 2010). Ainda se faz necessário avaliar o impacto dos fatores humanos no processo de desenvolvimento de software, uma vez que os trabalhos encontrados em Pirzadeh (2010), Sharp (2005) e Dyba (2008) relatam que fatores humanos e/ou sociais, sobre diferentes perspectivas na engenharia de software, são observados no desenvolvimento tradicional de software e na programação extrema (XP). Desta forma, este trabalho visa realizar um estudo qualitativo sobre o impacto dos fatores humanos em metodologias ágeis em um contexto real na indústria com base nos resultados de uma revisão sistemática da literatura (RSL). Este artigo está dividido como segue: Na seção 2 tem-se a fundamentação teórica com os principais conceitos desta dissertação. Na seção 3 as principais contribuições deste trabalho. Na seção 4 descreve-se o estado atual do estudo. Na seção 5 são elencados e descritos os principais trabalhos que se relacionam com esta pesquisa e por fim na seção 6 são descritos os resultados parciais desta dissertação. 2. Fundamentação Teórica Nesta seção, descreve-se os conceitos fundamentais sobre fatores humanos em engenharia de software e em desenvolvimento ágil de software Fatores humanos em engenharia de software O termo fator humano em engenharia de software é definido como alguns tipos de fatores sociais que surgem a partir de diversas interações e que precisam ocorrer para que o processo de desenvolvimento de software possa fluir. Estes fatores se encaixam em três categorias principais para a área de engenharia de software: (i) sob o ponto de vista do indivíduo, (ii) ou de um grupo coletivo, ou (iii) resultados da utilização das técnicas e abordagens usadas por engenheiros de software (SHARP, 2005). Para Pirzadeh (2010) o fator humano indica diferentes aspectos do ser humano que são envolvidos e impactam no desenvolvimento de software. Tais fatores podem ser abordados dentro de três categorias: 57

58 1) Individual: Abrange questões humanas individuais relacionadas à engenharia ou desenvolvimento de software, como características individuais, personalidade, cultura entre outros. 2) Interpessoal: É relacionada a fatores humanos entre os indivíduos que afetam ou são afetados pela Engenharia ou processo de desenvolvimento de software, como cooperação, aprendizado em grupo, trabalho dos times, dentre outros. 3) Organizacional: Inclui fatores humanos relacionados às organizações e ambientes de trabalho, como tomada de decisão nas organizações, consultores, ambiente organizacional e outros Fatores humanos em desenvolvimento ágil de software Segundo Cockburn (2002) fator humano pode ser descrito como alguma questão humana causada por um time de pessoas trabalhando juntas. Desta forma, este conceito pode ser repassado para o desenvolvimento ágil de software quando considera qualquer aspecto humano que esteja envolvido na formação de times para a construção de software, uma vez que este tipo de desenvolvimento tem o foco na interação das pessoas e nos indivíduos. Em Alistair e Highsmith (2002) são enfatizados alguns fatores humanos para metodologias ágeis de desenvolvimento como: cordialidade, talento, habilidades e comunicação. Esses fatores podem emergir quando um grupo de indivíduos está trabalhando junto como um time. 3. Contribuições Algumas contribuições podem ser identificadas ao término desta pesquisa: Fornecer um guia sobre o impacto dos fatores humanos em projetos de desenvolvimento de software, os quais usam metodologias ágeis; Auxiliar à academia com evidências empíricas para a comunidade de engenharia de software que sirvam de base para futuras pesquisas; Contribuir para a indústria na melhoria dos projetos de desenvolvimento de software das empresas sediadas no Porto Digital de Pernambuco. 4. Estado Atual do Trabalho Para se obter maior familiaridade com o tema proposto desta dissertação, objetivou-se realizar uma pesquisa bibliográfica como forma de encontrar quais fatores humanos estão sendo utilizados recentemente em projetos de desenvolvimento de software e, por conseguinte, quais destes utilizam desenvolvimento ágil de software. Esta pesquisa bibliográfica permitiu o conhecimento de uma gama de fenômenos que estão dispersos na literatura (vide Tabela 2). Após esta pesquisa, está sendo conduzida uma revisão sistemática da literatura com o objetivo de identificar, analisar e interpretar as evidências empíricas da literatura, no que se refere ao impacto dos fatores humanos sobre os projetos de desenvolvimento ágil de software. A revisão encontra-se na fase de análise e extração dos dados. 58

59 Ao final da Revisão sistemática uma pesquisa qualitativa será conduzida. De acordo com Lutters e Seaman (2007) tais pesquisas são geralmente utilizadas para coletar opiniões ou impressões sobre uma determinada situação. Para coletar os dados podem ser utilizados questionários, análise de documentos e entrevistas. Segundo Gray (2012) as entrevistas podem ser classificadas em cinco categorias: estruturadas, semiestruturadas, não direcionadas, direcionadas, e com conversas informais. Esta dissertação optou por realizar entrevistas semiestruturadas, pois, de acordo com Flick (2009), esta abordagem permite utilizar um planejamento aberto e aceita que os pontos de vista dos sujeitos entrevistados sejam melhor expressados, a que em uma entrevista padronizada ou a partir da aplicação de um questionário. A população de estudo serão os envolvidos com os processos de desenvolvimento de software das empresas associadas ao Porto Digital de Pernambuco que utilizam as Metodologias Ágeis. Para este estudo, serão realizadas entrevistas que serão gravadas em áudio e posteriormente transcritas. A extração dos dados das entrevistas será executada com base nos procedimentos de codificação aberta, seletiva e posteriormente a axial. Para a análise e síntese dos dados será aplicada a Teoria Fundamentada em Dados, juntamente com o procedimento de comparação (GLASER e STRAUSS, 1967). O cronograma desta pesquisa pode ser visualizado na Tabela 1 abaixo: Atividades/Período 1 Estudos iniciais e disciplinas do programa 2 Pesquisa bibliográfica 3 Condução da revisão sistemática 4 Aplicação das entrevistas 5 Escrita da dissertação Tabela 1. Cronograma de atividades 5. Comparação com Trabalhos Relacionados º 2º 1º 2º Pirzadeh (2010) conduziu uma revisão sistemática para identificar e caracterizar fatores humanos que influenciam o processo de desenvolvimento de software em cascata, considerando o ciclo de desenvolvimento e a gerência de software. Foram criadas categorias para os fatores humanos em níveis organizacionais, interpessoais e individuais, a qual se destacou como a mais importante. A autora também investigou quais fases do desenvolvimento eram mais pesquisadas e encontrou que a fase de Engenharia de requisitos era a de maior relevância dentre os estudos selecionados. Livermore (2007) aplicou um survey online que procurava investigar quais fatores estavam relacionados à implementação de metodologias ágeis. Encontrou fatores como: treinamento, envolvimento da gerência, acesso a recursos externos e tamanho da corporação. Tais resultados somente consideraram o aspecto técnico e organizacional e não abordaram a relevância de fatores humanos nesse contexto. 59

60 Em um relato de experiência, Law e Charron (2005) estavam interessados em pesquisar os efeitos das práticas ágeis em fatores sociais. Os autores não descreveram de que forma selecionaram os fatores como: compartilhamento do conhecimento, motivação e colaboração do cliente. Foram utilizados dois projetos industriais de software que obtiveram sucesso ao se adaptarem aos fatores sociais elencados. Em Gandomani et.al (2014) foi realizado uma pesquisa qualitativa com o objetivo de investigar como fatores humanos impactam na adoção e transição para desenvolvimento ágil de software. Foram realizadas entrevistas semiestruturadas e para análise dos dados utilizou-se Grounded Theory (GT). Como resultado, construiu-se uma teoria em que há fatores que facilitam e outros que impedem a mudança para a abordagem das metodologias ágeis. Todos estes trabalhos mencionados buscam a influência dos fatores humanos em desenvolvimento de software, seja da forma tradicional ou ágil e tem como contexto de estudo, a academia ou a indústria. Sendo assim, este estudo difere-se dos demais por estudar empresas que utilizam metodologias ágeis, realizando uma pesquisa qualitativa para investigar o impacto dos fatores humanos no desenvolvimento ágil de software, apoiada pelos dados resultantes da revisão sistemática da literatura. 6. Avaliação dos Resultados Os resultados desta pesquisa encontram-se na fase incipiente, a qual apresenta a formação de um catálogo de fatores humanos que foram encontrados durante a realização da pesquisa bibliográfica. O catálogo pode ser visualizado na Tabela 2 abaixo: Tabela 2. Catálogo de fatores humanos Fator Autores Resultado Capacidade do time e envolvimento do cliente Cordialidade, talento, habilidade e comunicação Responsabilidade, capacitação, liderança, comunicação e confiança Interpessoal, individual e organizacional Bom relacionamento e confiança Compartilhando conhecimento, colaboração do cliente e motivação Competência, características pessoais, comunicação, cultura, treinamento e aprendizagem Tsun Chow e Dac-Buu Cao Fatores de sucesso em projetos ágeis Alistair Cockburn e Jim Highsmith Vikash Lalsing, Somveer Kishnah e Sameerchand Pudaruth Fatores que promovem o bem-estar de um time ágil Fatores pessoais em desenvolvimento ágil de software e em gerência de projeto Laleh Pirzadeh Categorias de fatores relacionados aos ciclos de desenvolvimento de software Dyba e Dingsøyr Fatores para o sucesso de um time XP Amy Law e Raylene Charron Efeito das práticas ágeis sobre esses fatores sociais Subhas Chandra Misra, Vinod Kumar, Uma Kumar Fatores de sucesso ao adotar práticas de desenvolvimento ágil de software 60

61 A revisão sistemática ainda está na fase de análise e extração de dados. Tal revisão permitirá responder as seguintes perguntas de pesquisa: RQ1: O que se sabe sobre quais fatores humanos interferem na utilização de métodos ágeis? RQ2: Qual o impacto dos fatores humanos em métodos ágeis?. Pretende-se ao longo desta revisão verificar se existem outros fatores humanos além dos encontrados na pesquisa bibliográfica para que o mesmo faça parte do catálogo. Os dados mais aguardados serão os obtidos através da aplicação de entrevistas semiestruturadas que fornecerão dados empíricos sobre o impacto dos fatores humanos em desenvolvimento ágil de software, de forma a se obter uma visão de como esses aspectos estão sendo considerados pela indústria. Com os dados dessas entrevistas, pretende-se evidenciar os pontos positivos e negativos, estes principalmente, dos fatores humanos em metodologias ágeis. Referências COCKBURN, A. (2002) Agile Software Development. Boston: Addison Wesley. COCKBURN, A. HIGHSMITH, J. (2001) Agile Software Development: The People Factor, Computer, pp DYBÅ, T.; DINGSøYR, T. (2008) Empirical Studies of Agile Software Development: A Systematic Review. Information and Software Technology, Butterworth- Heinemann Newton, MA, USA, v. 50, n. 9, p FLICK, U. (2009) Introdução à pesquisa qualitativa. Tradução de Joice Elias Costa. Porto Alegre: Artmed. GANDOMANI, T.J; ZULZALIL, H; GHANI, A.A.A; SULTAN, A.B.M; SHARIF, K.Y. (2014) How Human Aspects Impress Agile Software Development Transition and Adoption. International Journal of Software Engineering and Its Applications Vol.8, No.1. GLASER, B. G.; STRAUSS, A. L. (1967) The Discovery of Grounded Theory: Strategies for Qualitative Research. Chicago: Aldine Transaction. GRAY, D. E. (2012) Pesquisa no mundo real. Tradução de Roberto Cataldo Costa. 2a.ed. Porto Alegre: Penso. LAW, A; CHARRON, R. (2005) Effects of Agile Practices on Social Factors. Human and Social Factors of Software Engineering (HSSE). St. Louis, Missouri, USA. LIVERMORE, J. A. (2007) Factors that Impact Implementing an Agile Software Development Methodology. SoutheastCon. Proceedings. IEEE. LUTTERS, W. G.; SEAMAN, C. B. (2007) The Value of War Stories in Debunking the Myths of Documentation in Software Maintenance. Information and Software Technology, v. 49, n. 6, p MANIFESTO ÁGIL. Disponível em: Acesso em 26 de abril de PIRZADEH, L. (2010) Human Factors in Software Development: A Systematic Literature Review. Master of Science Thesis in Computer Science and Engineering. Department of Computer Science and Engineering - Division of Networks and Distributed Systems. Chalmers university of technology. Göteborg, Sweden. SHARP, H; ROBISON, H. (2005) Some Social Factors of Software Engineering: the maverick, community and technical practices. Human and Social Factors of Software Engineering (HSSE). St. Louis, Missouri, USA. 61

62 Um Método de Extração de Valores Referência para Métricas de Softwares Orientados por Objetos Tarcísio G. S. Filó 1, Mariza A. S. Bigonha 1, Kecia Aline Marques Ferreira 2 1 Programa de Pós-Graduação em Ciências da Computação (PPGCC) Departamento de Ciência da Computação - Universidade Federal de Minas Gerais (UFMG) - Belo Horizonte - MG - Brasil 2 Departamento de Computação - Centro Federal de Educação Tecnológica de Minas Gerais (CEFET-MG) - Belo Horizonte - MG - Brasil {tfilo,mariza}@dcc.ufmg.br, kecia@decom.cefetmg.br Nível: Mestrado Ano de ingresso no programa: 2012 Época prevista de conclusão: março de 2014 Data da aprovação da proposta de dissertação: março de 2013 Eventos Relacionados: SBES Resumo. Valores referência para métricas de softwares orientados por objetos são úteis em diversos campos da Engenharia de Software, tais como processos de filtragem em estratégias de detecção de bad smells e identificação de medições anômalas em um processo de medição de produto, parte integrante de um programa de qualidade de software. Nesse trabalho apresentamos um método de extração de valores referência para métricas de softwares orientados por objetos, bem como mostramos a sua aplicação na identificação de valores referência para 18 métricas em um dataset de 111 softwares open-source. Os próximos passos do trabalho consistem em avaliar empiricamente a eficácia dos valores referência na avaliação da qualidade do software. Palavras-chave: métricas, valores referência, qualide de software, medição de software. Abstract. Thresholds for object-oriented software metrics are helpful in severous fields of Software Engineering, such as filtering mechanisms in bad smells detection strategies and identification of anomalous measurements in a software quality program. In this work, we present a method to extract thresholds of object-oriented software metrics and show its application in the thresholds identifying thresholds for 18 metrics of an 111 open-source software systems dataset. The next steps are related to the empirical evaluation of the thresholds effectiveness in software quality evaluation. Keywords: metrics, thresholds, software quality, software measurement. 62

63 1. Introdução Pesquisas relacionadas com valores referência para métricas de software orientado por objetos vem sendo realizadas a partir de diferentes metodologias e apresentam valores referência de formatos e significados distintos. Além disso, valores referência para diversas métricas propostas na literatura ainda não são conhecidos. Uma consequência direta desse problema é a inexistência de condições adequadas para avaliar quantitativamente e de forma eficaz a qualidade dos softwares. Valores referência permitem responder questões simples como Quais métodos do sistema possuem uma quantidade excessiva de parâmetros? ou Quais classes do sistema possuem muitos métodos?. Nesse contexto, o trabalho de pesquisa proposto tem por objetivo contribuir para a solução desse problema, catalogando e avaliando valores referência para um conjunto de 18 métricas de softwares orientados por objetos, a partir de um método sólido e embasado em dados estatísticos para derivação desses valores. Com valores referência catalogados, vislumbra-se que as métricas possam ser efetivamente aplicadas na indústria de software, e, consequentemente, a qualidade dos softwares possa ser avaliada de forma automática. 2. Solução Proposta Nesta seção é descrita a metodologia a ser aplicada na derivação de valores referência para as métricas de softwares orientados por objetos coletadas no Qualitas.class Corpus [Terra et al. 2013], que é uma versão compilada do Qualitas Corpus proposto por Tempero et al. (2010), no qual são disponibilizados arquivos XML referentes aos 111 sistemas contendo medições de 18 métricas de softwares: Básicas: número de classes por pacote, número de métodos, número de atributos, número de métodos sobrescritos, número de parâmetros, número de métodos estáticos e número de atributos estáticos. Complexidade: linhas de código por método, índice de especialização, complexidade de McCabe, profundidade de blocos aninhados e distância normalizada. Conjunto CK: métodos ponderados por classe, profundidade de árvore de herança, número de filhas e ausência de coesão em métodos. Acoplamento: acoplamento aferente e acoplamento eferente. Para a preparação dos dados, neste trabalho, foi desenvolvida uma ferramenta que lê os arquivos XML disponibilizados no Qualitas.class Corpus e alimenta um banco de dados Mysql com o objetivo de normalizar as medidas. Realizada a conversão por meio dessa ferramenta, têm-se uma forma rápida e ágil de agregar e sumarizar os dados Data-Fitting Um problema importante em Estatística é obter informação sobre a distribuição seguida pelo conjunto de dados analisados [Gibbons and Chakraborti 2003]. Para esse propósito, a ferramenta EasyFit (2013), por meio do teste de aderência de Kolmogorov-Smirnov, realiza a seleção da distribuição apropriada aos dados, o qual é o procedimento de escolher uma distribuição que tenha melhor ajuste para um conjunto de dados. O objetivo dessa etapa é estabelecer a distribuição apropriada a cada métrica de software estudada. Segundo Baxter et al. (2006), explorar as distribuições dos valores das métricas de software é fundamental para avançar no entendimento das estruturas internas de softwares. A partir da distribuição é possível identificar e entender suas características, como por exemplo, se o valor médio é ou não representativo para a análise. 63

64 2.2. Análise dos Dados EasyFit gera um histograma de probabilidade dos dados ajustados a distribuição. A partir dessa visualização gráfica e do conhecimento das características da distribuição mais aderente aos dados, é possível derivar valores referência para as métricas. Na abordagem de Ferreira et al. (2012), quando a métrica apresenta uma distribuição que possui valor médio representativo, como por exemplo, a distribuição de Poisson, este valor representa o valor típico da métrica. Senão, são identificadas três faixas de valores: Bom/Frequente, Regular/Ocasional e Ruim/Raro, onde Bom/Frequente corresponde a valores com alta frequência, caracterizando os valores mais comuns da métrica, na prática. Para os autores, esses valores não expressam necessariamente as melhores práticas da Engenharia de Software, e sim um padrão seguido pela maioria dos softwares. Ruim/Raro corresponde a valores com baixa frequência, e a faixa Regular/Ocasional é intermediária, e são valores que não são nem muito frequentes nem raros. A frequência é estabelecida via uma análise gráfica do histograma de probabilidade dos dados ajustados a distribuição. 3. Avaliação dos Resultados Ferreira et al. (2012) avaliaram os valores referência propostos via estudos de casos, considerando que a sua aplicação pode resultar em duas situações possíveis: o valor referência avalia corretamente ou não o método, a classe ou o pacote. A avaliação correta ocorre quando a faixa em que a métrica cai reflete a situação real do artefato avaliado. Quando não há avaliação correta do valor referência, os estudos de caso consideram duas situações: (1) falso-positivo - o valor referência gera uma classificação ruim e a inspeção qualitativa não identifica problemas estruturais; (2) falso-negativo - o valor não classifica a classe como ruim, mas a inspeção qualitativa identifica problemas em sua estrutura. A identificação de casos falsos-negativos demanda uma avaliação qualitativa de um número muito grande de classes. No entanto, considerando que a derivação é feita de forma quantitativa, via análise de distribuição das medidas coletadas de uma grande quantidade de sistemas, uma inspeção manual é inviável, dada a dimensão da amostra. Por essa razão, Ferreira et al. avaliaram os casos falsos-positivos a partir da inspeção manual apenas daquelas classes identificadas nas faixas Ruim/Raro, com o objetivo de avaliar a eficácia do valor referência para identificar problemas. Neste trabalho de dissertação é proposta a condução de 3 estudos de casos com os seguintes objetivos: Estudo de Caso 1: avaliar um software proprietário com a qualidade interna deteriorada, com o propósito de verificar a capacidade dos valores referência propostos em indicar essa má qualidade. Nesse sentido, esse estudo de caso investiga se a aplicação dos valores referência de fato identifica métodos e classes de qualidade, não produzindo assim resultados falsos-negativos. Em um software qualitativamente definido como ruim, espera-se que métodos e classes não sejam bem avaliados em consonância com a opinião dos desenvolvedores, refletindo o panorama de baixa qualidade. Esse estudo busca avaliar, respectivamente, as métricas de métodos, as métricas de classes e a correlação dessas métricas não avaliarem bem os métodos e classes devido a ocorrência de bad smells bem conhecidos. Estudo de Caso 2: avaliar uma amostra de métodos e classes classificadas como Ruim/Raro por meio dos valores referência estabelecidos, com o objetivo principal de verificar a presença de casos falsos-positivos. 64

65 Estudo de Caso 3: avaliar o software JHotDraw, de reconhecida qualidade estrutural, com o objetivo de verificar a capacidade dos valores referência em indicar essa qualidade. Se isso se confirmar, a aplicação dos valores referência possui baixo risco de levarem a resultados falsos-positivos, afinal, as classes são de boa qualidade e, de fato, são bem avaliadas pelos valores referência. Outra confirmação dessa capacidade é que os valores referência são confiáveis quando sugerem um panorama de qualidade, minimizando o problema de avaliações com resultados falsos-negativos, que ocorre quando a classe não possui problemas estruturais, mas os valores referência os indicam. 4. Estado Atual do Trabalho A preparação dos dados, data-fitting (Seção 2.1), análise dos dados (Seção 2.2) e a identificação dos valores referência para 18 métricas de softwares orientados por objetos foram concluídas. A Tabela 1 sumariza 5 dos 18 valores referência propostos. A avaliação dos resultados (Seção 3) está parcialmente concluída. Table 1. Valores Referência Identificados. Métrica Bom/Frequente Regular/Ocasional Ruim/Raro Acoplamento Aferente m 7 7 < m 39 m > 39 Acoplamento Eferente m 6 6 < m 16 m > 16 Número de Atributos m 3 3 < m 8 m > 8 Número de Métodos m 6 6 < m 14 m > 14 Complexidade de McCabe m 2 2 < m 4 m > 4 O processo de derivação para a métrica Número de Métodos é o seguinte: o Gráfico de Frequência Relativa Acumulada, Figura 1(a), sugere uma distribuição de cauda-pesada. Isso significa que há um grande número de classes com poucos métodos e um pequeno número de classes com muitos métodos. Como mostrado na Figura 1(b), o conjunto de valores dessa métrica possui melhor ajuste à distribuição Weibull. A Figura 1(c) mostra esses dados em escala logarítmica, sugerindo uma lei de potência. Foram identificados os valores que representam o 70 e 90 percentil dos dados, que correspondem aos valores 6 e 14 (Tabela 1). Os valores 70% e 90% foram identificados via uma análise visual no Gráfico de Frequência Relativa Acumulada da Figura 1(a). Pontos marcados em formato de quadrado e losango representam as regiões identificadas nessa análise. Também determinam a escolha desses percentis os conceitos das faixas Bom/Frequente, Regular/Ocasional e Ruim/Raro, que devem caracterizar, respectivamente, valores muito frequentes, que ocorrem ocasionalmente e raros. 5. Contribuições Pretendidas As principais contribuições pretendidas, oriundas da pesquisa proposta, incluem: 1. Um catálogo de valores referência para 18 métricas de softwares orientados por objetos, derivados a partir de um dataset de 111 softwares open-source. 2. Um catálogo de distribuições estatísticas que possuam melhor encaixe em relação as 18 métricas de softwares orientados por objetos, permitindo identificar características acerca de como os softwares estão sendo construídos. 65

66 (a) (b) (c) Figure 1. Número de Métodos: (a) Frequência Relativa Acumulada (b) Densidade de Probabilidade ajustada à Distribuição Weibull (c) Histograma em escala loglog. 3. Ampliação do universo de métricas com valores referência derivados a partir da metodologia de Ferreira et al. (2012), permitindo realizar uma análise comparativa em termos de resultados com outros trabalhos. 4. Avaliações dos valores referência em: (1) um software proprietário mal projetado, com o objetivo de estender a validação proposta a softwares fora do universo de código aberto e, (2) do dataset utilizado no processo de derivação. 5. Avaliação dos valores referência na identificação de métodos, classes e pacotes de baixa qualidade, bem como a avaliação em um software bem projetado. 6. Trabalhos Relacionados Alves et al. (2010) propuseram um método empírico para determinar valores referências a partir de um conjunto de softwares, onde as medições coletadas são agregadas gerando informações no formato: o valor 17 da métrica McCabe representa 0,658% de todos os sistemas. Esses valores são ordenados e os valores referência são identificados pela escolha do 70%, 80% e 90% percentil do conjunto, caracterizando os perfis de qualidade: low risk (entre 0-70%), moderate risk (70-80%), high risk (80-90%) and very high risk (> 90%). Alves et al. não consideram a distribuição apropriada aos dados na definição dos percentis que definem os perfis. Ferreira et al. (2012) identificam valores referência para 6 métricas de softwares orientados por objetos via medição das estruturas de um conjunto de 40 softwares de código aberto desenvolvidos em Java, de diferentes tamanhos, domínios e tipos, e uma análise estatística dos dados baseada em uma distribuição estatística apropriada. Oliveira et al. (2014) propuseram o conceito de valores referência relativos para avaliar métricas aderentes a uma distribuição de cauda-pesada. Os valores referência são relativos pois devem ser seguidos pela maioria das entidades, mas considera-se natural que um determinado número de entidades não siga os limites definidos. O formato dos valores referência é o seguinte: p% das entidades devem ter M k, aonde M é uma métrica de código-fonte, k é o limite definido p é a porcentagem mínima. Quando as contribuições desse trabalho são comparadas com os resultados apresentados por Ferreira et al. (2012) e estudos anteriores, identificam-se três diferenças prin- 66

67 cipais: (1) Foram introduzidas melhorias no método de derivação de valores referência de Ferreira et al., bem como, houve um avanço nas discussões acerca de suas limitações e qualidades em relação ao panorama atual da área. (2) Foram identificados valores referência para um número maior de métricas. (3) Os valores referência propostos provêem um benchmark para a avaliação quantitativa da qualidade interna de softwares orientados por objetos, considerando não somente classes, mas também métodos e pacotes. 7. Conclusões O objetivo dessa proposta de dissertação é definir um método para extração de valores referência para métricas de softwares orientados por objetos. O método proposto consiste na análise estatística da distribuição de um conjunto de medidas extraídas de um dataset de softwares, apresentando três faixas de valores: Bom/Frequente, Regular/Ocasional e Ruim/Raro. O método não usa técnicas estatísticas muito complexas, é reprodutível e foi aplicado a uma grande quantidade de softwares para extração dos valores referência. Desde a submissão desse artigo até hoje, avançamos em nossa pesquisa e obtivemos alguns resultados preliminares bem animadores sobre os valores referência propostos via estudos de casos realizados. Na continuidade do trabalho, pretendemos aprimorar os estudos de casos realizados, afim de avaliar os valores referência de forma a verificar se eles de fato auxiliam na identificação de problemas estruturais de software. References Alves, T. L., Ypma, C., and Visser, J. (2010). Deriving metric thresholds from benchmark data. In ICSM, pages IEEE Computer Society. Baxter, G., Frean, M., Noble, J., Rickerby, M., Smith, H., Visser, M., Melton, H., and Tempero, E. (2006). Understanding the shape of java software. In OOPSLA 06: Proceedings of the 21st annual ACM SIGPLAN, pages , NY, USA. ACM. EasyFit (2013). Easyfit. Disponível em: Acesso em 09/2013. Ferreira, K. A., Bigonha, M. A., Bigonha, R. S., Mendes, L. F., and Almeida, H. C. (2012). Identifying thresholds for object-oriented software metrics. Journal of Systems and Software, 85(2): Fowler, M. (2003). Anemic domain model. Disponível em: Acesso em 09/2013. Gibbons, J. D. and Chakraborti, S. (2003). Nonparametric Statistical Inference (Statistics: a Series of Textbooks and Monogrphs). CRC, 4 edition. Oliveira, P., Valente, M. T., and Lima, F. P. (2014). Extracting relative thresholds for source code metrics. In CSMR-WCRE, 2014 Software Evolution Week - IEEE Conference on, pages Tempero, E., Anslow, C., Dietrich, J., Han, T., Li, J., Lumpe, M., Melton, H., and Noble, J. (2010). Qualitas corpus: A curated collection of java code for empirical studies. In 2010 Asia Pacific Software Engineering Conference (APSEC2010), pages Terra, R., Miranda, L. F., Valente, M. T., and Bigonha, R. S. (2013). Qualitas.class Corpus: A compiled version of the Qualitas Corpus. Software Engineering Notes, 38(5):

68 Um Modelo Conceitual para Caracterização da Qualidade Interna de Sistemas de Software Open-Source Orientados a Objeto Mariana Santos 1, Paulo Bermejo (coorientador) 2, Heitor Costa (orientador) 1,2 1 Programa de Pós-Graduação em Ciência da Computação (PPGCC) Universidade Federal de Lavras (UFLA) - Lavras, MG - Brasil 2 Departamento de Ciência da Computação Universidade Federal de Lavras (UFLA) - Lavras, MG - Brasil mariana@bsi.ufla.br, bermejo@dcc.ufla.br, heitor@dcc.ufla.br Ano de ingresso ao programa: Maio/2013 Data prevista para término: Abril/2015 Data de aprovação da proposta: 26/03/2014 Evento relacionado: SBES Resumo. Projetos de software open-source recentemente ganharam importância na academia e na indústria. Com a crescente tendência de uso e os benefícios advindos da iniciativa, como a troca de conhecimentos e a capacidade de conduzir rapidamente inovações, pesquisas sobre a qualidade de software open-source tem ganhado renovado interesse. Além disso, dada a diversidade de habilidades e a experiência dos colaboradores e do estilo de gestão do seu código, a qualidade do código de software open-source precisa ser estudada e avaliada. Nesse sentido, modelos de qualidade de software criados utilizando técnicas estatísticas tornam-se uma alternativa eficiente para obter informações a fim de caracterizar a qualidade interna em sistemas de software open-source orientados a objeto. O objetivo deste trabalho é elaborar um modelo conceitual para a caracterização da qualidade interna de software, criado a partir da experiência de projetos desenvolvidos em Java, considerando domínios. Para tanto, são utilizadas técnicas estatísticas exploratórias e confirmatórias para obtenção dos resultados. Os resultados podem ser utilizados para prever características em sistemas de software em relação à sua manutenibilidade. Palavras-chave: Qualidade de software, orientação a objetos, projetos opensource, análise multivariada de dados, manutenibilidade. 68

69 1. Caracterização do Problema Sistemas de software precisam evoluir continuamente durante o seu ciclo de vida [Badri et al, 2012]. Nesse sentido, organizações do ramo de desenvolvimento de software estão cada vez mais preocupadas com a sua manutenção e garantia da sua qualidade, como o desenvolvimento a baixos custos e fáceis de serem evoluídos [Hamid; Hasan, 2010; Badri et al, 2012; Singh; Kannojia, 2013]. Apesar de serem necessárias e vitais para o desenvolvimento de software, atividades relacionadas à garantia da qualidade e à manutenção são dispendiosas. Pesquisas relatam aumento no custo dessas atividades de 35-40% para mais de 90% nas últimas décadas [Hildburn; Towhidnejad, 2002; Seliya; Khoshgoftaar, 2007; Midha; Bhattacherjee, 2012]. O desenvolvimento de sistemas de software open-source (OS) está se tornando cada vez mais importante nos dias de hoje [Cheliotis; 2009; Midha; Bhattacherjee, 2012]. Esses sistemas são disponibilizados em repositórios, tais como, Sourceforge e Github, e possuem ampla gama de domínios de software como negócios, desenvolvimento (navegadores web, IDE s, etc.) e educação [Midha; Bhattacherjee, 2012]. Aproveitando essa tendência crescente e os benefícios advindos da iniciativa, como a extensa troca de conhecimentos e a capacidade de conduzir rapidamente inovações, pesquisas sobre a qualidade de software OS tem ganhado renovado interesse [Briand et al, 2000; Hao Zhong et al, 2012; Souza; Maia, 2013]. Além disso, dada a diversidade de habilidades e a experiência dos colaboradores e do estilo de gestão do seu código, a qualidade do código de software OS precisa ser estudada e avaliada [Midha; Bhattacherjee, 2012]. Nesse contexto, modelos de qualidade de software criados por meio de técnicas estatísticas tem se mostrado uma alternativa eficiente para obter informações sobre a qualidade em software OS [Seliya; Khoshgoftaar, 2007]. Modelos de qualidade de software são definidos como um conjunto de características que provê um framework com requisitos de qualidade e meios de avaliar o software [ISO/IEC 25010, 2011]. Podem ser utilizados para identificar sistemas de software propensos a falhas e defeitos ou baixa manutenibilidade, modularidade e reusabilidade. O objetivo do trabalho é elaborar um modelo conceitual para caracterizar a qualidade interna de software, criado a partir da experiência de sistemas de software Java, considerando domínios. O uso de sistemas de software orientados a objetos (OO) justifica-se em decorrência da sua popularidade nos dias de hoje na comunidade de software. Portanto, é necessário que sistemas OO permaneçam manuteníveis [Hamid; Hasan, 2010; Dallal; 2013; Srivastava; Kumar, 2013]. Este trabalho está organizado da seguinte forma. Fundamentação teórica é apresentada na Seção 2. Contribuições são apresentadas na Seção 3. Trabalhos relacionados são apresentados na Seção 4. Cronograma e estado atual da pesquisa são apresentados na Seção 5. Avaliação dos resultados é discutida na Seção Fundamentação Teórica 2.1. Qualidade de Software Qualidade pode ser definida como o grau em que características de um produto ou serviço de software satisfazem necessidades explícitas e implícitas dos stakeholders, agregando valor a esse produto ou serviço [ISO/IEC 25010, 2011]. Qualidade interna é a totalidade das características do software do ponto de vista interno. Essa qualidade é 69

70 mensurada e avaliada em relação à qualidade do código-fonte por meio de medidas de software [ISO/IEC 25010, 2011; Kayarvizhy; Kanmani, 2011]. Na ISO/IEC 25010, a qualidade interna é parte do modelo de qualidade de sistemas de software Medidas de Software Medida é uma escala utilizada para a categorização de dados qualitativos de um sistema de software ou de suas especificações internas e externas [ISO/IEC 25010, 2011]. Elas podem ser coletadas durante o processo de desenvolvimento de software, identificando aspectos como [Yingjie Tian et al, 2008] quantidade de esforço, custo e complexidade. Quando medidas são específicas, elas representam características inerentes à tecnologia de programação adotada; por exemplo, herança na orientação a objetos Avaliação da Qualidade utilizando Técnicas Estatísticas Técnicas e abordagens são utilizadas para analisar dados, sejam qualitativos ou quantitativos. A análise multivariada de dados, tipo de análise estatística frequentemente utilizada para extrair conhecimento de grandes conjuntos de dados, tem se mostrado uma escolha apropriada para analisar a qualidade de sistemas de software [Zhong et al, 2004; Treiblmaier; Filzmoser, 2010; Muhammad et al, 2012]. Técnicas de dependência (e.g. regressão múltipla, análise discriminante e análise multivariada de variância) e interdependência (e.g. testes de correlação, agrupamento ou clustering e análise fatorial) são as mais utilizadas para fazer inferências sobre o relacionamento entre as diferentes variáveis [Hair et al, 2009] e propor modelos com base nos resultados encontrados. 3. Contribuições Algumas contribuições deste trabalho são (i) avaliação da qualidade interna de sistemas open-source OO de diferentes domínios sob a característica Manutenibilidade, considerando a amplitude das medidas, suas propriedades e relevância, (ii) identificação da similaridade entre características de sistemas open-source de diferentes domínios - o que é genérico/específico de cada domínio e (iii) construção de um modelo conceitual para caracterizar a qualidade de sistemas OS sobre diferentes propriedades. Como parte dos resultados esperados, o valor médio das medidas utilizadas é apresentado na Tabela 1, em que o maior valor está grafado em negrito e o menor valor está em itálico e sublinhado. Esses valores foram obtidos utilizando os plug-ins Metrics e VizzMaintenance. A seleção das medidas seguiu o critério de relevância: as mais citadas por artigos identificados em uma Revisão Sistemática de Literatura [Santos et al., 2014]. A análise descritiva dessas medidas foi realizada em parte dos sistemas selecionados para o trabalho (15 sistemas para cada domínio do Sourceforge), coletados nos repositórios Sourceforge ( e Github ( Tabela 1- Análise Descritiva dos Sistemas Selecionados por Domínio Domínios WMC CBO RFC LCOM NOC DIT LOC NOM CC NOA TCC Áudio & Vídeo (AV) Business & Enterprise (BE) Communications (C) Development (D) Games (G) Graphics (GPH) Home & Education (HE) Science & Engineering (SE) Security & Utilities (SU) System Administration (AS)

71 Esses valores indicam que sistemas do domínio BE tendem a ser mais complexos, modularizados e com maior quantidade de filhos, de métodos e de linhas de código. Sistemas nos domínios D e SA tendem a ser menos complexos (valores menores para WMC e CC, respectivamente). Quanto à propriedade coesão, sistemas nos domínios G e GPH tendem a ser mais coesos (valores menores para LCOM e TCC, respectivamente); por outro lado, sistemas nos domínios HE e SE tendem a ser menos coesos. Em relação à propriedade herança, sistemas no domínio HE tendem a ter a maior hierarquia entre classes; em contrapartida, sistemas no domínio D tendem a ter menor hierarquia entre classes. Para medidas de tamanho, sistemas no domínio SU tendem a ter menor quantidade de métodos em contraste com sistemas no domínio BE. Em relação à quantidade de atributos, sistemas no domínio D possuem menor média de atributos, contrapondo-se aos sistemas no domínio SA. O resultado preliminar da análise descritiva mostra que o comportamento das medidas varia de domínio para domínio. Esses resultados apoiam a etapa exploratória da pesquisa na descrição dos fatores extraídos pela Análise Fatorial Exploratória (AFE) e na descrição dos clusters encontrados pela Análise de clusters. A elaboração do modelo seguirá a estratégia de modelagem confirmatória (Figura 1). A construção do modelo será baseada na técnica de modelagem de equações estruturais, que avalia o quão os parâmetros (variáveis que compõem os construtos - medidas de software, representadas pela variável m e seus pesos) são invariantes (equivalentes) para diferentes grupos [Hair et al, 2009]. Cabe ressaltar que esses constructos (fatores da AFE), os pesos e as hipóteses de inter-relacionamento serão obtidos na etapa exploratória utilizando AFE. Figura 1 - Exemplo de Estratégia de Modelagem Confirmatória 4. Comparação com Trabalhos Relacionados Os trabalhos relacionados à proposta do trabalho consistem em investigar como medidas de software podem prever a propensão a falhas em classes [Briand et al, 2000] e outras características como modularidade [Kayarvizhy; Kanmani, 2011] e manutenibilidade [Al Dallal; 2013]. Além disso, há a criação de modelos de qualidade para avaliação da aquisição de sistemas OS [Soto e Ciolkowski, 2009], para definição/aplicação de tecnologias, processos e políticas de uso em sistemas OS [QualiPSo; 2014] e descrição de características de modularidade considerando vários domínios [Souza; Maia, 2013]. Mas, nesses estudos as limitações são quantidade reduzida de sistemas [Briand et al, 2000; Kayarvizhy; Kanmani, 2011; Al Dallal; 2013], não consistência entre os domínios de software e aspectos da OO. Além disso, com amostra de tamanho considerável para utilização de técnicas estatísticas mais robustas, analisam a qualidade em carácter exploratório [Soto; Ciolkowski, 2009; Terceiro et al.; 2012] ou apenas a modularidade 71

72 com objetivos descritivos, propondo valores de referência [Souza; Maia, 2013]. Este trabalho diferencia-se desses estudos ao propor a elaboração de um modelo conceitual para caracterizar a qualidade interna de sistemas de software Java, considerando domínios e utilizando técnicas estatísticas exploratórias e confirmatórias para obtenção dos resultados. Considerando os gaps mencionados, acredita-se que qualidade de um software OS e soluções para a sua melhoria podem ser representadas por fatores comuns e específicos em diferentes domínios. Com isso, neste trabalho, o objetivo é identificá-los e utilizá-los para prever fatores quanto à manutenibilidade. 5. Cronograma e Estado Atual do Trabalho O cronograma das atividades realizadas e previstas é apresentado na Tabela 2. Essas atividades são: 1) Caracterizar medidas associadas à qualidade interna de software OO por meio de uma Revisão Sistemática de Literatura; 2) Coletar valores para as medidas selecionadas nos sistemas (~500 sistemas de software); 3) Analisar a correlação entre as medidas e identificar fatores usando a técnica AFE; 4) Análise de cluster para identificar características semelhantes entre os sistemas estudados; 5) elaborar um modelo confirmatório das características internas dos sistemas OO Java a partir dos constructos extraídos da AFE; 6) Escrever a dissertação e realizar a defesa. No cronograma, de Jan/2014 a Mai/2014, a atividade 2 está em processo de finalização. A atividade 3 foi iniciada em Jun/2014. A atividade 4 terá início em Ago/2014. Pretende-se iniciar a criação do modelo confirmatório em Out/2014. Ativ Tabela 2 - Cronograma Mai Jun Jul Ago Set Out Nov Dez Jan Fev Mar Abr Mai Jun Jul Ago Set Out Nov Dez Jan Fev Mar Abr 6. Avaliação dos Resultados A caracterização da amostra (incluindo características dos domínios de software) será feita utilizando a técnica de inferência Análise Descritiva. Em seguida, será executada a etapa exploratória, utilizando a AFE e Análise de cluster. A última etapa do estudo consiste na confirmação estatística dos resultados, por meio do uso da técnica Partial Least-Squares para confirmar relacionamentos e inter-relacionamentos entre os constructos encontrados na AFE, tendo como produto um modelo estatístico que pode explicar as características de qualidade dos sistemas de software OS analisados. Referências Al Dallal, J. Object-Oriented Class Maintainability Prediction Using Internal Quality Attributes. In: Information and Software Technology. 55, 11, pp , Badri, M.; Drouin, N.; Toure, F. On Understanding Software Quality Evolution from a Defect Perspective: A Case Study on an Open Source Software System. In: Int. Conference on Computer Systems and Industrial Informatics pp.1-6, 18-20, Briand, L. C.; Wüst, J.; Daly, J. W.; Porter, V. D. Exploring the Relationship Between Design Measures and Software Quality in Object-Oriented Systems. In: Journal of Systems and Software, vol. 51, no. 3, pp , Cheliotis, G. From Open Source to Open Content: Organization, Licensing and Decision 72

73 Processes in Open Cultural Production. In: Decision Support Systems. 47, 3. pp , Hair, J. F.; Black, W. C.; Babin, B. J.; Anderson, R. E.; Tatham, R. L. Análise Multivariada de Dados. Bookman. 688p Hamid, N. F. I. A.; Hasan, M. K. Industrial-Based Object-Oriented Software Quality Measurement System and Its Importance. In: International Symposium in Information Technology, vol.3, pp , Hilburn, T. B.; Towhidnejad, M. Software Quality Across the Curriculum. In: Annual Frontiers in Education. vol.3, pp.s1g-18, S1G-23 vol.3, ISO/IEC 25010:2011 Systems and Software Engineering - Systems and Software Quality Requirements and Evaluation - System and Software Quality Models Kayarvizhy, N.; Kanmani, S. Analysis of Quality of Object Oriented Systems Using Object Oriented Metrics. In: International Conference on Electronics Computer Technology. vol.5, pp Midha, V.; Bhattacherjee, A. Governance Practices and Software Maintenance: A Study of Open Source Projects. In: Decision Support Systems, 54(1), pp Muhammad, S.; Maqbool, O.; Abbasi, A.Q. Evaluating Relationship Categories for Clustering Object-Oriented Software Systems. In: Software, v.6, no.3, pp , QualiPSo. Disponível em: Acessado em: 26/07/2014. Seliya, N.; Khoshgoftaar, T. M. Software Quality Analysis of Unlabeled Program Modules with Semi supervised Clustering. In: Transactions on Systems, Man and Cybernetics, Part A: Systems and Humans, vol.37, no.2, pp , Santos, M. A.; Bermejo, P.; Costa, H. Uma revisão sistemática sobre o uso de técnicas estatísticas para a avaliação da qualidade interna de sistemas de software orientados a objetos. In: SBES, Submetido. Soto, M.; Ciolkowski, M. The QualOSS open source assessment model measuring the performance of open source communities. In: 3rd International Symposium on Empirical Software Engineering and Measurement, pp , Souza, L. B. L. de; Maia, M. de A. Do Software Categories Impact Coupling Metrics? In: Working Conference on Mining Software Repositories. pp Srivastava, S.; Kumar, R. Indirect method to measure software quality using CK-OO suite. In: 2013 International Conference on Intelligent Systems and Signal Processing (ISSP), pp.47-51, Terceiro, A; Mendonça, M.; Chavez, C.; Cruzes, D.S. Understanding Structural Complexity Evolution: A Quantitative Analysis. In: 16th European Conference on Software Maintenance and Reengineering (CSMR), pp.85-94, Treiblmaier, H.; Filzmoser, P. Exploratory Factor Analysis Revisited: How Robust Methods Support the Detection of Hidden Multivariate Data Structures in IS Research. In: Information & Management. V. 47, Is. 4, pp Yingjie Tian; Chuanliang Chen; ChunHua Zhang. AODE for Source Code Metrics for Improved Software Maintainability. In: International Conference on Semantics, Knowledge and Grid. pp Zhong, S.; Khoshgoftaar, T. M.; Seliya, N. Analyzing Software Measurement Data with Clustering Techniques. In: Intelligence Systems. v. 19, no. 2, pp Zhong; H.; Yang, Y.; Keung, J. Assessing the Representativeness of Open Source Projects in Empirical Software Engineering Studies. In: Asia-Pacific Software Engineering Conference. vol.1, pp

74 Análise da Qualidade de Experimentos da Computação em Nuvem Helaine Lins 1, Vinicius Garcia 1, Sergio Soares 1 1 Centro de Informática Universidade Federal de Pernambuco (UFPE) Recife PE Brasil {hsl,vcg,scbs@cin.ufpe.br} Abstract. Context: Despite the increasing number of studies evaluating Cloud Computing (CC), results become obsolete quickly. Furthermore, indications point low methodological quality in their conceptions. Objective: Measure and analyze the methodological quality of experiments in the context of CC. Method: Through a Systematic Literature Review the experiments on CC will be identified and analyzed regarding their quality. A measurement instrument will be constructed for measuring the quality of experiments, based on Empirical Software Engineering. Results: The characterization and analysis of the evolution of the quality of experiments in CC in order to contribute to efforts for conducting evaluation studies of higher methodological quality in CC. Resumo. Contexto: Apesar do aumento do número de experimentos na Computação em Nuvem (CN) seus resultados se tornam obsoletos rapidamente, além disso indícios apontam baixa qualidade metodológica em suas concepções. Objetivo: Caracterizar, analisar e medir a qualidade metodológica dos experimentos no contexto da CN. Método: Através de uma Revisão Sistemática da Literatura (RSL) serão identificados e qualificados os experimentos da CN. Será proposto instrumento sistemático para aferição de qualidade com base na Engenharia de Software Empírica (ESE). Resultados: Espera-se caracterizar e analisar a evolução da qualidade dos experimentos na CN com o intuito de contribuir com os esforços para realização de experimentos de melhor qualidade metodológica na CN. 1. Caracterização do Problema A Computação em Nuvem foi vislumbrada em 1961 por McCarthy [Garfinkel 1999]. O conceito propôs que os recursos de TI fossem providos sob demanda e bilhetados como serviço utilitário. Porém, por questões de evolução tecnológica só veio à tona apenas em 1999 quando a Salesforce R disponibilizou o primeiro produto cloud. Ao se firmar como um dos paradigmas mais promissores da computação [Buyya et al. 2009], a CN vem atraindo os olhares de gigantes como a Amazon, Google, Microsoft, IBM, HP, entre outras, que provêem uma grande variedade de serviços. Para reforçar a tendência de crescimento, segundo estimativas do International Data Corporation (IDC) 1, os investimentos em CN devem alcançar a casa dos US$100 bilhões em Esta grande variedade de ofertas torna natural a prática de avaliação entre os diferentes serviços disponíveis. Porém estas comparações são trabalhosas, já que os serviços existentes mudam e se renovam rapidamente [Prodan and Ostermann 2009], o que torna obsoleta a validade dos seus resultados. Outro fator agravante são as diferentes

75 terminologias, definições e falta de padronização ao se registrar e reportar os resultados. Estes problemas diminuem as possibilidades de continuidade a partir dos estudos existentes, pois se torna ineficiente o reaproveitamento em novos estudos, tanto acadêmicos quanto industriais. Apesar dos estudos de avaliação possuem relação bem próxima com a prática de experimentação [Stantchev 2009], evidências apontam a presença de problemas relacionados ao relato de seus resultados [Li et al. 2013, Huang et al. 2013, Nasir and Niazi 2011, Silva et al. 2013, Durao et al. 2014]. Assim, a presente pesquisa pretende: (i) identificar e caracterizar os experimentos da CN, (ii) propor um instrumento para análise da qualidade dos experimentos da CN e (iii) analisar a evolução da qualidade dos experimentos da CN e realizar um paralelo com os realizados na ESE. 2. Fundamentação Teórica O crescimento acelerado de tecnologias de comunicação como a Internet, tem atraído a atenção de grande parte da indústria de Tecnologia da Informação (TI). Conceitos como a Computação em Nuvem, Utility Computing e Everything-as-a-Service vem possibilitando a consolidação de um modelo em que os serviços de computação são utilizados como serviços utilitários sob demanda, como a telefonia [Kleinrock 2003]. Dentre os conceitos citados, a CN é o mais recente e segundo o National Institute of Standards and Technology (NIST) possui cinco características essenciais [Mell and Grance 2009]: (i) alocação de recursos sob demanda, (ii) amplo acesso à rede, (iii) recursos disponíveis sob demanda, (iv) recursos em qualquer quantidade e a qualquer momento e (v) serviço medido (recursos monitorados com transparência). Ainda segundo o NIST, CN possui três modelos de serviços: (i) Software como Serviço (SaaS), (ii) Plataforma como Serviço (PaaS) e (iii) Infraestrutura como Serviço (IaaS). Quando se deseja avaliar serviços cloud é necessária a aplicação de técnicas e instrumentos capazes de mensurar, de maneira controlada, o fenômeno investigado e que considere as características idiossincráticas desta tecnologia. Uma das abordagens bem utilizadas em CN é a prática de benchmarking, que através da aplicação de determinadas cargas de trabalho no sistema em teste [Poess and Floyd 2000], coleta dados que permitem um especialista mensure um conjunto de índices de performance sobre o referido sistema. Estas práticas de avaliação, assim como em outras ciências, devem ser realizadas com um determinado nível de controle de medição, execução, custo e replicabilidade. A ESE é uma área da Engenharia de Software (ES) que tem como objetivo auxiliar a realização de estudos experimentais, preocupando-se com ferramentas e processos de desenvolvimento para a compreensão de seus limites para projeções de melhorias. Dentre os métodos empíricos existentes na ESE, o Experimento Controlado (EC) é a estratégia que permite a investigação de uma hipótese testável, onde uma ou mais variáveis são manipuladas para medir o seu efeito sobre outras variáveis [Easterbrook et al. 2008]. A força de um EC encontra-se no controle sobre o processo, relacionamento tratamentoresultado, rigor estatítico, maior relação entre teoria-prática, bem como a possibilidade de replicá-lo. Segundo [Wohlin et al. 2012] um experimento pode ser clasificado segundo duas perspectivas: (i) base humana: onde aspectos humanos influenciam na realização do experimento e (ii) base tecnológica: onde os aspectos humanos não influenciam na realização do experimento. Este trabalho destina-se a investigar somente os experimentos de base tecnológica na CN, excluíndo-se do escopo os de base humana. Estudos secundários foram introduzidos na ES através da Engenharia de Software Baseada em Evidência (ESBE). Seu objetivo é permitir que evidências de pesquisas pos- 75

76 sam ser integradas com a prática e valores humanos na tomada de decisão no desenvolvimento e manutenção de software [Kitchenham et al. 2004]. Através destes é possível identificar, avaliar e interpretar todos os resultados relevantes a um determinada questão de pesquisa. A Revisão Sistemática da Literatura (RSL) é um estudo secundário que permite a análise ampla e exploratória de diversos estudos primários correlatos, como fonte de informação, para a construção de conhecimentos em ES. Na ESE, a Avaliação da Qualidade (AQ) foi inicialmente introduzida por Kitchenham et al. através de guidelines para auxiliar a qualidade na realização de estudos empíricos [Kitchenham et al. 2002]. Desde o primeiro passo de Kitchenham novos checklists de qualidade para diferentes tipos de estudos experimentais foram propostos na EBSE. Apesar de não existir um conceito absoluto de qualidade em estudos empíricos algumas constatações apontam que o conceito deve estar relacionado ao viés da pesquisa, aumento da validade (interna e externa) e à correta interpretação dos dados [Moher et al. 1995, Kitchenham et al. 2002]. 3. Objetivos e Contribuições O objetivo principal deste trabalho é investigar e delinear a evolução da qualidade dos experimentos de base tecnológica realizados no contexto da CN. Para tal, planeja-se (i) Realizar uma RLS para identificar e caracterizar os experimentos de base tecnológica da CN, (ii) Propor um instrumento de avaliação da qualidade de experimentos de base tecnológica da CN e (iii) Avaliar a qualidade dos experimentos identificados. Quanto à RSL, as contribuições esperadas são: (i) identificar e caracterizar os experimentos de base tecnológica da CN, (ii) delinear a evolução histórica destes experimentos, (iii) identificar novas oportunidades de pesquisa e (iv) disponibilizar um os dados da pesquisa de forma a contribuir com futuras pesquisas e análises. Quanto ao instrumento de avaliação de qualidade, esperamos contribuir no desenvolvimento de pesquisas futuras: (i) como um instrumento de aferição da qualidade metodológica de experimentos de base tecnológica da CN e (ii) os elementos do instrumento podem embasar a construção de guias que auxiliem o desenvolvimento de experimentos da CN com maior qualidade metodológica. Com a avaliação da qualidade em si, espera-se: (i) prover uma identificação do perfil metodológico dos experimentos de base tecnológica realizados na CN, (ii) identificar comonalidades e peculiaridades específicas de experimentos de base tecnológica realizados na CN em relação a ESE, (iii) racionalizar a importância do problema de qualidade metodológica dos experimentos da CN e (iv) identificar oportunidades de melhorias metodológicas que possam contribuir para a melhoria de experimentos da CN. 4. Cronograma e Estado Atual do Trabalho Durante o primeiro ano no programa de mestrado todas os créditos de disciplinas foram cumpridos. Também participo de reuniões periódicas e workshops do grupo de pesquisa Assert 2 e ESEG 3. A pretensão de defesa é para fevereiro de 2015 e o cronograma de pesquisa proposto é apresentado na tabela Trabalhos Relacionados Em sua RSL Li et al.[li et al. 2013] avaliou a qualidade de estudos de avaliação em sistemas cloud observando aspectos relacionados à organização, apresentação dos resultados

77 Atividade Revisão Sistemática da Literatura Instrumento de Avaliação Avaliação da Qualidade Escrita da Dissertação Meses Jun Jul Agos Set Out Nov Dez Jan Tabela 1. Cronograma Proposto e descrição. Apesar de conseguir identificar em sua investigação que, em geral, os estudos de avaliação são conduzidos ou reportados inadequadamente, sua análise considerou apenas as avaliações de sistemas comerciais, excluindo os experimentos controlados e os sistemas cloud não comerciais. O projeto proposto investigará todos os experimentos de base tecnológica em todas as plataformas da CN, e realizará uma investigação mais detalhada e analisará criteriosamente a evolução da qualidade destes quanto aos mecanismos de suporte utilizados, replicabilidade e rigor estatístico. Também será realizado um paralelo da qualidade comparando-se aos experimentos da ESE. Teixeira propôs uma escala de qualidade baseada em listas de verificação que permitem analisar quantitativamente a qualidade de estudos empíricos [Teixeira 2014]. Também foi proposto critérios de avaliação gerais e específicos que possibilitam sua aplicação em diferentes tipos de estudos. O mecanismo é baseado em critérios de qualidade aplicáveis ao contexto proposto pela pesquisa e como o mesmo permite a avaliação de estudos empíricos como um todo, ele se torna genérico incluindo aspectos baseados em experimentos baseado em humanos. Assim sendo, será proposto um novo mecanismo capaz de avaliar os experimentos de base tecnológica no contexto da CN. 6. Avaliação dos Resultados A RSL terá seu protocolo revisado por pares mais experientes dos grupos de pesquisa, em ESE e CN, que colaboram com a realização da pesquisa. Desta forma, a experiência de integrantes que já participaram de estudos sistemáticos anteriores será um elemento muito importante que poderá a vir influenciar positivamente a qualidade do estudo. O protocolo da RSL será revisado por especialistas em CN para ratificar as strings de buscas, a definição dos termos, os critérios de inclusão/exclusão e critérios de qualidade utilizados. Quanto ao processo de avaliação da qualidade por meio do instrumento a ser aplicado, iremos utilizar métricas para analisar a confiabilidade do instrumento através do coeficiente para escalas nominais amplamente utilizado na literatura, o Cohen s Kappa [Cohen 1968]. Referências Buyya, R. et al. (2009). Cloud computing and emerging it platforms: Vision, hype, and reality for delivering computing as the 5th utility. Future Generation computer systems, 25(6): Cohen, J. (1968). Weighted kappa: Nominal scale agreement provision for scaled disagreement or partial credit. Psychological bulletin, 70(4):213. Durao, F., Carvalho, J. F. S., Fonseka, A., and Garcia, V. C. (2014). A systematic review on cloud computing. The Journal of Supercomputing. 77

78 Easterbrook, S., Singer, J., Storey, M.-A., and Damian, D. (2008). Selecting empirical methods for software engineering research. In Guide to advanced empirical software engineering, pages Springer. Garfinkel, S. (1999). Architects of the information society: 35 years of the Laboratory for Computer Science at MIT. MIT press. Huang, Q., Yang, C., Liu, K., Xia, J., Xu, C., Li, J., Gui, Z., Sun, M., and Li, Z. (2013). Evaluating open-source cloud computing solutions for geosciences. Computers & Geosciences, 59: Kitchenham, B. A., Dyba, T., and Jorgensen, M. (2004). Evidence-based software engineering. In Software Engineering, ICSE Proceedings. 26th International Conference on, pages IEEE. Kitchenham, B. A., Pfleeger, S. L., Pickard, L. M., Jones, P. W., Hoaglin, D. C., El Emam, K., and Rosenberg, J. (2002). Preliminary guidelines for empirical research in software engineering. Software Engineering, IEEE Transactions on, 28(8): Kleinrock, L. (2003). An internet vision: the invisible global infrastructure. Ad Hoc Networks, 1(1):3 11. Li, Z., Zhang, H., O Brien, L., Cai, R., and Flint, S. (2013). On evaluating commercial cloud services: A systematic review. Journal of Systems and Software, 86(9): Mell, P. and Grance, T. (2009). The nist definition of cloud computing. National Institute of Standards and Technology, 53(6):50. Moher, D., Jadad, A. R., Nichol, G., Penman, M., Tugwell, P., and Walsh, S. (1995). Assessing the quality of randomized controlled trials: an annotated bibliography of scales and checklists. Controlled clinical trials, 16(1): Nasir, U. and Niazi, M. (2011). Cloud Computing Adoption Assessment Model (CAAM) BT - 12th International Conference on Product Focused Software Development and Process Improvement, PROFES 2011, June 20, June 22, Poess, M. and Floyd, C. (2000). New tpc benchmarks for decision support and web commerce. ACM Sigmod Record, 29(4): Prodan, R. and Ostermann, S. (2009). A survey and taxonomy of infrastructure as a service and web hosting cloud providers. In Grid Computing, th IEEE/ACM International Conference on, pages IEEE. Silva, G. C., Rose, L. M., and Calinescu, R. (2013). A Systematic Review of Cloud Lock-In Solutions IEEE 5th International Conference on Cloud Computing Technology and Science, pages Stantchev, V. (2009). Performance evaluation of cloud computing offerings. In Advanced Engineering Computing and Applications in Sciences, ADVCOMP 09. Third International Conference on, pages IEEE. Teixeira, E. O. (2014). Análise da Qualidade de Experimentos Controlados no Contexto da Engenharia de Software Empírica. Mestrado em ciência da computação, Universidade Federal de Pernambuco. Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., and Wesslén, A. (2012). Experimentation in software engineering. Springer. 78

79 Definição de um Framework para Avaliação Sistemática de Técnicas de Teste no Contexto de Programação Concorrente Silvana M. Melo 1, Orientadora: Simone R. S. Souza 1 1 Instituto de Ciências Matemáticas e de Computação (ICMC) Universidade de São Paulo (ICMC/USP) Caixa Postal São Carlos SP Brasil {morita,srocio}@icmc.usp.br Resumo. Este artigo apresenta um projeto de doutorado em andamento cujo objetivo é investigar as principais alternativas para a atividade de teste que têm sido empregadas no contexto de aplicações concorrentes, a fim de desenvolver um framework que auxilie a avaliação sistemática dessas técnicas, facilitando a realização de estudos futuros e, principalmente, ajudando os profissionais da academia e da indústria a selecionar a melhor técnica/ferramenta de teste considerando suas necessidades e diversos fatores de qualidade como satisfação, custo, eficácia e eficiência. 1. Fundamentação Teórica Com objetivo de identificar e eliminar defeitos presentes no produto de software, atividades de VV&T (Verificação, Validação e Teste) visam garantir a qualidade do software produzido. Dentre essas, o teste de software é uma atividade de garantia de qualidade que tem como objetivo identificar defeitos no produto em teste. A atividade de teste consiste de uma análise dinâmica do produto e é uma atividade relevante para a identificação e eliminação de erros que persistem. No contexto de programas tradicionais (ou programas com características sequenciais), foram identificadas ao longo dos anos várias iniciativas de técnicas e critérios para a validação, as quais consideram duas questões importantes em relação à atividade de teste: 1) seleção de casos de teste, e 2) avaliação da adequação dos casos de testes em relação ao programa em teste [Beizer 1990, Coward 1988, DeMillo et al. 1978, Herman 1976, Laski and Korel 1983, Maldonado 1991, Mathur and Wong 1993, Rapps and Weyuker 1985]. Outra tendência é explorar e adaptar esses conceitos de teste para outros domínios de aplicação, tais como: Sistemas de Informação, Aplicações Concorrentes/Distribuídas, Sistemas de Tempo Real e Sistemas Embarcados. Diferentemente dos programas tradicionais, a computação distribuída envolve programas concorrentes que interagem para realizar as tarefas. Essa interação pode ocorrer de forma sincronizada ou não, na qual esses programas (ou processos) podem ou não concorrerem pelos mesmos recursos computacionais. A construção de processos concorrentes requer o uso de primitivas para: definir quais processos serão executados em paralelo, iniciar e finalizar processos concorrentes e a garantir a coordenação entre os processos concorrentes enquanto estes estiverem executando [Almasi and Gottlieb 1989]. Desses três tipos de primitivas, destacam-se as primitivas necessárias à interação (comunicação e sincronização) entre os processos, devido à sua frequência de utilização, bem 79

80 como impacto no desempenho final do programa concorrente. A construção de programas concorrentes pode seguir dois diferentes paradigmas, classificados de acordo com a memória disponível [Almasi and Gottlieb 1989]. O paradigma de memória distribuída estabelece a comunicação e a sincronização entre os processos por meio da passagem de mensagens, no qual cada processo é executado por uma unidade de processamento que possui seu próprio espaço de endereçamento. No paradigma de memória compartilhada, a sincronização é obtida com a utilização de semáforos e monitores e variáveis compartilhadas são usadas para permitir a comunicação entre os processos que compartilham o mesmo espaço de endereçamento. Esses dois paradigmas apresentam características diferentes, as quais necessitam ser consideradas durante os testes. O teste de aplicações concorrentes é mais complicado, pois além das dificuldades inerentes à atividade de teste, novos desafios são impostos devido principalmente ao comportamento não determinístico no qual diferentes sequências de sincronização podem ser obtidas com utilização de uma mesma entrada. Diversos trabalhos relevantes têm sido propostos na área de teste de programas concorrentes e eles podem ser classificados em diferentes abordagens, considerando por exemplo: análise estática ou dinâmica [Chen et al. 2009], paradigma de passagem de mensagem [Silva et al. 2005] ou memória compartilhada [Yang and Pollock 2003] e considerando a linguagem e/ou o uso de padrões [Sadowski and Yi 2009, Farchi et al. 2003]. Embora existam diversas propostas de técnicas e ferramentas para o teste de programas concorrentes, não há ainda uma maneira de auxiliar os profissionais que trabalham com programas concorrentes na indústria ou na academia, sobre qual dentre as inúmeras abordagens de teste existentes seria mais apropriada para as suas necessidades. Informações sobre custo-benefício, alcançabilidade e limitações são necessárias para a escolha da estratégia de teste adequada. Segundo kitchenham et al. [Kitchenham et al. 2004], a proposta de novas metodologias pela academia, por si só, não é suficiente para a melhoria da qualidade do processo de software. Há que se considerar evidências sobre potenciais benefícios, limitações, custo e riscos associados a sua implantação na academia ou na indústria. 2. Caracterização do Problema Dado o panorama atual das pesquisas desenvolvidas para o teste de programas concorrentes como apresentado na revisão sistemática em [Souza et al. 2011], pode-se notar a relevância e diversidade das pesquisas que propõe abordagens de teste para o software concorrente. Porém, até o momento nenhum trabalho que propõe uma metodologia de avaliação de técnicas de teste para a área de programação concorrente foi encontrado. Nesse sentido, esta proposta de doutorado visa a investigar a definição de um framework de apoio para avaliação de técnicas e ferramentas de teste no contexto de programação concorrente. Tendo como base os trabalhos de Vos et al. [Vos et al. 2012] e Shull et al. [Shull et al. 2001], esse framework deverá apoiar os desenvolvedores de software concorrente na indústria e na academia, na escolha dos mecanismos de teste mais apropriados para os seus interesses e suas restrições de tempo/custo. 80

81 3. Metodologia e Estado Atual do Trabalho Para o desenvolvimento deste projeto serão previamente reunidos e classificados os principais trabalhos que propõem metodologias de teste para o contexto da programação concorrente. A fim de auxilar a avaliação dessas metodologias, um framework será definido. Para isso, a metodologia proposta por Vos et al. [Vos et al. 2012] será instanciada para o contexto de programação concorrente, o que facilitará a realização de estudos secundários e formação de um corpo de evidência que juntos irão compor o framework, proporcionando uma base de conhecimento sólida, funcionando como base de pesquisa e norteando a avaliação sistemática de ferramentas/métodos/técnicas de teste propostos para este contexto. Sendo assim, a metodologia de desenvolvimento do projeto pode ser dividida em quatro grandes fases, descritas a seguir: Realização de uma revisão de literatura: a fim de identificar, reunir e analisar pesquisas relacionadas às metodologias utilizadas para o teste de programas concorrentes, disponíveis na literatura. A replicação da revisão sistemática apresentada em [Souza et al. 2011], incluindo trabalhos mais recentes publicados na academia é um dos objetivos nessa fase. Seleção e estudo das tecnologias de teste a serem investigadas: com o objetivo de identificar as principais tecnologias propostas por pesquisadores e desenvolvedores no contexto do teste de programas concorrentes, trabalhos que disponibilizam metodologias consolidadas de teste serão selecionados com base nos resultados obtidos com a realização da revisão sistemática. Tais trabalhos serão classificados de acordo com suas contribuições. Instanciação da metodologia proposta em [Vos et al. 2012] para o contexto de programação concorrente: a metodologia de avaliação de técnicas e ferramenta de teste deve ser instanciada a fim de apoiar técnicas de teste que tratam características específicas das aplicações concorrentes, como: não determinismo, comunicação e sincronização de processos e threads. Construção e disponibilização do corpo de conhecimento: todos os resultados obtidos por meio da realização deste trabalho deverão ser reunidos para construção de um corpo de evidências disponibilizado como base de conhecimento. Atualmente o trabalho encontra-se na fase de seleção e classificação das tecnologias a serem investigadas. Um mapeamento sistemático está sendo conduzido com objetivo de identificar as principais técnicas/ferramentas que têm sido propostas para o teste de programa concorrentes que servirão como base para o framework proposto. Um artigo científico com os resultados obtidos no mapeamento sistemático está sendo produzido e deverá ser submetido a um periódico ou evento da área. 4. Trabalhos Relacionados Diversos trabalhos têm proposto técnicas e ferramentas para o teste de software concorrente, e tratam as mais diferentes abordagens, como: injeção de falhas [Artho et al. 2006], verificação formal [Wu et al. 2009], desenvolvimento dirigido a teste [Jagannath et al. 2010], execução controlada [Ball et al. 2009], teste de mutação [Gligoric et al. 2013], verificação de modelos [Yang et al. 2008], teste baseado em modelos [Aichernig et al. 2009], teste estrutural [Souza et al. 2014], análise simbólica 81

82 [Kundu et al. 2010], teste baseado em busca [Krena et al. 2010], teste de cobertura de interleaving [Yu et al. 2012], teste de concorrência probabilística [Burckhardt et al. 2010], teste de alcançabilidade [Lei and Carver 2006], métricas de cobertura [Deng et al. 2013] e geração de casos de teste [Xiaoan et al. 2009]. Tendo em vista a vasta diversidade de técnicas existentes, torna-se complexa a tarefa de escolha da técnica mais adequada a um determinado projeto. Nesse sentido, alguns trabalhos na área da programação sequencial tem explorado a avaliação de técnicas e ferramentas a fim de classificar quais apresentam maiores benefícios quando aplicadas a um determinado contexto [Kitchenham et al. 1995, Vos et al. 2012, Vegas et al. 2006, Pilar et al. 2014]. Esses estudos proporcionam aos profissionais de teste uma maneira de selecionar técnicas e ferramentas de maneira mais sistemática e metodológica, tomando como base evidências científicas. Vos et al. [Vos et al. 2012] propõem um framework que disponibiliza uma metodologia para facilitar a realização de estudos de caso para avaliar e comparar técnicas e ferramentas de teste. A Figura 1 ilustra a metodologia, que propõe um framework genérico para auxiliar a instanciação de estudos primários (casos de teste) para avaliar técnicas e ferramentas de teste. Os estudos primários são reunidos em um corpo de evidência, que pode ser usado em estudos secundários (revisões de literatura) a fim de auxiliar os profissionais de teste a tomar decisões informadas sobre o uso de uma técnica e estimar o tempo/esforço que é necessário para sua implantação. O principal objetivo da metodologia é gerar estudos empíricos suficientes para servir como base de experiências documentadas e que sigam os princípios da Engenharia de Software Baseada em Evidências (ESBE), uma abordagem que procura integrar as melhores evidências de pesquisas com experiências práticas e valores humanos para auxiliar no processo de tomada de decisão sobre o desenvolvimento e manutenção de software [Kitchenham et al. 2004]. Figura 1. Metodologia para criação de um corpo de evidência [Vos et al. 2012]. O framework proposto por Vos et al. [Vos et al. 2012] define uma metodologia de avaliação de técnicas de teste apenas para o contexto da programação sequencial. Há a necessidade de extender o framework para o contexto da programação concorrente, pois 82

83 características específicas deste tipo de aplicação que influenciam diretamente na atividade de teste devem ser consideradas durante sua avaliação. Características como: o comportamento não determinístico, o elevado número de sincronizações a serem exercitadas durante o teste; a necessidade de detectar e corrigir erros típicos desse tipo de software, como: deadloks, condições de disputa, interferência e livelocks, não são encontradas em aplicações sequenciais e portanto não suportadas pelo framework proposto em [Vos et al. 2012]. 5. Resultados Esperados Com o desenvolvimento deste projeto de doutorado esperam-se as seguintes contribuições e resultados: 1. Desenvolvimento de um framework para auxiliar a avaliação sistemática de técnicas de teste para o contexto de programas concorrentes. 2. Disponibilização do material gerado nas avaliações conduzidas a fim de facilitar a realização de estudos secundários e comparações entre tecnologias de teste. 3. Contribuir para a transferência de tecnologia gerada na academia para centros desenvolvedores de software concorrente na academia e indústria. 4. Ampliar o uso do teste, hoje fortemente concentrado na academia, permitindo com isso a geração de novas demandas de teste, as quais realimentarão as pesquisas feitas formando-se um ciclo no desenvolvimento de novos conhecimentos. 5. Possibilitar o desenvolvimento de aplicações distribuídas com maior qualidade, através da criação de um framework de aplicação das técnicas de VV&T considerando diversos fatores como satisfação, custo, eficácia e eficiência. 6. Formação de recursos humanos em VV&T de aplicações distribuídas considerando desenvolver 1 projeto de iniciação científica atrelado ao projeto em questão e desdobramento para novos projetos de iniciação científica, mestrado e doutorado. 6. Avaliação dos resultados A avaliação da metodologia proposta deverá ser feita por meio da condução de estudos empíricos na academia e indústria, visando aumentar a compreensão dos pesquisadores, tornando o processo de desenvolvimento de software mais previsível e contribuindo para o refinamento e aperfeiçoamento da tecnologia, auxiliando a busca por melhores práticas de teste. Segundo Shull et al. [Shull et al. 2001] a metodologia de avaliação de transferência de uma nova tecnologia para indústria deve sempre partir da definição conceitual até sua aplicação prática, com equilíbrio constante entre as necessidades de pesquisa e da indústria. A proposta de utilização da metodologia no contexto industrial tem por objetivo a avaliação da aplicabilidade das abordagens definidas no ambiente acadêmico também em um ambiente prático real, principalmente considerando tecnologias que propõem ferramentas de suporte ao teste que podem atender as necessidades da indústria. Parcerias estão sendo estudadas entre profissionais da área de teste que trabalham com software concorrente tanto dentro da academia, quanto no âmbito industrial. Empresas parceiras de projetos relacionados a este trabalho são possíveis candidatas nessa tarefa de colaboração para validação do trabalho e devem ser contatadas durante a fase de definição e validação da metodologia. 83

84 Agradecimento Os autores gostariam de agradecer a FAPESP, pelo apoio financeiro (processo número: 2013/ ). Referências Aichernig, B., Griesmayer, A., Schlatte, R., and Stam, A. (2009). Modeling and testing multi-threaded asynchronous systems with Creol. ENTCS, 243:3 14. Almasi, G. S. and Gottlieb, A. (1989). Highly parallel computing. Benjamin-Cummings Publishing Co., Inc., Redwood City, CA, USA. Artho, C., Biere, A., and Honiden, S. (2006). Enforcer - efficient failure injection. LNCS, 4085: Ball, T., Burckhardt, S., Coons, K. E., Musuvathi, M., and Qadeer, S. (2009). Preemption sealing for efficient concurrency testing. Technical report, Microsoft. Beizer, B. (1990). Software testing techniques. Van Nostrand Reinhold Co., New York, NY, USA, 2 edition. Burckhardt, S., Kothari, P., Musuvathi, M., and Nagarakatte, S. (2010). A randomized scheduler with probabilistic guarantees of finding bugs. In ASPLOS, pages , Pittsburgh, PA. Chen, Q., Wang, L., Yang, Z., and Stoller, S. D. (2009). Have: Detecting atomicity violations via integrated dynamic and static analysis. In Chechik, M. and Wirsing, M., editors, FASE, volume 5503 of LNCS, pages Springer. Coward, P. D. (1988). A review of software testing. Inf. Softw. Technol., 30: DeMillo, R. A., Lipton, R. J., and Sayward, F. G. (1978). Hints on test data selection: Help for the practicing programmer. Computer, 11(4): Deng, D., 0022, W. Z., and Lu, S. (2013). Efficient concurrency-bug detection across inputs. In Hosking, A. L., Eugster, P. T., and Lopes, C. V., editors, OOPSLA, pages ACM. Farchi, E., Nir, Y., and Ur, S. (2003). Concurrent bug patterns and how to test them. In IPDPS 03, pages 286.2, Washington, DC, USA. IEEE Computer Society. Gligoric, M., Zhang, L., Pereira, C., and Pokam, G. (2013). Selective mutation testing for concurrent code. In ISSTA, pages ACM. Herman, P. M. (1976). A data flow analysis approach to program testing. Australian Computer Journal, 8(3): Jagannath, V., Gligoric, M., Jin, D., Rosu, G., and Marinov, D. (2010). Imunit: improved multithreaded unit testing. In IWMSE 10, pages 48 49, New York, United States. ACM. Kitchenham, B., Pickard, L., and Pfleeger, S. L. (1995). Case studies for method and tool evaluation. Software, IEEE, 12(4): Kitchenham, B. A., Dybaa, T., and Jorgensen, M. (2004). Evidence-Based Software Engineering. In Proceedings of ICSE 2004, pages IEEE Computer Society Press. Krena, B., Letko, Z., Vojnar, T., and Ur, S. (2010). A platform for search-based testing of concurrent software. In International Workshop on Parallel and Distributed Systems: Testing, Analysis, and Debugging (PADTAD 2010), pages 48 58, Trento, Italy. 84

85 Kundu, S., Ganai, M. K., and Wang, C. (2010). Contessa: Concurrency testing augmented with symbolic analysis. Lecture Notes in Computer Science (LNCS), 6174: Laski, J. W. and Korel, B. (1983). A data flow oriented program testing strategy. IEEE Trans. Softw. Eng., 9: Lei, Y. and Carver, R. H. (2006). Reachability testing of concurrent programs. IEEE Transactions on Software Engineering, 32: Maldonado, J. C. (1991). Critérios Potenciais Usos: Uma Contribuição ao Teste Estrutural de Software. PhD thesis, DCA/FEEC/UNICAMP, Campinas, SP. Mathur, A. P. and Wong, E. W. (1993). An empirical comparison of mutation and data flow based test adequacy criteria. Journal of Software Testing, Verification, and Reliability 4(1): Pilar, M., Simmonds, J., and Astudillo, H. (2014). Semi-automated tool recommender for software development processes. Electronic Notes in Theoretical Computer Science, 302(0): Proceedings of the Latin American Computing Conference (CLEI 2013). Rapps, S. and Weyuker, E. J. (1985). Selecting Software Test Data Using Data Flow Information. IEEE Trans. Softw. Eng., 11(4): Sadowski, C. and Yi, J. (2009). Tiddle: A trace description language for generating concurrent benchmarks to test dynamic analyses. In WODA. Shull, F., Carver, J., and Travassos, G. H. (2001). An empirical methodology for introducing software processes. In ESEC, pages Silva, R., Pezzi, G., Maillard, N., and Diverio, T. (2005). Automatic data-flow graph generation of mpi programs. In SBAC-PAD, pages Souza, P. S. L., do Rocio Senger de Souza, S., and Zaluska, E. (2014). Structural testing for message-passing concurrent programs: an extended test model. Concurrency and Computation: Practice and Experience, 26(1): Souza, S. R. S., Brito, M. A. S., Silva, R. A., Souza, P. S. L., and Zaluska, E. (2011). Research in concurrent software testing: a systematic review. In PADTAD, pages 1 5. Vegas, S., Juzgado, N. J., and Basili, V. R. (2006). Packaging experiences for improving testing technique selection. Journal of Systems and Software, 79(11): Vos, T. E. J., Marín, B., Escalona, M. J., and Marchetto, A. (2012). A methodological framework for evaluating software testing techniques and tools. In QSIC, pages Wu, M., Zhou, B., and Shi, W. (2009). A self-adaptive test framework for concurrent programs. In MEDES, pages , Lyon, France. Xiaoan, B., Na, Z., and Zuohua, D. (2009). Test case generation of concurrent programs based on event graph. In 5th International Joint Conference on INC, IMS, and IDC (NCM 2009), pages , Seoul, Korea. Yang, C.-S. D. and Pollock, L. L. (2003). All-uses testing of shared memory parallel programs. Softw. Test., Verif. Reliab., 13(1):3 24. Yang, Y., Chen, X., and Gopalakrishnan, G. (2008). Inspect: a runtime model checker for multithreaded C programs. Technical report, University of Utah. Yu, J., Narayanasamy, S., Pereira, C., and Pokam, G. (2012). Maple: a coverage-driven testing tool for multithreaded programs. In Leavens, G. T. and Dwyer, M. B., editors, OOPSLA, pages ACM. 85

86 Integração de Práticas Ágeis: Uma abordagem para melhorar a qualidade de especificações de software em projetos mobile Juliana Dantas R. V. de Medeiros 1, Alexandre M. L. de Vasconcelos 2, Carla T. L. L. Silva Schuenemann 2 1 Instituto Federal de Educação, Ciência e Tecnologia da Paraíba (IFPB) Jaguaribe, CEP: , João Pessoa-PB, Brasil 2 Centro de Informática (Cin) Universidade Federal de Pernambuco (UFPE) Cidade Universitária , Recife-PE, Brasil. juliana.medeiros@ifpb.edu.br, {amlv,ctllss}@cin.ufpe.br Abstract. The requirements engineering has been identified as a source of problems in adopting agile approaches. This research proposes an exploratory study in the industry. The aim is to investigate how the requirements engineering has been used in agile projects. In this context, a case study will be conducted in companies that develop mobile applications in Pernambuco. Then a new approach for specifying requirements in mobile projects will be defined, integrating the best practices of agile and adhering to CMMI-DEV. A controlled experiment will be performed to assess the quality and productivity of the proposed approach. Resumo. A engenharia de requisitos vem sendo apontada como uma das fontes de problemas na adoção das abordagens ágeis. Esta pesquisa propõe um estudo exploratório na indústria que tem por objetivo investigar como a engenharia de requisitos vem sendo utilizada em projetos ágeis e qual a qualidade das especificações geradas. Nesse contexto, será realizado um estudo de caso em empresas que desenvolvem aplicativos mobile em Pernambuco. Em seguida será elaborada uma nova abordagem para especificação de requisitos em projetos mobile, integrando as melhores práticas das metodologias ágeis e aderente ao CMMI-DEV. Para avaliar a qualidade e a produtividade da abordagem proposta será realizado um experimento controlado. 1. Caracterização do Problema De acordo com Thayer (1997), a Engenharia de Requisitos (ER) fornece o mecanismo apropriado para entender o que o cliente deseja, analisando as necessidades, verificando a viabilidade, negociando soluções, especificando-as sem ambiguidade e gerenciando suas mudanças. Apesar da importância da ER no sucesso do desenvolvimento do software e na minimização dos riscos de projeto, essa atividade é vista nos métodos ágeis como burocrática que torna o processo menos ágil. As Metodologias Ágeis possuem processos flexíveis e adaptativos e que aceitam as mudanças como parte inseparável do seu processo de desenvolvimento, visando à melhoria na qualidade de software e o aumento da satisfação do cliente [Highsmith 86

87 2000]. Alguns autores como Paetsh (2003) entendem que a engenharia de requisitos e os métodos ágeis podem ser considerados atividades incompatíveis. Além disso, evidências de pesquisas [Kamei 2012] em projetos que adotam Metodologias Ágeis apontam problemas de backlogs muito instáveis, dificuldades dos engenheiros de software em se adaptarem às mudanças constantes de requisitos, e ainda em aplicar práticas ágeis como User Stories e TDD (Test Driven Development). Analisando a duas principais lojas de aplicativos móveis (App Store e Google Play) é possível constatar que houve um crescimento de 50% nos últimos 12 meses na quantidade de aplicativos disponíveis. Estima-se que atualmente existem mais de aplicativos nessas duas plataformas [Techcrunch 2014]. Associado a este crescimento, tem-se o fato das aplicações estarem cada vez mais complexas, sendo essencial a aplicação dos princípios da engenharia de software. Entretanto, Wasserman (2010) relata a existência de poucas pesquisas científicas envolvendo a engenharia de software para dispositivos móveis, e considera que as atuais metodologias ágeis não atendem às peculiaridades do desenvolvimento para dispositivos móveis, apontando diversas áreas problemáticas que necessitam de estudos, dentre elas o levantamento de requisitos. Nesse contexto, o objetivo geral desta pesquisa é investigar como a engenharia de requisitos vem sendo conduzida em projetos que adotam práticas ágeis para desenvolver software. Com resultado dessa investigação, pretende-se propor uma nova abordagem que, através da integração de práticas ágeis, contribua para uma melhoria na qualidade das especificações de requisitos, em especial, para projetos de desenvolvimento de software para dispositivos móveis. Para isso foi definida a seguinte Questões de Pesquisa Principal (QP): QP: Como a engenharia de requisitos está sendo utilizadas em projetos que utilizam metodologias ágeis? 2. Fundamentação Teórica e Trabalhos Relacionados 2.1. Metodologias Ágeis As definições modernas de desenvolvimento de software ágil evoluíram a partir da metade de 1990 como parte de uma reação contra métodos "pesados". O processo originou-se da visão de que o modelo em cascata era burocrático, lento e contraditório à forma usual que os engenheiros de software trabalham. As Metodologias Ágeis foram criadas com intuito de eliminar os problemas causados pelas metodologias tradicionais. A definição oficial de Desenvolvimento Ágil de software foi criada sob forma de um Manifesto Ágil [Agile 2001] publicado em fevereiro de 2001 por um grupo de 17 especialistas em desenvolvimento de software que se reuniram com o objetivo de propor melhores práticas para desenvolver software. Este grupo foi denominado Aliança Ágil e, apesar de não terem chegado num consenso para definição de uma metodologia única, definiram quatro valores e doze princípios para nortear as metodologias ágeis. Baseadas nos princípios e valores do Manifesto, diversas metodologias têm sido propostas. Mais de uma década se passou desde o manifesto, entretanto, evidências de pesquisas em projetos que usam abordagens ágeis apontam limitações na sua adoção na indústria, alguns das quais relacionados à engenharia de requisitos [Kamei 2012]. 87

88 2.2. Engenharia de requisitos Requisitos são o ponto de partida para a definição de sistemas e consequentemente, são fatores decisivos no desenvolvimento do produto final. Pressman (2011) define requisito como sendo uma especificação do que deve ser implementado ou um algum tipo de restrição do sistema, e define a Engenharia de Requisitos (ER) como uma das importantes disciplinas da engenharia de software, sendo constituída de 7 tarefas: concepção, levantamento, elaboração, negociação, especificação, validação e gestão. As metodologias ágeis tratam a ER de modo bastante distinto dos modelos tradicionais. Quanto à identificação dos requisitos, os modelos ágeis prezam por um overview geral do problema sem maiores detalhes, e focam na elaboração de uma divisão desses itens de modo a serem definidos de maneira iterativa e incremental. Para isso, são definidos períodos fixos e curtos chamados de iterações em que um subconjunto de itens é detalhado e implementado. Nas metodologias ágeis só se deve focar no essencial e emergente para aquele momento, enquanto nas metodologias tradicionais as atividades de projeto e implementação necessitam da precedência de grandes esforços para especificação das funcionalidades [Filho 2011]. Dependendo da metodologia ágil empregada, técnicas\estratégias diferentes podem ser utilizadas para especificar requisitos. Ambler (2002) e Swaber (2002) realizaram estudos procurando analisar como a engenharia de requisitos pode ser melhor empregada em projetos ágeis. Entretanto, segundo o Standish Group (2013), apenas 39% dos projetos que utilizaram metodologias ágeis tiveram sucesso. Ou seja, continuamos nos deparando com altos índices de projetos com prazos e orçamentos estourados e que não atendem aos requisitos dos usuários. 3. Contribuições Esta pesquisa tem o objetivo de trazer contribuições para a Engenharia de Requisitos, especificamente quando aplicada em projetos ágeis de desenvolvimento de software para dispositivos móveis. A seguir destacamos as principais contribuições da pesquisa: A primeira contribuição é a realização de uma pesquisa indutiva e qualitativa, por meio de uma Revisão Sistemática da Literatura (RSL) como instrumento para observação do problema. O objetivo da revisão é coletar evidências que possam ser usadas para apoiar nas próximas atividades previstas para esta pesquisa; Realização de uma pesquisa qualitativa, mais especificamente, um Estudo de Caso em empresas do Porto Digital de Pernambuco. O objetivo é investigar e compreender a utilização, prática na indústria, das atividades de engenharia de requisitos que estão sendo aplicadas em projetos mobile, procurando identificar as limitações e a relação entre o uso das técnicas e a qualidade das especificações geradas e os atrasos nos projetos. Espera-se que o Estudo de Caso gere ideias e hipóteses que irão subsidiar a elaboração da nova abordagem. Elaboração de uma nova abordagem para especificação de requisitos em projetos mobile, integrando as melhores práticas das metodologias ágeis e aderente ao CMMI-DEV. Essa nova abordagem deverá ser um processo para engenharia de requisitos, descrevendo as técnicas de requisitos a serem utilizadas, as entradas e 88

89 as saídas previstas, e os procedimentos envolvidos. No contexto deste artigo, essa nova abordagem será chamada de BRA. Estudos realizados por Kamei (2012) apontam diversas limitações na adoção das Metodologias Ágeis, sendo uma delas a falta de estudos empíricos que apresentem resultados sobre as mesmas. Para avaliar a nova abordagem proposta será realizada uma pesquisa quantitativa, mais especificamente, um experimento controlado, sendo essa mais uma contribuição deste trabalho. O experimento será utilizado para avaliar a abordagem BRA e uma outra abordagem já existente, que será selecionada a partir dos resultados obtidos na RSL e no Estudo de Caso. Neste artigo, essa outra abordagem será chamada de XXX. 4. Estado Atual do Trabalho A seguir serão detalhadas as atividades já realizadas e o que está em andamento Revisão Sistemática da Literatura Os guidelines definidos por Kitchenham (2007) foram seguidos para planejar e executar a RSL, tendo sido feitas algumas adaptações propostas por Silva et al. (2011). A Figura 1 ilustra as etapas da revisão. Já foram concluídas as atividades (A), (B) e (C). RSL: Figura 1. Etapas da Revisão Sistemática - Adaptado de Silva et al. (2001) Foram definidas duas Questões de Pesquisa específicas para a realização da QP1.1: Quais práticas (atividades e técnicas) de engenharia de requisites de software estão sendo utilizadas em projetos de desenvolvimento de software que adotam metodologias ágeis? QP1.2: Quais os benefícios e limitações das atuais práticas de Engenharia de Requisitos quando adotadas em projetos que usam abordagens ágeis? Foram definidos 4 (quatro) critérios de inclusão e 8(oito) critérios de exclusão. O processo de pesquisa desta RSL foi realizado combinando busca automática e manual a fim de atingir uma ampla cobertura. Como fonte de dados manual foram selecionados artigos de 2008 à 2013 provenientes de uma conferência da área de Requisitos e de outra conferência específica da área de Metodologias Ágeis. Foram definidos 6 (seis) motores de busca como fonte de dados automática. A string utilizada para a busca automática foi construída com base em três termos extraídos das questões de pesquisa: requisitos, metodologias ágeis e software. A busca automática foi realizada através da ferramenta Reviewer 1. Para a busca automática não houve limitação de período de ano de publicação. 1 Reviewer ( 89

90 Com objetivo de diminuir o viés da pesquisa, os artigos resultantes da busca manual e automática foram distribuídos em 3 partes, sendo cada parte também analisada por um outro pesquisador, aluno de mestrado. A primeira etapa da Seleção dos Estudos (D) foi realizada aplicando-se os critérios de inclusão e exclusão analisando o título e o resumo de todos os artigos. No momento, está sendo feita a segunda etapa da seleção que consiste na aplicação dos critérios lendo a introdução e a conclusão dos artigos selecionados na primeira etapa Estudo de Caso O estudo de caso será conduzido seguindo o processo recomendado por Yin (2010), conforme apresentado na Figura 2. A disponibilidade das empresas que irão participar do Estudo de Caso será um fator essencial para o sucesso desta pesquisa. Figura 2. Processo para condução do Estudo de Caso - Adaptado de Yin (2010) A fase de Planejamento foi realizada tendo sido definida a Questão de pesquisa (QP) específica abaixo, além das duas Questões de Pesquisa definidas para a RSL: QP1.3: Existe relação entre a maneira como as equipes especificam os requisitos e o cumprimento dos prazos e a quantidade de bugs identificados? Como instrumento para a coleta de dados foi definida a utilização de entrevistas com engenheiros de software e a análise de documentos. Os dados serão analisados qualitativamente com o intuito de obter um entendimento sobre o processo a ser realizado. Os dados serão codificados de forma a extrair os significados dos relatos das entrevistas. Na análise de resultados haverá a triangulação como mecanismo para limitar os efeitos de interpretação de uma única fonte, além de aumentar a qualidade da pesquisa e reduzir as ameaças à validade. As demais fases previstas na Figura 2 serão iniciadas após o término da RSL, podendo eventualmente, haver algum ajuste nesse planejamento Elaboração de nova abordagem A elaboração da nova abordagem será feita levando-se em conta as peculiaridades intrínsecas do desenvolvimento para dispositivos móveis, dentre as quais: Regras de negócio compartilhadas com outros aplicativos tradicionais; Impacto do surgimento de novos dispositivos móveis na mudança de requisitos; Adequação das necessidades do usuário aos recursos de interface, memória, processamento e segurança disponíveis; Para elaboração da nova abordagem serão consideradas as metas e práticas do CMMI-DEV relacionadas à área de processo Desenvolvimento de Requisitos (RD - 90

91 Requirements Development). O objetivo é tornar a nova abordagem aderente ao referido modelo de qualidade no que diz respeito aos requisitos de software Experimento Controlado O planejamento para execução do experimento já foi realizado, tendo sido definida a seguinte Questão de Pesquisa (QP): QP1.4: Há diferença na utilização das abordagens BRA e da abordagem XXX no que diz respeito à qualidade das especificações geradas e do protótipo das telas construídos, e com relação à produtividade (tempo gasto para executar as atividades de ER)? Como parte do planejamento foram definidas as variáveis dependentes (resposta) e o Fator (variável independente), conforme Figura 3. Figura 3. Modelo Conceitual do Experimento Pretende-se executar o experimento utilizando projetos voltados para a indústria. O desenho experimental definido para um fator foi o Within-Subjects, onde os sujeitos recebem os dois tratamentos (abordagem BRA e XXX). Foras definidas três Hipóteses Nulas para avaliar se as abordagens são iguais no que diz respeito à qualidade e produtividade. Como forma de garantir uma maior confiabilidade de conclusão, será utilizado um teste estatístico, por exemplo, TESTE-T para análise dos dados coletados. 5. Avaliação dos Resultados 5.1. Resultados parciais da Revisão Sistemática da Literatura (RSL) A execução da busca automática retornou 2501 artigos. E a busca de dados manual retornou 344 artigos, totalizando assim, 2845 artigos. A utilização da ferramenta Reviewer para a busca automática agilizou a seleção inicial feita a partir do título e do resumo, tendo em vista que não foi necessário fazer o download dos artigos, pois no resultado gerado pela ferramenta já constavam essas informações. Após a primeira etapa da Seleção, o total de artigos foi reduzido à 305. A realização da segunda etapa da seleção tem demandado um esforço maior, tendo em vista a necessidade de se fazer o download dos artigos, e muitas vezes os artigos não são facilmente localizados. A RSL ainda não foi concluída, mas já proporcionou resultados importantes, tendo direcionado o foco da pesquisa para aplicação da ER em projetos mobile. A análise dos artigos sinalizou uma carência de pesquisas nessa área Resultados parciais do Estudo de Caso e Experimento A realização do planejamento antecipado do Estudo de Caso e do Experimento Controlado foi importante para permitir uma melhor compreensão do problema e uma 91

92 maior percepção do que deve fazer parte da solução proposta. Por exemplo, a ideia inicial para BRA era propor uma nova técnica focada na especificação de requisitos. Entretanto, durante a fase de planejamento do experimento controlado, analisando as ameaças à validade, foi possível perceber que uma abordagem focada apenas na especificação poderia comprometer a qualidade. A partir dessa análise, identificamos a necessidade da abordagem contemplar todo o processo de ER. Referências Agile Manifesto. (2001) Manifesto for Agile Software Development, 17 February Disponível em: < Acesso em: 26/05/2014. Ambler, S. W. (2002) Agile Modeling: Effective Practices for extreme Programming and the Unified Process. Wiley Chichester, ISBN Filho, H. F. B. P. (2011) Um estudo analítico entre as abordagens de Engenharia de Requisitos nas Metodologias Ágeis XP, SCRUM e Crystal. Monografia, UFPE. Highsmith, J. A. (2000) Adaptive software development: a collaborative approach to managing complex systems. New York, NY, USA: Dorset House Publishing. Kamei, F. K. (2012). Benefícios e Limitações das Metodologias Ágeis no Desenvolvimento de Software. Dissertação de mestrado, UFPE. Kitchenham, B.; Charters S. (2007) Guidelines for performing Systematic Literature Reviews in Software Engineering. Vol 2.3, EBSE , Keele, UK. Paetsh, F., Eberlein, A. and Maurer, F. (2003) Requirements Engineering and Agile Software Development, In: 12th IEEE International WETICE 03, IEEE CS Press. Pressman, R. S. (2011) Engenharia de Software - Uma Abordagem Profissional. 7a. Edição, McGrawHill. Schwaber, K. (2002) The Impact of Agile Processes on Requirements Engineering. Disponível: < Acesso em: 26/5/14. Silva, F. et al. (2011) Replication of Empirical Studies in Software Engineering: Preliminary Findings from a Systematic Mapping Study. Canada. RESER Standish Group. (2013). The CHAOS Manifesto Disponível em: Acesso: 26/05/2014. Techcrunch. (2014). itunes App Store Now Has 1.2 Million Apps.... Disponível em: Acesso: 30/07/2014. Thayer, R.H., and M. Dorfman. (1997) Software Requirements Engineering, 2d ed., IEEE Computer Society Press. Yin, R. K. (2010). Estudo de caso: planejamento e métodos. 2ed. Bookman. Wasserman, I. A. (2010). Software Engineering Issues for Mobile Application Developmen. Carnegie Mellon Silicon Valley. 92

93 Título do trabalho: Alocação de Participantes no Merge de Ramos Nome do aluno: Catarina de Souza Costa Nome do orientador: Leonardo Gresta Paulino Murta Nível: Doutorado Programa de pós-graduação: Programa de Pós-Graduação em Computação UFF de contato do aluno: de contato do orientador: Ano de ingresso no programa: 2012 Época prevista de conclusão: Março de 2016 Data da aprovação da proposta de tese/dissertação (qualificação): Setembro de 2014 Resumo: No processo de desenvolvimento de software, os artefatos são construídos e manipulados por diversos desenvolvedores que trabalham em paralelo. Uma prática comum neste processo é a ramificação da base de código em várias linhas de desenvolvimento. As alterações nos artefatos em cada ramo são combinadas via processo de merge. No entanto, alterações conflitantes podem surgir durante este processo. Quando estes conflitos não são resolvidos de maneira automática, decisões de conciliação por parte do desenvolvedor que está encarregado do merge são necessárias. Contudo, nem sempre o conhecimento do desenvolvedor em relação ao trabalho realizado em paralelo é levado em consideração ou se ele é realmente a pessoa mais apropriada para tomar as decisões de conciliação. Neste sentido, este trabalho objetiva propor um método de alocação de participantes no merge de ramos, que possa auxiliar na escolha do desenvolvedor mais apropriado para realizar o merge. Sigla(s) do(s) evento(s) do CBSoft relacionado(s): SBES 93

94 1. Caracterização do Problema É cada vez mais comum equipes desenvolverem software de maneira colaborativa, onde diferentes pessoas trabalham em paralelo, alterando os mesmos arquivos, e, em muitas das vezes, os mesmos trechos de código nestes arquivos. Estes desenvolvedores podem estar trabalhando em ramos diferentes, para promover a evolução de software de forma isolada (e.g., segregando manutenção evolutiva de corretiva). Porém, em algum momento essas mudanças precisam ser combinadas através de um processo de merge. Normalmente o merge de trabalho sem isolamento, sobre um mesmo ramo, é mais simples que o merge entre ramos, visto que seu propósito é integrar os commits de um único desenvolvedor com os commits remotos. Já o merge entre ramos tende a combinar duas sequências independentes e possivelmente longas de commits, que podem ter sido realizados por diversos desenvolvedores. Nos dois contextos, em caso de alterações que não possam ser combinadas de maneira automática, o desenvolvedor a realizar o merge é o responsável pela conciliação de decisões e resolução dos conflitos. Porém, resolver conflitos de merge não é uma tarefa simples. Enquanto duas alterações feitas em paralelo podem, individualmente, resultar em versões que funcionam corretamente, a tentativa de combinação dessas versões pode demandar conciliação de escolhas feitas por diferentes desenvolvedores (SARMA; REDMILES; VAN DER HOEK, 2012). O desenvolvedor responsável pelo merge entre ramos usualmente assume sozinho a responsabilidade de realizar as conciliações por toda a equipe. Apesar disso, nem sempre o conhecimento do desenvolvedor em relação ao trabalho realizado em paralelo é levado em consideração ou se o desenvolvedor é realmente a pessoa mais apropriada para tomar as decisões de conciliação. Alguns trabalhos defendem que a resolução de um conflito não deve ser responsabilidade somente de um desenvolvedor, e propõem que desenvolvedores possam resolver conflitos de merge de forma colaborativa (KOEGEL et al., 2010; NIEMINEN, 2012). O merge colaborativo pode ser uma solução interessante, principalmente para o merge entre ramos, em que os desenvolvedores estão isolados e podem não conhecer o trabalho realizado em paralelo. Porém, as propostas de merge colaborativo deixam a cargo do próprio desenvolvedor a escolha de outro desenvolvedor para o merge. Embora alocação de desenvolvedor em requisições de mudanças seja amplamente tratado na literatura, a alocação de desenvolvedores na atividade de merge tem sido relegada. 2. Fundamentação Teórica A Gerência de Configuração de Software (GCS) é uma disciplina que busca acompanhar todo o processo de desenvolvimento de software (LEON, 2000). Segundo Estublier (2000), a GCS permite a evolução de produtos de software sob controle, contribuindo assim para a qualidade e redução de atrasos. Neste cenário, os Sistemas de Controle de Versão (SCV), parte integrante da Gerência de Configuração, são fundamentais. Os SCV fornecem mecanismos para a ramificação em várias linhas de desenvolvimento e o merge do código fonte de uma linha de desenvolvimento com 94

95 outra (APPLETON et al., 1998). Ramos podem ser nomeados ou não nomeados. Os ramos não nomeados são criados de forma implícita, quando, por exemplo, um desenvolvedor clona um projeto de um repositório. Os ramos nomeados, criados de forma explicita, são novas linhas de desenvolvimento que seguem em paralelo a uma linha principal. Esses ramos podem ter diferentes propósitos (SANTOS; MURTA, 2012), como isolar desenvolvedores inexperientes, segregar manutenção evolutiva de corretiva, customizar o software para diferentes contextos, etc. Usualmente, em algum momento os ramos são combinados em uma nova versão por meio de um merge. O merge deve combinar corretamente as alterações conflitantes feitas ao longo de cada linha de desenvolvimento desde quando o ramo foi criado (ou desde a última vez que as duas linhas de desenvolvimento foram sincronizadas) (APPLETON et al., 1998). Segundo Mens (2002) três tipos de conflitos podem surgir durante o merge: textual, sintático e semântico. Conflitos textuais, também conhecidos como conflitos físicos, ocorrem quando operações simultâneas (por exemplo, a adição, remoção ou edição) ocorrem sobre as mesmas partes físicas de um arquivo (por exemplo, a mesma linha). Conflitos sintáticos ocorrem quando operações simultâneas conflitantes ocorrem no mesmo elemento sintático do arquivo. A estrutura sintática de um arquivo é geralmente definida em termos de um esquema ou de uma gramática. Finalmente, conflitos semânticos ocorrem quando as operações simultâneas interferem na semântica do arquivo. A semântica do arquivo pode ser expressa tanto em termos de semântica da linguagem de programação (i.e., relação entre elementos sintáticos) ou comportamento esperado do programa (geralmente verificada por casos de teste). 3. Contribuições Para tratar o problema apresentado na Seção 1 e fundamentado na Seção 2, este trabalho de doutorado propõe um método de alocação de desenvolvedores para a atividade de merge de ramos. Para a construção e evolução do método, é levada em consideração a revisão da literatura, para identificar o estado da arte, e uma pesquisa de opinião, para identificar o estado da prática O método se baseia na análise do histórico do projeto até o ponto da tentativa de merge, verificando os desenvolvedores envolvidos e os artefatos alterados no processo de construção do histórico até aquele momento. O método leva em consideração diferentes granularidades no processo de alocação de desenvolvedores: o projeto como um todo, arquivos e partes dos arquivos (e.g., métodos) alteradas. Ao olhar para o projeto como um todo, levando-se em conta o número de commits feitos por cada desenvolvedor até então, além de commits dos desenvolvedores nos dois ramos, o método realiza uma contagem de commits para identificar quais desenvolvedores devem participar da seção de merge. Por outro lado, ao considerar cada arquivo individualmente, o conhecimento de potenciais conflitos físicos para a alocação de desenvolvedores também é utilizado, levando-se em conta quais arquivos foram alterados nos dois ramos e quem os alterou, assim como quem é o especialista de cada arquivo. A informação sobre qual alteração afetou cada arquivo pode ser obtida diretamente dos metadados do SCV, via comandos de log. Já na verificação considerando partes dos arquivos, é possível usar o conhecimento de potenciais conflitos sintáticos, levando-se em conta, por exemplo, quais métodos foram afetados pelas alterações e quem alterou esses métodos, assim 95

96 como seus especialistas. A informação sobre qual alteração afetou cada método pode ser obtida via Árvore Sintática Abstrata (AST). Por fim, ao considerar métodos alterados, também é possível usar o conhecimento de potenciais conflitos semânticos via verificação da dependência entre os métodos que os desenvolvedores alteraram e/ou dependências indiretas entre métodos, através de variáveis. Para tal, técnicas como program slicing podem ser utilizadas. Como visto a percepção de quem é especialista pode variar em função da análise utilizada, verificada nas diferentes granularidades. Na Figura 1 é apresenta a estrutura do método de alocação de participantes para merge colaborativo de ramos. O histórico do projeto até o momento do merge é fundamental tanto para a etapa de Extração (responsável pela recuperação das informações dos desenvolvedores e artefatos alterados), quanto para os demais passos do método de alocação de participantes. O método inclui ainda as etapas de Tratamento, que tem o proposito de verificar e combinar alguns dados para extrair informações sintáticas e semânticas do projeto, Análise, com o proposito de verificar as informações extraídas e tratadas buscando evidências que permitam a alocação de desenvolvedores e, finalmente, Alocação, que é responsável pela classificação de desenvolvedores e indicação dos mais recomendados a participar do merge colaborativo. Cada uma destas etapas do método são descritas nas próximas seções Extração Figura 1. Visão Geral do Método A primeira etapa do método de alocação é a extração do histórico dos projetos de software clonados de um repositório. No processo de extração, as cabeças (do inglês heads) do merge em questão são identificadas. Na Figura 2, é possível visualizar um exemplo de merge entre C4 e C7, que visa gerar uma nova versão, C8. Figura 2. Exemplo de Merge Após a identificação dos commits a serem combinados, é identificado o ancestral comum, neste caso, C1. A partir destas informações, é possível identificar todos os commits dos ramos que estão sendo combinados. Por exemplo, no merge em questão são capturadas informações dos autores e artefatos alterados nos commits C5, C6 e C7, 96

97 que pertencem a um dos ramos, e dos commits C2, C3 e C4, que pertencem ao outro ramo. Além disso, informações do histórico do projeto até o ancestral comum também são capturadas para viabilizar a identificação de especialistas. Neste exemplo, essas informações se referem aos commits C0 e C1. Nesta fase, são extraídos nome e dos autores de cada commit que fazem parte do histórico do projeto até o momento da extração. São extraídas também informações sobre os artefatos alterados em cada commit, para o tratamento em diferentes granularidades: arquivo (nível físico) e método (níveis sintático e semântico). A partir desta etapa, tem-se os nomes e s de todos os desenvolvedores que realizaram commits relevantes para o merge em questão e quais artefatos e partes de artefatos foram modificados por esses commits Tratamento A etapa de tratamento refere-se à manipulação das informações extraídas. Inicialmente, as informações dos autores, como nome e , são tratadas para reduzir a possibilidade de registros de um único desenvolvedor sejam contatos como de diferentes desenvolvedores. Esse tratamento é necessário tendo em vista que os dados recuperados do histórico são informados pelos próprios desenvolvedores na configuração do repositório. Assim, um mesmo desenvolvedor pode ter diferentes cadastros em um mesmo projeto. Em relação aos artefatos alterados a cada commit, no nível físico são verificadas informações quanto aos arquivos adicionados, removidos ou modificados nos ramos e quem foram os autores das operações. Neste processo, apenas metadados extraídos do SCV são utilizados. No nível sintático são verificadas as partes que foram modificadas. Com a ajuda de uma AST, são verificados a que métodos essas partes modificadas pertencem. Neste processo, são combinadas informações de metadados do repositório do SCV e do código fonte do projeto. Assim, é possível saber quais desenvolvedores alteraram os métodos de cada arquivo do projeto e alocar um desenvolvedor baseado nas alterações dele nos métodos do arquivo em conflito. Já no nível semântico, dependências são verificadas. Essas dependências podem ser obtidas por meio de análise de acoplamento estrutural, lógico ou mesmo via program slicing Análise A etapa de análise é guiada por questões sobre o histórico do projeto até aquele ponto de merge, que variam de acordo com a granularidade definida. Essas questões incluem: (1) Quem são os especialistas nos artefatos alterados nos ramos? (2) Quem alterou os artefatos em cada ramo? (3) Qual é a relação entre os artefatos alterados em cada ramo? Para cada granularidade definida, métricas diferentes devem ser extraídas. No caso da análise do projeto como um todo, são extraídas informações sobre a quantidade de commits dos desenvolvedores dos ramos do merge e quais desenvolvedores que fizeram commits em ambos os ramos. No caso de análises no nível de arquivo, são extraídas informações referentes aos arquivos modificados nos ramos e desenvolvedores que modificaram estes arquivos. No caso de análise no nível de método, no nível sintático, são identificados os métodos que foram alterados pelo desenvolvedor, e, no nível semântico, a dependência lógica entre esses métodos. 97

98 3.4. Alocação A etapa de alocação é parametrizada pelo usuário que objetiva a combinação de dois ramos. O método permite ao usuário optar pela indicação de um único desenvolvedor ou de um conjunto de desenvolvedores a participar do merge (neste segundo caso, merge colaborativo). Para o merge colaborativo, o número de participantes alocados varia de acordo com o histórico extraído do merge em questão e da classificação destes com a análise das métricas definidas. A alocação sempre visa indicar o número mínimo de desenvolvedores para participar do merge e resolver o conflito de maneira apropriada. 4. Estado Atual do Trabalho Um estudo preliminar foi conduzido considerando o projeto como um todo para demonstrar as etapas do método. Para isso, foram utilizados dois projetos reais: Git e Voldemort. Na Tabela 1 são apresentadas informações quanto ao número de merges e de desenvolvedores dos projetos analisados, métricas definidas para caracterizar o perfil dos projetos. Como pode ser visto, foram extraídas informações sobre todos os merges realizados até o momento da extração. O número de merges dos projetos é variado: 406 no projeto Voldemort e no projeto Git. Quanto ao número de desenvolvedores, existe também uma grande variação: 59 desenvolvedores no projeto Voldemort e no projeto Git. Tabela 1. Informações de merges e desenvolvedores Projeto Número de Merges e Desenvolvedores Descrição # Merges # Desenvolvedores Git Sistema de Controle de Versão Distribuído Voldemort Banco de Dados Distribuído Utilizou-se média harmônica para ordenar os merges dos projetos e identificar os casos de merge potencialmente mais complexos, ou seja, com muitos desenvolvedores em cada ramo. No projeto Git, por exemplo, o cenário de merge mais complexo em relação a desenvolvedores, dado por média harmônica, tem 158 desenvolvedores no ramo 1 e 10 no ramo 2. Destes, 5 desenvolvedores realizaram commits em ambos os ramos, como pode ser visto na Tabela 2. Tabela 2. Desenvolvedores que realizaram commits em ambos os ramos Merge a8816e7bab03 Desenvolvedores em ambos os ramos Projeto Git Desenvolvedores Commits no ramo 1 Commits no ramo 2 Markus 23 5 Alex 7 1 Shawn 2 4 Jens 1 4 Ferry 1 1 Na Tabela 3 são listados os 3 desenvolvedores do projeto Git que mais realizaram commits em cada ramo. Para este merge, há uma interseção entre os desenvolvedores nas análises, assim, os desenvolvedores Markus, Shawn e Jens poderiam ser candidatos a participar do merge colaborativo. No projeto Voldemort, o merge mais complexo em termos de número de desenvolvedores, ordenado por média harmônica, tem 4 desenvolvedores no ramo 1 e 8 desenvolvedores no ramo 2. Para este merge, os desenvolvedores que realizaram commits em ambos os ramos também foram 98

99 os que mais realizaram commits. Neste caso, os desenvolvedores Bhusesh, Kirktrue, Alex e Bbansal seriam candidatos a participar do merge colaborativo. Tabela 3. Desenvolvedores que realizaram commits em ambos os ramos Merge a8816e7bab03 Desenvolvedores com mais commits Projeto Git Desenvolvedores Commits no ramo 1 Commits no ramo 2 Junio Schindelin 69 0 Jeff 58 0 Markus 23 5 Shawn 2 4 Jens 1 4 Essa análise inicial é baseada em contagem de commits, sem considerar os artefatos alvo destes commits. Nos próximos passos do trabalho serão extraídas e analisadas informações nas diferentes granularidades, arquivo e método. Espera-se comparar os resultados das diferentes abordagens do método de alocação proposto. Tabela 4. Desenvolvedores que realizaram commits em ambos os ramos Merge 2a5c69145fb6 Desenvolvedores com mais commits em ambos os ramos Projeto Voldemort Desenvolvedores Commits no ramo 1 Commits no ramo 2 Bhusesh Kirktrue Alex Bbansal Comparação com Trabalhos Relacionados Resolução de conflitos de merge é um tópico muito citado em pesquisas baseadas em técnicas de percepção (do inglês awareness). Ao monitorar os espaços de trabalho, ferramentas de percepção, como Palantír (SARMA; REDMILES; VAN DER HOEK, 2012) e CloudStudio (ESTLER et al., 2013), notificam os desenvolvedores cada vez que uma mudança que pode levar a um conflito está sendo feita. Outras abordagens, como o Crystal (BRUN et al., 2011) e WeCode (GUIMARÃES; SILVA, 2012), tentam continuamente realizar merge das cópias locais dos vários desenvolvedores. Porém, equipes podem trabalhar em ramos diferentes, não possibilitando a detecção preventiva dos conflitos. Os trabalhos que tratam de merge colaborativo normalmente discutem merge de código e merge de modelo. Nieminen (2012) propõe uma ferramenta baseada na web, denominada CoRED, que permite que vários usuários possam resolver conflitos de merge de código de uma forma colaborativa. Já o trabalho de Koegel et al., (2010) apresenta uma abordagem de merge de modelos. Nesta abordagem os conflitos são agregados em um problema que precisa ser debatido e as alternativas para resolver os conflitos representam propostas. Em nenhum dos trabalhos é considerado um método de escolha dos desenvolvedores para o merge colaborativo. A decisão fica a cargo do próprio desenvolvedor. 6. Avaliação dos Resultados Para a avaliação dos resultados preliminares e futuros, pretendem-se verificar se os desenvolvedores alocados pelo método foram os que realizaram efetivamente o merge. Para os casos em que o alocado não for o mesmo desenvolvedor que realizou o merge, será conduzido um estudo qualitativo para verificar a fundo essa divergência. Pretende- 99

100 se ainda analisar um projeto em andamento utilizando o método nas diversas granularidades para a alocação dos desenvolvedores especialistas no merge. Neste caso, será possível verificar com a equipe do projeto, de acordo com seus conhecimentos sobre o desenvolvimento, a real contribuição desta indicação. 7. Considerações Finais Este trabalho propõe um método de alocação de participantes para merge colaborativo baseado no histórico do projeto até o momento do merge. Acredita-se que as etapas definidas no método contribuem para a indicação dos desenvolvedores mais adequados para ajudar na resolução de conflitos. Além disso, algumas análises foram apresentadas como resultados preliminares, demonstrando a evolução das etapas do método proposto. Das três granularidades definidas, apenas uma foi utilizada nas análises (contagem de commits considerando o projeto como um todo). Porém, a identificação de especialistas, baseada na contribuição de cada desenvolvedor em cada artefato, é o próximo passo da pesquisa, que acreditamos permitir uma sugestão mais precisa. Referências APPLETON, Brad et al. Streamed lines: Branching patterns for parallel software development. 1998, [S.l.]: Citeseer, BRUN, Yuriy et al. Proactive detection of collaboration conflicts. 2011, p SANTOS, Rafael; MURTA, Leonardo Gresta Paulino. Monitoramento da Complexidade de Junção de Ramos em Sistemas de Gerência de Configuração. In: Simpósio Brasileiro de Engenharia de Software, ESTLER, H. Christian et al. Unifying Configuration Management with Merge Conflict Detection and Awareness Systems. ASWEC 13, 2013, Washington, DC, USA. Anais... Washington, DC, USA: IEEE Computer Society, p ESTUBLIER, Jacky. Software configuration management: a roadmap. ACM, GUIMARÃES, Mário Luís; SILVA, António Rito. Improving early detection of software merge conflicts. ICSE 2012, 2012, Piscataway, NJ, USA. Anais... Piscataway, NJ, USA: IEEE Press, p KOEGEL, Maximilian et al. Collaborative model merging. SPLASH 10, 2010, New York, NY, USA. Anais... New York, NY, USA: ACM, p LEON, Alexis. A Guide to Software Configuration Management. [S.l.]: Artech House, Incorporated, MENS, Tom. A state-of-the-art survey on software merging. Software Engineering, IEEE Transactions on, v. 28, n. 5, p , NIEMINEN, A. Real-time collaborative resolving of merge conflicts. In: TH International Conference on Collaborative Computing: Networking, Applications and Worksharing (Collaboratecom), 2012, [S.l: s.n.], p SARMA, Anita; REDMILES, David; VAN DER HOEK, Andre. Palantir: Early Detection of Development Conflicts Arising from Parallel Code Changes. IEEE Trans. Softw. Eng., v. 38, n. 4, p , jul

101 A Meta-Process Oriented to Software Product Quality Based on ISO/IEC and Compliant with CMMI-DEV and MR-MPS-SW Models Aluno: Carlos dos Santos Portela Orientador: Prof. Dr. Alexandre Marcos Lins de Vasconcelos (UFPE) Co-Orientador(es): Prof. Dr. Sandro Ronaldo Bezerra Oliveira (UFPA) / Prof. Dr. Marco Paulo Amorim Vieira (Universidade de Coimbra) Nível: Doutorado Programa de Pós-graduação: Programa de Pós-graduação em Ciência da Computação Centro de Informática, Universidade Federal de Pernambuco (CIn/UFPE) de contato do aluno: csp3@cin.ufpe.br dos orientadores: amlv@cin.ufpe.br, srbo@ufpa.br, mvieira@dei.uc.pt Ano de ingresso no programa: Março/2013 Época prevista de conclusão: Março/2017 Data da aprovação da proposta de tese (qualificação): Outubro/2014 Abstract. There are many standards and models with definitions and recommendations related to the quality of the software process and product, such as ISO/IEC 12207, ISO/IEC 15504, ISO/IEC 25000, CMMI and MPS.BR. However, the execution of a certificated process in a quality model does not necessarily guarantee a software product with quality. This paper proposes an analysis on the ISO/IEC and ISO/IEC standards and the CMMI-DEV and MR-MPS-SW models in order to identify the Software Engineering activities that ensure the quality of the software product according to the defined characteristics in the ISO/IEC Initially, we intend to conduct a systematic literature review on the relationship between the quality of the software process and product. From this analysis about the standards and models and from the systematic review results, we intend to define a software meta-process oriented to product quality. Posteriorly, we will accomplish a controlled experiment with software projects from a company that has its process certified by the CMMI-DEV or MR-MPS-SW. We expect this meta-process to assist the software development organizations in obtaining quality in their products since it is based on standards and models largely accepted. Keywords: Software Engineering, Software Quality Characteristics, Process Lifecycle, Review Systematic Literature, Controlled Experiment. Siglas do evento do CBSoft relacionado (SBES): Engenharia de software experimental; Processos de software; Qualidade de software e modelos de qualidade. 101

102 1. Problem Characterization The Software Quality is an area growing significantly because of the users who are increasingly requiring efficiency and effectiveness, among other quality characteristics important to a product as special as software [Guerra and Colombo, 2009]. Parallel to this market demand, there is a national and international movement to establish norms and standards in the Software Engineering area. When speaking of the quality of the software development process, it is important to highlight the MR-MPS-SW (Modelo de Referência MPS para Software - SPI Reference Model to Software) [SOFTEX, 2012], the CMMI-DEV (Capability Maturity Model Integration for Development) [SEI, 2010], the ISO/IEC Information Technology - Process Assessment [ISO/IEC, 2003], and the ISO/IEC Systems and Software Engineering - Software Life Cycle Process [ISO/IEC, 2008]. Regarding the quality of the software product, there are the ISO/IEC 9126 [ISO/IEC, 2006] standard that was the basis for construction of the new series ISO/IEC SQuaRE Software Quality Requirements and Evaluation [ISO/IEC, 2014]. However, the execution of a certificated process in a quality model does not guarantee a production of a software product with quality. There is a gap in the efforts being conducted in the search for quality: the process concentrates its efforts on the quality of the software production and maintenance mode, while the quality of the software product is focused more intensely when it is finalized through the evaluation of its performance [Guerra and Colombo, 2009]. The purpose of this paper is to propose an empirical analysis of the ISO/IEC and standards, the CMMI and MPS.BR models, and other approaches identified in systematic review, in order to identify the Software Engineering activities and to ensure quality of the software product from the defined characteristics in the ISO/IEC [ISO/IEC, 2014]. The Section 2 presents the theoretical background of this research. The research contributions are described in the Section 3. In the Section 4, the details of the actual stage of this doctoral work are showed. In the Section 5, the related works are compared with this work. Finally, the Section 6 presents the evaluation of the results according to the research s objectives. 2. Theoretical Background The ISO/IEC [ISO/IEC, 2006] proposes characteristics and sub characteristics that software should possess to have quality attributes. The ISO/IEC was issued in 2005, and the ISO/IEC 25010, which supersedes the ISO/IEC , was issued in The ISO/IEC has eight product quality characteristics and 31 subcharacteristics [ISO/IEC, 2014]. This standard can be applied in the definition of quality requirements of a software product and also in the evaluation of the software developed. For this reason, this standard will be the main theoretical background of these phases in the metaprocess proposed in this work. The ISO/IEC standard describes that the quality of a software system can be understood in different ways and be used in different approaches [ISO/IEC, 2014]. 102

103 For this reason, we will not define a concept of quality in this work in order to not narrow the scope of this study. Hence, the focus of this study is to identify approaches on quality. The approach term is used in this research in order to represent instruments used in the definition and implementation of the development processes oriented to the software product quality, such as models, standards, frameworks, processes, methodologies, tools, techniques, methods and procedures. The process lifecycle term represents a well-defined set of steps that provide a reference for the monitoring of the development process and its evolution: process definition, process enactment, process evaluation, process improvement, and process reuse. The activities of this cycle are called meta-activities and the lifecycle is called software meta-process [Oliveira, 2007]. 3. Contributions From this empirical study, the types of approaches presented in the selected studies will be identified. These approaches should be classified and quantified according to their type: models, standards, frameworks, processes, methodologies, tools, techniques, methods or procedures. Moreover, we intend to analyze the context in which these approaches are highly recommended. The comprehensiveness of the identified approaches will be analyzed in relation to their grounds, research method and obtained results. This analysis will focus on the strategy of the relationship between the process and product quality that are presented in the selected studies. From the systematic review, we intend to extract a mapping between certain activities of the development process and characteristics of the software product quality. The goal is to create a catalog of these activities by considering the entry and the output criteria, responsible, step-by-step, procedures, templates, methods and tools used in implementing these activities. Moreover, this catalog will present an impact analysis of each these activities and its relationship with the quality characteristics in the product resulting from the execution of these activities. Finally, as the main result of this research, we intend to define the software meta-process that allows the development of a product according to the quality desired by the project sponsor. The idea is to first establish a quality profile of this meta-process and then evaluate the characteristics of the product developed at the end of this cycle according to this defined profile. A sketch of this meta-process was discussed among researchers based on their experience and based on the initial results of this research. This sketch is shown in Figure 1. Figure 1. Meta-Process Sketch 103

104 4. Current Status of Work The research stages and its current state can be found in Table 1. Table 1. Research Project Status Research Phase Definition of Research Questions Systematic Literature Review Doctoral Qualifying Defense Definition of a Catalog of Process Activities Related to the Quality Product Specification of a Meta-Process Oriented to Product Quality Controlled Experiments Testing the Doctoral Thesis Hypotheses Writing the Doctoral Thesis Doctoral Thesis Defense Dissemination of Search Results Status Done In progress Scheduled for Out/2014 Scheduled for Dec/2014 Scheduled for Jun/2015 Scheduled for Aug/2015 Scheduled for Nov/2015 Scheduled until Jul/2016 Scheduled until Mar/2017 In progress 5. Comparison with Related Work From his experience dealing with customers who deploy customized software products, Rohleder (2009) learned that deriving products from shared software assets requires more than complying with quality standards like ISO/IEC He emphasizes that developers must also consider the quality profile of final products. His work describes a process that follows the quality profile of final products during product derivation and it helps to provide and validate industrial software application solutions. However, this approach focuses only on the evaluation of the final product when finalized, and does not consider the impact of the steps taken on the software development process. Grimán et al. (2007) claim that the architecture constitutes a very important work product to obtain product quality. They propose a method to estimate software reliability by evaluating software architecture. Software quality characteristics, such as reliability, maintainability, usability, portability, among others, can be directly determined by software architecture. This work is useful for addressing the quality characteristics based on the assessment of an intermediate product. However, this approach only deals the product quality with regard its architecture. Li et al. (2010) emphasize that the ability to respond to changes in the environment during the software development is crucial in achieving a quality product. Based on dynamic capability theory, they build a software quality model that is dependent on team flexibility, and this one dependent on reactive and anticipatory capabilities of the team members. Different from the proposal presented in this work, this approach does not consider the process factor in getting quality product, just the human factor. However, this approach will be useful in the treatment of human 104

105 resources component and its dynamic in the software meta-process proposed in this work. After identifying process activities that add quality to product, it is necessary to identify measures to stabilize the process and thus stabilize the product quality. In this context, Barcelos and Rocha (2008) highlight that an essential element for the statistical process control application is the suitability of the metrics being used. Therefore, in his work he presents a tool to evaluate statistical metrics schemes, considering their applicability in the statistical process control. This approach does not directly address the evaluation of quality of software products issue. However, the use of statistical process control in performance process analysis can identify actions that are needed for the stabilization and improvement of those processes. 6. Results Evaluation This research aims to evaluate the proposals of the literature concerning the following question: What are the approaches to support the process lifecycle oriented to product quality in the software projects context? From this research problem the following research question was defined: RQ: What is the relationship between the development process activities and the software product quality? This main research question will guide every step of this doctoral research Systematic Review The guidelines of Kitchenham and Charters (2007) were followed to plan the review. To execute this review, some steps were instantiated from Silva et al. (2011). The Figure 2 illustrates these review steps that will be followed in this review. Figure 2. Systematic Review Steps According to the main research question and based on the research objectives, secondary research questions are defined. These secondary questions facilitate and guide the data extraction from studies selected for this research. These questions aims to clarify important details that this review seeks to identify, to collaborate with the research project. These questions are presented follows: 105

106 RQ1: What the approaches are used in support of process lifecycle oriented processes to product quality? RQ2: How do these approaches address the relationship between the process quality and product quality? RQ3: What is the impact of the enactment of certain process activities in obtaining of the product quality characteristics? The search process was performed combining automatic and manual search to achieve a high coverage. The researchers will analyze the title and abstracts of all published papers within a range of 10 years (2004 to 2014). This range was used because the quality initiatives in the form of quality models have gained strength in Brazil 10 years ago from the institutionalization of the model MPS.BR. The manual search was performed on four conferences proceedings, selected according to the research area of this proposal: QSIC (International Conference on Quality Software); PROFES (International Conference on Product-Focused Software Process Improvement); SBQS (Simpósio Brasileiro de Qualidade de Software Brazilian Symposium on Software Quality); WAMPS (Workshop Anual do MPS Annual Workshop of MPS.BR model). The automatic search was performed on five search engines and indexing systems: ACM Digital Library ( IEEE Xplore ( ISI Web of Knowledge ( Scopus ( El Compendex ( To build the search string, synonyms were joined with OR and the set of synonyms for each term were joined with AND, as shown in Figure 3. Figure 3. Generic Search String Four researchers are conducting this systematic review. The search string has been executed and returned 1595 studies in automatic search published studies were identified in the manual search. These 2891 studies returned, only 2426 are available for review. Currently, this review is in the studies selection phase. The Mendeley free reference manager and MS Excel software was used to support the search and selection processes. 106

107 6.2. Controlled Experiment After the conclusion of the systematic review, a catalog of software engineering activities identified in the systematic review and in the ISO/IEC and standards will be elaborated. This catalog is going to contain descriptions of the procedures required to implement those activities. Subsequently, we will conduct controlled experiments with software projects owned by a company that has a CMMI- DEV or MPS.BR certificate. A controlled experiment is an investigation of a testable hypothesis where one or more independent variables are manipulated to measure their effect on one or more dependent variables [Easterbrook et al., 2007]. Controlled experiments allow us to precisely determine how variables are related to each other and whether a cause-effect relationship exists between them. Thus, the controlled experiments will take place after the first steps of this research and the definition of the hypothesis. The controlled experiment aims to measure the effect of the independent variable of the process activity in the quality characteristic of the dependent variable of the product. This will occur through the identification of measures to stabilize the implementation of these activities in order to stabilize the achievement of quality of the software product. Given that are 8 quality characteristics and 31 subcharacteristics, will be identified the most approached characteristics in the data extracted from the studies of the systematic review. In the controlled experiment, some of these characteristics will be selected in order to limit the scope of this research and validate the proposed metaprocess. This experiment is going to follow the guidelines laid down by Wholin et al. (2000) and is intended to be used in software projects of Brazilian companies located in the cities of Recife and Belém. The metrics will be defined according to the characteristics of the company and the product / process that are focus of this validation. The team will consist of members of the organization and researchers. 7. Acknowledgment The authors would like to thank CAPES (Coordenação de Aperfeiçoamento de Pessoal de Nível Superior - Coordination Program for Improvement of Postgraduate People) for financial supporting the development of this work. References Barcellos, M. and Rocha, A. R. (2008) Avaliação de Bases de Medidas considerando sua Aplicabilidade ao Controle Estatístico de Processos de Software. In Proceedings of VII Simpósio Brasileiro de Qualidade de Software, pages Easterbrook, S. et al. (2007) Selecting Empirical Methods for Software Engineering Research. In F. Shull, J. Singer and D. Sjøberg. Guide to Advanced Empirical Software Engineering, Chapter 11. Springer. 107

108 Grimán, A. et al. (2007) A Method Proposal for Architectural Reliability Evaluation. In Proceedings of the Ninth International Conference on Enterprise Information Systems, pages 1 5. Guerra, A. and Colombo, R. (2009). Tecnologia da Informação: Qualidade de Produto de Software. In Programa Brasileiro da Qualidade e Produtividade, pages 429. MCT/SEPIN, Brasília. ISO/IEC (2003) ISO/IEC Information Technology Software Process Assessment, International Organization for Standardization and the International Electrotechnical Commission, Geneva, Switzerland. ISO/IEC (2014) ISO/IEC Software Engineering Software Product Quality Requirements and Evaluation (SQuaRE) - Guide to SQuaRE, International Organization for Standardization and the International Electrotechnical Commission, Geneva, Switzerland. ISO/IEC (2006) ISO/IEC Information Technology Software Product Quality - Part 1: Quality Model, International Organization for Standardization and the International Electrotechnical Commission, Geneva, Switzerland. ISO/IEC (2008) ISO/IEC 12207: Systems and Software Engineering Software Lifecycle Process, International Organization for Standardization and the International Electrotechnical Commission, Geneva, Switzerland. Kitchenham, B. and Charters, S. (2007) Guidelines for performing systematic literature reviews in software engineering. Technical Report EBSE , Keele University and Durham University Joint Report. Li, Y. et al. (2010) Software Development Team Flexibility Antecedents. In Journal of Systems and Software, pages Oliveira, S. (2007) ProDefiner: Uma Abordagem Progressiva para a Definição de Processos de Software no Contexto de um Ambiente Centrado no Processo, Doctoral Thesis in Computer Science Centro de Informática, Universidade Federal de Pernambuco. Rohleder, C. (2009) Quality Product Derivation: A Case Study for Quality Control at Siemens 3 Quality Product Derivation. In Proceedings of the 8th World Scientific and Engineering Academy and Society, pages SEI Software Engineering Institute (2010) CMMI for Development V 1.3, April. Silva, F. Q. et al. (2011) Replication of empirical studies in software engineering preliminary findings from a systematic mapping study, In International Workshop on Replication in Empirical Software Engineering Research, pages SOFTEX Associação para Promoção da Excelência do Software Brasileiro (2012) Guia Geral MPS de Software: 2012, April. Wohlin, C. et al. (2000) Experimentation in software engineering: an introduction. Kluwer Academic Publishers, Norwell, MA, USA. 108

109 Search-Based Mutation Testing para Programas Concorrentes Rodolfo Adamshuk Silva 1, Simone do Rocio Senger de Souza 1 1 Instituto de Ciências Matemáticas e de Computação Universidade de São Paulo (ICMC/USP) Caixa Postal São Carlos SP Brazil Projeto de Doutorado {adamshuk,srocio}@icmc.usp.br Programa de Pós-Graduação em Ciências de Computação e Matemática Computacional do ICMC-USP Ano de ingresso no programa: 03/2013 Época prevista de conclusão: 02/2017 Data da aprovação da proposta de tese: Previsão de 15/09/2014 Sigla do evento do CBSoft relacionado: SBES Resumo. O teste de software é uma atividade que busca garantir a qualidade por meio da identificação de falhas no produto. Para a aplicação do teste de software, algumas técnicas são utilizadas como, por exemplo, a técnica estrutural, a funcional e a baseada em defeitos. Cada técnica possui seus critérios para auxiliar na criação dos casos de teste. Um dos critérios da técnica baseada em defeitos é o teste de mutação. Este critério de teste baseia-se nos enganos que podem ser cometidos pelos desenvolvedores de software. O teste de mutação tem se mostrado eficaz para revelar defeitos, porém, o seu alto custo compromete sua utilização, principalmente quando são considerados programas complexos. A Programação Concorrente é um paradigma de desenvolvimento essencial para a construção de aplicações com o intuito de reduzir o tempo computacional em muitos domínios. Estas aplicações têm novas características como comunicação, sincronização e não determinismo que precisam ser considerados durante a atividade de teste. No contexto de programas concorrentes, novos desafios são impostos e precisam ser adequadamente tratados. Isso ocorre devido ao não determinismo e as diferentes sincronizações entre processos. Search-Based Software Testing é uma abordagem que vem sendo empregada para otimizar a atividade de teste, aplicando meta-heurísticas para a solução de problemas complexos, como por exemplo, geração de dados de teste. Este projeto de doutorado está inserido nesse contexto, no qual se pretende investigar o uso de Search-Based Software Testing para redução do custo da aplicação do teste de mutação no contexto de aplicações concorrentes. Palavras-chave. Teste de mutação, Search-Based Testing, Programação concorrente. 109

110 1. Introdução Como um resultado dos avanços tecnológicos na área de hardware, por exemplo, processadores multicore, a computação distribuída faz-se cada vez mais presente nos sistemas atuais. Com isso, a programação concorrente está tornando-se cada vez mais popular no desenvolvimento de softwares modernos. Esse paradigma de desenvolvimento é essencial para a construção de aplicações capazes de reduzir o tempo computacional em vários domínios, por exemplo softwares para processamento de imagens, dinâmica de fluidos, entre outros. Diferentemente dos programas com características sequenciais, a computação distribuída envolve programas (ou processos) concorrentes (ou paralelos) que interagem para resolver um determinado problema. Essa interação pode ocorrer de forma sincronizada ou não, sendo que esses programas podem ou não concorrerem pelos mesmos recursos computacionais. Teste de software é uma atividade de garantia de qualidade que visa a identificar defeitos no produto em teste. A atividade de teste consiste em uma análise dinâmica do produto e é uma atividade relevante para a identificação e eliminação de defeitos que persistem. O teste de produtos de software envolve basicamente quatro etapas: planejamento de testes, projeto de casos de teste, execução e avaliação dos resultados dos testes [Myers et al. 2011]. Essas atividades devem ser desenvolvidas ao longo do próprio processo de desenvolvimento de software e, para isso, um ponto crucial é a seleção dos casos de teste que serão utilizados. Sabe-se que executar todos os casos de teste possíveis a partir do domínio de entrada do produto em teste é impraticável e, portanto, critérios de teste são definidos. Os critérios de teste procuram estabelecer como selecionar casos de teste que possuam alta probabilidade de encontrar a maioria dos defeitos com um mínimo de tempo e esforço. Um teste bem sucedido é aquele que consegue determinar casos de teste para os quais o programa em teste falhe. Um dos critérios de testes da técnica baseada em defeitos é o teste de mutação. Este critério utiliza informações sobre os enganos típicos que podem ser cometidos no processo de desenvolvimento para derivar casos de teste [Jia and Harman 2011]. Assim, os defeitos típicos de um domínio ou paradigma de desenvolvimento são caracterizados e implementados como operadores de mutação que, durante a atividade de teste, geram versões modificadas (mutantes) do produto em teste (especificação ou implementação, por exemplo). A intenção é auxiliar a seleção de casos de teste que demonstrem que os defeitos modelados pelos operadores de mutação não estão presentes no produto em teste. Um problema do teste de mutação que impede que ele seja aplicado amplamente é o alto custo computacional de executar o enorme número de mutantes com os casos de teste, além do alto número de casos de teste necessários para alcançar um escore de mutação mais próximo de 1.0 [Jia and Harman 2011]. A atividade de teste no contexto de programas concorrentes é considerada mais complexa quando comparada com a atividade de teste de programas sequenciais. Além das dificuldades inerentes à atividade de teste, outras ocorrem devido, principalmente, ao comportamento não determinístico dessas aplicações, no qual múltiplas execuções de um programa concorrente com a mesma entrada podem executar diferentes sequências de sincronização e podem produzir diferentes resultados. Cabe à atividade de teste, nesse cenário, identificar se todas as sequências de sincronização possíveis foram executadas e se as saídas obtidas estão corretas. Essa característica difere os programas concorrentes dos programas sequenciais e precisa 110

111 ser considerada durante a atividade de teste de software. Assim como os demais critérios de teste, o teste de mutação tem sido investigado para programas concorrentes [Offutt et al. 1996, Silva-Barradas 1998, Bradbury et al. 2006, Silva 2013]. 2. Motivação e Objetivo A busca por estratégias que visem a automatização de teste de software é constante não só para o critério de mutação, mas também para os outros critérios. Isso vem acontecendo porque os programas a serem testados estão cada vez maiores e mais complexos, tornando a atividade de teste mais custosa, em termos financeiros e computacionais, e mais demorada. Até mesmo programas simples são custosos de serem testados devido ao problema de explosão de casos de testes [Jia and Harman 2011]. Todavia, alguns desses problemas podem ser modelados matematicamente a fim de serem resolvidos por meio da otimização matemática utilizando-se meta-heurísticas. É nesse contexto que surgiu o conceito de Search-Based Software Testing (SBST) que consiste no uso de técnicas de busca utilizando meta-heurística (algoritmo genético, por exemplo) para automatizar total ou parcialmente a atividade de teste [McMinn 2011]. Técnicas de busca meta-heurística são arcabouços de alto nível que utilizam heurísticas para encontrar soluções à problemas que envolvem combinação de resultados a um custo computacional aceitável [McMinn 2011]. Essas técnicas não são algoritmos prontos, mas estratégias para a adaptação para problemas específicos. Pesquisas nessa área mostram que é promissora a aplicação de Search-Based no contexto de teste de software. As áreas de aplicação são cinco: geração de dados de teste, seleção de casos de teste, priorização de casos de teste, testes não funcionais e testes funcionais. A geração de dados de teste consiste em identificar um conjunto de dados de entrada válido para um programa, que satisfaça um determinado critério de teste com o objetivo de encontrar um dado de teste que faça o programa se comportar diferentemente do esperado, revelando, assim, um defeito. A seleção de casos de teste consiste em escolher quais casos de teste devem ser aplicados em um sistema [Maia 2009]. A priorização de casos de teste trata da ordenação dos casos de teste de modo que os mais significativos sejam executados primeiro [Maia et al. 2010]. Os testes não funcionais verificam características do sistema não relacionadas a funcionalidades [Briand et al. 2004]. Por sua vez, os testes funcionais verificam se a implementação de uma aplicação está de acordo com sua especificação [Cohen et al. 2003]. O principal problema associado ao teste de mutação está no número de mutantes gerados, sendo, na maioria das vezes, alto, fazendo com o que o custo computacional também seja alto [Jia and Harman 2011]. Esse problema é agravado quando se está tratando de programas concorrentes, uma vez que, por causa do não determinismo, o programa possui diferentes sequências de sincronização que devem ser exercitadas durante a atividade de teste. Isso faz com que a complexidade computacional da execução de todos os mutantes, a geração de dados de teste para matar todos os mutantes sejam altos [Jia and Harman 2011]. Outro problema está relacionado com a identificação dos mutantes equivalentes que é realizada pelo testador e leva certo tempo para ser concluída, pois se deve analisar o programa mutante, comparar com o programa original, para então decidir se o mutante é equivalente ou não. Então, quanto mais mutantes forem gerados, mais mutantes terão que ser analisados para identificar os equivalentes. 111

112 Devido ao alto custo da aplicação do teste de mutação, várias estratégias vêm sendo utilizadas para fazer com que o critério de mutação possa ser utilizado de maneira mais eficiente. As técnicas de redução do custo do teste de mutação podem ser divididas em três tipos: do fewer (redução de número de mutantes sem afetar desempenho), do faster (procurar executar os mutantes o mais rápido possível) e do smarter (dividir o custo computacional ou evitar a execução completa ou guardar informações do estado da execução) [Offutt and Untch 2001]. Levando em consideração os resultados já obtidos em [Silva 2013], surgiu a motivação de investigar abordagens que proporcionem a diminuição dos custos de aplicação do teste de mutação (do fewer) para programas concorrentes. O objetivo do projeto de doutorado é investigar e propor uma abordagem para a otimização do teste de mutação utilizando técnicas de Search-Based Software Testing. Os desafios científicos identificados neste projeto de doutorado estão relacionados ao uso de SBST aplicado ao teste de mutação. Além disso, tem-se a aplicação de técnicas de SBST no contexto de programas concorrentes, o que é considerado inovador, pois essa técnica é pouco aplicada para resolver os problemas envolvendo teste nesse contexto. 3. Resultados e Contribuições Com o objetivo de se ter uma visão ampla do contexto a ser estudado, uma revisão sistemática foi conduzida com o objetivo encontrar trabalhos que aplicam técnicas de meta-heurística como forma de automatizar o teste de mutação. Como a finalidade de alcançar esse objetivo, foram formadas as seguintes questões de pesquisa: Q1) Em quais etapas do teste de mutação SBST está sendo aplicada? Q2) Quais as técnicas de meta-heurística estão sendo utilizadas no teste de mutação? A condução da revisão foi realizada levando em consideração cinco máquinas de busca: IEEE Xplore, ACM Digital Library, Science Direct, Springerlink e ISI Web of Knowledge. A pesquisa retornou 195 trabalhos dos quais foram selecionados 55 artigos para a leitura completa. Isso demonstrou a falta de trabalhos nessa área. Vale ressaltar que nenhum dos artigos encontrados aplica SBST para teste de mutação em programas concorrentes, o que faz desta proposta de doutorado inovadora. A string de busca e os critérios de exclusão com o número de trabalhos excluídos são mostrados na Figura 1. Figura 1. String de busca e critérios de exclusão. Respondendo Q1, SBST está sendo aplicado para otimizar: a seleção de operador de mutação (1 trabalho), a geração de dado de teste (39 trabalhos), 112

113 a geração de mutante (12 trabalhos) e a geração de dado de teste e mutante simultaneamente (3 trabalhos). Respondendo a segunda questão de pesquisa, dentre os 15 trabalhos que apresentam abordagens para a redução do número dos mutantes utilizando SBST, as seguintes meta-heurísticas são utilizadas: Genetic Algorithm (15 trabalhos), NSGA-II (4 trabalhos), Greedy Algorithm (2 trabalhos), Hill Climbing (2 trabalhos), Immune Algorithm (1 trabalho) e Local Search (1 trabalho) Trabalhos Relacionados [May et al. 2003] apresenta uma abordagem inspirada no sistema imunológico do corpo humano chamada Immune Algorithm. A função de aptidão é calculada para o mutante observando o quão diferente foi a saída dada por ele em relação à saída do programa original. Para o dado de teste, a função de aptidão é calculada pelo número de mutantes que foram mortos. Nos trabalhos de [Adamopoulos et al. 2004, Assis Lobo de Oliveira et al. 2013] é apresenta uma metodologia que utiliza o conceito de co-evolução para gerar mutantes e dados de teste utilizando Genetic Algorithm. Em [Adamopoulos et al. 2004] a função de aptidão é calculada a partir do escore de mutação e em [Assis Lobo de Oliveira et al. 2013] é a divisão entre o número de mutantes mortos e o total de mutantes. Em [Jia and Harman 2008] Genetic Algorithm e Hill Climbing são utilizadas para geração de mutantes. A função de aptidão é calculada pela união do conjunto de casos de teste que mata o mutante, dividido pelo conjunto de casos de teste, chamada de fragilidade do mutante. Nos trabalhos de [Domínguez-Jiménez et al. 2009b, Domínguez-Jiménez et al. 2009a, Domínguez-Jiménez et al. 2010, Domínguez-Jiménez et al. 2011] é apresentada uma técnica utilizando Genetic Algorithm para a geração de mutantes. A função de aptidão é calculada levando em consideração se o mutante é morto ou não pelo caso de teste e quantos mutantes foram mortos pelo mesmo caso de teste. Em [Blanco-Munoz et al. 2011] Genetic Algorithm é utilizado para a geração de mutantes e a função de aptidão é calculada pela fragilidade do mutante. Em [Schwarz et al. 2011] é definida uma abordagem que utiliza Genetic Algorithm para encontrar um conjunto de mutantes que tenham um alto impacto e que estejam espalhados por todo o código. A função de aptidão é calculada pelo impacto que o mutante tem com relação aos outros mutantes. No trabalho de [Omar et al. 2013] são aplicadas as meta-heurísticas Genetic Algorithm e Local Search para encontrar mutantes de ordem superior (HOM) mais difíceis de serem mortos. Em [Harman et al. 2010] são aplicados Genetic Algorithm, Hill Climbing e Greedy Algorithm para geração de HOMs. Para ambos os trabalhos, a função de aptidão é calculada pela diferença entre as falhas encontradas no HOM e as falhas encontradas nos mutantes que compõe o HOM. Em [Langdon et al. 2009a, Langdon et al. 2009b, Langdon et al. 2010] é apresentada uma abordagem que utiliza NSGA-II para a geração de mutantes. NSGA-II não calcula função de aptidão Abordagem Proposta O objetivo deste trabalho é diminuir o custo relacionado à aplicação do teste de mutação no contexto de programas concorrentes. Para isso, está sendo investigado o uso de meta-heurísticas para a geração de mutantes. A partir desse objetivo, 113

114 duas perguntas puderam ser feitas: 1) Como o teste de mutação pode ser otimizado? e 2) Quais as possibilidades de utilização de SBST no contexto de teste de mutação e programação concorrente? Para responder essas perguntas, primeiramente foi conduzida uma revisão sistemática com o objetivo de identificar trabalhos que utilizam SBST para otimizar o teste de mutação sem focar em programas concorrentes. Com isso, pôde-se ter uma ideia das pesquisas na área de teste de mutação. Com os trabalhos publicados nessa área, pode-se observar que há a motivação de diminuir o custo do teste de mutação por meio de três abordagens diferentes: 1) seleção de operador de mutação, 2) geração de dado de teste, 3) geração de mutante. Observou-se que grande parte dos trabalhos utilizavam a meta-heurística Genetic Algorithm, que utiliza uma função de aptidão para atribui valores aos mutantes dependendo de quão bons eles são com relação ao resultado de otimização que se quer alcançar. Levando em consideração as funções de aptidão, não foi encontrada nenhuma que utilizasse a frequência de mutação para avaliar um mutante. Então, essa foi a motivação para desenvolver um experimento para avaliar se a frequência de execução de mutantes pode ser uma boa alternativa para ser utilizada, posteriormente como função de aptidão em um Genetic Algorithm. A frequência de execução calcula a quantidade de dados de teste que fazem com que o ponto onde há a mutação no programa mutante seja executado. Um importante ponto a se observar é a quantidade de mutantes vivos com uma alta frequência de execução. Segundo [Bottaci 2001], para demonstrar a presença de uma falha em um mutante (matar o mutante) é necessário que a execução do caso de teste alcance o ponto de mutação (condição de alcançabilidade), o valor da expressão modificada deve mudar o estado do programa mutante quando comparado com o programa original (condição de necessidade) e essa diferença no estado precisa ser propagada até a saída (condição de suficiência). Com isso, um mutante que possui uma grande frequência de execução pode ser um possível mutante equivalente (não satisfazendo a condição de necessidade) ou não há um caso de teste que o faça gerar uma saída diferente da apresentada pelo programa original (não satisfazendo a condição de alcançabilidade). O experimento tem como objetivo analisar os mutantes mais executados com o propósito de verificar quantos são equivalentes ao programa original. A hipótese nula diz que todos os mutantes com uma maior frequência de execução e que permanecem vivos são equivalentes. A hipótese alternativa diz que há um conjunto de mutantes que possuem uma frequência alta, porém não são equivalentes ao programa original. Esse experimento está em desenvolvimento e consiste em aplicar o teste de mutação utilizando a ferramenta Proteum em programas escritos na linguagem C e identificar os mutantes equivalentes. O objetivo é verificar se os mutantes equivalentes são os mutantes com maior frequência de execução e quantos mutantes mortos tem uma alta frequência de execução. Com isso, espera-se refutar a hipótese nula e poder afirmar que há um conjunto de mutantes que possuem uma frequência alta, porém não são equivalentes ao programa original, podendo usar essa medida como função de aptidão no Genetic Algorithm. Os resultados desse estudo irão propiciar o estabelecimento de uma proposta de redução de custo do teste de mutação, empregando técnicas de meta-heurística que posteriormente será aplicada no contexto de programação concorrente. 114

115 Referências [Adamopoulos et al. 2004] Adamopoulos, K., Harman, M., and Hierons, R. M. (2004). How to overcome the equivalent mutant problem and achieve tailored selective mutation using co-evolution. In IN GECCO (2), VOLUME 3103 OF LECTURE NOTES IN COMPUTER SCIENCE, pages Springer. [Assis Lobo de Oliveira et al. 2013] Assis Lobo de Oliveira, A., Gonyalves Camilo-Junior, C., and Vincenzi, A. (2013). A coevolutionary algorithm to automatic test case selection and mutant in mutation testing. In Evolutionary Computation (CEC), 2013 IEEE Congress on, pages [Blanco-Munoz et al. 2011] Blanco-Munoz, E., Garcia-Dominguez, A., Dominguez-Jimenez, J., and Medina-Bulo, I. (2011). Towards higher-order mutant generation for ws-bpel. In e-business (ICE-B), 2011 Proceedings of the International Conference on, pages 1 6. [Bottaci 2001] Bottaci, L. (2001). A genetic algorithm fitness function for mutation testing. In SEMINAL 2001 First International Workshop on Software Engineering using Metaheuristic INnovative ALgorithms, Toronto, Ontario, Canada. [Bradbury et al. 2006] Bradbury, J. S., Cordy, J. R., and Dingel, J. (2006). Mutation operators for concurrent Java (J2SE 5.0). In Proceedings of the Second Workshop on Mutation Analysis, pages 11 20, Washington, DC, USA. [Briand et al. 2004] Briand, L. C., Labiche, Y., and Shousha, M. (2004). Performance stress testing of real-time systems using genetic algorithms. Technical report, Carleton University. [Cohen et al. 2003] Cohen, M. B., Gibbons, P. B., Mugridge, W. B., and Colbourn, C. J. (2003). Constructing test suites for interaction testing. In Proceedings of the 25th International Conference on Software Engineering, pages [Domínguez-Jiménez et al. 2011] Domínguez-Jiménez, J., Estero-Botaro, A., García-Domínguez, A., and Medina-Bulo, I. (2011). Evolutionary mutation testing. Information and Software Technology, 53(10): [Domínguez-Jiménez et al. 2009a] Domínguez-Jiménez, J. J., Estero-Botaro, A., García-Domínguez, A., and Medina-Bulo, I. (2009a). Gamera: An automatic mutant generation system for ws-bpel compositions. Web Services, European Conference on, pages [Domínguez-Jiménez et al. 2010] Domínguez-Jiménez, J. J., Estero-Botaro, A., García-Domínguez, A., and Medina-Bulo, I. (2010). Gamera: A tool for ws-bpel composition testing using mutation analysis. volume 6189 of Lecture Notes in Computer Science, pages [Domínguez-Jiménez et al. 2009b] Domínguez-Jiménez, J. J., Estero-Botaro, A., and Medina-Bulo, I. (2009b). A framework for mutant genetic generation for ws-bpel. volume 5404 of Lecture Notes in Computer Science, pages [Harman et al. 2010] Harman, M., Jia, Y., and Langdon, W. (2010). A manifesto for higher order mutation testing. In Software Testing, Verification, and Validation Workshops (ICSTW), 2010 Third International Conference on, pages [Jia and Harman 2008] Jia, Y. and Harman, M. (2008). Constructing subtle faults using higher order mutation testing. In Source Code Analysis and Manipulation, 2008 Eighth IEEE International Working Conference on, pages [Jia and Harman 2011] Jia, Y. and Harman, M. (2011). An analysis and survey of the development of mutation testing. Software Engineering, IEEE Transactions on, 37(5):

116 [Langdon et al. 2009a] Langdon, W., Harman, M., and Jia, Y. (2009a). Multi objective higher order mutation testing with genetic programming. In Testing: Academic and Industrial Conference - Practice and Research Techniques, pages [Langdon et al. 2009b] Langdon, W. B., Harman, M., and Jia, Y. (2009b). Multi objective higher order mutation testing with gp. In Proceedings of the 11th Annual conference on Genetic and evolutionary computation, pages [Langdon et al. 2010] Langdon, W. B., Harman, M., and Jia, Y. (2010). Efficient multi-objective higher order mutation testing with genetic programming. J. Syst. Softw., 83(12): [Maia et al. 2010] Maia, C. L. B., do Carmo, R. A. F., de Freitas, F. G., de Campos, G. A. L., and de Souza, J. T. (2010). Automated test case prioritization with reactive GRASP. Adv. Soft. Eng., pages 2:1 2:13. [Maia 2009] Maia, Camila Loiola Brito, d. C. R. A. F. d. F. F. G. d. C. G. A. L. d. S. J. T. (2009). A multi-objective approach for the regression test case selection problem. In Proceedings of Anais do XLI Simpósio Brasileiro de Pesquisa Operacional, pages [May et al. 2003] May, P., Mander, K., and Timmis, J. (2003). Software vaccination: An artificial immune system approach to mutation testing. In Timmis, J., Bentley, P., and Hart, E., editors, Artificial Immune Systems, volume 2787 of Lecture Notes in Computer Science, pages Springer Berlin Heidelberg. [McMinn 2011] McMinn, P. (2011). Search-based software testing: Past, present and future. In International Workshop on Search-Based Software Testing (SBST 2011), pages [Myers et al. 2011] Myers, G. J., Sandler, C., and Badgett, T. (2011). The Art of Software Testing. Wiley Publishing, 3rd edition. [Offutt and Untch 2001] Offutt, A. J. and Untch, R. H. (2001). Mutation testing for the new century. chapter Mutation 2000: Uniting the Orthogonal, pages Kluwer Academic Publishers, Norwell, MA, USA. [Offutt et al. 1996] Offutt, A. J., Voas, J., and Payne, J. (1996). Mutation operators for Ada. Technical report. [Omar et al. 2013] Omar, E., Ghosh, S., and Whitley, D. (2013). Constructing subtle higher order mutants for java and aspectj programs. In Software Reliability Engineering (ISSRE), 2013 IEEE 24th International Symposium on, pages [Schwarz et al. 2011] Schwarz, B., Schuler, D., and Zeller, A. (2011). Breeding high-impact mutations. In Software Testing, Verification and Validation Workshops (ICSTW), 2011 IEEE Fourth International Conference on, pages [Silva 2013] Silva, R. A. (2013). Teste de mutação aplicado a programas concorrentes em mpi. Mestrado, ICMC, Instituto de Computação e Matemática Computacional, USP. [Silva-Barradas 1998] Silva-Barradas, S. (1998). Mutation analysis of concurrent software. PhD dissertation, Dottorato di Ricerca in Ingegneria Informatica e Automatica, Politecnico di Milano. 116

117 Constructing a Theory of Agile Governance: a step towards Business Agility Alexandre J. H. de O. Luna 1,2, Philippe Kruchten 2*, Hermano Moura 1+ 1 Informatics Center (CIn). Federal University of Pernambuco (UFPE). Av. Jornalista Anibal Fernandes, s/n, Cidade Universitária, , Recife, PE, Brazil. 2 Department of Electrical and Computer Engineering (ECE). The University of British Columbia (UBC) Main Mall. Vancouver, BC, V6T 1Z4, Canada. + Supervisor, * Co-supervisor. ajhol@cin.ufpe.br, pbk@ece.ubc.ca, hermano@cin.ufpe.br Abstract. Context: Competitiveness is the key to a sustainable development and it demands agility at the business and organizational levels, which in turn requires a flexible and customizable Information Technology (IT) environment, as well as effective and responsive governance in order to deliver value faster, better, and cheaper to the business. Objective: This paper describes the ongoing research design we conduct to analyze and understand better this context, and whose expected result will be a theory of agile governance to help researchers and practitioners apply agile capabilities on governance issues in order to achieve organizational performance and business competitiveness. Method: We conducted a systematic literature review on the state of the art of agile governance, together with a meta-ethnography study on professional social networks related to governance, and we are applying the phenomenology and grounded theory approaches to the collected data. Results: We have identified 16 emerging categories, organized into four major thematic groups, based on the patterns identified in the collected data. As a result, we could offer a convergent definition for agile governance, six meta-principles, and a map of findings organized by topic and classified by relevance and convergence, detailed in other paper under publishing process. Conclusion: We found evidence that indicates agile governance as a relatively new, wide and multidisciplinary area focused on organizational performance and competitiveness that needs to be more intensively studied and might have its boundaries better defined. We are currently making improvements and additions to the methodological approach for exploratory qualitative studies. Keywords Information Systems, Agile Governance, IT management, Organizational behavior, Software Engineering. Graduate Program: PhD in Computer Science from Federal University of Pernambuco (UFPE). Year of Admission: Estimated completion time: Date of approval of the proposed thesis / dissertation (qualification): scheduled for 29/08/2014. CBSoft event: SBES 117 1

118 1. Introduction Governments and corporations are increasingly realizing the emerging importance of Information and Communication Technologies (ICT) as catalyst factor of the driving aspects of change, renewal and implementation cycle of their business. These organizations are deepening the perception about how the Information Technologies (IT 1 ) capabilities are becoming key factors of success in the evolving of their market competitiveness and the achievement of their institutional mission [Gallagher and Worrell 2007; Tallon 2008]. In recent years, IT has seen an increase in investment and research focus in both the academic and the professional environments. These initiatives have entailed efforts to improve management models and to implement practices that make enterprises more competitive. Competitiveness is related with the idea to make more, better and faster, with less resources [Janssen and Estevez 2013]. At the same time, governance is closely related with the ability to steer (to guide, to govern) an organization, which may be a company, a government or a society [Bloom 1991]. In other words, governance is a key driver to make things happen on organizational environment. On the other hand, to achieve good governance demands capabilities such as flexibility, responsiveness and adaptability, as well as an effective and responsive sense of coordination across multiple business units. Actually, these capabilities belong to the agility paradigm in consonance with several authors, such as [Matt 2007], [Chen et al. 2008], [Li 2010]. Moreover, Kruchten [2011] define agility as: the ability of an organization to react to changes in its environment faster than the rate of these changes. In fact, this definition uses the ultimate purpose or function of being agile for a business, unifying and standardizing agile and lean approaches as simply "agile", rather than defining agility by a labeled set of practices or by a set of properties defined in opposition to the agile manifesto approach [Beck et al. 2001]. Going beyond, a good governance requests particularly organizational agility, which is stated by Thomsett [2013] as: the ability of an organization to respond quickly and effectively to unanticipated events in its environment. As a result, agility became an important business aspect, and according to Luftman et al. [1993], business agility is: "the ability to change the direction of the environment and respond efficiently and effectively to that change". In consonance with this definition, we distilled a new definition to business agility for use in this study as: the ability to deliver value 2 faster, better, and cheaper to the business. In line with these concepts, agile governance becomes the application of agile capabilities 3 on governance issues 4 in order to improve business agility, what we believe that can result in significant economic outcomes for companies and governments. In the subsequent sections this paper gives an overview of the related theoretical background, the methodology adopted to elaborate and evaluate the theory, as well as preliminary and expected results. 2. Background and Related Work In this scenario, IT governance, through which corporate governance 5 is applied, has emerged as an option to the effective management and control of IT services in organizations, ensuring the payback of investments and the improvement and innovation of business processes [IT Governance Institute 2001]. Through the influence of factors related to market regulation, such as the Sarbanes-Oxley Act [Congress of the United States of America 2002] and the Basel Accords [Bank for International Settlements 2010], the use of governance is also motivated by other objectives, such as: i) reducing the costs of business unavailability; ii) assurance of continuity of business processes; iii) guarantee of IT investments payback; and, iv) increasing organizational competitiveness [Weill and Ross 2004]. Ribeiro and Barata [2011] pointed out that to face competition, enterprises have adopted more efficient organizational dynamics that enable them to respond to socio-economic pressures while tackling profitable but volatile business opportunities. This led to the emergence of several types of networked interactions: supply chains, extended enterprises, virtual enterprises, collaborative networks, among others. Overall, agility is fundamental as the establishment of such networked organizations is not trivial. Partners will share profits, risks and responsibilities and ultimately the performance and success of the entire structure will always be dragged down by the less agile participant [Brown et al. 2013; Royce and Cantor 2013]. In practice, the design and maintenance of the IT systems for enterprise agility can be a challenge when the competitiveness of organization s products and services is depending of the application of models and frameworks 1 IT and ICT in this study will be used as synonyms, and understood as the means by which are covered the infrastructure, services and software as well as the organizational capabilities established to support the business. 2 An informal term that includes all forms of value that determine the health and well-being of the firm in the long run. [BD 2013] 3 The power or ability to do something. [OED 2013] 4 An important topic or problem for debate or discussion. [OED 2013] 5 is the set of processes, policies, rules, laws and institutions that affecting the way as a corporation is directed, administered or controlled [Cadbury 1992] 118 2

119 that have no guidance details of how to implement and deploy the necessary management instruments and governance mechanism [Luna et al. 2013]. Consequently, the challenges become even greater when dealing with these matters on a global software development and distributed environment, where cultural differences, awareness and communication style, if not treated properly can lead to conflicts. Arguably, in Global Development Environments governance issues are even more relevant and necessary, as well as its implementation even greater challenging [Dubinsky et al. 2011]. Several authors [Luna et al. 2010; Qumer and Henderson-Sellers 2008; Roosmalen and Hoppenbrouwers 2008; Sun et al. 2005] have pointed out the lack of methods, techniques and tools to help people and enterprises to achieve the business goals, means by the governance issues, in an agile way independent from the business area. At same time, many authors [Banihashemi and Liu 2012; Bartenschlager and Goeken 2010; Heston and Phifer 2011; Radnor and Johnston 2013] claim that the governance practices, models, guides and frameworks are most of them bureaucratic, time consuming and having no guidance details of how to implement and deploy the necessary management instruments and governance mechanism, such as ITIL [Mendel 2004], COBIT [Gerke and Ridley 2009], among others. These processes, models, guides and practices will be denominated conventional or traditional governance, by this study, according the shortcomings identified in their context. Over the last few years, Agile methodologies [Dybå and Dingsøyr 2008] have been gaining traction in industry and adding competitiveness and dynamism to the process of software development, through initiatives where the principles of communication and collaboration are essential Dubinsky and Kruchten [2009]. Moreover, Dubinsky and Kruchten [2009] and Dubinsky et al. [2010] highlight that Software Development Governance (SDG) has emerged in the last few years to deal with establishing the structures, policies, controls, and measurements for communication and for decision rights, to ensure the success of software development organizations. Recently, agile governance has been proposed [Cheng et al. 2009; Luna et al. 2010, 2013; Qumer 2007] which provides the wide application of principles and values of Agile Software Development [Beck et al. 2001] to the conventional governance processes. Luna [2009] has developed a framework for agile governance, in order to implement and improve governance in organizations, called MAnGve. This framework is focused to the deployment process, as a catalyzer to accelerate the deployment of governance. The MAnGve framework is designed to mitigate the lack of practical focus found in conventional governance models [MAnGve 2009]. The MAnGve is a framework based on an agile life cycle, seeking to translate the principles, values and practices from Agile Software Development to IT governance paradigm. However, altogether the agile governance phenomena still remained unexplored in depth. 3. Methodological Framework Considering the positive experience of several organizations working in the field of Software Engineering and the significant contribution that Agile Methodologies have brought to their software development processes [Ambler and Lines 2013; Kruchten 2011]. Likewise, taking in mind that no systematic review of agile governance has previously been found, we conducted a systematic literature review about the state of the art of agile governance (SLR-AG) in order to understand better the agile governance phenomena. Additionally, we have also intended to investigate how the domain of agile governance has evolved in the world through analysis of some key constructs, such as: genesis, shortcomings, evolution, trends, concepts, principles, etc.; as well to derive implications for research and for practice. When we started our doctoral research under this same context and motivation, we intended to propose a model for Agile Governance paradigm. However, after two years refining the knowledge available about this topic and conducting the aforementioned systematic review (SLR-AG), we realize two major viewpoints: (1) the paradox of the emerging phenomenon 6 : If any system that can be object from a model is contained into a phenomenon, which the researcher do not know, neither understand (yet), how can he or she characterize the boundary conditions to define the system that will be the reference to propose the model? ; (2) domain development level: based on the findings from the SLR-AG and in line with Edmondson and McManus [2007], we point out: (i) we think precipitated and inconsistent propose a model for agile governance in this stage of development, because the research design of this study has to adapt itself to the current state of theory and research, which is evidently nascent; (ii) as a result, the development level demands for exploratory qualitative studies, originally open-ended data that have to be interpreted for meaning; and, (iii) likewise, we are handling with a nascent field of study where all set of knowledge should be organized, connected and systematized in some kind of conceptual framework or theory, then to serve as a basis for future work, such as: models, applications, etc Research Problem From the described scenario in the previously section, we can identify the following research problem: 6 When we met this paradox in our work, we faced it not only as a specific paradox emerging from our research, but we deduced it as a broad paradox of Information Systems, addressing to the relationship between models, systems and phenomena in study. As we did not find any reference about similar paradox related to those aspects, we named it as a new one

120 Based on the presented context and on the fact that agile governance is a nascent, wide and multidisciplinary domain, focused on organizational performance and competitiveness: these phenomena need to be more intensively studied, analyzed, described and might have its boundaries better defined, as well as it should be organized, connected and systematized in some kind of conceptual framework or theory. This problem is compounded by the fact that, we did not find evidence in the literature about the existence of a theoretical approach that can help people and enterprises to analyze and describe agile governance [Luna et al. 2014] Justification Grounded on these understandings, our judgment leads us to consider the exploration and comprehension of these phenomena as a higher priority of this domain, justified by the development stage of this field of study and by the philosophical paradox faced. As a result the proposition of a theory for agile governance seems as a more auspicious product for this study, meeting the claims from the findings of the SLR-AG and providing a theoretical approach that can help researchers and practitioners to apply agile capabilities on governance issues in order to achieve organizational performance and business competitiveness. We believe that improving the competitiveness of governments and companies through the improvement of their IT governance and IT management shall result in significant economic outcomes. An initial premise for this research is that different types of theory exist in Information Systems and that all can be valuable. However, the existence of a theory that addresses Agile Governance issues was not found before or during the development of this study. Considering the wide and multidisciplinary nature of this domain pointed out by the SLR-AG, we believe that a meta-theory 7 should be a legitimate classification for this theory, according to the level of generalization intended [Gregor 2006] Research Objective The major objective of this study is to address these challenges by providing a theoretical approach that can help researchers and practitioners to apply agile capabilities on governance issues in order to achieve organizational performance and business competitiveness. Specifically, a meta-theory for analysis and description [Gregor 2006], which can be used to describe what agile governance is, as well as help to interpret and understand how agile capabilities can be applied upon governance issues in order to achieve business agility, guided by the following major research question: How a theoretical approach can be applied to analyze and describe what is agile governance in order to help people to combine agile capabilities with governance issues to achieve business agility? 3.4. Research Method In consonance with the current state of theory and research in the agile governance domain, the design of our research demands for an exploratory and qualitative study that have to be interpreted for meaning [Edmondson and McManus 2007]. This is also coherent with the finality of propose a theoretical approach that can help researches and practitioners to apply agile capabilities on governance issues to achieve business agility. Grounded theory has arisen as one of the best-known method to produce theories [Glaser 2002]. Gregor [2006] highlights that some examples of grounded theory can also be examples of Type I theory (Theory for Analyzing), where the grounded theory method gives rise to a description of categories of interest. In addition, Suddaby [2006] points out that where researchers have an interesting phenomenon without explanation and from which they seek to discover theory from data is the context when grounded theory is most appropriate. The exact situation experienced by this study. Indeed, this approach has been widely employed for the development of recent theories in IS, such as: [Adolph et al. 2012], [Dorairaj et al. 2011]. Table 1 Classification of Methodological Approach. SOURCE: own elaboration. Methodological Approach Description and References About the objective Exploratory [Marconi and Lakatos 2003] Exploratory Literature Review [Schuetzenmeister 2010]; Systematic Literature Review [Dybå and Dingsøyr 2008; Kitchenham et al. 2007]; Bibliometrics and Scientometrics [Weingart 2005]; Phenomenology [Creswell 2012]; Grounded Theory [Corbin and About the technical procedure Strauss 1990; Eisenhardt 1989; Pandit 1996]; Meta-ethnographic and qualitative Metaanalysis [Noblit and Hare 1988]; Expert s Survey [Groves et al. 2013]; Scenario Analysis [Antón et al. 1994]; Angen s theory assessment approach [Angen 2000]; and, Theory comparison [Eisenhardt 1989; Glaser and Holton 2007]. About the nature of variables Qualitative [Creswell 2002, 2012] About method approach Inductive [Jebreen 2012] About methods of procedure Comparative and Structuralist [Gauch Jr 2003; Gower 2002] 7 Meta-theory is at a very high level of abstraction and provides a way of thinking about other theories, possibly across disciplines [Gregor 2006]

121 At this point of our rationale, it is important to contextualize that we have been working on this domain at least for six years: we produced a master degree dissertation and publish a book about agile governance. In complement, over the last two years we conducted the systematic review, described at the beginning of the section 3, to investigate the state of the art of this domain. As a consequence of these experiences a set of knowledge intuitions, discoveries and insights about this topic were accumulated, condensed and crystalized by means of an inductive approach [Jebreen 2012], supported by procedures comparative and structuralist [Gauch Jr 2003]. This approach is quite congruent with the approach proposed by grounded theory [Corbin and Strauss 1990]. At the same time, these experiences will be fairly relevant in the process that will follow from now on. If on one hand, these previous experiences condensed on the personality, experience, and character of the researcher can be seen as an important component of the research process and should be made an explicit part of the analysis [Strauss and Corbin 1998]; on the other hand, this approach must be adopted carefully on these preexistent concepts to do not violate the notion of theoretical emergence, avoiding that preconceived notions of what is likely to be observed in the phenomena in study, which may reflect on what will "be seen" about the intended categories and overlooked more emergent ones [Suddaby 2006]. Considering the factors and concerns we have just exposed, we decided to apply phenomenology and grounded theory approaches compounded with other methods, techniques and procedures to complement and reduce the likelihood of bias of this study, as depicted in the Table 1. The following subsection will detail the study design pointing out where will be employed each method, procedure and technique Study Design and Evaluation To simplify the understanding of the methodological approach the study design was structured in five stages as depicted in Figure 1. Figure 1 Study Design. SOURCE: Adapted from [Adolph et al. 2012; Dorairaj et al. 2011; Monasor et al. 2013]. At the stage 1 we develop a Systematic Literature Review [Dybå and Dingsøyr 2008; Kitchenham et al. 2007] to investigate the state of the art of agile governance domain, establish the relevance of this work and frame this study, identifying the adequate approach for the following stages of this research. At this stage Bibliometrics and Scientometrics [Weingart 2005] were important to establish the relevance of the selected studies in the literature for the review process and also to help in the synthesis procedures. As a result, we generated a set of findings that crystalize a representative sampling from the phenomenon under study, which we called Body of Knowledge (BOK). From this BOK emerged during the synthesis process, using meta-ethnographic and qualitative metaanalysis methods [Noblit and Hare 1988], a new convergent meta-concept for agile governance, a mapping of findings organized in four major thematic groups and 16 categories, as well as six meta-principles and some directions for research and practice. These directions for research and practice not only confirmed the alleged 121 5