WDES ANAIS 2014 v1 PDF

Congresso Brasileiro de Software: Teoria e Prtica
28 de setembro a 03 de outubro de 2014 Macei/AL
VIII Workshop de Desenvolvimento Distribudo 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 Distribudo de

Software, Ecossistemas de Software e Sistemas de
Sistemas
COORDENADORES DO COMIT DE PROGRAMA
Cludia Werner - Universidade Federal do Rio de Janeiro (UFRJ)
Elisa Yumi Nakagawa - Universidade de So Paulo (USP)
Sabrina Marczak - Pontifcia Universidade Catlica do Rio Grande do Sul (PUCRS)
COORDENAO DO CBSOFT 2014
Baldoino Fonseca - Universidade Federal de Alagoas (UFAL)
Leandro Dias da Silva - Universidade Federal de Alagoas (UFAL)
Mrcio Ribeiro - Universidade Federal de Alagoas (UFAL)
REALIZAO
Universidade Federal de Alagoas (UFAL)
Instituto de Computao (IC/UFAL)
PROMOO
Sociedade Brasileira de Computao (SBC)
PATROCNIO
CAPES, CNPq, INES, Google
APOIO
Instituto Federal de Alagoas, Aloo Telecom, Springer, Secretaria de Estado do Turismo
AL, Macei Convention & Visitors Bureau, Centro Universitrio CESMAC e Mix Cpia
WDES
PROCEEDINGS
Volume 02
ISSN 2178-6097
AutoSoft 2014
VIII Workshop de Desenvolvimento Distribudo de

