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}