Qualidade em Ecossistemas de Software:Um Mapeamento Sistemático

Iuri Andrade Carvalho1

1 Núcleo de Engenharia do ConhecimentoPrograma de Pós Graduação em Ciência da Computação

Departamento de Ciência da ComputaçãoInstituto de Ciências Exatas

Universidade Federal de Juiz de Fora (UFJF)Rua José Lourenço Kelmer, s/n - Juiz de Fora - MG - Brasil

iuri.carvalho@ice.ufjf.br

Resumo. Em constante adaptação, é comum o surgimento de novos con-ceitos dentro do domínio da engenharia de software. Um dos conceitos emdestaque atualmente é o de Ecossistema de Software (ECOS). Este surgiudentro do contexto de desenvolvimento distribuído de software, onde sãoreunidas empresas, tecnologias e produtos de software sobre uma mesmaplataforma. Uma questão que vem recebendo grande atenção na área deECOS é a qualidade. A qualidade dos produtos disponíveis, a qualidade daplataforma, assim como sua estrutura, saúde e prosperidade são caracte-rísticas de vital importância para garantir o sucesso de um ecossistema. Opresente trabalho apresenta um mapeamento sistemático com o intuito deanalisar a área de qualidade em ECOS e visualizar suas principais carac-terísticas.

Abstract. Constantly adapting, it is common the emergence of new con-cepts in the field of software engineering. One of the concepts highlightedis currently the Software Ecosystem (SECO). This came within the distri-buted software development environment, where are combined companies,technologies and software products on the same platform. One issue thathas received much attention in the SECO area is quality. The quality ofproducts available, the platform of quality as well as its structure, healthand prosperity are vitally important features to ensure the success of anecosystem.This paper presents a systematic mapping in order to analyzethe quality of SECO area and view its main features.

1. IntroduçãoNos últimos trinta anos, uma das práticas de engenharia de software que ga-

nhou grande atenção foi o reuso. A redução no custo de desenvolvimento, reduçãode retrabalho e ganho de tempo trazidos por esta prática colocou-a em evidência[Bosch, 2009]. Modelos de desenvolvimento, paradigmas de linguagens de progra-mação e outros princípios foram criados com a intenção de facilitar e difundir oreuso [Sommerville et al., 2008]. Este permitiu também a criação de abordagens dedesenvolvimento como as Linhas de Produtos de Software (LPS). Séries de produ-tos desenvolvidos a partir de uma arquitetura comum tornaram-se uma alternativa

interessante para organizações desenvolvedoras pela redução do tempo e, consequen-temente, do custo de desenvolvimento [Bosch and Bosch-Sijtsema, 2010].

Contudo, o cenário de desenvolvimento de software vem se alterando rapi-damente [Jansen, 2013]. Com a presença praticamente ubíqua dos softwares nocotidiano, é cada vez maior e mais urgente a demanda por soluções de softwareeficazes [Santos, 2016]. Neste cenário e com o surgimento de outras abordagens dedesenvolvimento como o Desenvolvimento Distribuído de Software (DDS), apenasmanter uma arquitetura central não foi o bastante para algumas empresas desen-volvedoras. Estas abriram suas arquiteturas para a colaboração de desenvolvedoresexternos [Bosch, 2009]. Surgiu assim um novo conceito de desenvolvimento, ondevárias soluções de software, empresas e desenvolvedores aderem à uma plataformacomum. Este conceito foi denominado Ecossistema de Sofware (ECOS) [Jansen,2013].

Para as empresas mantenedoras de plataformas, existem diversas vantagens.O aumento da abrangência de suas plataformas, atingindo um número maior deusuários contemplados por soluções de software incorporadas a estas, deve ser des-tacado. Também, a redução de custos com pesquisa e desenvolvimento, uma vez quediversas soluções de software novas são desenvolvidas por empresas externas [Bosch,2009].

Contudo, o cenário criado pelos ECOSs traz novos desafios. Dentre estes,pode-se destacar a garantia da qualidade dos produtos e da plataforma de soft-ware componentes de um ECOS. A independência dos desenvolvedores externos,assim como os próprios atributos da plataforma podem influenciar na qualidadedo conjunto. Além disto, pela complexidade do cenário, a garantia de qualidadeno contexto de ECOS tem suas particularidades [Santos et al., 2014]. Diferente dodesenvolvimento tradicional, a empresa mantenedora da plataforma do ECOS, deno-minada Keystone, não tem total controle sobre os processos e modelos de desenvol-vimento utilizados pelas empresas externas. Desta forma, a Keystone não consegueefetuar diretamente a garantia da qualidade dos produtos desenvolvidos sobre suaplataforma [Santos et al., 2014]. Algumas Keystones enrijecem a distribuição des-tes produtos, fazendo um profundo controle de qualidade antes de disponibilizá-los.Porém, certas empresas evitam desenvolver nestas plataformas devido à dificuldadede disponibilização de seus produtos [Jansen, 2013].

Além dos padrões normais de qualidade observados em produtos de software,a saber qualidade de produto e qualidade de processo, existem outras dimensões dequalidade a serem observadas no contexto de ECOS. Algumas destas tem um enfoquevoltado as plataformas, como os conceitos de saúde e prosperidade de ECOS [Santoset al., 2014].

Na literatura existem alguns modelos que auxiliam a garantia da qualidadepara os produtos e a plataforma que compõem um ECOSs. Estes modelos pro-põem algumas iniciativas e padrões para abordar as diferentes visões de qualidadeque são provenientes dos ECOSs. Manikas [2016] apresenta um estudo longitudinal,onde diversas áreas envolvidas no contexto de ECOS são apresentadas e seus prin-cipais trabalhos citados. Dentre estes, foram citados cinco trabalhos que abordam