Software, Ecossistemas de Software e Sistemas de
Sistemas
PROGRAM CHAIR
CBSOFT 2014 GENERAL CHAIRS
ORGANIZATION
Universidade Federal de Alagoas (UFAL)
Instituto de Computao (IC/UFAL)
PROMOTION
Sociedade Brasileira de Computao (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 Universitrio CESMAC and Mix Cpia
WDES
Autorizo a reproduo parcial ou total desta obra, para fins acadmicos, desde que citada a fonte
WDES
Apresentao
Visando unir competncias e promover a integrao entre reas de pesquisa
correlatas, o Workshop de Desenvolvimento Distribudo de Software (WDDS), em sua
oitava edio, amplia a sua abrangncia, dando origem ao Workshop de
Desenvolvimento Distribudo de Software, Ecossistemas de Software e Sistemas de
Sistemas (WDES 2014). Esse evento constitui um frum para apresentao e discusso
de resultados e experincias de pesquisadores e praticantes das reas de
Desenvolvimento Distribudo de Software (DDS), Ecossistemas de Software (ECOS) e
Sistemas de Sistemas (SoS), visando a gerao de conhecimento que possa viabilizar
projetos de sucesso nessas trs reas e/ou nas suas relaes. Esse movimento
comeou durante as discusses realizadas nas edies de 2012 e 2013 do WDDS, o que
resultou na publicao de artigos que relacionaram as reas de pesquisa.
O Comit Diretivo do WDES 2014 constitudo por trs pesquisadores de cada uma
das trs reas envolvidas no workshop. Por sua vez, o Comit de Programa do WDES
2014 formado por 16 pesquisadores de instituies do Brasil (9) e do exterior (7),
com atuao e produo relevantes nas reas de pesquisa envolvidas no workshop. Os
membros do Comit de Programa conduziram um processo rigoroso de reviso, sendo
que cada artigo foi avaliado por pelo menos trs membros. Alm disso, visando
ampliar as discusses durante o workshop, esta edio conta tambm com artigos
convidados, escritos por especialistas das reas.
com satisfao que damos as boas-vindas aos autores e apresentadores de artigos,
da academia e da indstria. Tambm recebemos com grande prazer os demais
participantes do CBSoft 2014, que gostaramos de convidar a tomar parte ativamente
das discusses e momentos de integrao proporcionados pelo workshop.
Adicionalmente, gostaramos de agradecer a todos os demais autores que
submeteram seus artigos, aos membros do Comit Diretivo, Comit de Programa e
Comit de Organizao, e aos organizadores e patrocinadores do CBSoft 2014 pelo
suporte na realizao deste workshop.
Esta edio organizada conjuntamente pela Universidade Federal do Rio de Janeiro
(COPPE/UFRJ), Universidade de So Paulo (ICMC/USP) e Pontifcia Universidade
Catlica do Rio Grande do Sul (PUCRS), sob a coordenao das professoras Cludia
Werner, Elisa Yumi Nakagawa e Sabrina Marczak, respectivamente. O Comit de
Organizao conta com o apoio dos doutorandos Rodrigo Pereira dos Santos, Lucas
Bueno Ruas de Oliveira, Marcelo Benites Gonalves e Bernardo Jos Estcio. O evento
realizado no Centro de Convenes Ruth Cardoso, em Macei, Alagoas, no dia 28 de
setembro, em conjunto com o V Congresso Brasileiro de Software: Teoria e Prtica
(CBSoft 2014).
Esperamos que tenham uma tima estada em Macei
Cludia, Elisa e Sabrina
Organizadoras do WDES 2014
WDES
Comits Tcnicos / 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 So Paulo (USP)
Renata Pontin de Mattos Fortes - Universidade de So Paulo (USP)
Comit do programa / Program Committee
Vander Alves - Universidade de Braslia (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 Tecnolgica do Paran (UTFPR)
John Mcgregor - Clemson University, United States of America
Leonardo Murta - Universidade Federal Fluminense (UFF)
Rafael Prikladnicki - Pontifcia Universidade Catlica 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
Dnis Leonardo Zaniro - Universidade de So Paulo (USP)
WDES
Comit organizador / Organizing Committee

COORDENAO GERAL
COMIT LOCAL
Adilson Santos - Centro Universitrio Cesmac (CESMAC)
Elvys Soares - Instituto Federal de Alagoas (IFAL)
Francisco Dalton Barbosa Dias - Universidade Federal de Alagoas (UFAL)
COORDENADORES DO WDES 2014
WDES
ndice / Table of Contents

Um Framework para Gerenciamento de Riscos em Projetos de
Desenvolvimento Distribudo de Software
Jefferson Barbosa, Ivaldir de Farias Junior, Sabrina Marczak, Rodrigo Santos e
Hermano Moura
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 Vises para Apoiar a

Governana 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 Valena, Davi Viana, Bernado Estcio, Awdren
Fonto, 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 Gonalves, Elisa Yumi Nakagawa e Claudia Werner
58
WDES
Um Framework para Gesto de Riscos em Projetos de

Desenvolvimento Distribudo de Software
Jefferson Ferreira Barbosa, Ivaldir de Farias Junior, Sabrina Marczak,
Rodrigo Pereira dos Santos, Hermano Moura
Centro de Informtica Universidade Federal de Pernambuco (UFPE)

FACIN Pontifcia Universidade Catlica de Porto Alegre (PUCRS)
PESC/COPPE Universidade Federal do Rio de Janeiro (UFRJ)
{jfb2, ihfj, hermano}@cin.upfe.br, sabrina.marczack@pucrs.br,
rps@cos.ufrj.br
Abstract. Risk management is considered a critical factor for Distributed Software

Development (DSD) projects since the lack of proper identification of the projects 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 crticos para projetos de
Desenvolvimento Distribudo de Software (DDS) visto que a identificao de riscos
determina as incertezas que podem levar ao seu sucesso ou fracasso. Este artigo
apresenta um framework para a gesto de riscos em projetos DDS utilizando prticas
geis. O framework foi desenvolvido com base na literatura. Realizou-se uma avaliao
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. Introduo
O Desenvolvimento Distribudo de Software (DDS) tem atrado a ateno da indstria
nos ltimos anos, levando organizaes a mudarem a maneira como gerenciam seus
negcios em busca de menores custos, melhores profissionais, entre outras vantagens
(Audy & Prikladnicki, 2007). Projetos DDS trazem muitas vantagens, porm tambm
tm desafios, tais como a dificuldade de comunicao e a gesto de riscos, dentre outros
(Zanoni & Audy, 2003; Leme et al., 2007). Nestes projetos, os riscos tendem a ser
dinmicos devido multiplicidade dos vrios aspectos, i.e., mltiplas localizaes,
culturas, equipes, padres e tecnologias (Mudumba & Lee, 2010).
Assim, frameworks, processos, boas prticas e ferramentas associadas gesto
de riscos tm sido propostos para melhorar a identificao, anlise, monitoramento e
controle de riscos no gerenciamento de projetos DDS e melhorar a qualidade do produto
de software desenvolvido (Persson et al., 2009). Nessa direo, este trabalho tem como
objetivo investigar a seguinte questo de pesquisa: A concepo de um framework
composto por prticas geis pode auxiliar a gesto de riscos em projetos DDS?
2. Gerenciamento de Riscos em DDS

Um risco uma probabilidade de alguma circunstncia 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 gesto dos riscos em projetos de software muito importante, seja o projeto
co-localizado ou distribudo. A gesto deve contemplar os processos de identificao,
anlise e resposta aos riscos do projeto para minimizar as consequncias de eventos
negativos (Zanoni & Audy, 2003).
No DDS, a gesto 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 crticos de sucesso de risco e a segunda foca na viso da gesto de riscos
como atividade crtica na organizao para o sucesso destes projetos. Outros desafios
tambm foram desencadeados pela gesto de riscos em projetos DDS: tempo dedicado
gesto propriamente dita; envolvimento dos stakeholders na identificao dos riscos; uso
de mtodos para avaliao quantitativa de riscos; treinamento para a correta
identificao dos riscos; falta de um processo para essa gesto, adaptado realidade da
organizao; falta de um planejamento formal de resposta aos riscos; ausncia de
incentivo constante proatividade e comunicao; utilizao de uma ferramenta de apoio
ao processo; manuteno de um histrico 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 ateno dos praticantes de
DDS por causa de sua flexibilidade com relao s frequentes tentativas aplicadas para
dinamizar a gesto do projeto de forma proativa (Hossain et al., 2009). As prticas geis
tm sido adotadas como forma de melhorar o desempenho de projetos distribudos no
que tange especialmente a melhoria da comunicao, gesto de mudanas, riscos,
requisitos etc. (mite et al., 2010). Nesse sentido, uma viso clara da gesto de riscos
representa um grande desafio aplicao dessas prticas para a gesto 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 gesto de riscos denominado
SoftRisk. Este modelo se baseia na ideia de documentao, utilizao de dados histricos
e foco nos principais riscos com o objetivo de reduzir esforo e tempo na gesto e
mitigao desses riscos. Seus passos so: identificao dos riscos; probabilidade dos
riscos e estimativa de magnitude; documentao dos riscos; anlise; priorizao dos dez
principais riscos; monitoramento; controle; e execuo de operao estatstica. SoftRisk
trata a gesto de riscos em projetos com disperso geogrfica e em equipes virtuais.
Porm, trata de forma parcial a definio de papis dos stakeholders nesta gesto. Por
fim, no discute questes impostas por diferenas culturais em DDS, o que apontado
como uma limitao 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 contribuio desses autores foi elaborada a partir de
uma reviso sistemtica da literatura, que sintetizou riscos e tcnicas de resoluo. As
reas de risco identificadas foram: distribuio das tarefas, gerenciamento do
conhecimento, distribuio geogrfica, estrutura de colaborao, distribuio cultural,
relacionamentos entre os stakeholders, infraestrutura de comunicao e configurao da
10
WDES
tecnologia. Esse framework trata o envolvimento dos stakeholders e os papis que eles
tm na gesto de riscos de maneira superficial, ou seja, no existe uma sistematizao da
identificao dos atores e suas atribuies/responsabilidades dentro do projeto.
Hossain et al. (2009) identificaram reas e fatores de risco envolvidos no
gerenciamento de projetos DDS utilizando prticas de desenvolvimento gil de software.
A contribuio de Hossain et al. (2009) veio de uma reviso sistemtica da literatura
sobre o uso de prticas de Scrum em projetos DDS. Como resultado, foram identificados
desafios, reas de risco, estratgias e prticas atuais para a mitigao desses riscos e, em
seguida, foi proposto um framework conceitual. Esse framework conceitual formado
por dois componentes, classificados em: principais reas de risco e estratgias atuais para
a reduo desses riscos. Na viso dos autores, este framework precisa evoluir para
manter uma comunicao contnua, i.e., divulgao constante dos riscos do projeto, pois
esse um fator crtico de sucesso.
A Tabela 1 traz uma sntese dos trabalhos relacionados. Os critrios de
comparao foram selecionados com base em (Ramesh et al., 2006), (Keshlaf & Riddle,
2010) e (mite et al., 2010). As abordagens analisadas trazem significantes resultados
gesto de riscos em projetos DDS, porm ainda existem lacunas a serem tratadas. O
presente trabalho define o framework RADS para gesto de riscos em projetos DDS
como forma de preenchimento das lacunas no atendidas pelas abordagens apresentadas
nessa seo. RADS tem seu diferencial na utilizao de prticas geis na gesto de
riscos, clara identificao dos atores envolvidos e premissa de que a gesto de riscos
precisa de uma comunicao contnua no decorrer do projeto, por meio de relatrios,
reunies, dentre outros meios formais para as partes interessadas.
Tabela 1 Comparao dos trabalhos relacionados
SoftRisk
(Keshlaf &
Hashim, 2000)
AP
N
AP
AP
N
Critrios
Contexto DDS
Utilizao de prticas geis
Definio dos papis/Envolvimento dos Stakeholders
Definio de papis na gesto de risco
Comunicao contnua 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 = No atende
4. Metodologia
A pesquisa conduzida para a definio do framework foi organizada em quatro fases
(Figura 1). O procedimento para fundamentar a proposta do framework foi a realizao
de uma reviso bibliogrfica 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 questo de pesquisa. Baseado nos resultados dessas fases, na Fase 3,
definiu-se a verso inicial do framework. Finalmente, na Fase 4, executou-se um survey
com especialistas em DDS com experincia em projetos geis, com o objetivo de avaliar
se o mesmo pode auxiliar na gesto de riscos em projetos DDS, analisar a aplicabilidade
do framework em projetos reais e identificar oportunidades de melhoria em relao sua
estrutura. O questionrio do survey avaliou preliminarmente a verso inicial do
framework. O resultado desta avaliao apresentado na Seo 6.
11
WDES
Figura 1 Metodologia da Pesquisa
5. O Framework para Gesto de Riscos em Projetos de DDS

O framework RADS (Figura 2), acrnimo para Risco, gil, Distribudo, Software, foi
construdo inicialmente a partir da literatura e posteriormente objeto de anlise crtica de
especialistas em desenvolvimento gil e DDS. Com a perspectiva de ser um framework
de fcil utilizao, optou-se por no impor uma tcnica mais adequada do que outra para
definir seus componentes. O RADS composto por trs reas: i) gesto global de riscos,
ii) gesto de riscos em equipes distribudas e iii) identificao dos atores na gesto de
riscos. Cada rea composta por subreas e elementos, descritos na Tabela 2.
Figura 2 Representao grfica do framework RADS
O framework RADS utiliza prticas geis para o tratamento de riscos em DDS. O

RADS se inicia com a rea de Gesto Global de Riscos, que busca consolidar todos os
riscos identificados inicialmente pelas equipes distribudas do projeto (centralizar as
informaes) e divulgar essas informaes para as partes interessadas. Por sua vez, na
rea de Gesto de Riscos em Equipes Distribudas, busca-se realizar a identificao dos
riscos durante as iteraes do projeto. Alm disso, so contempladas a anlise, mitigao
e aplicao das estratgias de riscos para o projeto em questo. Por fim, tm-se a rea de
Identificao de Papis na Gesto de Riscos, definidos pelo framework.
12
WDES
Tabela 2 Descrio das reas, subreas e elementos do RADS

