WTDSoft 2014 - Instituto de Computação

Transcrição

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
WTDSoft
Volume 02
ISSN 2178-6097
Anais
WTDSoft 2014
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
WTDSoft
PROCEEDINGS
Volume 02
ISSN 2178-6097
WTDSoft 2014
PROGRAM CHAIR
CBSOFT 2014 GENERAL CHAIRS
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
WTDSoft
Autorizo a reprodução parcial ou total desta obra, para fins acadêmicos, desde que citada a fonte
4
WTDSoft
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 2014.
Eduardo Santana de Almeida
Coordenador do WTDSoft
5
WTDSoft
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
WTDSoft
Comitê organizador / Organizing Committee
COORDENAÇÃO GERAL
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
7
WTDSoft
Í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
10
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
16
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
22
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
27
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
33
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
39
Execução Paralela de Programas como suporte ao teste de mutação
Stevão Alves de Andrade, Márcio Eduardo Delamaro
45
Um estudo sobre geração de testes com BETA:
Avaliação e aperfeiçoamento
João Batista de Souza Neto, Anamaria Martins Moreira
50
O Impacto dos Fatores Humanos em Metodologias Ágeis
Aline Chagas Rodrigues Marques, Alexandre Marcos Lins de Vasconcelos,
Célio Andrade de Santana Júnior
56
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
62
8
WTDSoft
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
68
Análise da Qualidade de Experimentos da Computação em Nuvem
Helaine Solange Lins, Vinicius Cardoso Garcia, Sérgio Castelo Branco Soares
74
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
79
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
86
Alocação de Participantes no Merge de Ramos
Catarina de Souza Costa, Leonardo Gresta Paulino Murta
93
A Meta-Process Oriented to Software Product Quality Based on
ISO/IEC 25010 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
101
Search-Based Mutation Testing para Programas Concorrentes
Rodolfo Adamshuk Silva, Simone do Rocio Senger de Souza
109
Constructing a Theory of Agile Governance: a step towards
Business Agility
Alexandre J. H. de O. Luna, Philippe Kruchten, Hermano Moura
117
9
WTDSoft
Uma Abordagem para Checagem de Conformidade
Arquitetural na Modernização Apoiada por Modelos
Aluno: Fernando Chagas1
Orientador: Valter Vieira de Camargo1
1
Programa de Pós-Graduação em Ciência da Computação
Departamento de Computação – Universidade Federal de São Carlos (UFSCar)
Caixa Postal 676 – 13565-905 – São Carlos – SP – Brazil
[email protected], [email protected]
Resumo. Em geral, a arquitetura de sistemas legados apresenta inconsistências
em relação à arquitetura de referência. Uma alternativa para isso é conduzir
uma modernização apoiada por modelos (Architecture-Driven Modernization ADM), que é um processo proposto pela OMG com o objetivo de reestruturar
sistemas existentes com base em metamodelos padrão ISO. O principal metamodelo da ADM é o KDM, que objetiva representar um sistema legado em vários
nı́veis de abstração, inclusive o arquitetural. Entretanto, apesar da ADM fornecer todos os conceitos para a condução de modernizações, não foram encontradas propostas para Checagem de Conformidade Arquitetural (CCA). Embora
existam várias propostas que atuam em nı́vel de código-fonte, o mesmo não
ocorre em nı́vel de modelos, como o KDM. Portanto, deverá 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 também investigar cenários em que esse tipo de
checagem apresenta benefı́cios.
Nı́vel: Mestrado
Ano de Ingresso: 2013
Época prevista de conclusão: 04/2015
Data de aprovação da proposta de dissertação: 25/04/2014
Evento Relacionado: SBES
Palavras-chave: arquitetura de software, checagem de conformidade arquitetural,
adm, kdm
10
WTDSoft
1. Caracterização do Problema
Modificações tardias na fase de implementação e conflitos nos requisitos de qualidade resultam na incompatibilidade entre arquitetura planejada e implementada. Como alternativa para verificação dessas inconsistências, surgiu a Checagem de Corformidade Arquitetural (CCA), que é uma técnica que preenche a ponte entre os modelos de alto nı́vel do
projeto arquitetural e código-fonte [Knodel and Popescu 2007]. A Modernização Apoiada por Modelos (ADM) [OMG 2003], defende a realização do processo de modernização
considerando os princı́pios do desenvolvimento dirigido a modelos. A ADM define
vários metamodelos para auxiliarem nas modernizações, dentre eles o Knowledge Discovery Metamodel (KDM), que torna possı́vel a recuperação dos artefatos de software por meio de técnicas de engenharia reversa, em diferentes nı́veis de abstração
[Perez-Castillo et al. 2011]. Um pacote importante do KDM no contexto deste trabalho é
o de Estrutura (Structure), que permite representar elementos arquiteturais de um sistema.
Vários grupos de pesquisa tem atuado na linha de checagem de conformidade, propondo diferentes té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 realização da CCA no
contexto da ADM. Outro fator importante, é verificar a qualidade do KDM em representar
conceitos arquiteturais, já que não foi encontrado nenhum trabalho voltado para a camada
de abstrações do KDM, que é responsá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 verificação de desvios arquiteturais.
É importante ressaltar que o KDM é padrão ISO e pouco estudado até o momento
desta pesquisa, fator importante para a motivação deste trabalho, pois não foram encontradas abordagens que realizem modernizações por meio de padrões, o que impacta na
dificuldade de reuso, portabilidade e interoperabilidade de aplicações. Deste modo, o objetivo desta pesquisa é 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 necessário, indicar modificações no KDM no sentido de permitir
uma checagem de conformidade mais adequada.
2. Fundamentação Teórica
Knodel e Popescu (2007) descrevem a CCA como uma atividade chave para o controle
de qualidade de software. O objetivo é revelar diferenças entre a arquitetura planejada e a
atual do sistema. Uma atividade importante dentro da CCA é averiguar as restrições entre
elementos arquiteturais, para isso, Terra e Valente (2009) propuseram uma linguagem de
domı́nio especı́fico. Na abordagem, é possı́vel restringir dependências originadas a partir
do acesso a atributos e métodos, declaração de variáveis, criação de objetos, extensão
de classes, implementação de interfaces, ativação de exceções e uso de anotações. Uma
maneira de conduzir processos de reengenharia é por meio da Modernização Apoiada por
Modelos (ADM), que facilita a formalização de transformações por meio de princı́pios de
desenvolvimento dirigido a modelos. Um dos metamodelos especificados pela ADM, O
KDM, é fragmentado em quatro camadas correspondentes aos artefatos fı́sicos e lógicos
e é capaz de representar todo o sistema [Perez-Castillo et al. 2011].
Neste trabalho serão investigados interesses relacionados a CCA em KDM, por11
WTDSoft
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 é apresentado o diagrama de classes do pacote Structure.
Figura 1. Pacote StructureModel da Camada de Abstração no KDM
A classe StructureModel representa uma agregação de elementos arquiteturais,
como subsistemas, componentes, camadas, sistemas e visões arquiteturais. Note-se
també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, métodos, etc. Os relacionamentos são representados por uma classe concreta filha
de AbstractStructureRelationship. Os relacionamentos representados pela classe StructureRelationship possuem dois atributos, que é o elemento arquitetural de origem e o de
destino, que caracterizam a relação.
3. Caracterização da Contribuição
Na Figura 2 são apresentados os passos esperados da abordagem proposta. No passo A, o
engenheiro de software precisa fornecer uma especificação da arquitetura planejada que
deve conter os elementos arquiteturais e as regras de restrição de acesso entre eles. Os
elementos arquiteturais serão descritos de acordo com os elementos presentes no pacote
Structure do KDM, isto é, camadas, componentes, etc. As regras regulam os relacionamentos permitidos ou não entre os elementos. Até o momento, pretende-se utilizar as
regras de acesso propostas por Terra e Valente [2009]. O formato dessas regras nã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 é a arquitetura
planejada representada na forma de uma instância do pacote Structure do KDM.
Figura 2. Passos da abordagem proposta
12
WTDSoft
No passo B deve ser obtido um panorama atual do sistema legado, aqui, deverá
ser utilizada uma ferramenta chamada MoDisco1 , que será responsável por extrair as
informações do sistema e representar por meio de uma instâ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
código-fonte presentes na instância do KDM legado. A criação desse artefato deverá possuir apoio ferramental para facilitar a visualização e a criação dos relacionamentos. Por
exemplo, pode ser que três pacotes (java packages) existentes no KDM legado representem a camada de modelo existente na arquitetura. Ao final desse passo, o KDM legado
deverá ser transformado no sentido de incluir uma instância do pacote Structure contendo
uma visão arquitetural ainda sem os relacionamentos entre seus elementos.
No passo D, o objetivo é gerar um KDM em que o pacote Structure represente
a arquitetura atual, contendo todos os relacionamentos existentes entre seus elementos.
Para isso, um algoritmo deverá analisar o KDM modificado para identificar todos os relacionamentos existentes entre elementos de mais baixo nı́vel (classes, interfaces, mé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 métodos, acesso a variáveis, implementação
de interfaces, etc [Terra and Valente 2009]. Os passos C e D estão sendo planejados de
forma separada para permitir que o engenheiro de software possa modificar o mapeamento
fornecido caso ele tenha informado erroneamente alguma relação. Isso evita que a tarefa
de geração da arquitetura atual (passo D) seja feita repetidas vezes em caso de erros de
mapeamento, já que o passo D demanda uma quantidade significativa de processamento.
Por fim, no passo E será feita a checagem de conformidade, para isso, as
representações da arquitetura deverão ser comparadas. Como saı́da, espera-se que sejam apontados indı́cios de desvios arquiteturais, que são as diferenças encontradas entre
as representações fornecidas. O resultado da checagem será fornecido por meio de um
arquivo de texto simples que aponta as oportunidades ou por anotações na instância do
KDM. Note-se que neste projeto optamos por gerar uma representação da arquitetura atual
por meio do passo D. Isso deverá facilitar a comparação com a arquitetura planejada, já
que as duas representações estarão no mesmo nı́vel de abstração. Outra alternativa poderia ser não gerar a arquitetura atual e realizar as comparações entre os elementos de baixo
nı́vel e a arquitetura planejada.
Assim sendo, o principal objetivo neste projeto é desenvolver uma abordagem de
CCA usando o metamodelo KDM fornecido pela ADM. Outra contribuição será desenvolver uma técnica de conversão do pacote code/kdm para o pacote structure/kdm, pois
atualmente nenhuma ferramenta dá suporte para a representação de informações estruturais do sistema. Também será investigado a adequabilidade do metamodelo KDM para
realização de CCA. Por fim, serão caracterizados cenários em que a checagem de conformidade apoiada por modelos é mais viável do que em código-fonte.
4. Estado Atual do Trabalho
Até o momento foi feito um estudo do metamodelo KDM e de técnicas de ACC. Foram
verificadas maneiras de representar as regras de acesso entre elementos arquiteturais, e
1
http://www.eclipse.org/MoDisco/
13
WTDSoft
dentre os trabalhos estudados, as regras definidas por Terra e Valente (2009) foram escolhidas como base e deverão ser consideradas neste trabalho.
Foram criadas três instâ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
investigação sobre como os desvios arquiteturais são representados no KDM. Na Figura
3 é 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 visão do sistema e é representa
informações manipuladas na classe CarController, da camada de controle, que por sua
vez utiliza a classe Car (camada modelo) para realizar operações de controle. Qualquer
outro tipo de relação entre estas camadas não é permitido, porém, são feitos acessos da
classe SellCar a classe Car, correspondendo a um indicio de desvio arquitetural. Para que
esse indicio seja encontrado, consideramos a recuperação da arquitetura atual, na qual
todas as relações são apresentadas no pacote Structure do KDM (Figura 3b). A arquitetura planejada é definida pelo engenheiro de software e representada no mesmo nı́vel de
abstração que a atual (Figura 3c). Dessa maneira, as duas representações são comparadas
e verificadas as diferenças, que são possı́veis indı́cios de desvios arquiteturais.
Foi realizada uma investigaçã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 estereótipos (Stereotype), essa metaclasse pode ser uma
possı́vel alternativa para a especificação das regras de acesso a elementos arquiteturais.
Os estereótipos deverão representar cada tipo de relação existente de acordo com os tipos
de restrições entre elementos arquiteturais definidos por Terra e Valente (2009).
5. Trabalhos relacionados
Maffort entre outros (2013) apresentam heurı́sticas para descoberta de violações arquiteturais. A entrada da ferramenta proposta possui uma especificação dos componentes
em alto nı́vel e o histórico de revisões do sistema. Ela identifica dependências suspeitas
em código-fonte, baseando-se em hipóteses de frequência e correções feitas no passado
nessas dependências. Deiters entre outros (2009) propõem uma abordagem para ACC
baseada em regras. A descrição arquitetural é representada em fatos e regras lógicas. Os
fatos representam os elementos existentes arquiteturais, as regras definem as restrições. A
CCA é realizada executando as regras arquiteturais como queries sobre a união das bases
de conhecimento. Rahimi e Khosravi (2010) apresentam uma abordagem capaz de realizar CCA entre múltiplas linguagens de programação. A abordagem é dividida em duas
14
WTDSoft
etapas, primeiro são criados transformadores de código-fonte em modelos de alto nı́vel e
em seguida as linguagens são comparadas em um mesmo nı́vel de abstração. Maffort entre outros (2013) destaca a realização da CCA por meio da análise estática e histórica de
código-fonte, enquanto que a abordagem aqui proposta objetiva realizar análise estática
em modelos. Deiters entre outros (2010) se aproxima da proposta deste trabalho por
demonstrar o uso de regras de relação de conformidade para realização da CCA, neste
projeto, foi escolhida utilizar regras que sejam aplicadas no contexto da ADM. Rahimi e
Khosravi (2010) não trabalham com padrões para a realização da CCA enquanto que uma
das motivações da nossa abordagem é utilizar o KDM, que é padrão ISO.
6. Avaliação dos Resultados
Para a avaliação do trabalho proposto, serã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 necessário, indicar
modificações no KDM no sentido de permitir uma checagem de conformidade mais adequada. Também será avaliada se a atividade de checagem no KDM é capaz de ser considerada ótima, essa análise será feita por meio da contagem de falsos positivos e negativos,
em que a ausência deles contempla uma boa atividade de verificação.
Referê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), 2010 17th Working Conference on, pages 163–172.
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, 2009. EDOC ’09. IEEE International, pages 183–192.
Knodel, J. and Popescu, D. (2007). A comparison of static architecture compliance checking approaches. In Software Architecture, 2007. WICSA ’07. The Working IEEE/IFIP
Conference on, pages 12–12.
Maffort, C., Valente, M., Bigonha, M., Anquetil, N., and Hora, A. (2013). Heuristics
for discovering architectural violations. In Reverse Engineering (WCRE), 2013 20th
Working Conference on, pages 222–231.
OMG (2003). Model Driven Architecture (MDA) Guide. OMG doc. ab/2003-06-01.
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):519–532.
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):1073–1094.
15
WTDSoft
Uma Abordagem Baseada em Padrões para Interoperação de
Especificações de Workflows Científicos
Bruno Fernandes Bastos¹,²
[email protected]
Orientadores
Regina Maria Maciel Braga¹
[email protected]
Antônio Tadeu Azevedo Gomes²
[email protected]
1
2
Universidade Federal de Juiz de Fora (UFJF)
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
Workflows Científicos
Científicos,
Interoperação,
Eventos relacionados: SBES, SBCARS
16
Padrões
em
WTDSoft
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
WTDSoft
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.
Inicialmente foi feita uma primeira análise dos padrões propostos na iniciativa
Workflow Patterns1 e de workflows presentes no repositório myExperiment.2 A partir
1
http://www.workflowpatterns.com/
18
WTDSoft
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
2
http://www.myexperiment.org
19
WTDSoft
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
3
http://www.taverna.org.uk/documentation/taverna-galaxy/
20
WTDSoft
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. 1997. 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. 2000 ] 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. 37-45.
[Medeiros e Gomes 2013] Medeiros, V. e Gomes, A. T. A. (2013). Expressando atributos nãofuncionais em workflows científicos. CoRR, abs/1304.5099.
[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-toBusiness Service Outsourcing (IDSO „00) pág. 5–6.
[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. 2006. 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
WTDSoft
Adaptação de critérios de teste de programas concorrentes
para o teste de integração de robôs móveis
Marcos Pereira dos Santos1 , Simone R. S. Souza1
1
Instituto de Ciências Matemáticas e de Computação (ICMC) –
Universidade de São Paulo (ICMC/USP)
Caixa Postal 668 – 13.560-970 – 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
WTDSoft
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.
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 - http://ros.org/wiki/
23
WTDSoft
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.
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
WTDSoft
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.
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 - http://www.inct-sec.org/br/aplicacoes/carina
25
WTDSoft
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 387–392.
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 195 – 204.
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 369–376, 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 337–346, 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 386–391.
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):1893–1916.
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):1153 – 1164.
Taylor, R. N., Levine, D. L., and Kelly, C. D. (1992). Structural testing of concurrent
programs. IEEE Trans. Softw. Eng., 18(3):206–215.
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:279–330.
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, 2005.
ICECCS 2005. Proceedings. 10th IEEE International Conference on, pages 539–548.
26
WTDSoft
Avaliação de Arquiteturas Recuperadas com base em Métodos
de Avaliação Precoce
Mateus Passos Soares Cardoso1 , Christina von Flach G. Chavez1 , Crescencio Lima1
1
Programa Multiinstitucional de Pós-Graduação em Ciência da Computação - PMCC
Universidade Federal da Bahia - UFBA
{mateuspsc,flach,crescencio}@dcc.ufba.br
Resumo. Em geral, a documentação de arquitetura de sistemas de software não
existe ou está desatualizada. Ferramentas de recuperação de arquitetura automatizam parte do processo de obtenção da arquitetura a partir do código-fonte
do sistema de software e apoiam a criação ou atualização da documentação.
Entretanto, há pontos em aberto relacionados à avaliação das arquiteturas extraı́das por tais ferramentas. Por exemplo, como avaliar a qualidade de uma
ou mais arquiteturas extraı́das se não houver arquitetura conceitual documentada ou se os arquitetos que originalmente projetaram o sistema não estiverem
disponı́veis? Esta proposta apresenta uma abordagem para avaliar a qualidade
de arquiteturas de software extraı́das por ferramentas de recuperação com base
em métodos de avaliação precoce de arquitetura. Ferramentas de recuperação
serão usadas para obter modelos de arquitetura de software e os métodos de
avaliação – por exemplo, Software Architecture Analysis Method (SAAM) e Architecture Tradeoff Analysis Method (ATAM) – serão usados para avaliar a qualidade das arquiteturas extraı́das e riscos associados. Espera-se que a abordagem proposta contribua para a melhorar a compreensão e a documentação de
arquitetura em sistemas de software existentes.
Palavras - Chave. Arquitetura de Software, Recuperação de Arquitetura,
Avaliação de Arquitetura, SAAM, ATAM, SAR.
Ano de Ingresso no Programa:2013
Época prevista para conclusão: Maio de 2015
Data de Aprovação da proposta de tese/dissertação(qualificação):Abril de 2014
Eventos Relacionados:SBCARS, SBES
27
WTDSoft
1. Caracterização do Problema
Ferramentas de recuperação de arquitetura fornecem mecanismos para arquitetos e desenvolvedores recuperarem a arquitetura de um software a partir de representações do
código, de modo a remediar problemas comuns que ocorrem durante o desenvolvimento
do sistema, por exemplo, erosão, documentação incompleta, inconsistência entre arquitetura documentada e a arquitetura implementada, entre outros [Pollet et al. 2007].
Normalmente, a avaliação da qualidade da arquitetura extraı́da é feita por
comparação com a arquitetura conceitual documentada ou por meio de análise apoiada por arquitetos ou desenvolvedores do software implementado [Chardigny et al. 2008,
Mancoridis et al. , Terceiro et al. 2010, Pinzger 2005]. Nesse contexto, métodos de
avaliação tardia de arquitetura podem ser utilizados. Entretanto, para alguns sistemas de
software, a arquitetura conceitual não está disponı́vel nem os arquitetos ou desenvolvedores que participaram de sua construção. Como então avaliar a qualidade da arquitetura
extraı́da a partir de um sistema de software?
Uma possı́vel solução para esse problema é utilizar métodos de avaliação
precoce de arquitetura [Kazman et al. 2000, Clements et al. 2001]. Os métodos de
avaliaçã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] – têm como objetivo definir se uma arquitetura é apropriada ou
não para um sistema de software antes desta ser escolhida como a arquitetura definitiva
[Roy and Graham 2008] e certamente antes da implementação do sistema. O método
SAAM [Clements et al. 2001] busca avaliar se determinado conjunto de arquiteturas é
apropriado para um determinado sistema. O método ATAM [Kazman et al. 2000] serve
como uma extensão e avalia os possı́veis riscos que uma arquitetura candidata pode trazer para o sistema. Entretanto, estes dois métodos de avaliação não são simples de usar
e deve-se investigar com cuidado a viabilidade de seu uso no contexto da avaliação de
arquiteturas extraı́das a partir do sistema implementado.
Este trabalho tem como objetivo explorar a viabilidade do uso de métodos de
avaliação precoce de arquitetura para avaliar a qualidade de arquiteturas extraı́das com o
apoio de ferramentas de recuperação. Os objetos de estudo serão sistemas de software
de código aberto, cuja arquitetura documentada seja inexistente. Pretende-se utilizar os
métodos de avaliação de arquitetura precoce SAAM e ATAM como base para a definição
de uma técnica de avaliação de arquiteturas recuperadas com apoio de ferramentas de
recuperação e seus riscos associados.
Nesta seção, são apresentados conceitos relacionados a recuperação de arquitetura de software, com ênfase em ferramentas de recuperação (Seção 2.1) e a avaliação de arquitetura
de software, com ênfase em métodos (Seção 2.2).
2.1. Recuperação de Arquitetura de Software
Recuperação de arquitetura de software (Software Architecture Recovery – SAR) é o
processo de determinar a arquitetura de um sistema de software a partir de seu códigofonte ou outros artefatos de implementação. A recuperação de arquitetura permite a
28
WTDSoft
identificação e a extração de representação de alto nı́vel de sistemas de software existentes [Eixelsberger et al. 1996].
Há várias abordagens para recuperação de arquitetura do software (SAR). A ideia
geral é trabalhar com a arquitetura de software recuperada a partir do sistema implementado, que reflita com acurácia as decisõ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 (documentação, reuso, migração, etc.),
(ii) Processos (bottom-up, top-down ou hı́brido), (iii) Dados de Entrada (código-fonte,
documentos, etc.), (iv) Técnicas (quase-manual, semiautomática, quase-automática) e (v)
Dados de Saı́da (representação visual da arquitetura, texto, etc.). Neste trabalho, usamos
algumas destas dimensões para guiar a escolha de ferramentas para análise.
2.2. Avaliação de Arquitetura de Software
A avaliação da arquitetura de um sistema de software é 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.
Há diversas abordagens para avaliação de arquitetura de software
[Barcelos and Travassos 2006]. De modo geral, a avaliação de arquitetura pode ser
feita em dois momentos: antes da arquitetura do sistema estar pronta (avaliação precoce)
ou após a arquitetura do sistema e o próprio sistema estarem prontos (avaliação tardia)
[Clements et al. 2001]. Neste trabalho, serão utilizados dois métodos de avaliação precoce: SAAM [Clements et al. 2001] e ATAM [Kazman et al. 2000]. Os dois são métodos
baseados em cenários, uma categoria considerada bastante madura [Babar et al. 2004].
O SAAM (Scenario-Based Software Architecture Analysis Method)
[Roy and Graham 2008] é um método de avaliação precoce da arquitetura de sistemas de software. Sua análise verifica suposições a respeito da arquitetura (por exemplo,
se uma arquitetura é adequada ao sistema em questão) em confronto com os documentos
que descrevem a arquitetura. A análise busca encontrar problemas na arquitetura do
software, por exemplo, conflitos ou design incompleto da arquitetura. Além disso, o
SAAM ajuda a comparar arquiteturas candidatas de um sistema.
Como informação necessária para análise da arquitetura, o SAAM utiliza a arquitetura candidata e os requisitos do sistema [Roy and Graham 2008]. Como resultado, o
SAAM produz cenários sensı́veis a qualidade do sistema, o mapeamento entre os cenários
e os componentes arquiteturais e o esforço necessário para realizar estes cenários na arquitetura. O processo de análise é composto de seis etapas: Especificação dos requisitos do
sistema, descrição da arquitetura, extração de cenários, priorização de cenários, avaliação
da arquitetura em relação aos cenários, interpretação e apresentação dos resultados.
O ATAM (Architecture based Tradeoff Analysis Method) [Kazman et al. 2000] é
uma extensão do SAAM que cobre pontos na avaliação arquitetural que não eram cobertos
anteriormente, como os tradeoffs da arquitetura, ou seja, decisões arquiteturais que podem
afetar atributos de qualidade do sistema (por exemplo: adquirir mais servidores para a
aplicação aumentaria o desempenho e a disponibilidade, o que poderia deixar o sistema
mais suscetı́vel a ataques) [Roy and Graham 2008].
29
WTDSoft
O ATAM é composto por nove atividades estruturadas e mais complexas do que
as do SAAM: apresentação do ATAM, apresentação das regras de negócio, apresentação
da arquitetura, identificação de abordagens arquiteturais, geração de árvore de utilidade,
análise das abordagens arquiteturais, priorização de cenários, segunda análise da abordagens arquiteturais, apresentação dos resultados. Algumas atividades podem ocorrer em
paralelo.
3. Objetivos e Contribuições
Este trabalho de mestrado tem como objetivo principal apresentar uma abordagem baseada em métodos de avaliação precoce de arquitetura para apoiar a avaliação da qualidade
de uma ou mais arquiteturas de software extraı́das automaticamente com ferramentas de
recuperação a partir de um sistema implementado.
As práticas de métodos de avaliação precoce usadas em situações em que os sistemas já estão implementados podem ajudar em tarefas de redocumentação.
São objetivos especı́ficos deste trabalho:
• Definir critérios para seleção, análise e comparação de ferramentas de recuperação
de arquitetura, de forma a subsidiar a escolha das mais adequadas para uso.
• Analisar a viabilidade do uso de métodos de avaliação baseados em cenários
(SAAM) e cenários / atributos (ATAM) para situações em que os sistemas de software estão implementados, buscando também identificar atividades ou práticas
que possam ser aplicáveis.
• Propor uma abordagem de avaliação de arquiteturas recuperadas, com práticas
adaptadas de métodos de avaliação precoce baseados em cenários e/ou atributos,
para ser usada em sistemas de software implementados.
• Avaliar empiricamente a abordagem proposta.
São contribuições esperadas deste trabalho:
• Um conjunto de critérios de avaliação de ferramentas de recuperação de arquitetura;
• Uma abordagem de avaliação precoce de arquitetura que poderá ser usada em
casos onde apenas métodos tardios são adotados, e
• Uso de métodos de avaliação de arquitetura ainda pouco difundidos em ambientes
de desenvolvimento de software de código aberto.
4. Cronograma e Estado Atual do Trabalho
A Tabela 1 apresenta o cronograma de atividades previstas para o ano de 2014. Algumas das atividades representadas neste cronograma estão associadas aos objetivos apresentados na seção 3. Atualmente, o trabalho se encontra na fase de análise das ferramentas de recuperação e parte do resultado desta análise pode ser encontrado em:
http://goo.gl/PzVoc3.
Durante a fase de revisão de literatura, alguns trabalhos onde os autores buscaram avaliar as técnicas de recuperação de arquitetura e sua eficácia foram encontrados, a saber,
[Wu et al. 2005], [Maqbool and Babri 2007] e[Garcia et al. 2013].
30
WTDSoft
Tabela 1. Cronograma 2014
Atividade
Revisão da Literatura
Análise das Ferramentas de Recuperação
Análise dos Métodos de Avaliação
Definição da Abordagem de Avaliação
Avaliação da Abordagem Desenvolvida
Apresentação dos Resultados
JAN/FEV
MAR/ABR
MAI/JUN
JUL/AGO
SET/OUT
NOV/DEZ
Em seu trabalho, Wu [Wu et al. 2005] selecionou e aplicou seis algoritmos de
clusterização em 6 sistemas distintos. Os algoritmos de clusterização foram avaliados
em três aspectos: estabilidade, competência e distribuição dos clusters. Para realização
da avaliaçã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 recuperação que usam algoritmos de clusterização – 8 ferramentas no
estudo de [Maqbool and Babri 2007] e 6 ferramentas no estudo de [Garcia et al. 2013].
Para a avaliação das arquiteturas recuperadas, experts foram escolhidos para produzir arquiteturas para os sistemas que seriam analisados pelas ferramentas. Ao final do processo
de recuperação, a arquitetura obtida pelas ferramentas foi comparada com a arquitetura
produzida pelos experts.
A viabilidade do uso de SAAM e ATAM para avaliação de arquiteturas será analisada
por meio de um experimento-piloto. As arquiteturas recuperadas pelas ferramentas de
recuperação servirão como entrada e serão apresentadas aos subjects do experimento.
Uma ou mais visões arquiteturais poderão ser fornecidas. Os subjects serão divididos em
dois grupos: um grupo irá avaliar as arquiteturas de acordo com as práticas do SAAM
enquanto que o outro grupo irá avaliar de acordo as práticas do ATAM. Como resultado
dos métodos, serão definidos cenários sensı́veis a qualidade que servirão como base para
avaliação das arquiteturas recuperadas. Após o experimento, os participantes serão entrevistados sobre questões relacionadas a abordagem de avaliação utilizada.
A depender dos resultados obtidos, outros estudos experimentais poderão ser definidos para avaliação da abordagem proposta.
Referê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 285–288.
Clements, P., Kazman, R., and Klein, M. (2001). Evaluating Software Architectures:
Methods and Case Studies. Addison-Wesley Professional, 1 edition.
31
WTDSoft
Eixelsberger, W., Warholm, L., and Klö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. 2013 28th IEEE/ACM International Conference on
Automated Software Engineering (ASE), pages 486–496.
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 45–52.
Maqbool, O. and Babri, H. A. (2007). Hierarchical clustering for software architecture
recovery. Software Engineering, IEEE Transactions on, 33(11):759–780.
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 137–148.
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 525–535.
32
WTDSoft
Um estudo comparativo sobre sínteses de estudos de
métodos mistos na Engenharia de Software
Aluno: Danilo Monteiro Ribeiro1,
Orientador: Fábio Queda Bueno da Silva1
Co-orientador: Cesar França2
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, [email protected]
Nível: Mestrado
Ano de Ingresso: Março de 2013 - 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
WTDSoft
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
WTDSoft
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].
2.2. 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
WTDSoft
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: http://goo.gl/uLwg7y
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
WTDSoft
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/2009-0.
Danilo Monteiro Ribeiro recebe uma bolsa de pesquisa do CNPq, processo
#132554/2013-5.
Referências
Budgen, D., Turner, M., Brereton, P., Kitchenham, B. (2007) “Using Mapping Studies
in Software Engineering”, 2007.
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. 440-455
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. 2010. 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
WTDSoft
Res. Policy 10 (1) p.45-53.
Dyba, T.; Dingsøyr, T. (2008) “Empirical studies of agile software development : A
systematic review. Information and Software Technology”. Volume 50, Issue 910,p.833-859
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. 154
– 163.
Kitchenham, B. (2007) “Guidelines for Performing Systematic Literature Reviews in
Software Engineering.” Technical Report, Department of Computer Science,
University of Durham, 2007.
Kitchenham, B. Brereton P., and Budgen D (2012) “Mapping study completeness and
reliability – a case study” Evaluation and Assessment in Software Engineering
EASE, p.126-135
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. 638-651
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.792– 805.
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. 899–913.
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. 153 – 162.
38
WTDSoft
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 68511 – CEP 21945-970 – 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
WTDSoft
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.
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).
2.1. 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
WTDSoft
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.
2.2. 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
WTDSoft

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
WTDSoft
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.
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.
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
WTDSoft
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. 713-732.
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. 223-226.
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. 117-131.
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. 3151-3160.
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. 25–34, 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. 1-12.
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. 524-533.
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. 8-10.
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. 24-25.
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
WTDSoft
Execução paralela de programas como suporte ao teste de
mutação
Stevão Alves de Andrade1 , Orientador: Márcio Eduardo Delamaro1
1
{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
WTDSoft
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].
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
WTDSoft
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.
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.
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
WTDSoft
é 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.
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):135–152.
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 78–86.
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):649–678.
48
WTDSoft
Korel, B. (1990). Automated software test data generation. IEEE Trans. Softw. Eng.,
16(8):870–879.
Marshall, A., Hedley, D., Riddell, I., and Hennell, M. (1990). Static dataflow-aided weak
mutation analysis (sdawm). Information and Software Technology, 32(1):99 – 104.
Special Issue on Software Quality Assurance.
Mateo, P. R. and Usaola, M. P. (2013). Parallel mutation testing. Software Testing, Verification and Reliability, 23(4):315–350.
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 320–334, 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):99–118.
Quinn, M. (2004). Parallel Programming in C with MPI and OpenMP. McGraw-Hill
Higher Education. McGraw-Hill Higher Education.
49
WTDSoft
Um estudo sobre geração de testes com BETA:
Avaliação e aperfeiçoamento∗
João Batista de Souza Neto, Anamaria Martins Moreira (Orientadora)
1
Programa de Pós-Graduação em Sistemas e Computação (PPgSC)
Departamento de Informática e Matemática Aplicada (DIMAp)
Universidade Federal do Rio Grande do Norte (UFRN)
[email protected], [email protected]
Nı́vel: Mestrado
Ano de ingresso: 2013
Previsão de qualificação: agosto/2014
Previsão de conclusão: fevereiro/2015
Resumo. Das várias formas de se buscar qualidade de software, Teste de Software e Métodos Formais são duas que merecem destaque. Vários esforços vem
sendo feitos pela comunidade para unir essas duas metodologias, que podem se
complementar e trazer mais qualidade para o software. Um desses esforços foi
a criação da abordagem e ferramenta BETA (B Based Testing Approach), que
gera casos de teste a partir de especificações formais na notação do Mé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 limitações, assim como propor e
implementar melhorias, contribuindo para o seu aperfeiçoamento.
Eventos do CBSoft relacionados: SBES, SBMF
∗
Este trabalho recebe apoio financeiro da CAPES e CNPq (Instituto Nacional de Ciência e Tecnologia
para Engenharia de Software–INES, processo 573964/2008-4)
50
WTDSoft
1. Introdução e Caracterizaçã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 preocupação em se desenvolver software de
qualidade cresça a cada dia. Teste de Software e Métodos Formais são duas das disciplinas
que visam a qualidade no desenvolvimento de um software.
Métodos formais fazem uso de um formalismo matemático para descrever
informações de uma forma completa, consistente e não-ambı́gua. Por conta disso, fornecem informações mais precisas sobre os requisitos do software, que podem ser de grande
auxı́lio na criação de testes. Neste sentido, existem vá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 especificação
formal na notação do Método B [Abrial 2005]. Outra iniciativa também pode ser vista
em [Aydal et al. 2009], que apresenta uma abordagem de criação de testes a partir de
especificações escritas em Alloy [Jackson 2012]. Estas são apenas duas das várias iniciativas que unem métodos formais e teste de software, mostrando que esta é uma área de
estudo bastante ativa.
Em [Matos and Moreira 2012, Matos and Moreira 2013] é apresentada a abordagem e ferramenta BETA (B Based Testing Approach)1 . Nesta abordagem, casos de teste
de unidade são gerados a partir de especificações formais escritas na notação do Método
B. Fazendo uso de particionamento do espaço de entrada [Ammann and Offutt 2008], a
abordagem gera casos de teste positivos, que respeitam as restrições da especificação, e
negativos, que desrespeitam as restrições da especificação, exercitando ações não esperadas pelo software.
As experiências realizadas em [Matos and Moreira 2012, Matos and Moreira
2013] foram importantes para uma validação inicial da abordagem e da ferramenta, entretanto, se limitaram apenas ao projeto de casos de teste, não tendo sido realizadas a
implementação e execução dos mesmos. Além disso, a ferramenta continua em desenvolvimento, o que faz com que novas avaliações sejam necessárias. Neste contexto, a
proposta do presente trabalho é aplicar a abordagem e ferramenta BETA em novos estudos de caso, de modo a avaliar o comportamento de BETA em situações mais complexas,
assim como realizar todo processo de projeto, implementação e execução de testes. Com
isso, este trabalho pretende explorar BETA, identificando suas limitações e qualidades,
além de propor e implementar melhorias.
O restante deste trabalho está organizado da seguinte forma: na Seção 2 são apresentados alguns conceitos relacionados a Método B e Teste de Software; na Seção 3 é
apresentada a abordagem e ferramenta BETA; na Seção 4 são apresentados os objetivos
e contribuições deste trabalho; a Seção 5 descreve o estado atual do trabalho; na Seção 6
são apresentados os resultados que serão esperados com esta pesquisa.
Nesta seção serão apresentados os principais conceitos que embasam esta pesquisa. Será
apresentado uma breve introdução ao Método B e, em seguida, serão apresentados alguns
conceito relacionados a teste de software.
1
Informações e detalhes técnicos sobre a abordagem e ferramenta BETA podem ser encontrados no site
http://www.beta-tool.info/, onde a ferramenta pode ser baixada.
51
WTDSoft
2.1. Método B
O Método B é uma metodologia formal para especificação, projeto e codificação de sistemas [Abrial 2005]. Utilizando conceitos da teoria dos conjuntos, lógica de primeira
ordem, aritmética de inteiros e substituições generalizadas (transformadores de predicados), o processo do Método B se inicia com a criação de um módulo abstrato, chamado
máquina abstrata, que especifica o comportamento do sistema. A partir de um processo
contı́nuo, a máquina abstrata vai sendo refinada de modo a chegar a uma forma mais concreta. O último passo do método B é a implementação, que é o nı́vel mais concreto da
especificação, de modo que o código do sistema pode ser gerado automaticamente.
Os principais componentes de um módulo do Método B são as variáveis de estado,
o invariante, que especifica a validade e restrições para o estado, e as operações, que
modificam e consultam o estado. As operações são definidas em termos de substituições
generalizadas e possuem pré-condições, que devem ser satisfeitas para que as operações
possam ser executadas sem inconsistências. A coerência da máquina é garantida através
das obrigações de prova, que são expressões lógicas geradas a partir da especificação, que
devem ser provadas com o auxı́lio de um provador de teoremas.
2.2. Teste de Software
O Teste de Software é uma das abordagens que buscam aumentar a qualidade do software, pois tem o objetivo de identificar os seus defeitos. Neste trabalho são considerados
os testes funcionais, classicamente chamados de testes de caixa preta, projetados a partir
da especificação do sistema. Os testes também podem ser classificados de acordo com
a atividade do processo de desenvolvimento a que estão relacionados. Os testes de unidade, que estão relacionados à atividade de implementação e verificam cada unidade (um
método ou operação, por exemplo) do sistema de forma isolada, são considerados neste
trabalho.
Um conceito importante em teste de software é o de critério de cobertura, que
em [Ammann and Offutt 2008] é definido como uma regra ou conjunto de regras que
definem requisitos de teste para um conjunto de teste. Critérios de cobertura são importantes porque estabelecem limites na quantidade de testes a serem criados, mantendo
ainda uma boa qualidade. Existem vários tipos de critérios de cobertura, dentre os quais
se destacam a cobertura de grafos, cobertura lógica, particionamento do espaço de entrada e testes baseados em sintaxe. Outro conceito importante é o de oráculo de teste, que
é o mecanismo responsável por determinar o sucesso ou falha de um teste. Em [Li and
Offutt 2014] são apresentadas algumas estratégias de oráculo de teste, que consistem em
fazer verificações no estado interno do software, variáveis e invariante de estado, e nos
resultados das operações, entre outras verificações.
3. BETA
É uma abordagem e ferramenta para geração de casos de teste de unidade a partir de
especificações formais em B, apresentada em [Matos and Moreira 2012, Matos and Moreira 2013]. Utilizando como tipo de critério de cobertura o particionamento do espaço de
entrada [Ammann and Offutt 2008], BETA gera casos de teste positivos e negativos para
uma unidade (operação) de uma máquina abstrata B. A Figura 1 apresenta uma visão geral
52
WTDSoft
Figura 1. Visã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), é preciso caracterizar o espaço de entrada da operação sob teste,
que consiste em identificar as variáveis do domı́nio de entrada da operação e suas caracterı́sticas, que são obtidas a partir do invariante de estado da máquina e pré-condição da
operação. Em (2), o espaço é particionado em blocos disjuntos correspondentes a cada
caracterı́stica. Feito o particionamento, os blocos são combinados em (3) resultando em
um conjunto de fórmulas. Cada fórmula estabelece restrições para o domı́nio de entrada e
representa um caso de teste. Na etapa (4) são obtidos valores para as variáveis do espaço
de entrada que satisfazem as restrições impostas pelas fórmulas. Para a obtenção desses
valores, a abordagem sugere o uso de um solucionador de restrições2 . De posse desses
valores, é criada uma especificação contendo os dados de teste.
Outro elemento importante em um teste, além dos dados de entrada, é o oráculo
que determina seu sucesso ou falha, por isso, na etapa (5) são definidos os oráculos de
teste. A abordagem apresenta um método para a geração de oráculos para testes positivos.
A última etapa da abordagem (6), consiste na implementação dos testes concretos, que
leva em consideração a especificação e os oráculos gerados nas etapas anteriores. Atualmente, a ferramenta BETA automatiza os passos (1) ao (4) da abordagem, já os passos (5)
e (6) ainda são feitos de forma manual.
4. Objetivos e Contribuiçõ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 aperfeiçoamento.
O primeiro estudo de caso consiste em desenvolver testes para a API da linguagem de
programação Lua [Ierusalimschy 2012] a partir da especificação criada em [Moreira and
Ierusalimschy 2013]. Com esse estudo, este trabalho pretende validar a especificação verificando se os testes criados a partir dela são condizentes com a API real, ou seja, pretendese verificar se o comportamento real da API foi especificado corretamente. Além disso,
2
O solucionador de restrições utilizado pela ferramenta BETA é o ProB, uma ferramenta para verificação
de modelo e execução de especificações B – http://www.stups.uni-duesseldorf.de/ProB/
53
WTDSoft
a especificação da API possui um grande número de operações e utiliza muitos recursos
do Método B, o que permitirá aplicar BETA em situações mais complexas até então não
exploradas, que é o nosso principal objetivo.
O segundo estudo de caso consiste em utilizar BETA para contribuir com a
validação do compilador B2LLVM [Déharbe and Medeiros Jr. 2013], que gera código
LLVM [Lattner and Adve 2004] a partir de implementações B. O código gerado pelo
B2LLVM será testado com os casos de teste gerados por BETA a partir da especificação
B que originou o código. Ao verificar que o código LLVM gerado segue a especificação,
pode-se ter uma maior segurança que o B2LLVM está gerando o código corretamente.
Além dos estudos de caso, este trabalho pretende trazer contribuições para as
duas últimas etapas de BETA. A forma de obtenção dos oráculos de teste apresentada
na penúltima etapa da abordagem é fixa e foca apenas em testes positivos, não abordando
testes negativos. Por esse motivo, serão propostas estratégias de oráculo de teste para
diminuir essas deficiências da abordagem. Além disso, será desenvolvido um gerador de
guias de teste para a ferramenta com o intuito de automatizar parte da implementação dos
testes concretos, diminuindo o esforço gasto na última etapa da abordagem.
Para contribuir com a penúltima etapa da abordagem, este trabalho está propondo quatro
estratégias de oráculo de teste baseadas nas estratégias apresentadas em [Li and Offutt
2014]. As estratégias consistem em: 1) verificar a ocorrência de exceções; 2) verificar
o invariante de estado após a execução da operação; 3) verificar os valores das variáveis
de estado após a execução da operação; 4) verificar o retorno da operação. As estratégias
de oráculo podem ser combinadas para uma melhor verificação, provendo uma melhor
flexibilidade, inclusive em testes negativos.
Para diminuir o trabalho realizado na última etapa da abordagem, foi desenvolvido
um gerador de guias de teste. O gerador traduz os dados da especificação de casos de teste
gerada por BETA para um guia de teste em Java e C, utilizando as notações de teste JUnit3
e CuTest4 , respectivamente. O guia contém parte do código do teste concreto e precisa
ser adaptado pelo desenvolvedor para poder ser executado. O gerador também automatiza
parte da criação dos oráculos de teste com base nas estratégias propostas.
Os dois estudos de caso propostos neste trabalho já foram iniciados. No primeiro
estudo de caso, a especificação da API de Lua foi aplicada na ferramenta BETA. Inicialmente, a ferramenta não conseguiu gerar casos de teste para nenhuma operação da
especificação. Ao investigar o motivo, foi detectado que o solucionador de restrições utilizado pela ferramenta, o ProB, não estava conseguindo gerar valores para as variáveis
da especificação devido ao grande número de tipos de Lua considerados, que gerou uma
explosão combinatória. Dada esta limitação, este trabalho optou por diminuir o escopo
da especificação ao reduzir o número de operações e tipos de Lua que estavam sendo
considerados. Com a redução, BETA conseguiu gerar a especificação de casos de teste
para algumas operações da API. Os testes concretos serão implementados com o auxı́lio
do gerador de guias de teste.
3
4
JUnit é um framework de testes para Java – http://www.junit.org/
CuTest é um framework de testes para C – http://cutest.sourceforge.net/
54
WTDSoft
Para o segundo estudo de caso, foi escolhido um pequeno conjunto de máquinas
abstratas e suas implementações B. As implementações foram aplicadas no B2LLVM,
que gerou códigos LLVM correspondentes. As máquinas abstratas foram aplicadas na
ferramenta BETA, que gerou as especificações de casos de teste. Os testes concretos
foram implementados em C com o auxı́lio do gerador desenvolvido neste trabalho, sendo
necessário apenas algumas adaptações. Os primeiros resultados da execução dos testes
foram positivos.
6. Resultados Esperados
Os resultados deste trabalho serão importantes para contribuir com o aperfeiçoamento da
abordagem e ferramenta BETA. Em um primeiro momento, este trabalho conseguiu mostrar que a abordagem e ferramenta são aplicáveis em situações reais, além da identificação
de algumas limitações, relacionadas ao solucionador de restrições utilizado pela ferramenta, algo que será alvo de um futuro estudo (fora do escopo deste trabalho). Além
disso, este trabalho trouxe contribuições para BETA com a proposta de estratégias de
oráculo de teste e o gerador de guias de teste, que já estão sendo utilizados nos estudos de
caso em andamento.
Referê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 131–140.
Dé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 75–88.
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 51–66. 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
Prá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 95–113. Springer.
55
WTDSoft
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
WTDSoft
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.
Nesta seção, descreve-se os conceitos fundamentais sobre fatores humanos em
engenharia de software e em desenvolvimento ágil de software.
2.1. 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
WTDSoft
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.
2.2. 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.
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
WTDSoft
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:
Tabela 1. Cronograma de atividades
Atividades/Período
2013
1º
2014
2º
1º
2º
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
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
WTDSoft
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.
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
Tsun Chow e Dac-Buu Cao
Fatores de sucesso
projetos ágeis
Cordialidade,
talento,
habilidade e comunicação
Alistair Cockburn
Highsmith
Fatores que promovem
bem-estar de um time ágil
Responsabilidade,
capacitação,
liderança,
comunicação e confiança
Vikash Lalsing, Somveer
Kishnah e Sameerchand
Pudaruth
Fatores
pessoais
em
desenvolvimento
ágil
de
software e em gerência de
projeto
Interpessoal, individual
organizacional
e
Laleh Pirzadeh
Categorias
de
fatores
relacionados aos ciclos de
desenvolvimento de software
Bom
relacionamento
confiança
e
Dyba e Dingsøyr
Fatores para o sucesso de
um time XP
Compartilhando
conhecimento, colaboração
do cliente e motivação
Amy Law e Raylene Charron
Efeito das práticas ágeis
sobre esses fatores sociais
Competência, características
pessoais,
comunicação,
cultura,
treinamento
e
aprendizagem
Subhas Chandra Misra, Vinod
Kumar, Uma Kumar
Fatores de sucesso ao adotar
práticas de desenvolvimento
ágil de software
Capacidade do time
envolvimento do cliente
e
60
e
Jim
em
o
WTDSoft
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. 131-133.
DYBÅ, T.; DINGSøYR, T. (2008) “Empirical Studies of Agile Software Development:
A Systematic Review”. Information and Software Technology, ButterworthHeinemann Newton, MA, USA, v. 50, n. 9, p. 833-859.
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. 576–587.
MANIFESTO ÁGIL. Disponível em: http://agilemanifesto.org/principles.html. Acesso
em 26 de abril de 2014.
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
WTDSoft
Um Método de Extração de Valores Referência para Métricas
de Softwares Orientados por Objetos
Tarcı́sio G. S. Filó1 , Mariza A. S. Bigonha1 , Kecia Aline Marques Ferreira2
1
Programa de Pós-Graduação em Ciências da Computação (PPGCC)
Departamento de Ciência da Computação - Universidade Federal de Minas
Gerais (UFMG) - Belo Horizonte - MG - Brasil
2
Departamento de Computação - Centro Federal de Educação Tecnológica de Minas
Gerais (CEFET-MG) - Belo Horizonte - MG - Brasil
{tfilo,mariza}@dcc.ufmg.br, [email protected]
Nı́vel: Mestrado
Ano de ingresso no programa: 2012
Época prevista de conclusão: março de 2014
Data da aprovação da proposta de dissertação: março de 2013
Eventos Relacionados: SBES
Resumo. Valores referência para métricas de softwares orientados por objetos
são úteis em diversos campos da Engenharia de Software, tais como processos de filtragem em estratégias de detecção de bad smells e identificação de
medições anômalas em um processo de medição de produto, parte integrante
de um programa de qualidade de software. Nesse trabalho apresentamos um
método de extração de valores referência para métricas de softwares orientados
por objetos, bem como mostramos a sua aplicação na identificação de valores
referência para 18 métricas em um dataset de 111 softwares open-source. Os
próximos passos do trabalho consistem em avaliar empiricamente a eficácia dos
valores referência na avaliação da qualidade do software.
Palavras-chave: métricas, valores referência, qualide de software, mediçã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
WTDSoft
1. Introdução
Pesquisas relacionadas com valores referência para métricas de software orientado por
objetos vem sendo realizadas a partir de diferentes metodologias e apresentam valores
referência de formatos e significados distintos. Além disso, valores referência para diversas métricas propostas na literatura ainda não são conhecidos. Uma consequência direta
desse problema é a inexistência de condições adequadas para avaliar quantitativamente
e de forma eficaz a qualidade dos softwares. Valores referência permitem responder
questões simples como “Quais métodos do sistema possuem uma quantidade excessiva
de parâmetros?” ou “Quais classes do sistema possuem muitos métodos?”.
Nesse contexto, o trabalho de pesquisa proposto tem por objetivo contribuir para a
solução desse problema, catalogando e avaliando valores referência para um conjunto de
18 métricas de softwares orientados por objetos, a partir de um método sólido e embasado
em dados estatı́sticos para derivação desses valores. Com valores referência catalogados,
vislumbra-se que as métricas possam ser efetivamente aplicadas na indústria de software,
e, consequentemente, a qualidade dos softwares possa ser avaliada de forma automática.
2. Solução Proposta
Nesta seção é descrita a metodologia a ser aplicada na derivação de valores referência
para as métricas de softwares orientados por objetos coletadas no Qualitas.class Corpus
[Terra et al. 2013], que é uma versão compilada do Qualitas Corpus proposto por Tempero et al. (2010), no qual são disponibilizados arquivos XML referentes aos 111 sistemas
contendo medições de 18 métricas de softwares:
• Básicas: número de classes por pacote, número de métodos, número de atributos, número de métodos sobrescritos, número de parâmetros, número de métodos
estáticos e número de atributos estáticos.
• Complexidade: linhas de código por método, ı́ndice de especialização, complexidade de McCabe, profundidade de blocos aninhados e distância normalizada.
• Conjunto CK: métodos ponderados por classe, profundidade de árvore de
herança, número de filhas e ausência de coesão em métodos.
• Acoplamento: acoplamento aferente e acoplamento eferente.
Para a preparação dos dados, neste trabalho, foi desenvolvida uma ferramenta que
lê os arquivos XML disponibilizados no Qualitas.class Corpus e alimenta um banco de
dados Mysql com o objetivo de normalizar as medidas. Realizada a conversão por meio
dessa ferramenta, têm-se uma forma rápida e ágil de agregar e sumarizar os dados.
2.1. Data-Fitting
Um problema importante em Estatı́stica é obter informação sobre a distribuição seguida
pelo conjunto de dados analisados [Gibbons and Chakraborti 2003]. Para esse propósito,
a ferramenta EasyFit (2013), por meio do teste de aderência de Kolmogorov-Smirnov, realiza a seleção da distribuição apropriada aos dados, o qual é o procedimento de escolher
uma distribuição que tenha melhor ajuste para um conjunto de dados. O objetivo dessa
etapa é estabelecer a distribuição apropriada a cada métrica de software estudada. Segundo Baxter et al. (2006), explorar as distribuições dos valores das métricas de software
é fundamental para avançar no entendimento das estruturas internas de softwares. A partir
da distribuição é possı́vel identificar e entender suas caracterı́sticas, como por exemplo,
se o valor médio é ou não representativo para a análise.
63
WTDSoft
2.2. Análise dos Dados
EasyFit gera um histograma de probabilidade dos dados ajustados a distribuição. A partir dessa visualização gráfica e do conhecimento das caracterı́sticas da distribuição mais
aderente aos dados, é possı́vel derivar valores referência para as métricas. Na abordagem
de Ferreira et al. (2012), quando a métrica apresenta uma distribuição que possui valor
médio representativo, como por exemplo, a distribuição de Poisson, este valor representa
o valor tı́pico da métrica. Senão, são identificadas três faixas de valores: Bom/Frequente,
Regular/Ocasional e Ruim/Raro, onde Bom/Frequente corresponde a valores com alta
frequência, caracterizando os valores mais comuns da métrica, na prática. Para os autores, esses valores não expressam necessariamente as melhores práticas da Engenharia
de Software, e sim um padrão seguido pela maioria dos softwares. Ruim/Raro corresponde a valores com baixa frequência, e a faixa Regular/Ocasional é intermediária, e
são valores que não são nem muito frequentes nem raros. A frequência é estabelecida via
uma análise gráfica do histograma de probabilidade dos dados ajustados a distribuição.
Ferreira et al. (2012) avaliaram os valores referência propostos via estudos de casos,
considerando que a sua aplicação pode resultar em duas situações possı́veis: o valor referência avalia corretamente ou não o método, a classe ou o pacote. A avaliação correta
ocorre quando a faixa em que a métrica cai reflete a situação real do artefato avaliado.
Quando não há avaliação correta do valor referência, os estudos de caso consideram duas
situações: (1) falso-positivo - o valor referência gera uma classificação ruim e a inspeção
qualitativa não identifica problemas estruturais; (2) falso-negativo - o valor não classifica
a classe como ruim, mas a inspeção qualitativa identifica problemas em sua estrutura. A
identificação de casos falsos-negativos demanda uma avaliação qualitativa de um número
muito grande de classes. No entanto, considerando que a derivação é feita de forma quantitativa, via análise de distribuição das medidas coletadas de uma grande quantidade de
sistemas, uma inspeção manual é inviável, dada a dimensão da amostra. Por essa razão,
Ferreira et al. avaliaram os casos falsos-positivos a partir da inspeção manual apenas
daquelas classes identificadas nas faixas Ruim/Raro, com o objetivo de avaliar a eficácia
do valor referência para identificar problemas. Neste trabalho de dissertação é proposta a
condução de 3 estudos de casos com os seguintes objetivos:
• Estudo de Caso 1: avaliar um software proprietário com a qualidade interna deteriorada, com o propósito de verificar a capacidade dos valores referência propostos
em indicar essa má qualidade. Nesse sentido, esse estudo de caso investiga se a
aplicação dos valores referência de fato identifica métodos e classes de qualidade,
não produzindo assim resultados falsos-negativos. Em um software qualitativamente definido como ruim, espera-se que métodos e classes não sejam bem avaliados em consonância com a opinião dos desenvolvedores, refletindo o panorama
de baixa qualidade. Esse estudo busca avaliar, respectivamente, as métricas de
métodos, as métricas de classes e a correlação dessas métricas não avaliarem bem
os métodos e classes devido a ocorrência de bad smells bem conhecidos.
• Estudo de Caso 2: avaliar uma amostra de métodos e classes classificadas como
Ruim/Raro por meio dos valores referência estabelecidos, com o objetivo principal
de verificar a presença de casos falsos-positivos.
64
WTDSoft
• Estudo de Caso 3: avaliar o software JHotDraw, de reconhecida qualidade estrutural, com o objetivo de verificar a capacidade dos valores referência em indicar essa qualidade. Se isso se confirmar, a aplicação dos valores referência
possui baixo risco de levarem a resultados falsos-positivos, afinal, as classes são
de boa qualidade e, de fato, são bem avaliadas pelos valores referência. Outra
confirmação dessa capacidade é que os valores referência são confiáveis quando
sugerem um panorama de qualidade, minimizando o problema de avaliações com
resultados falsos-negativos, que ocorre quando a classe não possui problemas estruturais, mas os valores referência os indicam.
A preparação dos dados, data-fitting (Seção 2.1), análise dos dados (Seção 2.2) e a
identificação dos valores referência para 18 métricas de softwares orientados por objetos foram concluı́das. A Tabela 1 sumariza 5 dos 18 valores referência propostos. A
avaliação dos resultados (Seção 3) está parcialmente concluı́da.
Table 1. Valores Referência Identificados.
Métrica
Acoplamento Aferente
Acoplamento Eferente
Número de Atributos
Número de Métodos
Complexidade de McCabe
Bom/Frequente Regular/Ocasional Ruim/Raro
m≤7
7 < m ≤ 39
m > 39
m≤6
6 < m ≤ 16
m > 16
m≤3
3<m≤8
m>8
m≤6
6 < m ≤ 14
m > 14
m≤2
2<m≤4
m>4
O processo de derivação para a métrica Número de Métodos é o seguinte: o Gráfico
de Frequência Relativa Acumulada, Figura 1(a), sugere uma distribuição de cauda-pesada.
Isso significa que há um grande número de classes com poucos métodos e um pequeno
número de classes com muitos métodos. Como mostrado na Figura 1(b), o conjunto de
valores dessa métrica possui melhor ajuste à distribuição Weibull. A Figura 1(c) mostra
esses dados em escala logarı́tmica, sugerindo uma lei de potê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 análise visual no Gráfico de Frequência Relativa Acumulada da Figura 1(a). Pontos marcados
em formato de quadrado e losango representam as regiões identificadas nessa análise.
També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. Contribuições Pretendidas
As principais contribuições pretendidas, oriundas da pesquisa proposta, incluem:
1. Um catálogo de valores referência para 18 métricas de softwares orientados por
objetos, derivados a partir de um dataset de 111 softwares open-source.
2. Um catálogo de distribuições estatı́sticas que possuam melhor encaixe em relação
as 18 métricas de softwares orientados por objetos, permitindo identificar caracterı́sticas acerca de como os softwares estão sendo construı́dos.
65
WTDSoft
(a)
(b)
(c)
Figure 1. Número de Métodos: (a) Frequência Relativa Acumulada (b) Densidade
de Probabilidade ajustada à Distribuição Weibull (c) Histograma em escala loglog.
3. Ampliação do universo de métricas com valores referência derivados a partir da
metodologia de Ferreira et al. (2012), permitindo realizar uma análise comparativa em termos de resultados com outros trabalhos.
4. Avaliações dos valores referência em: (1) um software proprietário mal projetado,
com o objetivo de estender a validação proposta a softwares fora do universo de
código aberto e, (2) do dataset utilizado no processo de derivação.
5. Avaliação dos valores referência na identificação de métodos, classes e pacotes de
baixa qualidade, bem como a avaliação em um software bem projetado.
Alves et al. (2010) propuseram um método empı́rico para determinar valores referências
a partir de um conjunto de softwares, onde as medições coletadas são agregadas gerando
informações no formato: o valor 17 da métrica McCabe representa 0,658% de todos
os sistemas. Esses valores são ordenados e os valores referência sã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. não consideram a distribuição apropriada aos dados na definição
dos percentis que definem os perfis.
Ferreira et al. (2012) identificam valores referência para 6 métricas de softwares
orientados por objetos via medição das estruturas de um conjunto de 40 softwares de
código aberto desenvolvidos em Java, de diferentes tamanhos, domı́nios e tipos, e uma
análise estatı́stica dos dados baseada em uma distribuição estatı́stica apropriada.
Oliveira et al. (2014) propuseram o conceito de valores referência relativos para
avaliar métricas aderentes a uma distribuição de cauda-pesada. Os valores referência são
relativos pois devem ser seguidos pela maioria das entidades, mas considera-se natural
que um determinado número de entidades não siga os limites definidos. O formato dos
valores referência é o seguinte: p% das entidades devem ter M ≤ k, aonde M é uma
métrica de código-fonte, k é o limite definido p é a porcentagem mı́nima.
Quando as contribuições desse trabalho são comparadas com os resultados apresentados por Ferreira et al. (2012) e estudos anteriores, identificam-se três diferenças prin66
WTDSoft
cipais: (1) Foram introduzidas melhorias no método de derivação de valores referência de
Ferreira et al., bem como, houve um avanço nas discussões acerca de suas limitações e
qualidades em relação ao panorama atual da área. (2) Foram identificados valores referência para um número maior de métricas. (3) Os valores referência propostos provêem
um benchmark para a avaliação quantitativa da qualidade interna de softwares orientados
por objetos, considerando não somente classes, mas também métodos e pacotes.
7. Conclusões
O objetivo dessa proposta de dissertação é definir um método para extração de valores
referência para métricas de softwares orientados por objetos. O método proposto consiste
na análise estatı́stica da distribuição de um conjunto de medidas extraı́das de um dataset
de softwares, apresentando três faixas de valores: Bom/Frequente, Regular/Ocasional e
Ruim/Raro. O método não usa técnicas estatı́sticas muito complexas, é reprodutı́vel e foi
aplicado a uma grande quantidade de softwares para extração dos valores referência.
Desde a submissão desse artigo até hoje, avançamos em nossa pesquisa e obtivemos alguns resultados preliminares bem animadores sobre os valores referência propostos
via estudos de casos realizados. Na continuidade do trabalho, pretendemos aprimorar os
estudos de casos realizados, afim de avaliar os valores referência de forma a verificar se
eles de fato auxiliam na identificaçã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 1–10. 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 397–412, NY, USA. ACM.
EasyFit (2013). Easyfit. Disponı́vel em: http://www.mathwave.com/products/easyfit.html.
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):244–257.
Fowler,
M. (2003).
Anemic domain model.
Disponı́vel em:
http://www.martinfowler.com/bliki/AnemicDomainModel.html. 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 254–263.
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 336–345.
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):1–4.
67
WTDSoft
Um Modelo Conceitual para Caracterização da Qualidade
Interna de Sistemas de Software Open-Source Orientados a
Objeto
Mariana Santos1, 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
[email protected], [email protected], [email protected]
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
WTDSoft
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 6.
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
WTDSoft
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.
2.2. 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.
2.3. 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 (http://sourceforge.net/) e Github (https://github.com/).
Tabela 1- Análise Descritiva dos Sistemas Selecionados por Domínio
Domínios
WMC CBO RFC LCOM
6.782 4.035 12.209 0.245
Áudio & Vídeo (AV)
Business & Enterprise (BE) 25.370 6.164 16.805 0.273
4.822 4.209 13.326 0.266
Communications (C)
8.589 4.182 11.073 0.208
Development (D)
5.687 5.060 14.189 0.183
Games (G)
8.844 3.514 13.363 0.276
Graphics (GPH)
8.596 4.506 13.745 0.283
Home & Education (HE)
Science & Engineering (SE) 12.123 4.872 14.852 0.273
4.823 3.669 11.282 0.262
Security & Utilities (SU)
System Administration (AS) 4.803 4.267 10.499 0.243
70
NOC
211.0
705.0
112.0
162.0
166.0
113.0
149.0
227.0
87.00
219.0
DIT
LOC
NOM
2.259 56.829 2.732
2.304 220.074 11.840
2.115 40.205 1.773
1.964 66.062 3.617
2.019 121.000 2.016
2.279 77.442 3.012
2.431 58.916 3.550
2.110 95.151 3.781
2.256 38.229 1.705
2.287 37.997 2.309
CC
2.418
2.022
2.441
1.891
2.061
2.359
2.556
2.534
3.372
2.031
NOA
1.131
4.736
738.0
1.038
770.0
1.126
1.425
1.896
648.0
935.0
TCC
0.735
0.993
0.799
1.216
1.537
0.168
1.729
1.849
1.139
1.287
WTDSoft
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
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
WTDSoft
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.
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.
Tabela 2 - Cronograma
Ativ.
2013
2014
2015
Mai Jun Jul Ago Set Out Nov Dez Jan Fev Mar Abr Mai Jun Jul Ago Set Out Nov Dez Jan Fev Mar Abr
1
2
3
4
5
6
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.2028-2048, 2013.
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, 2012.
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. 245-273, 2000.
Cheliotis, G. From Open Source to Open Content: Organization, Licensing and Decision
72
WTDSoft
Processes in Open Cultural Production. In: Decision Support Systems. 47, 3. pp. 229244, 2009.
Hair, J. F.; Black, W. C.; Babin, B. J.; Anderson, R. E.; Tatham, R. L. Análise Multivariada
de Dados. Bookman. 688p. 2009.
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.1332-1336, 2010.
Hilburn, T. B.; Towhidnejad, M. Software Quality Across the Curriculum. In: Annual
Frontiers in Education. vol.3, pp.S1G-18, S1G-23 vol.3, 2002.
ISO/IEC 25010:2011 Systems and Software Engineering - Systems and Software Quality
Requirements and Evaluation - System and Software Quality Models. 2011.
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. 203-206. 2011.
Midha, V.; Bhattacherjee, A. Governance Practices and Software Maintenance: A Study of
Open Source Projects. In: Decision Support Systems, 54(1), pp. 23-32. 2012.
Muhammad, S.; Maqbool, O.; Abbasi, A.Q. Evaluating Relationship Categories for
Clustering Object-Oriented Software Systems. In: Software, v.6, no.3, pp.260-274,
2012.
QualiPSo. Disponível em: http://www.qualipso.org. 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. 201-211, 2007.
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, 2014. 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.498-501, 2009.
Souza, L. B. L. de; Maia, M. de A. Do Software Categories Impact Coupling Metrics? In:
Working Conference on Mining Software Repositories. pp. 217-220. 2013.
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, 2013.
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, 2012.
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. 197-207. 2010.
Yingjie Tian; Chuanliang Chen; ChunHua Zhang. AODE for Source Code Metrics for
Improved Software Maintainability. In: International Conference on Semantics,
Knowledge and Grid. pp. 330-335. 2008.
Zhong, S.; Khoshgoftaar, T. M.; Seliya, N. Analyzing Software Measurement Data with
Clustering Techniques. In: Intelligence Systems. v. 19, no. 2, pp. 20-27. 2004.
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. 808-817. 2012.
73
WTDSoft
Análise da Qualidade de Experimentos da Computação em
Nuvem
Helaine Lins1 , Vinicius Garcia1 , Sergio Soares1
1
Centro de Informática – Universidade Federal de Pernambuco (UFPE)
Recife – PE – Brasil
{hsl,vcg,[email protected]}
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.
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
R
em 1999 quando a Salesforce
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 2014.
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
1
http://www.idc.com/research/Predictions14/index.jsp
74
WTDSoft
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.
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 pos75
WTDSoft
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.
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
Assert2 e ESEG3 . A pretensão de defesa é para fevereiro de 2015 e o cronograma de
pesquisa proposto é apresentado na tabela 1.
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
2
3
http://assertlab.com/
https://sites.google.com/site/eseportal/
76
WTDSoft
Atividade
Jun
Jul
Agos
Meses
Set Out
Nov
Dez
Jan
Revisão Sistemática da Literatura
Instrumento de Avaliação
Avaliação da Qualidade
Escrita da Dissertação
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.
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):599–616.
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
WTDSoft
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 285–311. 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:41–52.
Kitchenham, B. A., Dyba, T., and Jorgensen, M. (2004). Evidence-based software engineering. In Software Engineering, 2004. ICSE 2004. Proceedings. 26th International
Conference on, pages 273–281. 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):721–734.
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):2371–
2393.
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):62–73.
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, 2011 - June 22, 2011.
Poess, M. and Floyd, C. (2000). New tpc benchmarks for decision support and web
commerce. ACM Sigmod Record, 29(4):64–71.
Prodan, R. and Ostermann, S. (2009). A survey and taxonomy of infrastructure as a
service and web hosting cloud providers. In Grid Computing, 2009 10th IEEE/ACM
International Conference on, pages 17–25. IEEE.
Silva, G. C., Rose, L. M., and Calinescu, R. (2013). A Systematic Review of Cloud
Lock-In Solutions. 2013 IEEE 5th International Conference on Cloud Computing
Technology and Science, pages 363–368.
Stantchev, V. (2009). Performance evaluation of cloud computing offerings. In Advanced
Engineering Computing and Applications in Sciences, 2009. ADVCOMP’09. Third
International Conference on, pages 187–192. 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
WTDSoft
Definição de um Framework para Avaliação Sistemática de
Técnicas de Teste no Contexto de Programação Concorrente
Silvana M. Melo1 , Orientadora: Simone R. S. Souza1
1
{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.
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
WTDSoft
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.
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
WTDSoft
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.
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
WTDSoft
[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
WTDSoft
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
WTDSoft
Agradecimento
Os autores gostariam de agradecer a FAPESP, pelo apoio financeiro (processo número:
2013/05046-9).
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:412–427.
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 167–178,
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 425–439. Springer.
Coward, P. D. (1988). A review of software testing. Inf. Softw. Technol., 30:189–198.
DeMillo, R. A., Lipton, R. J., and Sayward, F. G. (1978). Hints on test data selection:
Help for the practicing programmer. Computer, 11(4):34–41.
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
785–802. 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 224–234. ACM.
Herman, P. M. (1976). A data flow analysis approach to program testing. Australian
Computer Journal, 8(3):92–96.
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):52–62.
Kitchenham, B. A., Dybaa, T., and Jorgensen, M. (2004). Evidence-Based Software
Engineering. In Proceedings of ICSE 2004, pages 273–281. 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
WTDSoft
Kundu, S., Ganai, M. K., and Wang, C. (2010). Contessa: Concurrency testing augmented
with symbolic analysis. Lecture Notes in Computer Science (LNCS), 6174:127–131.
Laski, J. W. and Korel, B. (1983). A data flow oriented program testing strategy. IEEE
Trans. Softw. Eng., 9:347–354.
Lei, Y. and Carver, R. H. (2006). Reachability testing of concurrent programs. IEEE
Transactions on Software Engineering, 32:382–403.
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): 9–31.
Pilar, M., Simmonds, J., and Astudillo, H. (2014). Semi-automated tool recommender for
software development processes. Electronic Notes in Theoretical Computer Science,
302(0):95 – 109. 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):367–375.
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 10–14.
Silva, R., Pezzi, G., Maillard, N., and Diverio, T. (2005). Automatic data-flow graph
generation of mpi programs. In SBAC-PAD, pages 93–100.
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):21–50.
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):1606–1618.
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 230–
239.
Wu, M., Zhou, B., and Shi, W. (2009). A self-adaptive test framework for concurrent
programs. In MEDES, pages 456–457, 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 143–149, 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 485–502. ACM.
85
WTDSoft
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 Medeiros1, Alexandre M. L. de Vasconcelos 2, Carla T. L.
L. Silva Schuenemann 2
1
2
Instituto Federal de Educação, Ciência e Tecnologia da Paraíba (IFPB)
Jaguaribe, CEP: 58.015-020, João Pessoa-PB, Brasil
Centro de Informática (Cin) – Universidade Federal de Pernambuco (UFPE)
Cidade Universitária - 50740-560, Recife-PE, Brasil.
[email protected], {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.
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
WTDSoft
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
2.500.000 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
WTDSoft
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
WTDSoft
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.
A seguir serão detalhadas as atividades já realizadas e o que está em andamento.
4.1. 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).
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
RSL:
•
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 Reviewer1. Para a
busca automática não houve limitação de período de ano de publicação.
1
Reviewer (https://github.com/bfsc/reviewer)
89
WTDSoft
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.
4.2. 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.
4.3. 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
WTDSoft
Requirements Development). O objetivo é tornar a nova abordagem aderente ao referido
modelo de qualidade no que diz respeito aos requisitos de software.
4.4. 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.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.
5.2. 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
WTDSoft
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
2001. Disponível em: <http://www.agilemanifesto.org/>. Acesso em: 26/05/2014.
Ambler, S. W. (2002) “Agile Modeling: Effective Practices for eXtreme Programming
and the Unified Process”. Wiley Chichester, ISBN 978-0471202820.
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-2007-01, 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: <http://www.agilealliance.org/resources/articles/>. 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 2011.
Standish Group. (2013). “The CHAOS Manifesto
www.standishgroup.com. Acesso: 26/05/2014.
2013”.
Disponível
em:
Techcrunch. (2014). “iTunes App Store Now Has 1.2 Million Apps...”. Disponível em:
http://techcrunch.com/2014/06/02/itunes-app-store-now-has-1-2-million-apps-hasseen-75-billion-downloads-to-date/. 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
WTDSoft
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
Email de contato do aluno: [email protected]
Email de contato do orientador: [email protected]
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
WTDSoft
É 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.
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
WTDSoft
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
WTDSoft
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.
Figura 1. Visão Geral do Método
3.1. Extração
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
WTDSoft
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 e-mail 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 e-mails 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.
3.2. Tratamento
A etapa de tratamento refere-se à manipulação das informações extraídas. Inicialmente,
as informações dos autores, como nome e e-mail, 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.
3.3. 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
WTDSoft
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.
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 7.434 no projeto Git. Quanto ao número de desenvolvedores,
existe também uma grande variação: 59 desenvolvedores no projeto Voldemort e 1.103
no projeto Git.
Tabela 1. Informações de merges e desenvolvedores
Número de Merges e Desenvolvedores
Projeto
Descrição
Git
Sistema de Controle de Versão Distribuído
Voldemort
Banco de Dados Distribuído
# Merges
# Desenvolvedores
7.434
1.103
406
59
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
Desenvolvedores em ambos os ramos – Projeto Git
Merge
a8816e7bab03…
Desenvolvedores
Commits no ramo 1
Commits no ramo 2
Markus
Alex
Shawn
Jens
Ferry
23
7
2
1
1
5
1
4
4
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
WTDSoft
os que mais realizaram commits. Neste caso, os desenvolvedores Bhusesh, Kirktrue,
Alex e Bbansal seriam candidatos a participar do merge colaborativo.
Desenvolvedores com mais commits – Projeto Git
Merge
Desenvolvedores
Commits no ramo 1
Commits no ramo 2
Junio
Schindelin
Jeff
Markus
Shawn
Jens
512
69
58
23
2
1
0
0
0
5
4
4
a8816e7bab03…
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.
Desenvolvedores com mais commits em ambos os ramos – Projeto Voldemort
Merge
2a5c69145fb6
…
Desenvolvedores
Commits no ramo 1
Commits no ramo 2
Bhusesh
Kirktrue
Alex
Bbansal
33
29
20
4
11
10
13
2
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.
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. Pretende99
WTDSoft
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, 1998.
BRUN, Yuriy et al. Proactive detection of collaboration conflicts. 2011, p. 168–178.
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, 2012.
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, 2013. p. 201–210.
ESTUBLIER, Jacky. Software configuration management: a roadmap. ACM, 2000.
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, 2012. p. 342–352.
KOEGEL, Maximilian et al. Collaborative model merging. SPLASH ’10, 2010, New
York, NY, USA. Anais... New York, NY, USA: ACM, 2010. p. 27–34.
LEON, Alexis. A Guide to Software Configuration Management. [S.l.]: Artech House,
Incorporated, 2000.
MENS, Tom. A state-of-the-art survey on software merging. Software Engineering,
IEEE Transactions on, v. 28, n. 5, p. 449–462, 2002.
NIEMINEN, A. Real-time collaborative resolving of merge conflicts. In: 2012 8TH
International Conference on Collaborative Computing: Networking, Applications and
Worksharing (Collaboratecom), 2012, [S.l: s.n.], 2012. p. 540–543.
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. 889–908, jul. 2012.
100
WTDSoft
A Meta-Process Oriented to Software Product Quality
Based on ISO/IEC 25010 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)
E-mail de contato do aluno: [email protected]
E-mail dos orientadores: [email protected], [email protected], [email protected]
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 12207 and
ISO/IEC 15504 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 25010. 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
WTDSoft
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 15504 Information Technology - Process Assessment [ISO/IEC, 2003], and the ISO/IEC 12207
- 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 25000 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
12207 and 15504 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 25010 [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 9126-1 [ISO/IEC, 2006] proposes characteristics and sub characteristics
that software should possess to have quality attributes. The ISO/IEC 25000 was issued
in 2005, and the ISO/IEC 25010, which supersedes the ISO/IEC 9126-1, was issued in
2011. The ISO/IEC 25010 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 25010 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
WTDSoft
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
WTDSoft
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
Status
Done
Systematic Literature Review
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
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
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 9126. 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
WTDSoft
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.
6.1. 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
WTDSoft

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 (http://dl.acm.org/);
 IEEE Xplore (http://www.ieeexplore.ieee.org);
 ISI Web of Knowledge (http://apps.webofknowledge.com/);
 Scopus (http://www.scopus.com);
 El Compendex (www.engineeringvillage2.org).
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. 1296 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
WTDSoft
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 12207 and 15504
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 CMMIDEV 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 75–90.
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
WTDSoft
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 15504-2 - Information Technology – Software Process
Assessment”, International Organization for Standardization and the International
Electrotechnical Commission, Geneva, Switzerland.
ISO/IEC (2014) “ISO/IEC 25000 - 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 9126-1 - 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:2008 - 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 2007-001, Keele
University and Durham University Joint Report.
Li, Y. et al. (2010) “Software Development Team Flexibility Antecedents”. In Journal
of Systems and Software, pages 1726–1734.
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 51–56.
SEI – Software Engineering Institute (2010) “CMMI for Development – V 1.3”,
http://www.sei.cmu.edu/reports/10tr033.pdf, 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 61–70.
SOFTEX – Associação para Promoção da Excelência do Software Brasileiro (2012)
“Guia
Geral
MPS
de
Software:
2012”,
http://www.softex.br/wpcontent/uploads/2013/07/MPS.BR_Guia_Geral_Software_20121.pdf, April.
Wohlin, C. et al. (2000) “Experimentation in software engineering: an introduction”.
Kluwer Academic Publishers, Norwell, MA, USA.
108
WTDSoft
Search-Based Mutation Testing para Programas
Concorrentes
Rodolfo Adamshuk Silva1 , Simone do Rocio Senger de Souza1
1
Instituto de Ciências Matemáticas e de Computação – Universidade de São Paulo
(ICMC/USP)
Caixa Postal 668 – 13.560-970 – São Carlos – SP – Brazil
{adamshuk,srocio}@icmc.usp.br
Projeto de Doutorado
Programa de Pós-Graduação em Ciências de Computação e Matemática
Computacional do ICMC-USP
Ano de ingresso no programa: 03/2013
Época prevista de conclusão: 02/2017
Data da aprovação da proposta de tese: Previsão de 15/09/2014
Sigla do evento do CBSoft relacionado: SBES
Resumo. O teste de software é uma atividade que busca garantir a
qualidade por meio da identificação de falhas no produto. Para a aplicação
do teste de software, algumas técnicas são utilizadas como, por exemplo, a
técnica estrutural, a funcional e a baseada em defeitos. Cada técnica possui
seus critérios para auxiliar na criação dos casos de teste. Um dos critérios
da técnica baseada em defeitos é o teste de mutação. Este critério de teste
baseia-se nos enganos que podem ser cometidos pelos desenvolvedores de
software. O teste de mutação tem se mostrado eficaz para revelar defeitos,
porém, o seu alto custo compromete sua utilização, principalmente quando
são considerados programas complexos. A Programação Concorrente é um
paradigma de desenvolvimento essencial para a construção de aplicações
com o intuito de reduzir o tempo computacional em muitos domı́nios. Estas
aplicações têm novas caracterı́sticas como comunicação, sincronização
e não determinismo que precisam ser considerados durante a atividade
de teste. No contexto de programas concorrentes, novos desafios são
impostos e precisam ser adequadamente tratados. Isso ocorre devido ao não
determinismo e as diferentes sincronizações entre processos. Search-Based
Software Testing é uma abordagem que vem sendo empregada para otimizar
a atividade de teste, aplicando meta-heurı́sticas para a solução de problemas
complexos, como por exemplo, geração de dados de teste. Este projeto de
doutorado está inserido nesse contexto, no qual se pretende investigar o
uso de Search-Based Software Testing para redução do custo da aplicação
do teste de mutação no contexto de aplicações concorrentes.
Palavras-chave. Teste de mutação, Search-Based Testing, Programação
concorrente.
109
WTDSoft
1. Introdução
Como um resultado dos avanços tecnológicos na área de hardware, por exemplo,
processadores multicore, a computação distribuı́da faz-se cada vez mais presente
nos sistemas atuais. Com isso, a programação concorrente está tornando-se cada
vez mais popular no desenvolvimento de softwares modernos. Esse paradigma de
desenvolvimento é essencial para a construção de aplicações capazes de reduzir o
tempo computacional em vários domı́nios, por exemplo softwares para processamento de imagens, dinâmica de fluidos, entre outros. Diferentemente dos programas
com caracterı́sticas sequenciais, a computação distribuı́da envolve programas (ou
processos) concorrentes (ou paralelos) que interagem para resolver um determinado
problema. Essa interação pode ocorrer de forma sincronizada ou não, sendo que
esses programas podem ou não concorrerem pelos mesmos recursos computacionais.
Teste de software é uma atividade de garantia de qualidade que visa a
identificar defeitos no produto em teste. A atividade de teste consiste em uma análise
dinâmica do produto e é uma atividade relevante para a identificação e eliminação de
defeitos que persistem. O teste de produtos de software envolve basicamente quatro
etapas: planejamento de testes, projeto de casos de teste, execução e avaliação dos
resultados dos testes [Myers et al. 2011]. Essas atividades devem ser desenvolvidas
ao longo do próprio processo de desenvolvimento de software e, para isso, um ponto
crucial é a seleção dos casos de teste que serão utilizados. Sabe-se que executar
todos os casos de teste possı́veis a partir do domı́nio de entrada do produto em teste
é impraticável e, portanto, critérios de teste são definidos.
Os crité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 esforço. Um teste bem sucedido é aquele que consegue determinar casos
de teste para os quais o programa em teste falhe. Um dos critérios de testes da
técnica baseada em defeitos é o teste de mutação. Este critério utiliza informaçõ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 são caracterizados e implementados como
operadores de mutação que, durante a atividade de teste, geram versões modificadas
(mutantes) do produto em teste (especificação ou implementação, por exemplo).
A intenção é auxiliar a seleção de casos de teste que demonstrem que os defeitos
modelados pelos operadores de mutação não estão presentes no produto em teste.
Um problema do teste de mutação que impede que ele seja aplicado amplamente é
o alto custo computacional de executar o enorme número de mutantes com os casos
de teste, além do alto número de casos de teste necessários para alcançar um escore
de mutação mais próximo de 1.0 [Jia and Harman 2011].
A atividade de teste no contexto de programas concorrentes é considerada
mais complexa quando comparada com a atividade de teste de programas sequenciais. Além das dificuldades inerentes à atividade de teste, outras ocorrem devido,
principalmente, ao comportamento não determinı́stico dessas aplicações, no qual
múltiplas execuções de um programa concorrente com a mesma entrada podem
executar diferentes sequências de sincronização e podem produzir diferentes resultados. Cabe à atividade de teste, nesse cenário, identificar se todas as sequências de
sincronização possı́veis foram executadas e se as saı́das obtidas estão corretas. Essa
caracterı́stica difere os programas concorrentes dos programas sequenciais e precisa
110
WTDSoft
ser considerada durante a atividade de teste de software. Assim como os demais critérios de teste, o teste de mutação tem sido investigado para programas concorrentes
[Offutt et al. 1996, Silva-Barradas 1998, Bradbury et al. 2006, Silva 2013].
2. Motivação e Objetivo
A busca por estratégias que visem a automatização de teste de software é constante
não só para o critério de mutação, mas também para os outros critérios. Isso vem
acontecendo porque os programas a serem testados estão cada vez maiores e mais
complexos, tornando a atividade de teste mais custosa, em termos financeiros e computacionais, e mais demorada. Até mesmo programas simples são custosos de serem
testados devido ao problema de explosã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 otimização matemática utilizando-se meta-heurı́sticas.
É nesse contexto que surgiu o conceito de Search-Based Software Testing (SBST)
que consiste no uso de técnicas de busca utilizando meta-heurı́stica (algoritmo
genético, por exemplo) para automatizar total ou parcialmente a atividade de teste
[McMinn 2011]. Técnicas de busca meta-heurı́stica são arcabouços de alto nı́vel que
utilizam heurı́sticas para encontrar soluções à problemas que envolvem combinação
de resultados a um custo computacional aceitável [McMinn 2011]. Essas técnicas não
são algoritmos prontos, mas estratégias para a adaptação para problemas especı́ficos.
Pesquisas nessa área mostram que é promissora a aplicação de Search-Based
no contexto de teste de software. As áreas de aplicação são cinco: geração de dados
de teste, seleção de casos de teste, priorização de casos de teste, testes não funcionais
e testes funcionais. A geração de dados de teste consiste em identificar um conjunto
de dados de entrada válido para um programa, que satisfaça um determinado critério
de teste com o objetivo de encontrar um dado de teste que faça o programa se
comportar diferentemente do esperado, revelando, assim, um defeito. A seleção
de casos de teste consiste em escolher quais casos de teste devem ser aplicados
em um sistema [Maia 2009]. A priorização de casos de teste trata da ordenação
dos casos de teste de modo que os mais significativos sejam executados primeiro
[Maia et al. 2010]. Os testes não funcionais verificam caracterı́sticas do sistema não
relacionadas a funcionalidades [Briand et al. 2004]. Por sua vez, os testes funcionais
verificam se a implementação de uma aplicação está de acordo com sua especificação
[Cohen et al. 2003].
O principal problema associado ao teste de mutação está no número de
mutantes gerados, sendo, na maioria das vezes, alto, fazendo com o que o custo
computacional também seja alto [Jia and Harman 2011]. Esse problema é agravado
quando se está tratando de programas concorrentes, uma vez que, por causa do não
determinismo, o programa possui diferentes sequências de sincronização que devem
ser exercitadas durante a atividade de teste. Isso faz com que a complexidade
computacional da execução de todos os mutantes, a geração de dados de teste
para matar todos os mutantes sejam altos [Jia and Harman 2011]. Outro problema
está relacionado com a identificação dos mutantes equivalentes que é realizada pelo
testador e leva certo tempo para ser concluı́da, pois se deve analisar o programa
mutante, comparar com o programa original, para então decidir se o mutante é
equivalente ou não. Então, quanto mais mutantes forem gerados, mais mutantes
terão que ser analisados para identificar os equivalentes.
111
WTDSoft
Devido ao alto custo da aplicação do teste de mutação, várias estratégias
vêm sendo utilizadas para fazer com que o critério de mutação possa ser utilizado de
maneira mais eficiente. As técnicas de redução do custo do teste de mutação podem
ser divididas em três tipos: do fewer (redução de número de mutantes sem afetar
desempenho), do faster (procurar executar os mutantes o mais rápido possı́vel) e do
smarter (dividir o custo computacional ou evitar a execução completa ou guardar
informações do estado da execução) [Offutt and Untch 2001].
Levando em consideração os resultados já obtidos em [Silva 2013], surgiu a
motivação de investigar abordagens que proporcionem a diminuição dos custos de
aplicação do teste de mutação (do fewer ) para programas concorrentes. O objetivo
do projeto de doutorado é investigar e propor uma abordagem para a otimização do
teste de mutação utilizando técnicas de Search-Based Software Testing. Os desafios
cientı́ficos identificados neste projeto de doutorado estão relacionados ao uso de
SBST aplicado ao teste de mutação. Além disso, tem-se a aplicação de técnicas de
SBST no contexto de programas concorrentes, o que é considerado inovador, pois
essa técnica é pouco aplicada para resolver os problemas envolvendo teste nesse
contexto.
3. Resultados e Contribuições
Com o objetivo de se ter uma visão ampla do contexto a ser estudado, uma revisão
sistemática foi conduzida com o objetivo encontrar trabalhos que aplicam técnicas de
meta-heurı́stica como forma de automatizar o teste de mutação. Como a finalidade
de alcançar esse objetivo, foram formadas as seguintes questões de pesquisa: Q1)
Em quais etapas do teste de mutação SBST está sendo aplicada? Q2) Quais as
técnicas de meta-heurı́stica estão sendo utilizadas no teste de mutação? A condução
da revisão foi realizada levando em consideração cinco má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 área. Vale ressaltar que
nenhum dos artigos encontrados aplica SBST para teste de mutação em programas
concorrentes, o que faz desta proposta de doutorado inovadora. A string de busca
e os critérios de exclusão com o número de trabalhos excluı́dos são mostrados na
Figura 1.
Figura 1. String de busca e critérios de exclusão.
Respondendo Q1, SBST está sendo aplicado para otimizar: a seleção de
operador de mutação (1 trabalho), a geração de dado de teste (39 trabalhos),
112
WTDSoft
a geração de mutante (12 trabalhos) e a geração de dado de teste e mutante
simultaneamente (3 trabalhos). Respondendo a segunda questão de pesquisa, dentre
os 15 trabalhos que apresentam abordagens para a redução do número dos mutantes
utilizando SBST, as seguintes meta-heurı́sticas sã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).
3.1. Trabalhos Relacionados
[May et al. 2003] apresenta uma abordagem inspirada no sistema imunológico do
corpo humano chamada Immune Algorithm. A função de aptidão é calculada para
o mutante observando o quão diferente foi a saı́da dada por ele em relação à saı́da
do programa original. Para o dado de teste, a função de aptidão é calculada pelo
número de mutantes que foram mortos. Nos trabalhos de [Adamopoulos et al. 2004,
Assis Lobo de Oliveira et al. 2013] é apresenta uma metodologia que utiliza o
conceito de co-evolução para gerar mutantes e dados de teste utilizando Genetic
Algorithm. Em [Adamopoulos et al. 2004] a função de aptidão é calculada a partir
do escore de mutação e em [Assis Lobo de Oliveira et al. 2013] é a divisão entre o
número de mutantes mortos e o total de mutantes.
Em [Jia and Harman 2008] Genetic Algorithm e Hill Climbing são utilizadas para geração de mutantes.
A função de aptidão é calculada pela
uniã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-Jiménez et al. 2009b, Domı́nguez-Jiménez et al. 2009a,
Domı́nguez-Jiménez et al. 2010, Domı́nguez-Jiménez et al. 2011] é apresentada
uma técnica utilizando Genetic Algorithm para a geração de mutantes. A função de
aptidão é calculada levando em consideração se o mutante é morto ou não pelo caso
de teste e quantos mutantes foram mortos pelo mesmo caso de teste.
Em [Blanco-Munoz et al. 2011] Genetic Algorithm é utilizado para a geração
de mutantes e a função de aptidão é calculada pela fragilidade do mutante. Em
[Schwarz et al. 2011] é 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 código. A função de aptidão é calculada pelo impacto que o
mutante tem com relação aos outros mutantes.
No trabalho de [Omar et al. 2013] sã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] são aplicados Genetic
Algorithm, Hill Climbing e Greedy Algorithm para geração de HOMs. Para
ambos os trabalhos, a função de aptidão é calculada pela diferença entre as falhas
encontradas no HOM e as falhas encontradas nos mutantes que compõe o HOM. Em
[Langdon et al. 2009a, Langdon et al. 2009b, Langdon et al. 2010] é apresentada
uma abordagem que utiliza NSGA-II para a geração de mutantes. NSGA-II não
calcula função de aptidão.
3.2. Abordagem Proposta
O objetivo deste trabalho é diminuir o custo relacionado à aplicação do teste de
mutação no contexto de programas concorrentes. Para isso, está sendo investigado
o uso de meta-heurı́sticas para a geração de mutantes. A partir desse objetivo,
113
WTDSoft
duas perguntas puderam ser feitas: 1) Como o teste de mutação pode ser
otimizado? e 2) Quais as possibilidades de utilização de SBST no contexto de
teste de mutação e programação concorrente? Para responder essas perguntas,
primeiramente foi conduzida uma revisão sistemática com o objetivo de identificar
trabalhos que utilizam SBST para otimizar o teste de mutação sem focar em
programas concorrentes. Com isso, pôde-se ter uma ideia das pesquisas na área
de teste de mutação.
Com os trabalhos publicados nessa área, pode-se observar que há a motivação
de diminuir o custo do teste de mutação por meio de três abordagens diferentes:
1) seleção de operador de mutação, 2) geração de dado de teste, 3) geração de
mutante. Observou-se que grande parte dos trabalhos utilizavam a meta-heurı́stica
Genetic Algorithm, que utiliza uma função de aptidão para atribui valores aos
mutantes dependendo de quão bons eles são com relação ao resultado de otimização
que se quer alcançar. Levando em consideração as funções de aptidão, não
foi encontrada nenhuma que utilizasse a frequência de mutação para avaliar um
mutante. Então, essa foi a motivação para desenvolver um experimento para avaliar
se a frequência de execução de mutantes pode ser uma boa alternativa para ser
utilizada, posteriormente como função de aptidão em um Genetic Algorithm.
A frequência de execução calcula a quantidade de dados de teste que fazem
com que o ponto onde há a mutação no programa mutante seja executado. Um
importante ponto a se observar é a quantidade de mutantes vivos com uma alta
frequência de execução. Segundo [Bottaci 2001], para demonstrar a presença de
uma falha em um mutante (matar o mutante) é necessário que a execução do caso de
teste alcance o ponto de mutação (condição de alcançabilidade), o valor da expressão
modificada deve mudar o estado do programa mutante quando comparado com o
programa original (condição de necessidade) e essa diferença no estado precisa ser
propagada até a saı́da (condição de suficiência). Com isso, um mutante que possui
uma grande frequência de execução pode ser um possı́vel mutante equivalente (não
satisfazendo a condição de necessidade) ou não há um caso de teste que o faça
gerar uma saı́da diferente da apresentada pelo programa original (não satisfazendo
a condição de alcançabilidade).
O experimento tem como objetivo analisar os mutantes mais executados
com o propósito de verificar quantos são equivalentes ao programa original. A
hipótese nula diz que todos os mutantes com uma maior frequência de execução
e que permanecem vivos são equivalentes. A hipótese alternativa diz que há um
conjunto de mutantes que possuem uma frequência alta, porém não são equivalentes
ao programa original. Esse experimento está em desenvolvimento e consiste em
aplicar o teste de mutação utilizando a ferramenta Proteum em programas escritos
na linguagem C e identificar os mutantes equivalentes. O objetivo é verificar se os
mutantes equivalentes são os mutantes com maior frequência de execução e quantos
mutantes mortos tem uma alta frequência de execução. Com isso, espera-se refutar
a hipótese nula e poder afirmar que há um conjunto de mutantes que possuem uma
frequência alta, porém não são equivalentes ao programa original, podendo usar essa
medida como função de aptidão no Genetic Algorithm. Os resultados desse estudo
irão propiciar o estabelecimento de uma proposta de redução de custo do teste de
mutação, empregando técnicas de meta-heurı́stica que posteriormente será aplicada
no contexto de programação concorrente.
114
WTDSoft
Referê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 1338–1349. 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 829–836.
[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 38–48.
[Domı́nguez-Jiménez et al. 2011] Domı́nguez-Jiménez, J., Estero-Botaro, A.,
Garcı́a-Domı́nguez, A., and Medina-Bulo, I. (2011). Evolutionary mutation
testing. Information and Software Technology, 53(10):1108 – 1123.
[Domı́nguez-Jiménez et al. 2009a] Domı́nguez-Jimé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 97–106.
[Domı́nguez-Jiménez et al. 2010] Domı́nguez-Jimé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 490–493.
[Domı́nguez-Jiménez et al. 2009b] Domı́nguez-Jimé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 229–240.
[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 80–89.
[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 249–258.
[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):649–678.
115
WTDSoft
[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
21–29.
[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 1945–1946.
[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):2416–2430.
[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 Simpósio Brasileiro de Pesquisa
Operacional, pages 1824–1835.
[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 81–92. 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 153–163.
[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 34–44.
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
340–349.
[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
382–387.
[Silva 2013] Silva, R. A. (2013). Teste de mutação aplicado a programas concorrentes
em mpi. Mestrado, ICMC, Instituto de Computação e Matemá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
WTDSoft
Constructing a Theory of Agile Governance: a step towards
Business Agility
Alexandre J. H. de O. Luna1,2, Philippe Kruchten2*, Hermano Moura1+
1
2
Informatics Center (CIn). Federal University of Pernambuco (UFPE). Av. Jornalista
Anibal Fernandes, s/n, Cidade Universitária, 50740-560, Recife, PE, Brazil.
Department of Electrical and Computer Engineering (ECE). The University of British
Columbia (UBC). 2332 Main Mall. Vancouver, BC, V6T 1Z4, Canada.
+
Supervisor, *Co-supervisor.
[email protected], [email protected], [email protected]
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: 2011.
Estimated completion time: 2015.
Date of approval of the proposed thesis / dissertation (qualification):
scheduled for 29/08/2014.
CBSoft event: SBES
1
117
WTDSoft
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 (IT1) 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 value2 faster, better, and cheaper to the business”.
In line with these concepts, “agile governance” becomes the application of agile capabilities3 on governance
issues4 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 governance5 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
WTDSoft
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 phenomenon6: “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.
3.1. 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.
119
3
WTDSoft
“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].”
3.2. 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-theory7 should be a legitimate classification for this theory,
according to the level of generalization intended [Gregor 2006].
3.3. 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
About the objective
About the technical procedure
About the nature of variables
About method approach
About methods of procedure
Description and References
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
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].
Qualitative [Creswell 2002, 2012]
Inductive [Jebreen 2012]
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].
120
4
WTDSoft
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.
3.5.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
WTDSoft
importance of this research, as well as gave us the guidance for the next steps of this work, allowing to define the
final study product and to consolidate the study design to achieve the research aims.
In stage 2 we identify and consolidate the emerging theory’s core-components and test the hypotheses suggested
by the emerging relations between the categories already identified in the previous stage, and the new categories
and connections that can emerge during this stage, adopting a similar approach to grounded theory described by
[Corbin and Strauss 1990; Eisenhardt 1989; Pandit 1996] and the meta-ethnography approach described by Noblit
and Hare [1988]. The procedures in this stage are guided, but not limited to the following case study databases: the
BOK (generated during the stage 1), and an ensemble of social networks composed by researchers and
practitioners in governance, management and agile methods. As a result, we expect identify a set of emergent
concepts and categories, and a list of meta-values, as well as organizing them through ontology to make up the
emerging theory.
In stage 3 we will conduct a Survey [Groves et al. 2013] with experts (researchers and practitioners) on this
topic, utilizing a mix of closed-end and open-ended questions that have to be interpreted for meaning. This stage
aims to appraising the consistency and check the constitution of the emerging theory, through the application of
grounded theory upon the responses, and supplementing the information obtained with interviews when necessary.
In stage 4 we will assess the emerging theory applying Scenario Analysis [Antón et al. 1994], through the
development of a set of scenarios collected from real case studies and/or historical facts, to analyze the theory
behavior and intrinsic properties, such as: generalization, causality, explanation and prediction. At the same time
we will apply the Glaser’s criteria [Glaser 1992] to evaluate the theory’s credibility8 and Angen’s approach [Angen
2000] to conduct a validation from the ethical and substantive9 perspectives.
Finally, in stage 5 we will conduct an Exploratory Literature Review [Schuetzenmeister 2010] to identify other
theories in IS area, after the theory had emerged and stabilized, and pull in extant theory to compare and contrast
with the proposed theory [Glaser and Holton 2007], also to examine what is similar, what is different, and why, in
order to enhances the internal validity, generalizability, and theoretical level of the theory building [Eisenhardt
1989].
4. Current status of research
We conducted a systematic review about the state of the art of the agile governance up to and including 2013. On
that sampling, our search strategy identified 1992 studies in 10 databases, of which 167 had the potential to answer
our research questions. We organized the studies into four major groups: software engineering, enterprise,
manufacturing and multidisciplinary; classifying them into 16 emerging categories. As a result, the review provides
a convergent definition for agile governance, six meta-principles, and a map of findings organized by topic and
classified by relevance and convergence. Those complete results from the systematic literature review are under
publishing process in [Luna et al. 2014], and could not be detailed on this paper.
Table 2 – Research Schedule. SOURCE: own elaboration.
Research Schedule
Stage 1 - Systematic Review (up to 2011) [finished]
Stage 1 - Systematic Review (including 2012 & 2013)
Milestone 1 - Proposal definition (Qualify)
Stage 2 - Social Network Ethnography
Stage 3 - Experts Survey
Stages 1, 2, 3, 4, 5 - Data Analysis
Stage 4 - Theory Assessment
Stage 5 - Theory Comparison
Thesis writing
Publishing
Milestone 2 - Thesis defense
2 0 1 4
01 02 03 04 05 06 07 08 09 10 11
x x x x x x
x
x x x
x x x
x x x x x x x x x x x
x x
x
x x x x x x x x x x x
x
x
2 0 1 5
12 01 02 03 04 05 06
x x
x
x x x
x
x
x
Our review confirms that agile governance has a wide spectrum of interest for executives from any business area,
professionals, researchers and practitioners by treating, in essence, aspects such as: organizational performance and
competitiveness, as well as it can be verified by the categories and major groups that emerged from these review
findings. The entire conclusions, discussions and implications for research and practice from the SLR-AG will be
detailed in a subsequent paper. The Table 2 depicts the current status of work and the research schedule.
5.Conclusion and Expected Contributions
This paper described the study design of our ongoing research; the preliminary results are promising, and should
generate a meta-theory for agile governance, comprising: a meta-concept, meta-principles, meta-values, metacategories, categories and ontology relating these components to explaining causality or attempting predictive
8
[Glaser 1992] suggests credibility of a grounded theory can be evaluated through four criteria: fit, work, relevance and modifiability.
A substantive approach to validation indicates researchers need to document the chain of interpretations in order for others to judge
the trustworthiness of the meanings arrived at in the end [Angen 2000].
9
122
6
WTDSoft
generalizations among them. Besides, the adoption of the Greek prefix “meta” to characterize the theory and its
“meta-components” is in order to encompass the multidisciplinary attributes of the phenomena in study, providing
a way of thinking across the disciplines that compose the agile governance phenomena, trying to cover their broad
nature.
Other expected contributions are: (1) advance the state of the art of agile governance and some directions for
research and practice; (2) a detailed analysis about the theory structure; (3) a detailed analysis about the theory
behavior in different scenarios, considering the exploration of its properties, such as: generalization, causality,
explanation and prediction; (4) a detailed analysis about the theory comparison to extant theory to further elaborate
the theory proposed; (5) a detailed description of the methodological approach and process adopted for theory’s
development; (6) a scientific approach that can help researchers and practitioners to advance methodology for
combining diverse study types, as well quantitative and qualitative research. This approach can inspire researchers
and practitioners in future qualitative researches.
The authors believe that not only Information System area or software development organizations, but also whole
the IT industry will benefit from the results of this research. In fact, improving the competitiveness of governments
and companies through the improvement of their governance and management shall result in significant economic
returns. In a broader context, it will help any kind of organization to deliver value faster, better, and cheaper to the
business.
Acknowledgment
The authors acknowledge to CAPES, Brazil’s Science without Borders Program and CNPq by the research support. We are grateful to
Miguel Jiménez Monasor (University of Limerick, Ireland), Dr. Aurora Vizcaíno Barceló (Universidad de Castilla-La Mancha, Spain)
for having kindly provided their study design as a reference and give many valuable feedbacks about this issue. Special thanks to Dr.
Alberto Avritzer (Siemens, USA), Dr. John Noll (University of Limerick, Ireland), Dr. Tony Clear (Auckland University of Technology,
New Zealand), Dr. Sarah Beecham (University of Limerick, Ireland), Dr. Juho Mäkiö (Karlsruher Institute of Technology, Germany),
Dr. Julian Bass (Robert Gordon University, UK), Dr. Lars Bendix (Lund Institute of Technology, Sweden) and Siva Dorairaj (Victoria
University of Wellington, New Zealand) for their helpful feedback, suggestions and warnings about our original study design, during
the 8th IEEE International Conference on Global Software Engineering (ICGSE2013).
References
Adolph, S., Kruchten, P. and Hall, W. (jun 2012). Reconciling perspectives: A grounded theory of how people manage the process of software
development. Journal of Systems and Software, v. 85, n. 6, p. 1269–1286.
Ambler, S. W. and Lines, M. (2013). [S122] (GOP-E1-012) Disciplined Agile Delivery The Foundation for Scaling Agile. CrossTalk - The
Journal of Defense Software Engineering, n. December, p. 7–11.
Angen, M. J. (1 may 2000). Evaluating Interpretive Inquiry: Reviewing the Validity Debate and Opening the Dialogue. Qualitative Health
Research, v. 10, n. 3, p. 378–395.
Antón, A., McCracken, W. and Potts, C. (1994). Goal decomposition and scenario analysis in business process reengineering. Journal of
Advanced Information Systems, p. 94–104.
Banihashemi, S. and Liu, L. (2012). [S127] (SCO-E1-054) “LEAN GOVERNANCE”: A PARADIGM SHIFT IN INTER-ORGANIZATIONAL
RELATIONSHIPS (IORS) GOVERNANCE. In Proceedings for the 20th Annual Conference of the International Group for Lean
Construction.
Bank for International Settlements (2010). Third Basel Accord. http://www.bis.org/press/p100912.pdf, [accessed on Jul 22].
Bartenschlager, J. and Goeken, M. (2010). (POP-013) [S62] IT strategy Implementation Framework-Bridging Enterprise Architecture and IT
Governance. In Americas Conference on Information Systems (AMCIS) 2010 PROCEEDINGS.
BD (2013). Business Dictionary - definitions and meanings. http://www.businessdictionary.com/, [accessed on May 6].
Beck, K., Beedle, M., Bennekum, A. Van, et al. (2001). Manifesto for Agile Software Development. http://agilemanifesto.org/, [accessed on
May 1].
Bloom, A. (1991). The Republic of Plato. 2nd. ed. Harper Collins Publishers. p. 509
Brown, A. W., Ambler, S. and Royce, W. (may 2013). [S132] (ACM-E1-015) Agility at scale: economic governance, measured improvement,
and disciplined delivery. In Software Engineering (ICSE), 2013 35th International Conference on. . Ieee.
Cadbury, A. (1992). The Financial Aspects of Corporate Governance. In The Committee on the Financial Aspects of Corporate Governance,
UK.
Chen, R.-S., Sun, C.-M., Helms, M. M. and Jih, W.-J. (Kenny) (oct 2008). (SCD-0069) [S86] Aligning information technology and business
strategy with a dynamic capabilities perspective: A longitudinal study of a Taiwanese Semiconductor Company. International Journal of
Information Management, v. 28, n. 5, p. 366–378.
Cheng, T.-H., Jansen, S. and Remmers, M. (2009). (POP-015) [S63] Controlling and monitoring agile software development in three dutch
product software companies. In 2009 ICSE Workshop on Software Development Governance. . Ieee.
Congress of the United States of America (2002). AT THE SECOND SESSION. Sarbanes-Oxley Act of 2002. . 2002, p. 66.
Corbin, J. M. and Strauss, A. (1990). Grounded theory research: Procedures, canons, and evaluative criteria. Qualitative Sociology, v. 13, n. 1,
p. 3–21.
Creswell, J. W. (2002). Research design: Qualitative, quantitative, and mixed methods approaches. Second ed. p. 262
Creswell, J. W. (2012). Qualitative inquiry and research design: Choosing among five approaches. SAGE Publications. p. 395
Dorairaj, S., Noble, J. and Malik, P. (2011). Bridging cultural differences: A grounded theory perspective. Proceedings of the 4th India
Software …, p. 3–10.
Dubinsky, Y. and Kruchten, P. (2009). (POP-038) 2nd workshop on software development governance (SDG). 2009 31st International
Conference on Software Engineering - Companion Volume, p. 455–456.
Dubinsky, Y., Kruchten, P., Finkelstein, A., et al. (2010). (POP-047) [S74] Software Development Governance (SDG) Workshop. In ICSE ’10
Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering - Volume 2.
Dubinsky, Y., Ravid, S., Rafaeli, A. and Bar-Nahor, R. (aug 2011). Governance Mechanisms in Global Development Environments. 2011 IEEE
Sixth International Conference on Global Software Engineering, p. 6–14.
Dybå, T. and Dingsøyr, T. (aug 2008). Empirical studies of agile software development: A systematic review. Information and Software
Technology, v. 50, n. 9-10, p. 833–859.
123
7
WTDSoft
Edmondson, A. and McManus, S. (2007). Methodological fit in management field research. Academy of management review, v. 32, n. 4, p.
1155–1179.
Eisenhardt, K. M. (oct 1989). Building Theories from Case Study Research. The Academy of Management Review, v. 14, n. 4, p. 532.
Gallagher, K. P. and Worrell, J. L. (14 jul 2007). (SPL-0035) [S114] Organizing IT to promote agility. Information Technology and
Management, v. 9, n. 1, p. 71–88.
Gauch Jr, H. G. (2003). Scientific method in practice. First ed. Cambridge, UK: Cambridge University Press.
Gerke, L. and Ridley, G. (2009). Tailoring CobiT for Public Sector IT Audit: An Australian Case Study. In: Klinger, K.[Ed.]. Information
technology governance and service management: frameworks and adaptations. 1st. ed. Hershey: Information Science Reference (an imprint
of IGI Global). p. 101–125.
Glaser, B. G. (1992). Basics of Grounded Theory Analysis: Emergence vs. Forcing. Mill Valley, CA, USA: Sociology Press.
Glaser, B. G. (2002). Conceptualization: On theory and theorizing using grounded theory. International Journal of Qualitative …, v. 1, n. 2, p.
1–31.
Glaser, B. G. and Holton, J. (2007). Remodeling grounded theory. Historical Social Research/Historische …, n. 19, p. 47–68.
Gower, B. (2002). Scientific method: A historical and philosophical introduction. London and New York: Taylor & Francis e-Library. p. 288
Gregor, S. (2006). The nature of theory in information systems. MIS Quarterly, v. 30, n. 3, p. 611–642.
Groves, R., Jr, F. F. and Couper, M. (2013). Survey methodology. Wiley. com.
Heston, K. M. and Phifer, W. (2011). (SCO-001) [S90] The multiple quality models paradox: how much “best practice”is just enough? Journal
of Software Maintenance and Evolution, n. July 2009, p. 517–531.
IT Governance Institute (2001). Board briefing on IT governance. 2nd. ed. Rolling Meadows: IT Governance Institute. p. 66
Janssen, M. and Estevez, E. (jan 2013). [S147] (ISI-E1-009) Lean government and platform-based governance—Doing more with less.
Government Information Quarterly, v. 30, p. S1–S8.
Jebreen, I. (2012). Using Inductive Approach as Research Strategy in Requirements Engineering. International Journal of Computer and
Information Technology, v. 01, n. 02, p. 162–173.
Kitchenham, B. A., Charters, S., Budgen, D., et al. (2007). Guidelines for performing systematic literature reviews in software engineering.
Kruchten, P. (2011). (SCO-006) [S92] Contextualizing agile software development. Journal of Software: Evolution and Process, p. 11.
Li, J. (2010). (I3E-0147) [S47] A Study on the First Layer Assessment Variables of Logistics Quick Response Capability. In 2010 Second
International Conference on Multimedia and Information Technology. . Ieee.
Luftman, J., Lewis, P. and Oldach, S. (1993). Transforming the enterprise: The alignment of business and information technology strategies.
IBM Systems Journal, v. 32, n. 1, p. 24.
Luna, A. J. H. de O. (2009). MAnGve: A model for Agile Governance in IT. Master’s degree dissertation. Informatics Center, Federal
University of Pernambuco, Brazil.
Luna, A. J. H. de O., Costa, C. P., De Moura, H. P. and Novaes, M. A. (2010). (POP-009) [S60] Agile Governance in Information and
Communication Technologies: Shifting Paradigms. JISTEM Journal of Information Systems and Technology Management, v. 7, n. 2, p. 311–
334.
Luna, A. J. H. de O., Kruchten, P. and De Moura, H. P. (aug 2013). GAME: Governance for Agile Management of Enterprises: A Management
Model for Agile Governance. In 2013 IEEE 8th International Conference on Global Software Engineering Workshops. . Ieee.
Luna, A. J. H. de O., Kruchten, P., Pedrosa, M. L. G. do E., Neto, H. R. de A. and Moura, H. P. De (2014). Agile Governance: A Systematic
Literature Review. Under publishing process,
MAnGve (2009). MAnGve.org - Portal of the Movement for fostering Agile Governance. http://www.mangve.org/, [accessed on May 6].
Marconi, M. de A. and Lakatos, E. M. (2003). Fundamentos de Metodologia Científica. Fifth ed. São Paulo: Editora Atlas S. A. p. 310
Matt, D. T. (2007). (I3E-0125) [S43] Design of changeable assembly systems-a complexity theory based approach. In IEEE Industrial
Engineering and Engineering Management.
Mendel, T. (2004). ITIL’s Final Breakthrough: From “What” to “How.”CSO Online, p. 1–3.
Monasor, M., Vizcaíno, A., Piattini, M., Noll, J. and Beecham, S. (2013). Simulating Global Software Development Processes for Use in
Education: A Feasibility Study. 20th European Conference, EuroSPI. Dundalk, Ireland: Springer. p. 36–47.
Noblit, G. and Hare, R. (1988). Meta-ethnography: Synthesizing qualitative studies. v. 11p. 17
OED (2013). Oxford English Dictionary. http://oxforddictionaries.com, [accessed on May 30].
Pandit, N. (1996). The creation of theory: A recent application of the grounded theory method. The qualitative report, p. 1–13.
Qumer, A. (2007). (POP-001) [S54] Defining an Integrated Agile Governance for Large Agile Software Development Environments: A
Systematic Review and Analysis. In XP’07 Proceedings of the 8th international conference on Agile processes in software engineering and
extreme programming.
Qumer, A. and Henderson-Sellers, B. (nov 2008). (POP-054) [S75] A framework to support the evaluation, adoption and improvement of agile
methods in practice. Journal of Systems and Software, v. 81, n. 11, p. 1899–1919.
Radnor, Z. and Johnston, R. (nov 2013). [S162] (SCO-E1-015) Lean in UK Government: internal efficiency or customer service? Production
Planning & Control: The Management of Operations, v. 24, n. 10-11, p. 903–915.
Ribeiro, L. and Barata, J. (2011). (ACM-0093) [S10] Re-thinking diagnosis for future automation systems: An analysis of current diagnostic
practices and their applicability in emerging IT based production paradigms. Computers in Industry, v. 62, n. 7, p. 639–659.
Roosmalen, M. W. (Matthijs) Van and Hoppenbrouwers, S. J. B. A. (Stijn) (2008). (POP-058) [S76] Supporting Corporate Governance with
Enterprise Architecture and Business Rule Management: A Synthesis of Stability and Agility. In Proceedings of the International Workshop
on Regulations Modelling and Deployment (ReMoD’08) held in conjunction with the CAiSE'08 Conference.
Royce, W. and Cantor, M. (2013). [S163] (I3E-E1-005) Economic Governance of Software Delivery. IEEE Software, v. PP, n. 99, p. 1–1.
Schuetzenmeister, F. (2010). University research management: An exploratory literature review. n. January, p. 1–32.
Strauss, A. and Corbin, J. M. (1998). Basics of Qualitative Research: Techniques and Procedures for Developing Grounded Theory. SAGE
Publications.
Suddaby, R. (2006). From the editors: What grounded theory is not. Academy of management journal, v. 49, n. 4, p. 633–642.
Sun, Y., Zhang, Z. and Valota, O. (2005). (I3E-0024) [S28] A Methodology to form agile strategies in manufacturing organisations. In
Proceedings. 2005 IEEE International Engineering Management Conference, 2005. . Ieee.
Tallon, P. P. (2008). (SCO-090) [S106] Inside the adaptive enterprise: an information technology capabilities perspective on business process
agility. Information Technology and Management, v. 9, n. 123, p. 21–36.
Thomsett, R. (2013). The Five Keys to Organizational Agility: From Agile to Agility. In Executive Report, Cutter Consortium.
Weill, P. and Ross, J. W. (2004). IT Governance: How Top Performers Manage IT Decision Rights for Superior Results. Harvard Business
School Publishing India Pvt. Limited.
Weingart, P. (2005). Impact of bibliometrics upon the science system: Inadvertent consequences? Scientometrics, v. 62, n. 1, p. 117–131.
124
8

WTDSoft 2014 - Instituto de Computação

Transcrição

Documentos relacionados

o problema mente-corpo através das abordagens psico

Teorema de Ptolomeu

Engenharia da Computação

Engenharia da Computação

separados por dois pontos – centralizados e sem

Congruência de triângulos I - MA13 - Unidade 2

EXAME DE QUALIFICAÇ ÃO (TEORIA ERG ÓDICA) (1) Teorema

Baixar Material Teórico

COQ-760 – Métodos Matemáticos em Engenharia Química I

BOLETIM INFORMATIVO DO PRODUTO

Análise do uso de diferentes bandas de cores na