Estudo Empírico Sobre Relacionamento Entre Estrutura de Comunicação e Design de Sistemas com Base na Lei de CONWAY

Pós-Graduação em Ciência da Computação

“ESTUDO EMPÍRICO SOBRE RELACIONAMENTO

ENTRE ESTRUTURA DE COMUNICAÇÃO E

DESIGN DE SISTEMAS COM BASE NA LEI DE

CONWAY”

Por

ANDERSON MEDEIROS DE SANTANA

Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao

RECIFE 2014

UNIVERSIDADE FEDERAL DE PERNAMBUCO

CENTRO DE INFORMÁTICA

PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

ANDERSON MEDEIROS DE SANTANA

ESTUDO EMPÍRICO SOBRE RELACIONAMENTO ENTRE ESTRUTURA

DE COMUNICAÇÃO E DESIGN DE SISTEMAS COM BASE NA LEI DE

CONWAY

ESTE TRABALHO FOIAPRESENTADO ÀPÓS-GRADUAÇÃOEM CIÊNCIA DA COMPUTAÇÃODO CENTRO DE INFORMÁTICADA UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO REQUISITO PARCIAL PARA OBTENÇÃO DO GRAU DE MESTRE EM CIÊNCIA DA COMPUTAÇÃO.

ORIENTADOR(A): FÁBIO Q. B. DA SILVA, PHD

RECIFE 2014

Catalogação na fonte

Bibliotecária Jane Souto Maior, CRB4-571

S232e Santana, Anderson Medeiros de

Estudo empírico sobre relacionamento entre estrutura de comunicação e design de sistemas com base na lei de Conway. / Anderson Medeiros de Santana. – Recife: O Autor, 2014.

111 f.: fig., tab.

Orientador: Fábio Queda Bueno da Silva.

Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn, Ciência da Computação, 2014.

Inclui referências e apêndice.

1. Engenharia de software. 2. Tecnologia da informação. 4. Aspectos humanos. I. Silva, Fábio Queda Bueno da (orientador). II. Título.

005.1 CDD (23. ed.) UFPE- MEI 2014-177

Anderson Medeiros de Santana

ESTUDO EMPÍRICO SOBRE RELACIONAMENTO ENTRE ESTRUTURA DE COMUNICAÇÃO E DESIGN DE SISTEMAS COM BASE NA LEI DE CONWAY

Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Federal de Pernambuco, como requisito parcial para a obtenção do título de Mestre em Ciência da Computação.

Aprovado em: 08/09/2014

BANCA EXAMINADORA

__________________________________________ Prof. Dr.André Luís de Medeiros Santos

Centro de Informática / UFPE

__________________________________________ Prof. Dr. Clauirton de AlburquerqueSiebra

Departamento de Informática / UFPB

___________________________________________ Prof. Fábio Queda Bueno da Silva (Orientador)

AGRADECIMENTOS

A Deus que se faz presente mesmo quando estou distante e se revela nas pessoas não me deixando desanimar nem desistir quando as coisas parecem que não vão dar mais certo.

A minha família, em especial a minha mãe, D. Fátima, que soube educar a mim e aos meus irmãos diante de todas as adversidades dando-nos oportunidades que ela jamais teve e nunca deixando de investir na gente. A meu pai, in memorian, que mesmo em pouco tempo, ajudou na minha formação e me ensinou a ser o homem que sou hoje. Aos meus irmãos, Adriana e Fabinho dos quais sinto saudades por não estar perto.

Ao meu orientador, Fábio, pessoa que admiro e em quem me espelho como pesquisador que é, dedicado aos seus compromissos com o trabalho e no ofício de ensinar e que acreditou em mim quando eu mesmo já tinha dúvidas.

Aos colegas do HASE, pelas proveitosas discussões e com quem aprendi muito. Em especial a Fabrício, Ítala, Roberta e Marcão que quando souberam do meu desânimo, prontamente correram para me animar e não deixar desistir.

À Regina Miranda, Angélica Mascaro e Tatiana Bittencourt pessoas fundamentais na execução dessa pesquisa e que sem elas teria sido muito mais difícil.

Aos colegas/amigos, de hoje e de antes, da República que são minha família em Recife e grandes incentivadores meus: Artur, Jean, Paulo, Ednaldo, Evandro, Leonardo, Roberto e Saulo.

Aos demais colegas de mestrado, muitos dos quais viraram amigos. A todos os que me receberam em Recife e me fizeram sentir em casa.

Enquanto houver vontade de lutar haverá esperança de vencer.

E

E

R

E

C

D

S

B

L

C

RESUMO

Objetivo: O objetivo desse estudo é investigar as relações entre a estrutura de

comunicação de uma equipe de software e a arquitetura resultante do desenvolvimento de sistemas sob a perspectiva da Lei de Conway.

Método: Foi projetado um quasi-experimento no contexto da indústria de software na

qual os resultados de duas equipes de desenvolvimento foram comparados sob um mesmo projeto. Uma das equipes trabalhou uma abordagem ágil baseada em Scrum tendo comunicação frequente. A outra equipe trabalhou sob uma abordagem mais tradicional baseada no estilo de comando-e-controle de gerenciamento hierárquico com comunicação muito limitada entre os membros da equipe. Nós observamos ambas as equipes durante o projeto, entrevistamos os participantes e realizamos um grupo focal para coletar e comparar as impressões dos membros das equipes no final do projeto.

Resultados: Foram encontradas enormes diferenças entre o design arquitetural das

duas equipes, como previsto. A equipe hierárquica apresentou melhores resultados quanto a eficiência e eficácia do desenvolvimento. A equipe ágil produziu uma solução mais simples, com um design de Sistema mais acoplado do que o apresentado pela equipe hierárquica.

Conclusão: Nossas descobertas não apoiam completamente a Lei de Conway,

quanto à unidirecionalidade e ao homomorfismo, uma vez que apresentam características mais bidirecionais e polimórficas.

Palavras-Chave: Lei de Conway. Design de Sistema. Estrutura de Comunicação da Organização. CongruênciaSociotécnica.

E

S

R

B

O

’

C

S

S

D

ABSTRACT

Aim: The goal of this study is to investigate the relationships between the

communication structure of a software team and the resulting architecture of the software developed under the perspective of Conway’s Law.

Method: A quasi-experiment was designed in an industrial context in which the

results of two teams were compared. One team worked using an agile approach based on Scrum with daily meetings and frequent daily communication. The other team used a more traditional approach based on hierarchical command-and-control style of management with very limitedcommunication between team members. We observed both teams during the project, interviewed participants, and carried out a focus group to collect and compare impressions of team members at the end of the projects.

Results: We found large differences between architectural designs of the two teams,

as predicted. Hierarchical team presented best results with respect to efficiency and efficacy of development. Agile team produced a simpler solution and the system design was more coupledthan hierarchical team.

Conclusion: Our findings provided partial support to Conway’s Law, highlights

bidirectional and polymorphic characteristics.

Key-Words: Conway’s Law. System Design.Organization’s Communication Structure. Socio-Technical Congruence.

LISTA DE FIGURAS

FIGURA 1. MODELO ARQUITETURAL EQUIPE ÁGIL GRUPO FOCAL. ... 66

FIGURA 2. MODELO ARQUITETURAL EQUIPE HIERÁRQUICA GRUPO FOCAL. ... 67

FIGURA 3. ARQUITETURA EQUIPE ÁGIL (OBTIDA POR ENGENHARIA REVERSA) ... 67

FIGURA 4. ARQUITETURA EQUIPE HIERÁRQUICA (OBTIDA POR ENGENHARIA REVERSA) ... 68

FIGURA 5.ARQUITETURA SIMPLIFICADA DA APLICAÇÃO DESENVOLVIDA PELA EQUIPE ÁGIL ... 69

FIGURA 6. ARQUITETURA SIMPLIFICADA DA APLICAÇÃO DESENVOLVIDA PELA EQUIPE HIERÁRQUICA ... 69

FIGURA 7. ARQUITETURA FINAL DO SISTEMA DA EQUIPE ÁGIL ... 74

FIGURA 8. ARQUITETURA FINAL DO SISTEMA DA EQUIPE HIERÁRQUICA ... 75

FIGURA 9. ÚNICA PESSOA DESENVOLVENDO O SISTEMA ... 76

FIGURA 10. UMA EQUIPE DE TRÊS DESENVOLVEDORES ... 77