rea
Gesto Global
de Risco
Subrea
Reunio Global
Planejamento da
Sprint
Gesto de Risco
em Equipes
Distribudas
Execuo da
Sprint
Reviso da
Sprint
Identificao de
Papis na
Gesto de Risco
Elemento
Descrio do Elemento
Reunio Global de
Consolidao
Consolidao global dos riscos identificados pelas equipes distribudas. Esta reunio
tem a superviso do Gerente Global de Riscos.
Reunio Global de
Divulgao
Divulgao dos riscos identificados e priorizados para a prxima sprint para as

equipes geograficamente dispersas.
Identificao dos
Stakeholders
Identificao e participao dos vrios stakeholders envolvidos no processo de gesto

de riscos independente da disperso geogrfica desse stakeholder.
Identificao dos
Riscos
Processo de identificao dos riscos por parte da equipe distribuda.
(Boehm, 1991; Keshlaf & Hashim, 2000;

Hossain et al., 2009; PMI, 2013)
Processo de priorizao da lista criada no passo de Identificao de Riscos.
(Boehm, 1991; Keshlaf & Hashim, 2000;

PMI, 2013)
Anlise dos
Riscos
Referncias
(Persson et al., 2009)
(Nyfjord & Kajko-Mattsson, 2007;

Persson et al., 2009; PMI, 2013)
Planejamento de
Resposta aos Riscos
Processo de definio, documentao e incluso no backlog da sprint ou backlog do

projeto das aes necessrias para aceitao, transferncia e mitigao dos riscos
identificados e priorizados nos passos anteriores.
(Boehm, 1991; Ebert et al., 2008;

Hossain et. al., 2009);
Aplicao das Estratgias

de Mitigao dos Riscos
Execuo das estratgias de mitigao de riscos alocadas para as equipes distribudas

dentro da execuo da sprint.
(Nelson et al., 2008)
Identificao de
Novos Riscos
Processo de reviso da lista de riscos aps a execuo de uma sprint, pois novos
riscos podem surgir.
(Boehm, 1991; Nelson et al., 2008)
Status do Plano de
Mitigao dos Riscos
Neste passo, apresentado o status do plano de mitigao de riscos, informando se

houve necessidade de execuo do plano e atualizao de estratgias de mitigao
para novos riscos identificados na reviso da sprint.
Gerente Global do Projeto
Papel responsvel pela coordenao da gesto de riscos no nvel global, ou seja, de

todo o projeto.
(Nelson et al., 2008;

Ribeiro & Gusmo, 2008)
Gerente Global de Riscos
Papel responsvel por gerenciar as atividades de priorizao, consolidao e

divulgao dos riscos identificados pelas equipes para o Gerente Global do Projeto.
(Nelson et al., 2008;

Ribeiro & Gusmo, 2008)
Analista de Riscos
Equipes Distribudas
Cliente
Papel responsvel por gerenciar as atividades de risco das equipes.

Equipes responsveis pela identificao de stakeholders, de riscos, anlise dos riscos,
e documentao das estratgias de mitigao das equipes distribudas.
Responsvel por fazer a validao e priorizao dos riscos.
13
(Nyfjord & Kajko-Mattsson, 2007;

Persson et al., 2009; PMI, 2013)
Melhoria sugerida pelos especialistas
aps aplicao do questionrio.
WDES
6. Avaliao Preliminar do Framework RADS

Realizou-se um survey com o objetivo de avaliar, com profissionais da rea de TI com
experincia em projetos DDS e em projetos geis, se o framework atende ao objetivo de
auxiliar na gesto de riscos em projetos DDS. Avaliou-se ainda o uso de prticas geis
para potencializar a gesto de riscos neste tipo de projeto, dado que o framework
composto por este tipo de prticas. O questionrio de avaliao online foi enviado para
71 pesquisadores que pertencem comunidade do Workshop de Desenvolvimento
Distribudo de Software (WDDS, 2013) e para departamentos de TI dos seguintes
rgos pblicos, dado o acesso dos autores: Ministrio Pblico da Paraba, Tribunal de
Justia da Paraba, Tribunal Regional do Trabalho da Paraba e Tribunal Regional
Eleitoral da Paraba; Conselho Nacional do Ministrio Pblico de Braslia; Companhia de
Processamento de Dados da Paraba; e organizaes privadas: Unimed (Paraba e do Rio
de Janeiro), Incorptech de Pernambuco e Apple Inc. (EUA). Obteve-se um total de 28
respostas (39,4%). O questionrio ficou disponvel por duas semanas em novembro de
2013. O nmero de respondentes superou a mdia de respostas esperada por Marconi &
Lakatos (2003), que de 25% de devolues em questionrios aplicados online.
Os profissionais que responderam ao questionrio, entre suas caractersticas, tm
30 anos de idade em mdia; so gerentes de projetos e lderes de escritrio de projeto
(PMO); possuem em mdia quatro anos de experincia em DDS; as instituies onde
trabalham adotam o PMBOK como conjunto de boas prticas no gerenciamento de
projetos; e eles tm experincia em mdia de um ano com gerenciamento de projetos
geis. Todos so formados na rea de Computao e so ps-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 aderncia da aplicao do RADS ao DDS, as
respostas sugerem que o framework deve ser amadurecido em relao sua aplicao na
indstria. Neste sentido, os respondentes que concordaram e os que concordaram
totalmente (39%) afirmaram que importante o desenvolvimento de solues
acadmicas para gerar opes de escolha para o mercado.
Sobre a adoo de prticas geis no Framework RADS
Com relao a essa questo, 3 (11%) dos respondentes concordaram totalmente, 8
(28,5%) concordaram e 11 (39%) concordaram parcialmente de que a adoo de
prticas 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, no abordam como aplicar as suas prticas em um contexto
distribudo. Desta forma, necessria alguma interveno ou apoio, ou seja, alguma
iniciativa para conceber metodologias, frameworks ou guias de boas prticas, que ajudem
a minimizar os desafios enfrentados por equipes distribudas. Entre as razes daqueles
que discordaram, a principal foi que o RADS no tem uma equipe multidisciplinar.
14
WDES
Sobre a definio dos papis do Framework RADS