diretamente o tratamento da qualidade em ECOS.Diante deste cenário, foi proposto efetuar um mapeamento sistemático da

literatura específico para a área de qualidade em ECOS para mensurar a direçãodas pesquisas efetuadas na área, encontrar o estado da arte e detectar possíveisdeficiências e necessidades de pesquisa.

Este artigo está estruturado da seguinte forma. A seção dois apresenta aforma de execução do mapeamento sistemático. A seção três apresenta os resulta-dos obtidos. A seção quatro apresenta um breve relato dos trabalhos relacionados,encontrados durante o mapeamento. Por fim, a seção cinco apresenta as considera-ções finais, ameaças a validade deste estudo, e trabalhos futuros.

2. Mapeamento SistemáticoBasear as respostas das questões de pesquisa em evidências é uma abordagem

importante para efetividade dos resultados obtidos. Por este fato, Kitchenham [2004]apresentou o paradigma denominado engenharia de software baseada em evidências.O princípio deste paradigma é responder as questões de pesquisa dos trabalhosdesenvolvidos, com base em evidências encontradas na literatura.[Kitchenham et al.,2004].

Neste contexto, foram apresentadas duas abordagens para busca de evidên-cias: o mapeamento sistemático e a Revisão Sistemática da Literatura (RSL). Omapeamento sistemático busca avaliar a área de interesse, respondendo questõesgerais de pesquisa. O intuito é de detectar as principais abordagens presentes naliteratura para tratar esta área. Já a RSL busca responder questões de pesquisaespecíficas, efetuar comparações entre abordagens da área de interesse e avaliar aqualidade das pesquisas divulgadas [Kitchenham, 2010].

Desta forma, foi proposto efetuar um mapeamento sistemático da literatura,para identificar as principais tendências, o estado da arte, e os principais estudospara tratar a qualidade no contexto de ECOSs. Para executar o mapeamento, foramutilizadas três fases: planejamento, condução e relatório do estudo [Kitchenham,2004]. Para a execução de todo o processo de mapeamento, foi utilizada como apoioa ferramenta Parsifal1.

2.1. PlanejamentoA etapa de planejamento visa definir os objetivos a serem atingidos pela

pesquisa e o protocolo do mapeamento. Este tem o intuito de definir o métodode pesquisa e permitir a reprodutibilidade do estudo, além de reduzir riscos deocorrerem vieses nos resultados [Steinmacher et al., 2013].

O primeiro passo da construção do protocolo deste mapeamento foi a defi-nição das questões de mapeamento e as questões de pesquisa. Com o objetivo deencontrar as abordagens de qualidade em ECOS e a definição do estado da arte.

Foram apresentadas quatro questões de mapeamento:

∙ QM1: Qual a base de pesquisa mais relevante para a área?1Disponível em: https://parsif.al.

∙ QM2: Qual base com maior número de falsos positivos?∙ QM3: Como está a distribuição dos artigos durante os anos?∙ QM4: Qual ou quais autores mais expressivos na área?

Em seguida, foram propostas quatro questões de pesquisa:

∙ QP1: Quais metodologias de qualidade são utilizadas para ECOS?∙ QP2: Quais atributos de qualidade são mais frequentemente utilizados para

avaliar ECOS?∙ QP3: Qual o modelo mais utilizado na avaliação de qualidade em ECOS?∙ QP4: Qual o modelo de qualidade mais utilizado na avaliação da saúde e

prosperidade de ECOS?

Outro procedimento fundamental na construção do protocolo de mapeamentoé a definição dos parâmetros de: população, intervenção, comparação, saídas e con-texto. Estes parâmetros recebem o nome de PICOC [Petticrew and Roberts, 2008].Para este mapeamento, o PICOC foi definido como a seguir:

∙ População: a garantia da qualidade em ECOSs;∙ Intervenção: atributos e processos para qualidade ou utilização da percepção

dos atores ou avaliações de saúde e prosperidade;∙ Comparação: não foram definidas comparações;∙ Saídas: métodos, técnicas, abordagens, modelos, soluções, metamodelo, di-

mensões e outros tratamentos para qualidade;∙ Contexto: Ecossistemas de Software;

Definido o PICOC, são definidos os critérios de inclusão e exclusão dos artigosque serão pesquisados. Estes tem o objetivo de avaliar a relevância dos artigos queserão pesquisados e sua inclusão ou não nos resultados do mapeamento. Os critériosde inclusão definidos para este mapeamento foram:

∙ Publicações do ano de 2009 em diante;∙ Publicações definidas como do tipo artigo;∙ Publicações da área de ciência da computação;∙ Publicações com tema principal a qualidade em ECOS.

Os critérios de exclusão foram definidos como a seguir:

∙ Publicações anteriores ao ano de 2009;∙ Publicações que não são do tipo artigo;∙ Publicações que não são estudos primários;∙ Publicações que não são da área de ciência da computação;∙ Publicações que não são artigos abertos;∙ Publicações que não tenham com tema principal a qualidade em ECOS.

Para justificar a escolha dos critérios, pode-se citar alguns motivos. Como adefinição da área de ECOS foi efetuada por Bosch [2009], artigos com datas anteri-ores não abordariam o tema no contexto proposto. Publicações que não são do tipoartigo podem incluir diversos trabalhos como relatórios técnicos, anais de eventos eoutras publicações que não possuiriam o foco diretamente na área pesquisada. Da

mesma forma, estudos secundários, como RSL e outros mapeamentos, não contribui-riam com a pesquisa de maneira efetiva. Por fim, foram definidos apenas a presençade artigos abertos, pela necessidade de avaliação de seus conteúdos para inclusãoneste trabalho.

