WDES - Instituto de Computação - Universidade Federal de Alagoas

Transcrição

Congresso Brasileiro de Software: Teoria e Prática
28 de setembro a 03 de outubro de 2014 – Maceió/AL
VIII Workshop de Desenvolvimento Distribuído de Software,
Ecossistemas de Software e Sistemas de Sistemas
WDES 2014
Anais
WDES
Volume 02
ISSN 2178-6097
Anais
WDES 2014
VIII Workshop de Desenvolvimento Distribuído de
Software, Ecossistemas de Software e Sistemas de
Sistemas
COORDENADORES DO COMITÊ DE PROGRAMA
Cláudia Werner - Universidade Federal do Rio de Janeiro (UFRJ)
Elisa Yumi Nakagawa - Universidade de São Paulo (USP)
Sabrina Marczak - Pontifícia Universidade Católica do Rio Grande do Sul (PUCRS)
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
WDES
PROCEEDINGS
Volume 02
ISSN 2178-6097
AutoSoft 2014
VIII Workshop de Desenvolvimento Distribuído de
Software, Ecossistemas de Software e Sistemas de
Sistemas
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
WDES
Autorizo a reprodução parcial ou total desta obra, para fins acadêmicos, desde que citada a fonte
4
WDES
Apresentação
Visando unir competências e promover a integração entre áreas de pesquisa
correlatas, o Workshop de Desenvolvimento Distribuído de Software (WDDS), em sua
oitava edição, amplia a sua abrangência, dando origem ao Workshop de
Desenvolvimento Distribuído de Software, Ecossistemas de Software e Sistemas de
Sistemas (WDES 2014). Esse evento constitui um fórum para apresentação e discussão
de resultados e experiências de pesquisadores e praticantes das áreas de
Desenvolvimento Distribuído de Software (DDS), Ecossistemas de Software (ECOS) e
Sistemas de Sistemas (SoS), visando a geração de conhecimento que possa viabilizar
projetos de sucesso nessas três áreas e/ou nas suas relações. Esse movimento
começou durante as discussões realizadas nas edições de 2012 e 2013 do WDDS, o que
resultou na publicação de artigos que relacionaram as áreas de pesquisa.
O Comitê Diretivo do WDES 2014 é constituído por três pesquisadores de cada uma
das três áreas envolvidas no workshop. Por sua vez, o Comitê de Programa do WDES
2014 é formado por 16 pesquisadores de instituições do Brasil (9) e do exterior (7),
com atuação e produção relevantes nas áreas de pesquisa envolvidas no workshop. Os
membros do Comitê de Programa conduziram um processo rigoroso de revisão, sendo
que cada artigo foi avaliado por pelo menos três membros. Além disso, visando
ampliar as discussões durante o workshop, esta edição conta também com artigos
convidados, escritos por especialistas das áreas.
É com satisfação que damos as boas-vindas aos autores e apresentadores de artigos,
da academia e da indústria. Também recebemos com grande prazer os demais
participantes do CBSoft 2014, que gostaríamos de convidar a tomar parte ativamente
das discussões e momentos de integração proporcionados pelo workshop.
Adicionalmente, gostaríamos de agradecer a todos os demais autores que
submeteram seus artigos, aos membros do Comitê Diretivo, Comitê de Programa e
Comitê de Organização, e aos organizadores e patrocinadores do CBSoft 2014 pelo
suporte na realização deste workshop.
Esta edição é organizada conjuntamente pela Universidade Federal do Rio de Janeiro
(COPPE/UFRJ), Universidade de São Paulo (ICMC/USP) e Pontifícia Universidade
Católica do Rio Grande do Sul (PUCRS), sob a coordenação das professoras Cláudia
Werner, Elisa Yumi Nakagawa e Sabrina Marczak, respectivamente. O Comitê de
Organização conta com o apoio dos doutorandos Rodrigo Pereira dos Santos, Lucas
Bueno Ruas de Oliveira, Marcelo Benites Gonçalves e Bernardo José Estácio. O evento
é realizado no Centro de Convenções Ruth Cardoso, em Maceió, Alagoas, no dia 28 de
setembro, em conjunto com o V Congresso Brasileiro de Software: Teoria e Prática
(CBSoft 2014).
Esperamos que tenham uma ótima estada em Maceió
Cláudia, Elisa e Sabrina
Organizadoras do WDES 2014
5
WDES
Comitês Técnicos / Program Committee
Comitê Diretivo / Steering Committee
Carina Frota Alves - Universidade Federal de Pernambuco (UFPE)
Eduardo Santana de Almeida - Universidade Federal da Bahia (UFBA)
Elisa Hatsue Moriya Huzita - Universidade Estadual de Maringá (UEM)
Flavio Oquendo - Université de Bretagne-Sud, France (UBS)
José Carlos Maldonado - Universidade de São Paulo (USP)
Renata Pontin de Mattos Fortes - Universidade de São Paulo (USP)
Comitê do programa / Program Committee
Vander Alves - Universidade de Brasília (UnB)
Jan Bosch - Chalmers University of Technology, United States of America
USAParis Avgeriou - University of Groningen, The Netherlands
Heitor Costa - Universidade Federal de Lavras (UFLA)
Daniela S. Cruzes - SINTEF, Norway
Carlos E. Cuesta - Rey Juan Carlos University, Spain
Arilo Claudio Dias-Neto - Universidade Federal do Amazonas (UFAM)
Khalil Drira - LAAS-CNRS, France
Fernando Figueira - Universidade Federal do Rio Grande do Norte (UFRN)
Slinger Jansen - Utrecht University, The Netherlands
Alexandre L'Erario - Universidade Federal Tecnológica do Paraná (UTFPR)
John Mcgregor - Clemson University, United States of America
Leonardo Murta - Universidade Federal Fluminense (UFF)
Rafael Prikladnicki - Pontifícia Universidade Católica do Rio Grande do Sul (PUCRS)
Tania Tait - Universidade Federal do Rio Grande do Norte (UFRN)
Guilherme Travassos - Universidade Federal do Rio de Janeiro (UFRJ)
Revisores Adicionais / Additinal Reviewers
Dênis Leonardo Zaniro - Universidade de São Paulo (USP)
6
WDES
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)
COORDENADORES DO WDES 2014
7
WDES
Índice / Table of Contents
Um Framework para Gerenciamento de Riscos em Projetos de
Desenvolvimento Distribuído de Software
Jefferson Barbosa, Ivaldir de Farias Junior, Sabrina Marczak, Rodrigo Santos e
Hermano Moura
9
On the Identification of Factors that Promote High-Performance
Projects in Distributed Development
Sabrina Marczak, Marcelo Perin, Rafael Prikladnicki e Christiano Ayub
17
SECOView: Uma Abordagem Baseada em Visões para Apoiar a
Governança de Ecossistemas de Software
Yuri Abreu, Rodrigo Santos, Benno Albert e Claudia Werner
25
Ecosystem Business Models and Architectures
John McGregor e Simone Amorim
33
Qualidade em Ecossistemas de Software: Desafios e Oportunidades
de Pesquisa
Rodrigo Santos, George Valença, Davi Viana, Bernado Estácio, Awdren
Fontão, Sabrina Marczak, Claudia Werner, Carina Alves, Tayana Conte e
Rafael Prikladnicki
41
Towards the Dynamic Evolution of Context-based Systems-ofSystems
Elisa Yumi Nakagawa, Rafael Capilla, Francisco Diaz e Flavio Oquendo
45
Towards the Evaluation of System-of-Systems Software
Architectures
Daniel Soares, Brauner Oliveira, Milena Guessi, Flavio Oquendo, Marcio
Eduardo Delamaro e Elisa Yumi Nakagawa
53
On the Relations between Systems-of-Systems and Software
Ecosystems
Rodrigo Santos, Marcelo Gonçalves, Elisa Yumi Nakagawa e Claudia Werner
58
8
WDES
Um Framework para Gestão de Riscos em Projetos de
Desenvolvimento Distribuído de Software
Jefferson Ferreira Barbosa¹, Ivaldir de Farias Junior¹, Sabrina Marczak²,
Rodrigo Pereira dos Santos³, Hermano Moura¹
¹Centro de Informática – Universidade Federal de Pernambuco (UFPE)
²FACIN – Pontifícia Universidade Católica de Porto Alegre (PUCRS)
³PESC/COPPE – Universidade Federal do Rio de Janeiro (UFRJ)
{jfb2, ihfj, hermano}@cin.upfe.br, [email protected],
[email protected]
Abstract. Risk management is considered a critical factor for Distributed Software
Development (DSD) projects since the lack of proper identification of the project’s risks
can determine its success or failure. This paper presents a framework for risk
management in DSD projects that uses agile practices. The framework has been defined
based in literature and has been preliminarily evaluated with about 30 software
professionals who work with distributed projects. Results from this preliminary
evaluation indicate that the framework contributes to DSD area.
Resumo. O gerenciamento de riscos é um dos fatores críticos para projetos de
Desenvolvimento Distribuído de Software (DDS) visto que a identificação de riscos
determina as incertezas que podem levar ao seu sucesso ou fracasso. Este artigo
apresenta um framework para a gestão de riscos em projetos DDS utilizando práticas
ágeis. O framework foi desenvolvido com base na literatura. Realizou-se uma avaliação
preliminar com aproximadamente 30 profissionais da área de TI que trabalham com
DDS. Os resultados indicam que o framework contribui para a área de DDS.
1. Introdução
O Desenvolvimento Distribuído de Software (DDS) tem atraído a atenção da indústria
nos últimos anos, levando organizações a mudarem a maneira como gerenciam seus
negócios em busca de menores custos, melhores profissionais, entre outras vantagens
(Audy & Prikladnicki, 2007). Projetos DDS trazem muitas vantagens, porém também
têm desafios, tais como a dificuldade de comunicação e a gestão de riscos, dentre outros
(Zanoni & Audy, 2003; Leme et al., 2007). Nestes projetos, os riscos tendem a ser
dinâmicos devido à multiplicidade dos vários aspectos, i.e., múltiplas localizações,
culturas, equipes, padrões e tecnologias (Mudumba & Lee, 2010).
Assim, frameworks, processos, boas práticas e ferramentas associadas à gestão
de riscos têm sido propostos para melhorar a identificação, análise, monitoramento e
controle de riscos no gerenciamento de projetos DDS e melhorar a qualidade do produto
de software desenvolvido (Persson et al., 2009). Nessa direção, este trabalho tem como
objetivo investigar a seguinte questão de pesquisa: “A concepção de um framework
composto por práticas ágeis pode auxiliar a gestão de riscos em projetos DDS?”
2. Gerenciamento de Riscos em DDS
Um risco é uma probabilidade de alguma circunstância adversa acontecer (Sommerville,
2007). O risco pode afetar planejamento, recursos financeiros, qualidade do processo e,
9
WDES
consequentemente, a qualidade do produto e do desempenho do projeto de software.
Por isso, a gestão dos riscos em projetos de software é muito importante, seja o projeto
co-localizado ou distribuído. A gestão deve contemplar os processos de identificação,
análise e resposta aos riscos do projeto para minimizar as consequências de eventos
negativos (Zanoni & Audy, 2003).
No DDS, a gestão de riscos recebe grande destaque pois pode levar um projeto
ao sucesso ou fracasso (Audy & Prikladnicki, 2007). Estes autores argumentam que
riscos podem ser percebidos de duas formas em projetos DDS: a primeira diz respeito
aos “fatores críticos de sucesso” de risco e a segunda foca na visão da “gestão de riscos”
como atividade crítica na organização para o sucesso destes projetos. Outros desafios
também foram desencadeados pela gestão de riscos em projetos DDS: tempo dedicado à
gestão propriamente dita; envolvimento dos stakeholders na identificação dos riscos; uso
de métodos para avaliação quantitativa de riscos; treinamento para a correta
identificação dos riscos; falta de um processo para essa gestão, adaptado à realidade da
organização; falta de um planejamento formal de resposta aos riscos; ausência de
incentivo à constante proatividade e comunicação; utilização de uma ferramenta de apoio
ao processo; manutenção de um histórico de riscos de projetos anteriores, entre outros
(Keshlaf & Hashim, 2000; Hossain et al., 2009; Persson et al., 2009).
Nesse contexto, o desenvolvimento ágil tem chamado atenção dos praticantes de
DDS por causa de sua flexibilidade com relação às frequentes tentativas aplicadas para
dinamizar a gestão do projeto de forma proativa (Hossain et al., 2009). As práticas ágeis
têm sido adotadas como forma de melhorar o desempenho de projetos distribuídos no
que tange especialmente a melhoria da comunicação, gestão de mudanças, riscos,
requisitos etc. (Šmite et al., 2010). Nesse sentido, uma visão clara da gestão de riscos
representa um grande desafio à aplicação dessas práticas para a gestão do projeto em
geral, bem como que seja realizada com base na perspectiva ágil (Hossain et al., 2009).
3. Trabalhos Relacionados
Keshlaf & Hashim (2000) definiram um modelo para gestão de riscos denominado
SoftRisk. Este modelo se baseia na ideia de documentação, utilização de dados históricos
e foco nos principais riscos com o objetivo de reduzir esforço e tempo na gestão e
mitigação desses riscos. Seus passos são: identificação dos riscos; probabilidade dos
riscos e estimativa de magnitude; documentação dos riscos; análise; priorização dos dez
principais riscos; monitoramento; controle; e execução de operação estatística. SoftRisk
trata a gestão de riscos em projetos com dispersão geográfica e em equipes virtuais.
Porém, trata de forma parcial a definição de papéis dos stakeholders nesta gestão. Por
fim, não discute questões impostas por diferenças culturais em DDS, o que é apontado
como uma limitação do modelo.
O Framework Integrativo conhecido como Geographically Distributed Software
Projects – GDSP (Persson et al., 2009) identificou áreas e fatores de risco envolvidos no
gerenciamento de projetos DDS. A contribuição desses autores foi elaborada a partir de
uma revisão sistemática da literatura, que sintetizou riscos e técnicas de resolução. As
áreas de risco identificadas foram: distribuição das tarefas, gerenciamento do
conhecimento, distribuição geográfica, estrutura de colaboração, distribuição cultural,
relacionamentos entre os stakeholders, infraestrutura de comunicação e configuração da
10
WDES
tecnologia. Esse framework trata o envolvimento dos stakeholders e os papéis que eles
têm na gestão de riscos de maneira superficial, ou seja, não existe uma sistematização da
identificação dos atores e suas atribuições/responsabilidades dentro do projeto.
Hossain et al. (2009) identificaram áreas e fatores de risco envolvidos no
gerenciamento de projetos DDS utilizando práticas de desenvolvimento ágil de software.
A contribuição de Hossain et al. (2009) veio de uma revisão sistemática da literatura
sobre o uso de práticas de Scrum em projetos DDS. Como resultado, foram identificados
desafios, áreas de risco, estratégias e práticas atuais para a mitigação desses riscos e, em
seguida, foi proposto um framework conceitual. Esse framework conceitual é formado
por dois componentes, classificados em: principais áreas de risco e estratégias atuais para
a redução desses riscos. Na visão dos autores, este framework precisa evoluir para
manter uma comunicação contínua, i.e., divulgação constante dos riscos do projeto, pois
esse é um fator crítico de sucesso.
A Tabela 1 traz uma síntese dos trabalhos relacionados. Os critérios de
comparação foram selecionados com base em (Ramesh et al., 2006), (Keshlaf & Riddle,
2010) e (Šmite et al., 2010). As abordagens analisadas trazem significantes resultados à
gestão de riscos em projetos DDS, porém ainda existem lacunas a serem tratadas. O
presente trabalho define o framework RADS para gestão de riscos em projetos DDS
como forma de preenchimento das lacunas não atendidas pelas abordagens apresentadas
nessa seção. RADS tem seu diferencial na utilização de práticas ágeis na gestão de
riscos, clara identificação dos atores envolvidos e premissa de que a gestão de riscos
precisa de uma comunicação contínua no decorrer do projeto, por meio de relatórios,
reuniões, dentre outros meios formais para as partes interessadas.
Tabela 1 – Comparação dos trabalhos relacionados
SoftRisk
(Keshlaf &
Hashim, 2000)
AP
N
AP
AP
N
Critérios
Contexto DDS
Utilização de práticas ágeis
Definição dos papéis/Envolvimento dos Stakeholders
Definição de papéis na gestão de risco
Comunicação contínua no projeto
GDSP-RM
(Persson et
al., 2009)
A
N
AP
AP
AP
Framework
Conceitual (Hossain
et al., 2009)
A
A
N
N
AP
A = Atende, AP = Atende parcialmente, N = Não atende
4. Metodologia
A pesquisa conduzida para a definição do framework foi organizada em quatro fases
(Figura 1). O procedimento para fundamentar a proposta do framework foi a realização
de uma revisão bibliográfica nas principais bibliotecas digitais na Fase 1 (i.e., IEEE,
ACM e Scopus). Na Fase 2, foi realizada uma pesquisa sobre os principais trabalhos
relacionados à questão de pesquisa. Baseado nos resultados dessas fases, na Fase 3,
definiu-se a versão inicial do framework. Finalmente, na Fase 4, executou-se um survey
com especialistas em DDS com experiência em projetos ágeis, com o objetivo de avaliar
se o mesmo pode auxiliar na gestão de riscos em projetos DDS, analisar a aplicabilidade
do framework em projetos reais e identificar oportunidades de melhoria em relação à sua
estrutura. O questionário do survey avaliou preliminarmente a versão inicial do
framework. O resultado desta avaliação é apresentado na Seção 6.
11
WDES
Figura 1 – Metodologia da Pesquisa
5. O Framework para Gestão de Riscos em Projetos de DDS
O framework RADS (Figura 2), acrônimo para “Risco, Ágil, Distribuído, Software”, foi
construído inicialmente a partir da literatura e posteriormente objeto de análise crítica de
especialistas em desenvolvimento ágil e DDS. Com a perspectiva de ser um framework
de fácil utilização, optou-se por não impor uma técnica mais adequada do que outra para
definir seus componentes. O RADS é composto por três áreas: i) gestão global de riscos,
ii) gestão de riscos em equipes distribuídas e iii) identificação dos atores na gestão de
riscos. Cada área é composta por subáreas e elementos, descritos na Tabela 2.
Figura 2 – Representação gráfica do framework RADS
O framework RADS utiliza práticas ágeis para o tratamento de riscos em DDS. O
RADS se inicia com a área de Gestão Global de Riscos, que busca consolidar todos os
riscos identificados inicialmente pelas equipes distribuídas do projeto (centralizar as
informações) e divulgar essas informações para as partes interessadas. Por sua vez, na
área de Gestão de Riscos em Equipes Distribuídas, busca-se realizar a identificação dos
riscos durante as iterações do projeto. Além disso, são contempladas a análise, mitigação
e aplicação das estratégias de riscos para o projeto em questão. Por fim, têm-se a área de
Identificação de Papéis na Gestão de Riscos, definidos pelo framework.
12
WDES
Tabela 2 – Descrição das áreas, subáreas e elementos do RADS
Área
Gestão Global
de Risco
Subárea
Reunião Global
Planejamento da
Sprint
Gestão de Risco
em Equipes
Distribuídas
Execução da
Sprint
Revisão da
Sprint
Identificação de
Papéis na
Gestão de Risco
-
Elemento
Descrição do Elemento
Reunião Global de
Consolidação
Consolidação global dos riscos identificados pelas equipes distribuídas. Esta reunião
tem a supervisão do Gerente Global de Riscos.
Reunião Global de
Divulgação
Divulgação dos riscos identificados e priorizados para a próxima sprint para as
equipes geograficamente dispersas.
Identificação dos
Stakeholders
Identificação e participação dos vários stakeholders envolvidos no processo de gestão
de riscos independente da dispersão geográfica desse stakeholder.
Identificação dos
Riscos
Processo de identificação dos riscos por parte da equipe distribuída.
(Boehm, 1991; Keshlaf & Hashim, 2000;
Hossain et al., 2009; PMI, 2013)
Processo de priorização da lista criada no passo de Identificação de Riscos.
(Boehm, 1991; Keshlaf & Hashim, 2000;
PMI, 2013)
Análise dos
Riscos
Referências
(Persson et al., 2009)
(Nyfjord & Kajko-Mattsson, 2007;
Persson et al., 2009; PMI, 2013)
Planejamento de
Resposta aos Riscos
Processo de definição, documentação e inclusão no backlog da sprint ou backlog do
projeto das ações necessárias para aceitação, transferência e mitigação dos riscos
identificados e priorizados nos passos anteriores.
(Boehm, 1991; Ebert et al., 2008;
Hossain et. al., 2009);
Aplicação das Estratégias
de Mitigação dos Riscos
Execução das estratégias de mitigação de riscos alocadas para as equipes distribuídas
dentro da execução da sprint.
(Nelson et al., 2008)
Identificação de
Novos Riscos
Processo de revisão da lista de riscos após a execução de uma sprint, pois novos
riscos podem surgir.
(Boehm, 1991; Nelson et al., 2008)
Status do Plano de
Mitigação dos Riscos
Neste passo, é apresentado o status do plano de mitigação de riscos, informando se
houve necessidade de execução do plano e atualização de estratégias de mitigação
para novos riscos identificados na revisão da sprint.
Gerente Global do Projeto
Papel responsável pela coordenação da gestão de riscos no nível global, ou seja, de
todo o projeto.
(Nelson et al., 2008;
Ribeiro & Gusmão, 2008)
Gerente Global de Riscos
Papel responsável por gerenciar as atividades de priorização, consolidação e
divulgação dos riscos identificados pelas equipes para o Gerente Global do Projeto.
(Nelson et al., 2008;
Ribeiro & Gusmão, 2008)
Analista de Riscos
Equipes Distribuídas
Cliente
Papel responsável por gerenciar as atividades de risco das equipes.
Equipes responsáveis pela identificação de stakeholders, de riscos, análise dos riscos,
e documentação das estratégias de mitigação das equipes distribuídas.
Responsável por fazer a validação e priorização dos riscos.
13
(Nyfjord & Kajko-Mattsson, 2007;
Persson et al., 2009; PMI, 2013)
Melhoria sugerida pelos especialistas
após aplicação do questionário.
WDES
6. Avaliação Preliminar do Framework RADS
Realizou-se um survey com o objetivo de avaliar, com profissionais da área de TI com
experiência em projetos DDS e em projetos ágeis, se o framework atende ao objetivo de
auxiliar na gestão de riscos em projetos DDS. Avaliou-se ainda o uso de práticas ágeis
para potencializar a gestão de riscos neste tipo de projeto, dado que o framework é
composto por este tipo de práticas. O questionário de avaliação online foi enviado para
71 pesquisadores que pertencem à comunidade do Workshop de Desenvolvimento
Distribuído de Software (WDDS, 2013) e para departamentos de TI dos seguintes
órgãos públicos, dado o acesso dos autores: Ministério Público da Paraíba, Tribunal de
Justiça da Paraíba, Tribunal Regional do Trabalho da Paraíba e Tribunal Regional
Eleitoral da Paraíba; Conselho Nacional do Ministério Público de Brasília; Companhia de
Processamento de Dados da Paraíba; e organizações privadas: Unimed (Paraíba e do Rio
de Janeiro), Incorptech de Pernambuco e Apple Inc. (EUA). Obteve-se um total de 28
respostas (39,4%). O questionário ficou disponível por duas semanas em novembro de
2013. O número de respondentes superou a média de respostas esperada por Marconi &
Lakatos (2003), que é de 25% de devoluções em questionários aplicados online.
Os profissionais que responderam ao questionário, entre suas características, têm
30 anos de idade em média; são gerentes de projetos e líderes de escritório de projeto
(PMO); possuem em média quatro anos de experiência em DDS; as instituições onde
trabalham adotam o PMBOK como conjunto de boas práticas no gerenciamento de
projetos; e eles têm experiência em média de um ano com gerenciamento de projetos
ágeis. Todos são formados na área de Computação e são pós-graduados.
Sobre o uso do Framework RADS no contexto DDS
Dos 28 respondentes, 4 deles (14%) concordaram totalmente, 7 (25%) concordaram e
12 (43%) concordaram parcialmente que os passos descritos no framework sejam
suficientes para melhor gerenciar riscos em projetos DDS. Em contrapartida, 1 (3,5%)
discordou parcialmente, 3 (11%) discordaram e 1 (3,5%) discordou totalmente. Apesar
dos respondentes terem admitido à aderência da aplicação do RADS ao DDS, as
respostas sugerem que o framework deve ser amadurecido em relação à sua aplicação na
indústria. Neste sentido, os respondentes que concordaram e os que concordaram
totalmente (39%) afirmaram que é importante o desenvolvimento de soluções
acadêmicas para gerar opções de escolha para o mercado.
Sobre a adoção de práticas ágeis no Framework RADS
Com relação a essa questão, 3 (11%) dos respondentes concordaram totalmente, 8
(28,5%) concordaram e 11 (39%) concordaram parcialmente de que a adoção de
práticas ágeis no framework RADS ajuda a melhor gerenciar riscos em projetos DDS.
Em contrapartida, 3 (11%) discordaram parcialmente, 1 (3,5%) discordou e 2 (7%)
discordam totalmente. 29% dos respondentes afirmaram que as metodologias ágeis em
geral, como o Scrum e XP, não abordam como aplicar as suas práticas em um contexto
distribuído. Desta forma, é necessária alguma intervenção ou apoio, ou seja, alguma
iniciativa para conceber metodologias, frameworks ou guias de boas práticas, que ajudem
a minimizar os desafios enfrentados por equipes distribuídas. Entre as razões daqueles
que discordaram, a principal foi que o RADS não tem uma equipe multidisciplinar.
14
WDES
Sobre a definição dos papéis do Framework RADS
Dentre os 28 respondentes, 4 (14%) dos respondentes concordaram totalmente, 15
(54%) concordaram e 7 (25%) concordaram parcialmente que os papéis descritos e suas
atribuições são suficientes para a gestão de riscos em projetos de DDS. Por outro lado, 1
(3,5%) discordou parcialmente e 1 (3,5%) discordou totalmente. Apesar da maior
aceitação da definição dos papéis do RADS, os comentários dos respondentes indicaram
que o framework não é ágil em si, mas que ele faz o bom uso de práticas ágeis. Mesmo
os respondentes sabendo que o framework não foi concebido exclusivamente para
projetos ágeis, esta percepção se deu devido ao fato do framework definir papéis
hierarquizados, o que é contrário à definição de papéis em equipes ágeis.
Sobre a comunicação contínua no Framework RADS
Dos respondentes, 3 (11%) dos respondentes concordaram totalmente, 8 (28,5%)
concordaram e 11 (39%) concordaram parcialmente com a afirmativa de que o
framework RADS pode ser utilizado para o gerenciamento de riscos em projetos DDS
nas instituições onde trabalham. Em contrapartida, 3 (11%) discordaram parcialmente, 1
(3,5%) discordou e 2 (7%) discordam totalmente. A busca por uma comunicação efetiva
dentro dos projetos é algo que vem sendo estudado há anos e ainda hoje representa um
problema em aberto. Os respondentes afirmaram que manter uma comunicação contínua
(clara e objetiva) contribui significativamente para o sucesso do projeto gera mais
confiança entre os stakeholders.
Melhorias sugeridas para o Framework RADS
Os respondentes reforçaram que existe uma necessidade de melhorar a denominação dos
papéis, bem como alinhar as definições dos papéis com aqueles existentes nas
metodologias ágeis, pois estes não apregoam o conceito “comando-controle”, mas sim
equipes mais multidisciplinares. Eles também sugeriram a utilização, de forma mais
explícita, do papel “cliente” ou um “representante do cliente”, pois, independente do
projeto, o papel do cliente é bastante relevante, sobretudo na gestão de riscos.
7. Considerações Finais
O crescente interesse das organizações na utilização de técnicas de DDS despertou
algumas questões sobre as etapas do ciclo de gerenciamento de projetos deste tipo. Entre
as atividades envolvidas, está a gestão de riscos. Neste contexto, o framework RADS
busca contribuir para a melhoria do cenário de gerenciamento de projetos, em especial
no que diz respeito à gestão de riscos em organizações que utilizam DDS. O framework
contempla elementos identificados na literatura, inspirados nas metodologias ágeis, em
busca de um desenvolvimento de software mais dinâmico. A avaliação preliminar do
framework por especialistas indicou que ele tem potencial para ser aplicado na indústria e
está coerente com as necessidades de gestão de riscos em projetos DDS.
Como trabalho futuro, pretende-se aplicar o RADS em casos reais de projetos
DDS para avaliar a sua eficiência e eficácia. Apesar da limitação de não ter sido avaliado
em um estudo de caso, a quantidade de participantes que responderam ao survey (28 dos
71 convidados, 39,4% de resposta) foi superior ao indicado, como esperado em estudos
deste tipo (25%). Desta forma, acredita-se que os resultados alcançados são de
contribuição para a comunidade de DDS.
15
WDES
Referências
Audy, J., Prikladnicki, R. (2007) “Desenvolvimento Distribuído de Software: Desenvolvimento
de Software com Equipes Distribuídas”. Rio de Janeiro: Campus.
Boehm, B. (1991) “Software Risk Management: Principles and Practices”. IEEE Software, v. 8,
n. 1 (January), pp. 32-40.
Ebert, C., Murthy, B., Jha, N. (2008) “Managing Risks in Global Software Engineering:
Principles and Practices”, In: Proceedings of the IEEE International Conference on Global
Software Engineering, Princeton, pp. 131-140.
Hossain E., Babar, M., Hye-young, P., Verner, J. (2009) “Risk identification and mitigation
processes for using scrum in global software development: A conceptual framework”, In:
Proceedings of the Asia-Pacific Software Engineering Conference, Penang, pp. 457-464.
Keshlaf, A., Hashim, K. (2000) “A model and prototype tool to manage software risks”, In: Proc.
of the First Asia-Pacific Conference on Quality Software, Hong Kong, pp. 297-305.
Keshlaf, A., Riddle, S. (2010) “Risk Management for Web and Distributed Software
Development Projects”, Proceedings of the 5th International Conference on Internet
Monitoring and Protection, Barcelona, pp. 22-28.
Leme, L., Tait, T., Huzita, E. (2007) “Strategy of Risk Management for a Distributed Software
Engineering Environment”, In: Proceedings of the 4th International Workshop on Computer
Supported Activity Coordination, ICEIS 2007, Funchal.
Marconi, M., Lakatos, E. (2003) “Fundamentos de metodologia científica”. São Paulo: Atlas.
Mudumba, V., Lee, O. (2010) “A New Perspective on GDSD Risk Management: Agile Risk
Management”, In: Proceedings of the 5th IEEE International Conference on Global Software
Engineering, Princeton, pp. 219-227.
Nelson, C., Taran, G., Hinojosa, L. (2008) “Explicit Risk Management in Agile Processes”, In:
Proceedings of the 9th International Conference XP, Limerick, pp. 190-201.
Nyfjord, J., Kajko-Mattsson, M. (2007) “Commonalities in Risk Management and Agile Process
Models”, In: Proceedings of the International Conference on Software Engineering Advances,
Cap Estrel, p. 18.
Persson, J., Mathiassen, L., Boeg, J., Madsen, T., Steinson, F. (2009) “Managing Risks in
Distributed Software Projects: An Integrative Framework”. IEEE Transactions on
Engineering Management, v. 56, n. 3 (August), pp. 508-532.
PMI (2013) “A Guide to the Project Management Body of Knowledge (PMBOK® Guide)”.
Project Management Institute, 5th ed.
Ramesh, B., Cao, L., Mohan, K., Xu, P. (2006) “Can distributed software development be
agile?”. Communications of the ACM, v. 49, n. 10 (October), pp. 41-46.
Ribeiro, L., Gusmão, C. (2008) “Definição de um processo ágil de gestão de riscos em ambientes
de múltiplos projetos”. Hífen, Uruguaiana, v. 32, n. 62 (II Semestre), pp. 67-74.
Šmite, D., Moe, N., Ågerfalk, P. (2010) “Agility Across Time and Space: Summing up and
Planning for the Future”, In: Šmite, D., Moe, N., Ågerfalk, P. (eds.), “Agility Across Time
and Space”, Springer Berlin Heidelberg.
Sommerville, I. (2007) “Engenharia de Software”. São Paulo: Pearson Addison-Wesley, 8ª ed.
WDDS (2013) “Workshop de Desenvolvimento Distribuído de Software”. Disponível em:
<http://www.wdds.ufpb.br/2013/index.php>. Acessado em: 10/07/2014.
Zanoni, R., Audy, J. (2003) “Project Management Model for a Physically Distributed Software
Development Environment”, In: Proceedings of the 36th Hawaii International Conference on
System Sciences, Hawaii, pp. 1-8.
16
WDES
On the Identification of Factors that Promote HighPerformance Projects in Distributed Development
Preliminary Findings of an Empirical Study of a Fortune 500 IT Multinational Company
Sabrina Marczak1, Marcelo Perin1, Rafael Prikladnicki1, Christiano Ayub2
1
Computer Science School– Pontifícia Universidade Católica do RS (PUCRS)
6681 Ipiranga Ave. – Partenon – 90.619-900 – Porto Alegre – RS – Brazil
2
Development Center, ORG
Ipiranga Ave. – Partenon – 90.619-900 – Porto Alegre – RS – Brazil
{sabrina.marczak,rafaelp,mperin}@pucrs.br, [email protected]
Abstract. As part of a long-term research on high-performance projects in
distributed software development, we sought to investigate what leads a
project to meet or exceed its expected performance. In this paper we report on
the preliminary findings of our qualitative exploratory study. We conducted 11
semi-structured interviews in a Fortune 500 IT multinational company that
develops software in-house to support its business processes. Participants
listed 7 factors that promote high-performance in their opinion, including
timely attending the organization’s business needs. They also mentioned 5
issues related to achieving performance such as having a person mediating the
conversation between the business and the IT departments. We present the
identified factors and issues, and discuss their implications to the performance
of distributed software development projects.
1. Introduction
Project management discipline aims to guide software teams to plan, implement, and
control the development of any software product. Organizations introduce project
management to their software projects aiming to deliver their projects on time, on
budget, and with quality (Project Management Institute, 2013). However, in today’s
globalized IT market organizations also have to timely attend their customer’s demands
in order to remain competitive. Therefore, organizations and managers desire to have
their projects attending or exceeding their expected performance goals. We name these
high-performance projects.
Although there are several studies on project performance in distributed software
development (e.g., (Herbsleb and Mockus, 2003)), little is still known about what
promotes high-performance in this kind of project in modern times. In the past decade
we have seen information and communication technology improving, agile methods
being proposed, companies going over major reorganizations to better attend their
customer expectations, among other changes that might have affected how software
teams perform and deliver software products. Therefore, as part of a long-term research
on high-performance projects, in this initial phase we sought to empirically explore
what contributes to a distributed software development project to meet or exceed its
expected performance. We conducted an exploratory qualitative study based on semi-
17
WDES
structured interviews in a large IT company, named ORG (a fictitious name due to
confidentiality restrictions). Our 11 study participants listed 7 factors that promote and 5
issues that make it difficult to achieve high-performance in distributed software
projects. In this paper we report on the findings of this initial study and discuss the
implications of the identified factors and issues to the performance of distributed
software development projects.
2. Research Method
Our empirical study consisted of interviews conducted on-site in a large IT company.
Interviews were transcribed and analysis was guided by ground theory procedures
(Corbin and Strauss, 2007).
2.1. Company Background
The study was conducted in a large IT multinational company. Software products to
support the organizational processes are developed by the IT department. Demands to
develop or to update these products come from the business departments. IT
development teams are distributed among the headquarters’ office located in the US and
in Brazil, India, and Malaysia. The IT department follows a matrix structure based on
business areas (e.g., sales) and IT functions (e.g., developers). Projects vary from the
development of new products to the maintenance of legacy systems. Project teams
mainly follow the waterfall model. Some Scrum practices are scarcely adopted to
support project management. Processes vary from formal (following CMMI Level 3
practices) to informal (defined by the project members upon their needs).
An annual project roadmap is defined in December based on the requests made
by business representatives and recorded by business analysts. Business analyst
managers in conjunction with project managers prioritize the requests and define a set
of projects to be developed throughout the year. Priorities are defined based on business
impact and on development costs. Distributed software teams are then formed to
develop the elected projects. Members are assigned to the projects based on their skills
and domain knowledge, despite of their physical location. Therefore, a project often has
its roles distributed over several locations. By mid February each team receives a
business request document. The software team starts working to translate the business
into software requirements led by the software requirements analysts. These have to
consult with business analysts to clarify business requirements and, when necessary,
business representatives are invited to join the discussion. Project managers monitor the
project progress based on a set of organizational performance measures that are reported
to senior management in a regular basis. Results from these measurements are used to
determine whether a project failed, attended, or exceeded its performance goals.
2.2. Data Collection and Analysis
Our study consisted of 11 interviews conducted on-site with Brazilian team members.
Each interview lasted for an average of one hour. We asked the participant to answer to
the following taking her working experience with the company into consideration:
“Looking back at the distributed software projects you have participated on, please
think of one project that stood out and elaborate on what you think that contributed to
this project to attend or exceed its performance goals.”
18
WDES
Study participants were selected based on their experience working with the
company and on their role within the IT department. We started by asking the Brazilian
IT Director whom we should be talking with. He pointed out 3 Senior Managers who
have started in the IT department about 12 years ago when the development center was
created. We then asked these 3 Senior Managers to point out more prospective
participants. Eight other people were interviewed, totaling 11 participants in our study.
We received suggestions of other prospective participants, but as we analyzed the
collected data as we were conducting the interviews, we considered this number
sufficient by saturation of the responses. Table 1 describes the participants’ current roles
and job descriptions, and their past roles within the company.
All interviews were transcribed, and transcriptions were prepared for analysis in
the ATLAS.ti software. Our subsequent analysis was guided by grounded theory
procedures (Corbin and Strauss, 2007). One researcher coded the data using the opencoding procedure. A second researcher coded a smaller sample of the transcriptions to
compare the identified codes. The researchers then discussed the code list together,
unifying codes into categories when appropriate. The resulting categories represent the
factors and the issues presented in Section 3. Both researchers conducted a 3 hours long
meeting with the 11 participants to report on the findings, reviewing the results to
ensure accurateness and discussing their usefulness to the company as suggested by
Creswell (2008).
3. Initial Findings
Participants reported on 7 key factors. We present them below. Note that each
participant has reported on more than a factor. Participants’ quotes include the study’s
participant identifier (ID) defined in Table 1.
• Factor 1: Enables the business and helps the business to evolve. Four participants
mentioned that it is important that the project “introduces something new to the
business that will help it to quickly evolve and better attend the market” (P6). For
instance, one of the senior development managers (P4) discussed “why would the
organization migrate legacy systems that are reliable and have a low cost
maintenance to new technologies if the systems would maintain their original
features”? He defends the idea that new functionalities that would help the business
to speed up its activities have to be introduced in order to justify such major
maintenance migration. The senior manager that was firstly hired in Brazil (P2)
recalled that a few projects considered as high-performance were those that had
helped the business to answer the question such as “what can help us improve the
way how the [organizational] business is done nowadays?”
• Factor 2: Delivers what the business needs in a timely manner. Three participants
highlighted the importance of delivering what is requested in a timely manner “in
order to have a software product that supports the business process that is in place”
(P7). The former software architect (P9) argued it is important to “try to anticipate
the estimated deliver date since the faster the new system is in place the more likely it
is that it will be in sync with the current business process”. One of the senior
development managers (P5) mentioned “there is no room for delays in this company,
if the project is late the process might not be there anymore, we change things to
frequently”.
19
WDES
Table 1. Participant’s background
ID
P1
Current Role and
Job Description
Quality and metrics manager: This is a
worldwide position responsible for
defining and collecting metrics to measure
performance of IT teams as well as
defining processes to guide their work.
P2
Career manager: This manager is
responsible for planning and help
developing the career of the Brazilian
developers (it includes developers and
team leaders)
P3
Manager of the Project Management
function: This is a worldwide position
responsible for hiring Project Managers,
allocating them to manage IT projects, and
following-up on their work.
P4
Senior Development Manager: This
position is responsible for assigning
developers to projects, and to following-up
on their work alongside the Project
Manager.
Senior Development Manager: Same job
description as P4.
description as P4.
P5
P6
P7
P8
P9
P10
P11
Project Manager: This position is
responsible for managing the development
of the IT projects and for collecting
performance measurements to share with
Senior Management.
Project Manager: Same job description as
P7.
Project Manager: Same job description as
P7.
description as P4.
description as P4.
20
Past Roles
He started 12 years ago as a Software Reqs
Analyst. In this position, he led the worldwide
initiative of defining processes to support
requirements engineering activities. He also
acted as a Project Manager when he proposed,
among other things, a subset of the current
performance measures.
He also started 12 years ago. He was the first
employee hired by ORG to work in the
Brazilian Development Center. He acted as a
Development leader and a Project Manager.
He is also one of the focal points for the
research activities with PUCRS.
He is originally from the USA and joined
ORG about 20 years ago. He was one of
ORG’s first salesmen. He joined the IT team
12 years ago as a Project Manager. He was
one of the first managers assigned to work
with a Brazilian team. Two years later he
asked to have this job position transferred to
Brazil. He also worked as a Senior Project
Manager and a Career Manager.
He has been working at ORG for about 10
years and has started as a Developer. He also
acted as a Project Manager.
He has also started 10 years ago as a
Developer. He has acted as Dev Leader.
He has also started 10 years ago as a
Developer, acted as Dev Leader and Software
Architect.
She started about 8 years ago as a Software
Requirements Analyst.
She started 10 years ago as a Tester and also
acted as Test Leader.
He also started 10 years. He joined ORG as a
Developer and acted as a Software Architect.
He started 6 years ago as a Project Manager
and acted as the Site Manager for 3 years. As
a Site Manager he was responsible for hiring
people and controlling the overall IT
operations in Brazil.
He joined ORG about 4 years ago as a Project
Manager. He managed the development of
projects that are critical for the company’s
operation.
WDES
• Factor 3: Has an alignment between the business needs and the software
requirements. Seven out of 11 participants discussed how dynamic the organization
is and how challenging it is to have the software products attending the business
needs. For instance, the company has gone over two major reorganization structures
in the last 18 months, changing job functions, business goals, among other changes.
Therefore, they highlighted that a key factor to achieve high-performance is “to be
flexible and fast in perceiving changes and adjusting to them in order to keep the
software aligned to business needs” (P1).
• Factor 4: Finds the balance between what the customer ‘wants’ and what the
customer ‘really needs’. Three participants cited how critical it is that the IT team is
able “to distinguish between what the customer wants and what is really necessary to
support the business processes” (P3). In a distributed IT organization, where the
customers and end users are located in different time zones, often over 2 or 3
continents, it is “challenging to get to know the business processes in details to be
able to question the customer about her requests” (P2). The Quality and Metrics
manager (P1) recognized the importance of a “highly-skilled software requirements
analyst” to mediate the discussion with the business department in such scenario.
• Factor 5: Has a requirements engineering process that efficiently and effectively
defines what has to be done. Four participants recounted the relevance of a clear,
well-defined, and disseminated requirements engineering process. Former tester (P8)
recalled when the entire IT organization followed a single and unified development
process based on the CMMI Level 3. She mentioned “it was easier and faster to
communicate with everyone, and to perform our tasks. Now we need to waste time
negotiating with people from other sites how to do things and we never always reach
an agreement at first”.
• Factor 6: Has an adequate and qualified team. Five participants mentioned the
impact of “the right team” (P10). They were unisonous in recognizing that the
organization “has skilled employees that know how to provide the expected technical
solutions” (P2). They referred to the fact of having “people who know how to
approach the business team” (P2), “how to establish critical connections with them”
(P10), and “to identify whether the proper stakeholders are the ones originating the
demands to the IT team” (P11).
• Factor 7: Delivers on time, on budget, and with quality. Although 6 of the
participants mentioned that attending “traditional project management targets (e.g.,
being on time) is expected from any manager” (P2), only one participant described as
a key element “to deliver on time, on budget, and with quality” (P5). He said “we
cannot forget these are basic goals to any project and that sometimes we go easy on
them jeopardizing the quality of the final product”.
Although it was not part of our initial goal, during the interviews participants also
cited issues that had led projects to fail or to not completely attend their performance
goals. Given how much emphasis the respondents put on these issues, we report them
below as follows:
• Issue 1: To have a mediator between the business department and the IT team. Four
participants recalled the difficulties faced by software teams to timely clarify the
requirements. The former software requirements analyst (P7) mentioned “we know
that this is the structure that the organization imposes on us but they need to realize
21
WDES
how much it delays reaching out those who really know how the process should be
run”. The f critical applications’ former manager (P11) added “We need to be able to
reach the business representatives without depending on the business analysts that
quite frequently work in a high level that leaves important details out for the design
of the software solution”.
• Issue 2: To validate requirements too late in the development lifecycle. Four
participants pointed out as a serious drawback the fact that software requirements are
validated only after the development is over. One of the project managers (P7)
reported “too many business rules are identified as missing or misunderstood by the
software team in this point”. “It is also here that we learn that business processes
have changed and that the software has not been deployed yet is already obsolete”
(P9). One of the senior development managers (P11) suggested that “traditional
validation techniques like prototyping could be adopted to avoid such late findings”.
• Issue 3: To have poorly written software requirements. Although the participants
mentioned that they perceive the software professionals as well skilled, 3 of them
indicated that software requirements are still poorly written. A senior manager (P2)
said “because the projects’ roadmap is defined based on non-standardized written
business needs and requests, sometimes we inherit poorly defined business
requirements that are translated into poorly written software requirements. It would
be best if we could be closer to the business representatives”.
• Issue 4: To work based on assumptions. Associated to the perception that the
distance between business and IT teams is prejudicial, 3 participants mentioned that
“assuming certain knowledge about the business processes is a common practice of
the software teams that often results in disaster situations” (P11). A senior
development manager recalled that “the organization is so dynamic that even within
a single project it is risky to assume that the [business] processes have not changed,
mind in between projects” (P6). They wish the team members “would double-check
more often business rules and other important definitions used in the specification of
the software requirements” (P9).
• Issue 5: To implement improvements that were not requested. Three participants
commented on the fact that “software teams often add small improvements to the
applications without discussing them with the business analyst, resulting sometimes
in a positive feedback from the customers but quite often in waste of time and
rework” (P7). “This initiative is seen as pro-active behavior by software members but
perceived as ‘noisy’ by the business team” said a manager (P1).
4. Discussion and Final Considerations
To deliver a project on time, on budget, and with quality is a key premise in software
organizations. However, with the constant changing IT market software solutions need to
quickly adjust to business changes and to new customer’ requests. Agile methods have
been introduced aiming to provide a more flexible approach to software teams (Larman,
2003). Although these methods define practices that promote a more pro-active way of
working, there are organizations that still work based on more traditional approaches
such as the waterfall model as the investigated organization. Participants claimed that
following a more structured development model and a more ‘traditional’ organization
structure in which communication channels between departments are centralized helps
22
WDES
assuring that the project goals will be better achieved and that the customer will be better
served. Almost two decades ago Al-Rawas and Easterbrook (1996) have reported that
organizational barriers can inhibit efficient communication that leads to requirements
issues found later on in the development process. Despite this knowledge, our findings
suggest that the issue is still around.
Assuming that this Fortune 500 large IT multinational is not the only company in
the world to still follow the waterfall model and to having strictly communication
channels defined via the organization structure, our findings contribute to bringing to
light that traditional software engineering issues (e.g., issue 3 - poorly written software
requirements (Damian and Zowghi, 2003)) are still being faced by distributed software
teams. When going agile and following a more loose and dynamic process are not a
feasible option due to imposed organizational management decisions, software
engineering is still to provide effective and efficient recommendations. In a dynamic
market like the current one some practices, processes, and techniques provided in
literature might be limited. For instance, techniques to derive software requirements from
formally defined business processes (e.g., EKD (Bubenko, Sirna, and Brash, 2001)) to
ensure alignment might be over due when considering that organizations might not be
able to keep up-to-date written business processes.
We find it interesting that, in general, the factors and issues mentioned by our
respondents are not specific to distributed teams, i.e., these factors and issues are not
necessarily caused due to distance. The implication is that co-located teams might also
face them. Generalization of our findings has to be considered with caution. We have
investigated one single organization and interviewed members located in Brazil only.
Despite these limitations, we understand that the variety of roles played by the
respondents over the years and their large experience within the organization represent a
large set of projects, and as such the results are worth being considered by software
organizations with similar settings. Our next step in this long-term research is to
quantitatively investigate historical project data from ORG to identify which project
characteristics promoted high-performance.
Acknowledgement
We would like to thank the PDTI Program, financed by Dell Computers of Brazil Ltd.
(Law 8.248/91), and the participants for their collaboration and time.
References
Project Management Institute (2013) “A guide to the project management body of
knowledge,” 5th ed., Newtown Square, Project Management Institute, 589p.
Herbsleb, J. and Mockus, A. (2003) An Empirical Study of Speed and Communication
in Globally Distributed Software Development. IEEE Trans. on Software Eng., vol.
29, no. 6, June, pp. 481-494.
Corbin, J. and Strauss, A. (2007) “The basics of qualitative research: Techniques and
procedures for developing grounded theory,” Sage Publications, Los Angeles,
USA, 3rd ed., 400 p.
Creswell, J. (2008) “Research design: Qualitative, quantitative, and mixed methods
approaches,” Sage, Thousand Oaks, USA.
23
WDES
C. Larman (2003) “Agile and iterative development: A manager’s guide,” Addison
Wesley, New York, USA, 368p.
Al-Rawas, A. and Easterbrook, S. (1996) “Communication problems in requirements
engineering: A field study,” In: Proc. of the Conf. on Professional Awareness in
SEng, London, pp. 46-60.
Damian, D. and Zowghi, D. (2003) “RE challenges in multi-site software development
organisations”, Requirements Engineering, vol. 8, no. 3, pp. 149-160.
Bubenko, J., Sirna, J., and Brash, D. (2001) “EKD user guide,” Dept. of Computer and
Systems Sciences, Stockholm: Royal Institute of Technology.
24
WDES
SECOView: Uma Abordagem Baseada em Visões para
Apoiar a Governança de Ecossistemas de Software
Yuri Abreu1, Rodrigo Pereira dos Santos1, Benno Albert2, Cláudia Werner1
1
PESC/COPPE/UFRJ – Universidade Federal do Rio de Janeiro
Caixa Postal 68511 – CEP 21941-972 – Rio de Janeiro, RJ, Brasil
2
Petrobras, Tecnologia da Informação e Telecomunicações – Rio de Janeiro, RJ, Brasil
{yuriabreu, rps, werner}@cos.ufrj.br, [email protected]
Abstract. IT organizations constitute part of a Software Ecosystem (SECO)
when related to each other. They face challenges in managing, choosing and
maintaining their technologies in a dynamic market. On decision making
processes, these organizations have difficulties in visualizing SECO
information due to the lack of software asset management. This paper presents
a view-based approach for supporting SECO governance from IT architecture
activities. A tool was implemented as an extension of Brechó Library.
Resumo. Organizações de TI, em suas relações, fazem parte de Ecossistemas
de Software (ECOS) e enfrentam desafios ao organizar, selecionar e manter
tecnologias em um mercado dinâmico. Em processos de decisão, elas têm
dificuldades em visualizar informações de ECOS por carências na gestão dos
ativos de software. Este artigo apresenta uma abordagem baseada em visões
para apoiar a governança de ECOS a partir de atividades de arquitetura de
TI. Uma ferramenta foi construída como extensão da Biblioteca Brechó.
1. Introdução
Um Ecossistema de Software (ECOS) pode ser definido como um conjunto de negócios
funcionando como uma unidade e interagindo com um mercado compartilhado entre
software e serviços, juntos e inter-relacionados [Jansen et al., 2009]. Neste contexto, as
organizações enfrentam desafios ao lidar com a dinâmica do mercado [Messerschmitt &
Szyperski, 2003]. Fusões ou aquisições entre organizações fornecedoras de tecnologias
podem alterar a oferta de produtos e serviços, o que afeta as organizações consumidoras
e seus negócios. Esses eventos agregam complexidade em selecionar, adotar e gerir
ferramentas/tecnologias para dar suporte à organização e seus objetivos [Albert, 2014].
Nesse sentido, organizações consumidoras possuem, normalmente, um conjunto
de ferramentas de apoio a seus processos e profissionais, e produzem artefatos (produtos
e serviços) para atingir seus objetivos. Alguns problemas, no entanto, aparecem, como o
alto custo para adoção de novas tecnologias, a necessidade de reavaliar processos de
negócios frente a sua implantação, a dificuldade em lidar com a oferta e a relutância dos
usuários para aceitá-las [Freitas & Rech, 2003]. A arquitetura de TI das organizações
consumidoras, por exemplo, pode sofrer impactos do desafio de organizar, selecionar e
manter tecnologias em um mercado em constante mudança [Baars & Jansen, 2012].
Nos processos de tomada de decisão, essas organizações têm dificuldades em
visualizar informações de ECOS por carências na gestão de seus ativos de software. Isso
leva empresas consumidoras a recorrerem a institutos como Gartner e Forrester, que
25
WDES
agem como “conselheiros de TI” e produzem relatórios com base no mercado e opiniões
de profissionais da área [Albert et al., 2013]. Neste contexto, este artigo apresenta uma
abordagem baseada em visões para apoiar a governança de ECOS a partir de atividades
de arquitetura de TI, denominada SECOView. Uma infraestrutura de apoio foi
implementada como extensão de uma biblioteca de componentes e serviços de software
[Brechó, 2014] e uma análise preliminar de sua utilização foi realizada. O artigo está
organizado nas seguintes seções: a Seção 2 apresenta a fundamentação teórica; a Seção
3 apresenta a abordagem proposta; a Seção 4 discute a extensão da Biblioteca Brechó; a
Seção 5 discute uma análise preliminar de sua utilização; e a Seção 6 conclui o artigo.
2. Fundamentação Teórica
Organizações fornecedoras e consumidoras estabelecem laços ao se relacionarem, como
em contratos de aquisição de produtos e consultorias. As relações, organizações
envolvidas e informações trocadas são elementos de um ECOS. Nesse contexto, a fim de
cumprir as metas de uma organização consumidora, gerentes e arquitetos de TI têm o
desafio de avaliar relações entre tecnologias e fornecedores e usá-las a favor da
organização. As organizações que exploram essas novas relações, de fato, necessitam
construir um processo de decisão em seus modelos para usufruir de certa agilidade em
detrimento de seus concorrentes, o que impacta a sua arquitetura de TI [Gartner, 2007].
No cenário de ECOS, a definição de arquitetura de TI/software é estendida por
Manikas & Hansen (2013) como “Arquitetura de ECOS”, i.e., as estruturas do ECOS
como elementos de software, suas características e relações. Os elementos do ECOS
podem ser sistemas, componentes do sistema e atores. As relações se referem àquelas de
arquitetura de software, incluindo relações entre atores (e.g., fornecedores competindo
com um mesmo tipo de produto no mercado). Por sua vez, Gartner (2007) separa as
características de ECOS sob quatro visões: 1) visão do ECOS como uma entidade; 2)
visão das trocas mútuas com o valor de negócio; 3) visão de artefatos compartilhados,
tecnologias e propriedade intelectual; e 4) visão dos tipos específicos de ECOS.
Nesse contexto, a governança pode auxiliar uma organização a alcançar seus
objetivos, usufruir melhor dos recursos disponíveis e promover um aumento da
lucratividade e redução de riscos. Gartner (2007) indica que, para gerir arquitetura em
ECOS, seus componentes devem ter um conjunto mínimo de informações que possibilite
a sua gestão pela organização consumidora. Albert (2014) explica que os seguintes
dados devem fazer parte desse conjunto: Fornecedor, Natureza, Tecnologia, Maturidade,
Data, Tipo de Ativo Produzido, Versões, Licenças, Usuários e Utilização (i.e., log de
ferramenta de coleta de uso de software). Para dar suporte à governança, a gestão de
ativos de software entra como instrumento para gerir e otimizar práticas de aquisição,
implantação, uso e manutenção dos ativos da organização [Williams & O’Connor, 2011].
Como trabalhos sobre visões de governança em ECOS, há o Gartner Hype
Cycles [Gartner, 2008] e o Forrester Tech Horizon Chart [Hopkins et al., 2013], que
permitem acompanhar a maturidade de tecnologias. Outro trabalho, o ThoughtWorks
Technology Radar, agrega, em uma visão, uma combinação de abordagens que permitem
verificar a maturidade de tecnologias [ThoughtWorks, 2012]. Como diferencial da
abordagem SECOView, para além dos trabalhos relacionados, busca-se explorar visões
para a governança de ECOS a partir das atividades de arquitetura de TI da organização.
26
WDES
3. Abordagem Proposta
A abordagem SECOView visa manipular dados de uma biblioteca de ativos de software
para construir visões que apoiem a governança de ECOS. Estes dados se referem à
gestão de ativos de software e, desta forma, a SECOView propõe informações gráficas
para os usuários, ilustrando recortes do ECOS da organização, ou mesmo provendo uma
visão global. A estrutura da SECOView (Figura 1) mostra que mecanismos de busca e
recuperação e histórico de ativos produzidos são utilizados para se ter acesso aos dados
da gestão de ativos na biblioteca de ativos de software da organização (ou catálogo).
Estes dados se referem a: ativos de software (componente da biblioteca), fornecedores,
categorias de tecnologias e usuários. A SECOView interpreta os dados e, conforme
especificado pelo usuário, refina-os para gerar uma visão que exiba parte do (ou todo o)
estado do ECOS da organização. Gráficos são exibidos ao usuário a partir da agregação
dos dados das aplicações, componentes e serviços da organização.
Figura 1 – Estrutura da abordagem SECOView
A SECOView toma por base o modelo SECOGov [Albert, 2014], que consiste
em um framework de governança de ECOS que envolve as seguintes atividades para
apoiar a arquitetura de TI, nas visões intra e interorganizacional: (i) Gerir Taxonomia de
Software: manter as categorias adequadas para organizar os ativos de software da
organização; (ii) Gerir Arquitetura de Software: definir que ativos são padronizados para
cada categoria da taxonomia; (iii) Gerir Configurações-padrão de Software: definir quais
ativos compõem uma configuração para atender a um dado perfil de ator do ECOS; (iv)
Gerir Licenças de Software: gerir o quantitativo e a diversidade de tipos de licenças, e
atribuir e disponibilizar licenças para os usuários; (v) Acompanhar ECOS: manter
informações sobre os ECOS que a organização participa ou deseja participar por meio da
análise de relatórios de institutos, consultorias ou equipe de gestão da arquitetura
corporativa; (vi) Analisar a Maturidade de Tecnologias: cruzar informações dos ECOS
sobre a maturidade de determinada tecnologia ou mercado; e (vii) Selecionar Produto ou
Tecnologia: especificar requisitos da tecnologia desejada, avaliá-los e estabelecer uma
definição de aquisição ou contratação de serviços.
A partir de um ativo de software, para a atividade Gerir Licenças de Software, a
SECOView propõe inicialmente dois gráficos para a visão “intra”, que permitem
verificar: (1) o grau de dependência tecnológica dos ativos de um fornecedor que a
organização adquiriu licenças; e a distribuição de seu uso e desuso (disponibilidade); e
(2) a comparação de produtividade com outros ativos que produzem o mesmo tipo de
solução para a organização (i.e., ativo produzido), filtrado por período. Esta proposta é
27
WDES
motivada pelo resultado do levantamento de Rios (2013), que indica o controle das
licenças de cada ativo como crucial, pois isso concentra um dos maiores custos para o
setor de TI das organizações. Em alto nível, a SECOView propõe gráficos de ECOS
para examinar a visão “inter”: (3) o grau de dependência tecnológica da organização
consumidora em relação aos seus fornecedores; e (4) a distribuição das licenças da
organização consumidora em relação às categorias dos ativos adquiridos.
Por sua vez, para apoiar a atividade Gerir Arquitetura de Software do SECOGov,
propõe-se um rótulo para o ativo de software, “padrão”, para indicar o componente da
biblioteca que seja o padrão de arquitetura para uma categoria específica. Isso orienta
quais ativos de software devem ser adotados em maior escala pela organização. Além
disso, a SECOView propõe um módulo de gestão de análises de ECOS (relatórios) para
apoiar a atividade Acompanhar ECOS do SECOGov, a fim de armazenar dados de como
a organização consumidora participa do ECOS. Para facilitar a rastreabilidade destes
dados ao longo do tempo, a SECOView propõe ainda associar uma categoria de
tecnologias e/ou ativos de software a uma análise que justifique a adoção ou aquisição
pela organização. As análises podem ser ordenadas por parâmetros [Gartner, 2007], e.g.,
taxa de benefício, maturidade, tempo para adoção (anos) e recomendação para adoção.
Entre os recursos utilizados, estão: (i) gráfico de pizza: para analisar os ativos de
um fornecedor específico; (ii) gráfico de barras horizontais: para avaliar as licenças em
uso e desuso de fornecedor; (iii) gráfico de barras verticais: para avaliar os ativos
produzidos pela organização; (iv) grafos: para analisar dependências dos fornecedores; e
(v) planilhas: para exibir os resultados de relatórios de mercado sobre a análise das
tecnologias que a organização possui. Estes recursos foram baseados no levantamento
sobre mecanismos de recomendação e visualização, realizado por Souza (2008).
Ressalta-se que as atividades Gerir Taxonomia de Software e Gerir Configuraçõespadrão de Software são apoiadas pela implementação do modelo SECOGov, cujos
detalhes são descritos em (Albert, 2014), estando fora do escopo deste trabalho. Por fim,
as atividades Analisar a Maturidade de Tecnologias e Selecionar Produto ou Tecnologia
serão estudadas como trabalhos futuros.
4. Extensão da Biblioteca Brechó
Para dar suporte à abordagem proposta, foi implementada uma extensão da Biblioteca
Brechó. A Brechó consiste em um sistema web para gestão de ativos (componentes de
software, serviços web e aplicações) que fornece mecanismos de busca, recuperação,
armazenamento, documentação, publicação, controle de versão e evolução,
gerenciamento dos usuários e de licenças, entre outros [Werner et al., 2007]. A
biblioteca é organizada de forma hierárquica, onde um componente representa um ativo
armazenado de forma conceitual (nome e descrição), que possui um conjunto de
distribuições (corte funcional) e, estas, um conjunto de releases (corte temporal). Os
artefatos de uma release podem ser agrupados em pacotes para atender necessidades dos
usuários, ou disponibilizados como serviços web, ambos sob licenças (direitos/deveres).
Visando apoiar a governança dos componentes da biblioteca, um ícone para
acessar as visões da SECOView foi adicionado (Figura 2). Para o gráfico de fornecedor
(Figura 3), filtraram-se os componentes do fornecedor do componente selecionado,
separando a quantidade de licenças de cada componente e relacionando-as ao total de
28
WDES
licenças do fornecedor. Para o gráfico de alocação de licenças, analisaram-se todas as
releases do componente selecionado, de cada distribuição, comparando-se a quantidade
de licenças em uso/desuso, para cada release (Figura 3). Na visão “inter”, os gráficos de
ECOS foram desenvolvidos para analisar a biblioteca da organização, gerando uma
informação geral. O primeiro, “Dependência de Fornecedor” (Figura 4), foi construído a
partir da análise do total de licenças adquiridas/em uso das releases de cada fornecedor.
Similarmente, construiu-se o gráfico “Dependência de Categoria” (Figura 4) a partir da
análise dos dados de licenças adquiridas/em uso dos componentes de cada categoria.
Figura 2 – Tela “Meus Componentes”. Em destaque, ícones para a geração de gráficos
de um componente da biblioteca e o menu para acessar “gráficos de ecossistema”.
Figura 3 – Gráficos do fornecedor do componente Microsoft Office (esquerda) e da
alocação de licenças do componente Microsoft Office (direita).
Figura 4 – Gráficos da dependência de fornecedor (esquerda) e de categoria (direita).
Para configurar o atributo “padrão de arquitetura” para uma categoria, um novo
atributo, “standard”, foi acrescentado à entidade Componente da Brechó. A definição do
padrão é feita na tela de criação/edição de um componente: verificando se existe algum
29
WDES
padrão para a categoria em questão; fornecendo ao usuário escolhas pertinentes, e.g.,
caso tente definir um componente como padrão da categoria quando há outro, uma
mensagem para questionar se deseja alterar o padrão é exibida; caso positivo, realizando
as alterações pertinentes na base de dados (Figura 5). A marcação de componente padrão
foi feita acrescentando uma coluna no menu “Meus Componentes”, que exibe um “sinal
de visto” verde, caso o componente seja o padrão de sua categoria (Figura 2).
Figura 5 – Telas de definição do componente padrão de uma categoria quando há outro
padrão (esquerda) e de detalhes da categoria “Ferramentas de escritório” (direita).
Para acompanhar como a organização participa do ECOS, implementou-se o
módulo de análise de ECOS, para criar e editar uma análise, o que requer inserir dados
para facilitar a rastreabilidade e caracterização (e.g., nome, origem/fonte, descrição,
recomendação, impacto para o negócio, taxa de benefício, recomendação para adoção).
Foi implementada a tela “Listar Análises”, para recuperar as análises armazenadas e
exibi-las em uma tabela (Figura 6). Para facilitar a visão, implementou-se a ordenação
por alguns desses tipos de dados, clicando-se no item pretendido no cabeçalho da tabela.
Por fim, implementou-se o suporte ao acompanhamento de ECOS ao criar uma relação
entre as entidades, de modo que uma Análise pode estar associada a zero ou uma
Categoria que, por sua vez, pode estar associada a zero ou n Componentes, diferindo da
associação entre Componentes e Categoria (n a n). Para que o usuário gerencie estas
relações, foi criada uma funcionalidade para permitir essas associações (Figura 6).
Figura 6 – Tela “Listagem de análises” (esquerda) e de associação de análise (direita).
5. Utilização da Ferramenta
Com a intenção de observar inicialmente alguns elementos da interface do ferramental
desenvolvido, foi preparado um instrumento de análise da Brechó, utilizado por alunos
de graduação da área de Computação da UFRJ. O instrumento (formulário eletrônico)
incluiu algumas tarefas para verificar a adequação do tempo necessário para execução.
30
WDES
Além disso, o instrumento apontou alguns elementos de interface a serem observados
durante as tarefas, inspirados nas heurísticas de usabilidade adaptadas de [Nielsen, 1993].
Um piloto foi individualmente conduzido em 08/04/2014 com dois participantes
(um graduando em Engenharia da Computação e outro em Ciência da Computação).
Após a concordância, foi apresentado um texto sobre ECOS, o modelo de dados da
Brechó e a extensão implementada na SECOView. Ambos conseguiram responder às
perguntas, com poucos erros. Eles relataram dificuldades em encontrar certas opções
para realizar uma tarefa e visualizar a separação de componentes na tela “Meus
Componentes”, assim como a falta de um manual. A partir disso, foram feitas alterações
nas instruções e questões do instrumento, tornando os textos mais sintéticos, e também
no layout da ferramenta, para sanar os problemas de navegação.
A análise, então, foi conduzida individualmente com três participantes em
16/04/2014, graduandos em Ciência da Computação. Cada um preencheu a
caracterização, leu o embasamento e executou as tarefas propostas. Um exemplo de
tarefa foi: “Quais são os componentes associados à configuração de software
‘Programador Web’?”. Por fim, os participantes avaliaram a usabilidade da ferramenta.
Em geral, os participantes tiveram êxito em todas as tarefas. A Tabela 1 mostra os
resultados das avaliações dos participantes (P1, P2 e P3), na escala de 0 a 10.
Tabela 1 – Resultados da avaliação de usabilidade
Elementos de interface inspirados em [Nielsen, 1993]
(1) visibilidade do status
A ferramenta informa o que está acontecendo?
(2) concordância entre a ferramenta e o mundo real
A ferramenta utiliza a linguagem do usuário?
(3) controle e liberdade ao usuário
A ferramenta apresenta facilidade de interação e “saídas” claras?
(4) consistência e padrões
Diferentes situações ou ações representam a mesma coisa?
(5) prevenção de erros
O projeto da ferramenta prevê situação de erro ao invés de usar mensagem?
(6) minimização da carga de memória do usuário
As telas mostram o que está sendo feito e dão ideia do caminho percorrido?
(7) flexibilidade e eficiência de uso
A ferramenta atende a usuários experientes?
(8) projeto minimalista e estético
As informações são sintéticas e completas?
(9) reconhecimento, diagnóstico e recuperação de erros
Problemas e soluções são facilmente indicados?
(10) ajuda e documentação
Existem manuais simples e objetivos?
P1
P2
P3
6
5
8
6
8
9
7
1
9
8
8
10
9
9
10
6
0
10
8
7
10
7
8
9
8
4
10
4
6
8
O feedback indicou como pontos fracos: a dificuldade de encontrar informações;
a ausência de um manual on-line da ferramenta (i.e., ícones de ajuda); e a visibilidade do
estágio do usuário na tarefa. Entre os pontos fortes apontados, estão: a clareza dos
gráficos; a compilação da informação; e a prevenção de erros. Observou-se que os dois
participantes com o melhor desempenho nas tarefas foram os mais críticos e deram
feedback mais informativo. A análise realizada teve caráter preliminar e propiciou a
organização de um instrumento para conduzir um estudo de caso na indústria, com
participantes da área de governança, conforme apresenta (Albert, 2014).
6. Conclusão
Devido ao desafio da governança de ECOS, este artigo apresentou a abordagem
SECOView, cujo objetivo é manipular dados de uma biblioteca de ativos de software
para a construção de visões para apoiar a governança de ECOS a partir de atividades de
31
WDES
arquitetura de TI. A abordagem foi implementada como extensão da Biblioteca Brechó e
uma análise preliminar de utilização foi realizada. Como contribuições, são sumarizadas
características, artefatos e recursos importantes para a governança de ECOS no sentido
de apoiar a organização consumidora a melhorar a visão do ECOS em que está inserida.
Buscou-se com a SECOView um suporte para acompanhar a evolução do ECOS da
organização consumidora e dos ECOS relevantes aos seus objetivos de negócio. Os
recursos gráficos da SECOView trazem à pesquisa em ECOS uma visão sobre o
tratamento de dados em bibliotecas de ativos de software, a fim de atender as
necessidades de governança, pela carência de iniciativas na área [Baars & Jansen, 2012].
Alguns trabalhos futuros são apontados: (1) melhorar a interface da ferramenta,
com ícones de ajuda e visualização dos rastros das ações do usuário, e apoiar às demais
atividades do modelo SECOGov; (2) realizar um estudo de usabilidade com gerentes e
arquitetos de TI; e (3) estender a abordagem para tratar a gestão de demandas
(requisitos) em ECOS e contemplar mais variáveis arquitetônicas em sua estrutura.
Referências
Albert, B. (2014). “Secogov: Um Modelo de Governança de Ecossistemas de Software para
Apoiar Atividades de Arquitetura de TI”. Dissertação. COPPE/UFRJ, Rio de Janeiro, Brasil.
Albert, B.; Santos, R.; Werner, C. (2013) “Software Ecosystems Governance to Enable IT
Architecture Based on Software Asset Management”. In: 7th IEEE International Conference
on Digital EcoSystems and Technologies, Menlo Park, USA, pp. 55-60.
Baars, A.; Jansen, S. (2012) “A Framework for Software Ecosystem Governance”. In: 3rd
International Conference on Software Business, Boston, USA, pp. 168-180.
Brechó (2014) “Biblioteca de Componentes, Serviços e Aplicações de Software”, disponível em:
<http://reuse.cos.ufrj.br/brecho>, acesso em julho de 2014.
Freitas, H.; Rech, I. (2003) “Problemas e Ações na Adoção de Novas Tecnologias de
Informação”. Revista de Administração Contemporânea, v. 7, n. 1 (Jan-Mar), pp. 125-150.
Gartner (2007) “Evaluating Global-Class SECO”, disponível em: <http://www.gartner.com/
document/506608>, acesso em julho de 2014.
Gartner (2008) “Gartner Hype Cycles”, disponível em: <http://www.gartner.com/technology/
research/methodologies/hype-cycle.jsp>, acesso em julho de 2014.
Hopkins, B. et al. (2013) “Emerging Technology Innovation Needs New Tools”. Forrester.
Jansen, S.; Finkelstein, A.; Brinkkemper, S. (2009) “A Sense of Community: A Research Agenda
for Software Ecosystems”. In: 31st ICSE, NIER, Vancouver, Canada, pp.187-190.
Manikas, K.; Hansen., K. (2013) “Software Ecosystems – A Systematic Literature Review”.
Journal of Systems and Software, v. 86, n. 5 (May), pp. 1294-1306.
Messerschmitt, D.; Szyperski, C. (2003) “Software Ecosystem: Understanding an Indispensable
Technology and Industry”. Cambridge: MIT Press.
Nielsen, J. (1993) “Usability Engineering”. Cambridge: Academic Press.
Rios, L. (2013) “Governança de Ativos em Ecossistemas de Software na Biblioteca Brechó”.
Trabalho de Conclusão de Curso. Escola Politécnica da UFRJ, Rio de Janeiro, Brasil.
Souza, D. (2008) “Utilização de Técnicas de Visualização para a Recomendação de Substitutos”.
Dissertação. COPPE/UFRJ, Rio de Janeiro, Brasil.
ThoughtWorks (2012) “ThoughtWorks Technology Radar March 2012”, disponível em:
<http://thoughtworks.fileburst.com/assets/technology-radar-march-2012.pdf>.
Werner, C. et al. (2007) “Brechó: Catálogo de Componentes e Serviços de Software”. In: Anais
do XXI SBES, Sessão de Ferramentas, João Pessoa, Brasil, pp. 24-30.
Williams, C.; O’Connor, S. (2011) “Four Best Practices for Software Asset Management”. BCM
Software Industry Insights.
32
WDES
Ecosystem Business Models and Architectures
John D. McGregor1 , Simone da Silva Amorim2
1
School of Computing
Clemson University
Clemson, SC 29634 USA
[email protected]
2
Federal Institute of Education,
Science and Technology of Bahia
Salvador, BA Brazil 40170
[email protected]
Abstract. The ecosystem strategy has provided organizations with time and cost
savings by facilitating collaboration with other organizations with similar product ideas and compatible business models. This strategy requires a compatible
software architecture that is extensible, flexible, and scalable. In this position
paper we clarify definitions, summarize our previous work, and describe our ongoing work that supports defining effective and efficient ecosystem architectures
and business models.
1. Introduction
Every organization that produces a software product is embedded in an ecosystem that
comprises its collaborators, competitors, suppliers, and customers. We use “ecosystem”
as an analogy to the natural environment in which predators and prey interact. The
ecosystems in which we are interested are socio-technical ecosystems in which organizations, people, and technologies collaborate and compete on the development of softwareintensive products. The ecosystem may simply be the natural customer-supplier business
interactions of one organization with those with whom it does business or it may be a carefully orchestrated strategy that involves legal entities such as open source foundations or
partner programs, formal charters, and fees for membership.
Each organization in the ecosystem is following a business model that is more
collaborative, more continuous, more personalized, and more transparent than traditional
counterparts [Prahalad and Krishnan 2008]. Businesses are involving customers in the
product design process much more deeply than a few focus groups. By using social media
the opinions, complaints, and suggestions of customers are available to product designers as are their purchasing patterns. Rather than waiting for customers to initiate another
purchase, organizations establish a continual dialog via newsletters, reminders of events,
and other occasional communication. The data gathered from these continuous, collaborative relationships support the design of products that can be personalized based on data
collected in the ecosystem. The design process becomes more transparent to customers
as more information is revealed on both sides to establish the continuous relationship.
The software architecture underlying an ecosystem structure is critical to long term success because it unifies the work of personnel who are
33
WDES
distributed over different organizations and over geography.
In our previous work we have illustrated the need for the architecture of products, built
following an ecosystem-based strategy, to be flexible, extensible, and scalable [da Silva Amorim et al. 2013] [McGregor et al. 2013] [da Silva Amorim et al. 2014a]
[da Silva Amorim et al. 2014b]. The products must be sufficiently flexible to allow each
ecosystem member to configure easily the core product to meet the needs of their
particular customers. The architecture must be sufficiently extensible to allow completely
new features to be added to the core with minimal modifications. The architecture should
be sufficiently scalable to support the anticipated growth over the product life cycle.
We have observed that productive and robust ecosystems are centered around explicitly defined business models and a software architecture designed to satisfy those business models. There needs to be explicit linkages between the characteristics of the ecosystem strategy, business models, and the quality attributes of the product architectures.
The contribution of this paper is an analysis of the interactions of the three quality attributes, flexibility, extensibility, and scalability, with popular ecosystem business
models. We discuss the mechanisms that support these attributes and the tradeoffs that
result in products with these attributes as high priorities. We illustrate with examples
of specific architectures. The remainder of this paper is structured as follows: section 2
presents background relevant to understanding the analysis, section 3 presents an analysis
of quality attribute interactions, and section 4 summarizes our work and describes next
steps.
2. Background
2.1. Business models
A successful business model has a customer value proposition, profit formula, key resources, and key processes [Johnson et al. 2008]. We will use these elements as we analyze the impact of architecture qualities on business models in the next section. We
briefly present three business models, which will be used in the analysis, and we will
provide more details during the analysis discussion.
2.1.1. Coopetition
The “coopetition” business model is an efficient product development strategy that
leverages the collaboration among organizations in the ecosystem to share effort
and risks among the group. The group of organizations identify a core architecture that they wish to share among themselves, sometimes referred to as a platform [Baldwin and Woodard 2008]. The group collaborates in the planning and design
of the core architecture. They implement the core and often add frameworks that they
think will be useful in building products. These same collaborators then individually
compete with each other by taking the commonly developed artifacts and extending or
configuring them to produce a product of interest to their specific customer base. The
coopetition model’s value proposition addresses faster time to market and shared risk;
its profit formula is based on software reuse; key resources such as intellectual property
(IP) surrounding the core architecture which must be managed and key processes such
as management by consensus and promotion by meritocracy. For example, BMW applies
34
WDES
the coopetition business model to developing automotive systems through the AUTOSAR
Partnership, which has over 100 member organizations. The basic artifact is an automotive platform from which other vehicles can be built. BMW benefits because it can share
some of the risk of a new model with competitors such as Ford and GM and because the
extensive reference architecture allows BMW to produce more quickly and cheaply than
rivals that are not in the partnership.
2.1.2. Multi-sided markets
Hagiu and Wright defines a multi-sided market as “an organization that creates value primarily by enabling direct interactions between two (or more) distinct types of affiliated
customers” [Hagiu and Wright 2011]. In this model, an organization creates a product
that brings together two other groups that directly interact. Most often the product developer also establishes the market that creates value by having two types of clients. The
clients also provide feedback on improving the software supporting the market. This business model’s value proposition is to arrange for information suppliers and consumers to
be able to find each other; the profit formula is either fee-based or advertising-based; the
key resources are the software platform and members of the two client pools; the key
processes are developing the software and attracting clients. For example, the Science
Exchange provides a web portal where laboratories can register services which they offer [Science Exchange 2014]. Research groups can use the portal to locate services that
they may need as part of their experimentation.
2.1.3. Partner program
A large organization may establish a “partner” program whose membership is open to
other organizations interested in collaboration on one or more products. These organizations often pay a fee in order to gain the advantage of early access to new releases of
a product or special access to source code or other artifacts which they can use to build
extensions and apps. This early access allows the partners to have new products synchronized with the release of a new version of the main product; however, partners usually
do not have special access to source code and use the core application programming interfaces (APIs) to build products. The value proposition is being first to market, which
is an important advantage [Popp 2011]; the profit formula can be fee-based, in-kind contributions, or based on the product extensions attracting more buyers to the core product;
the key resources are the plans and designs of the dominant organization; key processes
are attracting partners and information sharing processes. For example, Microsoft has a
partner program for many of its products [Microsoft 2014]. Although definitely not open
source, Microsoft teams gather input from a variety of sources including the partners and
build roadmaps of products and features. Partners’ early access does not give them any
special access to source code; however, they are given access to the planned APIs earlier
than non-partners.
2.2. Quality Attributes
Based on our experience with a number of ecosystems in a number of domains,
we identified three quality attributes of the core architecture that contribute to
35
WDES
the success of an ecosystem: Extensibility, Scalability and Flexibility. We have
investigated how these quality attributes are present in ecosystem architectures.
[da Silva Amorim et al. 2013][da Silva Amorim et al. 2014a][da Silva Amorim et al. 2014b]
present the findings for each attribute and describe their impact in ecosystem architectures.
In our first study about Extensibility[da Silva Amorim et al. 2013] we investigated
the APIs of ecosystem platforms. APIs are the common mechanism that is used to allow
that external developers to connect their applications to the platform. A well-designed
API is essential to keeping external developers productive and satisfied. We identified 4
features with considerable influence in the building of an efficient API: Completeness,
Complexity, Design and Documentation. A complete API contains all the API elements
necessary to make developers’ work easier; the complexity of an API is reduced by eliminating details not needed to understand how to use the functions; the design of the API
influences how the components are organized and how decisions are made during building process; the documentation of the API offers guidance for external developers if it
is well-organized and clear. We examined these APIs features in 3 ecosystem platforms,
Hadoop [Monteith et al. 2013] that is increasing in use, Eclipse [Wermelinger 2009] that
is in solid use and CORBA [Schmidt 1993] that is declining in use. We evaluate how
these features are present in these architectures in order to illustrate extensibility in these
ecosystem architectures.
In our second study[da Silva Amorim et al. 2014a] we investigated the characteristics that contribute to build a scalable ecosystem. We used the six features defined by
Bondi [Bondi 2000] that describe the types of scalability in general systems: load, space,
space-time, structural, distance and speed/distance. We extended this classification and
defined more two additional features: artifact and people. Artifact scalability concerns
the increased number of managed artifacts over time. This increase occurs over chronological time, when several organizations join to ecosystem, over and over the phases of
the development process as they add new features to the platform. People scalability relates to the ecosystem’s ability to manage the growth of the membership of people and
organizations. These new participants contribute to diversity in the environment and improve the robustness and sustainability of the ecosystem. In addition, we performed case
studies with two ecosystems, the Eclipse Foundation [Wermelinger 2009] and Apache
OODT [Apache Foundation 2014] to examine these features in real-world ecosystems.
In our latest study [da Silva Amorim et al. 2014b], we analyzed features that influence the flexibility of ecosystem architectures. These features were classified into two
dimensions: business and technical dimensions. The business dimension refers to interactions among internal and external developers in addition to political and economical
aspects that influence design decisions that allow the building of flexible architectures.
The technical dimension considers the technical attributes with special attention to the
explicitly defined features of the architecture. We used Baldwin’s approach that is based
on the Propagation Cost metric [Baldwin et al. 2013] to adapt for ecosystems architectures. The original approach uses the design structure matrix (DSM) to record dependencies among the modules of system and to calculate the propagation cost considering
this cost as a measure of the system flexibility [MacCormack et al. 2006]. It does not
consider the dependencies of the API connected to the platform. We added weights in-
36
WDES
side the matrix where the values represent dependence with a module of the API. This
is the first step to get a different metric specific for ecosystem architectures. We applied
this metric in the Apache OODT ecosystem to exemplify the adaptation of the flexibility [Apache Foundation 2014].
3. Analysis
An ecosystem is successful if it continues to attract participants and is compatible with
their business models. This motivates the need for a platform that can meet the needs of
a wide range of participants. The platform is based on a core architecture that is scalable,
flexible, and extensible. Given the basics defined in section 2 we now consider how these
qualities support three ecosystem business models.
3.1. Business model characteristics
Table 1 provides a brief description of the linkages between the business process characteristics described in [Prahalad and Krishnan 2008] and the three business models we are
investigating.
Table 1. Business models vs. properties
Collaborative
Continuous
Personalized
Transparent
Coopetition
Ecosystem members co-develop products and
compete on the deployment of those products.
Feedback on innovations from product users
informs platform developers.
Multi-sided Market
An ecosystem member collaborates with two
consumer markets to bring them together.
Partners
The dominant producer collaborates with
smaller producers.
Feedback from both markets informs the platform supplier.
Platform may be used directly by individuals
instead of other product builders.
Open source development ecosystems show
everything from rules to voting.
Participants can filter a market to receive only
the information they wish to have.
Links to outside information energize both
markets through competition.
Ecosystem members work to attract new
clients, maybe even individuals, into the
product innovation process.
Users select the partners they wish to work
with and the add-ons they want to use.
Published categories of membership instead
of individual transactions level the playing
field.
3.2. Analysis by business model feature
The three quality attributes address each of the four parts of a business model but in
different ways for different models.
3.2.1. Value Proposition
The basic value proposition for ecosystem strategies includes reduced costs, quicker delivery of new features, and improved quality. These benefits are realized from improved
synergies among members of the ecosystem and are realized by both developers and users.
Flexible - The coopetition business model and the multi-sided markets model both
benefit from the flexibility provided by the variation mechanisms in the core architecture
to reconfigure the core to address multiple audiences. Most partner programs provide
less flexibility and the partners only build extensions rather than reconfiguring the core
product.
Extensible - The coopetition business model has less need for extensibility because the intense interactions in designing the core platform gives opportunities for anticipated changes to be identified and accommodated via variation mechanisms. The multisided markets business model uses extensibility when a specific client population can
be attracted by domain-specific features such as background checks for a dating service.
37
WDES
The partner programs extend the core product but market timing is controlled by the core
product.
Scalable - The multi-sided markets and partner models are based on handling
specific client loads so scalability is critical. The coopetition model is more generic and
certain types of products might be load sensitive such as the size of the product to be built
in a tools ecosystem.
3.2.2. Profit formula
The profit formulae for ecosystem strategies vary across strategies and roles of organizations, but what is common is that most strategies use an indirect formula. That is, the
organizations using many of the ecosystem strategies do not directly receive payment for
some of the work that is done. The work on the core platform is, in most cases, pooled
for the common good, often as open source. The profit may come from delivering an
audience for advertising-based models or from the ability for each participant to use the
work of the whole group as the basis for future products.
Flexible - The flexibility of the core platform enhances the profit formula of an
organization by giving the organization options for future products and helps attract and
retain developers. The effort required for inserting the variation mechanisms and for later
exercising these options is a cost against that profit. The coopetition model is particularly
sensitive to how flexible the platform is since the expectation is to produce products as
rapidly as possible.
Extensible - The extensibility of the core platform is the key to profit in the
ecosystem architectures. Anticipating all future features is impossible; however, ecosystem architects manage future feature development through the insertion of variation mechanisms. The use of loose coupling and well-defined APIs reduce the cost of defining the
extensions required for products and thereby increase profits.
Scalable - Products that utilize the multi-sided markets strategy will need to scale
in multiple dimensions in order to profit. Being able to handle an unconstrained number
of participants on each side of the market will yield the best profit.
3.2.3. Key resources
Personnel, money, and facilities are the key resources specified in most ecosystem business models. The facilities in particular include tools for collaboration and social networking tools. The ecosystem is as strong as the interactions among the organizations
and between the organizations and its customers.
Flexible - Developers who were not involved in building the core can become
productive more rapidly due to the variation mechanisms in place in the flexible architecture. This conserves all of the key resources. The multi-sided markets strategy follows
a distinct pattern which can be reflected in variation mechanisms and recipes to speed
development and conserve resources.
38
WDES
Extensible - Well-defined APIs in an extensible architecture make it easy for organizations following a partner strategy to attach their product extension to the main product. Up-to-date documentation, example architecture instantiations, and other aids assist
the developer in building product extensions.
Scalable - The multi-sided market strategy is sensitive to scaling from a resource
perspective. The searching and matching that usually is the focus of such a strategy needs
an architecture that maintains a linear growth pattern.
3.2.4. Key processes
The ecosystem business models usually include collaborations such as peer-to-peer,
dominant-to-subordinate, and multi-way interactions. The models also include development processes for both the core platform and products that are extensions of the core.
Flexible - The explicit variation mechanisms inserted in the core product to make
it flexible allows the development of the products to follow a set pattern making the process easy to define and follow. Ecosystems using the coopetition strategy select the variation mechanisms that first fit the situation and then that are the easiest to exercise.
Extensible - The partner strategy will benefit the most from having a standard set
of processes for defining and then for using the APIs in the architecture because partners
are usually limited to accessing the product through APIs to define extensions. In the
coopetition model the organization who developed the core is also developing the product
and should have some residual knowledge that goes beyond the APIs and should have
sufficient access to benefit from it.
Scalable - The development processes must accommodate a changing number of
organizations and their contributed resources. The processes must be able to scale in
a distributed environment. For the ecosystem to be successful the development process
must be able to support increases in number of organizations, number of developers, and
number of projects.
4. Summary
The ecosystem strategy supports a number of unique business models and enhances some
traditional ones as well. Each model supports different value propositions, profit is realized in different ways, and key resources and processes impose different constraints. The
architects and developers building the core architecture need to understand the business
model that ultimately will be the guide to success in order to prioritize how to handle
variation points, API definitions, and algorithm growth rates.
Our future work will include defining measures which distinguish ecosystems that
possess differing degrees of flexibility, extensibility, and scalability and does so in units
that are useful to ecosystem participants. The processes will have to address the wide variation in how the core architecture will ultimately be used. We will also identify ecosystem
design patterns.
References
Apache Foundation (2014). Apache oodt. http://oodt.apache.org/.
39
WDES
Baldwin, C., MacCormack, A., and Rusnak, J. (2013). Hidden structure: Using network
methods to map product architecture. Technical Report Working Paper 13-093, Harvard Business School.
Baldwin, C. Y. and Woodard, C. J. (2008). The architecture of platforms: A unified view.
Technical Report 09-034, Harvard Business School.
Bondi, A. B. (2000). Characteristics of scalability and their impact on performance. In
Proceedings of the 2nd international workshop on Software and performance, pages
195–203.
da Silva Amorim, S., Almeida, E. S. D., and McGregor, J. D. (2013). Extensibility in
ecosystem architectures: an initial study. In WEA, pages 11–15.
da Silva Amorim, S., de Almeida, E. S., and McGregor, J. D. (2014a). Scalability of
ecosystem architectures. In WICSA, pages 49–52.
da Silva Amorim, S., McGregor, J. D., Almeida, E. S. D., and von Flach G. Chavez, C.
(2014b). Flexibility in ecosystem architectures. In WEA.
Hagiu, A. and Wright, J. (2011). Multi-sided platforms. Technical Report 12-024, Harvard Business School.
Johnson, M. W., Christensen, C. M., and Kagermann, H. (2008). Reinventing your business model. Harvard business review, 86(12):57–68.
MacCormack, A., Rusnak, J., and Baldwin, C. Y. (2006). Exploring the structure of
complex software designs: An empirical study of open source and proprietary code.
Management Science, 52(7):1015–1030.
McGregor, J. D., Monteith, J. Y., Amorim, S., and Almeida, E. (2013). Modeling the
contributions of software architecture to the success of an ecosystem. In Proceedings
of SATURN - SEI Architecture Technology User Network.
Microsoft (2014). Microsoft partner program. https://mspartner.microsoft.
com/en/us/Pages/index.aspx.
Monteith, J. Y., McGregor, J. D., and Ingram, J. E. (2013). Hadoop and its evolving
ecosystem. In Proceedings of the Fifth International Workshop on Software Ecosystems, pages 57–68.
Popp, K. M. (2011). Hybrid revenue models of software companies and their relationship
to hybrid business models. In IWSECO@ICSOB, pages 77–88.
Prahalad, C. and Krishnan, S. (2008). The New Age of Innovation: Driving Cocreated
Value Through Global Networks. McGraw Hill professional. McGraw-Hill Education.
Schmidt, D. C. (1993). The adaptive communication environment: An object-oriented
network programming toolkit for developing communication software.
Science Exchange (2014). https://www.scienceexchange.com/.
Wermelinger,
M. (2009).
The architecture evolution of
http://michel.wermelinger.ws/chezmichel/2009/10/
the-architectural-evolution-of-eclipse/.
40
eclipse.
WDES
Qualidade em Ecossistemas de Software:
Desafios e Oportunidades de Pesquisa
Rodrigo Santos1, George Valença2, Davi Viana3, Bernardo Estácio4, Awdren Fontão3,5,
Sabrina Marczak4, Cláudia Werner1, Carina Alves2, Tayana Conte3, Rafael Prikladnicki4
1
PESC/COPPE – Universidade Federal do Rio de Janeiro (UFRJ)
2
CIn – Universidade Federal de Pernambuco (UFPE)
3
IComp – Universidade Federal do Amazonas (UFAM)
4
FACIN – Pontifícia Universidade Católica do Rio Grande do Sul (PUCRS)
5
INdT – Instituto Nokia de Tecnologia
{rps, werner}@cos.ufrj.br, {gavs, cfa}@cin.ufpe.br,
{davi.viana, tayana}@icomp.ufam.edu.br, [email protected]
{bernardo.estacio, sabrina.marczak, rafaelp}@pucrs.br
Abstract. Distributed software development has become a reality over the last decade. The
Software Engineering community has investigated technical, economic and social aspects.
This scenario leveraged the development of globalized, large-scale and long-term
platforms, which is treated as a kernel of software ecosystems. Understanding how this
scenario impacts the quality in software ecosystems has been considered a critical success
factor. This paper presents an initial discussion on the quality in software ecosystems
towards the identification of some challenges and opportunities.
Resumo. Desenvolvimento distribuído de software se tornou uma realidade na última
década. A comunidade de Engenharia de Software tem investigado aspectos técnicos,
econômicos e sociais. Isso propiciou o desenvolvimento de plataformas globalizadas, de
larga escala e de longo prazo, que tem sido tratado como o núcleo de ecossistemas de
software. Entender como este cenário impacta a qualidade em ecossistemas de software
tem sido um fator crítico. O artigo apresenta uma discussão inicial sobre qualidade em
ecossistemas de software visando identificar alguns desafios e oportunidades.
1. Introdução
O Desenvolvimento Distribuído de Software (DDS) se tornou uma realidade na última década
(Jiménez et al., 2009). Apesar dos desafios geográficos e culturais da colaboração, uma das
principais motivações do DDS está na busca por equipes mais produtivas e especializadas, produtos
de melhor qualidade e redução de custos de desenvolvimento (Sengupta et al., 2006). Paralelamente
à consolidação do DDS, outros modelos de desenvolvimento têm surgido, não limitados ao escopo
de um projeto/produto único (Cataldo & Herbsleb, 2010). Ao reunir diversos projetos em torno de
uma tecnologia de software central, esses modelos têm permitido o desenvolvimento de plataformas
globalizadas, de larga escala e de longo prazo (Manikas & Hansen, 2013). Tais plataformas
originam sistemas mais complexos, que integram uma rede de diversos atores e artefatos, mesmo
externos a elas, e formam Ecossistemas de Software (ECOS) (Bosch, 2009). Dittrich (2014) relata
que as práticas observadas em ECOS desafiam alguns pressupostos da Engenharia de Software (ES)
tradicional, dado que o desenvolvimento dos produtos não ocorre em torno de um projeto e sim pela
inovação contínua feita por diversos atores do ecossistema (i.e., inovação aberta). Nesse contexto,
um dos fatores críticos do desenvolvimento está na qualidade em ECOS (Santos & Werner, 2012).
Nos diferentes cenários de DDS, fatores que impactam a qualidade são discutidos, seja no
desenvolvimento local (onshoring) ou global (offshoring), dentro da empresa (insourcing) ou com
terceiros (outsourcing) (Prikladnicki & Audy, 2010). Entre eles, destacam-se o alinhamento entre os
41
WDES
processos, as dependências entre as atividades e entre os artefatos, a gestão de projetos globais e a
comunicação (Gomes & Marczak, 2012). Estes fatores influenciam na forma como o software é
definido, construído, testado e entregue aos consumidores, afetando consequentemente os estágios
do ciclo de vida (Jiménez et al., 2009). Semelhante a um dos cenários de DDS, as plataformas de
ECOS são desenvolvidas de maneira global, com o envolvimento de terceiros. No entanto, em
ECOS, atores externos, conhecidos ou não, atuam no desenvolvimento de produtos e/ou da própria
plataforma (Barbosa et al., 2013). Nesse sentido, alguns desafios de DDS podem ser herdados por
ECOS, que trazem fatores adicionais para qualidade, como abertura da arquitetura da plataforma,
hibridização de modelo de negócio e governança em outsourcing (Jansen et al., 2009).
Este artigo apresenta uma discussão inicial sobre qualidade em ECOS visando identificar
desafios e oportunidades de pesquisa para a comunidade de ES. Além desta seção de introdução, o
artigo está organizado da seguinte forma: a Seção 2 apresenta uma visão geral de como a qualidade
tem sido abordada em ECOS; a Seção 3 discute alguns desafios e oportunidades para qualidade em
ECOS; e a Seção 4 discorre sobre as considerações finais do artigo.
2. Qualidade em Ecossistemas de Software
Com uma ampla atuação de atores externos à organização que provê a plataforma, como startups e
desenvolvedores independentes (Miranda et al., 2014), o desafio da qualidade em ECOS vem se
tornando uma questão importante (Axelsson et al., 2014). De acordo com Barbosa et al. (2013), a
questão da qualidade não tem sido definida ou tratada especificamente para ECOS, mas a maneira
pela qual a qualidade é medida vem sendo uma preocupação real. As primeiras iniciativas para
discutir qualidade em ECOS foram voltadas para a avaliação das contribuições dos atores, o que é
crucial para o desenvolvimento e evolução da plataforma (Hmood et al., 2010). Na presença de um
keystone1, fatores adicionais são percebidos, como o nível de controle e poder sobre o ECOS
(Jansen et al., 2009). Por exemplo, para um ECOS fechado, como o ECOS iPhone, o keystone tem
controle para garantir que as contribuições atendam a um padrão de qualidade mínimo exigido pelo
canal de distribuição (AppleStore). Já em um ECOS aberto, como o ECOS MySQL/PHP, onde os
atores têm acesso ao código fonte e às bases de conhecimento relacionadas, o controle de qualidade
é mais difícil de ser gerenciado e garantido, considerando atores externos desconhecidos.
Além disso, a qualidade em ECOS não tem se restringido à visão dos processos e dos
produtos, mas explora a visão de saúde e de prosperidade (Fotrousi et al., 2014). Em (Manikas &
Hansen, 2013), percebe-se esta relação com a saúde do ECOS, i.e., o grau com que um ECOS
oferece oportunidades para colaboradores e para os que dele dependem. Por exemplo, Dhungana et
al. (2010) discutem dois indicadores: (i) sustentabilidade, capacidade do ECOS aumentar ou manter
a comunidade de colaboradores diante do aparecimento de tecnologias/produtos de competidores; e
(ii) diversidade, capacidade do ECOS envolver diferentes colaboradores ao prover uma plataforma
que dê suporte a diferentes produtos, linguagens, dispositivos, perfis etc. Já Hartigh et al. (2006)
apresentam três categorias de indicadores: (i) produtividade, capacidade do ECOS adaptar e
entregar novas tecnologias, processos e ideias aos seus participantes; (ii) robustez, capacidade do
ECOS sustentar a sua rede de relacionamentos e manter a arquitetura da plataforma estável; e (iii)
criação de nicho, capacidade do ECOS inovar ou propiciar que a sua comunidade o faça.
Vale ressaltar que, diferente do processo de desenvolvimento de um único produto, em
ECOS não há separação entre o desenvolvimento da plataforma e dos projetos sobre ela (Cataldo &
Herbsleb, 2010). Isso requer processos de gestão distribuídos que ampliam a forma de avaliar a
1
Um keystone é uma organização que disponibiliza uma tecnologia de software central para ampliar o seu portfólio de
produtos e serviços a partir da integração ou construção de novas soluções por atores externos (Jansen et al., 2009).
42
WDES
capacidade e maturidade dos processos dos atores do ECOS (Santos & Werner, 2012). São
necessárias estratégias para coordenar diferentes atores e sua comunicação no ECOS (Farias Júnior
et al., 2013); técnicas para melhorar a experiência (Fontão et al., 2014) e motivação (Miranda et al.,
2014) dos colaboradores; e abordagens (guias e padrões) para certificação das contribuições dos
atores (Maia et al., 2013) e para negociar requisitos nos projetos do ECOS (Valença et al., 2013).
3. Desafios e Oportunidades de Pesquisa
Esta seção resume alguns desafios para garantir a qualidade em ECOS. Para identificá-los, utilizouse a categorização de questões de DDS definida por Audy & Prikladnicki (2008) como orientação:
processos de software, infraestrutura, pessoas ou recursos humanos, gerenciamento e comunicação.
Os desafios relacionados a DDS (Seção 1) e a explanação sobre qualidade em ECOS (Seção 2) são
tomados como base e questões específicas de ECOS são trazidas à discussão:
Categoria 1 – Processos de Software e Padrões
Como responsável pela gestão da plataforma e do ecossistema em torno dela, o keystone deve rever
seus processos de software para melhorar a experiência dos colaboradores do ECOS (e.g.,
desenvolvedores externos, fornecedores etc.) e estabelecer controles adequados aos diferentes tipos
de atores. Nesse contexto, indicadores de saúde de ECOS podem ser usados como instrumentos
para apoiar a avaliação da capacidade e maturidade do keystone, visando lidar com a qualidade.
O keystone deve disseminar boas práticas e padrões arquiteturais para garantir a consistência das
integrações dos produtos no ECOS, cobrindo assim a sustentabilidade, a produtividade e a robustez
do ECOS. Seja no contexto de comunidades ou naquele formado por empresas de software, é
fundamental que frameworks e bibliotecas de desenvolvimento ou sistemas integradores funcionem
como mecanismos para garantir o pleno funcionamento das soluções geradas (e.g., capacidade para
manter a execução de aplicativos desenvolvidos por terceiros em ECOS móveis).
Categoria 2 – Aspectos Sociais e Gestão do Conhecimento
O conhecimento circulante entre a plataforma e os produtos ao redor influencia o processo de
aquisição de tecnologias pelo keystone. A diversidade dos elementos que compõem o ECOS e as
contribuições intelectuais dos diferentes atores devem ser aproveitadas adequadamente pelos
projetos e pela plataforma por meio de diferentes estratégias de captura de conhecimento.
Adicionalmente, é importante que a credibilidade de um colaborador seja verificada por meio de
certificações ou processos de seleção de parceiros adaptados para as particularidades de ECOS.
Categoria 3 – Governança
Uma estratégia de Gestão dos Produtos de Software (Software Product Management) deve ser
estabelecida pelo keystone e comunicada aos demais atores do ECOS. Desse modo, é possível que
haja alinhamento de portfólios e conhecimento do roadmap dos produtos. Nesse sentido, sob a ótica
de gestão de requisitos, requisitos de qualidade e de integração devem ser identificados e
difundidos. Em particular, requisitos de integração podem favorecer a reutilização ao serem
incorporados pela plataforma, reduzindo problemas relacionados e facilitando o atendimento de
prazos, possibilitando ainda a inovação pela comunidade e ajudando na criação de nicho.
As atividades de governança de ECOS podem auxiliar o keystone na identificação de atores e
artefatos críticos para a plataforma, internos e externos. Além disso, o keystone deve estabelecer
orientações quanto a atividades de teste pelos colaboradores de forma a garantir confiabilidade e
segurança de seus produtos para diferentes plataformas de ECOS. Por fim, colaboradores precisam
analisar e/ou comparar a saúde de diferentes ECOSs de interesse para tomar decisões nos projetos
de suas contribuições para a plataforma, e.g., sobre o planejamento de releases.
43
WDES
4. Considerações Finais
Este artigo apresentou uma discussão inicial sobre qualidade em ECOS. Alguns dos desafios de
qualidade em ECOS identificados são herdados do DDS, porém com uma amplitude de questões
relacionadas à arquitetura e modelos de negócio. Entre os itens chave de qualidade, estão a
aplicabilidade das metodologias atuais para maturidade e capacidade de processos de software em
relação a ambientes de ECOS e a gestão de conhecimento e aspectos sociais dos diferentes atores
com a finalidade de promover mais qualidade e saúde para os ECOSs. Além disso, devido à vasta
literatura de gestão do conhecimento, devem-se analisar possíveis adaptações de estratégias
existentes para os novos ambientes de desenvolvimento gerados pelos ECOSs. Não obstante o
amadurecimento das pesquisas mais voltadas para ECOS a partir de 2009 (Barbosa et al., 2013),
ainda são necessários trabalhos que investiguem o tópico de forma mais aprofundada. Como
próximos passos, pretende-se desenvolver um framework para gestão e monitoramento da qualidade
em ECOS, bem como explorar a qualidade de processos e produtos a partir de elementos de DDS.
Referências
Audy, J. & Prikladnicki, R. (2008) “Desenvolvimento Distribuído de Software”. Campus.
Axelsson, J. et al. (2014) “Characteristics of software ecosystems for Federated Embedded Systems: A case
study”. Information and Software Technology. In press.
Barbosa, O. et al. (2013) “A Systematic Mapping Study on Software Ecosystems through a Three-dimensional
Perspective”. In: Jansen, S. et al. (eds.) Software Ecosystems: Analyzing and Managing Business Networks in
the Software Industry, Edward Elgar, 59-81.
Bosch, J. (2009) “From Software Product Lines to Software Ecosystem”. In: SPLC, San Francisco, 1-10.
Cataldo, M., Herbsleb, J. (2010) “Architecting in Software Ecosystems: Interface Translucence as an Enabler for
Scalable Collaboration”. In: 4th ECSA, 2nd IWSECO, Copenhagen, 65-72.
Dittrich, Y. “Software engineering beyond the project – Sustaining software ecosystems”. Information and
Software Technology. In press.
Farias Junior, I. et al. (2013) “Reflexões sobre Comunicação no Desenvolvimento Distribuído no Contexto de
Ecossistemas de Software”. In: VII WDDS, Brasília, 52-59.
Fontão, A. et al. (2014) “MSECO Skill: Construção de Competências de Desenvolvedores em Ecossistemas de
Software Móvel”. In: XVII CIbSE, Pucón, 81-94.
Fotrousi, F. et al. (2014) “KPIs for Software Ecosystems: A Systematic Mapping Study”. In: 5th ICSOB, Paphos.
Gomes, V., Marczak, S. (2012) “Problems? We All Know We Have Them. Do We Have Solutions Too? A
Literature Review on Problems and Their Solutions in GSD”. In: ICGSE, Porto Alegre, 154-158.
Hartigh, E. et al. (2006) “The Health Measurement of a Business Ecosystem”. In: 6th Annual Meeting of the
European Chaos and Complexity in Organisations Network, Bergen aan Zee, 39p.
Hmood, A. et al. (2010) “OntEQAM – A Methodology for Assessing Evolvability as a Quality Factor in Software
Ecosystems IEEE Industrial Software Evolution and Maintenance Processes”. In: WISEMP, Montreal.
Jansen, S. et al. (2009) “A Sense of Community: A Research Agenda for Software Ecosystems”. In: 31st ICSE,
NIER, Vancouver, 187-190.
Jiménez, M. et al. (2009) “Challenges and Improvements in Distributed Software Development: A Systematic
Review”. Advances in Software Engineering 2009(3):1-16.
Maia, N. et al. (2013) “Elementos que Impactam o Planejamento de Testes em Ambientes de Desenvolvimento
Distribuído no Contexto de Ecossistemas de Software”. In: VII WDDS, Brasília, 60-67.
Manikas, K., Hansen, K. (2013) “Software Ecosystems – A Systematic Literature Review”. Journal of Systems
and Software 86(5):1294-1306.
Miranda, M. et al. (2014) “An exploratory study of the adoption of mobile development platforms by software
engineers”. In: 1st MOBILESoft, Hyderabad, 50-53.
Prikladnicki, R., Audy, J. (2010) “Process models in the practice of distributed software development: A
systematic review of the literature”. Information and Software Technology 52(8):779-791.
Sengupta, B. et al. (2006) “A research agenda for DDS”. In: 28th ICSE, Shanghai, 731-740.
Santos, R., Werner, C. (2012) “ReuseECOS: An Approach to Support Global Software Development through
Software Ecosystems”. In: VI WDDS, Porto Alegre, 60-65.
Valença, G. et al. (2013) “Analysing Requirements Negotiation in Software Ecosystems with Multi-Agent
Systems Techniques”. In: VII WDDS, Brasília, 44-51.
44
WDES
Towards the Dynamic Evolution of Context-based
Systems-of-Systems
Elisa Yumi Nakagawa1, Rafael Capilla2, Francisco J. Díaz3, and Flávio Oquendo4
1
2
3
University of São Paulo – USP, São Carlos, Brazil
University Rey Juan Carlos – URJC, Madrid, Spain
Ingeniería y Economía del Transporte – INECO, Madrid, Spain
4
IRISA - University of South Brittany – USB, Vannes, France
[email protected], [email protected],
[email protected], [email protected]
Abstract. Systems engineering has invested considerable efforts in the
development of complex-large systems, often known as Systems-of-Systems
(SoS). However, the systematization of current engineering practices based on
the inherent complexity and size of these systems is still challenging for
software engineers. In this light we focus in this paper on the evolution aspects
of SoS using dynamic variability techniques. We suggest paths where runtime
variability mechanisms can help to manage the evolution of such complexlarge systems.
1. Introduction
The discipline of Systems Engineering is considered an interdisciplinary field focused
on the design and management of large-scale systems [Sage 2000]. Systems engineering
deals with all those organizational and technical disciplines where a complex system is
considered and integrated as a whole. System engineering overlaps with other technical
and human-centered disciplines (e.g., control engineering, project management,
industrial engineering or mechatronics) aimed to produce and manage complex software
systems. Nowadays, the genesis and development of large Ultra-Large-Scale (ULS)
systems [Northrop 2006] perceived as a System-of-Systems (SoS) bring many
challenges from its conception to its maintenance and evolution.
SoS encompasses the integration of various operationally independent systems, even
developed with different technologies and for diverse platforms. An adequate
integration has been more and more necessary to promote cooperation among these
independent systems in order to provide more complex functions, which could not be
provided by any system working separately [Maier 1998]. One important challenge for
SoS development refers to its evolutionary development. Complex systems that exploit
context-awareness and modify their behavior at runtime demand more complex
maintenance procedures. As functions and purposes of SoS can change at runtime and
45
WDES
new constituents can be reassembled to perform a different mission, the challenge for
adaptive behavior in SoS demands specific solutions.
In this scenario, this paper discusses about SoS evolution. In particular, we focus on
addressing how dynamic variability techniques can support the evolution of such
complex systems. The remainder of this paper is as follows. In Section 2 we
characterize SoS from an architectural point of view. Section 3 discusses the evolution
and needs of SoS that demand dynamic adaptation and Section 4 motivates the role of
dynamic variability as key for the evolution of SoS. In Section 5 we outline the
application domain of Airport Management Systems and in Section 6 we suggest how
dynamic variability can help to develop and evolve better such large-scale systems.
Finally, in Section 7 we draw our conclusions and future work.
2. SoS Characterization
An SoS is constituted of various operational and managerially independent,
heterogeneous constituents interoperating and complying with a larger mission [DoD
2008]. Several examples of SoS can be identified; for instance, a medical system
integrating systems to diagnosis, treatment, and management of patients, airport system,
and avionics system, including several of them characterized as critical embedded
systems.
Two main characteristics are directly related to the constituent systems of an SoS: (i)
Operational independence: each constituent can deliver its own functionalities when not
working with other constituents; and (ii) Managerial independence: constituents keep
their own managerial sphere, being sometimes developed by diverse companies or other
institutions. In addition, considering the whole SoS, four characteristics are inherent: (i)
Emergent behavior: SoS can deliver new functionalities resulting from constituents
working together; (ii) Evolutionary development: functions and purposes of SoS can
dynamically change at runtime; (iii) Geographic distribution: constituents of an SoS can
be geographically distributed; and (iv) Runtime architecture: a new organization of the
constituents is sometimes necessary in order to comply with the SoS evolution. As
result of these characteristics, SoS becomes naturally unpredictable regarding to what
can happen during their execution. Moreover, unpredictability also characterizes the
environment where a SoS is being executed. Moreover, software essentially influences
the design, construction, deployment, execution, and even evolution of SoS. Therefore,
the backbone of the characteristics of both the constituents and the whole SoS is the
software-intensivity.
Considering the rise of software-intensive SoS and intending to systematize their
development, several initiatives from Software Engineering area can be identified. Both
academy and industry have invested efforts in that direction; however, in general, these
initiatives need still to be more experimented and matured. From the SoS software
architecture perspective, it is also required more research efforts. Software architectures
promote quality attributes, mainly interoperability, adaptability, security, reliability, and
performance, considered most relevant ones for SoS [Nakagawa 2013]. There are also
challenges that need be overcome, including the investigation and establishment of
approaches to create, represent, evaluate, and especially evolve these architectures.
Specifically, these architectures must be also prepared to support dynamic evolution, as
46
WDES
evolution has sometimes occurred without adequate, systematic control, resulting in
degradation of their quality.
3. SoS Evolution Challenges
Managing the complexity of SoS is not easy, demanding complex organizational
procedures. Several modern systems use context information to more efficiently
perform the possible variations and adaptation of their complex operations, which
require changes in their behavior. As the evolution of SoS is naturally a challenging,
complex task, SoS should optimally and adaptively manage the information and
resources according to varying context conditions (e.g., smart cities, intelligent
transportation, wireless sensors, or warfighter systems).
Viewing SoS as a software product line where many systems can interoperate to achieve
the desired functionality facilitates the development, evolution, and management of
SoS. As the variety of SoS can be huge, we will focus on this work on those systems
that require adaptive behavior and where the integration of complex technologies and
platforms demand a significant degree of systems engineering activities. From this
perspective, we state the following challenges focused in the SoS evolution:
Smart and runtime adaptation and reconfiguration: SoS with adaptive and
autonomous behavior should provide mechanisms to change their behavior at runtime
with minimal or none human intervention. Reconfiguration at runtime can be possible if
the solution provided is feasible and performed in many cases under strict timing
requirements;
Dynamic selection of choices: Many autonomous systems need to optimally make
runtime decisions. Hence, variability management at runtime is still a challenging task
for unforeseen scenarios;
Runtime management: The possibility of many critical complex systems to change
from one operational mode to another demands mechanisms where the system variants
can change at post-deployment time;
Awareness of runtime decisions: Software designers should be aware of which
runtime changes can affect to critical parts of the architecture. Consequently, there is a
strong need to notify the relevant stakeholders about critical runtime changes; and
Ripple effect of runtime decisions: As safety and reliability are important design
concerns, critical decisions made by an autonomous behavior may impact on other
critical parts of a complex system. Hence, we need solutions to track on the possible
deviations of the normal system’s operational mode when a change may cause damage
on other parts of the system.
4. The Role of Dynamic Variability
Software product lines have proven as a successful technique for building families of
related systems, often with a high degree of complexity. The evolution of a product line
is achieved on behalf of software variability techniques [Capilla 2013], which maximize
reuse and manage efficiently the variations of their family members. However, when
complex systems demand runtime solutions able to manage the variations of systems
47
WDES
dynamically, runtime variability becomes a relevant technique. Because managing the
variations at runtime is still in the infancy, the emerging parading of Dynamic Software
Product Lines (DSPLs) [Hinchey 2012] aims to manage the variations of systems at
execution time. In this regard we discuss in this section those DSPL techniques that can
be suitable for development and evolution of SoS systems that exploit contextawareness and runtime behavior.
Context-aware properties are the base to exploit runtime adaptation in many complex
systems. The evolution of SoS can be achieved better modeling the contextual
information using variability techniques. This contextual information of SoS that must
be managed at runtime enhances the behavior of the system and supports better the
evolution for unforeseen scenarios, as new functionality could be added, removed, or
changed dynamically. In addition, system dynamics is an approach of systems
engineering aimed to understand the behavior of complex systems over time. However,
one step beyond on simulation of the behavior of complex systems refers to those
solutions that can anticipate system changes at runtime. From a previous work we stated
the challenge for managing runtime variability [Capilla 2011] as a promising solution to
evolve SoS and which techniques can be suitable to model, change, and optimize the
variations that happen when the behavior changes [Capilla 2014]. Consequently,
runtime variability proves as a suitable technique for those SoS that demand adaptive
and sometimes unpredictable behavior during execution time. In next section we discuss
potential solutions at the architectural level for SoS that use context information and
demand runtime adaptation in order to address the evolution challenges described in
Section 3.
5. Airport Management Systems
Regarding the research methodology, in this preliminary work, we did an informal
analysis of the target application domain based on the long experience of one of the coauthors. We did not performed an exploratory case study [Robson, 2002; Runeson
2009] or more formal analysis, as in this position paper we only wanted to state the
main key areas where SoS development can be enhanced with dynamic variability
techniques for the development of complex critical systems. In this light, one important
domain suitable for SoS is the case of Airport Management Systems (AMS), which
encompasses the automation of airport procedures in various areas, such as information
systems, control and computerized remote controls, computer equipment, billing,
baggage handling, security, weather information, controls signaling, and allocation of
airport facilities, among others. All these key areas must work and cooperate in a
coordinate and synchronized manner to handle the normal airport’s operations and
reduce human intervention. At present, the trend is to achieve maximum integration to
maximize coordination and usage of resources and integrate middleware from different
vendors in order to guarantee real-time operations. Consequently, reliability, safety, and
security are major quality concerns addressed by this kind of system, many of them
redundant in the AMS. Some of the subsystems that belong to AMS are the following:
Airfield lighting control systems: this system controls the lighting aids installed on the
airport (runways, taxiways, stop bars, etc.), and in other cases light towers and
48
WDES
obstacles. In small airports this system is often integrated with the power control
system;
Weather information system: it is the responsible for acquiring, processing,
presenting, recording, and disseminating information on the prevailing weather
conditions at the airport and is vital for normal airport’s operations. This system
computes parameters extracted from a variety of sensors, such as wind speed and
direction, atmospheric pressure, rainfall and humidity detection, and it can compute
complex measures such as the Runway Visual Range (RVR);
Automatic baggage handling system: this system results key for the operation of large
airports as it depends of the number of passengers and the season where passengers
travel. It encompasses other subsystems that perform different functions with the
luggage (e.g., billing, transportation, security, classification, etc.) and is considered one
of the most cost-consuming systems in large airports; and
Airport security system: the aim of this system is to manage a wide variety of
subsystems and services to control intrusion detection and the inner perimeter using
CCTV cameras, access control, and fire detection sensors. Various security groups are
associated to different roles and stakeholders.
Other systems belonging to the AMS are: the electrical control system to ensure an
uninterrupted power supply using a large variety of sensors and analyzers, the
allocation of airport resources system, which uses large databases and real-time
information to allocate resources, and the standard communication system, which
interconnects basic services and all voice, radio, and internet communications. Many
other airport facilities can be integrated under the AMS, such as tunnel control system,
passenger information system, slot management system, parking control system, airport
GIS, aircraft docking systems, and many more.
As the large variety of subsystems and parameters is sometimes unmanageable for the
many situations that may occur in an airport, the integration and configuration of all
these system is hard. In many situations, the diversity and amount of the data managed
by these subsystems as well as the responses and operations they need to perform
depend on the state of other systems (e.g., a fire detection system can generate
automatic actions on the access control system and the automatic baggage handling
system, activating different alarms outside the airport). Consequently, the variations and
the diversity of runtime scenarios complicate the maintenance and evolution when new
requirements demand changes in the AMS. According to the SoS evolution challenges
described in Section 3, and in order to address the large number of scenarios that may
arise in the airport’s daily operations, we identified the following challenges that AMS
subsystems need to address regarding the dynamic adaptation and reconfiguration
operations:
Challenge 1: Diversity of information sources where much of the information comes
from the environment. As sensors belonging to different subsystems determine the
airport configuration in real time, the AMS should provide a way to integrate all the
information and distribute it to the implied stakeholders;
Challenge 2: Growing number of mobile employees that often use location services.
The AMS should manage such diversity of information, aiming to exchange important
data among systems and users in raw or cooked format, even outside the airport;
49
WDES
Challenge 3: Dynamic reconfiguration of systems that must be adapted to unforeseen
situations. The huge number of interfacing systems and the kind of data they share
becomes a problem to solve in case a system becomes off-line, in faulty situations or in
maintenance mode, in most cases without interruption of the airport operation; and
Challenge 4: Multilingual and multicultural support. Airlines systems from different
nationalities and different cultures must interact with the airport systems, so, the AMS
should interact with all the airlines systems operating on it. In every season, those
companies may change.
6. Building and Evolving AMS with Dynamic Variability
Considering the inherent characteristics and complexity of AMS and the challenges
stated in the previous section, we identified the following opportunities where static and
dynamic variability can play a role for building and maintaining some of the AMS
subsystems, such as we describe below:
Variability in Airfield lighting control systems: multivendor solutions integrated in a
single control system, include lighting control and single lamp fault signaling managed
in real-time;
Variability in Weather information system: small airports do not need to calculate the
parameters like Runway Visual Range (RVR) that might be replaced by a Visibility
Measurement (VM). Other parameters like wind conditions or temperature are
mandatory in big airports;
Variability in Automatic baggage handling system: the implementation of this
system varies from a really simple distribution system, to complex systems with
kilometers of installations and interfaces with many other systems, like fire detection or
security systems; and
Variability in Airport security system: the security system may vary from a simple
CCTV with a simple intrusion detection system in littlest airports, to really complex
systems in wider airports, integrating thousands of cameras, thousands of sensors of any
kind, and interfacing with many other systems in the airport or external to the airport.
6.1 Context-variability for AMS
Because many of the variations of these subsystems depend on sensor that analyze
context information at real-time, we adopt one of the strategy to model AMS context
properties using context variability techniques. As the large number of subsystems may
complicate to model all the variability at the same time, we preferred to adopt a strategy
focused on reuse, where context features are modeled using separated feature sub-trees
and in the case a subsystem or part of it is replaced by a more modern one, the context
variability sub-tree of that subsystem can be easily replaced in the feature model.
In Figure 1, we describe a layered reference architecture for AMS where we describe
the organization of the subsystems mentioned and where dynamic variability can be
used to managed the context properties of all these systems. Our approach uses a
context variability model to describe both context and non context features (right side of
Figure 1) but because the variability model is large, we only represent a subset of it. We
adopted the strategy to have different branches in the feature model to discriminate
50
WDES
between context and non-context features because of the following reasons: (i) non
context features in AMS are more stable; (ii) a separate context feature sub-tree is more
reusable in case we need to replace one of the subsystems; and (iii) context features that
can modify the structural variability at runtime are easily to anchor in the feature tree
under the right subsystem in case we need to add or remove features dynamically. By
contrary, having two separate feature sub-trees for each subsystem may add more
dependencies between features of each different subsystem.
Figure 1: Excerpt of the reference architecture of an Airport Management System (left side) and a subset
of the context variability to model (right side) that describes context and non-context features and those
that modify the structural variability at runtime (dotted lines).
6.2
Dynamic evolution of context variability
AMS have strong real-time requirements and runtime reconfiguration needs that require
a different treatment from the evolution point of view. For instance, new features in the
weather information system could be added at runtime through specific middleware.
This could be the case that an AMS will need to incorporate an insolation sensor aimed
to measure the amount of solar radiation energy received on a runaway. New context
features could be added or removed dynamically in the feature model, having an clear
impact on the structural variability of the AMS. Consequently, the evolution of the
variability of these systems and subsystems can be managed using dynamic variability
techniques such as those suggested in a previous work [Bosch 2012], and using the
notion of super-types (i.e., a taxonomy to group features under a common functionality)
to add and remove features at runtime. These dynamic variability techniques in
combination with context features can reduce human intervention during critical AMS
51
WDES
maintenance, as certain subsystems can be plugged into the AMS middleware at
execution time.
7. Conclusions
The inherent complexity of SoS like AMS, which are composed by a wide range of
systems and subsystems that must run coordinately at runtime, complicates the
deployment and evolution of such systems. In this scenario, context variability and
dynamic variability techniques, such as proposed in this work, become suitable for
dealing better with the evolution of unforeseen situations and for modeling the
variability and the diversity of scenarios that SoS must deal with. In this work, we have
presented challenges and suggested opportunities for applying dynamic variability in the
construction and maintenance of AMS. For the future work, we intend to get more
evidence about the viability of applying dynamic variability to more efficiently control
the construction of reconfigurable SoS, in the case, an AMS, and evolution of critical
operations of such system.
References
Bosch, J., Capilla, R. (2012) Dynamic Variability in Software-Intensive Embedded
System Families. IEEE Computer 45(10): 28-35.
Capilla, R., Bosch, J., Trinidad, P., Ruiz-Cortés, A., Hinchey, M. (2014) An Overview
of Dynamic Software Product Line Architectures and Techniques: Observations from
Research and Industry, Journal of Systems and Software 91(5), 3-23.
Capilla, R., Bosch, J., Kang, K-C. (2013) Systems and Software Variability
Management, Concepts, Tools and Experiences, Springer.
Capilla, R., Bosch, J. (2011) The Promise and Challenge of Runtime Variability, IEEE
Software 44(12), 93-95.
DoD. (2008) System Engineering Guide for Systems of Systems. Office of the Deputy
Under Secretary of Defense for Acquisition and Technology, Systems and Software
Engineering, Version 1.0.
Hinchey, M., Park, S., Schmid, K. (2012) Building Dynamic Software Product Lines,
IEEE Computer 45(10), 22-26.
Maier, M. W. (1998). Architecting principles for systems-of-systems. Systems
Engineering, 1, 4, 267-284.
Nakagawa, E. Y., et al. (2013) The State of the Art and Future Perspectives in Systems
of Systems Software Architectures, In SESoS’13, Montpellier, France, 13-20.
Northrop, L., et al. (2006) Ultra-Large-Scale Systems: The Software Challenge of the
Feature, Software Engineering Institute, Carnegie Mellon, Pittsburgh, USA.
Robson,C. (2002) Real World Research. Blackwell (2nd Ed.)
Runeson, P., Höst, M. (2009) Guidelines for conducting and reporting case study
research in software engineering, Empirical Software Engineering Journal 14(2),
131-164
Sage, A. P., Armstrong, J. E. (2000) Introduction to Systems Engineering, Wiley Series.
52
WDES
Towards the Evaluation of System-of-Systems Software
Architectures
Daniel Soares Santos1, Brauner Oliveira1, Milena Guessi1,
Flavio Oquendo2, Marcio Delamaro1, Elisa Yumi Nakagawa1
1
2
ICMC - University of São Paulo (USP)
São Carlos - Brazil.
IRISA - Université de Bretagne Sud (UBS)
Vannes - France.
{danielss, brauner}@usp.br, {milena, delamaro, elisa}@icmc.usp.br,
[email protected]
Abstract. Evaluation of software architectures is an important activity to the
quality of software systems, as it verifies conformance and completeness of
such architecture regarding requirements and goals. In another perspective,
Systems-of-Systems (SoS) have emerged as a new class of software systems,
which aggregates independent and heterogeneous constituent systems for
performing new, emergent capabilities. Likewise, evaluation of SoS software
architectures is also important for ensuring that important quality attributes
are met in the SoS. The main contribution of this study is to present current
challenges for evaluating SoS software architectures and point out important
perspectives of research in that direction. We observe that despite the several
proposals for evaluating software architectures of SoS, there is still no
consensus on exactly what should be evaluated in such architectures.
Moreover, there are several difficulties that need to be overcome.
1. Introduction
Software architecture is essential to the success of software intensive systems and plays
a key role in determining the quality of software systems. Decisions made at the
architectural level directly enable, facilitate, or interfere in the achievement of business
goals as well as of functional and quality requirements [Bass et al. 2012]. In this
context, the architectural evaluation can be used for comparing and identifying strengths
and weaknesses of different architectural alternatives. Evaluation can also guide the
maintenance or indicate new opportunities for enhancing software architectures. Finally,
evaluation is essential for ensuring that software architectures meet desired quality
attributes [Bosch 2000].
Several approaches for evaluating software architectures can be found in the
literature. Bosch (2000) identify four main groups for these evaluation approaches: (i)
experience-based methods, which are based on previous experience and domain
knowledge of consultants or developers; (ii) simulation-based methods, which typically
rely on a high level implementation of the software architecture for evaluating its
performance and accuracy; (iii) mathematical modeling methods, which use
mathematical proofs for evaluating operational quality requirements, such as
performance and reliability; and (iv) scenario-based methods, which evaluate a
53
WDES
particular quality attribute by creating scenario profiles. Each scenario describes an
intended use of the system by means of a concrete description of the quality
requirement. These scenarios help to identify architectural risks and its potential
consequences through an efficient and scalable way.
In parallel, software-intensive systems have become increasingly large and
complex, with their considerable dissemination in various application domains. In this
context, Systems-of-Systems (SoS) result from the integration of several constituent
systems that operate independently and could potentially be developed using different
technologies and platforms. An adequate integration has been more and more necessary
to promote cooperation among these independent systems in order to provide more
complex functions, which could not be provided by any system working separately. SoS
has been proposed for different domains, in particular, for critical embedded systems,
such as medical systems, airport systems, robotic and automotive [Nakagawa et al.
2013].
Besides interoperability, several other quality attributes are critical for SoS (e.g.,
performance, reliability and flexibility). However, it is quite challenging to meet these
quality attributes in SoS, as their constituents are often developed and maintained by
different organizations. Moreover, these organizations may have their own stakeholders,
development teams, and processes, which collaborate for increasing this challenge. In
this context, the evaluation of SoS software architectures could ensure that these quality
attributes are satisfied from the early stage of the SoS lifecycle. An early evaluation of
the software architecture quality also aids in validating architectural decisions.
In this scenario, the main goal of this paper is to present the main challenges in
evaluating SoS software architectures. For this, it was based on results of a Systematic
Literature Review (SLR)1. In this SLR, we surveyed the difficulties and challenges that
are inherent to SoS evaluation as a way of pointing out new, important research
perspectives in the software architecture area. Overall, 16 primary studies were included
in this SLR. The following discussion builds upon these studies.
The remainder of this paper is organized as follows. Section 2 presents a brief
introduction about current research on evaluation of SoS software architectures and
elaborates on the main quality attributes that have been addressed for such architectures.
Section 3 discusses the main challenges and difficulties for performing this evaluation.
Finally, Section 4 presents our final considerations and perspectives to future work.
2. Evaluation of SoS Software Architectures
Evaluation of software architectures usually occurs after the design of such architectures
but before implementation starts. Nonetheless, an architecture can be evaluated at any
stage of its life cycle [Clements et al 2002]. In particular, for SoS software architectures,
due to their characteristics, we have observed that most works have proposed
application of evaluation methods in the design phase, as well as in architectures already
established, intending to analyze their flexibility and ability to evolution. In our SLR,
we also identified several evaluation methods for SoS. Moreover, we also identified the
most common quality attributes considered during the evaluation of SoS software
architectures. The following sections summarize our findings.
1
Available at http://goo.gl/PU12iQ (last accessed on 07/13/2014)
54
WDES
2.1. Evaluation Methods
The processes for evaluation of SoS software architectures are typically supported by
different methods and techniques. These methods and techniques usually are adapted
and enhanced to create a new proposal for SoS software architectures. Overall, six of
the 16 works propose or use mathematical-modeling evaluation methods, four works
propose or use simulation-based methods, and six works propose or use scenario-based
methods. Among the scenario-based approaches, Architecture Trade-off Analysis
Method (ATAM) by [Kazman 2000] is the most popular one. This method deals with
multiple quality attributes, their relationships, and trade-offs at the architecture level in
order to gain insight about the compliance of the architecture implementation regarding
quality requirements and business objectives. In our SLR, it was not observed a
convergence in using a specific type of evaluation method. Besides that, we did not find
works that consider experience-based methods for evaluating SoS.
The suitability of the methods and techniques usually has been assessment
through expert opinion and experiences in real projects, proof of concept or
demonstration, case study, and application in industry. It is important to highlight that
all works selected to evaluation in the industrial context have proposed to use scenariobased evaluation methods. This result shows that these evaluation methods have been
well accepted by industry or at least that they could be scalable to SoS.
2.2. Quality Attributes
Evaluation methods can either focus on single or several quality attributes. Through
results of our SRL, all proposed scenarios-based methods do not focus on specific
quality attributes. The main reason is that scenarios-based methods usually focus
on identifying trade-off among different qualities attributes instead of measuring
each quality attribute. However, simulation-based and mathematical modeling methods
usually focus on one or a few tangible quality attributes. The most common quality
attributes considered by these methods are reliability, performance, operability,
complexity, and flexibility. However, we have observed that evaluation methods for
SoS should take into account several quality attributes. Moreover, these methods should
also be able of measuring and classifying these quality attributes in order to support an
accurate comparison among architectural alternatives. This may be possible through the
use of simulation-based in combination with scenarios-based approaches.
Finally, the use of quality models for evaluating SoS architectures would be
relevant, as they would provide standardization for quality attributes of SoS, as well as
establishment of relationships among such attributes. However, none of the works
included in our SLR discusses the use of quality models during architectural evaluation.
3. Challenges
We have also observed that there are several challenges for an adequate evaluation of
SoS software architectures. The following discussion focuses on the main challenges.
The reliability of the communication among constituent systems is an important
factor to the success of SoS [Urwin et al. 2010]. According to Stratton (2009), it is
difficult to ensure reliable communication through an architecture evaluation for several
reasons: (i) constituent systems are usually developed independently by different teams
55
WDES
at different places; (ii) specification of communication requirements is ambiguous; and
(iii) communication issues are often subtle and remain hidden for a long time.
Moreover, the complex interdependencies that exist among constituents make it difficult
to foresee the behavior of SoS due to an unexpected loss of one of their constituents. In
the worst, SoS could collapse or trigger a cascading failure among their constituents.
These consequences cannot be fully understood only through an architectural evaluation
of the independent systems, as SoS require an evaluation of the effect of
interdependence among constituents on the entire system [Guariniello, C. and
DeLaurentis 2014a].
Regarding the evolutionary and decentralized nature of SoS, it becomes difficult
to ensure, for instance, reliability, security, or performance, using architecture
evaluation methods, which focus exclusively on structural characteristics but ignore
behavior compliance. This could be a problem, as a simple divergence in the
implementation of one of the constituents often reduces performance and reliability of
the entire SoS [Chen et al. 2012, Ackermann et al. 2009 and Zhu et al. 2008]
Finally, an important step to an adequate architectural evaluation involves
identification of metrics to measure features of systems. However, metrics used to
evaluate individual systems can not directly deal with the characteristics of the SoS
[Guariniello and DeLaurentis 2014b]. This happens because the emergent behavior of
SoS usually cannot be captured and evaluated by evaluation approaches that address the
level of constituent systems [Meilich 2006].
4. Conclusion
This position paper briefly presents the most important results of our SLR about SoS
software architecture evaluation. Despite the number of initiatives to evaluate such
architectures, there is still no consensus on what exactly should be considered during
this evaluation. From our results, we observe that main challenges in the SoS
architecture evaluation are due to the complex interaction among constituent systems
and the evolutionary, distributed nature of SoS as well. Therefore, appropriate, scalable
evaluation approaches still need to be developed. Moreover, we envisage that these new
approaches should be able to successfully capture and evaluate the emergent behavior of
SoS.
As future work, we intend to continue our investigation on evaluation of SoS
architectures, updating this SLR as well as identifying appropriate architecture
evaluation methods that consider quality attributes usually addressed by SoS. Moreover,
we will investigate alternatives to combine these methods and techniques in order to
reduce the number of difficulties and challenges that are inherent to this new class of
complex, large software systems.
56
WDES
References
Ackermann, C., Lindvall, M. and Cleaveland, R. (2009) “Towards behavioral reflexion
models.” In ISSRE’2009, pages 175–184, Mysuru, India.
Bass, L., Clements, P. and Kazman, R. (2012) “Software Architecture in Practice”. SEI
Series in Software Engineering. Pearson Education.
Bosch, J. (2000) “Design and Use of Software Architectures: Adopting and Evolving a
Product-Line Approach”. ACM Press Series. Addison Wesley.
Chen, H.-M., Kazman, R. B. and Hong-Mei, C.. (2012) “Architecting ultra-large-scale
green information systems”. In GREENS’2012, pages 69–75, Zurich, Switzerland.
Clements, P., Kazman, R. and Klein, M. (2002) “Evaluating software architectures:
methods and case studies”. SEI series in software engineering. Addison-Wesley.
Guariniello, C. and DeLaurentis, D. (2014a) “Communications, information, and cyber
security in systems-of-systems: Assessing the impact of attacks through
interdependency analysis“. In CSER’2014, pages 720–727, Redondo Beach
California, USA.
Guariniello, C. and DeLaurentis, D. (2014b) “Integrated analysis of functional and
developmental interdependencies to quantify and trade-off ilities for system-ofsystems design, architecture, and evolution”. In CSER’2014, pages 728–735,
Redondo Beach, California, USA.
Kazman, R., Klein, M., Clements, P. (2000) "ATAM: A Method for Architecture
Evaluation". CMU/SEI-2000-TR-004. Software Engineering Institute. Carnegie
Mellon University.
Martensson, F. and Tekniska Hogskola, B. (2006) “Software Architecture Quality
Evaluation: Approaches in an Industrial Context”. Ph. D. thesis, Blekinge Institute of
Technology, Karlskrona, Sweden.
Meilich, A. (2006) “System of systems (SoS) engineering & architecture challenges in a
net centric environment”. In SoSE’2006, pages 1-5, Shanghai, China.
Nakagawa, E. Y., Gonçalves, M., Guessi, M., Oliveira, L. and Oquendo, F. (2013) “The
state of the art and future perspectives in systems of systems software architectures”.
In SESoS’2013, pages 13-20, Montpellier, France.
Stratton, W., Sibol, D., Lindvall, M., Ackermann, C. and Godfrey, S. (2009)
“Developing an approach for analyzing and verifying system communication.” In
IEEE Aerospace Conference, Big Sky, Montana, USA.
Urwin, E., Venters, C., Russell, D., Liu, L., Luo, Z., Webster, D., Henshaw, M. and Xu,
J. (2010) “Scenario-based design and evaluation for capability“. In SoSE’2010,
Loughborough, UK.
Zhu, L., Staples, M. and Jeffery, R. (2008) “Scaling up software architecture evaluation
processes”. In ICSP’2008, pages 112–122, Leipzig, Germany.
57
WDES
On the Relations between
Systems-of-Systems and Software Ecosystems
Rodrigo Santos1, Marcelo Gonçalves2, Elisa Yumi Nakagawa2, Cláudia Werner1
1
PESC/COPPE –Federal University of Rio de Janeiro, Rio de Janeiro, Brazil
2
ICMC/USP – University of São Paulo, São Carlos, Brazil
{rps, werner}@cos.ufrj.br, {marcelob, elisa}@icmc.usp.br
Abstract. Software development commonly involves many individuals, groups,
and organizations related by one or more central platforms. Moreover,
organizations have created and maintained products and services with
different technologies and for diverse application domains. In this scenario,
topics of research have arisen in the Software Engineering area in order to
adequately deal with such large, complex software systems. In this perspective,
Systems-of-Systems and Software Ecosystems are two topics that have been
separately investigated and, at the same time, they are complementary. In this
paper, we perform a preliminary discussion on how these topics are related to
each other, aiming at supporting collaborative research.
1. Context and Motivation
According to Boehm (2006), the increasing pace of change in the global industry is
driving organizations towards increasing levels of agility in their software development
methods, while their products and services are concurrently becoming more and more
software-intensive. It other words, software has represented a crucial element for most
of existing systems, since it impacts functions, resources, and risks in different sectors of
industry (Santos & Werner, 2011). Software-intensive systems have also become
increasingly ubiquitous, large, and complex, with considerable dissemination in various
application domains. In parallel, the software industry creates products, services, and
processes considering different facets and perspectives of value, because it produces
value realized by its stakeholders (e.g., companies, developers, clients and users). In this
perspective, Software Engineering (SE) community has defined the treatment of tangled
technical, economic, and social issues as important research themes (Boehm, 2006).
Diverse research topics have arisen in the SE area, in order to adequately deal
with such software systems. Recently, there has been a growing interest in a class of
software-intensive systems, known as Systems-of-Systems (SoS) (Maier, 1998), whose
constituents are themselves complex, heterogeneous, independent, and large. In another
perspective, organizations have opened up their software platforms and assets to others,
including a community of partners and 3rd-party developers over the world (Bosch,
2010). The set of actors, artifacts, and relations, either internal or external, over a
software platform has been called Software Ecosystems (SECO) (Messerschmitt &
Szypersky, 2003). SoS and SECO are two topics that have been still separately
investigated, but certainly they should be treated in a complementary way. We perform a
preliminary discussion on SoS and SECO as related research topics, promoting
opportunities for collaborative research. This paper is organized as follows: Sections 2
58
WDES
and 3 present an overview of SoS and SECO, respectively; Section 4 discusses relations
between SoS and SECO; and Section 5 provides some final considerations.
2. Systems-of-Systems Overview
In the last years, there has been a growing interest in research and development of SoS,
resulted from the integration of other independent and heterogeneous systems. These
systems are useful for several of society’s needs, such as healthcare, avionics, logistics,
energy, and transportation (De Laurentis & Crossley, 2005). Although SoS have several
definitions, there is a set of consensual characteristics (Maier, 1998): (i) the operational
independence in which all of the constituent systems of an SoS can deliver their
functionalities when not working in the SoS; (ii) the managerial independence in which
each constituent system can be individually managed; (iii) the evolutionary development
in which SoS may evolve over time to respond to changes in its environment, the
constituent systems, or in its requirements; (iv) the emergent behavior in which SoS
behaviors are the result of constituent systems working together and cannot be provided
by any of these systems alone; and (v) the geographical distribution in which the
constituent systems of an SoS are physically decoupled.
SoS exist to accomplish their major goals. That is, the constituent systems have
their own individual mission and contribute to the accomplishment of the global mission.
Moreover, both SoS and their constituent systems can have their respective stakeholders,
which can also have different perspectives of interest. Furthermore, SoS can assume
different categories, according to particular aspects (DoD, 2008): (i) virtual in which
there is no central control. Therefore, the constituent systems are independently managed
in a distributed and uncoordinated environment where the mechanisms to maintain the
whole SoS are not evident; (ii) collaborative in which the constituent systems voluntarily
collaborate more or less in order to address shared or common interests. In this case,
there is a central control that offers standards to enable the collaboration of the
constituent systems; (iii) acknowledged in which the goals, management, resources, and
central control of the SoS are recognized, but the constituent systems still retain their
independent management; and (iv) directed in which there is a central control and
specific main purposes. The constituent systems can have their operational and
managerial independence, but they are subordinated to the central control.
3. Software Ecosystems Overview
Components, services, and applications developed by the global software industry have a
direct relation with collaborators in promoting, distributing or selling, and evolving
software systems based on software technologies (platforms), the so-called SECO
(Messerschmitt & Szyperski, 2003). External and/or unknown developers are also
contributing to maintain and evolve these systems, changing the traditional value chain.
In this case, networks of multiple products and services over platforms should be used to
support the comprehension of relationships among organizations in SECO, focusing on a
business sense (Santos & Werner, 2011). On the other hand, social impacts should be
taken into account due to the socialization of SE (Mens & Goeminne 2011). The cycle of
creating, providing, and operating software systems occurs over a net of tangled
stakeholders. These elements contribute to (depend on) the propagation, amplification,
and expansion of platforms in the software industry. Thus, a community sense emerges
59
WDES
because business models are revisited in order to treat transactions/transfers in open
value chains (Santos & Werner, 2012). Both senses represent the trend of hybrid models
to manage and engineer software systems (Popp, 2012).
Some technical challenges are reinforced in SECO, especially regarding software
architecture (Bosch, 2010): (i) stability: once an organization is providing a platform for
external developers, interfaces should evolve in a predictable fashion and with significant
time for adjustments; (ii) simplicity: integration at each of the levels of data, workflow,
and UI integration should be designed to minimize the complexity of the final solution;
(iii) security and reliability: architecture should be designed to minimize defective and
malicious external code and vulnerabilities; and (iv) evolution: the scope of the platform
needs to be constantly adjusted upwards in order to incorporate functionalities based on
the community’s emerging requirements, but also slim down the platform through rearchitecting it to replace proprietary code with commercial or open source components.
4. SoS & SECO
SoS and SECO are two emerging, relevant research topics in SE area. However, it is
observed that typically the solutions for SECO and SoS are individually proposed by
isolated teams in order to meet particular domain-oriented problems. First of all,
according to Kazman et al. (2012), architectural challenges have motivated a number of
methods for the design, documentation, and analysis of the traditional single systems and
architectures over the past 10 years. Moreover, these methods share many of the same
principles, which can be used to systems of different scales. Aiming at helping the
comprehension of architecture in SECO, Klein & McGregor (2013) amplified the
concept of architecture to the so-called SoS platform, or “industry platform”, also
defined by Cusumano (2010). This kind of platform provides domain-specific and general
services to a set of systems that need to interact to form an SoS (Maier, 1998). From the
SECO viewpoint, an SoS platform can exist in an environment of different levels of
actors, artifacts, and relationships towards the development of globalized, large-scale,
and long-term products and services (Santos & Werner, 2012). These products and
services can be developed with different technologies, where integration and
communication are crucial, since they are software-intensive systems (Brown &
McDermid, 2007). Moreover, SoS platforms fulfill the inherent characteristics of SoS.
Additionally, the SoS concept started to gain its popularity mainly in military
domain as a strategy for reaching goals, or delivering unique capabilities that are the
result of a collaborative work of a dynamic set of existing systems (DoD, 2008). The
evolution of computational systems reveals that more software-intensive systems tend to
meet the SoS concept. Based on that, it is possible to identify many examples of studies
addressing new application domains where SoS is gaining ground, such as Smart Cities,
Global Earth Observation, and Critical Embedded Systems. On the other hand, the
SECO concept is popular in software business platforms and open source software
(OSS) domains (Manikas & Hansen, 2013). SECO can be seen as an application domain
for SoS as such (Kazman et al., 2012; Klein & McGregor, 2013; Axelsson et al., 2014).
SoS are typically complex, interdisciplinary systems whose functionalities and
purposes can dynamically evolve (Firesmith, 2010), encompassing several new
challenges to be developed (DoD, 2008). In turn, the concepts of virtual and
60
WDES
collaborative SoS have been explored in the SECO context, allowing collaboration of
different constituent systems and organizations in order to produce emergent
functionalities (Klein & Vliet, 2013). In both collaborative and virtual SoS, SECO are
more valuable because in these categories there is no strict control over the constituent
systems. As such, SECO concerns may aid SoS to leverage the network of actors in
order to deal with innovation from their constituent systems.
Despite the discussion on the SoS categories for SECO scenarios, we have
preliminarily drawn some similarities between SoS characteristics (Maier, 1998) and
SECO technical challenges (Bosch, 2010). For example, architectural stability required
for SECO platforms regarding to their components, services, and applications can be
compared to the operational independence of constituent systems of an SoS. In this case,
software systems integration and component-based development can be combined to
support strategies to cope with application programming interface issues. On the other
hand, platform evolution directly depends on the SECO community’s emerging
requirements and contributions, as well as the adjustments of underlying hybrid business
models. As such, SoS evolutionary development should take into account not only the
environment’s technical issues but also the business and social ones. In this case, SoS
architecture models should be extended to cope with context variables based on value
chains and social networks. Finally, emergent behavior produced by constituent systems
of an SoS working together can be related to the security and reliability in SECO.
System dynamics theory may be a useful instrument to simulate components
configurations in order to improve the architectural design.
5. Final Considerations
Both academia and industry have recognized the importance of SoS and SECO to an
effective development of software systems. In this perspective, more joint research must
be conducted since the notion of SECO may be at least as generalizable as SoS
themselves. As future work, we intend to investigate how SECO platforms can benefit
from SoS mindset and how SoS can benefit from business and social networks. We also
intend to evaluate the interactions between SoS and SECO in order to more clearly state
differences and similarities of such systems from an SE perspective through conduction
of a systematic mapping study. Finally, a few more concrete implications for Distributed
Software Development (DSD) will be investigated and discussed, since one of the
SoS/SECO characteristics is the potentially distributed nature.
References
Axelsson, J. et al. (2014) “Characteristics of software ecosystems for Federated
Embedded Systems: A case study”. Information and Software Technology. In press.
Boehm, B. (2006) “A View of 20th and 21st Century Software Engineering”. In: 28th
International Conference on Software Engineering (ICSE), Shanghai, China, 12-29.
Bosch, J. (2010) “Architecture Challenges for Software Ecosystems”. In: Proceedings of
the 4th European Conference on Software Architecture (ECSA), 2nd International
Workshop on Software Ecosystems (IWSECO), Copenhagen, Denmark, 93-95.
61
WDES
Brown, A., McDermid, J. (2007) “The art and science of software architecture”. In: 1st
European Conference on Software Architecture (ECSA), Aranjuez, Spain, 237-256.
Cusumano, M. (2010) “The Evolution of Platform Thinking”. Communications of the
ACM 53(1):32-34.
De Laurentis, D., Crossley, W. (2005) “A taxonomy-based perspective for systems of
systems design methods”. In: IEEE International Conference on Systems, Man and
Cybernetics (SMC), Waikoloa, USA, 86-91.
DoD (2008) “System engineering guide for systems of systems”. Technical Report,
Version 1.0, August 2008.
Firesmith, D. (2010) “Profiling systems using the defining characteristics of systems of
systems”. Technical Note CMU/SEI-2010-TN-001, Software Engineering Institute.
Kazman, R. et al. (2012) “Scaling up software architecture analysis”. Journal of Systems
and Software 85(7):1511-1519.
Klein, J., McGregor, J. (2013) “System-of-Systems Platform Scoping”. In: 4th
International Workshop on Product Line Approaches in Software Engineering
(PLEASE), San Francisco, USA, 1-4.
Klein, J., Vliet, H. (2013) “A Systematic Review of System-of-systems Architecture
Research”. In 9th International Conference on Quality of Software Architectures
(QoSA), Vancouver, Canada, 13-22.
Maier, M. (1998) “Architecting principles for systems-of-systems”. System Engineering
1(4):267-284.
Manikas, K., Hansen., K. (2013) “Software Ecosystems – A Systematic Literature
Review”. Journal of Systems and Software 86(5):1294-1306.
Mens, T., Goeminne, M. (2011) “Analysing the Evolution of Social Aspects of Open
Source Software Ecosystems”. In: 3rd International Workshop on Software
Ecosystems (IWSECO), Brussels, Belgium, 77-88.
Messerschmitt, D., Szyperski, C. (2003) “Software Ecosystem: Understanding an
Indispensable Technology and Industry”. The MIT Press.
Popp, K. (2012) “Leveraging Open Source Licenses and Open Source Communities in
Hybrid Commercial Open Source Business Models”. In: 4th International Workshop
on Software Ecosystems (IWSECO), Boston, USA, 33-40.
Santos, R., Werner, C. (2011) “Treating Business Dimension in Software Ecosystems”.
In: 3rd ACM/IFIP International Conference on Management of Emergent Digital
EcoSystems (MEDES), San Francisco, USA, 197-201.
Santos, R., Werner, C. (2012) “Treating Social Dimension in Software Ecosystems
through ReuseECOS Approach”. In: 6th IEEE International Conference on Digital
Ecosystems and Technologies – Complex Environment Engineering (DEST-CEE),
Campione d’Italia, Italy, 1-6.
62

WDES - Instituto de Computação - Universidade Federal de Alagoas

Transcrição

Documentos relacionados

Questions 1-4 refer to Reading A Reader`s Digest, Sept. 2006

É tempo de analisar e fazer uma completa reflexão sobre a vida

Science without borders reflection (PDF - 57KB)

Juramento de Maimônides

TRIBUNA 152.pmd

Why should I pledge to image gently®?

Acesse o poema Lady Lazarus.

TRIBUNA LAYOUT 160.pmd

For Our World Para Nosso Mundo.

Clique aqui para ler