Dentre os 28 respondentes, 4 (14%) dos respondentes concordaram totalmente, 15
(54%) concordaram e 7 (25%) concordaram parcialmente que os papis descritos e suas
atribuies so suficientes para a gesto de riscos em projetos de DDS. Por outro lado, 1
(3,5%) discordou parcialmente e 1 (3,5%) discordou totalmente. Apesar da maior
aceitao da definio dos papis do RADS, os comentrios dos respondentes indicaram
que o framework no gil em si, mas que ele faz o bom uso de prticas geis. Mesmo
os respondentes sabendo que o framework no foi concebido exclusivamente para
projetos geis, esta percepo se deu devido ao fato do framework definir papis
hierarquizados, o que contrrio definio de papis em equipes geis.
Sobre a comunicao contnua 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 instituies onde trabalham. Em contrapartida, 3 (11%) discordaram parcialmente, 1
(3,5%) discordou e 2 (7%) discordam totalmente. A busca por uma comunicao 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 comunicao contnua
(clara e objetiva) contribui significativamente para o sucesso do projeto gera mais
confiana entre os stakeholders.
Melhorias sugeridas para o Framework RADS
Os respondentes reforaram que existe uma necessidade de melhorar a denominao dos
papis, bem como alinhar as definies dos papis com aqueles existentes nas
metodologias geis, pois estes no apregoam o conceito comando-controle, mas sim
equipes mais multidisciplinares. Eles tambm sugeriram a utilizao, de forma mais
explcita, do papel cliente ou um representante do cliente, pois, independente do
projeto, o papel do cliente bastante relevante, sobretudo na gesto de riscos.
7. Consideraes Finais
O crescente interesse das organizaes na utilizao de tcnicas de DDS despertou
algumas questes sobre as etapas do ciclo de gerenciamento de projetos deste tipo. Entre
as atividades envolvidas, est a gesto de riscos. Neste contexto, o framework RADS
busca contribuir para a melhoria do cenrio de gerenciamento de projetos, em especial
no que diz respeito gesto de riscos em organizaes que utilizam DDS. O framework
contempla elementos identificados na literatura, inspirados nas metodologias geis, em
busca de um desenvolvimento de software mais dinmico. A avaliao preliminar do
framework por especialistas indicou que ele tem potencial para ser aplicado na indstria e
est coerente com as necessidades de gesto de riscos em projetos DDS.
Como trabalho futuro, pretende-se aplicar o RADS em casos reais de projetos
DDS para avaliar a sua eficincia e eficcia. Apesar da limitao de no 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 alcanados so de
contribuio para a comunidade de DDS.
15
WDES
Referncias
Audy, J., Prikladnicki, R. (2007) Desenvolvimento Distribudo de Software: Desenvolvimento
de Software com Equipes Distribudas. 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 cientfica. So 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., Gusmo, C. (2008) Definio de um processo gil de gesto de riscos em ambientes
de mltiplos projetos. Hfen, 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. So Paulo: Pearson Addison-Wesley, 8 ed.
WDDS (2013) Workshop de Desenvolvimento Distribudo de Software. Disponvel 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 Pontifcia Universidade Catlica 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, christiano.ayub@gmail.com
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 organizations 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 todays
globalized IT market organizations also have to timely attend their customers 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 studys
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. Participants 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
ORGs 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 companys
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 managers 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 Vises para

Apoiar a Governana de Ecossistemas de Software
Yuri Abreu1, Rodrigo Pereira dos Santos1, Benno Albert2, Cludia 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 Informao e Telecomunicaes Rio de Janeiro, RJ, Brasil

{yuriabreu, rps, werner}@cos.ufrj.br, benno.albert@petrobras.com.br
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. Organizaes de TI, em suas relaes, fazem parte de Ecossistemas
de Software (ECOS) e enfrentam desafios ao organizar, selecionar e manter
tecnologias em um mercado dinmico. Em processos de deciso, elas tm
dificuldades em visualizar informaes de ECOS por carncias na gesto dos
ativos de software. Este artigo apresenta uma abordagem baseada em vises
para apoiar a governana de ECOS a partir de atividades de arquitetura de
TI. Uma ferramenta foi construda como extenso da Biblioteca Brech.
1. Introduo
Um Ecossistema de Software (ECOS) pode ser definido como um conjunto de negcios
funcionando como uma unidade e interagindo com um mercado compartilhado entre
software e servios, juntos e inter-relacionados [Jansen et al., 2009]. Neste contexto, as
organizaes enfrentam desafios ao lidar com a dinmica do mercado [Messerschmitt &
Szyperski, 2003]. Fuses ou aquisies entre organizaes fornecedoras de tecnologias
podem alterar a oferta de produtos e servios, o que afeta as organizaes consumidoras
e seus negcios. Esses eventos agregam complexidade em selecionar, adotar e gerir
ferramentas/tecnologias para dar suporte organizao e seus objetivos [Albert, 2014].
Nesse sentido, organizaes consumidoras possuem, normalmente, um conjunto
de ferramentas de apoio a seus processos e profissionais, e produzem artefatos (produtos
e servios) para atingir seus objetivos. Alguns problemas, no entanto, aparecem, como o
alto custo para adoo de novas tecnologias, a necessidade de reavaliar processos de
negcios frente a sua implantao, a dificuldade em lidar com a oferta e a relutncia dos
usurios para aceit-las [Freitas & Rech, 2003]. A arquitetura de TI das organizaes
consumidoras, por exemplo, pode sofrer impactos do desafio de organizar, selecionar e
manter tecnologias em um mercado em constante mudana [Baars & Jansen, 2012].
Nos processos de tomada de deciso, essas organizaes tm dificuldades em
visualizar informaes de ECOS por carncias na gesto 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 relatrios com base no mercado e opinies

