1. Introdução

Após um período de seis meses de desenvolvimento com Programação Xp no projeto Colméia da biblioteca do IME, estava disposto a usar essas técnicas no projeto da empresa i.social. Mesmo não contando com uma equipe de programadores, acreditava que muitos valores da Xp poderiam ser bem aplicados na empresa i.social.

Nesta parte aplicativa do trabalho de conclusão de curso, apresentarei as fases do projeto realizado na empresa i.social, fazendo um paralelo entre as fases de um projeto utilizando Xp, exemplificando os conceitos teóricos envolvidos. Alguns conceitos da Engenharia de Software clássica também serão apresentados para efeito de comparação entre as duas metodologias de programação de software.

Finalizarei esta 2ª parte do trabalho com as conclusões a respeito das duas formas de desenvolvimento de software discutidas nesta monografia, tanto sob enfoque conceitual, mas principalmente sob o aspecto da aplicação prática dos mesmos no dia a dia das organizações.

2. Descrição sumária do projeto

A empresa i.social utilizava um sistema terceirizado para cadastro de vagas e de currículos de pessoas deficientes. Para proporcionar uma melhoria no setor de RH da empresa, buscando e recolocando pessoas de uma forma mais ágil e diminuindo gastos com a utilização de sistema terceirizado, acreditei que seria mais interessante desenvolver um software específico de RH que pudesse atender as necessidades da empresa i.social. E para desenvolver este software, busquei utilizar a Programação Xp como sendo a metodologia eleita para este projeto.
 
Para poder entender e melhor atuar no desenvolvimento deste projeto, conheci através do pessoal de RH da empresa i.social os sites dos sistemas que estavam sendo utilizados, das empresas terceirizadas. Nesta ocasião o pessoal de RH apontou as falhas e/ou melhorias que gostariam que fossem implementadas no novo software.

O projeto na empresa i.social deveria ser criado para cadastrar e pesquisar currículos e vagas e assim possibilitar que pessoas portadoras de deficiência física e/ou psíquica pudessem cadastrar seus currículos e buscar por vagas.

As premissas adotadas eram a de que os profissionais de RH poderiam cadastrar e buscar currículos além de cadastrar e monitorar empresas de RH que pretendessem acessar a base de dados de currículos da empresa i.social. As empresas usuárias do sistema poderiam inserir as vagas de emprego e buscar por currículos. E para controlar todo o sistema existiria a figura do administrador, que teria acesso a todas as informações cadastradas, com poder inclusive de alterá-las.

Desta forma, o trabalho de conclusão de curso buscou atender a necessidade do cliente – empresa i.social - através da construção de um software adequado para o pessoal de RH, utilizando alguns conceitos da Programação Xp para desenvolvê-lo.

3. Interação Empresa / Desenvolvedor

Um ponto muito discutido quando se trata do paradigma de Engenharia de Software clássica e Programação Xp é em relação ao papel do cliente no desenvolvimento.

A participação da empresa i.social no desenvolvimento do software, poderia ser pouco ativa, marcando-se apenas reuniões periódicas para apresentar o andamento do projeto em desenvolvimento e, depois da entrega do sistema, os funcionários de RH passariam a utilizá-lo e as alterações que não estavam na proposta original, bem como as melhorias detectadas, seriam então discutidas e realizadas.

Esse tipo de interação entre o cliente e desenvolvedor do software acontece em muitos desenvolvimentos de sistemas que utilizam a metodologia da Engenharia de Software clássica. Essa forma de interação está intimamente ligada com a técnica de análise de requisitos que a metodologia clássica propõe - produzir documentos com todos os detalhes e só então desenvolver o software - ou seja, o que foi definido no início é tomado como certo, não sendo necessária a participação ativa do cliente para discutir se as funcionalidades estão ou não sendo implementadas corretamente. Qualquer dúvida que se tenha no desenvolvimento bastaria elucidá-los nos documentos que contenham as especificações desenhadas início do projeto.

Apesar da minha pequena vivência e experiência profissional, eu sabia de antemão que a melhor solução seria a participação mais ativa da empresa no desenvolvimento do sistema, já que deixar todas as correções para o final poderia ser um trabalho árduo e caro e que poderia prejudicar muito os resultados da implementação do novo software. Já havia desenvolvido um outro projeto, onde o cliente passou a utilizar o sistema somente depois de pronto, e diversos pontos foram questionados, acarretando, além do aumento de custo do projeto, um desentendimento com o cliente e problemas com as alterações solicitadas, já que algumas modificariam diretamente a estrutura básica do sistema. Adicionalmente a tudo isto, ou como sua conseqüência, houve um grande atraso na entrega do projeto.

A fim de evitar ou minimizar tais acidentes de percurso, discutiu-se muito estes aspectos com a empresa i.social e após algumas conversas com a mesma, optou-se de comum acordo, pela idéia de ter uma participação mais ativa dela neste projeto, como preconiza o modelo de Programação Xp. Desta forma, foram agendadas reuniões entre os membros da empresa e o desenvolvedor do sistema, em média de uma a cada duas semanas.

Essas reuniões tiveram como objetivo apresentar pequenos releases do software ao cliente, e também aos profissionais de RH, e estes puderam usar e testar as funcionalidades desenvolvidas e já prontas naquele momento. Como resultado destas reuniões pode-se fazer um levantamento rápido das falhas que apareceram nas funcionalidades destes releases e sugestões de correções e melhorias.

Destas conversações com a empresa i.social, ficou claro e explícito que a mesma gostaria de algo rápido e que funcionasse bem.

4. Ciclo de vida do Projeto realizado na empresa i.social relacionado ao modelo de Programação Xp