FIGURA 11. ESQUEMA DE CONFIGURAÇÃO IDEAL POR BLATTER ET AL. (2013). ... 86

FIGURA 12. ESTRUTURA DE COMUNICAÇÃO DO GRUPO DE CONTROLE. ... 87

FIGURA 13.DESIGN DE SISTEMA PRODUZIDO PELO GRUPO 1. ... 89

FIGURA 14.DESIGN DO SISTEMA PRODUZIDO PELO GRUPO 2.. ... 89

FIGURA 15. DESIGN DO SISTEMA PRODUZIDO PELO GRUPO 3. ... 89

LISTA DE TABELAS

TABELA 1. PAPÉIS NA EQUIPE (BELBIN) ... 52

TABELA 2.CARACTERÍSTICAS DA EQUIPE ÁGIL ... 53

TABELA 3. CARACTERÍSTICAS DA EQUIPE HIERÁRQUICA ... 54

TABELA 4. MÉTRICAS DE CÓDIGO PARA SOFTWARE DESENVOLVIDO PELA EQUIPE ÁGIL ... 72

TABELA 5. MÉTRICAS DE CÓDIGO PARA SOFTWARE DESENVOLVIDO PELA EQUIPE HIERÁRQUICA ... 72

LISTA DE ABREVIATURAS E SIGLAS

BYU Brigham Young University

ERP Enterprise Resource Planning

EuroPLoP European Conference on Pattern Languages of Programs

HBR Harvard Business Review

LPS Linha de Produto de Software MVC Model-View-Controller

OS Operating System

PLoP Conference on Pattern Languages of Program Design

RESER International Workshop on Replication in Empirical Software Engineering Research

SUMÁRIO

1 INTRODUÇÃO ... 15

1.1. OBJETIVOS ... 16

1.2. JUSTIFICATIVA ... 17

1.3. METODOLOGIA, PERGUNTA DE PESQUISA E HIPÓTESES ... 18

1.4. ESTRUTURA DO TRABALHO ... 19 2 REFERENCIAL TEÓRICO ... 20 2.1. PRINCIPAIS ESTUDOS ... 20 2.1.1. Conway (1968) ... 21 2.1.2. Raymond (1996) ... 22 2.1.3. Coplien e Harrison (2004) ... 23

2.1.4. Herbsleb e Grinter (1999a, 1999b) ... 23

2.1.5. Demais Estudos ... 24

2.2. INTERPRETAÇÕES DA LEI DE CONWAY ... 26

2.2.1. Design do Sistema ... 26

2.2.1.1. Arquitetura do Software ... 26

2.2.1.2. Estrutura do Produto ... 27

2.2.1.3. Arquitetura do Produto ... 28

2.2.1.4. Estrutura do Artefato ... 28

2.2.2. Aspectos Organizacionais e Sociais ... 29

2.2.2.1. Estrutura Organizacional ... 29

2.2.2.2. Estrutura Social ... 31

2.2.3. Direções de Dependência ... 31

2.2.3.1. Bidirecional ... 32

2.2.3.2. Unidirecional ... 32

2.3. EXTENSÕES DA LEI DE CONWAY ... 33

2.3.1. Nova Dimensão ... 33

2.3.2. Novo Fator ... 34

2.3.3. Problemas com Estruturas ... 35

2.4. RECOMENDAÇÕES DA LEI DE CONWAY ... 36

2.4.1. Alinhar Organização e Arquitetura ... 37

2.4.2. Modularização ... 38 2.4.3. Coalocação e Globalização ... 40 2.4.4. Comunicação Eficaz ... 42 2.4.5. Flexibilidade ... 43 2.5. TRABALHOS RELACIONADOS ... 43 3 DESCRIÇÃO DO MÉTODO ... 46 3.1. CONTEXTO ... 46 3.2. QUESTÃO DE PESQUISA ... 47

3.3. DESIGN DO ESTUDO ... 49

3.4. AMOSTRA ... 51

3.5. PREPARO DA COLETA DE DADOS ... 54

3.6. PROCESSO DE COLETA DE DADOS ... 55

3.7. SÍNTESE E ANÁLISE DE DADOS ... 59

3.8. AMEAÇAS DA VALIDADE E CONFIABILIDADE ... 59

4 RESULTADOS E ANÁLISE ... 61

4.1. DESCRIÇÃO DO TRABALHO DAS EQUIPES ... 61

4.1.1. Equipe Ágil ... 61

4.1.2. Equipe Hierárquica ... 63

4.2. ANÁLISE INICIAL E ARQUITETURA RESULTANTE... 65

4.3. ANÁLISE DOS RESULTADOS ... 69

5 DISCUSSÃO ... 81

5.1. CONTEXTO ... 81

5.2. APRESENTAÇÃO DOS ESTUDOS ... 82

5.2.1. Bailey et al. (2013) ... 82

5.2.2. Betz et al. (2013) ... 83

5.2.3. Blatter et al. (2013) ... 85

5.3. ANÁLISE DAS PESQUISAS ... 89

6 CONCLUSÃO ... 94

1 INTRODUÇÃO

Após ter seu estudo rejeitado pela Harvard Business Review1_{(HBR) em 1967,} Melvin Conway conseguiu publicar o mesmo estudo na maior revista de TI da época, a Datamation2_{, um ano depois(BIRD, 2009). No estudo chamado “How do}

CommitteesInvent?”, Conway mostra o quão relacionadas estão a estrutura

organizacional de uma empresa e o design dos sistemas desenvolvidos por ela a ponto de declarar, em suas conclusões, que “qualquer organização que desenvolve um sistema (definido de forma ampla) irá produzir um design cuja estrutura é uma cópia da estrutura de comunicação da organização”(CONWAY, 1968).

Em 1975, Fred Brooks em suaobraseminal “The Mythical Man-Month” (BROOKS, 1975)reconheceu o estudo de Conway (1968)referindo-se àsconclusõesdeste como Lei de Conway. Entretanto haviam poucas evidências na época que confirmassem, refutassem, ou discutissem a lei(BIRD, 2009).

Apenas na década de 90 o termo “Lei de Conway” voltou a ganhar força. Em 1995, a Lei de Conway foi apresentada como um padrão arquitetural na

FirstConferenceonPatternLanguagesofProgram Design 3_{(PLoP) por James O.} Coplien(COPLIEN, 1995). Nos anos que se seguiram, a Lei de Conway passou a ser referenciada nas mais diversas pesquisas tornando-se objeto de estudo das mesmas (RAYMOND, 1996; BOWMAN; HOLT, 1998, 1999; HERBSLEB; GRINTER, 1999a, 1999b). O mesmo aconteceu nos anos 2000 (COPLIEN; HARRISON, 2004; CATALDO et al., 2006; NAGAPPAN et al., 2008; BIRD, 2009; BURTON et al., 2011).

Embora, atualmente, exista uma maior discussão a respeito da Lei de Conway, poucos são os estudos que realmente se preocuparam em testar os efeitos da lei e

1_{Harvard Business Review é uma revista de administração e negócios publicada desde 1922 pela}

Harvard Business Publishing, editora da Harvard Business School. Segundo estudos da Erdos&

Morgan/CMP, é a publicação "mais influente dos Estados Unidos da América" entre os formadores de opinião(HARVARD BUSINESS REVIEW, 2014).

2_{A Datamation Magazine foi fundada em 1957, sendo a primeira revista impressa dedicada}

exclusivamente à computação e à indústria de processamento de dados emergentes. Sendo pioneira ao realizar a transição para mídia on-line em 1995, com Datamation.com (DATAMATION, 2014).

3_{ConferenceonPatternLanguagesofProgram (PLoP) é um grupo de conferências anuais, realizadas}

nos Estados Unidos, promovidos pelo Grupo Hillside. O objetivo dessas conferências é desenvolver e aperfeiçoar a arte de padrões de projeto de software.

verificar, através de métodos empíricos, se a pesquisa de Conway (1968) é,realmente,efetiva em suas conclusões(BIRD, 2009).

Muitos estudos relacionam a Lei de Conway com a congruência sociotécnica, que discute o alinhamento entre aspectos sociais e técnicos dentro das empresas. Cataldo et al. (2006) foram os primeiros a relacionar os dois fenômenos. Eles utilizam o conceito da congruência sociotécnica, para reforçar a lei, e explicar que a relação entre estrutura de comunicação da organização e design de sistemas, podem ser equiparadas as relações sociais e técnicas dentro das organizações, sendo essas relações de causa e efeito.