de profissionais da rea [Albert et al., 2013]. Neste contexto, este artigo apresenta uma
abordagem baseada em vises para apoiar a governana de ECOS a partir de atividades
de arquitetura de TI, denominada SECOView. Uma infraestrutura de apoio foi
implementada como extenso de uma biblioteca de componentes e servios de software
[Brech, 2014] e uma anlise preliminar de sua utilizao foi realizada. O artigo est
organizado nas seguintes sees: a Seo 2 apresenta a fundamentao terica; a Seo
3 apresenta a abordagem proposta; a Seo 4 discute a extenso da Biblioteca Brech; a
Seo 5 discute uma anlise preliminar de sua utilizao; e a Seo 6 conclui o artigo.
2. Fundamentao Terica
Organizaes fornecedoras e consumidoras estabelecem laos ao se relacionarem, como
em contratos de aquisio de produtos e consultorias. As relaes, organizaes
envolvidas e informaes trocadas so elementos de um ECOS. Nesse contexto, a fim de
cumprir as metas de uma organizao consumidora, gerentes e arquitetos de TI tm o
desafio de avaliar relaes entre tecnologias e fornecedores e us-las a favor da
organizao. As organizaes que exploram essas novas relaes, de fato, necessitam
construir um processo de deciso em seus modelos para usufruir de certa agilidade em
detrimento de seus concorrentes, o que impacta a sua arquitetura de TI [Gartner, 2007].
No cenrio de ECOS, a definio 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 caractersticas e relaes. Os elementos do ECOS
podem ser sistemas, componentes do sistema e atores. As relaes se referem quelas de
arquitetura de software, incluindo relaes entre atores (e.g., fornecedores competindo
com um mesmo tipo de produto no mercado). Por sua vez, Gartner (2007) separa as
caractersticas de ECOS sob quatro vises: 1) viso do ECOS como uma entidade; 2)
viso das trocas mtuas com o valor de negcio; 3) viso de artefatos compartilhados,
tecnologias e propriedade intelectual; e 4) viso dos tipos especficos de ECOS.
Nesse contexto, a governana pode auxiliar uma organizao a alcanar seus
objetivos, usufruir melhor dos recursos disponveis e promover um aumento da
lucratividade e reduo de riscos. Gartner (2007) indica que, para gerir arquitetura em
ECOS, seus componentes devem ter um conjunto mnimo de informaes que possibilite
a sua gesto pela organizao consumidora. Albert (2014) explica que os seguintes
dados devem fazer parte desse conjunto: Fornecedor, Natureza, Tecnologia, Maturidade,
Data, Tipo de Ativo Produzido, Verses, Licenas, Usurios e Utilizao (i.e., log de
ferramenta de coleta de uso de software). Para dar suporte governana, a gesto de
ativos de software entra como instrumento para gerir e otimizar prticas de aquisio,
implantao, uso e manuteno dos ativos da organizao [Williams & OConnor, 2011].
Como trabalhos sobre vises de governana 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 viso, uma combinao de abordagens que permitem
verificar a maturidade de tecnologias [ThoughtWorks, 2012]. Como diferencial da
abordagem SECOView, para alm dos trabalhos relacionados, busca-se explorar vises
para a governana de ECOS a partir das atividades de arquitetura de TI da organizao.
26
WDES
3. Abordagem Proposta
A abordagem SECOView visa manipular dados de uma biblioteca de ativos de software
para construir vises que apoiem a governana de ECOS. Estes dados se referem
gesto de ativos de software e, desta forma, a SECOView prope informaes grficas
para os usurios, ilustrando recortes do ECOS da organizao, ou mesmo provendo uma
viso global. A estrutura da SECOView (Figura 1) mostra que mecanismos de busca e
recuperao e histrico de ativos produzidos so utilizados para se ter acesso aos dados
da gesto de ativos na biblioteca de ativos de software da organizao (ou catlogo).
Estes dados se referem a: ativos de software (componente da biblioteca), fornecedores,
categorias de tecnologias e usurios. A SECOView interpreta os dados e, conforme
especificado pelo usurio, refina-os para gerar uma viso que exiba parte do (ou todo o)
estado do ECOS da organizao. Grficos so exibidos ao usurio a partir da agregao
dos dados das aplicaes, componentes e servios da organizao.
Figura 1 Estrutura da abordagem SECOView
A SECOView toma por base o modelo SECOGov [Albert, 2014], que consiste
em um framework de governana de ECOS que envolve as seguintes atividades para
apoiar a arquitetura de TI, nas vises intra e interorganizacional: (i) Gerir Taxonomia de
Software: manter as categorias adequadas para organizar os ativos de software da
organizao; (ii) Gerir Arquitetura de Software: definir que ativos so padronizados para
cada categoria da taxonomia; (iii) Gerir Configuraes-padro de Software: definir quais
ativos compem uma configurao para atender a um dado perfil de ator do ECOS; (iv)
Gerir Licenas de Software: gerir o quantitativo e a diversidade de tipos de licenas, e
atribuir e disponibilizar licenas para os usurios; (v) Acompanhar ECOS: manter
informaes sobre os ECOS que a organizao participa ou deseja participar por meio da
anlise de relatrios de institutos, consultorias ou equipe de gesto da arquitetura
corporativa; (vi) Analisar a Maturidade de Tecnologias: cruzar informaes 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
definio de aquisio ou contratao de servios.
A partir de um ativo de software, para a atividade Gerir Licenas de Software, a
SECOView prope inicialmente dois grficos para a viso intra, que permitem
verificar: (1) o grau de dependncia tecnolgica dos ativos de um fornecedor que a
organizao adquiriu licenas; e a distribuio de seu uso e desuso (disponibilidade); e
(2) a comparao de produtividade com outros ativos que produzem o mesmo tipo de
soluo para a organizao (i.e., ativo produzido), filtrado por perodo. Esta proposta
27
WDES
motivada pelo resultado do levantamento de Rios (2013), que indica o controle das
licenas de cada ativo como crucial, pois isso concentra um dos maiores custos para o
setor de TI das organizaes. Em alto nvel, a SECOView prope grficos de ECOS
para examinar a viso inter: (3) o grau de dependncia tecnolgica da organizao
consumidora em relao aos seus fornecedores; e (4) a distribuio das licenas da
organizao consumidora em relao s categorias dos ativos adquiridos.
Por sua vez, para apoiar a atividade Gerir Arquitetura de Software do SECOGov,
prope-se um rtulo para o ativo de software, padro, para indicar o componente da
biblioteca que seja o padro de arquitetura para uma categoria especfica. Isso orienta
quais ativos de software devem ser adotados em maior escala pela organizao. Alm
disso, a SECOView prope um mdulo de gesto de anlises de ECOS (relatrios) para
apoiar a atividade Acompanhar ECOS do SECOGov, a fim de armazenar dados de como
a organizao consumidora participa do ECOS. Para facilitar a rastreabilidade destes
dados ao longo do tempo, a SECOView prope ainda associar uma categoria de
tecnologias e/ou ativos de software a uma anlise que justifique a adoo ou aquisio
pela organizao. As anlises podem ser ordenadas por parmetros [Gartner, 2007], e.g.,
taxa de benefcio, maturidade, tempo para adoo (anos) e recomendao para adoo.
Entre os recursos utilizados, esto: (i) grfico de pizza: para analisar os ativos de
um fornecedor especfico; (ii) grfico de barras horizontais: para avaliar as licenas em
uso e desuso de fornecedor; (iii) grfico de barras verticais: para avaliar os ativos
produzidos pela organizao; (iv) grafos: para analisar dependncias dos fornecedores; e
(v) planilhas: para exibir os resultados de relatrios de mercado sobre a anlise das
tecnologias que a organizao possui. Estes recursos foram baseados no levantamento
sobre mecanismos de recomendao e visualizao, realizado por Souza (2008).
Ressalta-se que as atividades Gerir Taxonomia de Software e Gerir Configuraespadro de Software so apoiadas pela implementao do modelo SECOGov, cujos
detalhes so descritos em (Albert, 2014), estando fora do escopo deste trabalho. Por fim,
as atividades Analisar a Maturidade de Tecnologias e Selecionar Produto ou Tecnologia
sero estudadas como trabalhos futuros.
4. Extenso da Biblioteca Brech

Para dar suporte abordagem proposta, foi implementada uma extenso da Biblioteca
Brech. A Brech consiste em um sistema web para gesto de ativos (componentes de
software, servios web e aplicaes) que fornece mecanismos de busca, recuperao,
armazenamento, documentao, publicao, controle de verso e evoluo,
gerenciamento dos usurios e de licenas, entre outros [Werner et al., 2007]. A
biblioteca organizada de forma hierrquica, onde um componente representa um ativo
armazenado de forma conceitual (nome e descrio), que possui um conjunto de
distribuies (corte funcional) e, estas, um conjunto de releases (corte temporal). Os
artefatos de uma release podem ser agrupados em pacotes para atender necessidades dos
usurios, ou disponibilizados como servios web, ambos sob licenas (direitos/deveres).
Visando apoiar a governana dos componentes da biblioteca, um cone para
acessar as vises da SECOView foi adicionado (Figura 2). Para o grfico de fornecedor
(Figura 3), filtraram-se os componentes do fornecedor do componente selecionado,
separando a quantidade de licenas de cada componente e relacionando-as ao total de
28
WDES
licenas do fornecedor. Para o grfico de alocao de licenas, analisaram-se todas as

releases do componente selecionado, de cada distribuio, comparando-se a quantidade
de licenas em uso/desuso, para cada release (Figura 3). Na viso inter, os grficos de
ECOS foram desenvolvidos para analisar a biblioteca da organizao, gerando uma
informao geral. O primeiro, Dependncia de Fornecedor (Figura 4), foi construdo a
partir da anlise do total de licenas adquiridas/em uso das releases de cada fornecedor.
Similarmente, construiu-se o grfico Dependncia de Categoria (Figura 4) a partir da
anlise dos dados de licenas adquiridas/em uso dos componentes de cada categoria.
Figura 2 Tela Meus Componentes. Em destaque, cones para a gerao de grficos

de um componente da biblioteca e o menu para acessar grficos de ecossistema.
Figura 3 Grficos do fornecedor do componente Microsoft Office (esquerda) e da

alocao de licenas do componente Microsoft Office (direita).
Figura 4 Grficos da dependncia de fornecedor (esquerda) e de categoria (direita).
Para configurar o atributo padro de arquitetura para uma categoria, um novo

atributo, standard, foi acrescentado entidade Componente da Brech. A definio do
padro feita na tela de criao/edio de um componente: verificando se existe algum
29
WDES
padro para a categoria em questo; fornecendo ao usurio escolhas pertinentes, e.g.,

caso tente definir um componente como padro da categoria quando h outro, uma
mensagem para questionar se deseja alterar o padro exibida; caso positivo, realizando
as alteraes pertinentes na base de dados (Figura 5). A marcao de componente padro
foi feita acrescentando uma coluna no menu Meus Componentes, que exibe um sinal
de visto verde, caso o componente seja o padro de sua categoria (Figura 2).
Figura 5 Telas de definio do componente padro de uma categoria quando h outro

padro (esquerda) e de detalhes da categoria Ferramentas de escritrio (direita).
Para acompanhar como a organizao participa do ECOS, implementou-se o

