UNIVERSIDADE DO SUL DE SANTA CATARINA JOS FLVIO LINS DO NASCIMENTO

INTEGRAO CONTNUA: ANTECIPANDO-SE AOS PROBLEMAS, MANTENDO A INTEGRIDADE E PROMOVENDO A QUALIDADE DO SOFTWARE

Palhoa 2012

JOS FLVIO LINS DO NASCIMENTO

INTEGRAO CONTNUA: ANTECIPANDO-SE AOS PROBLEMAS, MANTENDO A INTEGRIDADE E PROMOVENDO A QUALIDADE DO SOFTWARE

Relatrio apresentado ao Curso (GESTO DA da TECNOLOGIA DA INFORMAO), Universidade do Sul de Santa Catarina, como requisito parcial aprovao na disciplina de Estudo de Caso. .

Orientador: Prof. HELTON RIBEIRO NUNES

Palhoa 2012

JOS FLVIO LINS DO NASCIMENTO

INTEGRAO CONTNUA: ANTECIPANDO-SE AOS PROBLEMAS, MANTENDO A INTEGRIDADE E PROMOVENDO A QUALIDADE DO SOFTWARE

Este trabalho de pesquisa na modalidade de Estudo de Caso foi julgado adequado obteno do grau de Tecnlogo em Gesto da Tecnologia da Informao e aprovada em sua forma final pelo Curso Superior de Tecnologia em Gesto da Tecnologia da Informao da Universidade do Sul de Santa Catarina.

Palhoa, ____ de ____________de _____.

Professor e orientador Helton Ribeiro Nunes Universidade do Sul de Santa Catarina

AGRADECIMENTOS

Agradeo Unisul e equipe de professores que me acompanhou durante essa caminhada. minha esposa que sempre me apoiou. Um agradecimento especial ao meu pai que Deus achou por bem levar para junto dele e minha me.

RESUMO

A finalidade deste trabalho apresentar as melhorias proporcionadas pela correta aplicao das tcnicas de integrao, as vantagens da implantao de processos de desenvolvimento bem definidos e da automao dos processos para evitar falhas. A metodologia empregada se valeu da coleta de dados obtidos a partir de entrevistas com membros da equipe e de observaes feitas dentro do ambiente da fbrica. Os resultados obtidos permitiram identificar solues para os principais problemas da equipe de desenvolvimento. Os problemas identificados referem-se ao compartilhamento/cpia de workspaces, aos merges no cdigo, estrutura inadequada de branches do repositrio, ao no versionamento correto dos artefatos, automao do processo de build, ao controle das verses das bibliotecas utilizadas, ao histrico das alteraes realizadas no banco de dados, garantia da execuo dos testes, documentao do software e falta de comunicao entre os membros da equipe.

Palavras-chave: integrao contnua; qualidade de software; desenvolvimento de software

SUMRIO

1INTRODUO 2TEMA 3OBJETIVOS

3.1 OBJETIVO GERAL 3.2 OBJETIVOS ESPECFICOS

7 8 10
10 10

4PROCEDIMENTOS METODOLGICOS
4.1 CAMPO DE ESTUDO 4.2 INSTRUMENTOS DE COLETA DE DADOS

11
11 12

5APRESENTAO E ANLISE DA REALIDADE OBSERVADA 6PROPOSTA DE SOLUO DA SITUAO PROBLEMA

6.1 Proposta de melhoria para a realidade estudada 6.2 Resultados esperados 6.3 Viabilidade da proposta

13 18
18 22 24

7CONSIDERAES FINAIS REFERNCIAS

26 27

INTRODUO

Neste trabalho apresentamos os resultados obtidos a partir da analise dos problemas enfrentados por uma equipe de desenvolvimento de software. A pesquisa se limitou rea de desenvolvimento e testes e no foram levadas em conta questes como a metologia de desenvolvimento ou de gerenciamento de projetos utilizadas. Essa pesquisa implicou em entender as causas dos problemas enfrentados pela equipe de desenvolvimento e a identificao de ferramentas e solues que ajudassem a resolv-los.

TEMA

Garantir a qualidade do software produzido um dos maiores desafios que os profissionais da rea de TI enfrentam. Segundo a Norma NBR ISO 9000-2005, Um Sistema de Gesto de Qualidade pode fornecer a estrutura para melhoria contnua com o objetivo de aumentar a probabilidade de ampliar a satisfao do cliente e de outras partes interessadas. O mercado de TI bem heterogneo em relao s linguagens de programao em uso e, segundo estatsticas publicadas pelo site TIOBE (2012), as mais utilizadas no mundo so o Java, C, C#, C++ e o Objective-C. Cada uma delas tem suas prprias particularidades mas, durante o processo de desenvolvimento, utilizando-se qualquer umas dessas alternativas, as equipes enfrentaro o mesmo problema: Como garantir a qualidade do software que est sendo construdo, manter todo o trabalho realizado pela equipe integrado, automatizar os testes, identificar os problemas assim que eles ocorrem e acelerar as correes? A Integrao Contnua um conjunto de tcnicas que podem ser utilizadas para ajudar a resolver essas questes. Segundo Martin Fowler (2006),

