ENGENHARIA DE SOFTWARE APLICADA A PROJETOS DE CÓDIGO ABERTO
Gean Saturno Gonçalves1 [email protected]
Jaciara Silva Carosia2 [email protected]
RESUMO
Desde a criação do computador, a engenharia de softwares vem estudando formas de produzir software de qualidade. Devido as características abstratas e flexíveis do software, foi necessário adaptar uma engenharia a cada novo sistema desenvolvido. Todavia, existe um paradigma de desenvolvimento de software cuja informalidade, além de outros fatores, restringe a engenharia de software. Estes projetos são chamados de projetos de código aberto e são responsáveis por grande parte das tecnologias hoje existentes. No entanto, são esses os projetos que normalmente mais fracassam. O objetivo deste trabalho é propor uma engenharia de software que possa colaborar com a redução de projetos falhos na comunidade de código aberto. Através de um levantamento bibliográfico sobre engenharia de software, projetos de código aberto e a análise de casos de sucesso como Ubuntu, Firefox e Linux, foi proposta uma engenharia de software aplicada a projetos de código aberto. Após a execução da metodologia, conclui-se que a engenharia de software é capaz de auxiliar o desenvolvimento de projetos de código aberto, garantindo assim maior chance de sobrevivência, potencializando inovações e revoluções.
Palavras-chave
Engenharia de Software, Código Aberto, Software Livre
ABSTRACT
Since the creation of the computer, the software engineering has been studying ways to produce quality software. Because of the software's abstract and flexible features, it was necessary to adapt an engineering every new system developed. However, there is a software development paradigm whose informality, and other factors, restricted the software engineering. These projects are called open source projects and are responsible for most of today's existing technologies. However, these are the projects that usually fail more. The objective of this work is to propose a software engineering that can collaborate with the reduction of failed projects in the open source community. through a literature survey on software engineering and open source projects and analysis of successful cases as like Ubuntu, Firefox and Linux, proposed a software engineering applied to open source projects. After the implementation of the methodology, it is concluded that the software engineering is able to assist the development of open source projects, thus ensuring greater chance of survival, leveraging innovations and revolutions.
Keywords
Software Engineering, Open Source, Free Software
1 Pesquisador do Programa de Iniciação Cientifica do Centro Universitário da Fundação Guaxupé (UNIFEG). Discente do curso de Ciência da Computação.
2 Professor orientador da pesquisa. Mestre em Computação Aplicada pelo Instituto Nacional de Pesquisas Espaciais. Docente do curso de Ciência da Computação do UNIFEG. 2
1. INTRODUÇÃO
Com a descoberta do computador, várias áreas do conhecimento humano foram drasticamente afetadas, de modo que sofreram uma revolução surpreendente (PRESSMAN, 2011). O software, parte fundamental da computação, é o responsável por instruir os dispositivos computacionais fazendo com que cumpram com a sua programação. Devido ao software ser flexível e abstrato, ele pode ser aplicado em praticamente todas as áreas das ciências humanas. Atualmente, toda estrutura social do planeta é sustentada pelos softwares (SOMERVILLE, 2011). Todavia, devido as suas características, o software corre um grande risco de falhas, e para corrigir estas falhas, foi desenvolvido a Engenharia de Software. Devido á ampla aplicação do software, criaram-se várias categorias, o que torna impossível a aplicação de uma única engenharia para todas estas categorias de software. Para reduzir as chances de falha de um projeto, foi necessário adaptar os conceitos da engenharia de software para um determinado modelo de software, levando em consideração a sua categoria, modelo da empresa, modelo da equipe e do tipo de cliente (SOMERVILLE, 2011). Entre todos os modelos de software, existe um determinado paradigma de projeto chamado de projetos de código aberto. Este paradigma de projeto conta com uma característica informal natural, que contribui para a falta de engenharia de software para este modelo de projeto. A ideia de que uma engenharia de software não é necessária em um projeto de código aberto é frequentemente constatada, mas terrivelmente incorreta. Estatísticas apontam que incríveis 95% dos projetos de código aberto iniciados tendem ao fracasso (FOGUEL, 2015). Projetos de código aberto se distinguem ligeiramente de projetos comuns e muitos deles foram responsáveis por revoluções tecnológicas. Projetos como o Kernel Linux, linguagem de programação PHP, Java, servidores de aplicação como o Apache, banco de dados MySQL, e muitos outros projetos, abriram possibilidades que poderiam não existir se fossem projetos comuns (CHRISTOPH, 2004). O objetivo deste trabalho foi idealizar uma modelo de engenharia de software que possa ser capaz de orientar um projeto de código aberto, reduzindo suas chances de falha, o que resultará em uma contribuição ainda maior para o futuro. Para isto, foi efetuado um levantamento bibliográfico sobre engenharia de software e projetos de código aberto, possibilitando a idealização da engenharia de software aplicada a projetos de código aberto. Após a idealização da engenharia de software, foi efetuado o estudo de casos para comparar a engenharia de software idealizada com as aplicadas nos casos estudados, permitindo o aperfeiçoamento da idealização.
2. ENGENHARIA DE SOFTWARE
Devido às características flexíveis e abstratas do software, seu projeto e construção pode facilmente sair de controle sem a devida atenção. Devido à crescente demanda por software, foi necessário desenvolver técnicas, métodos e ferramentas capazes de auxiliar o desenvolvimento de
Revista de Iniciação Científica - UNIFEG, Guaxupé - nº 15 - 2015
3
softwares sem falhas. Deste modo, foi desenvolvida a engenharia de software, que vem propondo muitos métodos para uma produção adequada (SOMERVILLE, 2011). Embora várias técnicas tenham sido desenvolvidas, há uma incrível divergência entre projetos de software. O primeiro ponto, um projeto de software não será igual a outro. Ele poderá adequar a diferentes ferramentas e tecnologias, ou simplesmente um software com um objetivo diferente. Um exemplo desta divergência é a comparação de um site comercial com um jogo virtual, ambos são softwares, porém, possuem objetivos diferentes. Neste caso, a engenharia de software aplicada a um site não seria a mesma aplicada a um jogo virtual, o que exige uma adequação das técnicas e modelos idealizados pela engenharia de software. Este problema de conversão não se limita apenas ao software, ele ecoa através do modelo da empresa, da equipe e até mesmo do cliente (SOMERVILLE, 2011). Para as fases de produção do software, foram desenvolvidos vários modelos de processos. Um processo é basicamente uma sequencias de atividades, compostas por ações e tarefas para alcançar um determinado objetivo. Todavia todos os modelos da engenharia de software devem ser adaptados ao projeto a ser desenvolvido (PRESSMAN, 2011). A engenharia de software não se limita apenas o processo do projeto, esta engenharia também engloba a gerência dos projetos, o processo é apenas um ponto da gerência (SOMERVILLE, 2011). Segundo Pressman (2011), a gerência de um software é fundamental para a sobrevivência do mesmo. Um projeto com uma gerência de baixa qualidade resulta em trabalhos menos eficientes, uma tarefa leva mais tempo para ser efetuada, isso gera um aumento do custo final do projeto. Para isto, a gerência do projeto foca em 4 pontos, conhecido como os 4 pês: 1. Pessoal. 2. Produto. 3. Processo. 4. Projeto. O software é desenvolvido por recursos humanos, pesquisas apontaram que os recursos humanos são os itens mais importantes no projeto, e as capacidades de seleção e cultivação destes recursos estão diretamente ligadas ao sucesso do projeto. Levando isto em consideração a Software Engenering Intitute (SEI) desenvolveu um modelo de maturidade e capacidade dos recursos humanos (PRESSMAN, 2011). Algumas das atividades que compõem este modelo são: • Formação de Equipe • Comunicação • Ambiente de trabalho • Gerencia de desempenho • Desenvolvimento de carreira • Desenvolvimento do grupo de trabalho • Desenvolvimento da cultura da equipe
Revista de Iniciação Científica - UNIFEG, Guaxupé - nº 15 - 2015
4
Outro ponto de influência no projeto é a estrutura organizacional da equipe. Existem milhares de estruturas organizacionais diferentes, porém, assim como os processos, foram definidos paradigmas gerais (PRESSMAN, 2011). Alguns destes paradigmas são: • Paradigma fechado: Estrutura tradicional, contém o chefe e seus subordinados. Esta estrutura desenvolve grande capacidade de produção, porém sua inovação acaba sendo restringida. • Paradigma aberto: Estrutura geralmente utilizada em projetos de código aberto. Expande a capacidade de inovação da equipe, porém a eficiência depende da comunicação entre os recursos. Após a organização dos recursos humanos, é necessário conhecer o produto que será desenvolvido. Para isto é necessário analisar onde o projeto irá atuar e com isto o objetivo do produto. Com a equipe pronta e o produto especificado, é possível definir o processo que será aplicado neste projeto, levando em conta o produto e o pessoal. Segundo Pressman (2011), a única maneira de controlar a complexidade de um projeto é com o planejamento. Assim, estes 4 aspectos (pessoas, produto, processo e projeto) são fundamentais para o sucesso de um software. Se apenas um deles não for bem administrado, o projeto pode estar em risco. Uma técnica muito fortemente sugerida pera engenharia de software é o uso de documentação. A documentação é uma forma de registrar acontecimento, ideias, modificações, descrevendo os detalhes do sistema a ser desenvolvido. O documento, embora trate de descrever o software, deve ser trabalhado de várias formas ou perspectivas diferentes (PFLEGGER, 2004). Para usuário, o documento deve tratar da parte de usabilidade do projeto, descrição de menus, ações, ferramentas, restrições e etc. Para os desenvolvedores do projeto, a documentação deve ser mais técnica, apresentando as características e comportamento dos módulos que irão implementar os requisitos do projeto. A documentação de requisitos é fundamental para orientar a equipe de software, pois será a principal referência para seu desenvolvimento. Outra técnica de documentação importante é a documentação interna. Assim como a documentação descreve o sistema, a documentação interna descreve o seu código. A descrição do código fonte do software permite que uma tarefa seja pausada e retomada sem muitos esforços, facilita a localização e correção de falhas. Além disso, quando o código estiver completo, provavelmente outras pessoas irão utilizá-lo de várias formas diferentes. O código escrito pode ser testado por outra equipe, outras pessoas irão integrar o módulo desenvolvido com o restante do sistema, alterações ou correções exigidas após o desenvolvimento do software. Desta forma, a documentação no código auxilia e facilita o trabalho de outras pessoas entenderem ou modificarem o código (PFLEGGER, 2004).
3. SOFTWARE DE CÓDIGO ABERTO
Segundo a Open Source (2015), existem dois tipos de softwares. Os softwares onde ninguém tem acesso ao seu código são chamados de softwares proprietário. Por outro lado, os softwares que
Revista de Iniciação Científica - UNIFEG, Guaxupé - nº 15 - 2015
5
deixam seu código disponível para qualquer um analisar, estudar, modificar e distribuir são chamados de software de código aberto. Fogel (2015) afirma que o projeto de código aberto é produzido por um grupo de voluntários, ou colaboradores, que estão geograficamente dispersos e que possivelmente desconhecem completamente um ao outro. Projetos com esta natureza não pode ser ‘administrados’, o projeto é iniciado e então é influenciado pelos seus colaboradores, voluntários e outras partes interessadas. Deste modo, a sobrevivência, e a evolução dependem de um trabalho em conjunto entre todas as partes envolvidas. O software de código aberto já foi capaz de destruir o monopólio de empresas privadas (OLIVEIRA, 2011). Alguns exemplos são: • Sistema operacional Linux. Sistema que superou a alternativa privada da Microsoft para servidores. • Servidor HTTP Apache: Servidor utilizado para hospedar sites. Este software gratuito destronou a solução paga da Microsoft. • PHP: Uma das linguagens mais utilizadas nos dias de hoje. Superou a linguagem de programação da Microsoft. Estes três exemplos compõe a maior parte da internet até os dias de hoje (CRISTOPH, 2004). Atualmente, as grandes empresas já compreenderam que desenvolver tecnologias complexas de modo compartilhado resulta em soluções inovadoras e com um custo reduzido. Um exemplo é a nova API gráfica batizada de Vulcan desenvolvida pelo grupo Krhonos que conta com mais de 100 membros incluindo Intel, IBM, Nvidia, AMD, Sony, Apple, Samsung LG, Google e outras gigantes. Diferentemente do seu concorrente direto, o DirectX da Microsoft, a Vulkan permite que o mesmo software seja executado em todas plataformas, enquanto o DirectX é de uso exclusivo para plataformas Windows (VULKAN, 2015). Outra particularidade dos softwares de código aberto é a sua licença. Segundo Guisser (2009), um software proprietário possui sua licença vendida por um tempo determinado. Já o software de código aberto possui uma licença que permite que ele seja livremente usado, alterado e distribuído. Existem várias licenças diferentes prontas para que qualquer um possa atribuir a seu projeto, evitando a criação de novas licenças (FOGUEL, 2015). As licenças mais conhecidas são: • Licença Apache • Licença BSD • GNU General Public License (GPL) • Eclipse Public License Foguel (2015) afirma que a principal diferença entre as licenças, estão na permissão de uso em softwares proprietários, possibilidade de uso para softwares livres e marcas registradas, o que não permite que outras distribuições usem o mesmo nome da principal. Outro fator muito importante em um projeto de código aberto são as ferramentas nele utilizadas. Segundo Foguel (2015) um projeto de código aberto depende da gerência da informação e para isto, existem várias tecnologias fundamentais. Todo projeto de código aberto deve contar com
Revista de Iniciação Científica - UNIFEG, Guaxupé - nº 15 - 2015
6
pelo menos um rastreador de bugs, um software gerenciador de versão, um website, um fórum e um canal de chat. Os projetos de código aberto são produzidos por diversas pessoas diferentes, que provavelmente estão trabalhando isoladamente, porém interagem entre si através da internet. Para que a comunidade funcione, é necessário estabelecer políticas de governo democrático. Em projetos de código aberto, qualquer pessoa pode criar um projeto concorrente ao que existe atualmente, o que é chamado de fork. Com a chance de o projeto ser copiado por qualquer um e quando quiser não permite que alguém exerça muito poder sobre o projeto. Se o líder do projeto tomar alguma decisão que não é aprovada por parte da comunidade de colaboradores, o projeto pode receber um fork. Além do fork não dar muita autoridade para uma determinada pessoa, ele da autoridade para qualquer pessoa. Se uma determinada pessoa desejar adaptar o projeto a alguma área específica, ele tem todo o direito para isto (FOGUEL 2015). Segundo Foguel (2015), softwares de sucesso geralmente surgem de um problema pessoal, todavia, softwares de código aberto compartilham a solução deste problema com outras pessoas que tenham problemas semelhantes ou iguais. Portanto o software de código aberto pode surgir do zero ou a partir de outro software através de um fork. Projetos de código aberto possuem diversas linhas de desenvolvimento, não que isto seja uma característica única deste tipo de projeto, mas é o meio que ele utiliza. Isto permite que o projeto possa ser desenvolvido 24 horas por dia e 366 dias no ano, onde cada equipe trabalha em uma característica do software. Isto acontece devido ao fato de que enquanto o ocidente descansa o oriente é capaz de manter o desenvolvimento. Assim o projeto possui uma atualização continua. A característica informal deste tipo de projeto muitas vezes influencia no seu desenvolvimento. Projetos sem políticas de padronização tendem a cair em anarquia, pois resulta em um ambiente onde a cooperação da comunidade é impossível. A característica anárquica é comum em projetos de código aberto que são classificados como mortos ou falhos.
4. ENGENHARIA DE SOFTWARE APLICADA A PROJETOS DE CÓDIGO ABERTO
A engenharia de software foi fundada para reduzir o número de falhas de software. Segundo Fogel (2015), é difícil dizer quando que um projeto de código aberto falhou. Um projeto talvez possa ser considerado falho uma vez que não possui colaboradores nem usuários, por isto não é possível calcular com exatidão o número de projetos de código aberto que falharam, porém, o número gira em torno de 90 a 95%, ou seja, em 10 projetos de código aberto, um poderá sobreviver. Isto tudo pode ocorrer por um mal-entendido em relação ao projeto código aberto. Muitas empresas não compreendem o processo para tornar o código de uma aplicação aberto. Abrir o código de um software pode trazer mais uma série de problemas. Neste tipo de projeto é necessário que o código seja legível, que possua uma documentação para auxiliar novos voluntários e um grupo de discussões para futuras duvidas (FOGUEL, 2015). Foguel (2015) também afirma que a gerência de um projeto de código aberto é única, discreta, ativa e presente. Este é o padrão de gerência utilizado em muitos projetos de sucesso.
Revista de Iniciação Científica - UNIFEG, Guaxupé - nº 15 - 2015
7
Outro problema que é citado por Fogel (2015) é a comunidade. A comunidade é onde todos os envolvidos com o projeto se interagem. É necessário que esta comunidade seja agradável para que os desenvolvedores retornem para o projeto. Os projetos de código aberto bem-sucedidos possuem ambiente amigáveis e agradáveis para a interação das partes interessadas. Deste modo, Foguel (2015) estabelece quatro necessidades em um projeto de código aberto: 1. Gerência. 2. Código legível. 3. Documentação acessível e de qualidade. 4. Comunidade agradável. Para uma melhor gerência, além de facilitar a produção do software, é importante definir um processo de produção (PRESSMAN, 2011). Observando o paradigma do projeto de código aberto, parece impossível de definir um padrão de processo dentro dele. Todavia, um padrão de processo pode ser aplicado nos voluntários. Desta forma políticas podem ser definidas, como por exemplo, definir uma comunicação inicial com a comunidade permitindo o acoplamento de recursos humanos proporcionando mais eficiência ao desenvolvimento. Outro exemplo é a definição de que todas as sugestões devam ser postadas no fórum antes de ser discutida, ou todos módulos devem ser enviados através do gerenciador de versão. Este padrão de interação dos voluntários auxilia a gerência do projeto. O corpo de gerentes de um projeto de código aberto deve ser proporcional à dimensão que o projeto tomou. Gerentes podem aparecer espontaneamente, ou ser estrategicamente designados para o cargo. Alguns gerentes que são comumente encontrados em projetos de código aberto são: 1. Gerente de Correções: Avalia as correções efetuadas pela comunidade e toma providencias caso não estejam corretas. 2. Gerente de Tradução: Organiza equipes de tradução e interliga as mesmas com o desenvolvimento do projeto, traduzindo o software e sua documentação. 3. Gerente de Documentação: Efetua a mesma tarefa que o gerente de correções, porém, direcionado a documentação. Este gerente também é responsável por sincronizar a documentação com eventos ocorridos no desenvolvimento. 4. Gerente de Falhas: Vasculham todos os meios de comunicação do projeto a procura de falhas, e elegendo as mais urgentes, para então repassar para os desenvolvedores. Entre os paradigmas de estrutura de equipe citado por Pressman (2011) a estrutura de equipe aberta aparenta ser o paradigma mais apropriado para projetos de código aberto. O paradigma aberto é excelente para resolução de problemas complexos, sendo capaz de desenvolver soluções criativas e inovadoras. Todavia este paradigma exige uma alta comunicação entre os envolvidos e requer um consenso de toda a comunidade. Como é de imaginar, não é nada fácil fazer com que toda a comunidade coopere para o sucesso do projeto. Segundo Foguel (2015) são necessárias várias pessoas para gerenciar todas as comunidades. Para manter desenvolvedores no projeto, os mesmos devem ter oportunidade para cooperar, a colaboração é uma forma de motivar os novos integrantes. Já desenvolvedores que estão mais
Revista de Iniciação Científica - UNIFEG, Guaxupé - nº 15 - 2015
8
tempo no projeto, vão tentar tomar todas as tarefas de uma determinada área. Este tipo de atitude abala toda a cooperação da comunidade. Em relação ao projeto Foguel (2015) afirma que um dos maiores motivos de um projeto de código aberto dar errado, é criar um projeto que solucione um problema já solucionado por outro já existente. Por este motivo, é importante procurar projetos que já existam. Nos dias atuais, é pouco provável que não exista uma solução de código aberto para algum problema. Caso exista um projeto que solucione o problema, os esforços podem ser aplicados neste projeto. Se não houver um projeto que solucione o problema, é possível localizar softwares que podem ser adaptados com um fork. É importante ter em mente que forks são eficientes apenas para criar projetos que diferenciem do original. Criar um fork de um projeto, mas manter a mesma solução é um esforço desperdiçado, além de prejudicar o software original, projetos que recorreram a esta atitude fracassaram. A licença tem grande influência sobre o projeto. É importante aplicar ao projeto a licença que mais condiz com o objetivo do mesmo. A licença GPL, por exemplo, define que qualquer distribuição do seu projeto, deve utilizar a mesma licença. Esta licença foi projetada para defender o movimento de software livre, pois além de não permite que softwares proprietários usufruam do trabalho da comunidade, promove o movimento de software livre. Porém, esta licença restringe outras licenças de código aberto também, o que pode não ser conveniente. Já a licença MIT é compatível com qualquer outra licença, inclusive permite que o código seja aplicado em programas proprietários (FOGUEL, 2015). O fato de qualquer indivíduo ter acesso ao código fonte de um software de código aberto pode ocasionar alguns problemas, novos projetos podem utilizar o nome de outro para aproveitar de sua reputação. Segundo Foguel (2015) marcas registradas é uma maneira de defender a reputação de um software de código aberto. Marca registrada é muito importante para softwares que concorrem na linha de frente com as alternativas privadas. Enquanto que em softwares proprietários, usuários podem ser alcançados com muitos desenvolvedores, projetos de código aberto dependem dos dois, pois um usuário pode ser um possível colaborador, e com mais colaboradores, mais usuários o projeto irá alcançar. Deste modo, a missão do projeto deve ser moldada publicamente, de modo que fique acessível e legível aos usuários, pois será uma informação muito procurada por pessoas interessadas no projeto. Segundo Chacon e Strub (2015) o SCV é um software que registra toda e qualquer modificação no arquivo, usar este tipo de software permite retornar a qualquer versão anterior do projeto ou arquivo. Os SCV atuais trabalham de maneira distribuída, onde cada colaborador possui uma cópia do projeto. Toda alteração, tanto local, quando global pode ser sincronizada e adaptada. Pressman (2011) também cita como indicador de risco a má gerência de software e a competência da equipe. Estes itens são totalmente aplicáveis aos projetos de código aberto. Todavia adquirir bons desenvolvedores para projeto de código aberto não se resume apenas a salário. É neste momento que a capacidade de liderança deve desabrochar e agir para motivação dos desenvolvedores.
Revista de Iniciação Científica - UNIFEG, Guaxupé - nº 15 - 2015
9
Pflegger (2004) afirma que a documentação é onde as características do software estão especificadas. Devido à natureza dos projetos de código aberto, a diversidade de pessoas que iram ter acesso ao software é muito maior, o que amplia a necessidade de uma documentação. Além disso, não há como definir o perfil de pessoas que acessaram a documentação, o que exige ainda mais atenção. Assim como softwares proprietários, os softwares de código aberto necessitam da documentação interna e a documentação do usuário. Segundo Foguel (2015), a primeira sensação do novo desenvolvedor é estranheza com o código. E nesta situação, geralmente pessoas tendem a buscar algo para ler, mesmo que seja rústico e incompleto. Isto faz com que a documentação interna seja o elo do desenvolvedor com o código. Como Pflegger (2004) afirma, a documentação interna facilita a compreensão do código escrito por outra pessoa. Em frente ao desenvolvimento comunitário onde dezenas de pessoas podem ter alterado um determinado arquivo, e dezenas poderão alterá-lo futuramente, técnicas para apoiarem a compreensão do código não tem porque serem ignoradas. Em relação à documentação para usuários, é fundamental que a documentação esteja disponível online e off-line, pois usuários geralmente iram ler antes de baixar, para configurar a máquina, e depois de baixar, para aprender a usar, ou consultar algum tópico. A documentação não auxilia apenas novos usuários, a documentação auxilia os desenvolvedores a manterem o foco no projeto, pois dúvidas que repetidamente são levantadas podem ser explicadas na documentação. Foguel (2015) afirma que os arquivos da documentação podem ser disponibilizados em forma de wikis, pois estas ferramentas auxiliam a organização da documentação além de auxiliar novos usuários que já estão familiarizados com estes sistemas.
5. ESTUDO DE MÚLTIPLOS CASOS
Para alcançar o objetivo deste trabalho, além da engenharia de software aplicada a projetos de código aberto, foi realizado um estudo de múltiplos casos de projetos de código aberto existentes na atualidade. Esse estudo pode ajudar a localizar tópicos que não foram tratados nesta engenharia de software e melhorar os tópicos existentes.
5.1 – Linux
O primeiro projeto de código aberto a ser tratado é nada menos que o projeto de código aberto mais bem-sucedido da história. O Linux teve sua origem em outro kernel chamado Unix e está sobre a licença GPL versão 2. O Código fonte do Linux é hospedado em um servidor git próprio, não fazendo uso do GitHub. O rastreador de bugs utilizado é o Bugzila. O Linux também possui uma wiki bem completa sobre praticamente todas as partes do kernel. O Kernel Linux possui várias versões que são mantidas por diversos contribuintes. A Versão principal é chamada de mainline e é usado pelas diversas distribuições Linux existentes. Existem também as versões de suporte a tempo estendido chamadas de longterm que podem ser usadas
Revista de Iniciação Científica - UNIFEG, Guaxupé - nº 15 - 2015
10
para qualquer fim, desde automação a desenvolvimento de sistemas embarcados (LINUX KERNEL, 2015). O Projeto Linux também possui um processo cujo objetivo é localizar modificações da comunidade que possam ser aplicadas no mainline do projeto, centralizando o seu desenvolvimento (LINUX FUNDATION, 2015).
5.2 – Warzone 2100
Warzone 2100 é um jogo de estratégia em tempo real onde o jogador encara o comando de uma força chamada The Project e o seu objetivo é reconstruir a terra devastada por uma guerra nuclear. O jogo foi desenvolvido pela Pumpkin Studios e lançado como um software proprietário em 1999. Em 2000 a empresa responsável pelo jogo fechou suas operações (IGN 2015) e em 2004 o seu código fonte foi aberto e entregue na mão da comunidade para prosseguir o seu desenvolvimento (WARZONE 2100, 2015). Este projeto está entre os estudos de caso devido ao seu tempo de existência. Desde 2004 até o ano atual, 2015, são mais de 10 anos, onde este projeto teve melhorias, o que faz deste um bom caso de estudo. Seu código está hospedado no GitHub, e esta ferramenta disponibiliza um gráfico de contribuições da comunidade dentro de 10 anos. Mesmo este sendo um jogo com baixa qualidade gráfica, comparando aos jogos atuais, o projeto vem recebendo significantes contribuições da comunidade desde 2005. O projeto possui um site que é a porta do projeto. A partir do site é possível acessar perguntas frequentes, Wiki, relatório de bug, modificações, Fórum e Download, o arsenal completo descrito por Foguel (2015). A página de perguntas frequentes traz informações básicas para o novo usuário. A wiki do projeto reúne todas as suas informações em um único local, modificações, tradução, inteligência artificial, relatório de bugs, programação, arte e comunicação, não havendo distinção entre usuários e desenvolvedores. O texto das páginas se mostra convidativo para motivar a colaboração de cada vez mais pessoas, sendo bem explicativas e apoiando que novos usuários entrem em contato com a comunidade. Segundo Warzone 2100 (2015) a maior parte da comunicação da comunidade é efetuada pelo rastreador de bugs, e chats divididos em jogadores, desenvolvedores e assuntos gerais. O projeto define vários padrões, como é o caso do guia de estilo de programação. Na tentativa de criar um estilo de programação homogenia, o projeto define um estilo para ser utilizado por todos os colaboradores. Para propor novas funcionalidades e características o contribuinte deve seguir um certo padrão para se relacionar com a comunidade. O projeto também define um padrão para o envio de alterações através do github, definindo um comportamento homogêneo entre os colaboradores.
5.3 – Ubuntu
Ubuntu é uma plataforma de software de código aberto que pode ser utilizado desde servidores até smartphones (UBUNTU, 2015). Na página destinada o Ubuntu para desktop é possível encontrar
Revista de Iniciação Científica - UNIFEG, Guaxupé - nº 15 - 2015
11
uma área que instrui usuários a interagir com a comunidade crescente de usuários Ubuntu. Esta área apresenta quatro opções para o visitante: perguntas, lista de discussão, insights e o fórum. A área de perguntas é uma parte da rede Stack Exchange possuindo uma lista dinâmica de perguntas e respostas sobre diversas áreas do sistema, onde usuários podem aprender mais com o sistema e ajudar outros usuários. Para poder responder a qualquer pergunta, o contribuinte deve se cadastrar, e a cada ajuda, o contribuinte recebera uma pontuação, chamada de reputação, representando sua colaboração com a comunidade. Este sistema ajuda a esclarecer dúvidas de novos usuários e a incentivar que usuários experientes compartilhem seus conhecimentos em troca de reputação, mantendo um câmbio dinâmico de conhecimento e integrando a comunidade. A página da comunidade apresenta meios de colaboração com o projeto. O Ubuntu apresenta várias formas de colaboração. E para manter o projeto aberto a comunidade e a colaboração, foi desenvolvido uma regra de conduta para toda a comunidade. E estas regras são ditadas pelo Concelho Comunitário Ubuntu. Além disso, é delegado ao concelho criar ou aceitar novos projetos e equipes. Todo o trabalho do Ubuntu é dividido em equipes, onde cada equipe trabalha em uma área específica do projeto, como o kernel, segurança design e etc. Um diferencial do Ubuntu são as equipes locais (LoCo Teams). Esta equipe é composta por membros regionais e foge do paradigma online comum em projetos de código aberto. Equipes locais se encontram e interagem entre si presencialmente. Estas e muitas outras informações gerais sobre o Ubuntu podem ser encontradas na Wiki do projeto.
5.4 – Firefox
O Firefox, além de ser um navegador com o código aberto, ganhou o prêmio de navegador mais rápido e a sua mantenedora, a Mozila ganhou o prêmio de empresa mais confiável da internet em privacidade (MOZILA, 2015). Na página principal da Mozila é possível acessar a área de colaboração através do tópico “Envolvesse com o projeto”. O Firefox possui diversas áreas para se atuar. Codificação, teste, design, marketing e desenvolvimento web. Existe uma área exclusiva para os interessados a participar do projeto. E para começar o novo integrante faz contato direto com outro integrante mais experiente cuja função é orientar novos interessados guiando-o através o projeto com tarefas. Assim como Foguel (2015) sugere o Firefox utiliza todas as ferramentas fundamentais e também possui uma Wiki para informações detalhadas do projeto. O código dos seus projetos está disponível no GitHub e seu gerenciador de bugs é o Bugzila.
5.5 – Libre Office
O LibreOffice é suíte office de código aberto que conta com diversas ferramentas práticas e poderosas LibreOffice (2015). O Libre Office surgiu do OpenOffice e está licenciado sobre a LGPL e sobre a Mozila Public License (MPL). Segundo a LibreOffice (2015) a Governança do projeto é efetuado por 3 órgãos:
Revista de Iniciação Científica - UNIFEG, Guaxupé - nº 15 - 2015
12
1. Conselho Diretor. Principal administrador do projeto e das equipes. 2. Comitê de Admissão. Responsáveis pelo ingresso e novos membros e supervisão a eleição os membros o Conselho Diretor. 3. Membros. Os Membros são todas as pessoas que participam o projeto de forma ativa. Estes membros executam várias tarefas no desenvolvimento do projeto, como a documentação, teste, desenvolvimento, design e etc. O Libre office utiliza o git como controlador de versões, e o código é hospedado em um repositório da empresa. O projeto também possui uma Wiki, onde todas as informações do projeto são reunidas. Para discussões, o Libre office utiliza a ferramenta Nabble, capaz de fornecer uma interface semelhante a um fórum para de discussões. O LibreOffice também utiliza o Bugzila para gerência de bugs e para comunicação é utilizando canais IRCs, onde cada equipe possui um determinado canal. Para novos contribuintes, a equipe de desenvolvimento do LibreOffice desenvolveu uma série de tarefas para iniciá-los. Estas tarefas têm como objetivo ajudar os iniciantes a ultrapassar as barreiras encontradas em projetos de código abertos. O LibreOffice criou várias listas de novas funcionalidades, cada uma com sua funcionalidade, como por exemplo a lista de ideias malucas, onde são armazenadas ideias que alteram a estrutura do software, são armazenadas para futuras discussões. Outras listas encontradas são as de necessidades das empresas, melhorias de interface, necessidades básicas e melhorias sugeridas pelos usuários. Assim como Warzone, o LibreOffice também define um estilo de programação padrão entre a comunidade, e este estilo é o mesmo utilizado no OpenOffice, mantendo uma codificação semelhante tanto em funcionalidades antigas quanto novas. O LibreOffice também possui um padrão de processo para a interação da comunidade, mantendo uma comportamento padrão de interação facilitando a gerência.
5.6 – EvolutionRTS
Segundo EvolutionRTS (2015), este projeto trata-se de um jogo de estratégia em tempo real com o código aberto desenvolvido por 5 anos e recebendo atualizações constantemente. Está disponível na loja virtual de jogos Steam, porém sua nota é baixa em relação a outros jogos. O código fonte deste projeto está hospedado no GitHub, sendo este seu rastreador de bugs e Git seu controlador de versões. O ambiente de discussão do projeto é um grupo no Google Groups. Revolution RTS não possui nenhum tipo de documentação introdutória ao projeto, e aparentemente não possui nenhuma estrutura política. Por se tratar de um jogo, onde pode ser encontrado muitos algoritmos complexos, a documentação possui ainda mais importância (Pfleeger, 2004). Como Foguel (2015) afirma, não é possível afirmar com clareza quando um projeto de código aberto está morto, todavia EvolutionRTS não está caminhando muito bem e sua atividade no GitHub
Revista de Iniciação Científica - UNIFEG, Guaxupé - nº 15 - 2015
13
não apresenta um padrão crescente, o que não apresenta uma desenvoltura em seu desenvolvimento.
6. ANÁLISE DOS CASOS
Como podem ser observados nas sessões anteriores, os projetos de código aberto que seguiram as considerações de Foguel (2015), conseguiram se estabelecer melhor no mundo do código aberto. Todas as ferramentas apontadas por Foguel (2015) são utilizadas em boa parte dos projetos analisados. Isto aponta positivamente para a engenharia de software proposta neste trabalho. Há uma contradição entre Pressman (2011) e Foguel (2015), enquanto Foguel (2015) afirma que os projetos devem ser abertos para novos integrantes, Pressman (2011) afirma que o sucesso o projeto depende da seleção de integrantes. Com a análise dos projetos foi possível encontrar um equilíbrio entre estas duas afirmações. O projeto é aberto para todos, porém há filtros e barreiras estratégicas para novos integrantes, além de direcionar boa parte dos interessados para outras áreas, como documentação tradução e entre outras. Muitos dos casos dividem a comunidade em equipes, onde cada equipe é responsável por uma determinada área do projeto. Ubuntu foi além, quebrando o paradigma online, possui equipes locais, composta por indivíduos capazes de interagir localmente. Outro fato que é digno de atenção é a preocupação dos casos analisados na forma de codificação. Isto demonstra a preocupação dos projetos em manter um código homogêneo, facilitando o trabalho de alteração. Este fato confirma a afirmação de Foguel (2015) onde diz que é necessário que os projetos de código aberto possuam código legível. Outra ferramenta que apareceu nos casos de uso foi o Ask Ubuntu. Mesmo esta ferramenta não ter sido citada por Foguel (2015) ela é mais que merecedora de atenção. A ferramenta desenvolve um sistema de contribuição e atribuição de mérito que mobiliza toda a comunidade experiente a compartilhar seu conhecimento ajudando usuários do sistema. Como a nota da resposta é atribuída pelo usuário que fez a pergunta, educação e respeito passam a ser comum nas respostas. O Linux apresenta a gerência de informações que Foguel (2015) cita. A equipe é responsável por monitorar os contribuintes, localizar alterações que possam ser utilizadas no Linux mainline. Esta equipe gerencia exclusivamente a informação de alterações no código de outros projetos a filtra as informações interessantes. Warzone 2100 apresenta o processo de contribuição que foi inclusa na engenharia de software aqui proposta. Como pode ser observado, ele define um padrão de comportamento para qualquer alteração e melhoria no projeto. Deste modo, toda a comunidade sabe onde encontrar uma determinada informação, assim como verificar o desenvolvimento de uma alteração, solicitar novas melhorias e entre outros. Já o EvolutionRTS não seguiu as recomendações de Foguel (2015) e coincidentemente não se tornou um projeto com muita presença.
Revista de Iniciação Científica - UNIFEG, Guaxupé - nº 15 - 2015
14
7. CONSIDERAÇÕES FINAIS
O objetivo da engenharia de software é a melhoria da qualidade dos produtos desenvolvidos, bem como o aumento da produtividade do processo de desenvolvimento. No entanto, para ser eficiente em seus propósitos, todos os métodos, ferramentas e procedimentos sugeridos, devem ser adaptados a cada projeto em questão, isso se aplica obviamente também a projetos de código aberto. Com isto conclui-se que a engenharia de software proposta por este trabalho é capaz de orientar satisfatoriamente projeto de código abertos reais. Espera-se que a adoção desta engenharia de software possa reduzir o número de projetos que são classificados como inativos e atribuir qualidade a projetos de código aberto. Isto irá acelerar a adoção do paradigma de código aberto, fazendo com que mais projetos assim sejam iniciados e que projetos já existentes possam abrir seu código e estar preparado para o desenvolvimento distribuído e comunitário, oferecendo soluções abertas e distribuindo conhecimento. Desta forma, o software pode continuar a oferecer suporte a humanidade, porém de maneira mais rápida, segura, eficiente e aberta.
8. REFERÊNCIAS
CHACON, Scott e STRUB, Bem. Pro GIT: Everything you need to know about Git. 2. ed Apress, 2015.
CHRISTOPH, Roberto de Holanda. Engenharia de Software para Software Livre. Rio de Janeiro, 2004.
EVOLUTIONRTS. Evolution RTS. Disponível em:
FOGUEL, Karl. Producing Open Source Software: How to Run a Successful Free Software Project. 2015.
IGN. IGN Brasil. Disponível em:
LIBREOFFICE. A melhor suite office livre. Disponível em:
LINUX FUNDATION. The Linux Fundation. Disponível em:
LINUX KERNEL. The Linux Kernel Archives. Disponível em:
OPEN SOURCE. Open source is changing the world: Join the moviment | Open Source. Disponível em:
PFLEEGER, Shari Lawrence. Engenharia de Software: Teoria e prática. 2. ed. São Paulo: Pretice Hall, 2004.
PRESSMAN, Roger S. Engenharia de Software: Uma abordagem profissional. Porto Alegre: AMGH, 2011.
SOMERVILLE, Ian. Engenharia de Software. São Paulo: Person, 2011.
Revista de Iniciação Científica - UNIFEG, Guaxupé - nº 15 - 2015
15
UBUNTU. Ubuntu PC operating system. Disponível em:
WARZONE 2100. Warzone 2100, Disponível em:
Revista de Iniciação Científica - UNIFEG, Guaxupé - nº 15 - 2015