mdulo de anlise de ECOS, para criar e editar uma anlise, o que requer inserir dados
para facilitar a rastreabilidade e caracterizao (e.g., nome, origem/fonte, descrio,
recomendao, impacto para o negcio, taxa de benefcio, recomendao para adoo).
Foi implementada a tela Listar Anlises, para recuperar as anlises armazenadas e
exibi-las em uma tabela (Figura 6). Para facilitar a viso, implementou-se a ordenao
por alguns desses tipos de dados, clicando-se no item pretendido no cabealho da tabela.
Por fim, implementou-se o suporte ao acompanhamento de ECOS ao criar uma relao
entre as entidades, de modo que uma Anlise pode estar associada a zero ou uma
Categoria que, por sua vez, pode estar associada a zero ou n Componentes, diferindo da
associao entre Componentes e Categoria (n a n). Para que o usurio gerencie estas
relaes, foi criada uma funcionalidade para permitir essas associaes (Figura 6).
Figura 6 Tela Listagem de anlises (esquerda) e de associao de anlise (direita).
5. Utilizao da Ferramenta
Com a inteno de observar inicialmente alguns elementos da interface do ferramental
desenvolvido, foi preparado um instrumento de anlise da Brech, utilizado por alunos
de graduao da rea de Computao da UFRJ. O instrumento (formulrio eletrnico)
incluiu algumas tarefas para verificar a adequao do tempo necessrio para execuo.
30
WDES
Alm disso, o instrumento apontou alguns elementos de interface a serem observados

durante as tarefas, inspirados nas heursticas de usabilidade adaptadas de [Nielsen, 1993].
Um piloto foi individualmente conduzido em 08/04/2014 com dois participantes
(um graduando em Engenharia da Computao e outro em Cincia da Computao).
Aps a concordncia, foi apresentado um texto sobre ECOS, o modelo de dados da
Brech e a extenso implementada na SECOView. Ambos conseguiram responder s
perguntas, com poucos erros. Eles relataram dificuldades em encontrar certas opes
para realizar uma tarefa e visualizar a separao de componentes na tela Meus
Componentes, assim como a falta de um manual. A partir disso, foram feitas alteraes
nas instrues e questes do instrumento, tornando os textos mais sintticos, e tambm
no layout da ferramenta, para sanar os problemas de navegao.
A anlise, ento, foi conduzida individualmente com trs participantes em
16/04/2014, graduandos em Cincia da Computao. Cada um preencheu a
caracterizao, leu o embasamento e executou as tarefas propostas. Um exemplo de
tarefa foi: Quais so os componentes associados configurao 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 avaliaes dos participantes (P1, P2 e P3), na escala de 0 a 10.
Tabela 1 Resultados da avaliao de usabilidade
Elementos de interface inspirados em [Nielsen, 1993]
(1) visibilidade do status
A ferramenta informa o que est acontecendo?
(2) concordncia entre a ferramenta e o mundo real

A ferramenta utiliza a linguagem do usurio?
(3) controle e liberdade ao usurio

A ferramenta apresenta facilidade de interao e sadas claras?
(4) consistncia e padres

Diferentes situaes ou aes representam a mesma coisa?
(5) preveno de erros

O projeto da ferramenta prev situao de erro ao invs de usar mensagem?
(6) minimizao da carga de memria do usurio

As telas mostram o que est sendo feito e do ideia do caminho percorrido?
(7) flexibilidade e eficincia de uso

A ferramenta atende a usurios experientes?
(8) projeto minimalista e esttico

As informaes so sintticas e completas?
(9) reconhecimento, diagnstico e recuperao de erros

Problemas e solues so facilmente indicados?
(10) ajuda e documentao

Existem manuais simples e objetivos?
P1
P2
P3
10
10
10
10
10
O feedback indicou como pontos fracos: a dificuldade de encontrar informaes;

a ausncia de um manual on-line da ferramenta (i.e., cones de ajuda); e a visibilidade do
estgio do usurio na tarefa. Entre os pontos fortes apontados, esto: a clareza dos
grficos; a compilao da informao; e a preveno de erros. Observou-se que os dois
participantes com o melhor desempenho nas tarefas foram os mais crticos e deram
feedback mais informativo. A anlise realizada teve carter preliminar e propiciou a
organizao de um instrumento para conduzir um estudo de caso na indstria, com
participantes da rea de governana, conforme apresenta (Albert, 2014).
6. Concluso
Devido ao desafio da governana de ECOS, este artigo apresentou a abordagem
SECOView, cujo objetivo manipular dados de uma biblioteca de ativos de software
para a construo de vises para apoiar a governana de ECOS a partir de atividades de
31
WDES
arquitetura de TI. A abordagem foi implementada como extenso da Biblioteca Brech e

uma anlise preliminar de utilizao foi realizada. Como contribuies, so sumarizadas
caractersticas, artefatos e recursos importantes para a governana de ECOS no sentido
de apoiar a organizao consumidora a melhorar a viso do ECOS em que est inserida.
Buscou-se com a SECOView um suporte para acompanhar a evoluo do ECOS da
organizao consumidora e dos ECOS relevantes aos seus objetivos de negcio. Os
recursos grficos da SECOView trazem pesquisa em ECOS uma viso sobre o
tratamento de dados em bibliotecas de ativos de software, a fim de atender as
necessidades de governana, pela carncia de iniciativas na rea [Baars & Jansen, 2012].
Alguns trabalhos futuros so apontados: (1) melhorar a interface da ferramenta,
com cones de ajuda e visualizao dos rastros das aes do usurio, 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 gesto de demandas
(requisitos) em ECOS e contemplar mais variveis arquitetnicas em sua estrutura.
Referncias
Albert, B. (2014). Secogov: Um Modelo de Governana de Ecossistemas de Software para
Apoiar Atividades de Arquitetura de TI. Dissertao. 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, Servios e Aplicaes de Software, disponvel em:
<http://reuse.cos.ufrj.br/brecho>, acesso em julho de 2014.
Freitas, H.; Rech, I. (2003) Problemas e Aes na Adoo de Novas Tecnologias de
Informao. Revista de Administrao Contempornea, v. 7, n. 1 (Jan-Mar), pp. 125-150.
Gartner (2007) Evaluating Global-Class SECO, disponvel em: <http://www.gartner.com/
document/506608>, acesso em julho de 2014.
Gartner (2008) Gartner Hype Cycles, disponvel 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) Governana de Ativos em Ecossistemas de Software na Biblioteca Brech.
Trabalho de Concluso de Curso. Escola Politcnica da UFRJ, Rio de Janeiro, Brasil.
Souza, D. (2008) Utilizao de Tcnicas de Visualizao para a Recomendao de Substitutos.
Dissertao. COPPE/UFRJ, Rio de Janeiro, Brasil.
ThoughtWorks (2012) ThoughtWorks Technology Radar March 2012, disponvel em:
<http://thoughtworks.fileburst.com/assets/technology-radar-march-2012.pdf>.
Werner, C. et al. (2007) Brech: Catlogo de Componentes e Servios de Software. In: Anais
do XXI SBES, Sesso de Ferramentas, Joo Pessoa, Brasil, pp. 24-30.
Williams, C.; OConnor, 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
johnmc@clemson.edu
2
Federal Institute of Education,