Conforme acima mencionado, utilizou-se a metodologia de Programação Xp no desenvolvimento deste software para a empresa i.social e como amplamente explanado na 1ª parte deste trabalho de conclusão de curso (parte conceitual), a mesma seguiu os passos definidos neste método de produção de software como se verificará a seguir:
   
    4.1. Fase de Exploração

A Engenharia de Software clássica, como descrito em detalhes na 1ª parte deste trabalho, investe muito tempo nas fases de levantamento e análise de requisitos. Profissionais visitam as empresas para acompanharem o dia-a-dia dos seus funcionários e escrevem documentos detalhados e extensos que serão utilizados no desenvolvimento do sistema.

Os documentos desenvolvidos são as bases para transformar os processos diários não automatizados ou mal automatizados da empresa em funcionalidades do sistema, já que o objetivo básico do software, é automatizar os processos repetitivos – as rotinas - realizadas de forma não automatizadas ou mal automatizadas.
   
Já a Programação Xp, por outro lado, propõe investir menos tempo com levantamento e análise de requisitos. Escrevem-se histórias, normalmente em fichas, descrevendo as funções que a empresa utiliza ou deseja ver contida no sistema.

Depois de anotar todos os pontos importantes do processo em avaliação, fiz um levantamento das críticas ao sistema que a empresa i.social utilizava e das novas idéias que os usuários de RH gostariam de ver contemplado no software a ser desenvolvido. Comecei então a navegar pelo sistema terceirizado, para analisar as funcionalidades, as interfaces e as facilidades e dificuldades encontradas durante a navegação do mesmo. A partir daí, desenvolveu-se uma proposta simples mostrando à empresa i.social o fluxo do sistema com as páginas (uma vez que o sistema é via Internet) que fariam parte do mesmo.

Não pude investir muito tempo para desenvolver a proposta, analisando em detalhe todos os requisitos, entrevistando os funcionários e gerando um documento especificando tudo que seria necessário desenvolver, já que o cliente gostaria de algo rápido.

Desenhou-se em cada ficha uma tela do futuro sistema indicando suas funcionalidades e as estimativas de tempo para desenvolvê-las. Nestas fichas estão ocultas as implementações do sistema já que, normalmente, são feitas junto ao cliente e os detalhes da implementação é ocultado do mesmo.

Apesar de em muitos casos da Programação Xp o próprio cliente escreve essas fichas, neste projeto em particular, como o foi embasado no sistema que a empresa i.social utilizava, agregado de algumas novas funcionalidades específicas, eu mesmo as descrevi. Para fazer a estimativa do tempo total necessário que se consumiria no projeto, bastou somar os tempos de cada ficha.

Utilizando uma ferramenta da Microsoft chamada Visio, essas fichas foram transformadas em um fluxograma do processo. Abaixo, apresento algumas imagens que mostram o fluxo do sistema. Essas imagens foram usadas para um melhor entendimento entre os desenvolvedores e o cliente. Foram na realidade, o meio de comunicação entre as partes.

Funcionalidades disponíveis para o usuário

Funcionalidades disponíveis para a empresa

Se esse projeto fosse desenvolvido seguindo os padrões da Engenharia de Software clássica, ao invés de fichas com as telas e funcionalidades do sistema, criar-se-ia um extenso e detalhado documento, no qual estaria representado todos os requisitos do sistema.

A titulo de exemplificação, segue abaixo alguns requisitos funcionais e não-funcionais definidos para o projeto:
 
   Requisitos funcionais:

   1) O usuário do sistema, no caso, o portador de deficiência, poderá cadastrar e alterar o seu currículo para enviá-lo para as vagas cadastradas na base de dados do sistema e possibilitar que a empresa i.social e outras empresas busquem seu perfil. Podem também fazer perguntas para a empresa i.social.

   2 ) O administrador do sistema poderá gerenciar os profissionais de RH da empresa i.social que buscam os currículos dos usuários na base de dados do sistema. Cadastra, altera e remove esses profissionais.

   3) Os profissionais de RH da empresa i.social poderão cadastrar, alterar e remover currículos e vagas, assim como cadastrar, alterar e remover empresas de RH que usarão o sistema. Poderão também pesquisar currículos na base de dados do sistema e enviar currículos selecionados para empresas nas quais a i.social está oferecendo consultoria.

   4) Outras empresas de RH poderão ter acesso restrito ao sistema, podendo buscar currículos, cadastrar e gerenciar vagas. 

   Requisitos não-funcionais:

   1) Pode-se acessar o sistema de qualquer lugar do país.

   2) O sistema pode ser acessado por qualquer tipo de plataforma, não só plataforma Windows.

   3) O banco de dados somente deve ser acessado através do sistema desenvolvido e por usuários cadastrados ou em processo de cadastramento.

   4) O tempo de resposta do sistema precisa ser rápido para não deixar o usuário impaciente.

   5) O tempo de desenvolvimento do software deve levar em torno de 3 a 4 meses.

   6) O sistema precisa ser seguro. Cada tipo de usuário pode ter acesso somente às funcionalidades permitidas para seu nível de acesso, por exemplo, o usuário com o currículo cadastrado não pode ter acesso a opção de excluir currículo, pois essa opção não pertence a seu nível de acesso.

Além de criar as histórias, outra característica da fase de exploração em um projeto de Programação Xp são as análises que se fazem nas tecnologias para definir quais serão usadas durante o projeto. Abaixo estão visualizadas as análises das tecnologias que foram feitas para o projeto da empresa i.social.

Em projetos para a Internet, ou sistemas em geral, é necessário definir a linguagem de programação, o tipo de banco de dados, bem como as ferramentas de teste e de desenvolvimento.

4.1.1 Definição do Banco de Dados

Existem no mercado muitos e variados tipos de banco de dados e, para cada um, encontraremos aspectos positivos e negativos. A escolha de banco de dados para o projeto da empresa i.social foi pelo MySql, uma vez que este preenche os seguintes requisitos necessários do sistema:

- No quesito desempenho, o MySql é considerado um dos bancos de dados mais rápidos. Os desenvolvedores do MySql investem muito na agilidade das consultas e buscas nas tabelas.

- No quesito segurança, fator indispensável no sistema da empresa i.social, que contém dados sigilosos de diversas pessoas, o MySql é bastante seguro e estável contando com recursos que garantem sua integridade, possibilitando backup, restauração, controle de usuários e acessos, além da verificação e correção de tabelas corrompidas.

- Pode ser utilizado tranqüilamente em aplicações corporativas, oferecendo suporte para diversas linguagens de programação, como o Java.

- Outro fator importante é a gratuidade do MySql, reduzindo os custos na implantação do projeto.

4.1.2. Definição da linguagem de programação

Existem diversas linguagens de programação no mercado, como: Asp, JSP (Java Server Pages), PHP e Perl. Um ponto indiscutível é que o sistema seria desenvolvido com uma linguagem orientada a objetos para diminuir seu custo, já que facilitam a “refatoração” e a manutenção, além de outras vantagens.

Apesar da curva de aprendizado em Java ser maior que a de PHP, Java seria mais vantajosa, uma vez que tenho alguns anos de programação com essa linguagem. Logo, não investiria muito tempo em aprender uma nova tecnologia. PHP é mais rápido para acesso ao banco de dados que JSP, mas é possível fazer otimizações que deixam as duas linguagens equiparadas. Desenvolvendo JSP com Velocity, por exemplo, ao invés de JSP puro, reduz-se bastante o tempo de acesso ao banco de dados.

A Internet só aceita páginas estáticas no formato html. Para desenvolver um sistema para a Internet, é necessário montar a página estática a partir de uma página dinâmica em tempo de execução. O Velocity monta a página muito mais rapidamente que o JSP, além de contar com uma melhor segurança.

Outras vantagens de se utilizar Java para projetos mais robustos são:

     • A manutenção se torna bem mais fácil, pelo fato de ser orientada a objetos.

     • Encontram-se muitos componentes reutilizáveis e livres para a plataforma Java, além de existir grupos de discussão muito antigos que trazem soluções para diversas dúvidas a problemas que um programador Java pode enfrentar.

As vantagens de Java em relação ao PHP fizeram com que se optasse por Java como a linguagem usada neste projeto.

O mundo Java é muito extenso, e atualmente conta com alguns frameworks que ajudam no desenvolvimento dos sistemas. O mais expressivo no mercado é o Struts. Ou seja, além da decisão da linguagem, foi necessário definir se o sistema seria feito com auxílio de um framework como o Struts ou não. No projeto Colméia, conheci o poder de organização desse framework e da facilidade para se refazer o sistema.

Um poderoso container (processa o Servelet - código Java - para que esses códigos sejam convertidos em páginas html estáticas) e uma tabela centralizada com todos os links do sistema é um dos principais fatores do seu sucesso.

A organização em três camadas utilizando o modelo MVC, “Model-View-Controller” (“Modelo-Visão-Controlador”), também deixa o sistema mais fácil para a etapa de manutenção do software.

Existem três formas de usar JSP com Java para a Internet, a saber: Modelo 1, Modelo 2 e modelo MVC [1],[5]. Modelo 1 e Modelo 2 são formas de utilização de JSP. Apesar de não serem os termos mais utilizados pela especificação J2EE da Sun, os desenvolvedores Java os utilizam muito.

   Modelo 1

O modelo 1 é utilizado em aplicações pequenas e simples e funciona da seguinte forma: o navegador faz acesso às páginas JSP diretamente, e estas fazem referência direta aos JavaBeans (Model). Os JavaBeans são processados (Controller), e com base no resultado gerado, o navegador mostra uma nova página (View) para o usuário.

O controle de fluxo das páginas é descentralizado. Cada página faz referência a uma próxima página e assim sucessivamente. É uma maneira de desenvolvimento rápida, mas que coloca em risco a fase de manutenção do software, podendo ser muito difícil fazer os reparos caso o sistema cresça com o passar do tempo.

   Modelo 2

São aplicações em JSP nas quais, ao invés dos navegadores terem acesso às páginas diretamente, é necessário passar por uma etapa anterior, um servelet, e este acessa a lógica de negócio controlando qual página deve ser exibida. Essa forma de utilização do JSP ficou conhecida como Modelo 2.

   Modelo MVC

O modelo MVC usa como base o Modelo 2, com a diferença de que força a separação do modelo, da visão e do controle de forma rígida. Muitas etapas do desenvolvimento do software são repetições de procedimentos já efetuados anteriormente. Este modelo tem por objetivo simplificar essas repetições, aumentando a produtividade, facilitando a manutenção, produzindo um software melhor.  Em detalhes, o MVC tem a seguinte estrutura:

   • Camada de Controle: manuseia a lógica do negócio, responsável pelo fluxo, qualidade e segurança das informações que o sistema utiliza. Faz o elo entre as camadas de negócio e apresentação. É o meio de campo entre as duas estruturas lógicas.

   • Camada de Modelo: é a lógica do negócio no sistema. O que o sistema realmente deve fazer se encontra esta camada.

   • Camada de Visão: É a interface do sistema, gerada a partir da requisição processada na camada de Controle. É uma casca que esconde por detrás toda a programação do software. Os formulários e relatórios mostrados na tela pertencem a esta camada.

Para o projeto de criação do software para a empresa i.social utilizou-se o Modelo 1. A decisão de utilizar JSP puro, ou Modelo 1, foi baseada nos fatos apresentados abaixo:

- Apesar de o sistema ter potencial, a priori, de ser desenvolvido em quatro fases, não seria um sistema muito robusto. Na realidade, ele é bem simples, precisando apenas fazer cadastros de currículos, vagas e pesquisa.
 
