diff --git a/00-capa.tex b/00-capa.tex
 index 3315fe5..3da4a96 100644
 --- a/00-capa.tex
 +++ b/00-capa.tex
 @@ -1,17 +1,31 @@
 \autor{Antonio\author{Antonio Soares de Azevedo Terceiro}
 \titulo{Caraterização\title{Caracterização da Complexidade Estrutural em Sistemas de Software}
 \def\supervisorname{Orientadora}
 \orientador{Prof.Software Livre}
 
 \date{2012}
 
 % Orientador(a)
 % Opção: [f] - para orientador do sexo feminino
 \adviser[f]{Prof. Dra. Christina von Flach Garcia Chavez}
 
 \coorientador{Prof.% Orientador(a)
 % Opção: [f] - para orientador do sexo feminino
 \coadviser{Prof. Dr. Manoel Gomes de Mendonça Neto}
 
 \comentario{%
 Tese apresentada ao Programa Multiinstitucional% dados da ficha catalográfica
 \authorcitationname{Terceiro, Antonio Soares de Azevedo}
 \advisercitationname{Chavez, Christina von Flach Garcia}
 \coadvisercitationname{Mendonca, Manoel Gomes de}
 \catalogtype{Tese (doutorado)}
 \catalogtopics{%
 1. Complexidade Estrutural.
 2. Manutenção de Pós-GraduaçãoSoftware.
 3. Fatores Humanos em Ciência da Computação da Universidade Federal da Bahia, Universidade
 EstadualEngenharia de FeiraSoftware.
 4. Mineração de Santana e Universidade Salvador, como requisito
 parcial para obtenção do grauRepositórios de DoutorSoftware.
 5. Teorias em Ciência da Computação.Engenharia de Software.
 6. Engenharia de Software Experimental.
 7. Projetos de Software Livre.
 }
 \instituicao{Universidade Federal da Bahia}
 \local{Salvador}
 \data{2012}\catalogcdd{CDD 20.ed. 005.2}
 
 \capa
 \folhaderosto% capa
 \dmccfrontpage{PMCC-DSc-0006}
 diff --git a/00-resumos.tex b/00-resumos.tex
 index 39b4aef..0b633fa 100644
 --- a/00-resumos.tex
 +++ b/00-resumos.tex
 @@ -2,8 +2,8 @@
 % <resumo>
 % Objetivos
 %%%%%%%%%%%
 Esta tese propõeapresenta uma teoria para caracterizar acaracterização da complexidade estrutural em
 sistemas de software. Esta teoria buscasoftware livre, com objetivo de identificar (i) a
 contribuição de diversos fatores para a variação da complexidade
 estrutural e (ii) os efeitos da complexidade estrutural sobre projetos
 de software.
 @@ -21,20 +21,21 @@ de software.
 
 % Metodologia
 %%%%%%%%%%%%%
 Para testar a validadeas possíveis causas da teoria proposta,complexidade estrutural, foram
 realizados quatro estudos experimentais, utilizando mineração de dados
 em repositórios de projetos de software livre. Foram analisados dados
 históricos de mudanças realizadas em 13 sistemas de diferentes domínios
 de aplicação e escritos em diferentes linguagens de programação. Os
 resultados dos estudos realizados são sintetizados através de uma teoria
 que descreve causas e consequências da complexidade estrutural.
 
 % Resultados
 %%%%%%%%%%%%
 Os resultadosdestes estudos indicaram que todos os fatores estudados influenciaramsignificativamente a
 variação da complexidade estrutural em pelo menos um dos projetos, mas
 projetos diferentes foram influenciados por conjuntos diferentes de
 fatores. Modelos construídos foram capazes de descrever até 93\% da
 variação na complexidade estrutural nos projetos estudados.
 % </resumo>
 
 \textbf{Palavras chave:}
 @@ -50,10 +51,10 @@ Projetos de Software Livre.
 
 \begin{abstract}
 
 This thesis proposespresents a theory to characterizecharacterization of structural complexity in free
 software systems. This theory aimssystems to identify (i) the contribution of several factors to
 the structural complexity variation and (ii) the effects of structural
 complexity in software projects.
 %
 Possible factors in the structural complexity variation include: human
 factors, such as general experience of the developers and their
 @@ -66,17 +67,18 @@ project.
 Effects of structural complexity include higher effort, and consequently
 higher cost, in software comprehension and maintenance activities.
 
 To test the validitypossible causes of the proposed theory,structural complexity, four empirical studies
 were performed, mining data from free software project repositories. We
 analyzed historical data from changes performed in 13 systems from
 different application domains and written in different programming
 languages. The results of these studies were summarized by means of a
 theory that describes causes and consequences of structural complexity.
 
 The resultsof these studies indicated that all the factors studied influenced the
 structural complexity variationsignificantly in at least one of the projects, but
 different projects were influenced by different sets of factors. The
 models obtained were capable of describing up to 93\% of the structural
 complexity variation in the projects analyzed.
 
 \textbf{Keywords:}
 Structural Complexity,
 diff --git a/00-termo-de-aprovacao.tex b/00-termo-de-aprovacao.tex
 new file mode 100644
 index 0000000..16d8fd1
 --- /dev/null
 +++ b/00-termo-de-aprovacao.tex
 @@ -0,0 +1,7 @@
 \approvalsheet{Salvador, 23 de Março de 2012}{
   \comittemember{Profa. Dra. Christina von Flach Garcia Chavez}{Universidade Federal da Bahia}
   \comittemember{Prof. Dr. Dalton Dario Serey Guerrero}{Universidade Federal de Campina Grande}
   \comittemember{Prof. Dr. Guilherme Horta Travassos}{Universidade Federal de Rio de Janeiro}
   \comittemember{Prof. Dr. Claudio Nogueira Sant'Anna}{Universidade Federal da Bahia}
   \comittemember{Prof. Dr. Eduardo Santana de Almeida}{Universidade Federal da Bahia}
 }
 diff --git a/01-introducao.tex b/01-introducao.tex
 index 7ddfdfe..62d47f3 100644
 --- a/01-introducao.tex
 +++ b/01-introducao.tex
 @@ -1,19 +1,21 @@
 \chapter{Introdução}\xchapter{Introdução}{Este capítulo descreve a motivação do trabalho,
 seus objetivos, a metodologia adotada e os resultados obtidos.}
 
 %%fakesection Preambulo
 Manutenção e evolução de software são atividades que consomem uma grande
 parte dos custos associados ao ciclo de vida de um sistema de software
 \cite{bennett2000} e, consequentemente,\cite{bennett2000}. Consequentemente, a compreensão, avaliação e controle
 de fatores que as influenciam são de fundamental importância.
 
 A complexidade dos sistemas de software
 \cite{mccabe1976,darcy2005,sangwan2008} é um destes fatores.fator que possivelmente
 influencia as atividades de menutenção e evolução. Quanto maior a
 complexidade de um sistema de software, maior é o esforço para
 compreendê-lo, modificá-lo e evoluí-lo \cite{darcy2005,midha2008}.
 %
 Em especial, a \emph{complexidade estrutural}, uma medida de
 complexidade definida em termos de acoplamento e coesão,coesão \cite{darcy2005}, é
 um indicativo de problemas na manutenibilidade de sistemas de software
 \cite{darcy2005, meirelles2010}.
 
 Darcy e colegas realizaram um experimento controlado com desenvolvedores
 @@ -28,23 +30,18 @@ Como para uma boa parte dos sistemas de software a necessidade de
 mudança é inevitável \cite{lehman1985, lehman1997}, minimizar o esforço
 necessário para atividades de manutenção é algo desejável.
 
 No caso específico de projetos de software livre, níveis mais altos de
 complexidade estrutural podem causar uma diminuição na capacidade do
 projeto de absorver ou atrair novos desenvolvedores
 \cite{meirelles2010}. Esta capacidade de atrair novos desenvolvedores é
 uma condição necessária para o sucesso de um projeto de software livre
 \cite{santosjr2009}.
 
 Existe ainda evidência anedótica sobre osOs efeitos do excesso de complexidade em projetos de software.software podem ser
 verificados em episódios de conhecimento público. \texttt{gnome-session}
 e \texttt{eog} são dois projetos de software livre, componentes do
 GNOME\footnote{\url{http://gnome.org/}}, um sistema de área de trabalho
 para computadores e dispositivos embarcados. Num determinado ponto da
 evolução destes sistemas, seus mantenedores resolveram reescrevê-los
 completamente. Em conversas pessoais com um desenvolvedor envolvido nos
 processos de reescrita dos dois sistemas, foi relatado que um dos
 motivos que levaram à decisão de reimplementá-los a partir do zero foi o
 fato do seu código fonte ter se tornado ``complexo demais''.demais'': consertar
 defeitos passou a demandar cada vez mais esforço, e adicionar novas
 funcionalidades ainda mais.
 
 O esforço de reescrita de sistemas inteiros é algo que idealmente
 se quer evitar, de forma que os desenvolvedores possam dedicar o seu
 @@ -77,13 +74,12 @@ Assim, este trabalho tem os seguintes objetivos específicos:
     Identificar os fatores que influenciam a complexidade estrutural em
     sistemas de software.
   \item
     Formular uma teoria que identifique a contribuição dos fatores
     identificados à variação da complexidade estrutural em sistemas de
     software, bem comoIdentificar os efeitos da complexidade estrutural sobre o esforço
     necessário para atividades de manutenção em projetos de software.
   \item
     Testar a validade das proposiçõesinfluência de um subconjunto dos fatores identificados como
     possíveis causas da teoria propostacomplexidade estrutural através de estudos
     experimentais.
 \end{enumerate}
 
 O conhecimento sobre quais fatores influenciam a complexidade estrutural
 @@ -92,40 +88,47 @@ controlar o crescimento da complexidade, ou buscar a sua redução. Isto
 pode contribuir para uma maior capacidade de compreensão e mudança no
 sistema, reduzindo o esforço de manutenção e consequentemente os custos.
 
 ACom base em um \emph{brainstorm} inicial,  identificou-se que a
 complexidade estrutural de um projeto de software pode aumentar em
 função de diferentes fatores, como o nível de maturidade do projeto, o
 aumento no tamanho do seu código fonte, o tipo de manutenção ao qual o
 projeto é submetido, práticas de desenvolvimento, decisões de projeto
 tomadas no início do projeto, e mesmo características dos
 desenvolvedores que trabalham no projeto.
 
 Neste trabalho,Com o objetivo de estudar fatores relacionados conjuntamente, estes
 fatores estãoforam classificados em três grupos: fatores relacionados à
 organização desenvolvedora, fatores relacionados à manutenção a qual o
 sistema é submetido, e fatores relacionados aos desenvolvedores
 envolvidos no projeto. FoiEm função no limite de tempo para o
 desenvolvimento do trabalho e do escopo definido -- projetos de
 software livre, foi dada ênfase aos fatores relacionados à
 manutenção e aos fatores relacionados aos desenvolvedores.desenvolvedores; os fatores
 relacionados à organização não foram abordados.  A figura
 \ref{fig:escopo} ilustra o escopo do presente trabalho.
 
 \begin{figure}[hbt]
   \begin{center}
     \includegraphics{figuras/escopo}\includegraphics[width=0.9\textwidth]{figuras/escopo}
   \end{center}
   \caption{Grupos de fatores que podem influenciar a complexidade
   estrutural. Os grupos de fatores abordados diretamente neste trabalho
   estão destacados}destacados em cinza.}
   \label{fig:escopo}
 \end{figure}
 
 \section{Metodologia de Trabalho}
 \label{sec:intro:metodologia}
 
 Nesta tese, foi definida uma teoria que relacionainvestigada a influência de diversos fatores àsobre a
 variação da complexidade estrutural, e abem como os efeitos da complexidade
 estrutural aos
 seus efeitos.sobre a atividade de manutenção de software.
 
 Os fatores identificados comcomo potenciais influenciadores da complexidade
 estrutural foram classificados nos seguintes grupos:em três diferentes grupos. Estes grupos
 reuniram fatores conceitualmente relacionados, de forma que os fatores
 pertencentes a a cada grupo pudessem ser avaliados em conjunto. Esta
 classificação foi a seguinte:
 
 \begin{enumerate}
   \item
 @@ -139,7 +142,7 @@ estrutural foram classificados nos seguintes grupos:
     \label{item:fatores:manutencao}
     Fatores relacionados à manutenção realizada sobre o sistema:
     %
     variação de tamanho,tamanho do sistema,
     difusão de mudança,
     tipo de mudança.
   \item
 @@ -164,8 +167,7 @@ seguinte procedimento foi realizado:
   \item Obtenção do código fonte correspondente ao estado atual do
     sistema exatamente após aquela mudança.
   \item
     Extração de métricas do código fonte, incluindo a complexidade
     estrutural.fonte.
   \item
     Cálculo dos valores das variáveis correspondentes aos fatores
     estudados.
 @@ -177,9 +179,9 @@ seguinte procedimento foi realizado:
 \end{itemize}
 
 O primeiro estudo realizado foi um estudo exploratório no qual
 desejava-se validar aexperimentar esta abordagem de análise da evolução da
 complexidade estrutural através da mineração de dados semiautomática em
 repositórios de projetos de software livre.
 %
 Para isso, foram analisadas 21 versões, abrangendo 15 meses de
 desenvolvimento, de um projeto de pequeno porte escrito em C.
 @@ -188,18 +190,32 @@ O segundo estudo investigou a influência do nível de participação de
 desenvolvedores em projetos de software livre na complexidade estrutural
 adicionada ou removida por eles.
 %
 O nível de participação de um desenvolvedor em um projeto de software
 livre indica a posição social de um desenvolvedor naquele
 projeto\cite{mockus2002, crowston2005}: desenvolvedores centrais
 realizam a maior parte das atividades e possuem maior poder de decisão,
 enquanto os desenvolvedores periféricos realizam uma menor parte das
 atividades e possuem menor poder de decisão.
 %
 Foram analisados 7 projetos de servidores web escritos em C, que
 totalizavam mais de 13.000 mudanças em seus repositórios.
 %
 O desenvolvedor responsável por cada mudança foi classificado
 comcomo central ou periférico no momento da realização da mudança, e
 comparou-se a variação na complexidade causada por desenvolvedores
 centrais e periféricos.
 
 O terceiro estudo investigou três fatores de uma vez: experiência dos
 desenvolvedores, variação de tamanho e difusão da mudança.
 %
 Neste trabalho, a experiência dos desenvolvedores é um indicador da
 quantidade de atividades realizadas anteriormente pelo desenvolvedor no
 projeto \cite{mockus2000}; a variação de tamanho indica o número de
 linhas de código adicionadas ou removidas por cada mudança, e a difusão
 da mudança indica o número de arquivos adicionados ou modificados por
 cada mudança \cite{mockus2002}.
 %
 Foram analizadosanalisados 5 projetos escritos em C, C++ e Java, cada um com pelo
 menos 18 meses de desenvolvimento, que totalizaram mais de 5.000 mudanças.
 %
 Foram construídos modelos de regressão linear, onde a variação na
 @@ -207,8 +223,9 @@ complexidade estrutural foi modelada como uma função dos fatores
 estudados.
 %
 Mudanças que aumentavam a complexidade estrutural foram analisadas
 separadamente de mudanças que reduziam a complexidade estrutural, poispor
 considerarmos que representam atividades de manutenção de naturezas
 distintas.
 
 O quarto estudo experimental teve o objetivo de refinar os modelos de
 regressão linear obtidos anteriormente.
 @@ -216,11 +233,18 @@ regressão linear obtidos anteriormente.
 Para isso, foram analisados os mesmos projetos utilizados no estudo
 anterior.
 %
 Os modelos foram refinados através ada introdução do grau de autoria do
 desenvolvedor sobre os módulos alterados e da separação da difusão de
 mudança em número de módulos alterados e número de módulos adicionados.
 %
 O grau de autoria mensura a interação de um desenvolvedor com um
 determinado artefato de software \cite{fritz2010}.
 
 Para sintetizar os resultados dos estudos, foi formulada uma teoria que
 identifica causas da complexidade estrutural e suas consequências sobre
 o processo de manutenção de sistemas de software livre.
 
 Durante o desenvolvimentoPara apoiar a realização dos estudos, foi desenvolvida uma ferramenta
 chamada Analizo. A Analizo é capaz de analisar código fonte escrito em
 C, C++ e Java, calcula um conjunto de mais de 20 métricas de software, e
 suporta analisar cada revisão armazenada em um repositório de controle
 @@ -234,21 +258,15 @@ Os principais resultados deste trabalho incluem:
 
 \begin{itemize}
   \item
     Uma proposta de teoria para a complexidade estrutural em projetos de
     software. Apesar da teoria proposta ainda ter pouca evidência
     experimental e baixa generalidade, ela é de alta utilidade para
     projetos de software. Além disso, ela pode ser refinada mediante a
     realização de estudos que forneçam mais evidências experimentais.
   \item
     Obtenção de resultados experimentais acerca da influência de fatores
     humanos e características da manutenção realizada sobre a variação
     da complexidade estrutural em sistemas de software,software livre, e
     consequentemente, sobre a manutenibilidade destes sistemas.
     Em especial,
     \begin{itemize}
       \item
         O estudo da evolução da complexidade estrutural do sistema pode
         ser utilizado para identificar momentos ondeem que a arquitetura do
         sistema é alterada de forma substancial.
       \item
         Todos os fatores estudados influenciaram a variação na
 @@ -263,26 +281,29 @@ Os principais resultados deste trabalho incluem:
         diferentes de fatores.
       \item
         Os modelos obtidos são capazes de explicar até 93\% da variação
         na complexidade estrutural.estrutural como uma função de um subconjunto dos
         fatores estudados, no contexto dos sistemas estudados.
     \end{itemize}
   \item
     Uma proposta de teoria para a complexidade estrutural em projetos de
     software livre. Apesar da teoria proposta ainda ter pouca evidência
     experimental e baixa generalidade, a avaliação realizada indica que
     de ela é de alta utilidade para projetos de software. Além disso,
     esta teoria pode ser refinada mediante a realização de estudos que
     forneçam mais evidências experimentais.
   \item
     A construção de uma ferramenta para análise de código fonte que pode
     ser usada para estudos experimentais em larga escala que envolvam
     análise de código fonte em diferentes linguagens de programação.
 \end{itemize}
 
 O restante da tese detalha o desenvolvimento do trabalho e seus
 resultados.
 
 \section{Organização do texto}
 \label{sec:intro:organizacao}
 
 O restante deste texto está organizado confirme descrito a seguir.
 
 O capítulo \ref{cap:software-livre} apresenta conceitos fundamentais
 sobre projetos de software livre, sua forma de funcionamento, suas
 diferenças e semelhanças em relação a projetos de software ditos
 ``convencionais''.proprietário
 (ditos ``convencionais'').
 
 No capítulo \ref{cap:complexidade-estrutural}, é feita uma revisão da
 literatura sobre complexidade em sistemas de software, e descrita a
 @@ -293,22 +314,14 @@ Os fatores estudados como possíveis causas da variação da complexidade
 estrutural em projetos de software são descritos no capítulo
 \ref{cap:fatores}.
 
 O capítulo \ref{cap:teoria} apresenta uma teoria para a complexidade
 estrutural em sistemas de software. São relacionados construtos e
 proposições desta teoria, representando principalmente causas e
 consequências da complexidade estrutural.
 
 Os estudos experimentais desenvolvidos para avaliar os diversos fatores
 como causas da variação da complexidade estrutural em sistemas de
 software são apresentados e discutidos no capítulo
 \ref{cap:estudos-experimentais}.
 
 O capítulo \ref{cap:discussao}\ref{cap:teoria} apresenta umadiscussão dos resultados
 deste trabalho, em duas partes: primeiro, é feita uma avaliação da teoria propostapara a complexidade
 estrutural em função da literatura existentesistemas de software livre, indicando principalmente
 causas e dos resultados
 obtidos com os estudos experimentais componentes deste trabalho;
 segundo, é feita uma avaliação dos resultados relativos à influência dos
 diversos fatores sobre aconsequências da complexidade estrutural.
 
 O capítulo \ref{cap:conclusao} elenca as contribuições e limitações
 deste trabalho, e relaciona possíveis trabalhos futuros.
 diff --git a/02-software-livre.tex b/02-software-livre.tex
 index d9a59fb..26ddfe9 100644
 --- a/02-software-livre.tex
 +++ b/02-software-livre.tex
 @@ -1,4 +1,9 @@
 \chapter{Projetos\xchapter{Projetos de Software Livre}Livre}{
   Este capítulo discute projetos de software livre. São discutidas
   definições e as principais caracterítiscas destes projetos, e em
   seguida faz-se uma discussão da utilização de projetos de software
   livre como objeto de estudo em Engenharia de Software.
 }
 \chaptermark{Software Livre}
 \label{cap:software-livre}
 
 @@ -12,19 +17,20 @@ Assim, neste capítulo, apresentamos uma breve caracterização de projetos
 de software livre (seção \ref{sec:software-livre:definicao}), bem como
 uma discussão sobre o uso de projetos de software livre como objeto de
 estudo na pesquisa em Engenharia de Software (seção
 \ref{sec:software-livre:objeto-de-estudo}). A seção
 \ref{sec:software-livre:conclusao} conclui o capítulo, ressaltando os
 principais conceitos apresentados.
 
 \section{Definição e características}
 \label{sec:software-livre:definicao}
 
 Software livre representa uma classe de sistemas de software
 distribuídos sob licenças cujos termosque permitem aos seus usuários usar,
 estudar e modificar o software. Para isso, necessariamente o
 código-fonte deve estar disponível. Em contraste com o conceito de
 software livre, softwareSoftware não considerado como
 software livre é conhecido como software proprietário.
 
 Do ponto de vista da Engenharia de Software, oum aspectomais importante
 do software livre é o seu processo de desenvolvimento. Um projeto de
 software livre começa quando um desenvolvedor individual ou uma
 organização decide tornar um produto de software disponível ao público
 @@ -49,11 +55,12 @@ os usuários finais terão então acesso às novas funcionalidades ou
 reparos que foram contribuídos de volta para o projeto.
 
 Com o passar do tempo, cada nova versão do produto possui mais
 funcionalidades e é mais portável do que a versão anterior, devido às
 contribuições de desenvolvedores externos. Os colaboradores mais
 frequentes normalmente ganharãopodem ganhar a confiança dos fundadores do
 projeto,projeto e receberãoreceberem acesso direto de escrita ao código fonte oficial do
 projeto, passando assim a poderem fazer mudanças diretamente na versão
 oficial.
 
 O processo pelo qual desenvolvedores se juntam a projetos de software
 livre e ganham responsabilidades -- e reconhecimento -- varia conforme o
 @@ -61,7 +68,7 @@ projeto.
 %
 Projetos pequenos normalmente possuem procedimentos bastante
 informais para isso. Por exemplo, um dos desenvolvedores atuais pode
 simplesmente oferecer umuma conta de acesso ao repositório de controle de
 versão para o novo desenvolvedor.
 %
 Projetos maiores, por outro lado, podem ter processos mais
 @@ -89,7 +96,7 @@ contribuições sejam adicionadas ao repositório.
   \label{fig:repository-interaction}
 \end{figure}
 
 Em geral, projetos de software livre usam um ambiente bastante parecidoambientes bastantes parecidos
 para colaboração entre os seus desenvolvedores: além do sistema de
 controle de versão, normalmente são utilizados um sistema de gestão de
 atividades para receber relatos de defeitos dos usuários e organizar as
 @@ -106,7 +113,7 @@ projetos de software ditos ``convencionais'':
   \item
     \textbf{Disponibilidade do código fonte.} O código fonte de projetos de
     software livre está sempre disponível na internet, e a maioria dos
     projetos possuempossui um repositório de controle de versão público.
   \item
     \textbf{Simbiose desenvolvedor/usuário.} Em boa parte dos projetos de
     software livre, os desenvolvedores são também usuários do software, e
 @@ -137,13 +144,14 @@ projetos de software ditos ``convencionais'':
 \end{itemize}
 
 Apesar da literatura de Engenharia de Software nos últimos anos ter
 tratado o software livre como um fenômeno homogêneo
 \cite{osterlie2007b}, as características acimaapresentadas anteriormente não
 se aplicam a todos os projetos de software livre, e algumas delas se
 manifestam de formas bastante diferentes, de projeto para projeto.
 
 \sectionmark{Software Livre em Engenharia de Software}
 \section{Projetos de Software Livre como objeto de estudo em
 Engenharia de Software}
 \label{sec:software-livre:objeto-de-estudo}
 
 Dados de projetos privados de desenvolvimento de software são
 @@ -163,16 +171,17 @@ publicamente na internet. Através desses repositórios de informação,
 pesquisadores podem monitorar e analisar o trabalho da equipe de
 desenvolvimento sobre um determinado artefato. Este tipo de dado tem
 sido largamente utilizado em estudos de Engenharia de Software com a
 assistência desde ferramentas que automatizam a extração e análise de dados
 de repositórios públicos acessíveis pela \emph{web} \cite{kon2011}.
 
 Projetos de software livre têm produzido com sucesso sistemas de
 software sofisticados, usando metodologias e processos por vezes
 substancialmente diferentes dosdaqueles documentados nos livros textos
 clássicos de Engenharia de Software \cite{pressman2009,sommerville2010}.
 Entender como o software livre funciona e quais aas suas diferenças e
 similaridades com o desenvolvimento de software ``convencional'' pode
 ajudar pesquisadores e praticantesprofissionais da prática a melhorar a prática deda
 Engenharia de Software em geral.
 
 A pesquisa sobre software livre trouxe uma série de novos tópicos
 interessantes à agenda de pesquisa em Engenharia de Software, como
 @@ -188,7 +197,7 @@ e atratividade de projetos de software livre
 Pesquisa sobre software livre não se limita às subáreas existentes da
 Engenharia de Software: o estudo sobre o fenômeno do software livre em
 si é também uma área de pesquisa promissora para as ciências sociais em
 geral, administração, economia,economia e filosofia. A principal conferência
 internacional sobre pesquisa em software livre, a \emph{International
 Conference on Open Source Systems}, é um evento multidisciplinar que
 reúne anualmente pesquisadores de diversas áreas do conhecimento.
 @@ -196,12 +205,12 @@ reúne anualmente pesquisadores de diversas áreas do conhecimento.
 Vale ressaltar, no entanto, que o estudo de projetos de software livre
 possui algumas limitações.
 %
 Primeiro, a disponibilidade imediata de informações sobre o processo de
 desenvolvimento não traz consigo acesso direto às pessoas envolvidas no
 processo, o que não facilita a realização de estudos qualitativos que
 necessitem de dados não registrados eletronicamente.  Os pesquisadores
 precisam, assim como no caso de projetos privados, entrar em contato com
 os participantes do projeto e solicitar as informações necessárias.
 
 Segundo, não se tem controle sobre os participantes do projeto, o que
 torna infactível a realização de estudos controlados. Os estudos que
 @@ -221,6 +230,34 @@ diferentes de projetos de software proprietário do que projetos de
 software proprietário distintos são diferentes entre si
 \cite{wilson2011}.
 
 Apesar das limitações discutidas, projetos de software livre têm servido
 à comunidade de pesquisa em Engenharia de Software como objeto de estudo
 de forma crescente nos últimos anos \cite{kon2011}.
 
 \section{Conclusão}
 \label{sec:software-livre:conclusao}
 
 Um projeto de software livre é caracterizado por termos de uso que
 permitem aos seus usuários usar, modificar e redistribuir o software;
 consequentemente, seu código fonte é disponibilizado para todos os seus
 usuários. A disponibilidade do código fonte viabiliza a colaboração de
 diferentes desenvolvedores através da internet de forma a adaptar o
 software às suas diversas necessidades.
 
 Uma vez que uma grande parte das atividades de colaboração que compõem o
 desenvolvimento de um projeto de software livre é registrada
 eletronicamente e de forma pública, estes projetos representam uma
 oportunidade sem precedentes para pesquisadores da Engenharia de
 Software. Apesar disso, é necessário reconhecer as limitações na
 utilização de projetos de software livre em pesquisas de Engenharia de
 Software.  Por exemplo, a grande heterogeneidade entre projetos de
 software livre faz com que não haja um projeto de software livre
 arquetípico, e com que projetos de software livre não possam ser
 considerados como representativos do caso geral de projetos de
 desenvolvimento de software. O mesmo acontece com projetos de software
 proprietário, no entanto.
 
 Neste trabalho, projetos de software livre foram analisados com o
 objetivo de caracterizar a influência de um conjunto de fatores sobre a
 variação da sua complexidade estrutural. O capítulo seguinte apresenta
 os principais conceitos sobre complexidade estrutural.
 diff --git a/03-complexidade-estrutural.tex b/03-complexidade-estrutural.tex
 index 834d7fd..85b2e31 100644
 --- a/03-complexidade-estrutural.tex
 +++ b/03-complexidade-estrutural.tex
 @@ -1,4 +1,14 @@
 \chapter{Complexidade Estrutural}\xchapter{Complexidade Estrutural}{
   Este capítulo descreve o conceito de complexidade em geral, fazendo um
   breve apanhado do campo de sistemas complexos. Em seguida, o conceito
   de complexidade em sistemas de software é discutido e diferentes
   propostas de medidas para complexidade de sistemas de software são
   apresentadas, entre elas a medida conhecida como complexidade
   estrutural, utilizada no restante deste trabalho. O capítulo é
   concluído com uma discussão sobre os efeitos da complexidade
   estrutural em sistemas de software e sobre o comportamento
   evolucionário da complexidade estrutural.
 }
 \label{cap:complexidade-estrutural}
 
 %%fakesection Preambulo
 @@ -7,24 +17,27 @@ fundamental neste trabalho.
 
 A seção~\ref{sec:complexidade} introduz de forma geral o conceito de
 complexidade de acordo com o campo de estudo de sistemas complexos, bem
 bemcomo características comuns de sistemas que são ditos ``sistemas
 complexos'', e uma caracterização de sistemas de software como sistemas
 complexos.
 %
 A seção~\ref{sec:complexidade:software} discute especificamente a
 complexidade em sistemas de software em termos de conceitos da
 Engenharia de Software como módulos, abstração, e arquitetura de
 software.
 %
 Em seguida, a seção~\ref{sec:complexidade:medidas} discute três
 abordagens diferentes para a medição de complexidade de software, que
 fornece subsídios para a escolha de uma abordagem de medição a ser
 utilizada neste trabalho.
 Por fim, a%
 A seção~\ref{sec:complexidade:efeitos} discute os efeitos da
 complexidade estrutural sobre projetos de software, e a
 seção~\ref{sec:complexidade:evolucao} discute a evolução histórica da
 complexidade estrutural em projetos de software.
 %
 Este capítulo é concluído pela seção \ref{sec:complexidade:conclusao},
 onde são discutidos os principais resultados identificados.
 
 \section{Sistemas Complexos}
 \label{sec:complexidade}
 @@ -46,7 +59,7 @@ mais curto para uma fonte de alimento.
 Outros exemplos de sistemas considerados complexos incluem os sistemas
 nervoso e imunológico, sistemas econômicos, ou sistemas de software,
 como a \emph{World Wide Web} \cite{mitchell2009}.
 %
 Algo que se pode notar nesta lista é a existência de dois tipos de sistemas
 complexos: sistemas naturais e sistemas artificiais.
 
 @@ -56,7 +69,7 @@ mesmo que ``natural'': uma floresta é natural, mas uma fazenda não é
 \cite{simon1996}. As ciências naturais buscam compreender os sistemas
 naturais e suas propriedades.
 
 Já sistemasSistemas artificiais são projetados por humanos, com \emph{objetivos}
 e \emph{funções} definidos. Sistemas artificiais podem ou não serem
 projetados à imagem de um sistema natural, e durante a sua concepção
 eles são discutidos em termos tanto de suas \emph{características} (o
 @@ -128,17 +141,51 @@ naturais pelo fato de serem projetados; consequentemente, o seu processo
 evolucionário não é intrinsecamente parte do seu comportamento, mas
 fruto da ação consciente de seus desenvolvedores.
 
 É importante ressaltar que esta caracterização de sistemas de software
 como sistemas complexos diz respeito à estrutura interna dos sistemas,
 ou seja, aos componentes que o constituem e ao relacionamento entre
 estes componentes. Não foram considerados outros aspectos importantes de
 sistemas complexos, como por exemplo o seu relacionamento com o
 ambiente externo.
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \section{Complexidade em Sistemas de Software}
 \label{sec:complexidade:software}
 
 Para viabilizarA complexidade de um sistema de software está relacionada a compreensãofatores que
 afetam o custo associado a desenvolvê-lo e mantê-lo \cite{tegarden1995}.
 Segundo Tegarden \emph{et al}, três tipos de complexidade afetam a
 capacidade que desenvolvedores possuem de compreender sistemas de
 softwaresoftware: a complexidade do problema, a complexidade procedural, e a
 complexidade do projeto do sistema. Esta última é o foco deste trabalho.
 
 A \emph{complexidade do problema} está relacionada ao domínio do
 problema. De forma simplória, assume-se que problemas mais complexos são
 mais difíceis de compreender do que problemas mais simples. Normalmente,
 não sejam
 triviais, é necessário dividi-lospossuímos qualquer tipo de controle sobre este tipo de complexidade,
 o que faz com que o seus efeitos sobre a capacidade de compreensão de
 desenvolvedores seja inevitável.
 
 A \emph{complexidade procedural} está relacionada à estrutura lógica
 da programa, em especial do seu comprimento, em termos de número de
 \emph{tokens}, linhas de código fonte, ou estruturas de controle.
 
 A \emph{complexidade do projeto do sistema} está relacionada ao
 mapeamento entre o domínio do problema e o domínio da solução, na forma
 de um sistema de software. Tegarden \emph{et al} diferenciam o que eles
 chamaram de \emph{complexidade estrutural}, associada ao acoplamento
 entre módulos, e \emph{complexidade de dados}, associada à coesão
 interna dos módulos. Esta tese trata deste tipo de complexidade, a qual
 chamamos como um todo de \emph{complexidade estrutural}.
 %
 A complexidade estrutural, portanto, está relacionada ao projeto do
 sistema, ou seja, à sua divisão em \emph{módulos}.
 
 \emph{Módulos} são unidades de um sistemagrande que são estruturalmente
 independentespossuem uma independência
 relativa entre si, mas que trabalham em conjunto.conjunto para produzir o
 comportamento resultante do sistema \cite{parnas1972}.  O sistema como
 um todo deve prover uma arquitetura que dá suporte tanto à independência
 de estrutura como à integração de função \cite[p. 63]{baldwin1999}.
 
 A \emph{arquitetura} de um software é a estrutura que determina quais
 tipos de módulos existem, quais propriedades cada um desses módulos são
 @@ -147,19 +194,19 @@ externamente visíveis, e como os módulos se relacionam entre si
 
 O ato ou efeito de se projetar um sistema como um conjunto de módulos é
 chamado de \emph{modularização}. A modularização pode ser considerada
 comcomo uma das fases da definição da arquitetura do sistema. Segundo
 Baldwin e Clark \cite{baldwin1999}, a modularização deve seguir dois
 princípios básicos, o da \emph{ocultação de informação} e o da
 \emph{abstração}.
 
 \emph{Ocultação de informação} consiste em esconder detalhes de um
 módulo dos demais, de forma que estes detalhes possam ser alterados sem
 que os demais módulos também precisem ser alterados \cite{parnas1972}.
 Parnas propõe que módulos encapsulem decisões que estejam propensas a
 mudar, de forma queestas mudanças relacionada a estas decisões não afetem as
 demais partes do sistema.  Desta forma, módulos são projetados para
 expor uma interfacepara outros módulos que fornece acesso à sua funcionalidade,funcionalidade a outros
 módulos, mas sem expor os detalhes da sua implementação.
 
 A \emph{abstração} consiste em fazer com que módulos apenas interajam
 com a interface dos outros módulos. Desde que sua interface seja
 @@ -172,24 +219,28 @@ paralelo, e isolar a incerteza confinando-a dentro de módulos \cite[p.
 90-91]{baldwin1999}.
 
 Mesmo dividido em módulos, um sistema de software ainda possui uma
 complexidade com a qual seus desenvolvedores precisam lidar. Além da
 complexidade do problema, que é natural, o projeto do sistema como um
 conjunto de módulos inter-relacionados possui uma complexidade
 característica que afeta a capacidade de desenvolvedores de compreender
 e realizar manutenção sobre o sistema. Esta complexidade está
 relacionada ao relacionamento entre os diferentes módulos do sistema,
 bem como à estrutura de cada módulo individual.
 
 \section{Medidas de Complexidade em Sistemas de Software}
 \label{sec:complexidade:medidas}
 
 No campo de sistemas complexos, existem diversas propostas de medidas de
 complexidade que capturam diferentes aspectos de suada complexidade de um
 sistema \cite{mitchell2009}.
 %
 Da mesma forma, na área de Engenharia de Software, existem diferentes
 propostas de medidas de complexidade de software \cite{mccabe1976,
 sangwan2008, darcy2005} que capturam diferentes aspectos da complexidade
 de sua
 complexidade.um sistema de software.
 
 Esta seção descreve três abordagens para medição de complexidade de
 sistemas de software e apresenta uma caracterização das mesmassoftware. Estas abordagem são caracterizadas em termos
 dos seguintes critérios:
 
 \begin{description}
 @@ -197,13 +248,26 @@ dos seguintes critérios:
     A medida leva em consideração tanto a complexidade interna de
     cada módulo como a complexidade inerente ao relacionamentos entre os
     diferentes módulos do sistema?
 
     Este critério visa garantir que a abordagem captura aspectos
     importantes da complexidade estrutural de um sistema
     \cite{tegarden1995}.
   \item[C2]
     A medida representa uma dimensão distinta do que se pode obter
     medindo o tamanho do sistema?
 
     Este critério visa garantir que a abordagem escolhida seja
     justificável em termos de esforço: uma vez que medir o tamanho do
     sistema usualmente requer menos esforço do que medir propriedades da
     sua estrutura, procura-se abordagens que meçam propriedades
     significantemente não relacionadas ao tamanho.
   \item[C3]
     A medida pode ser usada de forma independente da
     linguagemdo paradigma de
     programação e da estrutura escolhida pelos desenvolvedores para
     organizar os módulos do sistema?
 
     Este critério visa privilegiar as abordagens que possam ser
     aplicadas no maior número possível de contextos diferentes.
 \end{description}
 
 Os critérios representam questões de interesse para este trabalho e, de
 @@ -220,7 +284,7 @@ complexidade de sistemas de software no nível de subrotinas
 %
 Destas, a que se tornou mais amplamente usada foi a complexidade
 ciclomática de McCabe \cite{mccabe1976}, que ainda é utilizada em
 trabalhos recentes \cite{barry2007,midha2008,zhang2007}.\cite{barry2007,zhang2007,midha2008}.
 
 A complexidade ciclomática de McCabe é uma medida da complexidade de uma
 sub-rotina, e calcula o número de possíveis traços de execução de uma
 @@ -261,15 +325,16 @@ software.
 
 Outro problema com a complexidade ciclomática é o fato dela estar
 fortemente correlacionada a medidas de tamanho \cite{vandermeulen2007,
 jay2009, herraiz2011}. Uma vez que medidas de tamanho são usualmente
 mais simples de calcular, utilizar complexidade ciclomática para medir
 complexidade de sistemas de software é pouco justificável.
 
 No entanto, a complexidade ciclomática indica o número de possíveis
 caminhos na execução de uma sub-rotina, e portanto é uma medida bastante
 útil para a atividade de teste de software \cite{herraiz2011}.
 
 \subsection{Complexidade Estrutural como combinação de ``gordura''graus de violação
 e tamanho}
 
 Sangwan e colegas \cite{sangwan2008} definem complexidade estrutural de
 um software em termos da combinação de três características:
 @@ -301,7 +366,7 @@ arestas que precisa ser removido para não haver dependências
 circulares. Por exemplo, na figura \ref{fig:strutcure101}, o \emph{MFS}
 é composto das arestas com pesos 3, 3 e 22. O grau de violação devido a
 entrelaçamento é um valor normalizado entre 0 e 1, calculado como a
 razão entre a soma dos pesos do \emph{MFS} pelopela soma dos pesos de todas
 as dependências. No exemplo da figura \ref{fig:strutcure101}, o grau de
 violação devido a entrelaçamento é
 $(3+3+22)/(3+3+22+8+84+329) \simeq 0.0623$.
 @@ -327,7 +392,7 @@ $max\left\{0, [(value - threshold)/value]\right\}$,
 onde $threshold$ é um limiar arbitrário.
 
 A determinação do \emph{tamanho} também depende do nível de abstração: o
 tamanho umde um pacote de alto nível é a soma dos tamanhos de seus
 sub-pacotes, o tamanho de um pacote que contém classes é a soma dos
 tamanhos das classes, e assim por diante, até chegar no tamanho de um
 método, definido como 1 mais o número de instruções contidas no método.
 @@ -347,7 +412,7 @@ escolha dos desenvolvedores) não se encaixam na estrutura de medição do
 \emph{Structure 101}.
 
 Outra desvantagem é o fato de que o limiar utilizado no cálculo do grau
 de violação devido à ``gordura'' seré arbitrário. Isto faz com que a
 medição dependa de um elemento subjetivo, e com que medições usando
 limiares diferentes não sejam compatíveis entre si.
 
 @@ -359,9 +424,10 @@ complexidade estrutural seja medida através da combinação de acoplamento
 e coesão. Estes são dois conceitos complementares: enquanto o
 acoplamento reflete o relacionamento entre módulos, a coesão nos fornece
 uma visão da organização dos componentes internos de um módulo e seus
 relacionamentos.  A literatura clássica para praticantesprofissionais da prática de
 projeto de software defende que módulos com baixo acoplamento e alta
 coesão são mais fáceis de entender e modificar \cite{martin2003,
 mcconnel2004}.
 
 Em termos de complexidade, a combinação de acoplamento e coesão numa
 única medida captura tanto a complexidade criada pelo excesso de
 @@ -386,33 +452,35 @@ Na definição acima, $A(m)$ representa o acoplamento do módulo $m$, e
 $FC(m)$ representa a falta de coesão do módulo $m$.
 
 Esta medida de complexidade estrutural é portanto a complexidade
 estrutural média entre todos os módulos do sistema. Quando um sistema
 cresce em tamanho e também tem a sua complexidade estrutural média
 aumentada, pode-se inferir que não só o sistema como um todo está maior
 e portanto, mais difícil de compreender e modificar, mas também que cada
 módulo, em média, também é mais difícil de compreender e modificar.modificar do
 que antes.
 
 A métrica proposta por Darcy \emph{et al.} para complexidade estrutural
 possui diversos pontos fortes.
 %
 Primeiro, a sua abordagemela foi baseada numaderivada de uma revisãoabrangente da literatura, na qual
 acoplamento e coesão foram identificados como fatores que poderiam
 fornecer uma medida significativa de complexidade estrutural.
 %
 Segundo, acoplamento e coesão não estão limitados ao paradigma da
 orientação a objetos. A maioria dos paradigmas de desenvolvimento de
 software possui uma ou mais construções que fazem o papel de
 \emph{módulo} -- ``classes'', ``aspectos'', ``tipos abstratos de
 dados'', ou ``arquivos-fonte'' -- para as quais medidas de acoplamento e
 coesão podem ser obtidas.
 %
 Finalmente, Darcy \emph{et al.}  validaram a suposição de que a
 complexidade estrutural está associada a maior esforço de manutenção por
 meio de um experimento controlado.  Os autores descobriram que nem
 acoplamento nem falta de coesão individualmente  explicavam a diminuição
 do desempenho dos desenvolvedores numa atividade de compreensão; apenas
 quando acoplamento e falta de coesão foram combinados e considerados
 como fatores que interagem, foi possível observar uma associação com
 maior esforço de manutenção.
 
 Ao contrário da complexidade de McCabe, a complexidade estrutural
 proposta por Darcy \emph{et al} não está necessariamente relacionada ao
 @@ -430,9 +498,15 @@ a complexidade estrutural também cresça necessariamente.
 
 \subsection{Avaliação das medidas}
 
 A tabela \ref{tab:medidas:comparacao} apresenta uma avaliação das
 diferentes medidas descritas anteriormente em função dos critérios
 apresentados no início da seção~\ref{sec:complexidade:medidas}.
 
 \begin{table}[hbt]
   \centering
   \begin{tabular}{p{0.65\textwidth}ccc}\caption{Comparação entre medidas de complexidade para sistemas de
   software}
   \begin{tabular}{p{0.75\textwidth}ccc}
     \hline
     \textbf{Proposta}                          & \textbf{C1} & \textbf{C2} & \textbf{C3} \\
     \hline
 @@ -441,16 +515,13 @@ a complexidade estrutural também cresça necessariamente.
     SC por Darcy \emph{et al} \cite{darcy2005} & Sim         & Sim         & Sim \\
     \hline
   \end{tabular}
   \caption{Comparação entre medidas de complexidade para sistemas de
   software}
   \label{tab:medidas:comparacao}
 \end{table}
 
 A tabela \ref{tab:medidas:comparacao} apresenta uma avaliação das
 diferentes medidas descritas anteriormente em função dos critérios
 listados no início da seção~\ref{sec:complexidade:medidas}. 
 Os quesitos marcados com uma interrogação são aquelesNão foi possível avaliar o critério C2 para os
 quaisa medida de complexidade
 estrutural do Structure 101, pois não foi encontradaevidência na literatura.literatura
 técnica nenhuma evidência sobre a sua relação com o tamanho de sistemas
 de software.
 
 A medida de complexidade estrutural proposta por Darcy e
 colegas \cite{darcy2005} é a única que atende a todos os critérios
 @@ -502,7 +573,7 @@ estrutural atraíram menos usuários e também menos desenvolvedores.
 Para projetos de software livre que não possuem apoiadores corporativos
 e dependem apenas de desenvolvedores independentes para evoluir, este
 resultado demonstra a necessidade de manter a complexidade estrutural do
 seusistema sob controle.
 
 Resultados semelhantes aos descritos anteriormente também estão
 disponíveis para outras medidas de complexidade: Midha \cite{midha2008}
 @@ -510,7 +581,7 @@ estudou 450 projetos escritos em C e C++ disponíveis no
 \emph{Sourceforge} e verificou que a complexidade de McCabe estava
 positivamente correlacionada com o número de defeitos e com o tempo
 levado para correção de defeitos, e negativamente correlacionada com o
 número de contribuiçãocontribuições de novos desenvolvedores.  Ainda que usando uma
 medida diferente da utilizada neste trabalho, esses resultados reforçam
 a percepção que que um aumento na complexidade em projetos de software é
 algo a ser evitado.
 @@ -523,15 +594,15 @@ software livre escritos em Java disponíveis no \emph{Sourceforge} e
 mediram a complexidade estrutural da forma proposta por Darcy \emph{et
 al} \cite{darcy2005}.  Entre estes projetos, eles verificaram quatro
 diferentes padrões na evolução da complexidade estrutural: dois deles
 apresentavamuma tendência de crescimento ao final do período observado,
 enquanto outros dois apresentaramuma estabilização da complexidade
 estrutural. Nenhum dos padrões encontrados, no entanto, apresentouuma
 tendência de diminuição da complexidade estrutural ao final do período
 de observação: aparentemente, a tendência natural da complexidade
 estrutural éde sempre aumentar com o tempo, ou na melhor das hipóteses,de se
 manter estável. Um estudo preliminar realizado comcomo parte deste trabalho
 também identificouuma tendência de crescimento da complexidade estrutural
 em um projeto de software livre pequeno e escrito em C
 \cite{terceiro2009}.
 
 \def\FNLehman{\footnote{Ainda que as ``leis de Lehman'' não sejam
 @@ -571,3 +642,27 @@ Faz-se necessário, então, identificar fatores que influenciam a variação
 na complexidade estrutural, de forma que desenvolvedores e líderes de
 projetos sejam capazes de manipulá-los para manter a complexidade
 estrutural dos seus projetos sob controle.
 \section{Conclusão}
 \label{sec:complexidade:conclusao}
 
 Este capítulo apresentou os principais conceitos sobre complexidade
 estrutural utilizados neste trabalho. Inicialmente, foi feita uma
 analogia com o campo dos sistemas complexos.
 %
 Em seguida, foi discutido o conceito de complexidade para sistemas de
 software. Além da complexidade estrutural, tratada no restante deste
 trabalho, a complexidade em sistemas de software pode ser encarada por
 dois outros pontos de vista: a complexidade do problema (ou complexidade
 natural) e a complexidade procedural.
 
 Três medidas para complexidade de sistemas de software foram
 apresentadas e avaliadas, ao fim do que a medida de complexidade
 estrutural baseada em acoplamento e coesão proposta por Darcy \emph{et
 al} foi selecionada para utilização neste trabalho. Resultados
 existentes associam esta medida a consequências negativas em projetos de
 software, e indicam que sua tendência evolutiva natural parece ser de
 crescimento, ou no melhor caso, de estagnação, mas nunca de redução.
 
 O capítulo seguinte descreve fatores identificados como possíveis
 causas para a variação da complexidade estrutural em sistemas de
 software.
 diff --git a/04-fatores.tex b/04-fatores.tex
 index 060f0d2..c186ad2 100644
 --- a/04-fatores.tex
 +++ b/04-fatores.tex
 @@ -1,4 +1,14 @@
 \chapter{Fatores\xchapter{Fatores de Interesse para o Estudo da Evolução da Complexidade
 Estrutural}Estrutural}{
   Este capítulo descreve fatores identificados como possíveis causas da
   variação na complexidade estrutural em projetos de software,
   classificados em três grupos: fatores relacionados aos
   desenvolvedores, fatores relacionados à manutenção realizada no
   sistema, e fatores relacionados à organização onde o sistema é
   desenvolvido. Por fim, são discutidos estudos relacionados, que
   investigam a influência destes fatores sobre outros atributos de
   qualidade de sistemas de software.
 }
 \chaptermark{Fatores de Interesse}
 \label{cap:fatores}
 
 @@ -43,16 +53,16 @@ fatores foram então organizados em três grupos:
     esperamos que fatores relacionados às mudanças realizadas no sistema
     possuam uma influência sobre a complexidade estrutural.
 
     Neste grupo estão fatores como variação de tamanho,tamanho do sistema
     causado por uma mudança, difusão de mudança, tipo de manutenção
     realizada, etc.  A seção \ref{sec:fatores:mudancas} discute fatores
     relacionados ao processo de manutenção.
 
   \item
     \emph{Fatores relacionados à organização.}  Além das características
     dos desenvolvedores, esperamos que o ambiente organizacional ondesob o
     qual um sistema é desenvolvido também possua alguma influência sobre
     a complexidade estrutural.
 
     Neste grupo estão fatores como maturidade do processo de
     desenvolvimento, estrutura organizacional, etc.
 @@ -63,7 +73,8 @@ fatores foram então organizados em três grupos:
 
 A seção \ref{sec:fatores:trabalhos-relacionados} discute trabalhos
 relacionados, nos quais fatores apresentados neste capítulo são
 explorados. A seção \ref{sec:fatores:conclusao} conclui o capítulo com
 um resumo do que foi apresentado nas seções anteriores.
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 @@ -73,12 +84,12 @@ explorados.
 \subsection{Experiência no Projeto}
 \label{sec:fatores:experiencia}
 
 A \emph{experiência do desenvolvedor} é abordada na literatura técnica
 em termos de duas dimensões distintas. A primeira dimensão está
 associada com a experiência prévia de trabalho dos desenvolvedores: eles
 são caracterizados em termos de ``anos de experiência'', ou de ``nível
 de habilidade'', normalmente representadas em escalas ordinais como
 ``baixo/médio/alto''``baixo, médio ou alto'' ou em escalas numéricas simples como ``de 1 a 5''.
 
 Esta dimensão de experiência já foi usada, por exemplo, para predizer
 produtividade de projetos \cite{banker1991}, esforço de manutenção
 @@ -88,11 +99,12 @@ criticados por não levarem em conta aspectos de experiência prática
 anterior \cite{steen2007}.
 
 Uma segunda dimensão de experiência dos desenvolvedores está relacionada
 com suaa atividade numem um dado projeto. Ao invés de utilizar medidas
 subjetivas e estáticas como descrito acima,anteriormente, esta dimensão é
 caracterizada pela contagem de mudanças que um desenvolvedor realiza no
 projeto. Considera-se queque, de forma geral, a experiência do
 desenvolvedor naquele projeto aumenta na medida em que ele realiza
 mudanças.
 
 A experiência de um desenvolvedor no contexto de um projeto pode ser
 medida com o uso de informações de \emph{commits} em sistemas de
 @@ -115,18 +127,17 @@ preditora para a ocorrência de defeitos \cite{mockus2000,matsumoto2010}.
 \subsection{Grau de Autoria}
 \label{sec:fatores:grau-de-autoria}
 
 Um aspecto importante da participação de um desenvolvedor num projeto de
 desenvolvimento de software diz respeito às partes do projeto com as
 quais ele interage.  A partir de informações sobre mudanças armazenadas
 numem um sistema de controle de versão, é possível determinar a parcela de
 autoria de um desenvolvedor com relação a qualquer arquivo do projeto.
 
 O \emph{grau de autoria} de um desenvolvedor com relação a um elemento
 do sistema \cite{mockus2002-1,fritz2010} é uma medida que indica tal
 parcela, de forma que se possa caracterizar um desenvolvedor em termos
 dos elementos sobre os quais ele tem mais conhecimento, ou mesmo
 comparar dois desenvolvedores em termos da probabilidadesprobabilidade de terem
 conhecimento sobre um determinado elemento.
 
 Mockus e Herbsleb \cite{mockus2002-1} utilizaram informações de autoria
 @@ -147,7 +158,7 @@ A proposta de Fritz e colegas \cite{fritz2010} para calcular o grau de
 autoria resolve esta questão: na medida em que um desenvolvedor altera
 um módulo, o grau de autoria dos desenvolvedores que haviam alterado o
 mesmo módulo anteriormente irá decair. Fritz e colegas utilizaram o grau
 de autoria em conjunto como informações sobre interação.
 
 O \emph{grau de conhecimento} ($DOK$ -- \emph{degree of knowledge}) de um
 desenvolvedor com relação a um determinado elemento do código (arquivo,
 @@ -210,7 +221,7 @@ grau de interação, o grau de conhecimento de um desenvolvedor sobre um
 determinado elemento do sistema pode ser medido em estudos que apenas
 contemplem dados obtidos de sistemas de controle de versão.
 
 Desse modo, torna-se viável a utilização do grau de autoria comcomo um
 \emph{proxy} para o grau de conhecimento em estudos experimentais
 quantitativos em larga escala.
 
 @@ -233,7 +244,7 @@ projeto. O nível de participação é determinado pela quantidade de
 contribuições que o desenvolvedor realiza, e está associado ao poder de
 decisão que o desenvolvedor possui sobre o projeto.
 
 O ``modelo cebola'' \cite{crowston2005, mockus2002},\cite{mockus2002, crowston2005}, ilustrado na figura
 \ref{fig:onion-model}, se tornou uma representação amplamente aceita do
 que acontece num projeto de software livre, ao indicar a existência de
 níveis concêntricos de contribuição.
 @@ -303,7 +314,7 @@ triagem de defeitos \cite{masmoudi2009}.
 \subsection{Variação de Tamanho}
 \label{sec:fatores:variacao-de-tamanho}
 
 O \emph{tamanho do software} é um atributo que têmtem sido recorrentemente
 observado por pesquisadores e engenheiros de software.
 %
 Muitos acreditam que há uma relação entre tamanho do software e sua
 @@ -351,14 +362,14 @@ são pontuais, afetando poucas linhas de código em um único módulo;
 outras mudanças podem afetar diversos módulos diferentes.
 
 Uma alta difusão de mudança pode indicar de que o \emph{design} atual do
 software não comporta aqueleaquela mudança de uma forma modular, e por isso é
 necessário alterar uma grande quantidade de módulos diferentes para
 atingir o resultado desejado.
 
 Como a cognição humana tem limites \cite{miller1956, gigerenzer2002},
 uma mudança que envolve uma quantidade de módulos maior do que aquela
 com a qual um desenvolvedor pode lidar ao mesmo tempo exige um maior
 esforço cognitivo por parte dos desenvolvedores. Isso podepoderia acarretar,
 por exemplo, num maior risco de violação de decisões arquiteturais ou de
 introdução de defeitos.
 
 @@ -369,13 +380,14 @@ probabilidade de introdução de defeitos \cite{mockus2000}.
 
 Hassan propôs medidas para a complexidade de mudanças baseadas na sua
 entropia, um conceito similar à difusão de mudança, que superaram outras
 outrasmétricas usadas anteriormente, como número de modificações prévias e
 número de defeitos prévios, na previsão de defeitos \cite{hassan2009}.
 
 Espera-seIntuitivamente, é de se esperar que mudanças que afetam mais módulos
 também aumentem o risco de que ao modificar um \emph{design} de software
 existente, os desenvolvedores acabem tornando-o mais complexo. Por outro
 lado, a recíproca pode também ser verdadeira: talvez um \emph{design}
 mais complexo leve a mudanças mais difusas.
 
 \subsection{Tipo de Mudança}
 \label{sec:fatores:tipo-de-mudanca}
 @@ -432,7 +444,7 @@ repositórios de engenharia de software. Por exemplo, diversos sistemas
 de gestão de atividades armazenam explicitamente esse tipo de informação
 para cada requisição de mudança.
 
 Espera-se que o tipo de mudança influenciainfluencie a variação na complexidade
 estrutural. Correções de defeitos provavelmente não afetam a
 complexidade estrutural. Já melhorias provavelmente afetam, pois podem
 envolver a adição de novos módulos e a modificação substancial de
 @@ -441,6 +453,14 @@ módulos existentes.
 \section{Fatores relacionados à organização}
 \label{sec:fatores:organizacao}
 
 Neste trabalho, o termo ``organização'' é utilizado num sentido amplo,
 abrangendo coletivos de pessoas que colaboram para a construção de um
 sistema de software. Exemplos de organizações são empresas de
 desenvolvimento de software e projetos de software livre. As subseções a
 seguir apresentam aspectos de organizações de desenvolvimento de
 software que podem ter influência sobre a complexidade estrutural de
 sistemas de software.
 
 \subsection{Nível de maturidade}
 \label{sec:fatores:maturidade}
 
 @@ -450,7 +470,7 @@ realizam projetos, acumulando práticas e conhecimentos que são
 aproveitados de um projeto para o outro.
 
 O \emph{nível de maturidade} de uma organização desenvolvedora de
 software indica a presençãopresença de alguns elementos considerados importantes
 para a obtenção de produtos de software de qualidade, como por exemplo a
 sistematização do processo de desenvolvimento, a presença de boas
 práticas e a instituição de um programa de melhoria do processo de
 @@ -474,14 +494,14 @@ A partir da percepção de que projetos de software livre são organizações
 substancialmente diferentes das organizações desenvolvedoras de software
 para as quais modelos como CMMI e MPS-BR foram desenvolvidos, o projeto
 QualiPSo desenvolveu o OMM (\emph{Open Source Maturity Model}
 \cite{omm}.\cite{omm}). O OMM tem o objetivo de fornecer um modelo de maturidade
 adaptado à realidade de projetos de software livre, contendo elementos
 específicos do desenvolvimento de software livre e deixando de lado
 aspectos que apenas se aplicam a organizações privadas de
 desenvolvimento de software.
 
 Espera-seÉ de se esperar que mais altos níveis de maturidade incorram em software
 com menos complexidade estrutural. Na medida em que alcançam níveis mais
 altos de maturidade, as organizações podem tomar medidas para melhoria
 do produto e do processo que beneficiem a manutenibilidade dos produtos.
 Em especial, espera-se que impeçam o aumento explosivo da complexidade
 @@ -519,21 +539,20 @@ precisão e revocação \cite{nagappan2008}. O modelo obtido obteve uma
 desempenho melhor do que outros modelos baseados em métricas de
 código-fonte, número de mudanças prévias e número de defeitos prévios.
 
 Capra, Francalanci e Merlo concluíram num estudo de caso com 75 projetos
 de software livre que projetos com uma estrutura de governança mais
 aberta exibiram melhor qualidade de design \cite{capra2008}.
 
 Também esperamos que a estrutura organizacional na qual um sistema de
 software é desenvolvido influencie a sua complexidade estrutural. Em
 especial, se a lei de Conway estiver certa, a complexidade da estrutura
 de comunicação de uma organização deve refletir-se na complexidade do
 sistema.sistema produzido por ela.
 
 \section{Estudos Relacionados}
 \label{sec:fatores:trabalhos-relacionados}
 
 Esta seção apresenta brevemente alguns trabalhos relacionados, divididos
 em subseções que os agrupam em tópicos que consideramos associados ao
 tema deste capítulo.  Assim como neste tese, nos estudos apresentados a
 seguir, é investigada a influência dos fatores discutidos neste capítulo
 sobre atributos de qualidade de sistemas de software.
 
 \subsection{Impacto de fatores organizacionais sobre atributos de
 qualidade de software}
 @@ -570,15 +589,15 @@ desenvolvimento pode levar a uma perda de integridade conceitual
 \subsection{Caracterização de mudanças em projetos de software}
 
 William e Carver  realizaram uma revisão sistemática com o objetivo de
 determinar os tipos de mudanças que impactam na arquitetura de software
 \cite{williams2010}.  Com base nos resultados, eles propuseram um
 esquema para caracterização de mudanças na arquitetura de software.
 Nesse esquema, as mudanças são avaliadas em termos de diferentes
 características, de forma a guiar o desenvolvedor no processo de decisão
 sobre a viabilidade da mudança e na previsão dos seus impactos
 \cite{williams2010}. Algumas das características incluídas no esquema de
 caracterização de mudanças proposto pelos autores coincidem com os
 fatores utilizados neste trabalho, e são discutidos no capítulo \ref{cap:fatores}.trabalho.
 
 \subsection{Impacto de mudanças sobre atributos de qualidade}
 
 @@ -620,3 +639,22 @@ desenvolvedores como ``número de \emph{commits} por desenvolvedor'',
 módulos alterados por mais desenvolvedores continham mais falhas, e que
 o uso de métricas relacionadas aos desenvolvedores melhoravam o
 desempenho de modelos de predição \cite{matsumoto2010}.
 
 \section{Conclusão}
 \label{sec:fatores:conclusao}
 
 Este capítulo apresentou um conjunto de fatores que podem influenciar a
 complexidade estrutural em sistemas de software, divididos em três
 grupos: fatores relacionados aos desenvolvedores, fatores relacionados à
 manutenção realizada no sistema, e fatores relacionados à organização de
 desenvolvimento de software.
 
 Foi apresentada uma série de estudos relacionados, nos quais é
 investigada a influência destes fatores sobre atributos de qualidade de
 software.
 
 O capítulo seguinte descreve os estudos realizados durante o
 desenvolvimento deste trabalho, nos quais investigou-se a influência
 dos fatores relacionados aos desenvolvedores e dos fatores relacionados
 à manutenção realizada sobre a variação da complexidade estrutural em
 projetos de software livre.
 diff --git a/06-estudos-experimentais.tex b/05-estudos-experimentais.tex
 similarity index 72%
 rename from 06-estudos-experimentais.tex
 rename to 05-estudos-experimentais.tex
 index 391c692..a5a6930 100644
 --- a/06-estudos-experimentais.tex
 +++ b/05-estudos-experimentais.tex
 @@ -1,4 +1,10 @@
 \chapter{Estudos\xchapter{Estudos Experimentais Realizados}Realizados}{
   Este capítulo descreve os estudos experimentais realizados durante o
   desenvolvimento deste trabalho. São apresentados quatro estudos e é
   feita uma discussão geral sobre os resultados obtidos, em termos dos
   fatores que influenciam a complexidade estrutural em sistemas de
   software livre.
 }
 \label{cap:estudos-experimentais}
 \chaptermark{Estudos Experimentais}
 
 @@ -35,6 +41,11 @@ o anterior na busca de melhores modelos para a variação da complexidade
 estrutural. O estudo inclui  os componentes do grau de autoria (seção
 \ref{sec:fatores:grau-de-autoria}) e melhora a definição operacional
 da difusão de mudança (seção \ref{sec:fatores:difusao-de-mudanca}).
 %
 Por fim, a seção \ref{sec:estudos:conclusao} conclui este capítulo e
 apresenta uma discussão sobre os fatores que foram identificados nos
 estudos como relevantes com relação à variação da complexidade
 estrutural nos projetos analisados.
 
 \section{Considerações gerais}
 \label{sec:estudos:overview}
 @@ -45,7 +56,7 @@ apresentados neste capítulo.
 \subsection{Cálculo da complexidade estrutural}
 
 Nos estudos realizados, a complexidade estrutural foi calculada conforme a
 proposta de David,Darcy, Kemerer, Slaughter e Tomayko \cite{darcy2005}. Desta
 forma, a complexidade estrutural de um sistema de software é definida
 como:
 
 @@ -72,15 +83,29 @@ número de componentes conexos de um grafo não dirigido onde os vértices
 são as sub-rotinas (métodos, funções, etc) de um módulo, e as arestas
 indicam que duas sub-rotinas usam pelo menos um atributo ou variável em
 comum, ou que uma das sub-rotinas chama a outra.  Estes componentes
 conexos representam partes independentes de um módulo, ou seja, que
 implementam responsabilidades distintas.
 
 Para linguagens orientadas a objeto como C++ e Java, classes são
 considerads como módulos. Para C, pares de arquivos
 cabeçalho/implementação (\texttt{.h}/\texttt{.c}) são considerados como
 um módulo. Ainda que as métricas utilizadas para acoplamento e móduloscoesão
 tenham sido definidas no contexto da orientação a objetos, consideramos
 que possuem maiselas podem ser aplicadas no contexto de uma responsabilidades independentes,programas em C com as
 devidas adaptações, considerando as funções e portanto
 distintas.
 
 \subsection{Analizo}variáveis de um módulo
 como análogas a métodos a atributos de uma classe.
 
 \subsection{A ferramenta Analizo}
 \label{sec:estudos:analizo}
 
 Durante o desenvolvimento deste trabalho, identificamos a necessidade de
 realizar análise de código fonte para extração de métricas.  As
 ferramentas encontradas que estavam disponíveis sob licenças de software
 livre ou suportavam uma única linguagem de programação ou estavam
 obsoletas, que dificultava a sua utilização. Identificamos a necessidade
 de realizar análise de código fonte em programas escritos em diferentes
 linguagens de programação. Por isso, foi desenvolvida uma ferramenta
 para realizar análise de código fonte chamada de Analizo,Analizo.  Analizo é uma
 suíte de ferramentas de análise e visualização de código fonte que
 suporta diferentes linguagens de programação.  Analizo foi utilizada
 para extração de dados em todos os estudos experimentais realizados.
 @@ -101,9 +126,9 @@ um \emph{design} orientado a objetos de forma que diferentes estratégias
 de extração de dados a partir do código fonte pudessem ser
 implementadas.
 
 Joenio Costa (Universidade Católica do Salvador) implementou um extrator
 baseado no Doxygen\footnote{\url{http://www.doxygen.org/}}, um sistema
 para documentação de software cujo \textit{parser} padrão suporta
 código-fonte C, C++ e Java \cite{costa2009}. Isso possibilitou analisar
 projetos sem a necessidade de compilar o seu código fonte, o que traz
 duas vantagens.  Primeiro, o processo de extração passou a exigir menos
 @@ -118,33 +143,33 @@ ferramenta pelo nome original, uma vez que praticamente nenhum código do
 significa ``análise'' em esperanto.
 
 Para o segundo estudo experimental (seção \ref{sec:estudo:sbes2010}),
 Luiz Romário Rios (UFBA) colaborou com a criação de programas para
 automatizar o processo de invocar Analizo em todas as versões
 disponíveis em um repositório de controle de versão.  Estes programas
 foram reunidos num pacote chamado de \texttt{analizo-utils}. Apesar da
 adoção do \textit{parser} do Doxygen, que teoricamente suportaria C, C++
 e Java, havia um defeito na interface da Analizo comocom o Doxygen que
 impedia a correta análise de código orientado a objetos. Por essa razão,
 o estudo descrito na seção \ref{sec:estudo:sbes2010} precisou ser
 realizado apenas com projetos escritos em C.
 
 Na mesma época, Paulo Meirelles, João Miranda e Lucianna Almeida
 (IME-USP) começaram a colaborar no desenvolvimento de Analizo, em
 especial, na implementação de novas métricas e no desenvolvimento de um
 novo extrator para determinação do tamanho em linhas de código com a
 ajuda de uma ferramenta chamada
 \texttt{sloccount}\footnote{\url{http://www.dwheeler.com/sloccount/}}.
 
 O defeito na interface com o Doxygen foi resolvido, de forma que para o
 estudo apresentado na seção \ref{sec:estudo:csmr2012}, foi possível
 analisar projetos escritos em C, C++ e Java. Além disso, os programas
 auxiliares presentes no pacote \texttt{analizo-utils} foram incorporados
 à Analizo, oficializando o suporte aà mineração de dados em repositórios
 de controle de versão.
 %
 Nesse cenário, a saída disponível para o processo de mineração de dados
 era uma única tabela, que continha uma linha para cada versão analisada.
 Cada uma destas linhas continha métricas globais relativas àqueleàquela versão
 (por exemplo, tamanho em linhas de código, número de módulos), e
 métricas de módulo agregadas (por exemplo, acoplamento médio, falta de
 coesão média, e complexidade estrutural média -- que era nossa variável
 @@ -200,7 +225,8 @@ estudos experimentais apresentados neste capítulo:
     detalhe possível os procedimentos utilizados nos estudos.
 \end{itemize}
 
 \section{Estudo sobre evolução\section{Evolução da complexidade estrutural numem um projeto de software livre}
 \sectionmark{Evolução da complexidade estrutural}
 \label{sec:estudo:quacos2009}
 
 O primeiro estudo realizado foi um estudo exploratório com dois
 @@ -209,15 +235,15 @@ objetivos principais:
 \begin{itemize}
   \item
     Experimentar uma abordagem para o estudo da evolução da complexidade
     estrutural em projetos de software que pudessepossa ser usada por
     desenvolvedores em seus próprios projetos. Isto incluía realizar uma
     prova de conceito de Analizo.
   \item
     Obter resultados iniciais sobre a evolução da complexidade
     estrutural num projeto de software livre escrito em C, de forma a
     poder compará-los comcomplementar os resultados obtidos no estudo de Stewart e colegas
     \cite{stewart2006}, realizados com projetos de software escritos em
     Java.
 \end{itemize}
 
 Para isso, foi realizado um estudo de caso com a evolução de um projeto
 @@ -234,14 +260,14 @@ Projects: A Case Study}'' \cite{terceiro2009}. O apêndice
 
 \subsection{Hipóteses}
 
 Este estudo colocouinvestigou duas hipóteses com relação à evolução do projeto
 Ristretto:
 
 \begin{description}
   \item
     $H_1:$ o tamanho do código fonte cresceaumenta com a passagem do tempo
   \item
     $H_2:$ a complexidade estrutural do projeto cresceaumenta com a passagem do
     tempo.
 \end{description}
 
 @@ -258,12 +284,11 @@ projeto, foram extraídas as seguintes variáveis:
   \item
     $SLOC$ -- tamanho do projeto em linhas de código.
   \item
     $SC$ -- complexidade estrutural média, conforme \cite{darcy2005}.
     No estudo publicado, esta variável foi originalmente chamada
     ``CplXLCoh'', que era o nome utilizado no estudos do grupo
     proponente \cite{darcy2005, stewart2006}. Posteriormente decidiu-se
     usar um nome mais simples.simples ($SC$).
 \end{itemize}
 
 As hipóteses foram testadas de acordo com a seguintes formalizações:
 @@ -303,14 +328,6 @@ correlação de $0.8636375$ entre $RD$ e $SC$, com $p < 0.01$. A figura
 \ref{fig:ristretto:complexidade-estrutural} mostra uma plotagem da
 complexidade estrutural média contra o dia de lançamento.
 
 \begin{figure}[hbt]
   \begin{center}
     \includegraphics[width=0.9\textwidth]{artigos/structural-complexity-evolution-case-study/arch-evolution}
   \end{center}
   \caption{Ristretto: evolução da arquitetura}
   \label{fig:ristretto:arquitetura}
 \end{figure}
 
 Apesar de tanto tamanho quanto complexidade estrutural apresentarem uma
 forte correlação com o tempo de lançamento das versões, nota-se
 claramente que esse crescimento não é uniforme. Na figura
 @@ -328,24 +345,56 @@ versão imediatamente anterior, ou seja, as descontinuidades no
 aumento da complexidade estrutural coincidiram com momentos de
 reorganização da arquitetura do projeto.
 
 \begin{figure}[h]
   \begin{center}
     \includegraphics[width=0.8\textwidth]{artigos/structural-complexity-evolution-case-study/arch-evolution}
   \end{center}
   \caption{Ristretto: evolução da arquitetura}
   \label{fig:ristretto:arquitetura}
 \end{figure}
 
 \subsection{Ameaças à validade}
 
 Com relação à \emph{validade  de conclusão}, a utilização do teste de
 correlação de Pearson não foi totalmente adequada: ainda que $SLOC$ e
 $SC$ apresentem distribuição normal, o mesmo não vale para a
 variável independente $RD$. Desta forma, a utilização do teste
 de Pearson não é adequada, por ele ser indicado para variáveis normais
 \cite{wohlin2000}. No entanto, verificou-se posteriormente que o teste
 de Spearman, adequado para variáveis cuja distribuição não é normal,
 confirma os resultados relatados e até apresenta correlações mais
 fortes.
 
 Este estudo também apresenta ameaças à \emph{validade externa}, porque o
 projeto estudado (Ristretto) não é representativo de sistemas de
 software nos quais este tipo de análise se faz necessário. Primeiro, é
 um sistema bastante pequeno (menos de dez mil linhas de código).
 Segundo, porque possui apenas um desenvolvedor. Apesar do repositório de
 controle de versão do projeto apresentar 13 diferentes autores de
 contribuições ao projeto, foi descoberto posteriormente que apenas 1
 desenvolvedor fazia modificações no código fonte, enquanto os outros 12
 realizavam mudanças apenas em arquivos relacionados à tradução do
 programa para diferentes idiomas.
 
 \subsection{Conclusões}
 
 Neste estudo identificamos que mudanças na tendência evolutiva de
 aumento da complexidade estrutural, como descontinuidades e redução da
 taxa de crescimento, normalmente estão associadas a mudanças estruturais
 na arquitetura do projeto.
 
 Concluímos também que a abordagem desenvolvida para análise automatizada
 de projetos de software era viável para estudos de grande escala e que
 poderíamos automatizar a execução para um grande número de versões.
 
 De forma similar, uma vez que é possível automatizar a execução da
 Analizo, ela poderia ser introduzida no processo de compilação de
 projetos, viabilizando a análise e visualização de métricas durante o
 processo de desenvolvimento.
 
 \section{Estudo experimental sobre complexidade estrutural\section{Complexidade e nível de
 participação de desenvolvedore}desenvolvedores}
 \sectionmark{Complexidade Estrutural e Nível de Participação}
 \label{sec:estudo:sbes2010}
 
 Este estudo teve o objetivo de investigar a influência do nível de
 @@ -403,17 +452,18 @@ Assim, formulamos a segunda hipótese:
 \subsection{Projeto experimental}
 
 Este estudo foi realizado por meio da coleta de dados em repositórios de
 controle de versão de 7 projetos de software livre,livre no domínio de
 servidores \emph{web}.\emph{web}, conforme apresenta a tabela
 \ref{tab:core-periferia:projetos}. A unidade experimental escolhida foi
 o \emph{commit}, como são conhecidas as mudanças registradas em sistemas
 de controle de versão.
 Para cada \emph{commit}, foram obtidas as seguintes variáveis:
 
 \begin{itemize}
   \item
     Variável independente:
     \begin{itemize}
       \item
         $L$, o nível de participação no projeto associado ao
         desenvolvedor no momento de realização do \emph{commit}. Esta
         variável possui dois valores: ``central'' e ``periférico''.
 @@ -441,6 +491,7 @@ descritivas dos projetos analisados neste estudo.
 
 \begin{table}
   \centering
   \caption{Projetos analisados}
   \begin{tabular}{lllll}
     \hline
     \textbf{Projeto}          &
 @@ -458,7 +509,6 @@ descritivas dos projetos analisados neste estudo.
     weborf    & 2008/07 & 2009/10 & 139  & 3    \\
     \hline
   \end{tabular}
   \caption{Projetos analisados}
   \label{tab:core-periferia:projetos}
 \end{table}
 
 @@ -525,10 +575,65 @@ $H_2$ foi formalizada como se segue:
   \mu_{\left|\Delta{}SC\right|_{perif}}
 \]
 
 O teste-t para $H_2$ também nos permitiu aceitar $H_2$ withcom $p < 0.05$
 ($p = 0.01091324$). Desta forma, os dados também suportaram a nossa
 hipótese de que nas atividades de redução da complexidade, os
 desenvolvedores centrais são capazes de remover mais complexidade (em
 média) do que os desenvolvedores periféricos.
 
 \subsection{Ameaças à validade}
 
 Ainda que projetado cuidadosamente, este estudo possui algumas
 limitações que representam ameaças à sua validade.
 
 Do ponto de vista da \emph{validade de conclusão}, o fato da variável
 testada ($\Delta{SC}$) não possuir uma distribuição normal e ainda assim
 ter sido utilizado um teste-t representa um risco, uma vez que o teste-t
 normalmente requer variáveis com distribuição normal. Apesar disso,
 Wohlin nota que o teste-t é robusto o suficiente para suportar algum
 distanciamento das suas pré-condições. Em especial, como a amostra é
 grande o suficiente, o teste-t pode ser usado sem problemas
 \cite{wohlin2000}. Para ter certeza, foi aplicado também um teste de
 Wilcoxon/Mann-Whitney -- um teste não paramétrico utilizado em substituição
 ao teste-t para amostras não distribuídas normalmente -- que nos
 forneceu resultados semelhantes.
 
 Com relação à \emph{validade externa}, a escolha de projetos escritos em
 C e dentro de um único domínio de aplicação não produziu uma amostra
 representativa de sistemas de software livre nem de sistemas de software
 em geral.
 
 Do ponto de vista da \emph{validade interna}, o fato de ter sido
 utilizada uma única variável independente representa uma ameaça. A nossa
 análise levou em consideração apenas o fato do desenvolvedor
 responsável pela mudança ser um desenvolvedor central ou periférico.
 %
 Em especial, não foi analisada a natureza de cada mudança, ou outros
 atributos dos desenvolvedores e das mudanças.
 %
 Desta forma, é possível que haja outros fatores fora do nosso controle
 que influenciem a variação na complexidade estrutural causada por
 mudanças.
 
 Do ponto de vista da \emph{validade de construção}, uma limitação
 causada pela escolha de usar apenas informações armazenadas de forma
 estruturada nos repositórios de controle de versão é a possibilidade de
 considerar o usuário responsável pelo \emph{commit} como sendo o autor
 do \emph{commit}. Como os projetos analisados utilizavam sistemas de
 controle de versão que não armazenam a informação de autoria
 explicitamente, é possível que uma parte dos \emph{commits} realizados
 estejam sendo atribuídos a desenvolvedores que apenas aplicaram no
 repositório oficial mudanças que na verdade foram realizadas por outros
 desenvolvedores.  Para mitigar essa possibilidade, nos estudos
 posteriores foram utilizados apenas informações de projeto cujo controle
 de versão armazena explicitamente a informação de autoria de cada
 \emph{commit}.
 
 Ainda com relação à \emph{validade de construção}, não foram analisadas
 mudanças que não causaram mudança na complexidade estrutural (i.e.
 aquelas onde $\Delta{}SC = 0$).  Tais mudanças podem revelar atividade
 de \emph{design} interessantes, mas que pelo fato de não alterarem a
 complexidade estrutural, foram desconsideradas neste estudo.
 
 \subsection{Conclusões}
 
 @@ -585,7 +690,7 @@ domínios de aplicação, com o objetivo de estudar a influência de três
 fatores sobre a variação de complexidade estrutural: experiência dos
 desenvolvedores, variação de tamanho e difusão da mudança.
 
 Este estudo foi aceito para publicaçãopublicado nos anais da \emph{16th European
 Conference on Software Maintenance and Reengineering} com o título
 ``\emph{Understanding Structural Complexity Evolution: a Quantitative
 Analysis}'' \cite{terceiro2012:csmr}. O apêndice \ref{apendice:csmr2012}
 @@ -690,6 +795,7 @@ mas considerados para conjuntos disjuntos de \emph{commits}.
 \def\DMsg{Mensageria}
 \begin{table}
   \centering
   \caption{Descritivo dos projetos estudados}
   \begin{tabular}{llllll}
     \hline
     \projeto  & \ling & \devtime    & \devs   & \modules & \domain  \\
 @@ -701,14 +807,13 @@ mas considerados para conjuntos disjuntos de \emph{commits}.
     Zeromq2   & C++      & 1.75 anos  & 39    & 106      & \DMsg   \\
     \hline
   \end{tabular}
   \caption{Descritivo dos projetos estudados}
   \label{tab:csmr2012:projetos}
 \end{table}
 
 Para mitigar a limitação identificada no estudo apresentado na seção
 \ref{sec:estudo:sbes2010}, desta vez buscamos projetos que utilizassem
 um sistema de controle de versão que armazena explicitamente a
 identificação do autor do \emph{commit}.  DesteDesta forma, neste estudo
 foram analisados 5 projetos que utilizavam
 Git\footnote{\url{http://git-scm.org/}}, cujos repositórios, portanto,
 apresentam informação de autoria das mudanças mais confiável.  Os
 @@ -720,7 +825,7 @@ de Lisp, e sua principal implementação, que também se chama Clojure, é
 desenvolvida em Java e compila código Clojure para \emph{bytecode} de
 máquinas virtuais Java. Node é uma plataforma para programação em
 Javascript baseada no motor V8 Javascript com entrada e saída
 baseada em eventos, usada principalmente para programação
 de aplicações servidoras em Javascript. Redis e Voldemort são sistemas
 de armazenamento de pares chave/valor, normalmente consideradas como
 pertencendo à categoria de ``bancos de dados NoSQL''.  Zeromq2 é uma
 @@ -779,6 +884,8 @@ considerados significativos estão destacados em negrito.
 
 \begin{table}
   \centering
 \caption{Modelos de regressão para \emph{commits} que \textbf{aumentam}
 a complexidade estrutural.}
 % latex table generated in R 2.14.0 by xtable 1.5-6 package
 % Tue Nov  1 18:16:49 2011
 \begin{tabular}{llllr}
 @@ -794,8 +901,6 @@ considerados significativos estão destacados em negrito.
 \end{tabular}\\
 \vspace{0.5em}
 ***: $p < 0.001$; **: $p < 0.01$; *: $p < 0.05$
 \caption{Modelos de regressão para \emph{commits} que \textbf{aumentam}
 a complexidade estrutural.}
   \label{tab:csmr2012:models:inc}
 \end{table}
 
 @@ -827,7 +932,7 @@ abrangem mais arquivos também são aquelas que introduzem mais
 complexidade estrutural.
 
 Para testar as hipóteses $H_4$ a $H_6$, foram construídos modelos de
 regressão linear similares aos discutidos acima, masmas com a redução de
 complexidade estrutural como variável dependente (e portanto levando
 em consideração apenas os \emph{commits} nos quais a variação de
 complexidade é negativa). A redução de complexidade estrutural foi
 @@ -849,6 +954,8 @@ regressão significativos estão destacados em negrito.
 
 \begin{table}
   \centering
 \caption{Modelos de regressão para \emph{commits} que \textbf{diminuem}
 as complexidade estrutural.}
 % latex table generated in R 2.14.0 by xtable 1.5-6 package
 % Tue Nov  1 18:16:49 2011
 \begin{tabular}{llllr}
 @@ -864,8 +971,6 @@ regressão significativos estão destacados em negrito.
 \end{tabular}\\
 \vspace{0.5em}
 ***: $p < 0.001$; **: $p < 0.01$; *: $p < 0.05$
 \caption{Modelos de regressão para \emph{commits} que \textbf{diminuem}
 as complexidade estrutural.}
   \label{tab:csmr2012:models:dec}
 \end{table}
 
 @@ -884,8 +989,8 @@ aqueles com menores variações de tamanho, ou seja, \emph{commits}
 que incluem um número pequeno de linhas de código ou mesmo que removem
 linhas de código.
 %
 Voldemort também apresentou uma coeficiente significativo para este
 fator, $\Delta{LOC}$, mas estecom coeficiente foi negativo:positivo: neste projeto,
 os \emph{commits} que adicionaram mais linhas de código foram aqueles
 que proporcionaram maiores reduções na complexidade estrutural, o que é
 anti-intuitivo. Talvez os desenvolvedores do projeto tenham conseguido
 @@ -894,14 +999,96 @@ maiores, mas menos acoplados ou mais coesos.
 
 $H_6$ (difusão das mudanças influencia a redução da complexidade
 estrutural positivamente) foi confirmada para Node, Redis e Zeromq2.
 Nossa interpretação é quede que nestes projetos os \emph{commits}
 que afetam mais arquivos são aqueles que causam uma maior redução na
 complexidade estrutural.
 
 \subsection{Ameaças à validade}
 \label{sec:estudo:csmr2012:ameacas}
 
 Apesar de ter sido projetado com cuidado, este estudo não está livre de
 ameaças à sua validade. Checamos o projeto experimental contra a lista
 de ameaças à validade por Wohlin \emph{et al} \cite{wohlin2000} e as
 questões identificadas são relatadas nesta seção.
 
 Com relação à \emph{validade externa}, o fato de terem sido avaliados
 apenas projetos de software livre faz com que não possamos generalizar
 os resultados para projetos de software em geral. Também não podemos
 generalizar para o caso geral de projetos de software livre, uma vez que
 apenas 5 projetos foram analisados e projetos de software livre
 arbitrários também apresentam bastante heterogeneidade entre si.
 
 Com relação à \emph{validade de construção}, uma limitação inerente à
 métrica usada para experiência dos desenvolvedores é o fato dela ser
 monotônica, ou seja, dela sempre crescer e nunca decair. Isto poderia
 ser compensado com a introdução de outra medida representando o grau de
 conhecimento do desenvolvedor com relação ao código, que crescesse na
 medida que o desenvolvedor trabalhe no código, e diminua em períodos de
 inatividade ou quando outros desenvolvedores modificam o código.
 
 Ainda com relação à \emph{validade de construção}, não foi levada em
 consideração a natureza das mudanças introduzidas pelos \emph{commits}:
 o fato de um \emph{commit} representar o conserto de um defeito, a
 implementação de uma nova funcionalidade ou uma refatoração pode fazer
 uma grande diferença. Por exemplo, a natureza da complexidade estrutural
 introduzida pela implementação de uma nova funcionalidade pode ser
 diferente da complexidade estrutural introduzida por uma refatoração.
 Uma refatoração pode aumentar a complexidade estrutural por estar
 introduzindo características típicas de \emph{frameworks}, o que pode
 possibilitar que mudanças futuras sejam realizadas com menores aumentos
 na complexidade estrutural.
 
 Outra ameaça à \emph{validade de construção} é o fato de que
 \emph{commits} que não alteraram a complexidade estrutural -- ou seja,
 aqueles para os quais $\Delta{SC} = 0$ -- não foram incluídos na
 análise. É possível que alguns destes \emph{commits} acabem na realidade
 influenciando futuros \emph{commits} que alteram a complexidade
 estrutural.  Por exemplo, um \emph{commit} que introduz um defeito sério
 pode levar os desenvolvedores a perceber que uma grande refatoração é
 necessária para evitar defeitos semelhantes no futuro.
 %
 Incluir estes \emph{commits} na análise realizada neste estudo não seria
 tão simples, no entanto: como todos eles possuem o mesmo valor para a
 variável dependente ($\Delta{SC} = 0$!), eles não iriam fornecer
 resultados úteis nos modelos de regressão. Precisaríamos de um projeto
 experimental diferente para aproveitar estes dados adicionais.
 
 % changes that spawn several commits
 Outra ameaça à \emph{validade de contrução} é a premissa de que cada
 \emph{commit} representa uma mudança auto-contida. Se houverem mudanças
 lógicas que tenham sido realizadas como uma série de \emph{commits},
 esta informação foi perdida e cada \emph{commit} foi analisado como
 sendo uma mudança independente.
 
 Com relação à \emph{validade de conclusão}, o presente estudo apresenta
 algumas limitações relacionadas à violação de premissas das regressões
 lineares múltiplas realizadas:
 
 \begin{itemize}
   \item Nenhuma das variáveis independentes possui uma distribuição
     normal. Da mesma forma, as variáveis dependentes também não possuem
     distribuição normal.
   \item Os resíduos não são distribuídos normalmente, e na maioria dos
     modelos eles não são homoscedásticos, ou seja, não possuem a mesma
     variância.
   \item Alguns dos modelos apresentam violação de independência dos
     resíduos.
   \item Como a maioria dos modelos apresentaram um baixo coeficiente de
     determinação, é possível que regressão linear não seja uma técnica
     adequada para este estudo.
 \end{itemize}
 
 Outra limitação à \emph{validade de conclusão} é o fato de que não foi
 feito um ajuste nos níveis de significância em função do fato de terem
 sido realizados múltiplos testes de significância \cite{bland1995}. Os
 níveis de significância ($p$) associados a cada coeficiente dos modelos
 de regressão linear deveriam ter sido ajustados, usando por exemplo o
 método de Bonferroni.
 
 \subsection{Conclusões}
 
 O método aplicado neste estudo pode ser usado para suportar decisões de
 atribuição de trabalho em atividades de manuntençãomanutenção de software. Por
 exemplo, gerentes que encontrarem nos seus projetos uma associação entre
 experiência dos desenvolvedores e aumento na complexidade estrutural
 podem querer alocar os desenvolvedores mais experientes para trabalhar
 @@ -918,10 +1105,10 @@ relevantes para o projeto em questão.
 Com relação aos resultados, tiramos importantes lições deste estudo,
 que são discutidas a seguir.
 
 \textbf{Todos os fatores estudados apresentaremapresentaram influência sobre a
 variação da complexidade estrutural em pelo menos 2 modelos de regressão.}
 %
 Isto significasugere que experiência dos desenvolvedores no projeto, variação
 de tamanho e difusão de mudanças devem ser levados em consideração
 quando se estiver monitorando métricas de software para decidir como
 priorizar recursos para revisão de código.
 @@ -957,19 +1144,20 @@ mesmos que influenciam a diminuição.}
 Dependendo dos seus objetivos, gerentes de projeto podem considerar
 conjuntos diferentes de fatores. Se o objetivo principal é evitar o
 crescimento da complexidade estrutural, um conjunto de fatores deve ser
 levandolevado em conta; se o objetivo é trabalhar para reduzir a complexidade
 estrutural, então um conjunto diferente de fatores deve ser trabalhado.
 
 \textbf{Existem\textbf{Provavelmente existem outros fatores influenciando a
 complexidade estrutural que não foram levados em conta neste estudo.}
 %
 Nossos modelos de regressão não alcançaram um coeficiente de
 determinação ($R^2$) alto o suficiente, o que significasuficiente. Isso nos leva a crer que existempodem
 existir outros fatores não abordados neste estudo que influenciam a
 complexidade estrutural e que não foram
 abordados neste estudo.estrutural. Mais pesquisas são necessárias para identificar
 estes fatores.
 
 \section{Refinamento de modelos para evolução da complexidade estrutural}
 \sectionmark{Modelos para evolução da complexidade estrutural}
 \label{sec:estudos:melhores-modelos}
 
 No estudo anterior (conforme visto na seção \ref{sec:estudo:csmr2012}),
 @@ -1013,7 +1201,7 @@ refinamentos nos modelos:
 
 As hipóteses deste estudo estão relacionadas aos refinamentos realizados nos
 modelos para a variação da complexidade estrutural. Estamos interessados
 em identificar se estasestes refinamentos produzem modelos com maior coeficiente
 de determinação. Temos então as seguintes hipóteses:
 
 \begin{description}
 @@ -1047,7 +1235,7 @@ aumentam a complexidade estrutural:
 \begin{description}
 
   \item[$H_4$:]
     A primeira autoria influencia negativamente o aumento nada
     complexidade estrutural.
 
     Desenvolvedores que alteram módulos criados por eles devem ser
 @@ -1097,7 +1285,7 @@ seguintes hipóteses análogas:
     de causar maiores reduções na complexidade estrutural.
 
   \item[$H_{10}$:]
     O número de modificações posteriores influencia positivamenteo a
     redução na complexidade estrutural.
 
     Desenvolvedores modificando módulos que estão acostumados a
 @@ -1167,6 +1355,9 @@ extraídas:
 
 \begin{table}
   \centering
   \caption{Quantidade de \emph{commits} analisados, divididos entre os
   \emph{commits} que aumentam a complexidade estrutural e os que a
   reduzem.}
   \begin{tabular}{lrr}
     \hline
     Projeto   & $\Delta{SC} > 0$ & $\Delta{SC} < 0 $  \\
 @@ -1178,9 +1369,6 @@ extraídas:
     zeromq2   & 77               & 63                 \\
     \hline
   \end{tabular}
   \caption{Quantidade de \emph{commits} analisados, divididos entre os
   \emph{commits} que aumentam a complexidade estrutural e os que a
   reduzem.}
   \label{tab:melhores-modelos:quantidade-de-commits}
 \end{table}
 
 @@ -1239,7 +1427,7 @@ são introduzidos os termos que compõem o grau de autoria.
   M_4:
   \Delta{SC} =
   \alpha_0 +
   \alpha_1 EExp +
   \alpha_2 FA +
   \alpha_3 DL +
   \alpha_4 AC +
 @@ -1258,22 +1446,22 @@ $M_3$ e $M_4$.
 
 \begin{table}
   \centering
   \caption{
     Diferenças nos coeficientes de determinação dos novos modelos em
     comparação ao modelo original $M_1$, entre os \emph{commits} que
     aumentam a complexidade estrutural.
   }
   \begin{tabular}{lr|r|r|r}
     \hline
     Projeto   & $R^2_{M_1}$ & $R^2_{M_2} - R^2_{M_1} (H_1) $ & $R^2_{M_3} - R^2_{M_1} (H_2) $ & $R^2_{M_4} - R^2_{M_1} (H_3)$ \\
     \hline
     clojure & 0.08 & -0.000.00 & 0.02 & 0.02 \\
     node & 0.14 & 0.01 & 0.20 & 0.21 \\
     redis & 0.82 & 0.11 & 0.02 & 0.11 \\
     voldemort & 0.47 & 0.18 & 0.04 & 0.18 \\
     zeromq2 & 0.20 & 0.10 & -0.000.00 & 0.13 \\
     \hline
   \end{tabular}
   \caption{
     Diferenças nos coeficientes de determinação dos novos modelos em
     comparação ao modelo original $M_1$, entre os \emph{commits} que
     aumentam a complexidade estrutural.
   }
   \label{tab:melhores-modelos:r2:aumentam}
 \end{table}
 
 @@ -1283,47 +1471,50 @@ testados para os commits que aumentam a complexidade estrutural,
 arredondados para 2 casas decimais. Neste estudo, consideramos como
 significativas diferenças de pelo menos 0.05.
 
 Pode-seNa tabela \ref{tab:melhores-modelos:r2:aumentam}, pode-se verificar que
 $M_2$  obteve um desempenho significantementecoeficiente de determinação melhor do que $M_1$ em 3
 dos 5 projetos: Redis, Voldemort e Zeromq2.
 %
 $M_3$ superou $M_1$ em apenas 1 dos 5 projetos: Node.
 %
 Finalmente, $M_4$ forneceu os melhores resultados, com um coeficiente de
 determinação significativamente melhor do que $M_1$ em 4 dos 5 projetos:
 apenas para Clojure $M_4$ não obteve uma melhora significativa no
 desempenho.coeficiente de determinação. Com relação à magnitude dessas melhorias,
 $M_4$ conseguiu melhorias entre 0.11 e 0.21 no coeficiente de
 determinação.
 
 \begin{table}
   \centering\begin{tabular}{lr|r|r|r}\centering
   \caption{
     Diferenças nos coeficientes de determinação dos novos modelos em
     comparação ao modelo original $M_1$, entre os \emph{commits} que
     reduzem a complexidade estrutural.
   }
   \begin{tabular}{lr|r|r|r}
     \hline
     Projeto   & $R^2_{M_1}$ & $R^2_{M_2} - R^2_{M_1} (H_1) $ & $R^2_{M_3} - R^2_{M_1} (H_2) $ & $R^2_{M_4} - R^2_{M_1} (H_3)$ \\
     \hline
     clojure & 0.43 & -0.000.00 & 0.26 & 0.26 \\
     node & 0.06 & -0.01 & -0.02 & -0.02 \\
     redis & 0.23 & -0.01 & 0.13 & 0.14 \\
     voldemort & 0.05 & -0.01 & 0.02 & 0.02 \\
     zeromq2 & 0.44 & -0.000.00 & 0.04 & 0.05 \\
     \hline
   \end{tabular}
   \caption{
     Diferenças nos coeficientes de determinação dos novos modelos em
     comparação ao modelo original $M_1$, entre os \emph{commits} que
     reduzem a complexidade estrutural.
   }
   \label{tab:melhores-modelos:r2:diminuem}
 \end{table}
 
 A tabela \ref{tab:melhores-modelos:r2:diminuem} apresenta os resultados
 relativos aos \emph{commits} que reduzem a complexidade estrutural.
 
 $M_2$ não obteve um desempenho significantemente melhor do que $M_1$ em
 nenhum dos projetos.
 %
 $M_2$ não obteve um coeficiente de determinação significantemente melhor
 do que $M_1$ em nenhum dos projetos.
 %
 $M_3$ obteve melhor desempenhocoeficiente de determinação em 2 dos 5 projetos,
 Clojure e Node.  No caso de Node, o coeficiente de determinação obtido
 por $M_3$ $R^2$ foi menor do que o do o do modelo original $M_1$, mas
 não é uma diferença considerada significativa neste estudo.
 %
 $M_4$ novamente apresentou os melhores resultados. $M_4$ foi
 significativamente superior a $M_1$ em 3 dos 5 projetos (Clojure, Redis
 @@ -1335,6 +1526,7 @@ porém a diferença não é considerada significativa neste estudo.
 \def\y{\ding{51}}
 \begin{table}
   \centering
   \caption{Resumo dos resultados para $H1$, $H_2$ e $H_3$}
   \begin{tabular}{lccc|ccc}
     & \multicolumn{3}{c}{$\Delta{SC} > 0$} & \multicolumn{3}{c}{$\Delta{SC} < 0$} \\
     \hline
 @@ -1347,7 +1539,6 @@ porém a diferença não é considerada significativa neste estudo.
     zeromq2   &  \y   &       &   \y  &       &       &   \y    \\
     \hline
   \end{tabular}
   \caption{Resumo dos resultados para $H1$, $H_2$ e $H_3$}
   \label{tab:melhores-modelos:resumo-h1-h2-h3}
 \end{table}
 
 @@ -1371,10 +1562,9 @@ aumentos na complexidade estrutural.
 $H_5$ (o número de modificações posteriores influencia negativamente o
 aumento na complexidade estrutural) não foi confirmada.
 %
 Clojure apresentou um coeficiente significativo, mas com valor zero, o que pode ser interpretado como ``temos certeza quezero. Na
 nossa interpretação, o número de modificações posteriores \textbf{não}
 influencia o aumento da complexidade estrutural.
 %
 Zeromq2 apresentou um coeficiente positivo, o que contradiz a nossa
 hipótese. Os desenvolvedores que realizaram mudanças em módulos que eles
 @@ -1394,8 +1584,10 @@ aumento na complexidade estrutural) foi confirmada para 3 dos 5
 projetos: Redis, Voldemort e Zeromq2.
 
 \begin{table}
   \footnotesize
   \centering
   \caption{Regressões lineares para \emph{commits} que aumentam a
   complexidade estrutural}
   \footnotesize
   \begin{tabular}{lllll}
     \hline
     Projeto   & Exp                   & FA ($H_4$)            & DL ($H_5$)            & AC ($H_6$)        \\
 @@ -1417,17 +1609,13 @@ projetos: Redis, Voldemort e Zeromq2.
   \end{tabular}
   \\\vspace{0.5em}
   ***: $p < 0.001$; **: $p < 0.01$; *: $p < 0.05$
   \caption{Regressões lineares para \emph{commits} que aumentam a
   complexidade estrutural}
   \label{tab:melhores-modelos:commits-que-aumentam}
 \end{table}
 
 %%%Retirei "já"
 Os resultados relativos aos \emph{commits} que reduzem a complexidade
 estrutural são apresentados na tabela
 \ref{tab:melhores-modelos:commits-que-reduzem} e descritos a seguir.
 
 
 $H_9$ (a primeira autoria influencia positivamente a redução na
 complexidade estrutural) foi confirmada apenas para Clojure. Naquele
 projeto, as mudanças realizadas por desenvolvedores que foram os autores
 @@ -1462,8 +1650,10 @@ redução na complexidade estrutural) não foi confirmada em nenhum dos
 projetos.
 
 \begin{table}
   \footnotesize
   \centering
   \caption{Regressões lineares para \emph{commits} que reduzem a
   complexidade estrutural}
   \footnotesize
   \begin{tabular}{lllll}
     \hline
     Projeto   & Exp       & FA ($H_9$)             & DL  ($H_{10}$)       & AC ($H_{11}$)         \\
 @@ -1485,11 +1675,16 @@ projetos.
   \end{tabular}
   \\\vspace{0.5em}
   ***: $p < 0.001$; **: $p < 0.01$; *: $p < 0.05$
   \caption{Regressões lineares para \emph{commits} que reduzem a
   complexidade estrutural}
   \label{tab:melhores-modelos:commits-que-reduzem}
 \end{table}
 
 \subsection{Ameaças à validade}
 
 Por se tratar de uma extensão do estudo apresentado na seção anterior,
 este estudo compartilha todas as suas ameaças à validade, apresentadas
 na seção \ref{sec:estudo:csmr2012:ameacas}.
 
 
 \subsection{Conclusões}
 
 A tabela \ref{tab:melhores-modelos:resumo-h4-h13} apresenta um resumo
 @@ -1503,7 +1698,7 @@ hipóteses foram confirmadas em mais de 1 projeto, a saber:
     %olhar acomplamento médio? fan-in, fan-out?
   \item
     $H_{10}$: o número de modificações posteriores influencia
     positivamenteo a redução na complexidade estrutural.
   \item
     $H_{11}$: o número de modificações por outros desenvolvedores
     influencia negativamente a redução na complexidade estrutural.
 @@ -1511,6 +1706,8 @@ hipóteses foram confirmadas em mais de 1 projeto, a saber:
 
 \begin{table}
   \centering
   \caption{Resumo sobre as hipóteses relacionadas à influência dos
   diversos fatores sobre a variação na complexidade estrutural}
   \begin{tabular}{lcccccccccc}
     \hline
     Projeto   & $H_{4}$ & $H_{5}$ & $H_{6}$ & $H_{7}$ & $H_{8}$ & $H_{9}$ & $H_{10}$ & $H_{11}$ & $H_{12}$ & $H_{13}$ \\
 @@ -1522,8 +1719,6 @@ hipóteses foram confirmadas em mais de 1 projeto, a saber:
     zeromq2   &         &         &         &   \y    &   \y    &         &          &          &          &          \\
     \hline
   \end{tabular}
   \caption{Resumo sobre as hipóteses relacionadas à influência dos
   diversos fatores sobre a variação na complexidade estrutural}
   \label{tab:melhores-modelos:resumo-h4-h13}
 \end{table}
 
 @@ -1533,6 +1728,8 @@ complexidade estrutural em cada projeto, apresentados na tabela
 
 \begin{table}
   \centering
   \caption{Resumo dos fatores que influenciam a variação da complexidade
   estrutural em cada projeto}
   \begin{tabular}{l|ll|ll}
     \hline
     Projeto   & Fatores para $\Delta{SC} > 0$ & $R^2$ & Fatores para $\Delta{SC} < 0$ & $R^2$ \\
 @@ -1544,8 +1741,6 @@ complexidade estrutural em cada projeto, apresentados na tabela
     zeromq2   & $DL$, $AM$                    & 0.33  & $DL$, $\Delta{LOC}$           & 0.48  \\
     \hline
   \end{tabular}
   \caption{Resumo dos fatores que influenciam a variação da complexidade
   estrutural em cada projeto}
   \label{tab:melhores-modelos:resumo-fatores}
 \end{table}
 
 @@ -1576,3 +1771,157 @@ variabilidade na complexidade estrutural destes projetos que não pode
 ser explicada com as variáveis que utilizamos até agora, e que ainda é
 necessário identificar outros fatores que influenciam a variação da
 complexidade estrutural naqueles projetos.
 \section{Conclusões}
 \label{sec:estudos:conclusao}
 
 Uma das principais preocupações deste trabalho foi identificar os
 fatores que poderiam ser considerados como causa da complexidade
 estrutural.  Uma vez conhecidos os fatores que influenciam o aumento e a
 diminuição da complexidade estrutural, gerentes de projeto podem
 adicionar aos seu processos atividades para contenção da complexidade
 estrutural, de forma que a manutenção futura do sistema seja menos
 custosa.
 
 Conforme discutido no capítulo \ref{cap:fatores}, identificamos três
 grupos de fatores candidatos a influenciar a complexidade estrutural em
 sistemas de software: fatores relacionados aos desenvolvedores
 envolvidos no projeto, fatores relacionados à manutenção do sistema, e
 fatores relacionados à organização desenvolvedora de software.
 %
 Neste trabalho, exploramos fatores dos dois primeiros grupos
 (desenvolvedores e manutenção) em uma série de estudos experimentais
 descritos ao longo deste capítulo.
 
 \textbf{Experiência no projeto} foi utilizada em dois estudos,
 descritos nas seções \ref{sec:estudo:csmr2012} e
 \ref{sec:estudos:melhores-modelos}. No primeiro estudo, a experiência no
 projeto teve uma influência significativa em 1 modelo de 5 no caso de
 \emph{commits} que aumentavam a complexidade, e em 1 de 5 no caso de
 \emph{commits} que reduziam a complexidade. No segundo estudo, a
 experiência no projeto teve uma influência significativa em 1 de 5
 modelos para \emph{commits} que aumentavam a complexidade e 2 de 5 para
 \emph{commits} que reduziam a complexidade estrutural.
 
 \textbf{Grau de autoria} foi introduzido no estudo descrito na seção
 \ref{sec:estudos:melhores-modelos}, e teve seus 3 componentes (autoria
 inicial -- $FA$, alterações subsequentes -- $DL$ e alterações por outros
 desenvolvedores -- $AC$) usados como fatores independentes.
 %
 Autoria inicial ($FA$) foi significativa em 1 dos 5 modelos para \emph{commits}
 que aumentavam a complexidade, e em 2 de 5 modelos para \emph{commits}
 que reduziam a complexidade estrutural.
 %
 Alterações subsequentes ($DL$) foi significativa em 1 dos 5 modelos para
 \emph{commits} que aumentavam a complexidade, e em 3 de 5 modelos para
 \emph{commits} que reduziam.
 %
 Alterações por outros desenvolvedores ($AC$) foi significativa em 1 dos
 5 modelos para \emph{commits} que aumentavam a complexidade, e em 2 de 5
 modelos para \emph{commits} que reduziam.
 %
 Vale notar que os componentes do grau de autoria foram significativos
 mais vezes entre os \emph{commits} que reduziam a complexidade do que no
 caso dos \emph{commits} que aumentavam a complexidade.
 
 \textbf{Nível de participação} foi utilizado no estudo descrito na
 seção \ref{sec:estudo:sbes2010} para classificar os autores dos
 \emph{commits} entre desenvolvedores centrais ou periféricos, e
 verificou-se que, em geral, %ou no contexto do estudo?
 os desenvolvedores centrais introduziam menos
 -- e removiam mais -- complexidade do que os periféricos. No entanto,
 como o nível de participação não foi utilizado na construção dos modelos
 de regressão linear, não podemos verificar em que parcela dos caso ele
 se aplicaria.
 
 \textbf{Variação de tamanho} se mostrou como um fator importante no
 estudo da variação da complexidade estrutural. Em ambos os estudos onde
 foi utilizada (seções \ref{sec:estudo:csmr2012} e
 \ref{sec:estudos:melhores-modelos}), a variação de tamanho influenciou
 significativamente a variação na complexidade em 3 de 5 modelos para
 \emph{commits} que aumentavam a complexidade, e em 2 de 5 modelos para
 \emph{commits} que reduziam a complexidade.
 
 \textbf{Difusão de mudança} também foi um fator influente em uma
 grande quantidade de casos. No primeiro estudo
 (\ref{sec:estudo:csmr2012}), ele foi significativo em 4 entre 5 modelos
 para \emph{commits} que aumentavam a complexidade, e em 3 entre 5
 modelos para \emph{commits} que reduziam a complexidade.
 %
 No segundo estudo, a difusão de mudança foi estudada separadamente a
 partir de módulos alterados ($CM$) e módulos adicionados ($AM$).
 %
 Verificou-se então que $CM$ foi significativo em 1 dos 5 modelos para
 \emph{commits} que aumentavam a complexidade, e em 2 entre 5 modelos
 para os \emph{commits} que reduziam a complexidade.
 %
 $AM$ foi significativo em 3 entre 5 modelos para \emph{commits} que
 aumentavam a complexidade, e não foi significativo em nenhum dos 5 modelos
 para os \emph{commits} que reduziam a complexidade.
 
 Podemos usar a frequência com que cada fator foi significativo como uma
 métrica que indique a relevância deste fator no estudo da variação da
 complexidade estrutural.
 %
 Dessa forma, pode-se priorizar os fatores durante o planejamento de
 estudos futuros.
 %
 Também é possível que gerentes de projeto utilizem essa métrica para
 priorizar a implantação de medições desses fatores nos seus projetos.
 
 \begin{figure}
   \begin{center}
     \includegraphics[width=1\textwidth]{figuras/fatores-aumentam}
   \end{center}
   \caption{
     Fatores em ordem de relevância para \emph{commits} que
     aumentam a complexidade estrutural.
   }
   \label{fig:discussao:fatores:aumentam}
 \end{figure}
 
 A figura \ref{fig:discussao:fatores:aumentam} apresenta os fatores em
 ordem crescente de frequência, para \emph{commits} que aumentam a
 complexidade estrutural. Pode-se ver que os fatores mais frequentes
 foram $\Delta{LOC}$ e $AM$. Em atividades cujo objetivo seja
 controlar o aumento da complexidade estrutural, esses dois fatores podem
 ser priorizados em relação aos demais.
 
 Entre os \emph{commits} que aumentam a complexidade, pode-se notar que
 todos os fatores humanos (experiência e os componentes do grau de
 autoria $FA$, $DL$ e $AC$) foram significativos em apenas um projeto.
 %Já
 Fatores relacionados à evolução/manutenção do sistema ($\Delta{LOC}$ e
 módulos adicionados, $AM$) foram significativos em 3 projetos dos 5
 analisados.
 
 \begin{figure}
   \begin{center}
     \includegraphics[width=1\textwidth]{figuras/fatores-reduzem}
   \end{center}
   \caption{
     Fatores em ordem de relevância para \emph{commits} que
     reduzem a complexidade estrutural.
   }
   \label{fig:discussao:fatores:reduzem}
 \end{figure}
 
 Os fatores que influenciam a variação da complexidade estrutural para os
 \emph{commits} que a reduzem são representados na figura
 \ref{fig:discussao:fatores:reduzem}. %Como podemos ver, 
 $DL$ foi o fator
 mais relevante nos estudos realizados. Gestores implantando atividades
 com objetivo de reduzir a complexidade estrutural podem priorizar a
 alocação de desenvolvedores às áreas do projeto nas quais eles estão
 acostumados a realizar mudanças.
 
 Podemos notar que no caso da redução de complexidade, o fator que foi
 significativo mais vezes foi um fator humano: o número de alterações
 prévias ($DL$). Também é válido notar que nesse caso, os demais fatores
 humanos -- experiência e os outros componentes do grau de autoria --
 foram significativos no mesmo número de projetos que fatores relacionados à
 evolução/manutenção, como $\Delta{LOC}$ e número de módulos modificados
 ($CM$).
 
 O capítulo seguinte descreve apresenta uma teoria que relaciona causas e
 consequências da complexidade estrutural em projetos de software livre.
 Esta teoria sintetiza os resultados experimentais obtidos com este trabalho.
 diff --git a/05-teoria.tex b/06-teoria.tex
 similarity index 58%
 rename from 05-teoria.tex
 rename to 06-teoria.tex
 index 2edd72f..d7756c1 100644
 --- a/05-teoria.tex
 +++ b/06-teoria.tex
 @@ -1,11 +1,20 @@
 \chapter{Uma\xchapter{Uma Teoria para a Complexidade Estrutural em Projetos de
 Software}Software Livre}{
   Este capítulo apresenta uma teoria proposta para sintetizar os
   resultados obtidos nesta tese. Esta teoria busca principalmente
   identificar causas e consequências da complexidade estrutural em
   sistemas de software livre.
 }
 \chaptermark{Teoria}
 \label{cap:teoria}
 
 %%fakesection Preambulo
 Este capítulo apresenta uma teoria para a complexidade estrutural em
 projetos de software,software livre, construída utilizando a metodologia proposta
 por Sjøberg Dybå, Anda, e Hannay \cite{sjoberg2008}.  Esta teoria
 relaciona possíveis causas e consequências da complexidade estrutural no
 contexto de projetos de software livre, e foi formulada como uma síntese
 dos resultados obtidos neste trabalho.
 
 O restante deste capítulo está organizado da seguinte forma: a
 seção~\ref{sec:teorias} introduz os conceitos fundamentais sobre teorias
 @@ -15,6 +24,8 @@ complexidade estrutural em projetos de software aqui proposta.  Os
 construtos, proposições e explicações, e escopo da teoria proposta são
 apresentados em detalhe nas seções~\ref{sec:teoria:construtos},
 \ref{sec:teoria:preposicoes} e \ref{sec:teoria:escopo}, respectivamente.
 A seção \ref{sec:teoria:avaliacao} conclui o capítulo realizando uma
 avaliação da teoria proposta.
 
 \section{Teorias em Engenharia de Software} 
 \label{sec:teorias}
 @@ -74,7 +85,7 @@ situações que seguem o padrão  ``um \emph{ator} aplica
 \emph{tecnologias} para desempenhar \emph{atividades} em um
 \emph{sistema de software}''.  Os conceitos acima destacados (ator,
 tecnologia, atividade e sistema de software) são chamados de ``classes
 arquetípicas''.arquetípicas'' ou ``arquétipos''.
 %
 Os autores sugerem que os elementos representados na teoria sejam
 associados a essas classes arquetípicas por meio de especialização e
 @@ -90,7 +101,7 @@ Os construtos numa teoria em Engenharia de Software usualmente estão
 associados a elementos que são, ou compõem, \emph{atores},
 \emph{tecnologias}, \emph{atividades}, ou \emph{sistemas de software}.
 
 \section{Visão geral da teoria proposta}
 \label{sec:teoria}
 
 O objetivo principal da teoria proposta é identificar as causas e
 @@ -114,21 +125,24 @@ software}
 
 A figura \ref{fig:teoria} traz uma representação gráfica da teoria
 proposta neste trabalho. A representação usa a notação proposta por
 Sjøberg et al.,\emph{et al.},  parcialmente baseada em diagramas de classe da UML.
 
 Os construtos presentes na teoria são representados por classes ou
 atributos de classe. Uma classe pode ser uma subclasssubclasse de outra, e nesse
 caso elas são conectadas pela seta de herança da UML. Por exemplo,
 ``Projeto de Software''Software Livre'' é um tipo de ator na teoria, e isso é
 representado no diagrama fazendo de ``Projeto de Software Livre'' uma
 subclasse da classclasse arquétipo ``Ator''.
 
 Uma classeUm construto também pode serum componente de outra, e esseoutro construto. Por exemplo,
 na teoria proposta, um desenvolvedor faz parte de um projeto de software
 livre. No diagrama, este fato é representado por umaapresentando a classedentro de outra, na parte superior da caixa.
 Por exemplo,
 ``Desenvolvedor'' é um componente decomo uma classe interna à classe ``Projeto de Software''.Software
 Livre''.
 
 Se um construto écorresponde a um valor específico de uma variável, isto
 é modelado como uma subclasse, e.g. a subclasse ``Médio porte, Software
 de infraestrutura'' da classe ``Sistema de Software''. Já no caso de
 construtos para os quais se está interessado na variação de valores de
 uma determinada variável, então o construto é representado por um
 atributo de uma classe e colocado na parte de baixo da caixa onde a
 @@ -144,9 +158,10 @@ proposição ``$A$ influencia $B$''.
 
 Na teoria proposta, os atores principais são \emph{Projetos de
 Software}, entendidos enquanto organizações de pessoas cujo objetivo é
 produzir, manter ou evoluir sistemas de software.software livre.
 
 Construtos relacionados aos projetos de software livre são:
 
 Construtos relacionados a projetos de software são:
 \begin{description}
   \item[Nível de maturidade]
     indica o nível de maturidade da organização onde o projeto é
 @@ -154,24 +169,30 @@ Construtos relacionados a projetos de software são:
     como por exemplo, CMMI (\emph{Capability Maturity Model
     Integration}) \cite{cmmi}, MPS-BR (Melhoria do Processo de Software
     Brasileiro) \cite{mpsbr} e, para projetos de software livre, OMM
     (\emph{Open Source Maturity Model} \cite{omm}. Estes modelos cobrem
     diferentes aspectos das organizações. Por exemplo, o MPS-BR cobre o
     contexto específico de organizações desenvolvedoras de software
     brasileiras, enquanto o OMM envolve questões específicas de projetos
     de software livre, cujas organizações são substancialmente
     diferentes do que tradicionalmente se considera como uma organização
     desenvolvedora de software.  Este construto foi descrito na seção
     \ref{sec:fatores:maturidade}.
 
   \item[Estrutura Organizacional]
     na qual o projeto é desenvolvido. Determinadas estuturas
     organizacionais podem facilitar o desenvolvimento e a manutenção do
     projeto, e outras podem dificultar. Este construto foi descrito na
     seção \ref{sec:fatores:estrutura-organizacional}.
 
   \item[Custo]
     do projeto. O custo normalmente é considerado como uma função do
     esforço necessário para realizar as atividades do projeto, e pode
     ser mensurado em ``homens-hora''.``homens-hora'', ``recursos'', etc.  O custo de um
     projeto é um dos principais fatores considerados na análise de sua
     viabilidade \cite{pressman2009}.
 \end{description}
 
 Projetos de software livre são compostos por \emph{desenvolvedores},
 relacionados aos seguintes construtos:
 
 \begin{description}
 @@ -194,32 +215,28 @@ relacionados aos seguintes construtos:
 
   \item[Nível de Participação]
     indica o grau de envolvimento de um desenvolvedor e a sua posição
     social num projeto, em especial em projetosprojeto de software livre \cite{crowston2005}.
     Desenvolvedores centrais (\emph{core}) são aqueles que desempenham a
     maior parte da atividade do projeto e usualmente possuem maior poder
     de decisão no projeto.  Desenvolvedores periféricos fazer
     contribuições esporádicas e exercem menor influência sobre os rumos
     do projeto.
     %
     Este construto foi descrito na seção
     \ref{sec:fatores:core-periferia}.
 \end{description}
 
 \emph{Mudanças} são\emph{Manutenção} é uma atividades na quaisqual os desenvolvedores alteram umrealizam
 mudanças num sistema de software. Os resultados desta atividade ficam
 registrados em sistemas de controle de versão, etambém nos referimos a estes registroseles
 comomudanças (ou \emph{commits}, \emph{checkins}, etc). Desta forma, a
 depender do contexto, \emph{mudança} pode se referir ao ato de alterar
 um sistema de software, ou ao resultado deste ato. Em geral, neste
 trabalho, quando nos referimos a \emph{mudanças}, estamos nos referindo
 simultaneamte ao ato e ao seu efeito.etc.
 
 Em alguns casos, as mudanças realizadas alteram a arquitetura do
 sistema, e o fazem ficar mais ou menos complexo. Outras mudanças não
 alteram a estrutura do sistema, e portanto não possuem qualquer efeito
 sobre a complexidade estrutural.
 
 Os seguintes construtos são atributos das mudanças.estão associados à atividade de manutenção:
 
 \begin{description}
   \item[Variação de Tamanho]
 @@ -249,33 +266,29 @@ Os seguintes construtos são atributos das mudanças.
     num sistema, maior será o seu custo de manutenção.
 \end{description}
 
 \emph{Compreensão} é uma atividade que faz parte da atividade de
 manutenção. Desenvolvedores e pesquisadores afirmam que, de 40\%  a 60\%Uma parte considerável do esforço de manutenção é dedicado à
 compreensão do software a ser modificado.
 %
 Antes de realizar uma mudança em um sistema de software como parte de
 uma atividade de manutenção, o desenvolvedor precisa entender o sistema
 em termos da sua estrutura e funcionamento, formar um modelo mental do
 sistema, e então decidir como exatamente essa mudança precisa ser
 realizada de forma a atingir os objetivos da manutenção%A manutenção pode ter como objetivo, -- por exemplo,
 adicionar uma nova funcionalidade, consertar um defeito ou tornar uma
 determinada parte do sistema mais flexível para mudanças futuras.
 
 O seguinte construto está associado à atividade de compreensão:
 
 \begin{description}
   \item[Esforço] necessário para a realização de uma atividade de
     manutençãocompreensão está relacionada a diversos fatores, tais como tamanho,
     complexidade, familiaridade do desenvolvedor com o sistema e com o
     domínio da aplicação, etc.
 \end{description}
 
 Por fim, o construto principal da teoria proposta está relacionado a
 \emph{Sistemas de Software}:Software Livre}:
 
 \begin{description}
   \item[Complexidade estrutural]
 @@ -285,7 +298,7 @@ Por fim, o construto principal da teoria proposta está relacionado a
     descrita no capítulo \ref{cap:complexidade-estrutural}.
 \end{description}
 
 \section{Proposições e explicações}
 \label{sec:teoria:preposicoes}
 
 A seguir são listadas as proposições que compõem a teoria proposta,
 @@ -335,9 +348,8 @@ juntamente com suas respectivas explicações.
 
     \explicacao
     A adição de código -- para incluir novas funcionalidades ou corrigir
     defeitos -- além de tornar o sistema maior, necessariamentepode também torna o torna mais complexo.torná-lo Já
     uma redução no tamanho do sistema torna-otente a torná-lo menos complexo.
 
   \item[P5]
     A difusão de uma mudança influencia a variação na complexidade
 @@ -357,10 +369,10 @@ juntamente com suas respectivas explicações.
     \explicacao
     Mudanças caracterizadas como correções tendem a ser localizadas e
     portanto, não alteram significantemente a organização dos elementos
     do software e a complexidade estrutural. Já mudanças que modificam a
     arquitetura do sistema -- caracterizadas como melhorias, que
     modificam o  comportamento do sistema ou a sua implementação,implementação --
     podemmodificar
     também a sua arquitetura e portanto alterar a sua complexidade estrutural.
 
   \item[P7]
     A complexidade estrutural influencia positivamente o esforço
 @@ -383,7 +395,7 @@ juntamente com suas respectivas explicações.
 
     \explicacao
     Antes de realizar uma mudança sobre um sistema de software, o
     desenvelvedordesenvolvedor precisa primeiramente compreender o sistema. Desta
     forma, um aumento no esforço para compreensão acarreta um aumento no
     esforço necessário para realizar atividades de manutenção.
 
 @@ -405,14 +417,14 @@ juntamente com suas respectivas explicações.
     software.
 
     \explicacao
     Organizações com nível mais altonível de maturidade possuem processos e
     práticas padronizados para lidar com as mudanças, de forma a poder
     realizá-las com menor impacto sobre a qualidade interna e
     possivelmente, a complexidade estrutural do software.
 
   \item[P11]
     A estrutura organizacional onde um projeto é desenvolvido influencia
 influencia    as mudanças realizadas num sistema de software
 
     \explicacao
     Determinadas estruturas organizacionais proporcionam uma comunicação
 @@ -420,7 +432,7 @@ juntamente com suas respectivas explicações.
     responsabilidades do projeto facilita o processo de desenvolvimento,
     e portanto deve levar a uma melhor qualidade interna.  Já outras
     estruturas organizacionais podem se mostrar inadequadas e dificultar
     o trabalho dos desenvolvedores edesenvolvedores, não contribuicontribuindo para uma melhor
     qualidade interna.
 
 \end{description}
 @@ -442,10 +454,12 @@ são consideradas axiomas. Isto é, elas são assumidas como verdadeiros
 dentro do nosso domínio de análise, e servem de ponto de partida para
 inferir outros fatos na nossa teoria.
 
 P6, P10 e P11 não puderam ser exploradas nesta tese.tese devido a restrições
 de tempo.
 
 \begin{table}
   \centering
   \caption{Situação das proposições com relação à sua validação}
   \begin{tabular}{ll}
     \hline
     \textbf{Proposição} & \textbf{Situação} \\
 @@ -463,42 +477,203 @@ P6, P10 e P11 não puderam ser exploradas nesta tese.
     P11                 & Não explorada  \\
     \hline
   \end{tabular}
   \caption{Situação das proposições com relação à sua validação}
   \label{tab:proposicoes}
 \end{table}
 
 \section{Escopo da teoria}
 \label{sec:teoria:escopo}
 
 Ainda que essa teoria possa a princípio ser aplicada a qualquer tipo de
 projeto, é preciso explicitar o contexto em que ela está sendo testada
 nesta tese.
 
 Os estudos experimentais foram realizados com dados de projetos de
 software livre, o que faz com que os resultados não sejam generalizáveis
 para projetos de software em geral. Como o rótulo de ``projeto de
 software livre'' não implicaem nenhuma metodologia ou ferramenta,ferramenta
 específica, os resultados também naonão podem ser generalizados diretamente
 para projetos de software livre em geral.Ainda que neste trabalho tenhamos focado em projetos de software livre,
 o único construto da teoria que é específico de projetos de software
 livre é o Nível de Participação, e por consequência a única proposição
 que é específica para projetos de software livre é P1.
 %
 No entanto, em projetos de software proprietário onde haja rotatividade
 de desenvolvedores e desenvolvedores com diferentes dedicações, é
 possível aplicar o conceito de nível de participação de forma
 análoga ao caso de projetos de software livre.
 
 Além disso, em função das limitações da ferramenta de análise de código
 fonte utilizada, os projetos analisados se limitaram a sistemas escritos
 em C, C++ e Java.
 
 Os critérios de seleção de projetos para os estudos experimentais
 implicaram em restrições (não premeditadas) ao escopo em que a teoria
 foi testada.
 %
 Com relação a domínios de aplicação, normalmente este trabalho se ateve
 à análise dea grande maioria dos projetos
 analisados são classificados como software de infraestrutura, como
 servidores web, compiladores, sistemas de bancos de dados etc.
 %
 Com relação ao tamanho, os sistemas analisados são de médio porte,
 contendo até 35.000 linhas de código.
 
 \section{Avaliação da Teoria}
 \label{sec:teoria:avaliacao}
 
 Segundo Sjøberg, Dybå, Anda, e Hannay \cite{sjoberg2008}, uma teoria em
 Engenharia de Software deve ser avaliada em termos dos critérios
 descritos a seguir.
 
 \textbf{Testabilidade.}
 O quanto a teoria é formulada de forma a permitir refutação
 experimental.
 
 \textbf{Suporte experimental.}
 O quanto a teoria é suportada por estudos experimentais que
 confirmam a sua validade.
 
 \textbf{Poder de explicação.}
 O quanto a teoria abrange, e até que ponto ela prediz todas as
 observações dentro do seu escopo. Também, o quanto a teoria é
 simples, contém poucas premissas arbitrárias, e está relacionada ao
 que já se sabe.
 
 \textbf{Parsimônia.}
 O quanto a teoria é formulada de forma econômica, com um mínimo de
 conceitos e proposiçoes.
 
 \textbf{Generalidade.}
 A amplitude do escopo da teoria, e o quanto ela é independente de
 situações específicas.
 
 \textbf{Utilidade.}
 O quanto a teoria dá suporte a questões relevantes para a indústria de
 software.
 
 A teoria sobre a complexidade estrutural em sistemas de software
 proposta neste trabalho foi avaliada de acordo com cada um dos critérios
 colocados acima. Essa avaliação, no entanto, foi realizada pelo próprio
 autor deste trabalho, o que representa uma ameça à sua validade.  Um
 resumo desta avaliação é apresentado na tabela
 \ref{tab:discussao:teoria:avaliacao}.
 
 \begin{table}
   \centering
   \caption{Resumo da avaliação da teoria proposta}
   \begin{tabular}{ll}
     \hline
     \textbf{Critério}     & \textbf{Avaliação} \\
     \hline
     Testabilidade         & Alta               \\
     Suporte experimental  & Baixo              \\
     Poder de explicação   & Baixo              \\
     Parcimônia            & Média              \\
     Generalidade          & Baixa              \\
     Utilidade             & Alta               \\
     \hline
   \end{tabular}
   \label{tab:discussao:teoria:avaliacao}
 \end{table}
 
 \textbf{Testabilidade.}
 Todos os construtos presentes na teoria são claros e precisos, de forma
 que são imediatamente compreensíveis e não ambíguos.
 %
 A partir das proposições colocadas na figura \ref{fig:teoria} (capítulo
 \ref{cap:teoria}, página \pageref{fig:teoria}) podemos facilmente
 deduzir hipóteses para teste experimental.
 %
 O escopo definido para a teoria está colocado claramente.
 %
 Portanto, consideramos a testabilidade da teoria como \emph{alta}.
 
 \textbf{Suporte experimental.}
 %
 A tabela \ref{tab:discussao:suporte-experimenal} apresenta o suporte
 experimental para as proposições presentes na teoria.
 
 P1 (\emph{Nível de participação influencia a complexidade estrutural}) foi
 confirmada no estudo descrito na seção~\ref{sec:estudo:sbes2010}.
 
 O estudo apresentado na seção \ref{sec:estudo:csmr2012} apresentou
 suporte experimental para P2 (\emph{Experiência do desenvolvedor no projeto
 influencia a complexidade estrutural}) em 2 de 10 casos, P4 (\emph{Variação de
 tamanho influencia complexidade estrutural}) em 5 de 10 casos, e P5
 (\emph{Difusão de mudanças influencia a complexidade estrutural}) em 7 de 10
 casos.
 
 O estudo apresentado na seção \ref{sec:estudos:melhores-modelos} nos
 forneceu evidência experimental para P3 (\emph{Grau de autoria do
 desenvolvedor influencia a complexidade estrutural}).
 
 P7 (\emph{Complexidade estrutural influencia o esforço necessário para
 compreensão de software}) foi confirmada por dois estudos de outros
 autores \cite{darcy2005, midha2008}, e representa a nossa justificativa
 para trabalhar nos fatores que influenciam a complexidade estrutural.
 
 Como não foi realizada uma revisão sistemática da literatura técnica, a
 quantidade de estudos que suportam essa teoria é bastante limitada.  A
 maioria das proposições confirmadas possuem apenas um estudo associado,
 exceto no caso de P7 que possui dois estudos.  Além disso, três
 proposições não puderam ser exploradas e outras duas foram assumidas
 como axioma. Desta forma, avaliamos o suporte experimental como
 \emph{baixo}.
 
 \begin{table}
   \centering
   \caption{Suporte experimental às proposições.}
   \begin{tabular}{ll}
     \hline
     \textbf{Proposição} & \textbf{Suporte experimental}     \\
     \hline
     P1    & \cite{terceiro2010:core-periphery}              \\
     P2    & 2/10 \cite{terceiro2012:csmr}                   \\
     P3    & 3-4/10 (seção \ref{sec:estudos:melhores-modelos}) \\
     P4    & 5/10 \cite{terceiro2012:csmr}                   \\
     P5    & 7/10 \cite{terceiro2012:csmr}                   \\
     P6    & Não explorada.                                  \\
     P7    & \cite{darcy2005,midha2008}                      \\
     P8    & Assumida como axioma.                           \\
     P9    & Assumida como axioma.                           \\
     P10   & Não explorada.                                  \\
     P11   & Não explorada.                                  \\
     \hline
   \end{tabular}
   \label{tab:discussao:suporte-experimenal}
 \end{table}
 
 \textbf{Poder de explicação.}
 Conforme discutido nas seções \ref{sec:estudo:csmr2012} e
 \ref{sec:estudos:melhores-modelos}, os modelos testados para os fatores
 \emph{Experiência}, \emph{Grau de autoria}, \emph{Variação de Tamanho} e
 \emph{Difusão da Mudança} apresentam uma grande amplitude de variação
 nos seus coeficientes de determinação ($R^2$). Em alguns projetos, uma
 grande parte da variação na complexidade estrutural pode ser explicada a
 partir dos modelos obtidos.  Para outros projetos apenas uma pequena
 parte da variação encontra explicação, o que significa que a maior parte
 da variação da complexidade estrutural ainda não pode ser explicada
 pelos fatores incluídos nesta teoria.
 %
 Além disso, o teste de hipótese utilizado no estudo sobre o \emph{Nível
 de participação} (seção \ref{sec:estudo:sbes2010}) foi uma comparação de
 médias, e envolveu uma única variável independente (o nível de
 participação, que indicava desenvolvedores centrais ou periféricos).
 %
 Desta forma, avaliamos o poder de explicação da teoria como
 \emph{baixo}.
 
 \textbf{Parcimônia.}
 Todos os construtos e proposições apresentados são relevantes no
 contexto da teoria, pois representam representam aspectos importantes
 que devem ser levados em consideração na análise da evolução da
 complexidade estrutural em sistemas de software. No entanto, alguns
 construtos e proposições não puderam ser explorados, e ainda assim foram
 mantidos na teoria, mesmo sem suporte experimental.
 %
 Desta forma, consideramos a parcimônia da teoria proposta como
 \emph{média}.
 
 \textbf{Generalidade.}
 Considerando o escopo proposto --- projetos de software livre em C, C++ e Java,
 com até 35000 linhas de código e em domínios de aplicação ligados a
 software de infraestrutura -- avaliamos que a teoria proposta possui
 generalidade \emph{baixa}.
 
 \textbf{Utilidade.}
 Conforme estudos que mostraram uma associação de complexidade estrutural
 com maior esforço de manutenção \cite{darcy2005,midha2008}, e o fato de
 que maior esforço de manutenção implica em maiores custos e maior risco,
 a questão da complexidade estrutural num projeto de software é de vital
 importância.
 %
 %
 Desta forma, avaliamos a utilidade desta teoria como \emph{alta}.
 
 diff --git a/08-conclusao.tex b/07-conclusao.tex
 similarity index 92%
 rename from 08-conclusao.tex
 rename to 07-conclusao.tex
 index 149ab8c..2a4716e 100644
 --- a/08-conclusao.tex
 +++ b/07-conclusao.tex
 @@ -1,4 +1,8 @@
 \chapter{Conclusão}\xchapter{Conclusão}{
   Este capítulo conclui este trabalho discutindo os principais
   resultados obtidos, suas limitações e as oportunidades identificadas
   para trabalhos futuros.
 }
 \label{cap:conclusao}
 
 %%fakesection
 @@ -22,12 +26,12 @@ estrutural sofria variações bruscas, ou deixava de aumentar no mesmo
 ritmo, aconteceram mudanças na arquitetura do sistema.
 %
 Este resultado sugere que mudanças abrutas na complexidade estrutural ou
 no seu ritmo de mudança podepodem ser usadausadas para identificar estes diferentes
 períodos na evolução de um sistema de software.
 
 O estudo apresentado na seção \ref{sec:estudo:sbes2010} concluiu que
 desenvolvedores centrais introduzem menos complexidade do que
 desenvolvidosdesenvolvedores periféricos. Também foi verificado que desenvolvedores
 centrais causam maiores reduções na complexidade estrutural do que os
 desenvolvedores periféricos. Este resultado demonstra a importância da
 manutenção de uma equipe de desenvolvedores centrais num projeto de
 @@ -57,7 +61,7 @@ estudo apresentado na seção \ref{sec:estudos:melhores-modelos} indicaram
 que todos os fatores estudados apresentaram influência sobre a variação
 da complexidade estrutural em pelo menos um dos modelos construídos.
 
 No seção \ref{sec:discussao:fatores},\ref{sec:estudos:conclusao}, foi identificado que, no caso de
 \emph{commits} que aumentam a complexidade estrutural, a variação de
 tamanho e o número de módulos adicionados -- fatores ligados à
 manutenção -- apresentaram influência significativa sobre um número
 @@ -102,17 +106,17 @@ reproduzida.  Assim, os fatores foram elencados de acordo com a intuição
 e experiência prévia com desenvolvimento de software, e não foram fruto
 de uma pesquisa na literatura.  Isso se deve em parte também ao fato de
 que a pesquisa realizada não conseguiu identificar estudos que
 estudassemabordassem especificamente as causas da complexidade estrutural em
 sistemas de software.
 
 % Formular uma teoria ⋯
 Teorias em Engenharia de Software podem ser construídas a partir de
 evidência existente através de Revisão Sistemática da Literatura,
 Meta
 análiseMetanálise ou comatravés de uma abordagem baseada num Portal de
 Experiências \cite{shull2008}. A teoria proposta nesta tese foi baseada
 em evidência existente, mas ela não foi construída com base em nenhuma
 destas abordagens. Nossa teoria foi construída a partir do conjunto de
 fatores que havia sido determinado previamente como possíveis causas da
 complexidade estrutural, bem como da reunião das hipóteses existentes
 nos estudos experimentais.
 
 diff --git a/99-apendices.tex b/99-apendices.tex
 index 5bdecbb..f85c292 100644
 --- a/99-apendices.tex
 +++ b/99-apendices.tex
 @@ -1,24 +1,41 @@
 \appendix
 
 \chapter{Structural\xchapter{Structural Complexity Evolution in Free Software Projects: A
 Case Study}Study}{
   Este apêndice contém uma reprodução de artigo publicado com o mesmo
   título, nos anais do \emph{Joint Workshop on Quality and Architectural
   Concerns in Open Source Software (QACOS) and Open Source Software and
 Product Lines (OSSPL) -- QACOS/OSPL 2009}.
 }
 \label{apendice:qacos2009}
 
 \includepdf[pages=-]{artigos/structural-complexity-evolution-case-study.pdf}
 
 \chapter{An\xchapter{An Empirical Study on the Structural Complexity Introduced by
 Core and Peripheral Developers in Free Software Projects}Projects}{
   Este apêndice contém uma reprodução de artigo publicado com o mesmo
   título nos anais do XXIV Simpósio Brasileiro de Engenharia de Software
   em 2010.
 }
 \label{apendice:sbes2010}
 
 \includepdf[pages=-]{artigos/complexidade-estrutural-centrais-perifericos.pdf}
 
 \chapter{Understanding\xchapter{Understanding Structural Complexity Evolution: a Quantitative
 Analysis}Analysis}{
   Este apêndice contém uma reprodução de artigo publicado com mesmo
   título nos anais da \emph{16th European Conference on Software
   Maintenance and Reengineering}, em 2012.
 }
 \label{apendice:csmr2012}
 
 \includepdf[pages=-]{artigos/analise-quantitativa-complexidade-estrutural.pdf}
 
 \chapter{Analizo:\xchapter{Analizo: an Extensible Multi-Language Source Code Analysis and
 Visualization Toolkit}Toolkit}{
   Este apêndice contém uma reprodução de artigo publicado nos anais da
   sessão de ferramentas do I Congresso Brasileiro de Software, em 2010.
 }
 \label{apendice:analizo}
 
 \includepdf[pages=-]{artigos/analizo-cbsoft2010-tools.pdf}