A Integrao Contnua uma pratica de desenvolvimento de software na qual os membros de um time integram seu trabalho frequentemente, geralmente, cada um integra pelo menos uma vez ao dia podendo haver mltiplas integraes por dia. Cada integrao verificada automaticamente (incluindo testes) para detectar erros de integrao o mais rpido possvel. Muitos times acham que essa abordagem leva a uma significante reduo nos problemas de integrao e permite que um time desenvolva software coeso mais rapidamente. Martin Fowler

A importncia de um estudo sobre este tema justifica-se pelo crescente interesse do governo e das empresas privadas por softwares que sejam desenvolvidos com mais qualidade, mais rapidamente, com um custo menor, que atendam as necessidades para os quais foram idealizados e que possuam qualidade suficiente para competir no mercado internacional.

Trata-se de um mercado de nmeros impressionantes. Mesmo com a desacelerao da economia nos Estados Unidos e a crise na Europa, o mercado brasileiro de Tecnologia da Informao e Comunicao (TIC) continuar crescendo em 2012. Pelas anlises do instituto de pesquisas Gartner, mercados emergentes de TI como o Brasil devero crescer acima da mdia global para 2012, estimada em 4,6%. O setor de TI no Pas registrar elevao de mais que o dobro, podendo alcanar taxas acima de 10%. Os investimentos na rea para 2012 esto previstos em 143,8 bilhes de dlares. At 2015, o Gartner projeta que o mercado brasileiro de TI experimentar uma taxa de crescimento anual de 9,9%. Ainda segundo a consultoria, as companhias da Amrica Latina vo investir 384 bilhes de dlares em TI at 2015 e o Brasil responder por mais de 40% dos negcios.

3 OBJETIVOS

3.1 OBJETIVO GERAL

O resultado pretendido por este estudo demonstrar como a correta aplicao das prticas de Integrao Contnua pode ajudar a antecipar a identificao dos problemas, facilitar a manuteno, promover a integridade dos produtos e garantir a qualidade do software.

3.2 OBJETIVOS ESPECFICOS

Identificar e descrever as reas do processo de desenvolvimento em que a Integrao Contnua atua ajudando a garantir a qualidade do software; Identificar as melhores prticas a serem utilizadas, para cada rea, quando se implanta a Integrao Contnua em um time desenvolvimento; Para cada melhor prtica identificada definir quais caractersticas devero ser atendidas para que se possa consider-la aplicada plenamente; Identificar, para cada rea, quais ms prticas ou vcios de desenvolvimento so prejudiciais e devem ser evitados; Identificar e descrever que tipos de ferramentas podem ajudar a automatizar o processo de Integrao Contnua; Definir um fluxo bsico de trabalho a ser seguido pela equipe de desenvolvimento de forma a garantir a correta implantao da Integrao Contnua;

4 PROCEDIMENTOS METODOLGICOS

4.1

CAMPO DE ESTUDO

Segundo Rauen (2002) define, um estudo de caso uma anlise profunda de um ou de poucos objetos, que busca retratar a realidade de forma completa e profunda, de modo a permitir o seu amplo e detalhado conhecimento. Tendo esse ensinamento como guia, a caracterizao do estudo deste trabalho ser uma pesquisa na forma de um estudo de caso EXPLICATIVO. Seu objetivo identificar porque determinadas tcnicas da Integrao Contnua funcionam e como se aplicam. Schiffman e Kanuk (2000, p. 26) ensinam que um plano de amostragem deve responder s seguintes questes: quem pesquisar e quantos pesquisar (o tamanho da amostra). A deciso de quem pesquisar exige que a populao seja definida de modo que uma amostra adequada possa ser selecionada. Yin(2006) assinala que a definio do estudo de caso a ser analisado est relacionada maneira como voc definiu as questes iniciais da pesquisa. O universo de estudo desta pesquisa compreende os integrantes de uma equipe formada por 10 desenvolvedores, 2 analistas de sistema e 1 arquiteto que so responsveis pelo cdigo-fonte de um sistema de gerenciamento de entregas do tipo SEDEX. A escolha da amostra nessa pesquisa ser de carter no-probabilstico. Na amostra no-probalstica intencional, estamos interessados na opinio de determinados indivduos da equipe, mas que no so representativos da mesma. Portanto, no nos dirigimos massa, mas queles elementos que, pela funo desempenhada ou cargo ocupado, vo fornecer maiores subsdios soluo do problema de pesquisa levantado, conforme orientam Lakatos e Marconi (1991).