- Funcionalidades automatizadas e muito complexas não fazem parte do projeto.
 
- O tempo que seria gasto para montar toda a estrutura de desenvolvimento com o Struts, seria relativamente grande.

Apesar de ter programado durante seis meses com o Struts no projeto Colméia, percebi naquela ocasião, que minha equipe, que contava com bons programadores gastava muito tempo com a produção de uma página. Dificuldades com o Struts no projeto Colméia deixavam o programador algumas horas afastado da produção do software.

Segundo as recomendações da própria equipe criadora e mantenedora do Struts, para sistemas pequenos (de até vinte páginas), não é recomendada a sua utilização, especialmente por causa da adição de complexidade desnecessária. Para esses sistemas recomenda-se o Modelo 1.[18]

4.1.3. Servidor para a Internet

O sistema informado roda sobre o servidor Tomcat que é dos mais utilizados para aplicações em Java, e recomendado para o tipo de aplicação da empresa i.social.

4.1.4. Ferramenta de Desenvolvimento

Como o projeto seria desenvolvido em JSP utilizando classes em Java, o Eclipse era uma dos mais recomendados para este tipo de projeto. Elegeu-se a ferramenta Eclipse por ser uma ferramenta livre, originalmente criada pela IBM e com a possibilidade de aumentar suas funcionalidades padrões adicionando-se plugins.

A interface padrão do Eclipse oferece várias funcionalidades tais como:

   • Autocompletar e sintaxe highlight de código em Java (estruturas como “for”, “if” e variáveis tem cores diferenciadas para facilitar a programação).
  
   • Ferramenta de CVS para controle de versões.

   • Sistema Junit integrado para a realização de testes.

4.1.5. Ferramenta de Depuração

Foi usado o JUnit [19], que é um framework livre para construção e execução de testes unitários de classes em Java. É muito prático para criar testes automatizados, sendo que além da facilidade de implantação, já está integrado na ferramenta Eclispe.
 
Quando o programador gera um código de teste automatizado e executa-o no JUnit, as entradas são verificadas e os resultados obtidos possibilitam o programador ter conhecimento se o código está ou não bem implementado. A Programação Xp recomenda desenvolver o projeto orientado a testes, onde o teste é escrito antes de escrever o método.

Como comprovei na prática, no projeto Colméia, a melhora do código e a diminuição de erros que os testes automatizados causam, os métodos e as classes desenvolvidas no sistema da empresa i.social foram testados antes das implementações, como recomenda Xp.

Além do JUnit, existem outras ferramentas para depuração do sistema, não apenas do código mas da interface do sistema, mas nesse projeto, com o feedback do cliente e os testes padrões, não foi necessário investir tempo do projeto com novos tipos de testes.

4.1.6. Documentação do projeto

Basicamente, pode-se documentar o código descrevendo o que faz cada classe, cada método e cada módulo, ou documentar todo o sistema, não somente o código fonte, por exemplo, descrevendo todas as funcionalidades do sistema minuciosamente. A Programação Xp, diferentemente da Engenharia de Software clássica que entrega diversas pastas com os detalhes das funcionalidades do software para o cliente, não prioriza a documentação de todo o sistema, priorizando, por outro lado, um código que todos os envolvidos no projeto possam entender.

No projeto da empresa i.social não foi necessária a entrega de documentos com as especificações, mas o código precisava estar bem documentado. Para isso, sabemos que em Java, pode-se utilizar a documentação dos métodos, das classes e dos módulos via Javadocs. Javadoc é uma forma de comentário criada pela Sun para facilitar a geração da documentação da API do sistema. Quando um Javadoc é criado para um método, classe ou módulo, pode ser inserida uma pequena descrição do que ele faz. Pode-se também descrever o que cada parâmetro de entrada significa além das exceções, etc. Por meio desta ferramenta (Javadocs), é possível converter todos os comentários feitos no código do padrão Javadoc para páginas em html.

Logo, no projeto da i.social, comentários foram feitos por meio de Javadoc, provendo um código que programadores de Java poderão entender facilmente, como sugere as práticas de Xp relacionadas ao código fonte.

4.1.7. Modelagem do Banco de Dados

Existem algumas formas de se modelar o banco de dados. Pode-se criar diversos campos em uma tabela, tendo-se desta forma um ganho na velocidade de acesso aos dados, mas por outro lado, é difícil de se fazer a manutenção. Ou pode-se fazer o inverso, ou seja, criando-se tabelas separadas, perdendo velocidade de acesso, mas facilitando a manutenção.

Um dos valores da Programação Xp é o padrão de codificação. Fora o código em si, onde os programadores precisam seguir normas de codificação estabelecidas no início do projeto para desenvolverem as funcionalidades, o banco de dados também precisa seguir um padrão para facilitar o entendimento das tabelas e torná-las fáceis de manutenção e acesso.

No sistema da empresa i.social, utilizei o formato usado no mercado para atribuição dos nomes dos campos e das tabelas, por exemplo, para atribuir um nome a uma tabela, o padrão do mercado é “tabela_nomeDaTabela“

Na primeira fase do projeto, seria necessário desenvolver uma modelagem de dados para guardar as informações dos currículos dos usuários, informações dos dados dos funcionários de RH que acessam o sistema para buscar currículos, além das informações dos administradores do sistema; para isso, foram criadas três tabelas.

Eu poderia ter optado por uma estrutura menos esparsa, ou seja, transformado as três tabelas relacionadas em uma só tabela. Entretanto, como explicado anteriormente, ganharíamos eficiência, mas, por outro lado, seria uma grande confusão trabalhar como uma tabela enorme, com diversos campos. Fora a redundância dos dados daí decorrente, o que complicaria as inserções, as alterações e as eliminações de dados.