Science and Technology of Bahia
Salvador, BA Brazil 40170
simone.amorim@ifba.edu.br
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 models 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 models 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 ecosystems 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 Baldwins 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
195203.
da Silva Amorim, S., Almeida, E. S. D., and McGregor, J. D. (2013). Extensibility in
ecosystem architectures: an initial study. In WEA, pages 1115.
da Silva Amorim, S., de Almeida, E. S., and McGregor, J. D. (2014a). Scalability of
ecosystem architectures. In WICSA, pages 4952.
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):5768.
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):10151030.
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 5768.
Popp, K. M. (2011). Hybrid revenue models of software companies and their relationship
to hybrid business models. In IWSECO@ICSOB, pages 7788.
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 Valena2, Davi Viana3, Bernardo Estcio4, Awdren Fonto3,5,
Sabrina Marczak4, Cludia 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 Pontifcia Universidade Catlica 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, awdren.fontao@indt.org.br
{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 distribudo de software se tornou uma realidade na ltima
dcada. A comunidade de Engenharia de Software tem investigado aspectos tcnicos,
econmicos e sociais. Isso propiciou o desenvolvimento de plataformas globalizadas, de
larga escala e de longo prazo, que tem sido tratado como o ncleo de ecossistemas de
software. Entender como este cenrio impacta a qualidade em ecossistemas de software
tem sido um fator crtico. O artigo apresenta uma discusso inicial sobre qualidade em
ecossistemas de software visando identificar alguns desafios e oportunidades.
1. Introduo
O Desenvolvimento Distribudo de Software (DDS) se tornou uma realidade na ltima dcada
(Jimnez et al., 2009). Apesar dos desafios geogrficos e culturais da colaborao, uma das
principais motivaes do DDS est na busca por equipes mais produtivas e especializadas, produtos
de melhor qualidade e reduo de custos de desenvolvimento (Sengupta et al., 2006). Paralelamente
consolidao do DDS, outros modelos de desenvolvimento tm surgido, no 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 tm 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 prticas observadas em ECOS desafiam alguns pressupostos da Engenharia de Software (ES)
tradicional, dado que o desenvolvimento dos produtos no ocorre em torno de um projeto e sim pela
inovao contnua feita por diversos atores do ecossistema (i.e., inovao aberta). Nesse contexto,
um dos fatores crticos do desenvolvimento est na qualidade em ECOS (Santos & Werner, 2012).
Nos diferentes cenrios de DDS, fatores que impactam a qualidade so 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 dependncias entre as atividades e entre os artefatos, a gesto de projetos globais e a

comunicao (Gomes & Marczak, 2012). Estes fatores influenciam na forma como o software
definido, construdo, testado e entregue aos consumidores, afetando consequentemente os estgios
do ciclo de vida (Jimnez et al., 2009). Semelhante a um dos cenrios de DDS, as plataformas de
ECOS so desenvolvidas de maneira global, com o envolvimento de terceiros. No entanto, em
ECOS, atores externos, conhecidos ou no, atuam no desenvolvimento de produtos e/ou da prpria
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,
hibridizao de modelo de negcio e governana em outsourcing (Jansen et al., 2009).
Este artigo apresenta uma discusso inicial sobre qualidade em ECOS visando identificar
desafios e oportunidades de pesquisa para a comunidade de ES. Alm desta seo de introduo, o
artigo est organizado da seguinte forma: a Seo 2 apresenta uma viso geral de como a qualidade
tem sido abordada em ECOS; a Seo 3 discute alguns desafios e oportunidades para qualidade em
ECOS; e a Seo 4 discorre sobre as consideraes finais do artigo.
2. Qualidade em Ecossistemas de Software

Com uma ampla atuao de atores externos organizao que prov a plataforma, como startups e
desenvolvedores independentes (Miranda et al., 2014), o desafio da qualidade em ECOS vem se
tornando uma questo importante (Axelsson et al., 2014). De acordo com Barbosa et al. (2013), a
questo da qualidade no tem sido definida ou tratada especificamente para ECOS, mas a maneira
pela qual a qualidade medida vem sendo uma preocupao real. As primeiras iniciativas para
discutir qualidade em ECOS foram voltadas para a avaliao das contribuies dos atores, o que
crucial para o desenvolvimento e evoluo da plataforma (Hmood et al., 2010). Na presena de um
keystone1, fatores adicionais so percebidos, como o nvel 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 contribuies atendam a um padro de qualidade mnimo exigido pelo
canal de distribuio (AppleStore). J em um ECOS aberto, como o ECOS MySQL/PHP, onde os
atores tm acesso ao cdigo fonte e s bases de conhecimento relacionadas, o controle de qualidade
mais difcil de ser gerenciado e garantido, considerando atores externos desconhecidos.
Alm disso, a qualidade em ECOS no tem se restringido viso dos processos e dos
produtos, mas explora a viso de sade e de prosperidade (Fotrousi et al., 2014). Em (Manikas &
Hansen, 2013), percebe-se esta relao com a sade 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 trs 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 estvel; e (iii)
criao de nicho, capacidade do ECOS inovar ou propiciar que a sua comunidade o faa.
Vale ressaltar que, diferente do processo de desenvolvimento de um nico produto, em
ECOS no h separao entre o desenvolvimento da plataforma e dos projetos sobre ela (Cataldo &
Herbsleb, 2010). Isso requer processos de gesto distribudos que ampliam a forma de avaliar a
Um keystone uma organizao que disponibiliza uma tecnologia de software central para ampliar o seu portflio de
produtos e servios a partir da integrao ou construo de novas solues por atores externos (Jansen et al., 2009).
42
WDES
capacidade e maturidade dos processos dos atores do ECOS (Santos & Werner, 2012). So
necessrias estratgias para coordenar diferentes atores e sua comunicao no ECOS (Farias Jnior
et al., 2013); tcnicas para melhorar a experincia (Fonto et al., 2014) e motivao (Miranda et al.,
2014) dos colaboradores; e abordagens (guias e padres) para certificao das contribuies dos
atores (Maia et al., 2013) e para negociar requisitos nos projetos do ECOS (Valena et al., 2013).
3. Desafios e Oportunidades de Pesquisa

Esta seo resume alguns desafios para garantir a qualidade em ECOS. Para identific-los, utilizouse a categorizao de questes de DDS definida por Audy & Prikladnicki (2008) como orientao:
processos de software, infraestrutura, pessoas ou recursos humanos, gerenciamento e comunicao.
Os desafios relacionados a DDS (Seo 1) e a explanao sobre qualidade em ECOS (Seo 2) so
tomados como base e questes especficas de ECOS so trazidas discusso:
Categoria 1 Processos de Software e Padres
Como responsvel pela gesto da plataforma e do ecossistema em torno dela, o keystone deve rever
seus processos de software para melhorar a experincia dos colaboradores do ECOS (e.g.,
desenvolvedores externos, fornecedores etc.) e estabelecer controles adequados aos diferentes tipos
de atores. Nesse contexto, indicadores de sade de ECOS podem ser usados como instrumentos
para apoiar a avaliao da capacidade e maturidade do keystone, visando lidar com a qualidade.
O keystone deve disseminar boas prticas e padres arquiteturais para garantir a consistncia das
integraes 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 solues geradas (e.g., capacidade para
manter a execuo de aplicativos desenvolvidos por terceiros em ECOS mveis).
Categoria 2 Aspectos Sociais e Gesto do Conhecimento
O conhecimento circulante entre a plataforma e os produtos ao redor influencia o processo de
aquisio de tecnologias pelo keystone. A diversidade dos elementos que compem o ECOS e as
contribuies intelectuais dos diferentes atores devem ser aproveitadas adequadamente pelos
projetos e pela plataforma por meio de diferentes estratgias de captura de conhecimento.
Adicionalmente, importante que a credibilidade de um colaborador seja verificada por meio de
certificaes ou processos de seleo de parceiros adaptados para as particularidades de ECOS.
Categoria 3 Governana
Uma estratgia de Gesto dos Produtos de Software (Software Product Management) deve ser
estabelecida pelo keystone e comunicada aos demais atores do ECOS. Desse modo, possvel que
haja alinhamento de portflios e conhecimento do roadmap dos produtos. Nesse sentido, sob a tica
de gesto de requisitos, requisitos de qualidade e de integrao devem ser identificados e
difundidos. Em particular, requisitos de integrao podem favorecer a reutilizao ao serem
incorporados pela plataforma, reduzindo problemas relacionados e facilitando o atendimento de
prazos, possibilitando ainda a inovao pela comunidade e ajudando na criao de nicho.
As atividades de governana de ECOS podem auxiliar o keystone na identificao de atores e
artefatos crticos para a plataforma, internos e externos. Alm disso, o keystone deve estabelecer
orientaes quanto a atividades de teste pelos colaboradores de forma a garantir confiabilidade e
segurana de seus produtos para diferentes plataformas de ECOS. Por fim, colaboradores precisam
analisar e/ou comparar a sade de diferentes ECOSs de interesse para tomar decises nos projetos
de suas contribuies para a plataforma, e.g., sobre o planejamento de releases.
43
WDES
4. Consideraes Finais
Este artigo apresentou uma discusso inicial sobre qualidade em ECOS. Alguns dos desafios de
qualidade em ECOS identificados so herdados do DDS, porm com uma amplitude de questes
relacionadas arquitetura e modelos de negcio. Entre os itens chave de qualidade, esto a
aplicabilidade das metodologias atuais para maturidade e capacidade de processos de software em
relao a ambientes de ECOS e a gesto de conhecimento e aspectos sociais dos diferentes atores
com a finalidade de promover mais qualidade e sade para os ECOSs. Alm disso, devido vasta
literatura de gesto do conhecimento, devem-se analisar possveis adaptaes de estratgias
existentes para os novos ambientes de desenvolvimento gerados pelos ECOSs. No obstante o
amadurecimento das pesquisas mais voltadas para ECOS a partir de 2009 (Barbosa et al., 2013),
ainda so necessrios trabalhos que investiguem o tpico de forma mais aprofundada. Como
prximos passos, pretende-se desenvolver um framework para gesto e monitoramento da qualidade
em ECOS, bem como explorar a qualidade de processos e produtos a partir de elementos de DDS.
Referncias
Audy, J. & Prikladnicki, R. (2008) Desenvolvimento Distribudo 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) Reflexes sobre Comunicao no Desenvolvimento Distribudo no Contexto de
Ecossistemas de Software. In: VII WDDS, Braslia, 52-59.
Fonto, A. et al. (2014) MSECO Skill: Construo de Competncias de Desenvolvedores em Ecossistemas de
Software Mvel. In: XVII CIbSE, Pucn, 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.
Jimnez, 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
Distribudo no Contexto de Ecossistemas de Software. In: VII WDDS, Braslia, 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.
Valena, G. et al. (2013) Analysing Requirements Negotiation in Software Ecosystems with Multi-Agent
Systems Techniques. In: VII WDDS, Braslia, 44-51.
44
WDES
Towards the Dynamic Evolution of Context-based