Mas somente com estudos empíricos é que que se poderá terconclusões mais sólidas sobre a Lei de Conway, confirmando-a, aprimorando-a ou derrubando-a. O estudo de Cataldo et al. (2006) garante apenas a existência de uma relação entre estruturas organizacionais e arquitetura de software, mas não garante como esse efeito acontece e nem quem tem mais peso nessa relação.

O ponto mais claro na necessidade dos estudos empíricos na área, se sustentam no fato de que existem diversas interpretações diferentes da Lei de Conway que chegam até mesmo a se contradizer (BAILEY et al., 2013; BETZ et al., 2013). Por se tratar de uma “lei”, a comunidade científica deveria ter uma visão mais homogênea do que essa lei realmente representa e interpretá-la, ao menos, de uma forma que tais interpretações não se contradissessem.

1.1. OBJETIVOS

Partindo do princípio de que existem diversas interpretações distintas sobre a Lei de Conway e que, muitas vezes, essas interpretações acabam sendo contraditórias (BAILEY et al., 2013; BETZ et al., 2013), o objetivo dessa pesquisa é investigaro fenômeno da Lei de Conway em um contexto específico a partir de um estudo empírico com intuito de se ter argumentos suficientes para verificar os efeitos dessa lei, atentando às variações que a mesma vem apresentando ao longo dos anos pelos mais diversos pesquisadores.

A partir do design de um quasi-experimento, onde duas equipes distintas, dentro de um contexto real de desenvolvimento de software, terão de projetar e implementar uma mesma aplicação, sob diferentes estruturas de comunicação, uma que é a utilizada pela empresa e outra que está alheia a essa estrutura, a finalidade é verificar as diferenças dos projetos, os desenhos arquiteturais dos sistemas e o desempenho das equipes diante das facilidades ou limitações de comunicação, traçando um paralelo com a Lei de Conway e verificando sua validade para esse experimento.

1.2. JUSTIFICATIVA

A motivação para realização dessa pesquisa veio através da proposta do Projeto de Replicação Conjunta (Joint Replication Project) do RESER 2013 Workshop4_{, onde a comunidade científica da Engenharia de Software, foi convidada} para discutir sobre o estudo de Conway (1968).

A decisão por investigar a Lei de Conway veio seguida de um design de um quasi-experimento, que permitisse investigar o fenômeno a partir da observaçãodo trabalho de duas equipes distintas no desenvolvimento de um mesmo projeto seguindo metodologias diferentes, para que com isso, fosse possível tirar conclusões positivas ou negativas acerta da Lei de Conway.

O resumo dessa dissertação5_{com as análises iniciais do estudo sobre a Lei de} Conway foi submetido para o RESER 2013, compondo a sessão de Replicação Conjunta, juntamente com outras três pesquisas,as quais serão discutidas no Capítulo 5, com algumas citações ao longo do texto dos outros capítulos.

4_{O RESER(International Workshop on Replication in Empirical Software Engineering Research) é um}

eventoquefaz parte do ESEM (International Symposium on Empirical Software Engineering and

Measurement) e ocorredurante a ESEIW (Empirical Software Engineering International Week). A

missão do Workshop é debater sobre estudos de replicação na Engenharia de Software. Uma das sessões do RESER é o Joint Replication Project, onde, a cada evento, a comunidade científica é convidada a discutir, em suas pesquisas, um determinado assunto. Em 2013, ocorreu a terceira edição do RESER, em Baltimore, Maryland, EUA.

5 _{SANTANA, A. M. DE; SILVA, F. Q. B. DA; MIRANDA, R. C. G. DE; et al. Relationships Between}

Communication Structure and Software Architecture: An Empirical Investigation of the Conway’s Law at the Federal University of Pernambuco. Proceedings of the 2013 3rd International Workshop on Replication in Empirical Software Engineering Research.Anais., RESER’13. p.34–42, 2013. Washington, DC, USA: IEEE Computer Society. Disp.:<http://dx.doi.org/10.1109/RESER.2013.18>.

1.3. METODOLOGIA,PERGUNTA DE PESQUISA E HIPÓTESES

Ao longo do processo de desenvolvimento, as duas equipes foram acompanhadas em suas tarefas por três observadores que se revezaram na função de tomar nota de acontecimentos que fossem relevantes para a pesquisa, sendo dois deles pesquisadores membros da empresa e um externo. Também foram realizadas entrevistas com os participantes com intuito de entender como eles pensaram na solução do problema. Terminado o prazo do projeto, foi realizado um grupo focal, onde os desenvolvedores apresentaram desenhos de como entendiam a arquitetura do sistema que desenvolveram. Por fim, foi realizada engenharia reversa para se chegar a um modelo arquitetural que correspondesse a estrutura do projeto apresentado por cada equipe.

A metodologia aplicada foi utilizada para responder a seguinte questão de pesquisa: “Como os diferentes tipos de estrutura de comunicação intra-equipes

afetam o design de um sistema de software desenvolvido por essas equipes?”

A pergunta de pesquisa apontou para um conjunto de hipóteses:



𝐻

atuando no projeto seguindo a estrutura de comunicação da organização. 

𝐻

dificuldades no momento de integração dos módulos do sistema.



𝐻

manter do que o desenvolvido pela equipe ágil.



𝐻

do que a apresentada pela equipe hierárquica.



𝐻



𝐻

alternativos do que a desenvolvida pela equipe ágil.

As hipóteses minaram alguns pontos importantes da pesquisa. Após análise dos dados, os resultados apontam uma ligeira discordância da Lei de Conway, onde foi percebido que a estrutura de comunicação organizacional não tem tanto impacto no design do sistema. Pelos resultados, se uma estrutura de comunicação,

independentemente de ser a adotada pela organização, for bem definida para um determinado projeto, poderá apresentar resultados semelhantes ou melhores, quando comparado a estrutura organizacional, em relação a arquitetura do software.

1.4. ESTRUTURA DO TRABALHO

Os demais capítulos dessa dissertação estão organizados como segue: No Capítulo 2 é apresentada a revisão da literatura contendo as principais discussões e interpretações sobre a Lei de Conway, dando destaques a diversos aspectos e fundamentos apresentados pelos pesquisadores.

O Capítulo 3 apresenta a descrição da metodologia partindo do contexto, explicando a questão de pesquisa e hipóteses, discutindo o design do estudo, apontando a amostra, indicando o preparo e o processo de coleta de dados, discorrendo sobre síntese e análise dos dados e finalizando com as ameaças da validade e confiabilidade do estudo.

No Capítulo 4 os resultados são apresentados e analisados, sendo observadas as primeiras conclusões do estudo.

O Capítulo 5 apresenta uma discussão com os resultados dos estudos que compuseram a sessão de Replicação Conjunta do RESER 2013, apresentando uma dimensão maior das conclusões sobre Lei de Conway.

Por fim, no Capítulo 6 são feitas as considerações finais dessa dissertação, apontando as implicações para pesquisa, limitações e melhorias e os trabalhos futuros.

2 REFERENCIAL TEÓRICO

Este capítulo apresenta um conjunto de discussões envolvendo a Lei de Conway, conforme apresentado na literatura, mostrando as impressões dos pesquisadores que tem estudado e investigado os fatores acerca das conclusões do estudo de Conway (1968). Foram considerados para essa revisão da literatura, os artigos mencionados no estudo de Bailey et al.(2013) e Hvatum e Kelly(2005).

Nas subseções que seguem, é feito um apanhado dos principais estudos sobre a Lei de Conway, apresentado um conjunto de diferentes interpretações dela,indicado possíveis extensões, e citando as prescrições da lei segundo os pesquisadores. Além disso, o capítulo encerra com um apanhado de estudos relacionados com o apresentado nesta dissertação.

2.1. PRINCIPAIS ESTUDOS

A Lei de Conway tem sido amplamente discutida e aceita na Engenharia de Software, mas não apenas nessa área. Também podemos encontrar referências ao estudo de Conway (1968) em áreas distintas, como: Gestão de Qualidade de Software, Sistemas de Informação, Melhorias de Processo e Produto, Psicologia, Negócios, Economia e Finanças, Multimídia e Inteligência Artificial, etc.(BAILEY et al., 2013). Alguns estudos tem se destacado por serem pioneiros na divulgação da Lei, por terem sido referenciados e servirem de base para outros estudos e/ou, ainda, por abrirem uma ampla discursão acerca das conclusões do estudo de Conway(1968), permitindo uma série de reflexões sobre a mesma.