O sistema foi desenvolvido em etapas, sendo que novas tabelas podem ser inseridas ou tabelas existentes podem ser modificadas, mas segundo o valor da Programação Xp, “design simples”, precisamos pensar no presente, e no presente, as tabelas criadas estão funcionado perfeitamente com o sistema.

4.1.8. Desenvolvimento das Páginas em JSP

Normalmente um sistema resume-se em cadastramento, eliminação e atualização de dados, e busca dessas informações. No caso da empresa i.social foi necessário criar formulários para se inserir os dados (informações) que o cliente desejava que fossem preenchidos. A primeira parte do desenvolvimento foi criar a estrutura do formulário, a parte visual do sistema, o que o usuário vê pela Internet.

Segundo o valor “design simples”, como o sistema da empresa i.social foi desenvolvido de forma incremental, foi necessário criar uma interface simples, fácil de usar e que agrega as novas funcionalidades rapidamente. Para cumprir essa prática da Programação Xp, as páginas foram modeladas utilizando ferramentas do mercado que possibilitam o cumprimento desta prática.

O projeto da página foi feito utilizando o software Dreamweaver; que já existe há muito tempo no mercado, e tem funcionalidades que ajudam muito o desenvolvedor. O sistema usa o mesmo layout para todas as páginas, o que implica que o cabeçalho, o corpo e o rodapé das páginas devem seguir os mesmos padrões, como fonte dos textos, cores e menu.

Criou-se um arquivo do tipo Css “Cascading Style Sheets”, que são folhas de estilo para páginas da Internet que facilitam o desacoplamento entre visual e programação. Nestas folhas de estilo, definem-se todas as propriedades visuais da página. Ao invés de colocar a formatação dentro do código, o programador cria um vínculo para uma folha de estilo, procedendo de forma idêntica para todas as páginas do sistema. Quando se quiser alterar a aparência do sistema, basta modificar apenas um único arquivo, e automaticamente todas as páginas serão alteradas. Assim, é possível cumprir o valor de “design simples”, já que é possível alterar todo o layout do sistema, caso necessário, em pouco tempo.

Um segundo passo no desenvolvimento das páginas, foi fazer a validação dos campos antes de enviá-los para o banco de dados. Um campo de data de nascimento, por exemplo, não pode conter caracteres diferentes de números e barra, sendo assim, precisamos fazer a validação para reconhecer se o usuário digitou os caracteres permitidos ou não. Para fazer essa validação, foi utilizado o Javascript que é uma linguagem de programação criada pela Netscape em 1.995 para atender, principalmente, as seguintes necessidades:

   • Precisaria fazer a validação de formulários no lado do cliente.

   • Precisaria interagir com a página. Por isso foi feita como uma linguagem do tipo script.

   • Precisaria ser interpretada e não compilada.

   • Oferecesse suporte para expressões regulares.

O Javascript foi usado no projeto da i.social para criar funções que usam expressões regulares para analisar se as informações preenchidas pelos usuários estão de acordo com o formato requerido pelo sistema. Apesar de todas estas facilidades, pelo fato de se fazer a validação no lado do cliente (navegador), não se pode confiar plenamente na sua validação. Usuários mal intencionados podem desabilitar a função Javascript do navegador, burlando as regras de validação. Para solucionar esta fragilidade do Javascript costuma-se fazer validações no lado do servidor.

Mesmo que a Programação Xp não coloca foco no futuro, foi criado um método, no sistema da i.social, em Javascript para validar qualquer tipo de campo, mesmo que alguns tipos de campos não foram necessários no projeto. Isso só foi feito porque era muito simples, bastando colocar três ou quatro condições adicionais. Caso contrário, não seria implementado.

O terceiro passo no desenvolvimento, foi criar as classes em Java (“Beans”), com os métodos necessários, que recebem os dados do formulário, executam a lógica de negócio, e fazem o cadastro das informações no banco de dados.

De forma bem resumida, esses foram os três passos necessários para produzir uma página, que poderiam ser feitos em paralelo, não sendo necessário fazer exatamente na ordem descrita neste trabalho.

Muitos detalhes da implementação foram ocultados por não se constituírem no objetivo da monografia.

Agora serão apresentadas, em resumo, as idéias de programação em JSP, que são mais complexas que o CSS e o JavaScript.

JSP é uma tecnologia que permite tornar dinâmica uma página da Internet. Existem dois modos de desenvolvimento de páginas dinâmicas. Em termos estruturais, pode-se usar servlets diretamente para gerar as páginas em html, ou usar JSP, que será transformado em um servlet e depois em uma página em html.

A tarefa de projetar o layout da página é responsabilidade, normalmente, do Web Designer e inclui tarefas como a diagramação dos textos e imagens, aplicação de cores, criação da estrutura visual do site e dos links para navegação. Já o desenvolvedor para a Internet é responsável pela criação das funcionalidades que serão executadas em um site. O trabalho destes dois profissionais é integrado na criação de uma única página, mas durante o desenvolvimento, essas tarefas precisam estar separadas, evitando interferências. Ou seja, um profissional não deve alterar o que foi feito pelo outro profissional. A tecnologia Servlet nos dificulta atingir esse ideal e devido a esse problema de não separar programação e visão, a Sun desenvolveu uma tecnologia baseada em Servlets chamada de JSP.

Java Server Pages (JSP) são páginas em html que incluem código em Java e outras tags (métodos prontos) especiais. A parte dinâmica é gerada pelo código JSP e a parte estática da página pode ser projetada por um Web Designer, de modo que os dois trabalham separadamente na mesma página. A primeira vez que uma página JSP é carregada pelo container do JSP, o código em Java é compilado gerando um Servlet que é executado, criando uma página em html que é enviada para o navegador. As chamadas subseqüentes são enviadas diretamente ao Servlet que foi gerado na primeira requisição feita pela navegador, e não ocorrem mais as etapas de geração e compilação do Servlet.