Em sequência, foi efetuada a seleção das bases de pesquisa. Foram seleciona-das bases que em seu acervo estivessem presentes publicações da área de ciência dacomputação. Outro critério de escolha utilizado foi a capacidade de uso de pesqui-sas avançadas, para aplicação da string de busca do mapeamento. Por fim, todas asbases selecionadas deveriam ser compatíveis com a ferramenta de apoio escolhida.Para detectar as bases relevantes, foram utilizadas como exemplo algumas das basesapresentadas por Manikas [2016], as quais já apresentavam os requisitos estipulados.As bases escolhidas estão apresentadas a seguir.

∙ ACM Digital Library (http://dl.acm.org/)∙ IEEEXplorer (http://ieeexplore.ieee.org)∙ ScienceDirect (http://www.sciencedirect.com/)∙ Scopus (https://www.scopus.com)∙ Web of Science (http://apps.webofknowledge.com/)

Com as bases definidas, o passo seguinte é a definição da string de busca.Para isto, foi utilizado os itens que compõem o PICOC para a retirada das palavrase expressões mais relevantes. Esta atividade tem a finalidade de encontrar o melhorconjunto de palavras, as quais são relacionadas por operadores lógicos. Este conjuntoforma a string de busca, que tem por objetivo fazer com que as bases forneçam osestudos mais aderentes ao contexto da pesquisa. Com resultado foi gerada a stringa seguir:

(quality OR "quality assurance") AND (perception OR perceptions OR attri-bute OR attributes OR process OR health OR evolvability) AND ("software ecosys-tem"OR "software ecosystems"OR SECO OR "software digital ecosystem"OR "soft-ware digital ecosystems")

Esta string é genérica, pois cada base possui sua própria sintaxe de busca.Para contemplar a pesquisa, esta string foi adaptada para cada base, mantendo suaestrutura básica. A Tabela 1 mostra as strings resultantes para cada base.

Um parâmetro importante para se avaliar a efetividade da busca é a definiçãode artigos de controle. Estes devem ser artigos reconhecidos na área pesquisada, eservem para avaliar se a busca está refletindo de maneira correta os objetivos propos-tos. Foram definidos cinco artigos de controle para este mapeamento. Estes foramapresentados por Manikas [2016] como artigos importantes da área de qualidade emECOS. Estes artigos são os seguintes:

∙ Schugerl et al. [2009]∙ Hmood et al. [2012]∙ Jansen [2013]∙ Stefanuto et al. [2011]∙ Franco-Bedoya et al. [2014]

Concluído o planejamento e construído o protocolo, a próxima fase a serexecutada é a condução do mapeamento

Tabela 1. String de busca por base.Base String de buscaACM (quality OR "quality assurance") AND (perception OR perceptions OR

attribute OR attributes OR process OR health OR evolvability) AND("software ecosystem"OR "software ecosystems"OR SECO OR "softwaredigital ecosystem"OR "software digital ecosystems")

IEEEXplorer (quality OR "quality assurance") AND (perception* OR attribute* ORprocess OR health OR evolvability) AND ("software ecosystem*"ORSECO OR "software digital ecosystem*")

ScienceDirect TITLE-ABSTR-KEY((quality OR "quality assurance") AND (percep-tion OR perceptions OR attribute OR attributes OR process OR he-alth OR evolvability) AND ("software ecosystem"OR "software ecosys-tems"OR SECO OR "software digital ecosystem"OR "software digitalecosystems"))

Scopus TITLE-ABS-KEY((quality OR "quality assurance") AND (perceptionOR perceptions OR attribute OR attributes OR process OR health ORevolvability) AND ("software ecosystem"OR "software ecosystems"ORSECO OR "software digital ecosystem"OR "software digital ecosys-tems"))

Web of Sci-ence

TS=((quality OR "quality assurance") AND ((perception* OR attri-bute* OR process OR health OR evolvability) AND ("software ecosys-tem*"OR SECO OR "software digital ecosystem*"))

2.2. Condução

A primeira atividade executada na condução do mapeamento foi a obtençãodos estudos. Para isso, cada base foi acessada e sua referente string de busca adap-tada foi executada. Os resultados obtidos foram salvos em um arquivo tipo bibitex,e importados para a ferramenta de apoio utilizada. As buscas foram executadasentre agosto e setembro de 2016. O número total de estudos localizados foi de 103.A Tabela 2 mostra a distribuição destes resultados pelas bases utilizadas.

Tabela 2. Número de artigos por base.Base Número de ArtigosACM 14IEEEXplorer 11ScienceDirect 8Scopus 55Web of Science 15

Dentre estes, foram localizados 29 artigos duplicados, excluídos automatica-mente pela ferramenta Parsifal, resultando em 74 artigos para aplicação dos critériosde inclusão e exclusão.

Em seguida, foi efetuada a leitura dos títulos e resumos dos artigos resultantese aplicados os critérios de inclusão e exclusão. Neste processo foram excluídos 51arquivos, restando 23 para análise integral do texto e aplicação dos critérios deinclusão e exclusão. Após esta etapa, foram excluídos 11 artigos, resultado em 12

artigos classificados como relevantes para a área de qualidade em ECOSs. A Figura1 mostra o fluxo do processo de condução do mapeamento.

Figura 1. Fluxo de condução do mapeamento.

A etapa de mapeamento visa capturar, selecionar e filtrar os artigos que seadequem à pesquisa, caracterizados pelos critérios de inclusão e exclusão. Obtidosos artigos, é possível efetuar a avaliação do panorama da área analisando os dadosdestes. Esta atividade é feita na terceira etapa do mapeamento, o relatório doestudo.

2.3. Relatório do EstudoPara representar o cenário geral do mapeamento podem ser descritas algumas

informações importantes. Primeiramente, pode-se analisar a distribuição do númerode publicações por base para responder à primeira questão de mapeamento (QM1):Qual a base de pesquisa mais relevante para a área? O gráfico presente na Figura 2demonstra a distribuição de artigos por base.

Figura 2. Distribuição de artigos por base.

O número de estudos aceitos em cada base demonstra a principal base deinteresse da área, onde o maior número de estudos é indexado. O gráfico presentena Figura 3 mostra este resultado.

Figura 3. Distribuição de artigos aceitos por base.

Comparando os gráficos presentes nas figuras 2 e 3, podemos fazer algumasobservações. Primeiramente, como base com maior relevância, podemos observarque a base Scopus teve o maior número de resultados tanto na busca inicial quantoem artigos aceitos. Em contrapartida, nesta base foi encontrado o maior número defalsos positivos, artigos encontrados pela string de busca mas que não foram aceitosdurante o processo. Este dado responde a segunda questão de mapeamento (QM2):Qual base com maior número de falsos positivos?

Outra observação que pode ser feita, é a do menor número de artigos en-contrado. Neste quesito, a base ScienceDirect obteve a menor representatividade.Obteve o menor número de estudos selecionados na busca inicial e não obteve ne-nhum artigo aceito no final do processo de seleção.

Para analisar a evolução da área, pode-se observar o gráfico presente naFigura 4. Nele, é apresentado o número de publicações por ano desde o ano base de2009. Com estes dados, pode-se responder à terceira questão de mapeamento (QM3):Como está a distribuição dos artigos durante os anos? Através desta observação, épossível visualizar uma preocupação crescente nos últimos quatro anos com o temaabordado. Resultado esperado, uma vez que o contexto de ECOS é cada vez maispresente dentre os ambientes de software e desenvolvimento atuais [Manikas, 2016].Contudo, entre os anos de 2011 e 2012 pode-se observar uma descontinuidade decrescimento, uma vez que o número de publicações é menor em 2012 que em 2011.Tal situação pode indicar a imaturidade da área na situação, onde os conceitosbásicos da área de ECOS necessitavam de maior solidificação.

Por fim, pode-se analisar a distribuição de publicações por autor, respon-dendo à quarta questão de mapeamento (QM4): Qual ou quais autores mais expres-sivos na área? Observando os resultados, pode-se detectar uma dispersão. Dentreos doze artigos selecionados, somente os artigos publicados por Alves and Pessôa[2010], Stefanuto et al. [2011] e Alves et al. [2015] possuem autor ou coautor emcomum. Os restantes são trabalhos desenvolvidos por autores distintos.

De acordo com as observações efetuadas, pode-se afirmar a existência deindícios para a tendência emergente da área. Ainda pouco explorada, situação de-monstrada pelo pequeno número de trabalhos existentes, a área é de vital impor-tância para estrutura da tendência também emergente dos ECOSs. Contudo, osdados apresentados nesta seção demonstram apenas o panorama geral da área. Os

Figura 4. Artigos por ano de publicação.

resultados de pesquisa obtidos serão apresentados na próxima seção.

3. Resultados ObtidosCom o processo de busca concluído e apresentadas as análises do relatório de

mapeamento, pode-se apresentar os resultados de pesquisa obtidos. Esses resultadossão inicialmente a resposta das perguntas de pesquisa apresentadas no protocolo.

A primeira questão de pesquisa apresentada (QP1) foi: quais metodologias dequalidade são utilizadas para ECOS? Como resposta podemos citar diversas meto-dologias distintas. Pode-se apresentar neste quesito modelos [Franco-Bedoya et al.,2014] [Lytra et al., 2015] [Schugerl et al., 2009] e metamodelos [Hmood et al., 2012][Lytra et al., 2015], assim como frameworks [Kajan et al., 2011] [Alves and Pessôa,2010] [Alves et al., 2015] e modelos de maturidade [Stefanuto et al., 2011] [Alvesand Pessôa, 2010]. Por fim, Mhamdia [2013] apresenta processos de medição aplica-dos a ECOS na perspectiva de qualidade, enquanto Frantz et al. [2015] apresenta aaplicação de um processo de tomada de decisão com o mesmo objetivo.

A segunda questão de pesquisa apresentada (QP2) foi: Quais atributos dequalidade são mais frequentemente utilizados para avaliar ECOS? Como resposta,pode-se citar os atributos listados por da Silva Amorim et al. [2014], a saber: co-municação, time de trabalho, tecnologia e integração. Estes atributos, que sãovinculados à plataforma de software do ECOS, são abordados também por Franco-Bedoya et al. [2014] e Jansen [2013]. Estes dois artigos também compartilham entresi outros atributos em comum, como sustentabilidade e abertura.

A terceira pergunta de pesquisa apresentada (QP3) foi: Qual modelo maisutilizado na avaliação de qualidade em ECOS? Para responder esta pergunta, foramanalisadas duas dimensões. A primeira, a recorrência do modelo nos artigos encon-trados. Neste quesito, pode-se destacar o modelo de maturidade apresentado porStefanuto et al. [2011], que é abordado direta ou indiretamente em três artigos. Asegunda dimensão analisada foi o número de citação dos artigos observados em suasbases de origem. Como resultado, pode-se apresentar os modelos de Franco-Bedoyaet al. [2014] e Schugerl et al. [2009] como modelos de qualidade mais citados, e nova-mente Stefanuto et al. [2011] como modelo de maturidade mais citado. O número decitações demonstra indícios do número de trabalhos que utilizam os modelos apre-sentados. Desta forma, pode-se citar os trabalhos listados acima como modelos mais

utilizados.Por fim, a quarta pergunta de pesquisa apresentada (QP4) foi: Qual o mo-

delo de qualidade mais utilizado na avaliação da saúde e prosperidade de ECOS?Como resposta, encontrou-se o modelo proposto por Franco-Bedoya et al. [2014],onde são tratadas diretamente dimensões de qualidade da plataforma do ECOS.Outros modelos que tratam a saúde e prosperidade de forma menos expressiva sãoencontrados em Schugerl et al. [2009] e Hmood et al. [2012].

Todas as perguntas propostas como questões de pesquisa foram respondidasde acordo com os artigos captados e seu conteúdo. Contudo, as respostas demons-tram que os trabalhos mais expressivos são os categorizados como artigos de controle.Para melhorar o entendimento do panorama da área e dos resultados obtidos, foifeita uma breve análise do conteúdo dos artigos encontrados neste mapeamento. Apróxima seção apresentará esta análise.

4. Trabalhos Relacionados

Esta seção visa apresentar uma breve visão dos artigos selecionados no pro-cesso de mapeamento, para ilustrar melhor o panorama da área.

4.1. Schugerl et al. [2009]

Este artigo apresenta uma arquitetura para análise semântica de requisitosnão funcionais de software no contexto de ECOS. Ao descrever requisitos não fun-cionais de software como atributos de qualidade, este trabalho indica a garantia daqualidade de produtos de software através da análise destes requisitos.

Além da garantia de qualidade, o trabalho citado ainda busca avaliar pelaevolução de artefatos de software a capacidade de evoluir, ou seja, a evolutibilidadedo produto de software através da análise semântica de seus artefatos.

Para isto, primeiramente o domínio dos requisitos não funcionais de softwarefoi modelado semanticamente utilizando ontologias. A modelagem de processos desoftware também foi contemplada, assim como os artefatos de software. Atravésdisso, a análise, acesso e avaliação dos atributos não funcionais de software pode serfeita.

As ontologias geradas para os processos descritos foram incorporadas a umaarquitetura denominada SE-Advisor. Esta utiliza serviços web do tipo REST paraacessar os repositórios e efetuar as análises. Os resultados são persistidos na base deconhecimento e podem ser utilizados para monitoramento dos atributos de qualidadedentro do ECOS.

As contribuições apresentadas no trabalho são duas. A primeira é a criaçãode um modelo semântico rico e unificado para obtenção de conhecimento sobre vá-rios recursos e componentes. A segunda é a arquitetura proposta, capaz de provera análise automatizada ou semi-automatizada de atributos não funcionais de arte-fatos de software, por meio da qual é possível efetuar a avaliação da qualidade deevolutibilidade do produto de software e, consequentemente, do ECOS.

4.2. Alves and Pessôa [2010]Este artigo descreve inicialmente o Brazilian Public Software (BPS). Um

ECOS público incentivado por órgãos governamentais. O principal intuito destetrabalho é detalhar seu portal de controle de qualidade, denominado 5CQualiBRe o Quality Framework, um framework para tratamento da qualidade dentro doBPS. A partir deste, busca-se aplicar modelos e normas de qualidade para atingir agarantia de qualidade dos produtos de software desenvolvidos dentro do BPS. Porfim, é descrito o modelo de maturidade desenvolvido para aplicar às empresas ecomunidades participantes deste ECOS.

4.3. Kajan et al. [2011]Este artigo apresenta uma arquitetura denominada BISA para testes em

ECOS. Esta arquitetura é definida sobre três princípios: negócios (B), inteligência(I) e serviços (S). De acordo com a definição de regras de negócio para testes, asbases de conhecimento definem as rotinas de teste necessárias através dos serviços.Para o controle da qualidade do processo, são utilizados cinco módulos: operaçõesde teste, produção em tempo real, produção off-line, simulação e análise off-line eum modulo de gerenciamento. Desta forma, é apresentado um framework de testese garantia de qualidade para os produtos de software que compõem um ECOS.

4.4. Stefanuto et al. [2011]Este trabalho é desenvolvido no contexto de um ECOS denominado Brazilian

Public Software (BPS). Stefanuto et al. [2011] denominam o BPS não somente comoum ECOS, mas como um ecossistema digital, pois integra componentes de software,aplicações, serviços online, dentre outros componentes tecnológicos. O BPS forneceum portal para desenvolvimento colaborativo de soluções. Este portal também provêpara os usuários funcionalidades como fórum e blog.

O intuito deste trabalho é avaliar a percepção de qualidade dos participantesdo BPS. Dentre os grupos de interesse, formados para desenvolvimento de soluçõespara o portal, são destacados dois. O primeiro, com foco em questões municipais,denominado 4CM Br, e outro com foco em questões de qualidade, denominado5CQualiBr. O trabalho citado tem seu foco neste último grupo, e visa avaliar apercepção dos usuários em torno das questões de qualidade abordadas por ele.

Além das percepções do usuário sobre a qualidade, Stefanuto et al. [2011]também apresentam um modelo de maturidade para as comunidades componentesdo BPS. Este modelo é semelhante a outros modelos de maturidade encontradosna literatura, como o CMMI. É dividido em cinco níveis. Cada nível avalia o graude conhecimento e maturidade das comunidades de desenvolvimento relacionados adeterminados atributos. Dentre estes pode-se citar: infraestrutura funcional, regrase guias para definição de qualidade de artefatos, definição de projetos de desenvol-vimento, dentre outros.

Para avaliar as percepções dos colaboradores do ECOS, foram aplicadas en-trevistas nos lideres de comunidades de desenvolvimento. Os resultados indicam queestes líderes tendem a perceber o BPS apenas como um mecanismo de repositórioe publicidade, e não como um ambiente de produção colaborativa. Em acréscimo,

os usuários ainda apontaram considerar a infraestrutura do BPS informal, limitadae antiquada. Tais resultados demonstram a necessidade da formalização das ativi-dades dentro do BPS. Diante deste cenário, Stefanuto et al. [2011] mostram que oBPS se encontra no nível II de maturidade, havendo ainda grandes dificuldades aserem superadas para alcançar mais maturidade para o ecossistema BPS.

4.5. Hmood et al. [2012]O trabalho apresentado por Hmood et al. [2012] fornece um metamodelo

semântico para suportar tal necessidade. Inicialmente, foi efetuada a formalizaçãodos modelos de qualidade. Esta etapa proporcionou o desenvolvimento de umaontologia que, através da estrutura do modelo, é capaz de definir seu reuso emoutros processos de desenvolvimento. Outra ontologia foi desenvolvida, com o foconas etapas do processo desenvolvimento e suas atividades de medição da qualidade.Desta forma, o modelo é capaz de definir semanticamente cada atividade de medidade qualidade necessária em cada etapa do desenvolvimento.

As ontologias desenvolvidas foram incluídas em um metamodelo, denominadoSE-EQUAM, capaz de transformar um domínio de desenvolvimento sintático paraum domínio semântico. Consequentemente, a evolução dos processos, assim como oreuso, são viabilizados.

4.6. Mhamdia [2013]Este trabalho apresenta a avaliação de qualidade de um ECOS através da

perspectiva de seus usuários. Através de um survey, foram coletadas informaçõessobre produtividade, robustez e satisfação dos atores envolvidos no ECOS. Nasperguntas aplicadas, buscou-se captar dos atores sua perspetiva sobre o ambiente aoqual o indivíduo estava inserido, assim como suas noções de saúde e prosperidade doECOS, bem como noções de garantia de qualidade, modelos de maturidade e outrosconhecimentos necessários. Ao final, são apresentadas análises estatísticas para adefinição das dimensões iniciais apresentadas para categorizar a saúde e prosperidadedo ECOS avaliado.

4.7. Jansen [2013]Este trabalho tem como foco principal os atributos de qualidade existentes

nas plataformas de software e a caracterização destas. Através de um estudo decaso, Jansen [2013] buscou confirmar duas hipóteses. A primeira se refere aos ex-tensores de plataforma, empresas e desenvolvedores externos que desenvolvem novasfuncionalidades para esta, tem grandes problemas de arquitetura ao selecionar umaplataforma. A segunda diz respeito à arquitetura da plataforma influencia o com-portamento do desenvolvimento dos extensores de plataforma e influencia o apoiofornecido pela própria plataforma do ECOS.

Neste estudo, Jansen [2013] apresenta a Tabela 3, contendo os principaisatributos observados nas plataformas do ponto de vista dos desenvolvedores. Estesatributos foram definidos como principais motivos de escolha das plataformas.

Nesta análise, a primeira hipótese foi rejeitada. Como mostra a Tabela 3,os atributos utilizados para a seleção das plataformas não são inerentes às suas

Figura 5. Atributos de seleção das plataformas [Jansen, 2013]

arquiteturas. Assim, os desenvolvedores não veem a arquitetura da plataforma comoimpedimento ou encorajamento para sua escolha.

A segunda hipóte foi aceita. Foi demonstrado que vários atributos de qua-lidade influenciam o comportamento dos desenvolvedores significantemente, tantopositiva como negativamente.

Assim, Jansen [2013] apontou grande influência da qualidade diretamente nodesempenho do desenvolvimento. Portanto, a necessidade de medida dos atributosde qualidade por parte das plataformas componentes de ECOSs foi evidenciada.

4.8. da Silva Amorim et al. [2014]

Este trabalho busca avaliar a flexibilidade em arquiteturas de ECOSs. Dentreos aspectos listados como influentes para os atributos de qualidade foram citadosdois: aspectos de negócios e técnicos. Para a avaliação, foram aplicadas métricas evisões de flexibilidade, através de uma matriz de rastreabilidade entre os atributosde design da arquitetura do ECOS. Através destas métricas, foi possível rastrearcomo cada aspecto influencia nos atributos de qualidade, e definindo a garantia daqualidade através da melhoria da infraestrutura do ECOS.

4.9. Franco-Bedoya et al. [2014]

A partir de um ECOS denominado Open Source Software (OSS), este tra-balho define características de qualidade que são inerentes ao ECOS. Para elencarestas características, este trabalho iniciou-se através de uma RSL.

Com as características definidas, foi gerado o modelo denominado QuESo.Este modelo foi composto de dois tipos de elementos: características de qualidadee medições. As características de qualidade correspondem aos atributos de softwarerelevantes para avaliação. Estas são organizadas através de uma hierarquia, divididaem dimensões. As dimensões são: a plataforma do ECOS, a comunidade componentedeste e sua rede de elementos. As dimensões são divididas em características e estas,por sua vez, são divididas em subcaracterísticas. A Figura 6 ilustra o modelo QuESo.

Para exemplificar as medidas componentes do modelo pode-se citar a sub-características tamanho, integrante da característica capacidade de manutenção, dadimensão qualidade da comunidade. Tal subcaracterísticas pode ser mensuradaatravés do número de contribuintes do ECOS, número de membros, número de erroscorrigidos dentre outros.

Observando o modelo, pode-se visualizar características como sustentabili-dade, capacidade de manutenção, dentre outras. Estas características são impor-tantes para definição de saúde e prosperidade do ECOS. Desta forma, o modeloproposto auxilia na garantia destas dimensões de qualidade, inerentes aos ECOSs.

Figura 6. Modelo de qualidade QuESo Franco-Bedoya et al. [2014]

4.10. Lytra et al. [2015]Este artigo apresenta uma abordagem para tomada de decisões na definição

de dimensões em arquiteturas de ECOSs. Através de um metamodelo, definiçõesexecutadas podem ser reutilizadas para garantir a repetição dos mesmos atributoscontemplados em situações anteriores. Para automatizar o processo, foi criado umprotótipo contendo o metamodelo proposto, e efetuado um estudo de caso aplicandoa ferramenta em um ECOS de smart cities.

4.11. Frantz et al. [2015]Este trabalho apresenta a aplicação de um modelo denominado Markov para

melhoria de integrações de software no domínio de ECOS. A partir da modelagemdos processos efetuada pelo Markov, estes podem ser agilizados, evitando gargalos,diminuindo custo, tempo de desenvolvimento e riscos agregados. Em acréscimo,as propriedades não funcionais são validadas no ambiente de integração, efetuandoassim a garantia da qualidade dos produtos de software produzidos dentro do ECOS.

4.12. Alves et al. [2015]O objetivo deste artigo é desenvolver um framework para conduzir a produção

de software no domínio de ECOS e avaliar a qualidade dos produtos desenvolvidos.Aplicando os princípios do framework, o desenvolvimento de software no domíniodo ECOS BPS demonstrou surtir efeito, em conjunto com seu portal de incentivoàs práticas de qualidade. Em acréscimo, este artigo apresenta a evolução do mo-delo de maturidade proposto para o BPS e suas contribuições para a melhoria dodesempenho das comunidades componentes do ECOS e suas produções.

4.13. Quadro ComparativoAnalisando o conteúdo dos trabalhos relatados, e selecionando suas principais

características, principais temas abordados e perspectivas de tratamento da quali-

dade, foi possível gerar um quadro comparativo. Este quadro está demonstrado naTabela 3.

Tabela 3. Quadro comparativo dos trabalhos relacionados.Artigo Modelo de

QualidadeModelo deMaturidade

Arquitetura Atributosde Produto

Atributosde Plata-forma

Saúde eProsperi-dade deECOS

Schugerl et al. [2009] X X X XAlves and Pessôa [2010] X X XKajan et al. [2011] X X XStefanuto et al. [2011] X XHmood et al. [2012] X X XMhamdia [2013] X XJansen [2013] Xda Silva Amorim et al. [2014] X XFranco-Bedoya et al. [2014] X X XLytra et al. [2015] X X XFrantz et al. [2015] X XAlves et al. [2015] X X X

5. Considerações FinaisA prática do reuso causou mudanças profundas na engenharia de software.

As facilidades da utilização de componentes de software já testados e funcionais alémde agilizar o processo reduz o custo de desenvolvimento e o risco de retrabalho. Talsituação expandiu os limites das organizações de desenvolvimento que, juntamentecom a globalização, gerou ambientes de desenvolvimento colaborativo e distribuídode software.

Neste novo cenário, surgiram também os Ecossistemas de Software. Estes setornaram uma alternativa interessante para as empresas, onde plataformas de soft-ware foram disponibilizadas para desenvolvimento externos. Tal situação aumentao alcance das empresas mantenedoras de plataforma, causando a redução de custoscom pesquisa e desenvolvimento por parte destas, denominadas Keystones.

Como em diversas realidade de produção e desenvolvimento, a preocupa-ção com a qualidade também é presente no contexto dos ECOSs. Usuários cadavez mais exigentes, assim como a necessidade de novas funcionalidades surgindofrequentemente, colocam esta preocupação em destaque. Além disso, a visão dequalidade neste contexto vai além do tradicional, abordando conceitos como saúde eprosperidade de ECOS. Tais conceitos são inerentes à realidade de desenvolvimentodistribuído de software gerada pelos ECOS.

A literatura nos mostra que já existem alguns modelos voltados ao trata-mento de qualidade no contexto de ECOSs. Para se avaliar de forma mais expressivatal panorama, foi proposto o presente mapeamento sistemático. Neste, foi possívelencontrar doze artigos que abordam a área, detectando nestes os principais mo-delos, atributos e tratamentos para a qualidade utilizados atualmente no contextode ECOS. Contudo, tais estudos ainda são escassos, além do número reduzido deautores envolvidos.. Esta situação dá indícios que há muito a ser explorado nestaimportante área.

5.1. Ameaças à validade

Como ameaças à validade deste mapeamento, pode-se citar primeiramente aslimitações apresentadas pela ferramenta de apoio. Como esta trabalha com arquivosdo tipo bibitex, as bases não compatíveis com este formato, como a Springer Link,foram excluídas. Tal escolha pode reduzir o número de artigos válidos. Contudo,esta ameaça pode ser mitigada pela presença da base SCOPUS, pois esta indexatrabalhos de outras bases, o que reduz esta ameaça.

Outra ameaça é a criação e adaptação da string de busca. Como as palavrase expressões são derivadas do PICOC, a correta construção deste é vital para aefetividade da pesquisa. Da mesma forma, a adaptação da string para cada basepode mudar o foco da pesquisa caso não seja feita de forma precisa. Para mitigaresta ameaça, foi solicitado a um especialista que avaliasse a string para validá-la emelhorar sua efetividade.

Por fim, a ultima ameaça é o número de pesquisadores. Este mapeamentofoi efetuado por um pesquisador apenas. Tal situação aumenta o risco de viesespresente no trabalho. Para mitigar esta ameaça, o pesquisador foi acompanhado porespecialistas e orientadores, reduzindo o risco de interpretações pessoais presentesno mapeamento.

5.2. Trabalhos futuros

Como trabalhos futuros, pode-se citar a evolução deste mapeamento parauma RSL, aumentando a efetividade dos resultados obtidos. Em acréscimo,pretende-se desenvolver uma arquitetura voltada a modelos semânticos, capaz deavaliar a qualidade dos componentes do ambiente de um ECOS.

ReferênciasA. M. Alves and M. Pessôa. Brazilian public software: beyond sharing. In Pro-

ceedings of the International Conference on Management of Emergent DigitalEcoSystems, pages 73–80. ACM, 2010.

A. M. Alves, M. Pessoa, and C. F. Salviano. Proposal for a framework for qualitymeasurement to the spb–brazilian public software. Business Process ManagementJournal, 21(1):100–125, 2015.

J. Bosch. From software product lines to software ecosystems. In Proceedingsof the 13th International Software Product Line Conference, SPLC ’09, pa-ges 111–119, Pittsburgh, PA, USA, 2009. Carnegie Mellon University. URLhttp://dl.acm.org/citation.cfm?id=1753235.1753251.

J. Bosch and P. M. Bosch-Sijtsema. Softwares product lines, global developmentand ecosystems: collaboration in software engineering. In Collaborative SoftwareEngineering, pages 77–92. Springer, 2010.

S. da Silva Amorim, J. D. McGregor, E. S. De Almeida, and C. von Flach G Cha-vez. Flexibility in ecosystem architectures. In Proceedings of the 2014 EuropeanConference on Software Architecture Workshops, page 14. ACM, 2014.

O. Franco-Bedoya, D. Ameller, D. Costal, and X. Franch. Queso a quality modelfor open source software ecosystems. In Software Engineering and Applications(ICSOFT-EA), 2014 9th International Conference on, pages 209–221, Aug 2014.

R. Z. Frantz, S. Sawicki, F. Roos-Frantz, I. Yevseyeva, and M. Emmerich. On usingmarkov decision processes to model integration solutions for disparate resources insoftware ecosystems. ICEIS 2015 - 17th International Conference on EnterpriseInformation Systems, Proceedings, 2:260–267, 2015.

A. Hmood, I. Keivanloo, and J. Rilling. Se-equam - an evolvable quality meta-model. In Computer Software and Applications Conference Workshops (COMP-SACW), 2012 IEEE 36th Annual, pages 334–339, July 2012. doi: 10.1109/COMP-SACW.2012.67.

S. Jansen. How quality attributes of software platform architectures influ-ence software ecosystems. In Proceedings of the 2013 International Workshopon Ecosystem Architectures, WEA 2013, pages 6–10, New York, NY, USA,2013. ACM. ISBN 978-1-4503-2314-7. doi: 10.1145/2501585.2501587. URLhttp://doi.acm.org/10.1145/2501585.2501587.

E. Kajan, L. Lazic, and Z. Maamar. Software engineering framework for digitalservice-oriented ecosystem. In in: 19th Telecommunications Forum (TELFOR),pages 1320–1323, 2011.

B. Kitchenham. Procedures for performing systematic reviews. Keele, UK, KeeleUniversity, 33(2004):1–26, 2004.

B. Kitchenham. What’s up with software metrics?–a preliminary mapping study.Journal of systems and software, 83(1):37–51, 2010.

B. A. Kitchenham, T. Dyba, and M. Jorgensen. Evidence-based software enginee-ring. In Proceedings of the 26th international conference on software engineering,pages 273–281. IEEE Computer Society, 2004.

I. Lytra, G. Engelbrecht, D. Schall, and U. Zdun. Reusable architectural decisionmodels for quality-driven decision support: A case study from a smart cities soft-ware ecosystem. In Proceedings of the Third International Workshop on SoftwareEngineering for Systems-of-Systems, pages 37–43. IEEE Press, 2015.

K. Manikas. Revisiting software ecosystems research: A longitudinal li-terature study. Journal of Systems and Software, 117:84 – 103, 2016.ISSN 0164-1212. doi: http://dx.doi.org/10.1016/j.jss.2016.02.003. URLhttp://www.sciencedirect.com/science/article/pii/S0164121216000406.

A. B. H. S. Mhamdia. Performance measurement practices in software ecosystem.International Journal of Productivity and Performance Management, 62(5):514–533, 2013.

M. Petticrew and H. Roberts. Systematic reviews in the social sciences: A practicalguide. John Wiley & Sons, 2008.

R. Santos. MANAGING AND MONITORING SOFTWARE ECOSYSTEM TOSUPPORT DEMAND AND SOLUTION ANALYSIS. PhD thesis, UniversidadeFederal do Rio de Janeiro, 2016.

R. Santos, G. Valença, D. Viana, B. Estácio, A. Fontãoo, S. Marczak, C. Werner,C. Alves, T. Conte, and R. Prikladnicki. Qualidade em ecossistemas de software:Desafios e oportunidades de pesquisa. In Proceedings of VIII Workshop on Distri-buted Software Development, Software Ecosystems and Systems-of-Systems, pages41–44, 2014.

P. Schugerl, J. Rilling, R. Witte, and P. Charland. A quality perspective ofsoftware evolvability using semantic analysis. In Semantic Computing, 2009.

ICSC ’09. IEEE International Conference on, pages 420–427, Sept 2009. doi:10.1109/ICSC.2009.10.

I. Sommerville, S. S. S. Melnikoff, R. Arakaki, E. d. A. Bar-bosa, and K. Hirama. Engenharia de software. Pearson Pren-tice Hall, São Paulo, 2008. ISBN 9788588639287 8588639289. URLhttp://www.worldcat.org/search?qt=worldcat𝑜𝑟𝑔𝑎𝑙𝑙𝑞 = 9788588639287.

G. Stefanuto, M. Spiess, A. M. Alves, and P. F. D. Castro. Qua-lity in software digital ecosystems the users perceptions. In Procee-dings of the International Conference on Management of Emergent Digi-tal EcoSystems, MEDES ’11, pages 85–88, New York, NY, USA, 2011.ACM. ISBN 978-1-4503-1047-5. doi: 10.1145/2077489.2077504. URLhttp://doi.acm.org/10.1145/2077489.2077504.

I. Steinmacher, A. P. Chaves, and M. A. Gerosa. Awareness support in distribu-ted software development: A systematic review and mapping of the literature.Computer Supported Cooperative Work (CSCW), 22(2-3):113–158, 2013.