Um grupo focal realizado

naEuropeanConferenceonPatternLanguagesofProgramsEuroPLoP 2005(HVATUM; KELLY, 2005)procurou discutir os efeitos da Lei de Conway na Engenharia de Software e deu destaque a dois estudos que passaram a ser amplamente referenciados na literatura: Raymond(1996) e Coplien e Harrison(2004).Em 2013, durante o RESER, Bailey et al. (2013)apresentou uma revisão da literatura onde classificou como importantes (além estudos do EuroPLoP 2005 e do estudo de

Melvin Conway (1968)) outros 9 estudos, com base no número de vezes que foram citados pelos artigos resultantes de sua revisão da literatura: Herbsleb e Grinter (1999a), Herbsleb e Grinter (1999b), Bird(2009), Amrit et al.(2004), Herbsleb (2007), Coplien (1995), Cataldo et al. (2006), Souza, de et al. (2005) e Rowe et al. (1984).

2.1.1. CONWAY(1968)

Conway (1968) concluiu que “qualquer organizaçãoque desenvolveum sistema (definido de forma ampla) iráproduzir um designcuja estruturaé uma cópia daestrutura de comunicaçãoda organização”. A maioria dos pesquisadores têm utilizado esta afirmação como verdade sem nenhuma ressalva sobre ela, muitos utilizando as mesmas palavras usadas por Melvin Conway, outros utilizando suas próprias palavras, mas sem desviar do significado original (BAILEY et al., 2013).

Bird et al. (2008) utilizou a afirmativa: “...conecta a estrutura do artefato com a estrutura organizacional” para se referir ao estudo de Conway (1968). Já Herbleb e Mockus (2003) diz que “...a estrutura do sistema se assemelha a estrutura da organização que o projetou”, semelhante a Ebert (2011) que afirma que “...a estrutura do produto de software reflete a estrutura organizacional da companhia que o produziu” e a Boer, de; Vliet e Van (2009)que pontuam que “...a estrutura de uma organização é espelhada na estrutura do software que a organização produz”.

Conway explica a relação entre sistema e estrutura da organização como sendo homomórfica:

Estetipo de relacionamentoque preservaa estruturaentre dois conjuntos decoisasé chamado dehomomorfismo. Falando comoum matemático, diríamos que há homomorfismodo gráficolinearde um sistema parao gráficolineardo design desua organização.(CONWAY, 1968)

Alguns pesquisadores interpretaram a Lei de Conway como sinônimo desse relacionamento homomórficoentre suas estruturas. (CATALDO et al., 2008)afirma que “...a estruturado componente e a estrutura organizacional estão numa relaçãohomomórfica, onde mais de umcomponente pode seratribuído a uma equipe, porém um componentedeve ser atribuído auma única equipe”. Enquanto isso, Oliva et al. (2012) aponta que “...a relaçãoentreaarquitecturadeumsistema de softwareea estrutura daorganização que desenvolveueste softwareéhomomórfica”.

Outros pontos abordados no estudo de Conway (1968) são analisados por outros autores, como: impacto do tamanho da organização sobre a produtividade e qualidade dos produtos (ARANDA, 2010); cita o exemplo do sistema de armamento (BATENBURG et al., 2008); mostra o exemplo ilustrando a relação entre a estrutura de um sistema e a estrutura da organização que o projetou (gráfico) (ZHOU, 2008) e cita que “As organizaçõesnormalmente atribuema responsabilidade de um

componenteauma equipe” (CATALDO; HERBSLEB, 2009).

2.1.2. RAYMOND(1996)

Raymond(1996) apresenta uma versão da Lei de Conway com base em um exemplo de design de compilador:

Umaorganização de pesquisacontratadatinhaoito pessoas para produzir um compiladorCOBOLeum compiladorALGOL. Depois de algumasestimativas iniciaisde dificuldade etempo,cincopessoasforam designados parao

desenvolver o compiladorCOBOLe trêspara o ALGOL. O

compiladorCOBOLresultanterodouem cinco fases e o compilador

ALGOLrodouemtrês. (CONWAY, 1968)

Com base nesse exemplo, Raymond(1996) cria uma “prova” da Lei de Conway dizendo que: “A regra de quea organização dosoftwaree a organizaçãoda equipe desoftwareserãocongruentes; foi inicialmente apresentada como ‘Se você temquatro grupos de trabalhoemum compilador, você terá um compilador de 4 passos.’”

Outros pesquisadores têm utilizado a conclusão de Raymond(1996) de uma forma mais geral: “Se n grupos trabalham em um compilador, você terá um compilador de n passos” (BAILEY et al., 2013). Essadefinição foi analisada na EuroPLoP 2005(HVATUM; KELLY, 2005) e considerada a versão mais fácil de se considerar da Lei de Conway, tratando-se de uma microssituação, onde se tende a quebrar um problema em pedaços que correspondam ao número de desenvolvedores disponíveis para resolvê-lo. Entretanto, Hvatum e Kelly(2005) alertam para um problema decorrente dessa prática, uma vez que “embora possa parecer fácil gerenciar essespedaços, é improvável que eles serão do mesmotamanhoeo designresultantepouco provavelmente serábom”, destacando que isso poderia ser resolvido gastando-se tempo produzindo um design melhor,

podendo, até mesmo, utilizar menos módulos e menos programadores. Hvatum e Kelly(2005) ainda apontam que mesmo sendo essa versão da Lei de Conway apresentada por Raymond(1996)“a mais conhecida e mais fácil de entender, ela é, na verdade, a menos interessante”.

2.1.3. COPLIEN E HARRISON(2004)

Coplien e Harrison (2004)apresentam sua definição da Lei de Conway: “Existe uma estreita relação entre a estrutura de uma organização e os artefatos que ela constrói”. Eles discutem os padrões de construção de software organizacionais e destacam o efeito da lei nessa relação.

Ao falar das implicações da Lei de Conway, Coplien e Harrison (2004) chegam a ser duros:

Se partes de uma organização (por exemplo, equipes, departamentos ou subdivisões) não refletem de perto partes essenciais do produto, ou se as relações dentro das organizações não refletem as relações entre partes do produto, então o projeto estará com problemas (...) Portanto: Certifique-se que a organização é compatível com a arquitetura do produto.(COPLIEN; HARRISON, 2004)

Em sua interpretação, Coplien e Harrison (2004) afirmam que “a arquitetura [do sistema] deve dirigir a organização e não vice-versa”, dessa forma eles acreditam que deve haver um domínio da arquitetura sobre a organização e sugerem que “a melhor estrutura em longo prazo é derivada de um alinhamento de três vias principais: regras de negócio (domínio), estrutura da organização e estrutura do software” (COPLIEN; HARRISON, 2004).

2.1.4. HERBSLEB E GRINTER (1999A, 1999B)

Herbsleb e Grinter (1999a, 1999b) apresentam o advento do desenvolvimento de software distribuído traçando um paralelo com a Lei de Conway. Ambos os artigos são similares e descrevem um estudo de caso de equipes de software geograficamente distribuídas para verificar desafios na coordenação desses projetos. Eles destacam que “...a estrutura do sistema espelha a estrutura da organização que o projetou”.

Bailey et al. (2013) observa que a afirmação de Herbsleb e Grinter (1999a, 1999b) sobre a Lei de Conway não menciona a estrutura de comunicação da organização, que é especificada na definição original de Conway(1968). Entretanto em um dos artigos, eles dizem que o relacionamento é argumentado por Conway como uma “...consequencia necessária da necessidade de comunicação entre as pessoas que fazem o trabalho” (HERBSLEB; GRINTER, 1999d). No outro artigo, eles afirmam que “A Lei de Conway... foi o primeiroreconhecimento explícito de queos padrões de comunicaçãode uma organizaçãodeixam uma marca indelévelsobreo produtoconstruído” (HERBSLEB; GRINTER, 1999c).

