1. Introdução
1.1. O Sistema
Atualmente as solicitações de serviços de suporte feitas ao CPD da UFS são encaminhadas, de acordo com o tipo do serviço, ou ao setor de manutenção de microcomputadores e periféricos ou ao setor de redes.
Os dois setores trabalham de forma independente e contam com o auxílio de pequenos sistemas totalmente sem integração e incompletos do ponto de vista da satisfação dos requisitos mínimos desejados.
Em função das limitações dos sistemas utilizados para auxiliar o acompanhamento e a execução das solicitações de serviços (ordens de serviços) pendentes, estes setores ainda dependem em grande parte de anotações em papel. Conseqüentemente o controle e a eficiência no atendimento ficam prejudicados, pois entre outras coisas, não há como visualizar de forma estruturada, a situação das solicitações pendentes ou atendidas em determinado período, e muito menos como gerar estatísticas e relatórios destes dados.
1.2. Desenvolvimento Ágil
No início de 2001, durante um workshow em Snowbird, Utah, EUA, um grupo de profissionais veteranos na área de software decidiu reunir-se para discutir formas de melhorar o desempenho de seus projetos. Embora cada envolvido tivesse suas próprias práticas e teorias preferidas, todos concordavam que, em suas experiências prévias, os projetos de sucesso tinham em comum um pequeno conjunto de princípios. Com base nisso eles criaram o Manifesto para o Desenvolvimento Ágil de Software, freqüentemente chamado apenas de Manifesto Ágil, e o termo Desenvolvimento Ágil passou a descrever abordagens de desenvolvimento que seguissem estes princípios, que são apresentados a seguir:
· Indivíduos e interação entre eles mais que processos e ferramentas
· Software em funcionamento mais que documentação abrangente
· Colaboração com o cliente mais que negociação de contratos
· Responder a mudanças mais que seguir um plano
O manifesto reconhece o valor dos itens à direita, mas diz que devemos valorizar bem mais os itens à esquerda.
1.3. Extreme Programming (XP)
É a mais conhecida das abordagens para desenvolvimento de software que obedecem aos princípios do Manifesto Ágil.
É uma metodologia criada por Kent Beck no final dos anos 90. Vem fazendo sucesso em diversos países, por ajudar a criar sistemas de melhor qualidade que são produzidos em menos tempo e de forma mais econômica que o habitual.
A XP é composta por um pequeno conjunto de práticas, que giram em torno de alguns valores básicos, que diferem substancialmente da forma como se desenvolve software na grande maioria dos projetos tradicionais.
1.4. Test-Driven Development (TDD)
Está tornando-se umas das mais bem sucedidas técnicas de desenvolvimento da atualidade. O seu mantra que consiste em escrever um teste, escrever o código para fazer o teste passar e depois refatorar, resulta em resultados rápidos ao programador, o que aumenta a sua confiança e impõem ritmo ao processo de desenvolvimento.
Além disso, TDD dá muito mais certeza de que:
• Qualquer erro de codificação será identificado e corrigido rapidamente;
• A implementação está obedecendo aos requisitos;
• Qualquer nova iteração concluída e integrada ao sistema, caso gere algum erro, este poderá ser localizado e corrigido de forma ágil e fácil.
1.5. Refatoração
É o processo de alteração de um sistema de software de modo que o comportamento externo do código não mude, mas que sua estrutura interna seja melhorada. É uma maneira disciplinada de aperfeiçoar o código que minimiza a chance de introdução de falhas. Em essência, refatorar é melhorando o projeto do código após este ter sido escrito. [Fowler, Martin – Refatoracão]
O processo de Refatoração depende substancialmente da existência de testes de unidade para o código que está sendo refatorado. Sem estes testes, fica muito difícil ter a segurança de que a refatoração foi feita corretamente, ou seja, não inseriu nenhum erro num código que anteriormente estava funcionando.
1.6. Refatoração, TDD e XP
A Refatoração e a TDD são conceitos intimamente relacionados, ou seja, são dependentes e não funcionam corretamente uma sem a outra.
TDD pode ser utilizado sem refatoração, mas neste caso torna-se muito difícil fazer algo de qualidade(correto). Isto acontece porque com TDD codifica-se primeiro algo muito simples, só para passar nos testes que já foram escritos. Depois disso melhora-se o código via refatoração até que este fique com a qualidade mínima desejada.
Refatoração pode ser utilizado sem TDD, mas neste caso há uma grande possibilidade de ocorrerem problemas, principalmente se deixarmos para escrever os testes unitários depois. Pois é muito comum esquecermos de escrever algum dos testes ou escrevermos testes desnecessários. Ou seja, refatorar sem testes que monitoram as modificações no código, alertando quando e onde foram inseridos problemas no código que já estava funcionando, é no mínimo arriscado.
Já a XP utiliza fortemente, entre muitas outras práticas, a TDD e a Refatoração, e não pode ser aplicada corretamente sem estas técnicas de desenvolvimento. Apesar disso, a recíproca não é verdadeira, ou seja, o fato de se estar utilizando TDD e/ou Refatoração não dá nenhuma garantia de que também se está utilizando XP.