4.2. Fase de Planejamento

Eleitas as tecnologias e após refazer algumas histórias do projeto, as etapas a seguir foram definidas:

   Fase I: Desenvolvimento de um sistema para cadastramento de currículos e sua busca.

   FaseII: Desenvolvimento do cadastramento de vagas e sua busca.

   Fase III: Desenvolvimento do sistema para cadastramento de empresas usuárias e seu controle de acesso.

   Fase IV: Idéias que poderiam surgir durante o projeto e, se aprovadas, esta fase se responsabilizaria pelo desenvolvimento das mesmas. 

4.3. Fase da Primeira Iteração

Apesar de não ser feito em duplas (como recomenda a metodologia Xp), já que fui o único programador do sistema, foram feitos testes no JUnit para avaliar as funcionalidades e após obter o resultado positivo, implementei-as como recomenda o modelo de Programação Xp.

Após três semanas de desenvolvimento, foi apresentada a primeira versão do sistema aos usuários de RH.

Cadastramento de Currículos

Busca de Currículos

Um profissional de RH usou o sistema durante a reunião e testou as funcionalidades implementadas, apontando sugestões e erros como, por exemplo, certos campos desnecessários.

4.4. Fase de Produção

Os erros e as sugestões geradas no primeiro release foram revistos e o código foi refeito. A partir desta fase, ao invés de usar o ambiente de teste local, foi usado o ambiente de teste disponibilizado pelo provedor, onde estão armazenadas as páginas do sistema. Nesta fase também foram realizadas reuniões com o cliente e algumas novas histórias foram feitas.

Mesmo em desenvolvimento e com poucas funcionalidades, a empresa i.social já podia, durante a fase de produção, usar o sistema via Internet para fazer os cadastros e as pesquisas de currículos. O objetivo era alimentar a base de dados e testar se as funcionalidades realmente apresentavam boa performance.

4.5. Fase de Manutenção

Com o início das demais fases, alguns métodos implementados na Fase I do projeto foram refeitos, e otimizações foram feitas para aumentar a velocidade de cadastramento e pesquisa dos dados. Como o sistema inicialmente foi desenvolvido localmente, foi utilizada uma forma de conexão com o banco de dados utilizando o Tomcat , que funcionava muito bem.

Quando o sistema foi para o servidor, os acessos ao banco de dados ficaram extremamente lentos e após pesquisa, descobriu-se que seria necessário mudar a forma de acesso ao banco de dados, e nesta fase foi realizada essa mudança.

Esta fase ainda está em aberto, uma vez que a empresa i.social continua propondo novas funcionalidades e ajustes no sistema.
 
4.6. Fase de Morte

Como a empresa i.social continua propondo novas funcionalidades e ajustes no sistema, não posso considerar o sistema finalizado, mas o período previsto para finalizar as funcionalidades estabelecidas no início do projeto, de 3 a 4 meses, foi finalizado dentro do prazo. Portanto, esta fase ainda não ocorreu.

5. Conclusões

Em junho de 1.996 a Fortune Magazine publicou um artigo com o título "The Trouble with Software Is ... It Sucks" (“Os problemas com os software”), descrevendo os resultados de uma pesquisa feita em 352 empresas desenvolvedoras de software, pesquisada pela Standish Group e os resultados são impressionantes: [7]

Foram analisadas 352 empresas somando um total de 8380 projetos:

- 31% de todos os projetos de software foram cancelados antes de serem finalizados;

- Apenas 16.2% de todos os projetos foram entregues no tempo planejado;

- 52;7% dos projetos foram entregues, porém com prazos maiores, custos maiores ou com menos funcionalidades do que especificado no início do projeto.

Segundo a própria Standish Group, o principal responsável por esses problemas, contribuindo com aprox. 40%, foram os erros e mudanças de requisitos no projeto.

Como já se comentou, a Engenharia de Software clássica investe muito tempo em levantamento e análise de requisitos com o objetivo de coletar todas as informações necessárias antes do desenvolvimento do software. Na prática é muito difícil obtê-las completamente.

Gasta-se muito nessa fase do projeto. Muitas vezes, quando ela termina, os custos e o tempo já inviabilizaram o projeto, causando o cancelamento do mesmo. Como mostram os números, 31% dos projetos foram cancelados antes de suas conclusões, onde de 40 a 50% dos 31% a análise de requisitos foi a responsável. Mesmo quando os projetos são concluídos, apenas 16,2% são entregues na data prevista, ou seja, o modelo de desenvolvimento de software utilizado atualmente tem um retorno muito baixo de sucesso em primeira instância. Em segunda instância, mesmo que os projetos são concluídos (52,7%), os custos e prazos não foram respeitados.

Mesmo que o cliente especifique muito bem o sistema, como o software será desenvolvido baseado nos documentos escritos, erros de interpretação podem levar a equipe a cometer erros graves nas funcionalidades. Além disso, na prática, muitas vezes a seqüência de fases definida pelo modelo em cascata não é respeitada, surgindo fases intermediárias e sobreposições de fases.

Outro ponto negativo é o fato de o cliente ter acesso ao software depois de um período longo de desenvolvimento. Erros que, se fossem vistos antes, poderiam levar pouco tempo para serem corrigidos, entretanto, como são descobertos posteriormente, o custo e o trabalho de correção pode ser aumentado de forma exponencial. Como mostraram as estatísticas, o custo de corrigir erros na fase de manutenção é vinte vezes maior que se descobertos no início do projeto.