Herbsleb e Grinter (1999a, 1999b) apontam que Conway(1968) foca primariamente em questões de arquitetura, na estrutura do produto e o que será desenvolvido, evocando a necessidade de designs modulares que reduzem a comunicação e facilitam a coordenação efetiva, enquanto seus estudos exploram outras dimensões como planejamento e processos. Eles afirmam que “Idealmente, arquiteturas, planos, e processos – mecanismos de coordenação – deveriam ser suficientes para estabelecer uma coordenação efetiva sobre equipes” (HERBSLEB; GRINTER, 1999d).

No geral, a essência dos estudos de Herbsleb e Grinter (1999a, 1999b) é consistente com a Lei de Conway (no que diz respeito a um bom design garantir uma melhor coordenação), entretanto isso seria mais difícil de observar em equipes distribuídas globalmente. Sua conclusão é de que a Lei de Conway até se aplica ao desenvolimento distribuído, mas apenas para componentes de produtos que possuem arquitetura, planos e processos estáveis e estabelecidos, uma vez que a instabilidade aumenta as necessidades de comunicação, o que se torna difícil para equipes distribuídas.

2.1.5. DEMAIS ESTUDOS

Os demais estudos principais apresentam descrições interessantes sobre a Lei de Conway e são citados na literatura por outros estudos como forma de evidenciar e ampliar a discussão sobre a lei (BAILEY et al., 2013).

Bird (2009)apresenta sua inferência da Lei de Conway como um corolário da mesma, na qual também considera as consequências da Lei de Conway para uma empresa de desenvolvimento:

Um Sistema de software cuja estrutura se aproxima da estrutura de comunicação de sua organização, funciona “melhor” (de forma geral) do que um subsistema no qual sua estrutura difere da estrutura de comunicação de sua organização.(BIRD, 2009)

Sobre a semelhança entre estrutura de comunicação organizacional e sistemas, Amrit et al. (2004) afirma: “Organizações que projetam sistemas estão restritas a produzir designs que são cópias das estruturas de comunicação dessas organizações”(AMRIT et al., 2004a).

Herbsleb (2007), reforça a relação homomórfica apresentada por Conway(1968):

Conway... observou que a estrutura de um produto tende a ser semelhante a estrutura da organização que o projetou. Conway... apontou que isto é provável resultar em uma relação homomórfica entre a arquitetura e a organização, ou seja, cada componente é atribuído a exatamente uma equipe, apesar de uma equipe poder criar mais de um componente. (HERBSLEB, 2007)

Coplien (1995)apresenta uma questão interessante quanto a implicação da Lei de Conway caracterizando-a como bilateral ao afirmar: “Organização segue arquitetura, ou arquitetura seque organização”.

Tratando de congruência,Cataldo et al. (2006)aponta:

Na literatura da teoria organizacional, o conceito de congruência, ou fit, é uma ideia bem desenvolvida e normalmente refere-se ao jogo entre um design organizacional particular e capacidade da organização para realizar uma tarefa. A definição ou seleção de uma estrutura organizacional é influenciada, entre vários fatores, pelas interdependências entre tarefas.(CATALDO et al., 2006)

Souza, de et al. (2005)apresenta a mesma definição dada por Herbsleb e Grinter (1999a, 1999b): “...a estrutura do sistema espelha a estrutura da organização que o projetou”.

Falando de estrutura de sistemas e linguagens, Rowe et al. (1984), apresenta a seguinte situação, onde os sistemas operacionais apresentam características diferentes da estrutura da linguagem que o implementou (por exemplo, sistema não

estruturado escrito em linguagem estruturada): “Na verdade, Unix e C são interessantes exemplos contrários à lei de Conway,que diz que os sistemas se parecem com as organizações que os produzem, o que certamente se aplica [também] ao PL/1 e Ada”(ROWE et al., 1984).

2.2. INTERPRETAÇÕES DA LEI DE CONWAY

Conway(1968), especificamente, identifica a relação entre “design de sistemas” e “estrutura organizacional”. Desde que suas conclusões foram observadas inicialmente até os dias de hoje, diversas são as interpretações dadas a cerca do entendimento de seu estudo o que pode ser tido como, ainda, uma carência na compreensão da Lei de Conway (BAILEY et al., 2013).Herbsleb e Mockus(2003a), chegam a sugerir uma teoria de coordenação que pode ser utilizada em testes empíricos para definir com precisão os fenômenos relevantes e gerar uma formalização da Lei de Conway, o que alinharia o conjunto de interpretações com base nos resultados dos testes.

As subseções que seguem apresentam o foco das interpretações da Lei de Conway nas mais diversas pesquisas que tem tratado o assunto.

2.2.1. DESIGN DO SISTEMA

O termo “design de sistema” é utilizado por Conway(1968)de forma ampla, o que pode ser causa das interpretações diferentes por parte dos pesquisadores. Esse termo é constantemente substituído por outros (BAILEY et al., 2013), conforme veremos a seguir.

2.2.1.1. ARQUITETURA DO SOFTWARE

O termo “arquitetura de software” pode ser encontrado nos estudos de Del Rosso (2009), Bass et al. (2008) e Coplien(2006).

Del Rosso (2009), utiliza uma análise de rede social para estudar as redes de conhecimento que se desenvolve através da troca de conhecimento entre os

desenvolvedores. Seus resultados sugerem a importância do alinhamento entre a arquitetura do software e a organização no processo evolutivo do sistema. O termo pode ser encontrado no trabalho nos seguintes pontos: “...uma arquitetura de software específico tende a espelhar a estrutura da organização que o desenvolveu”(ROSSO, DEL, 2009) e “Um link que existe entre a arquitetura de software e a estrutura da organização é conhecido como lei de Conway” (ROSSO, DEL, 2009).

Com intuito de avaliar a competência arquitetural das organizações por meio de modelos que “ajudem na explicação, medida e melhoria da arquitetura que compete a um indivíduo ou organização”, Bass et al. (2008), sobre a Lei de Conway diz:

A arquitetura de software e o sistema resultante são desenvolvidos por pessoas dentro de um contexto organizacional e de negócios. Tanto uma organização quanto uma arquitetura possuem estrutura, e o alinhamento dessas estruturas tem um grande impacto, seja no design da arquitetura ou no design da organização. Isso foi observado pela primeira vez em 1968 por Melvin Conway. (BASS et al., 2008)

De forma similar, Coplien(2006) afirma que “a estrutura de qualquer arquitetura de software reflete a estrutura da organização que o constrói”.

2.2.1.2. ESTRUTURA DO PRODUTO

Le e Panchal (2012)mencionam a Lei de Conway no seguinte contexto:

Enquanto a literatura de congruência sociotécnica analisa os impactos das estruturas de produto sobre as organizações, porém não há nada sugerindo que a estrutura organizacional também afeta a estrutura do produto. Na literatura científica organizacional, este efeito é comumente conhecido como Lei de Conway. (LE; PANCHAL, 2012)

Herbsleb e Mockus(2003)fazem referência a “uma estrutura organizacional que espelha na estrutura do produto”. Já Salger(2009)em seu estudo sobre gestão de desenvolvimento de software global aponta que “a estrutura organizacional e a estrutura do produto influenciam um ao outro”. Em outro estudo, Panchal menciona a Lei de Conway enquanto discursa a relação entre estrutura organizacional e estrutura do produto:

O impacto da estrutura organizacional na estrutura do produto é bem conhecida. De acordo com Conway – qualquer organização que desenvolve

um sistema (definição mais ampla do que apenas em sistemas de informação), inevitavelmente, produzirá um projeto cuja estrutura é uma cópia da estrutura de comunicação da organização... Ao mesmo tempo, a comunicação entre os diferentes participantes baseia-se na estrutura do produto e é acionada pelas as dependências entre os subsistemas, o que implica o efeito da estrutura do produto na estrutura organizacional. Assim, os produtos e as estruturas organizacionais são altamente interdependentes por natureza. (PANCHAL, 2010)

2.2.1.3. ARQUITETURA DO PRODUTO

Colfer e Baldwin(2010)estabelecem uma relação isomórfica ao afirmar que “deve haver uma relação isomórfica (espelhada) entre os padrões de comunicação dos desenvolvedores e a arquitetura do produto em desenvolvimento”.

Predizendo uma estrutura de comunicação baseada na estrutura do produto, Biedermann e Lindemann(2011) mencionam “que a arquitetura do produto imita a organização que desenvolveu o produto”.