4.2 INSTRUMENTOS DE COLETA DE DADOS

Os instrumentos de coleta de dados adotados neste trabalho so descritos no quadro a seguir.

Instrumento de coleta de dados

Universo pesquisado

Finalidade do Instrumento

Desenvolvedores e analistas de Entrevista sistemas

Identificar que melhorias podem ser obtidas com a implantao da Integrao Contnua, quais dificuldades sero enfrentadas e o papel de cada um

Observao Direta ou do participantes

O ambiente a ser observado ser a fbrica de software, durante os dias normais de trabalho Relatrios de auditoria do cdigo-

Identificar como a equipe est lidando com a implantao da Integrao Contnua Identificar quais os problemas do cdigo-fonte e se eles esto sendo tratados

Documentos

fonte

Dados Arquivados

Os insumos so os prprios artefatos gerados pelo desenvolvimento (casos de usos, cdigo-fonte, diagramas, etc.) e que se encontram no repositrio da fbrica

Identificar o tamanho do software desenvolvido e o nmero de erros em funo de cada tipo de artefato

Quadro 1- Instrumento de coleta de dados. Fonte: Unisul Virtual, 2007.

5 APRESENTAO E ANLISE DA REALIDADE OBSERVADA

Esse estudo est sendo desenvolvido em uma pequena empresa de desenvolvimento de software que presta servios principalmente para rgos governamentais. Trabalhando em regime de outsourcing ela recebe solicitaes que podem ser softwares completos ou apenas componentes para serem integrados a sistemas maiores j existentes. A empresa, segundo seu plano estratgico, tem a misso de fornecer solues personalizadas e ferramentas para ETL, do ingls Extract Transform Load (Extrao Transformao Carga). A funo dessas ferramentas permitir a extrao de dados a partir de diversas origens (outros sistemas, arquivos, banco de dados, etc.), a transformao desses conforme regras de negcios (opcional) e, por fim, a carga (em bancos de dados, por exemplo). No caso da empresa, ela tem buscado se especializar em arquivos texto contendo grandes volumes de dados, gerados a partir de sistemas rodando na alta plataforma (Mainframe) para carga em sistemas rodando em baixa plataforma (Windows/Linux). Esses dados, aps processados, serviro de insumo, principalmente, para sistemas de Data Mining. Segundo Fayyad 1996, Data Mining trata-se do "processo no-trivial de identificar, em dados, padres vlidos, novos, potencialmente teis e ultimamente compreensveis". Foi escolhida para anlise uma das equipes de desenvolvimento de software. A metodologia de desenvolvimento utilizada pela equipe do tipo gil baseada em SCRUM. As Metodologias geis tornaram-se populares a partir de 2001 quando especialistas em processos de desenvolvimento de software representando os mtodos Scrum [Schwaber e Beedle (2002)], Extreme Programming (XP) [Beck (1999)] e outros, estabeleceram princpios compartilhados por todos esses mtodos. Foi ento criada a Aliana gil e deu-se o estabelecimento do Manifesto gil [Agile Manifesto (2004)].

A equipe em questo possui um chefe de equipe, um analista de sistemas, um arquiteto e cinco desenvolvedores e est organizada da seguinte forma:

Em relao a TI a equipe utiliza equipamentos prprios. Foram adquiridas 8 estaes de trabalho com processadores Intel Core i3, 4GB RAM, HD de 250GB e monitores de 21 polegadas. Os sistemas operacionais utilizados so o Windows 7 Professional(Chefe da equipe e Analistas) e Linux Debian Mint 11(Arquiteto e Desenvolvedores). Pelo cliente, foi disponibilizado um banco de dados DB2, um servidor de aplicao e uma sala que ser utilizada at a concluso do desenvolvimento. Concludo o desenvolvimento essa estrutura ser desmontada e a manuteno durante a fase de garantia ser feita remotamente, via VPN(Virtual Private Network). A plataforma adotada foi o Java/J2ee 6 ou superior rodando em servidores de aplicao Oracle Weblogic. As interfaces de tela so desenhadas e renderizadas por componentes JSF. Os desenvolvedores utilizam o Eclipse (Helios) como IDE de desenvolvimento. O repositrio para o cdigo-fonte e documentao dos sistemas est em um servidor Subversion fornecido pelo cliente. Acompanhando o trabalho e entrevistando alguns membros da equipe pudemos identificar algumas ms prticas adotadas e os problemas delas decorridos. Com relao rea de trabalho (workspaces) cada desenvolvedor utiliza a sua, porm, algumas vezes vimos ocorrer o compartilhamento ou a cpia da rea de trabalho entre os desenvolvedores. Em conversa com um deles ele nos disse que demora muito montar uma workspaces do zero a partir do svn... so muitos projetos para lembrar... acho mais rpido copiar de algum. Cada desenvolvedor, em sua estao de trabalho, montou a estrutura de diretrios que achou mais conveniente e no existe uma padronizao nesse sentido. Apesar de existir um repositrio de cdigo-fonte no subversion no existe o hbito de se aplicar (fazer o commit) frequentemente das alteraes nem obrigatrio o uso de