Systems-of-Systems
Elisa Yumi Nakagawa1, Rafael Capilla2, Francisco J. Daz3, and Flvio Oquendo4
1
University of So Paulo USP, So Carlos, Brazil
University Rey Juan Carlos URJC, Madrid, Spain
Ingeniera y Economa del Transporte INECO, Madrid, Spain

4
IRISA - University of South Brittany USB, Vannes, France

elisa@icmc.usp.br, rafael.capilla@urjc.es,
fjdiaz@ineco.com, flavio.oquendo@irisa.fr
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 systems 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 airports 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 airports 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 airports 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-Corts, 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 SESoS13, 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., Hst, 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
ICMC - University of So Paulo (USP)

So Carlos - Brazil.
IRISA - Universit de Bretagne Sud (UBS)

Vannes - France.
{danielss, brauner}@usp.br, {milena, delamaro, elisa}@icmc.usp.br,

flavio.oquendo@irisa.fr
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 ISSRE2009, pages 175184, 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 GREENS2012, pages 6975, 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 CSER2014, pages 720727, 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 CSER2014, pages 728735,
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 SoSE2006, pages 1-5, Shanghai, China.
Nakagawa, E. Y., Gonalves, M., Guessi, M., Oliveira, L. and Oquendo, F. (2013) The
state of the art and future perspectives in systems of systems software architectures.
In SESoS2013, 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 SoSE2010,
Loughborough, UK.
Zhu, L., Staples, M. and Jeffery, R. (2008) Scaling up software architecture evaluation
processes. In ICSP2008, pages 112122, Leipzig, Germany.
57
WDES
On the Relations between

Systems-of-Systems and Software Ecosystems
Rodrigo Santos1, Marcelo Gonalves2, Elisa Yumi Nakagawa2, Cludia Werner1
1
PESC/COPPE Federal University of Rio de Janeiro, Rio de Janeiro, Brazil

2
ICMC/USP University of So Paulo, So 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 societys 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 communitys 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 communitys 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
environments 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 dItalia, Italy, 1-6.
62

WDES ANAIS 2014 v1 PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

WDES ANAIS 2014 v1 PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Congresso Brasileiro de Software: Teoria e Prtica

28 de setembro a 03 de outubro de 2014 Macei/AL

VIII Workshop de Desenvolvimento Distribudo de Software,

VIII Workshop de Desenvolvimento Distribudo de

VIII Workshop de Desenvolvimento Distribudo de

Comits Tcnicos / Program Committee

Comit organizador / Organizing Committee

ndice / Table of Contents

On the Identification of Factors that Promote High-Performance

SECOView: Uma Abordagem Baseada em Vises para Apoiar a

Ecosystem Business Models and Architectures

Qualidade em Ecossistemas de Software: Desafios e Oportunidades

Towards the Dynamic Evolution of Context-based Systems-ofSystems

Towards the Evaluation of System-of-Systems Software

On the Relations between Systems-of-Systems and Software

Um Framework para Gesto de Riscos em Projetos de

Centro de Informtica Universidade Federal de Pernambuco (UFPE)

Abstract. Risk management is considered a critical factor for Distributed Software

2. Gerenciamento de Riscos em DDS

consequentemente, a qualidade do produto e do desempenho do projeto de software.

A = Atende, AP = Atende parcialmente, N = No atende

Figura 1 Metodologia da Pesquisa

5. O Framework para Gesto de Riscos em Projetos de DDS

Figura 2 Representao grfica do framework RADS

O framework RADS utiliza prticas geis para o tratamento de riscos em DDS. O

Tabela 2 Descrio das reas, subreas e elementos do RADS

Divulgao dos riscos identificados e priorizados para a prxima sprint para as

Identificao e participao dos vrios stakeholders envolvidos no processo de gesto

Processo de identificao dos riscos por parte da equipe distribuda.

(Boehm, 1991; Keshlaf & Hashim, 2000;

Processo de priorizao da lista criada no passo de Identificao de Riscos.

(Boehm, 1991; Keshlaf & Hashim, 2000;

(Persson et al., 2009)

(Nyfjord & Kajko-Mattsson, 2007;

Processo de definio, documentao e incluso no backlog da sprint ou backlog do

(Boehm, 1991; Ebert et al., 2008;

Aplicao das Estratgias

Execuo das estratgias de mitigao de riscos alocadas para as equipes distribudas

(Nelson et al., 2008)

(Boehm, 1991; Nelson et al., 2008)

Neste passo, apresentado o status do plano de mitigao de riscos, informando se

(Nelson et al., 2008)

Gerente Global do Projeto

Papel responsvel pela coordenao da gesto de riscos no nvel global, ou seja, de

(Nelson et al., 2008;

Gerente Global de Riscos

Papel responsvel por gerenciar as atividades de priorizao, consolidao e

(Nelson et al., 2008;

Papel responsvel por gerenciar as atividades de risco das equipes.

(Nyfjord & Kajko-Mattsson, 2007;

6. Avaliao Preliminar do Framework RADS

Sobre a definio dos papis do Framework RADS

On the Identification of Factors that Promote HighPerformance Projects in Distributed Development

Sabrina Marczak1, Marcelo Perin1, Rafael Prikladnicki1, Christiano Ayub2

Computer Science School Pontifcia Universidade Catlica do RS (PUCRS)

Development Center, ORG

Abstract. As part of a long-term research on high-performance projects in

structured interviews in a large IT company, named ORG (a fictitious name due to

Table 1. Participants background

Current Role and

Career manager: This manager is

Manager of the Project Management

Senior Development Manager: This