Para Amrit e Van Hillegersberg(2010) é importante considerar o efeito de acoplamento de software sobre coordenação de requisitos ainda no contexto da Lei de Conway uma vez que “Conway... analisou a relação entre a arquitetura do produto e a estrutura organizacional”.

Kwan et al. (2011) trata a medição da congruência sociotécnica com respeito a taxa de sucesso de construção de software, afirmando que “a conceituação original da congruência sociotécnica foi a Lei de Conway, que observou que a arquitetura do produto reflete a estrutura organizacional”.

2.2.1.4. ESTRUTURA DO ARTEFATO

O termo “estrutura do artefato” foi utilizado nos estudos de Jermakovics et al. (2011), Sarma et al. (2009) e Bird et al. (2008).

Jermakovics et al. (2011) propõem uma abordagem para mineração e visualização de redes de desenvolvedores a partir de sistemas de controle de versão e afirmam que “a estrutura do artefato de software está fortemente relacionada a estrutura da organização”. JáBird et al. (2008) estudam a estrutura social em comunidades de código aberto e afirmam que “A ‘Lei de Conway’... conecta estrutura do artefato com a estrutura da organização”. Por fim, Sarma et al. (2009)afirma:

Com interfaces bem definidas, os esforços das equipes estão confinados a grupos menores, e as necessidades de coordenação são moderadas. Princípios de design de software, tais como a separação de interesses... desempenham papel nesse processo, de acordo com a "Lei de Conway... que conecta estrutura artefato com estrutura organizacional. (SARMA et al., 2009)

2.2.2. ASPECTOS ORGANIZACIONAIS E SOCIAIS

Assim como o termo “design de sistema”, utilizado inicialmente por Conway(1968), tem um conjunto distinto de interpretações, também o termo “estrutura de comunicação da organização”, apresentado no mesmo estudo, é diferentemente discutido por pesquisadores interessados na Lei de Conway, que se baseia em ambos (BAILEY et al., 2013). A seguir discutimos as diferentes terminologias utilizadas por outros pesquisadores referindo-se a “estrutura de comunicação da organização”.

2.2.2.1. ESTRUTURA ORGANIZACIONAL

Independentemente da Lei de Conway, o impacto da estrutura organizacional sobre um projeto é uma área comum de estudo. Em sua pesquisa Galvina e Åmite (2012) apontam os problemas de comunicação e coordenação em um projeto de desenvolvimento distribuído. Sua principal questão de pesquisa explora a estrutura organizacional: “Como uma estrutura organizacional não clara afeta os fluxos de tarefas em um projeto de software altamente distribuído?” Realizado o estudo, em suas conclusões, Galvina e Åmite(2012) respondem a pergunta de pesquisa como “...nós aprendemos que um relacionamento organizacional fechado resultou em uma coordenação encapsulada e quebrou o plano inicial de atribuição de tarefas”. Ou seja, seu resultado indica a importância de uma estrutura organizacional clara para melhor coordenação (GALVINA; ÅMITE, 2012).

Hadaytullah et al. (2010)baseiam o seu estudo na estrutura organizacional para desenvolver uma arquitetura de software que esteja em conformidade com essa estrutura e que também atenda a requisitos de qualidade. O estudo afirma que “para qualquer sistema de software, a estrutura do sistema e a estrutura organizacional de desenvolvimento são ou serão semelhantes”.

O estudo de (DHUNGANA et al., 2010)apresenta meios de estruturar um espaço de modelagem para área de engenharia de linha de produto de software (LPS), enfatizando a necessidade de estruturar modelos linhas de produto baseados na estrutura organizacional de acordo com a Lei de Conway.

A fim de especificar melhor o conhecimento, Strandberg et al. (2006) apresenta a definição de organização e arquitetura organizacional, apresentando um novo termo:

Organização, [é] a entidade social cujo objetivo é direcionado, é projetada como deliberadamente estruturada e coordenada, e está conectada ao ambiente externo... A arquitetura organizacional descreve (1) como os direitos de decisão são atribuídos dentro da organização, (2) a avaliação de performance de sistemas de ambos indivíduos e unidades negócio, e (3) os métodos para prover incentivos ou recompensar indivíduos pela realização de suas tarefas de forma eficaz. (STRANDBERG et al., 2006)

Relacionando essas definições com a Lei de Conway, Strandberg et al. (2006) diz que “qualquer organização que desenvolve um sistema, inevitavelmente, irá produzir um design cuja estrutura reflete a estrutura de comunicação da organização”. A partir dessas afirmações, é possível fazer um alinhamento de três vias entre produto, processo e estrutura organizacional. O estudo ainda alerta para problemas com estruturas organizacionais inflexíveis,

A lei de Conway... basicamente afirma que empresas podem se tornar vítimas de seu próprio sucesso, pois não podem romper com sua arquitetura de produtos existentes, com a estrutura organizacional e/ou com a estrutura de processos com rapidez necessária quando há uma necessidade de uma mudança, por exemplo, devido a tecnologias inovadoras, novas formas de organização, mudanças nos processos, etc. (STRANDBERG et al., 2006) Coplien e Harrison (2004) sugerem, de modo similar, três vias de alinhamento entre organização, negócios e estrutura de software.

Apesar das similaridades encontradas nas três vias de alinhamento apresentadas por Strandberg et al. (2006) e Coplien e Harrison (2004), ainda que com diferenças nas estruturas envolvidas, é possível notar que a estrutura organizacional tende a ser tratada de forma consistente, enquanto as outras estruturas são tratadas de forma bastante diferentes (BAILEY et al., 2013).

2.2.2.2. ESTRUTURA SOCIAL

Alguns estudos, citam os efeitos de fatores sociais no desenvolvimento de software (HERBSLEB; GRINTER, 1999d; SOUZA, DE et al., 2005; OLIVA et al., 2012), entretanto devemos ter cuidado para não nos confundirmos, pois fatores sociais no contexto de desenvolvimento de software, por si só, difere de afirmações específicas sobre Lei de Conway.

A maioria das pesquisas sobre a estrutura social, analisa sua relação com a estrutura do sistema, também conhecido como congruência sociotécnica.Avritzer et al. (2010)afirmam que “introduzida por Cataldo et al. (2006), a congruência sociotécnica mede o alinhamento das dependências de tarefas para atividades de coordenação”. Onde Conway(1968) originalmente escreveu a respeito de “estrutura de comunicação da organização”, o estudo de congruência sociotécnica concentra-se nas estruturas sociais de deconcentra-senvolvedores e equipes, independente de como essas estruturas são refletidos em uma organização formal(BAILEY et al., 2013).

Alguns estudos têm procurado esclarecer a Lei de Conway pela construção de gráficos de redes sociais, tanto do grupo de desenvolvimento quanto da arquitetura do produto resultante, calculando-se a congruência dos dois gráficos(AMRIT et al., 2004b; VALETTO et al., 2007).

Por fim, as implicações da Lei de Conway tem sido discutidas em profundidade. Bowman e Holt(1998, 1999) empregaram a Lei de Conway para inferir a partir de artefatos (desde copyrightenotificação de mudança) a estrutura social dos desenvolvedores de projetos open source (código aberto). Uma vez que essa estrutura social é inferida, facilita-se a identificação de componentes de sistema especialistas, revela as dependências não-funcionais, e fornecem estimativas de qualidade para os componentes.

2.2.3. DIREÇÕES DE DEPENDÊNCIA

As direções de dependência discutem qual lado influencia mais a Lei de Conway, se as formas de estruturas organizacionais ou o design do sistema, partindo-se de um para o outro. Discutiremos sobre bidirecionalidade e unidirecionalidade.

2.2.3.1. BIDIRECIONAL

Colfer e Baldwin(2010) chegaram a uma conclusão interessante sobre o efeito bidirecional da Lei de Conway. Primeiramente eles disseram que “os vínculos organizacionais de um projeto de desenvolvimento... irão corresponder às dependências técnicas do sistema que está sendo desenvolvido”. Com base nessa afirmação, eles concluíram que Conway(1968) “não impôs uma direção de casualidade: os efeitos podem fluir a partir da estrutura organizacional para o design técnico...; a partir do design técnico para a estrutura organizacional...; ou em ambas as direções”(COLFER; BALDWIN, 2010). Em seu estudo de caso em trabalhos distribuídos entre as empresas da amostra, Colfer e Baldwin(2010) confirmam que a direção de casualidade flui nos dois sentidos.