comentrios quando isso ocorre. Perguntado sobre isso um dos desenvolvedores relatou que eu prefiro trabalhar o dia inteiro e s subir o cdigo ao fim do dia. A estrutura das linhas de desenvolvimento dentro do subversion confusa e difcil de manter, alm da principal (trunk) existem diversos troncos (teste, homologao, produo, bugs, etc.) que so mantidos sincronizados atravs de um processo manual e por isso sujeito a falhas. Quando no aplicadas corretamente alteraes muitas correes e melhorias se perdem. O arquiteto responsvel nos informou que no h muito que se fazer porque os requisitos no caminham em sincronia com o desenvolvimento, existem ainda os defeitos a serem corrigidos em produo e as vrias mudanas solicitadas pelo cliente o tempo todo. No existe uma poltica para se nomear as verses (label) e quase impossvel, por exemplo, recuperar uma verso anterior dos produtos que seja funcional. Essa situao foi identificada analisando-se a estrutura do svn. Questionado se seria possvel obter uma determinada verso dos aplicativos que fosse funcional o arquiteto responsvel relatou que no impossvel mas seria bastante trabalhoso e no haveria garantias de que a verso funcionaria. O build dos produtos feito manualmente pelo arquiteto bem como os merges necessrios entre as linhas de desenvolvimento. Segundo o arquiteto, esse um trabalho estressante, que toma muito de seu tempo e que est sujeito a erros e outros tipos de problemas, por exemplo, ele nos relatou que j precisou se ausentar duas vezes por motivo de sade e isso acabou prejudicando o andamento do trabalho. Cada desenvolvedor responsvel por obter (no caso baixar da internet) as bibliotecas necessrias para compilar os projetos, no existe um controle sobre as verses utilizadas. Os desenvolvedores disseram que preferem sempre trabalhar com as ltimas verses das bibliotecas por isso esto sempre baixando quando uma nova lanada. Um dos desenvolvedores possui conhecimento em banco de dados e o responsvel por fazer as alteraes nas tabelas e outras estruturas do banco. Segundo ele no existe uma poltica formal para documentar essas alteraes e nem sempre possvel rastrear o histrico delas. Por conta prpria ele criou um arquivo em sua estao local vai colocando registrando nele todas as alteraes, da seguinte forma, ele coloca a data em que rodou e o script que foi executado. Alguns poucos testes unitrios so escritos pelos desenvolvedores, porm, eles no esto integrados ao processo de build, ou seja, no so executados em nenhum momento durante o build dos produtos. O cdigo documentado via javadocs mas essa documentao incompleta e nunca gerada junto com o build.

No existe um feedback dos builds para a equipe, nem quando ele funciona, nem quando ocorrem erros. Em relao ao clima na equipe, observou-se, nas visitas realizadas, que o nvel de stress elevado devido a problemas como a perda de alteraes e a dificuldade de se manter o banco de dados atualizado. Existem tambm os problemas causados pela indisponibilidade do arquiteto para ajudar e acompanhar a resoluo dos problemas. Isso tem ocorrido por causa do tempo tomado dele pelas tarefas de manuteno de cdigo e gerao de builds realizadas diariamente. As tarefas so dificultadas tambm pela grande quantidade de cdigo que precisa ser analisada para se fazer corretamente o merge entre as linhas de desenvolvimento. A equipe como um todo est com suas tarefas atrasadas devido ao tempo gasto corrigindo-se os problemas no identificados durante o build e isso est causando uma perda de receita importante para a empresa e aumentando o nvel de presso sobre a equipe e a insatisfao do cliente. Como pontos positivos, identificamos que a equipe est disposta a entender os problemas e fazer as mudanas necessrias. A gerncia est atenta e quer participar do processo e o cliente tambm entende a importncia de mudanas e implantao de novos processos. O quadro a seguir resume os pontos fortes e fracos levantados durante a observao realizada na equipe em estudo.

Problema

Pontos fortes

Pontos fracos Falta a padronizao da workspaces