Uma vantagem do modelo de Engenharia de Software clássica é a geração de um documento robusto contendo toda a especificação do software, que pode ser usado futuramente, por exemplo, por programadores que não fizeram parte do projeto original e precisam entender o fluxo do sistema. Obviamente, que para isto ocorrer, é necessário que este documento seja muito bem feito, bem como seja atualizado sempre que houver alguma alteração em qualquer parte do projeto.

Porém, apesar de a Engenharia de Software clássica ser muito utilizada, é possível mostrar, por meio dos dados estatísticos, o baixo rendimento deste método ao se produzir um software. Uma justificativa para um grande número de adeptos a esse modelo seria a falta de opção de metodologias alternativas de desenvolvimento, metodologias estas mais vantajosas que a Engenharia de Software clássica.

Entretanto, essa realidade começou a mudar nos últimos anos com o surgimento das metodologias ágeis. A metodologia Xp faz parte do grupo dessas metodologias, e os projetos que as estão utilizando têm mostrado, na prática, a eficácia do modelo. Clientes satisfeitos e software bem desenvolvidos são resultados práticos desse modelo teórico de desenvolvimento de software. Trata-se, portanto, de um modelo que está repercutindo cada vez mais no mundo dos software, entrando em grandes empresas que desenvolviam e ainda desenvolvem software  pela  forma clássica.

Como se discutiu no decorrer do trabalho, trata-se de uma mudança radical no estilo de desenvolvimento de software, e como toda idéia nova é difícil de ser aceita, ainda existe muita resistência à sua utilização.

A Programação Xp está sendo usada por desenvolvedores inovadores que estão colhendo bons resultados na sua sistemática de produção de software, o que certamente aumentará o valor da argumentação futura para sua eficácia. Mas, não podemos negligenciar o fato de que, apesar de todos os benefícios que a Xp oferece, existirem limitações que esbarram no seu crescimento e na sua aplicação, como a seguir procuramos esclarecer:

- Para se utilizar a Programação Xp torna-se necessário a ocorrência concomitante de uma série de fatores, e na prática, em grandes corporações que desenvolvem projetos complexos, é muito difícil juntar todos eles.

- Há de se considerar também certas limitações por parte do cliente, tais como a de não aceitação de todas regras impostas pela Programação Xp, a de não garantir um feedback rápido nas fases de desenvolvimento, a de não poder garantir a sua presença em muitos momentos críticos do desenvolvimento, além de desejar uma documentação detalhada de todo o software desenvolvido.

- Pode também ocorrer limitação por parte do software em si, como no caso de desenvolvimento de um software muito grande e complexo, no qual seja necessário o trabalho de mais de 10 programadores. Os casos em que os testes demoram horas para gerar os resultados e o código demora muito tempo para ser compilado, também limitam o uso da Programação Xp.

- Pode haver limitações da equipe do projeto, caso não seja possível contar com os programadores que seguirão rigorosamente as regras da Programação Xp.

- O espaço de trabalho pode também vir a ser um limitante, caso não se tenha um lugar propício para toda a equipe estar junta, o que dificultaria a comunicação, que é um fator de enorme relevância na metodologia da Programação Xp.

Nos comentários acima, não se levou em consideração as limitações oriundas da linguagem de programação utilizada. De repente, pode ser difícil fazer testes automatizados, gastando-se muitas horas do projeto só para isso, limitando a utilização da Xp.

Após este breve sumário sobre os pontos positivos e negativos das duas formas de desenvolvimento de software em discussão no presente trabalho e, por meio das respostas as duas perguntas descritas abaixo, mostraremos que fatores podem facilitar na decisão de escolha entre essas duas formas de desenvolver software:

1ª) Por que foram utilizados os valores da Programação Xp e não os da Engenharia de Software clássica neste projeto realizado na i.social?

2ª) Por que em projetos como este, similares ou mais complexos, pode ser mais vantajoso utilizar o modelo de Programação Xp em relação ao da Engenharia de Software clássica?

A primeira pergunta será respondida baseando-se nas seguintes razões:

a) Não fazia parte do projeto desenvolver um documento detalhado e as reuniões aconteceriam constantemente, possibilitando um início rápido do projeto. Na prática, o projeto em 3 semanas já tinha o primeiro release e os profissionais de RH da empresa i.social já podiam cadastrar currículos na base de dados, além dos ajustes que já estavam sendo feitos.

b) Antes da entrega de um release seriam feitos testes automatizados para eliminar possíveis erros. Na prática, as funcionalidades mais complexas foram testadas e somente depois de passarem no teste foram implementadas, gerando um sistema confiável.

c) Após a entrega do release, os profissionais de RH usariam o sistema. Na prática, o release foi disponibilizado, e na primeira semana, as dúvidas, os erros e as sugestões foram apontados. Os erros foram corrigidos de forma rápida e as sugestões foram discutidas para estabelecer as prioridades. Quando a prioridade era alta, implementava-se na mesma fase, sendo que as sugestões com baixa prioridade foram deixadas para fases futuras.

d) No final do projeto, pouca alteração seria necessária, uma vez que os releases seriam entregues e reformulados e somente após o aval do cliente, começaria um novo release. Na prática, os releases consumiram em média 3 semanas para serem desenvolvidos cada um e uma semana para serem alterados. A partir dai, iniciava-se uma nova fase com um novo release.

e) Se os ajustes fossem deixados para o final do projeto, poderia ser necessário um extenso e árduo trabalho para refazer as funcionalidades mal implementadas, consumindo tempo e esforços e, como mencionado na Parte I deste trabalho, ajustes efetuados no final do projeto são muito mais onerosos. Na prática, ocorreram algumas falhas de comunicação e funcionalidades foram implementadas com erros. Mas, tenho certeza de que, se todos os erros fossem reparados somente no final do projeto, ou em períodos de tempo maiores que 3 semanas de programação, como em muitos projetos que utilizam a Engenharia de Software clássica, seriam consumidos de 2 a 3 meses para serem reparados.