De forma semelhante, De Souzae Redmiles (2005) deduzem que a Lei de Conway é uma relação bidirecional entre o produto e o modelo tarefa com base na declaração de Coplien e Harrison (2004):

Se as partes de uma organização (equipes, departamentos ou subdivisões) não refletem de perto as partes essenciais do produto, ou se as relações entre as organizações não refletem as relações entre os componentes do produto, então o projeto estará em apuros. (COPLIEN; HARRISON, 2004)

2.2.3.2. UNIDIRECIONAL

Le e Panchal(2012)analisaram, utilizando técnicas de modelagem, as interdependências entre a co-evolução de estruturas de produtos e estruturas comunitárias em comunidades de desenvolvimento de produtos de baixo acoplamento (principalmente, comunidades de software de código aberto). Eles apresentaram algumas hipóteses, com base em seu estudo, e concluíram que a estrutura do produto influencia significativamente a estrutura da comunidade. Porém, o inverso não ficou claro.

Através de uma revisão da literatura sobre estrutura organizacional, Hadaytullah et al., (2010) confirmam o impacto da estrutura organizacional sobre a arquitetura do software, sugerindo uma natureza unidirecional da Lei de Conway.

Dhungana et al. (2010)discutem diferentes estruturas a serem seguidas durante a modelagem da engenharia de linha de produto de software. Uma das

estruturas citadas é uma estrutura organizacional que inclui interesses de todos os membros da equipe. Sugerindo que não seguir a estrutura da organização trará redundância ao modelo de software. Assim, eles afirmam a natureza unidirecional na Lei de Conway.

2.3. EXTENSÕES DA LEI DE CONWAY

A Lei deConway é relativamente simples(STRANDBERG et al., 2006), (BURTON et al., 2011). Com base nessa afirmação, Bailey et al.(2013) em sua revisão da literatura, apontou estudos que, de algum modo, conseguiram dar uma nova visão a Lei de Conway, com base em suas nuances e fronteiras indefinidas que alguns pesquisadores tem explorado.Assim, Bailey et al.(2013) definiram como extensão da Lei de Conway, trabalhos de pesquisa que atendessem algum dos critérios abaixo:

 Adiciona uma nova dimensão para a Lei de Conway.

 Reconhece um novo fator aplicável a Lei de Conway.

 Identifica problema com as estruturas definidas na Lei de Conway.

As subseções seguintes apresenta as pesquisas que atenderam os critérios apontados por Bailey et al.(2013), descrevendo em que cada uma delas se enquadra no critério específico.

2.3.1. NOVA DIMENSÃO

Quanto a nova dimensão, cada um dos estudos, introduziu um novo conceito a Lei de Conway que se baseia em dois: estrutura de comunicação da organização e design do sistema.

Strandberg et al. (2006) introduziram o conceito de "estrutura de processo" na Lei de Conway. O alinhamento de duas viasdo estudo original de Conway (1968) é estendido, em seu estudo, a um alinhamento de três vias entre as estruturas de organização, produto e processo.

Um padrão semelhante de alinhamento de três vias é observado por Coplien e Harrison(2004), onde eles vão além de organização e software e incluem “estrutura de negócios.”

Del Rosso(2009)também sugere um alinhamento de três vias, com a terceira dimensão sendo a "rede de conhecimento".Ele afirma que

a compreensão das diferentes visões: estrutura organizacional, rede de conhecimento e arquitetura de software, são essenciais na manutenção e evolução do software. Na verdade, o seu alinhamento deve ser garantido e nossa pesquisa nos permite dizer que a estrutura da rede de conhecimentos deve ser considerada neste processo. (ROSSO, DEL, 2009)

2.3.2. NOVO FATOR

Alguns pesquisadores observaram que o processo de desenvolvimento de software é mais amplo do que normalmente pensamos e com isso passaram a considerar todos os stakeholders envolvidos na construção do software (inclusive os externos) como novo fator nas dimensões da Lei de Conway.

A tendência (CATALDO; HERBSLEB, 2008a) sugere que a Lei de Conway é limitada a desenvolvedores e a organização que projeta o sistema. Hendry (2008) afirma, a partir de uma perspectiva sociotécnica, a importância de compreender as interações entre as partes interessadas, processos e materiais que facilitem o sucesso do projeto, já queConway (1968) não discute. Hendry (2008)sugere que a “Lei de Conway...deva ser expandida além dos limites normais de um processo de desenvolvimento para incluir stakeholdersexternos, e não apenas desenvolvedores”.

De forma semelhante, Coplien(2006) identifica um novo fator, afirmando: Podemos pensar nos desenvolvedores como ‘habitando’ o código. Porém muitas vezes esquecemos que os usuários de um programa são também ‘habitantes’ do código. Isso sugere que a arquitetura de software deve estar alinhada não apenas com a estrutura da organização que o constrói, mas também com o da organização que o utiliza. (COPLIEN, 2006)

Dhugana et al. (2010) sugerem que o conhecimento do negócio deve ser distribuído entre as partes interessadas (stakeholders). A fim de incluí-los na construção de um espaço de modelagem para uma linha de produtos, é necessário que a arquitetura siga a estrutura da equipe. Desta forma, as preocupações dos

2.3.3. PROBLEMAS COM ESTRUTURAS

Os problemas com as estruturas podem prejudicar o entendimento e até mesmo a observação da Lei de Conway em alguns contextos específicos. As conclusões dos estudos de Schaefer (2005), Strandberg et al. (2006) e Ye et al. (2008) apontam aquilo que eles definiram como problemas na Lei de Conway.

Schaefer(2005) refuta a Lei de Conway da seguinte forma:

A crença de que ‘organizaçõesque produzem sistemas... estão restritas a produzir projetos que são cópias da estrutura de comunicação dessas organizações’, pode ser facilmente refutada pela observação de que organizações hierárquicas têm sido muito bem sucedidas na concepção e implementação de sistemas emrede,posteriores à invenção do Ethernet e TCP/IP. (SCHAEFER, 2005)

Schaefer(2005)aponta ainda que em estruturas organizacionais tradicionais, os desenvolvedores são mantidos longe das tomadas de decisão que afeta a qualidade do software produzido. Apontando este problema, o estudo conclui,

a solução para a organização é simples, pelo menos em conceito. Em primeiro lugar, deve-se reconhecer que alguns problemas existem dentro da organização e devem ser tratados em nível estrutural e, segundo, quando esses problemas ocorrerem, a organização deve fazer uma tentativa honesta de mudar estruturalmente, como forma de reação. (SCHAEFER, 2005)

Strandberg et al. (2006)sugerem limitações em empresas que seguem determinadas estruturas organizacionais sem possibilidade de mudanças. A necessidade de flexibilizar a estrutura organizacional é proposta ao afirmar,

Com referência ao trabalho deauto-organização,do vencedordoPrêmio Nobel Ilya Prigogine, Jenner e Hebert(não datado) apresentam casos em que as empresas têm usado com sucesso a desordem eo caos para gerar novas estruturas e padrões organizacionais. Não seguir processos padrões em várias ocasiões resultou em encontrar melhorias nos produtos, quer como falhas de sucesso (por exemplo, Post-It6_{) ou deliberadamente}

evitando seguir procedimentos padrões (por exemplo, o início de Skunk Works7_{). (STRANDBERG et al., 2006)}

6_{Inicialmente o Post-It não fez muito sucesso. Criado pelo cientista Dr. Spencer Silver da 3M (que}

desenvolve produtos aderentes, como adesivos e colas), em 1968 e rejeitado diversas vezes pela empresa em que trabalhava, o adesivo de fácil remoção só começou a ser comercializado em 1977 depois que um amigo de Spencer passou a utilizar a invenção para marcar páginas do livro do coral da Igreja (3M, 2013).

7_{Skunk Works é um apelido oficial para a fábrica de aeronaves}

LockheedMartin’sAdvancedDevelopmentPrograms (ADP), conhecida formalmente como LockheedAdvancedDevelopmentProjects. O termo foi utilizado pela primeira vez em 1943, quando a fábrica foi acionada pela força aérea para produzir uma uma aeronave às pressas. Como não havia tempo a perder com burocracia, a organização produziu a aeronave sem um contrato formal, a essa