Justificativa A cpia de workspaces pode causar problemas de sincronizao com svn e perda de cdigo. Se a original tem problemas a cpia tambm os ter As alteraes se acumulam e quando o commit finalmente feito podem ocorrer conflitos de cdigo Quantos mais branches mais merges e maior possibilidade de perda de cdigo Sem marcos no codigo muito dificil se recuperar uma fotografia de um

Como minimizar os Os desenvolvedores problemas esto dispostos a decorrentes do colaborar compartilhamento/c pia de workspaces

Como minimizar os merges no cdigo

O subversion, utilizado pela equipe, permite um excelente controle da verso do cdigo-fonte

No existe a cultura de se subir as alteraes o tempo todo mas de maneira coerente No existe uma poltica que defina o ciclo de vida dos branches

um procedimento Como simplificar a estrutura de branches relativamente simples gerenciar branches no do repositrio svn Como tornar possvel recuperar uma determinada verso dos produtos a partir

O Subversion fornece No existe uma todas as ferramentas poltica para criar e necessrias para criar nomear as verses labels, tags e outras

do repositrio Como automatizar o processo de build

marcaes no codigofonte O subversion sozinho Hoje feito manualmente pelo no capaz mas existem ferramentas arquiteto que facilitam a automao dos processos de build No existe nenhuma padronizao das verses nem controle sobre o que est sendo usado

determinado momento do software Sujeito a falhas, toma tempo da pessoa envolvida, no d um feedback dos resultados Diversos problemas podem surgir quando utilizamos diferentes verses de uma mesma biblioteca

Como controlar as No uma boa veses das bibliotecas prtica colocar as utilizada bibliotecas no repositorio mas existem ferramentas que cumprem esse papel Como manter o controle das alteraes realizadas no banco As alteraes no banco esto salvas em arquivos texto que podem ser facilmente guardados no repositrio

Apenas o desenvolvedor responsvel possui uma lista das alteraes num controle feito manualmente

muito difcil rastrear as alteraes e retornar a um ponto anterior

Como garantir que os testes foram executados e verificar os resultados

simples escrever Nenhum teste testes unitrios, testes executado integrados so mais complexos. possvel integrar a execuo desses testes ao build Os javadocs so Nenhuma simples de escrever e documentao fcil integrar a gerada gerao deles ao build O envio de e-mail ou RSS so ferramentas simples mas extremamente eficazes nessa funo e podem ser integrados ao build Hoje, eventualmente, o arquiteto envia um e-mail avisando a equipe

Como nenhum teste executado os erros sero encontrados apenas durante a homologao pelo cliente ou, pior, em produo difcil identificar as funes dos componentes criados Surgem problemas de comunicao e demora nas tomadas de decises relacionadas ao build

Como gerar e manter atualizada a documentao dos produtos Como manter todos informados sobre os builds

6 PROPOSTA DE SOLUO DA SITUAO PROBLEMA

Nesta seo sero apresentadas propostas de melhoria, os resultados esperados e a viabilidade da proposta.

6.1

PROPOSTA DE MELHORIA PARA A REALIDADE ESTUDADA

A partir da situao analisada, sugere-se a alterao de alguns processos existentes, a implantao de novos, baseados em boas prticas reconhecidas e adotadas pelo mercado, a utilizao de ferramentas que possam automatizar as tarefas e um plano de treinamento. Acreditamos que esse conjunto de aes, uma vez adotado corretamente, tem o potencial de minimizar os problemas identificados. Nessa proposta apresentaremos uma soluo para cada um dos problemas identificados. As solues propostas envolvero a alterao de um ou mais processos relacionados situao identificada e a implantao de ferramentas para automao (quando se aplicar). As ferramentas que vamos sugerir atuam, pela suas caractersticas, na soluo de vrios dos problemas identificados, por isso, antes de apresentarmos as solues faremos uma apresentao sucinta de cada um das ferramentas e na soluo descreveremos que caracterstica da ferramenta se aplica naquele contexto, quando for o caso. Alm disso, o que propomos aqui tambm uma mudana de cultura dentro da equipe atravs da implantao das tcnicas de integrao contnua. A primeira e principal ferramenta que estamos sugerindo o Apache Maven, ou simplesmente Maven, mantido pela Apache Software Foundation. Trata-se de uma ferramenta para gerenciamento e automao de projetos em Java que possui um modelo de configurao simples de manter, baseado no formato XML. O Maven utiliza uma construo conhecida como Project Object Model (POM). O POM um arquivo XML, geralmente chamado pom.xml, em que descrevemos todo o processo de construo de um projeto de software, suas dependncias, outros mdulos e componentes e a sua sequncia de construo. O Maven contm tarefas pr-definidas que realizam funes bem conhecidas como compilao e empacotamento de cdigo.