f) Mesmo sendo poucos os requisitos funcionais e não-funcionais, como mencionado no item 4.1, o desenvolvimento de um formulário complexo contendo todos os detalhes da implementação e funcionalidades, levaria no mínimo de 1 a 3 meses para ser produzido, já que o cliente não está disponível a qualquer momento para analisar o mesmo, e antes de sua autorização não se poderia começar ou dar continuidade ao desenvolvimento. Neste documento também seriam necessários ajustes, até se atingir um nível viável de entendimento entre desenvolvedor e cliente para dar inicio ao projeto. Na prática, o que ocorreu no sistema da empresa i.social, como mencionado anteriormente, é que em menos de um mês a empresa já tinha um release disponibilizado.

Vamos responder agora a segunda pergunta:

Quando se comparam duas entidades, por exemplo, qual é o carro mais rápido, basta testar o carro A e o carro B, comparar os resultados e rapidamente é possível chegar a uma conclusão de qual é o carro é mais veloz.
Infelizmente, tratando-se de metodologias de desenvolvimento de software, os dados que temos são resultados de projetos realizados com uma metodologia ou com outra. No caso da empresa i.social, temos o resultado gerado pela metodologia da Programação Xp. Não foi feito o mesmo projeto utilizando os conceitos da Engenharia de Software clássica, para permitir comparar e concluir que o projeto em Programação Xp foi mais ou menos vantajoso, como facilmente se conclui no exemplo dos dois carros.

Logo, torna-se necessário usar certos indícios para mostrar que em projetos como o da empresa i.social e outros, que permitem a aplicação dos valores da Programação Xp, obtêm-se melhores resultados quando comparados com a Engenharia de Software clássica. No projeto da empresa i.social, os indícios foram mencionados nos itens 3 e 4 (incluindo os sub-itens) e resumidos na resposta da primeira questão acima.

Um cálculo simples pode ser feito, ou seja, 4 meses foram consumidos para desenvolver o que foi estabelecido no início do projeto e, levando em conta a sexta razão mencionada na resposta 1, o mesmo projeto somente poderia iniciar-se após o terceiro mês, quando a documentação supostamente estaria pronta. Sendo assim, pode-se encontrar um indício nesse projeto, de que o modelo da Programação Xp foi mais viável.

Assim, para projetos do porte do desenvolvido na empresa i.social, e levando-se em consideração as premissas prévias dos envolvidos no projeto, recomenda-se a utilização dos valores da Programação Xp, que gerarão um bom resultado, pressupondo-se que o desenvolvedor e a empresa tomem esses valores com muita seriedade, como ocorreu neste projeto realizado na i.social.

Não se pode afirmar com 100% de precisão que projetos como o descrito nessa monografia Xp são melhores que os feitos com a Engenharia de Software clássica, mas indícios mostram que é melhor. Não se pode afirmar, tomando por base somente este projeto, que projetos mais robustos e complexos, que poderiam ser desenvolvidos utilizando os valores da Programação Xp, terão resultados superiores se os mesmos fossem desenvolvidos utilizando a Engenharia de Software clássica. O que sim, pode-se dizer, é que logicamente, os valores da Programação Xp, tendem a gerar um projeto com uma qualidade superior e em um tempo razoavelmente mais curto quando comparado se o mesmo fosse desenvolvido por meio da engenharia clássica, como foi mostrado na Parte I e na prática na Parte II.

Pelo fato de não se desenvolver uma documentação robusta e de não se deixar os testes para o final, ou testes se realizarem em períodos de tempos maiores, onde já é possível produzir uma quantidade muito grande de código, pode-se esperar que projetos com a metodologia de Programação Xp tendem a ser mais rápidos, como mencionado no parágrafo anterior.

Num futuro talvez não muito longínquo, será possível ter uma claridade muito maior dos resultados, já que teremos uma quantidade bem maior de experiências de projetos desenvolvidos com a Programação Xp. Munidos de dados estatísticos mais precisos e abrangentes, o melhor ou pior desempenho do modelo de Programação Xp  poderá ser constatado, comparado com o da Engenharia de Software clássica, ou os casos em que se deva utilizar uma ou outra metodologia.

Assim, o projeto da empresa i.social contribuiu para aumentar o número de casos de sucesso utilizando os valores da Programação Xp mas, por enquanto, o que se pode afirmar é que, tratando-se de uma metodologia nova, com ainda pequeno espaço amostral de projetos utilizando-a, tudo indica tratar-se de uma metodologia promissora que gera resultados melhores, ou tão bons, mas implementados mais rapidamente, se comparados com os mesmos projetos desenvolvidos utilizando o modelo clássico.

Além da necessidade de novos projetos para ampliar o espaço amostral, a Programação Xp tem também um outro desafio a vencer, que é o de ampliar e expandir o nicho de projetos que é capaz de desenvolver. Será necessário estudar técnicas que aprimorem e possibilitem a Programação Xp ser utilizada nos casos ainda limitados pelo modelo atual.

Acreditamos que o aumento do número de projetos em Programação Xp, proporcionará um melhor conhecimento desta tecnologia e com isto um amadurecimento do modelo, que será capaz de ser usado num nicho muito maior de desenvolvimento de software. Assim, pode-se concluir, que a metodologia da Programação Xp é realmente um modelo promissor de desenvolvimento de software.

 

Para ver o projeto da i.social concluído basta clicar aqui.

 

* API: [5] "Application Programming Interface ou simplesmente API é um conjunto de rotinas e padrões estabelecidos por um software para utilização de suas funcionalidades. De modo geral, a API é composta por uma série de funções acessíveis somente por programação, e que permitem utilizar características do software menos evidentes ao usuário tradicional." - pt.wikipedia.org/wiki/API