Ye et al. (2008) estudam a estrutura de comunicação entre os desenvolvedores, e sugerem que, “A dependência de unidades do sistema é reduzida através dos esforços de modularização. A modularização do sistema, no entanto, não leva à eliminação de tarefas dependentes entre os desenvolvedores”. A primeira apontada no estudo é que a arquitetura muda através do ciclo de vida do produto e essas alterações resultam em grandes mudanças de dependências de tarefas entre desenvolvedores. Em segundo lugar, as dependências de um sistema não podem ser diretamente associadascom as tarefas do desenvolvedor. Assim, o estudo afirma que “as dependências entre os desenvolvedores de software, portanto, não são totalmente captadas na dependência estrutural de unidades do sistema” (YE et al., 2008). Isto sugere um desalinhamento entre as estruturas na Lei de Conway.

2.4. RECOMENDAÇÕES DA LEI DE CONWAY

Bailey et al. (2013)categoriza os estudos que tratam da Lei de Conway com base na alegação dos pesquisadores que prescrevem comportamentos da Lei de Conway dentro das organizações. Nesse contexto, eles classificam os estudos da seguinte forma:

 alinhamento entre organização e arquitetura;

 modularização;

 alocação geográfica de colaboradores;

 manutenção de comunicação eficaz;

 manutenção de flexibilidade

Naturalmente, existe um conjunto de conflitos entre o posicionamento dos pesquisadores nos estudos em termos de como essas recomendações devem ser seguidas, e até mesmo se elas devem ser seguidas (BAILEY et al., 2013). As

prática, que passaram a adotar, chamaram de “Skunk Works” (LOCKHEED MARTIN CORPORATION, 2013). Atualmente o termo skunkwork é utilizado na áreas de negócio e engenharia para descrever grupos autônomos dentro de uma organização, com alto grau de autonomia e sem interferência burocrática, que cuja tarefa é trabalhar em projetos avançados ou secretos (THE ECONOMIST, 2008).

subseções a seguir, detalham cada uma das prescrições enumeradas, conforme apresentadas na literatura.

2.4.1. ALINHAR ORGANIZAÇÃO E ARQUITETURA

Sobre Lei de Conway, o comportamento mais comumente prescrito trata de alinhar a estrutura organizacional e arquitetura(BASS, L. et al., 2007; BOSCH; BOSCH-SIJTSEMA, 2010; HADAYTULLAH et al., 2010; BIEDERMANN; LINDEMANN, 2011)(BURTON et al., 2011), a fim de facilitar o desenvolvimento de software. Os pesquisadores têm sido enfáticos nesse ponto. Le e Panchal(2012) afirmam que “Níveis elevados de congruência sociotécnicasão apresentados para influenciar positivamente a produtividade e a velocidade de desenvolvimento de produto”. Bass, M. et al. (2007) é ainda mais rígido ao afirmar: “O fracasso em atingir o alinhamento entre organização e arquitetura pode ter consequências graves para a evolução do software”. A gravidade do “desalinhamento” seria tão forte que, em alguns casos, pode levar “até a falência da empresa”(BASS, L. et al., 2007).

No entanto, existe discordância quanto à direcionalidade desse alinhamento. Vimos parte dessa discussão quando tratamos de direção de dependência (seção 2.2.3).

Vários pesquisadores defendem, especificamente, que a organização que deve determinar a arquitetura do produto. Coplien(2006)disse: “A arquitetura de software deve alinhar-se com a estrutura da organização que o constrói. Uma vez que a organização já existe, a arquitetura deve refletir a estrutura existente”.

Assim como Coplien(2006), Lings et al. (2006) defendem o planejamento da“arquitetura do sistema em torno da estrutura distribuída da equipe”. Similarmente,Dhungana et al. (2010) sugerem a estruturação da linha de produto com base na estrutura da equipe.

No entanto, alguns pesquisadores apoiam o ponto de vista oposto, de que a arquitetura deve determinar a estrutura da organização. Avritzer et al. (2010)chamam a atenção de que devíamos “alinhar a atribuição de tarefas com base na arquitetura do software.”Nordberg(2003) sugere projetar a arquitetura primeiro

para amarrá-la a organização, depois. Bosch e Bosch-Sijtsema(2010)afirma que “a importância de alinhar a organização com a arquitetura é conhecida há décadas.”

Ainda assim, existem pontos comuns. Nordberg (2003) e Coplien(1995) discutindo a importância do reconhecimento da Lei de Conway na determinação da estrutura de uma organização, recomendam que as organizações “congelem” a sua estrutura até que tenham determinado a melhor arquitetura para o produto, assim a organização vai harmonizar perfeitamente com essa estrutura. Entretanto, no caso de Nordberg (2003) a estrutura da organização deve mudar após a determinação da arquitetura e no caso de Coplien(1995), o “congelamento” deve garantir que a arquitetura seguirá a mesma estrutura da organização.

Alguns pesquisadores também levam em consideração a estrutura das empresas que irão utilizar o software, afirmando que não apenas a estrutura da empresa que desenvolve o sistema deve ser levada em conta, mas que arquitetura do software deve se voltar para as necessidades estruturais das organizações que irão utilizá-lo (COPLIEN, 2006).Coplien(2006)observou que “a arquitetura do sistema CAD deve seguir a estrutura da organização que irá utilizá-lo.” Da mesma forma,Benders et al.(2006) observaram que “uma questão fundamental no processo está no alinhamento de sistemas de ERP com as características da organização usuária.”

Os pesquisadores prescritivos também discutem outros alinhamentos que devem ocorrer além do fundamental, entre organização e arquitetura. Bruno(2011) propõe que “cada um Processo de Desenvolvimento devem aderir aos Processos de Negócio implícitos e explícitos da organização”. Como resultado de vários estudos de caso, Bosch e Bosch-Sijtsema(2010)reforça o alinhamento de arquitetura, processos e organização.

2.4.2. MODULARIZAÇÃO

Muitos pesquisadores sugerem como consequência da Lei de Conway a modularização do software (LINGS et al., 2006; BIRD, 2009; BECK; DIEHL, 2011; SOUZA, DE; REDMILES, 2011; CARLSON; XIAO, 2012), apontando as implicações dessa prática. “Uma solução ideal para o problema de organizaro esforço de

software de grande porte é decompor o sistema em módulos altamente coesos e fracamente acoplados”(BIRD et al., 2011). A modularização deve ser“pensada para reduzir a complexidade do desenvolvimento de software”(BOLICI et al., 2009) e encurtar o tempo de desenvolvimento (CARLSON; XIAO, 2012).

A modularização também garante o isolamento das equipes quanto às modificações feitas nas outras partes do sistema(BIRD et al., 2011). “Sem modularidade, existe pouca esperança de que os colaboradores entendam o suficiente sobre o design para contribuir com ele, ou desenvolver novos recursos e corrigir defeitos sem afetar outras partes do sistema”(MACCORMACK et al., 2012). De Souza e Redmiles(2011)descobriram, em suas pesquisas, que “arquiteturas modulares tornamredesmais gerenciáveis”. “Modularização é a abordagem normalmente utilizada para minimizar as dependências técnicas entre as partes de um sistema...”(CATALDO; HERBSLEB, 2008a). Existe um consenso geral de que cada módulo só deve ser atribuído a uma única equipe, mas as equipes podem receber vários módulos para desenvolver(HERBSLEB; MOCKUS, 2003b; CATALDO et al., 2008).

Subsistemas inter-relacionados “devem ser desenvolvidos por programadores que possuem comunicação fácil e frequente com os outros colaboradores" (HADAYTULLAH et al., 2010), porque “os desenvolvedores que lidam com componentes dependentes estão mais propensos a se comunicar do que os desenvolvedores de aplicações cujos componentes são independentes" (FONSECA et al., 2006). “A abordagem tradicional para reduzir a necessidade de comunicar e coordenar em organizações de desenvolvimento é a modularização ou o particionamento do sistema a ser desenvolvido em partes quase independentes”(CATALDO; HERBSLEB, 2008b)

Um exemplo do impacto da modularização é dado no estudo realizado pela Harvard Business School(MACCORMACK et al., 2012) que procurou identificar os efeitos da Lei de Conway nas diferentes estruturas arquitetônicas de sistemas open

source(código aberto) comparados a produtos comerciais. Maccormack et al.

(2012)partiram da hipótese de que os produtos comerciais apresentariam uma estrutura mais acoplada do que a dos sistemas open source, devido à estrutura mais integrada das organizações comerciais. Os resultados apoiam a Lei de Conway,