O Maven foi construdo para trabalhar em rede e pode baixar plugins de diversos repositrios. Ele disponibiliza suporte nativo para a recuperao de arquivos deste repositrio, e para a incluso dos artefatos resultantes no final do processo. Um cache de artefatos atua como ponto de sincronizao dos artefatos de um projeto local. Todas as solues propostas comeam a partir da implantao do Maven em todos os projetos da fbrica. Somente a partir da as outras ferramentas a serem propostas podero realizar suas tarefas. A segunda ferramenta que estamos propondo o Apache Continuum. Trata-se, na verdade, de um servidor de integrao contnua que permite a criao de builds automatizados, gerenciamento das releases, segurana baseada em roles e integrao com diversas ferramentas de gerenciamento de builds como o Maven e o Ant. Ele executa os mesmo papel do Hudson, uma ferramenta tambm de qualidade reconhecida pelo mercado. Estamos sugerindo o Apache Continuum devido facilidade de integrao com as outras duas ferramentas, tambm mantidas pela Apache Software Foundation. Por ltimo, temos o Apache Archiva. um software de gerenciamento de repositrios que permite a criao e a manuteno de repositrios de artefatos pessoais ou de toda a empresa. de extrema utilidade quando utilizamos ferramentas, tais como Maven, Continuum ou o ANT. O Archiva oferece vrios recursos, dentre os quais repositrio remoto, gerenciamento de acesso de segurana, construo de artefatos de armazenamento, distribuio, navegao, indexao e relatrios de uso.

Nos prximos itens descreveremos as solues, como se aplicam as ferramentas citadas e quais processos sero alterados e ou melhorados.

a) Soluo para minimizar os problemas decorrentes do compartilhamento/cpia de workspaces

Para solucionar esses problemas estamos propondo uma mudana na mentalidade da equipe e no processo. Primeiro, devero ser criadas uma ou mais workspaces padro a serem utilizadas pela equipe. Essa workspace dever ser guardada em um servidor de arquivos e sempre que um novo membro chegar equipe ou sempre que algum precisar dever utilizar essas workspaces. Junto com as workspaces devero ser publicados no servidor de arquivos documentos que expliquem como fazer a instalao e as configuraes necessrias.

b) Soluo para minimizar os merges no cdigo

O subversion, servido de controle de verso utilizado pela equipe, permite um excelente controle da verso do cdigo-fonte e no h necessidade de troc-lo, no entanto, precisamos mudar alguns hbitos. A equipe dever ser orientada e treinada para subir as alteraes diversas vezes durante o desenvolvimento. As alteraes quando se acumulam tendem a causar problemas de merge e conflitos. Ainda como parte da soluo teremos o Apache Continuum configurado para executar diversos builds dirios. Isso d uma maior segurana equipe porque se algum problema for detectado pelo Apache Continuum todos sero notificados tornando possvel resolver rapidamente os problemas.

c) Soluo para simplificar a estrutura de branches do repositrio

Estamos propondo a criao de uma poltica que defina o ciclo de vida dos branches e que permita diminuir o nmero de branches. A equipe dever ser orientada e treinada para utilizar apenas um branch para desenvolvimento. Quando chegar o momento dos testes integrados dever ser criado um branch de testes que ser removido assim que os testes forem concludos. Qualquer correo feita no branch de testes dever se refletido no de desenvolvimento. Para homologao pelo cliente dever ser criado um branch de homologao. Aps o trmino da homologao, as alteraes devero ser refletidas em desenvolvimento, ser criado um label para a verso homologada e o branch de homologao ser removido.

d) Soluo que torna possvel recuperar uma determinada verso dos produtos a partir do repositrio

A soluo para recuperao das verses depende dos labels citados na soluo anterior. So eles que tornaro recuperar as verses a partir do controlador de verses.

e) Soluo para automatizar o processo de build

A partir do momento em que os projetos so configurados para utilizar Apache Maven torna-se possvel automatizar todo o processo de build. O Apache Continuum ser o responsvel pela execuo dos builds seguindo o agendamento proposto e pela notificao de toda a equipe nas situaes em que ocorrer algum problema. Caber equipe definir qual o agendamento mais adequado e que tipos de notificaes devero ser enviadas. O arquiteto ser responsvel por implementar esse agendamento no servidor de integrao contnua.

f) Soluo para controlar as verses das bibliotecas utilizadas

O Apache Archiva ser o responsvel por gerenciar todas as bibliotecas a serem utilizadas. Caber ao arquiteto definir quais verses devero ser utilizadas e configurar essas dependncias para cada projeto nos respectivos arquivos pom.xml. A partir da, tanto o build automtico quanto equipe de desenvolvimento utilizaro apenas as verses autorizadas.

g) Soluo para manter o controle das alteraes realizadas no banco

Cada alterao a ser feita no banco de dados dever possuir dois arquivos. O primeiro deles a alterao a ser feita, o segundo, faz o caminho contrrio, desfazendo a alterao feita. Todos os arquivos devero seguir uma nomenclatura padro a ser definida pela equipe e devero ser numerados. Dever existir um documento que indique quais arquivos j foram processados, quando e o responsvel pela execuo.

h) Soluo para garantir a execuo dos testes, verificar e reportar os resultados

Uma vez que todos os projetos esto configurados para utilizar o Apache Maven torna-se possvel automatizar os testes. A equipe dever definir o que dever ser testado e escrever os testes correspondentes. O Apache Continuum ser responsvel por executar todos os testes criados, juntamente com o build automtico, e reportar os resultados. Quando algum

teste falha o build como um todo falha tambm e esse comportamento que ajuda a garantir a qualidade do software porque os erros so reportados rapidamente e tem que ser resolvidos rapidamente ou o build no funcionar (estar quebrado).

i) Soluo para manter atualizada a documentao dos produtos

A linguagem Java possui uma ferramenta poderosa para documentar o cdigofonte, trata-se do javadoc. A equipe dever ser orientada e treinada para documentar todo o cdigo utilizando as tags javadoc de maneira correta e de acordo com os padres a serem definidos pela equipe. O Apache Maven dever ser configurado para gerar essa documentao juntamente com a construo do projeto assim, sempre que o Apache Continuum executar o buil automtico, ser gerada a documentao atualizada de todo o software.

j) Soluo para manter todos informados sobre os builds

A Apache Continuum, responsvel pelos builds automticos, possui diversos mecanismos de notificao. Alm do tradicional email, podemos utilizar SMS ou at mesmo programas de comunicao instantnea tais como GTalk ou MSN.

6.2

RESULTADOS ESPERADOS

A partir das propostas de melhorias espera-se diminuir a incidncia dos problemas aqui identificados, o aumento da produtividade devido automao dos processos, a melhora na comunicao entre os membros da equipe, maior agilidade na correo dos problemas e o aumento na qualidade do software produzido.

a) Soluo para minimizar os problemas decorrentes do compartilhamento/cpia de workspaces

Com a soluo proposta espera-se o fim dos problemas causados pelo compartilhamento das workspaces e o aumento da produtividade. O processo dever se tornar mais transparente e simples, principalmente para os novos membros da equipe.

b) Soluo para minimizar os merges no cdigo

Espera-se que a soluo proposta diminua drasticamente a necessidade de merges e que, quando houver necessidade um merge manual, a dificuldade seja bastante reduzida. previsto tambm que as horas poupadas por essa soluo possam ser usadas pela equipe, principalmente o arquiteto, no desenvolvimento de outras solues e produtos.

c) Soluo para simplificar a estrutura de branches do repositrio

A poltica definida, se aplicada corretamente, simplificar bastante a manuteno dos branches. Qualquer membro da equipe dever ser capaz de entender o funcionamento da estrutura poder at substituir eventualmente o arquiteto quando necessrio.

d) Soluo que torna possvel recuperar uma determinada verso dos produtos a partir do repositrio

Espera-se que equipe tenha sobre o software e sobre as verses um controle que no possvel antes das alteraes propostas. Se tudo for como esperado, ser possvel se obter a qualquer momento qualquer verso que for necessria, a partir do controlador de verses.

e) Soluo para automatizar o processo de build

Espera-se um aumento na produtividade da equipe como todo, principalmente da equipe de arquitetura e de testes. Mesmo a equipe de desenvolvimento ser beneficiada pela facilidade de identificao dos erros de maneira muito mais rpida e precisa.

f) Soluo para controlar as verses das bibliotecas utilizadas

Espera-se o fim de todos os problemas relacionados s verses dos componentes utilizados pela equipe no desenvolvimento do software.

g) Soluo para manter o controle das alteraes realizadas no banco

O resultado esperado um controle muito mais preciso de tudo o que for alterado no banco, a reduo de problemas causados por alteraes que precisam ser desfeitas e um histrico apurado de tudo o que foi feito.

h) Soluo para garantir a execuo dos testes, verificar e reportar os resultados

Espera-se o aumento da produtividade da equipe e da qualidade do software produzido. Tambm esperamos uma maior agilidade na identificao dos problemas e sua correo.

i) Soluo para manter atualizada a documentao dos produtos

Aqui esperamos que a documentao sempre atualizada seja til para que a equipe como um todo conhea melhor o software, principalmente os membros novos. Por outro lado, mesmo outras equipes da empresa, como de vendas, por exemplo, podero se beneficiar de uma documentao atualizada e sempre disponvel.

j) Soluo para manter todos informados sobre os builds

Esperamos um aumento na agilidade da tomada de decises, uma melhora significativa da comunicao entre os membros da equipe. Outro ganho ser a gerao de um histrico bastante completo das ocorrncias que poder ser utilizado na melhoria dos processos.

6.3

VIABILIDADE DA PROPOSTA

As solues aqui propostas so relativamente simples de serem aplicadas. Nota-se que toda a empresa est envolvida no processo e existe boa vontade para aceitar as mudanas, muito embora haja a resistncia de alguns membros s mudanas que refletem sobre rea de desenvolvimento principalmente. Do ponto de vista do custo envolvido, a empresa dever arcar apenas com a aquisio de um novo computador que ser utilizado como servidor de integrao contnua. Os softwares aqui sugeridos so todos de uso livre, inclusive de cdigofonte aberto, portanto, no h custo de lincenciamento.

Quanto ao conhecimento necessrio para a implantao a empresa tem duas opes: contratar uma consultoria externa que prover o treinamento necessrio a um dos membros da equipe ou solicitar que um ou mais arquitetos estudem as ferramentas por conta

prpria e faam a instalao e configurao. Ambas as alternativas tem prs e contras e caber empresa identificar a melhor opo para seu caso. Vale lembrar que so ferramentas que possuem ampla documentao disponvel, gratuitamente, na internet.Existem tambm livros que tratam desse tema, inclusive, usando as ferramentas aqui sugeridas.

7 CONSIDERAES FINAIS

Na realizao deste trabalho buscou-se entender os problemas que foram relatados pela equipe desenvolvimento e encontrar as solues mais adequadas para resolvlos. Aumentar a produtividade, melhorar a comunicao entre os membros, ajudar a reduzir o re-trabalho, reduzir o trabalho repetitivo, o nmero de falhas e diminuir o stress da equipe como um todo.

Foi um desafio conseguir identificar as causas dos problemas e quais ferramentas poderiam efetivamente trazer ganhos equipe da maneira que fosse mais rpida e segura, no entanto, acreditamos que, fazendo uso das solues aqui propostas, a empresa obter ganhos de qualidade a mdio e longo prazo que se refletiro por muito tempo e em todos os produtos da empresa.

Foram encontrados problemas e propostas solues. A partir da implantao das solues propostas velhos problemas sero resolvidos e novos surgiro, nessa hora, deveremos reiniciar o processo que foi feito at aqui, e da mesma forma que fizemos antes identificar os problemas e suas solues. Esse ciclo garante a evoluo e a melhoria dos processos e dos produtos produzidos.

REFERNCIAS

LOHN, Joel Irineu. Metodologia para elaborao e aplicao de projetos: livro didtico. 2 ed. rev. e atual. Palhoa: UnisulVirtual, 2005. 100 p. RAUEN, Fbio Jos. Roteiros de investigao cientfica. Tubaro: Unisul, 2002. BRESSAN, F. O mtodo do estudo de caso. Disponvel em: <http://www.fecap.br/adm_online/art11/flavio.htm>. Acesso em: 10 dez. 2006. FOWLER, Martin. Continuous Integration. Disponvel em: < http://martinfowler.com/articles/continuousIntegration.html>. Acesso em: 26 maio 2012 TIOBE. TIOBE Programming Community Index for May 2012. Disponvel em: < http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html>. Acesso em: 26 maio 2012 Norma NBR ISO 9000-2005. Disponvel em: < http://pt.scribd.com/doc/52238836/NBR-ISO-9000-2005>. Acesso em: 26 maio 2012 YIN, R. K. Estudo de caso: planejamento e mtodos. Porto Alegre: Bookman, 2005.Lakatos e Marconi (1991). Fayyad, Usama; Piatetski-Shapiro, Gregory; Smyth, Padhraic (1996) The KDD Process for Extracting Useful Knowledge from Volumes of Data. In: Communications of the ACM, pp.27-34, Nov.1996 Schwaber e Beedle. Scrum. Disponvel em: < http://www.scrum.org/ >. Acesso em: 26 maio 2012 Beck. Extreme Programming (XP). Disponvel em: < http://xprogramming.com/index.php>. Acesso em: 26 maio 2012 Vrios. Agile Manifesto (2004). Disponvel em: < http://agilemanifesto.org/ >. Acesso em: 26 maio 2012 BNDES. Horizonte de Investimentos 2007-2010: Uma Sntese. Disponvel em: http://www.bndes.gov.br/SiteBNDES/export/sites/default/bndes_pt/Galerias/Arquivos/conhec imento/liv_perspectivas/02.pdf. Acesso em: 26 maio 2012 Wikipedia. Apache Maven. Diponvel em :http://pt.wikipedia.org/wiki/Apache_Maven. Acesso em: 26 maio 2012