Sistemas Legados

Objetivo
Conceiturar sistemas legados, tecnologias atuais para manter sistemas críticos em produção, estendendo o seu ciclo de vida, integrado-os a novos sistemas e tecnologias. E a importância desses sistemas para as organiações, tanto de ponto de vista estratégico quanto do econômico, o desenvovimento de técnicas e tecnologias para a sua integração aos novos sistemas. Um pequeno estudo de caso é apresentado, demostrando uma das abordagens para integração.
1. INTRODIÇÃO
Escolher e executar adequadamente processos de desenvolvimento de software, são aspectos fundamentais para desenvolver produtos de software de qualidade.


A Engenharia de Requisitos tem surgido para melhorar o processo de desenvolvimento de software em um dos pontos cruciais para a obtenção de um produto de qualidade: a correta elicitação, análise, especificação e validação de requisitos. É de consenso tanto da comunidade acadêmica quanto industrial que um produto de software de qualidade é aquele que é capaz de atender os requisitos funcionais e não-funcionais dos respectivos usuários.
Assim, verifica-se, que a qualidade de um produto de software é
fortemente influenciada pela qualidade do processo utilizado. Melhorar o processo de desenvolvimento é um aspecto fundamental para a melhoria da qualidade do produto.


Fornecer software de qualidade não é apenas uma questão de funcionalidade visual. É necessário atentar para a documentação do mesmo, a facilidade para rastrear e avaliar impactos de mudanças nos requisitos, verificar a satisfação dos requisitos não funcionais, entre outros aspectos críticos. Este sentimento é também expresso em, no qual são identificados os problemas mais comuns em projetos de software como falhas na elicitação e análise de requisitos e impossibilidade completa de manutenção, devido principalmente à falta ou inadequada documentação.
Estes problemas agravam-se, em muitos casos, desenvolvedores de software, nos quais há a necessidade de atualizar e/ou reconstruir sistemas legados, juntamente com a difícil tarefa de evoluir de metodologias tradicionais tais como abordagem estruturada atuais, como o Processo Unificado. As dificuldades neste processo são inúmeras. É importante considerar todas as informações úteis e que possam ser aproveitadas a partir da documentação existente do sistema legado. Um conjunto de diretrizes que visam facilitar o processo de transição em sistemas legados, que permitem mapear importantes informações em Diagramas de Fluxos de dados (DFDs) para Casos de uso em UML.
Desta forma, inicialmente, os principais processos e metodos de desenvolvimento de software existentes atualmente. Propõe-se um conjunto de evolução natural que muitas empresas se defrontam em relação à transição do uso de métodos tradicionais estruturados para o uso de metodos e processos orientados a objetos. É apresentando um conjunto de diretrizes para auxiliar engenheiros de requisitos na transição do uso de metodos.
2. Desenvolvimento de Sistemas
Independente do metodo escolhida para a construção de um produto de software, a mesma deve possuir uma semântica bem-definida, de modo que, qualquer outro desenvolvedor possa interpretar e ser capaz de entender os propósitos do sistema sem ambigüidades.
Deve também propiciar e nortear o desenvolvimento de forma que o
produto final de software possua características fundamentais relacionadas a
qualidade do produto em si.
Ao definirmos os termos da abordagem de cada um, sem contar que a experiência do analista é fator primordial para o sucesso de qualquer análise. Muitas suposições são feitas quando tratamos a respeito de seus benefícios e vantagens em relação a outras já existentes. O que se observa na prática, é uma constante evolução decorrente de experiências pessoais de um grupo de pessoas. Essa evolução tem levado a criação de abordagens de desenvolvimento de software mais eficientes, bem definidas e preocupadas em integrar efetivamente com os usuários no processo de desenvolvimento de software, e de forma mais critica, no processo de engenharia de requisitos. Busca-se também desenvolver softwares mais coesos, de fácil gerenciamento, passíveis de certificação e com um custo menor.

3. O Processo de Transição em Sistemas Legados
Muitas são as contribuições relacionadas a atualização de sistemas legados em relação a uma nova metodologia.
Sistemas legados possuem lógica de programação, decisões de projeto,
requisitos de usuário e regras de negócio, que podem ser recuperados, facilitando sua reconstrução, sem perda da semântica. Assim, abandoná-los e começar o projeto do zero seria uma perda considerável.
Nas próximas seções apontaremos decisivas para realizar a transição, visando melhorar / atualizar os sistemas legados.

3.1 Treinamento de Pessoal
Este treinamento requer que a equipe que irá realizar esta difícil tarefa, tenha algumas qualidades que julgamos serem essenciais:
a) Conhecimento da nova metodologia( RUP, na maioria dos casos);
b) Conhecimento de ferramentas CASE que facilitem o trabalho de migração;
c) Excelente ambiente de trabalho, não só em relação ao grau de relacionamento do grupo como também em relação a um local apropriado para o desenvolvimento do trabalho, sem precisar dividir o ambiente de trabalho com várias pessoas de setores diferentes, por exemplo.
Estas qualidades são fundamentais para que o processo de migração seja mais efetivo e produtivo.

3.2 Organização da Base de Informações
A organização da base de informações é decisiva para facilitar a engenharia reversa de um sistema legado utilizanda. As seguintes situações podem ser observadas:
a) Um sistema sem documentação neste caso, estão disponíveis apenas as informações do código fonte do sistema;
b) Um sistema com documentação atualizada Neste caso, documentação em ordem, o processo é facilitado, uma vez que podemos verificar a análise efetuada anteriormente e as atualizações que se tornaram necessárias com o passar dos anos. Temos um histórico completo do sistema, simplificando a organização.

c) Um sistema com uma documentação não atualizada Nesta situação bastante comum, as equipes mal tiveram tempo de realizar as atualizações nos códigos fontes do sistema. Normalmente, as equipes que trabalham no sistema não foram as mesmas que o desenvolveram.
As situações acima, devemos ter em mente que a equipe que irá realizar a tarefa de evolução de sistemas legados, não será a mesma que o desenvolveu. Assim, precisamos nos basear em alguns pontos cruciais para o desenvolvimento do projeto, conforme segue:
Deve-se integrar efetivamente, o usuário/cliente no processo de desenvolvimento.
A integração e interação constante de usuário/cliente durante todo o processo de transição do uso e modificando e reconstruindo sistemas legados
é ponto decisivo para o sucesso do processo.
Deve-se considerar efetivamente os requisitos que o sistema deve atender (ou
requisitos verdadeiros). Os requisitos do sistema são o que o sistema produz ou emite em forma de relatórios e consultas visuais em tela para os respectivos
usuários. O que o sistema produz justifica a sua existência e a sua essência.
Preocupar-se com a satisfação dos requisitos de clientes e usuários é uma questão chave no processo de transição adotado.
Para compreendermos melhor este processo, tomemos como base os três tipos diferentes de situações apresentadas em relação a sistemas legados (baseados na documentação existente) e suas respectivas ações a serem desenvolvido.

A transição da Análise essencial ou estruturada Orientada a Objetos, como RUP. Cabe ressaltar que os metodos orientadas a objetos consideram os casos de uso como elementos chaves e essenciais no processo de desenvolvimento.

Sistemas Legados, Situação da Documentação, Inexistente Precária, Atualizada Análise Estruturada/Análise Essencial Implementado na Análise Estruturada Fases:
1 Realizar a Conversão de DFDs em Casos de Uso;
2 Analisar E/S do Sistema;
3 Validar com os Stakeholders as E/S;
4 Organizar Casos de Uso.
Implementados na Análise Essencial Fases:
1- Analisar código fonte do Sistema;
2- Analisar E/S do Sistema;
3- Validar com os Stakeholders as E/S;
Fases:

1 Atualizar DFDs - Analisar DFDs existentes e compará-los com a análise efetuada no código fonte;
2 Realizar a Conversão de DFDs em Casos de Uso;
3 Analisar E/S do Sistema;
4 Validar com os Stakeholders as E/S;
5 Organizar Casos de Uso
Fases:
1 Analisar Diagrama de Contexto;
2 Realizar a Conversão de DFDs em Casos de Uso;
3 Analisar E/S do Sistema;
4 Validar Stakeholders apontados na Fase 1 e as E/S apontadas na Fase 3.
5 Organizar Casos de Uso.
Passos a serem seguidos na realização de engenharia reversa em sistemas legados.

Na análises e comparações a serem efetuadas em sistemas legados considerando a documentação existente.
Relatos apontam para o consenso de que a análise do código fonte e sua organização, auxilia o engenheiro de software a remodelar o sistema sob o enfoque orientado a objetos. Contudo, pouca atenção se dá as outras possibilidades de uso de informações, como por exemplo, o mapeamento de modelos e diagramas que representam, tipicamente, os aspectos essenciais de um sistema. Desta forma, pode-se enriquecer a coleta de informações
necessária a atualização/reconstrução de sistemas legados. podem efetivamente ser mapeados para casos de uso em UML, facilitando o trabalho de transição.
A seguir apresentamos um conjunto de diretrizes que permitem mapear Diagramas de Fluxos de Dados para casos de uso em UML. As diretrizes a serem propostas podem ser aplicadas para mapear elementos de metodologias tradicionais (Estruturada ou Essencial), para o Processo Unificado, uma vez que nosso principal enfoque será obter os casos de uso referentes ao sistema, os quais são elementos chaves nos dois processos orientados a objetos.

3.3 Mapeando elementos de Diagramas de Fluxos de Dados para Casos de Uso em UML. Um dos maiores problemas atuais no desenvolvimento de software está relacionado ao processo de transição. Atualmente, muitas organizações são
obrigadas a mudar seus sistemas computacionais utilizando novas abordagens de
desenvolvimento, as quais apresentam algumas vantagens tais como: maior flexibilidade, suporte automatizado para todo o processo de desenvolvimento, etapas e artefatos bem definidos, bem como possibilidade de uso efetivo do paradigma orientado a objetos. Contudo, na maioria das situações, existem informações importantes nos sistemas legados que devem ser mapeadas para novos artefatos gerados no uso de novas metodologias.
Neste contexto, verificamos que tipicamente Diagramas de Fluxos de Dados
desenvolvidos utilizando metodologias tradicionais precisam ser mapeados de forma mais efetiva e sistemática para a técnica de casos de uso. É importante ressaltar que casos de uso fazem parte da UML e são considerados essenciais na maioria dos processos de desenvolvimento orientados a objetos atualmente utilizados.
Não é correto assumir que apenas o código fonte em sistemas legados é suficiente para elicitar e documentar todos os requisitos essenciais de sistemas computacionais objetos de transição e evolução. É necessário atentar para toda documentação disponível que possa auxiliar na transição e evolução de sistemas de software.
O foco das diretrizes está no mapeamento de Diagramas de Fluxos de Dados
para Casos de Uso em UML. Após a descrição das diretrizes, apresentamos uma
tabela que mostra a aplicabilidade das diretrizes para cada situação, tomando como base a documentação disponível dos sistemas legados.
Estas diretrizes são dependentes exclusivamente da situação documental disponível, podendo ser aplicadas, dependendo da situação da
documentação do software legado. Situação da Documentação Existente Diretrizes a serem implementadas
Uso das diretrizes propostas de acordo com a situação documental disponível.

a) A Análise do Diagrama de Contexto - Esta diretriz tem por objetivo relacionar as entidades externas como prováveis atores do sistema legados. Nessa diretriz todas as entidades externas serão relacionadas como possíveis atores do sistema. A análise do diagrama de contexto.
b) Conversão do Diagrama de Fluxo de Dados para Diagrama de
Casos de Uso
b.1) Para cada nível do sistema legado será elaborado um Caso de Uso, como
b.2) Analisar a especificação do processo. Caso não possua Entidade Externa, ele é o resultado de um outro processo anterior que o originou. Neste caso, deve ser definido apenas como um Entidades Externas que serão prováveis
atores do sistema:
- Cliente
- Atendente
- Gerente

Sistema de Controle de Locadora Cliente Atendente Gerente Fluxos de entrada/saída são mapeados para especificação do caso de uso pré e póscondições Entidade Externa é mapeada para ator no diagrama de casos de uso O processo, é mapeado para Caso de uso e o Português estruturado deste processo é mapeado para a especificação do caso de uso do tipo <> ou <> , o qual será chamado em outro caso de uso. Devemos ter o cuidado de validá-lo com o DFD que o chamou, e assim incluí-lo no processo de conversão
3). Normalmente, a especificação do processo indica quais são os passos necessários para se atingir um determinado objetivo. Deste modo, pode-se a partir da especificação do processo analisado já incluir no caso de uso correspondente as colaborações e generalizações indicadas. A Conversão para caso de uso especial. Análise e conversão da especificação do processo Validar Cliente.

Fonte: Código do Português Estruturado.

b.3) Analisar os fluxos de entrada e saída, bem como a especificação do processo. Este passo é importante para validar os depósitos de dados identificados
4) O caso de uso Validar Cliente é descrito com base nas informações contidas na especificação do processo. Definimos o objetivo do caso de uso analisado, sua prioridade, indicando se sua execução é essencial ao sistema, as pré-condições existentes para sua execução, as pós-condições após a sua execução e o cenário principal juntamente com os fluxos secundários, indicando alternativas de execução. Descreve-se também os caso de uso pai e subordinados, os quais são detectados no decorrer da conversão.
No passo 1 do cenário principal (O caso de uso inicia Quando DeptVendas requer avalidação do cliente) devemos indicar o responsável pela execução do mesmo.
Apesar da especificação do processo não indicar o ator, possui como
Entidade Externa o DeptVendas, logo, ele é incluído como ator do Caso de Uso. Criar cliente Novo outros passos é realizada uma referência a especificação do processo, como por exemplo, em Se cliente encontrado, que foi representado pelo
passo 2 O sistema verifica a existência do cliente. Os fluxos de exceção são tratados pelos casos de uso secundários (include ou extend), associados ao caso de uso principal Validar Cliente. Caso de Uso Validar Cliente Objetivo Este caso de uso descreve o procedimento para que um cliente seja validado de acordo com sua situação decorrente do crédito Prioridade ( x )Essencial ( ) Secundário Pré-Condições Dados do cliente e Pedido do cliente incluído. Pós-Condições Pedido do Cliente Processado. Cenário Principal
1. O caso de uso inicia Quando DeptVendas requer a validação do cliente;
2. O sistema verifica existência do cliente (caso de uso checar cliente é incluído);
3. O sistema verifica o crédito do cliente (caso de uso checar crédito é incluído);
4. O sistema reune todos os pedidos do cliente (caso de uso reunir pedidos é incluído);
5. O sistema cadastra todos os pedidos do cliente (caso de uso criar pedido cliente é incluído).
Fluxos Secundários Caso de Uso Pai Caso de Uso Subordinado Checar cliente Checar crédito Reunir pedidos Criar pedido Tabela 4. Especificação do Caso de Uso.

c) Organização das Entradas e Saídas do Sistema esta diretriz tem por objetivo relacionar e validar as entradas e saídas do sistema. Este passo requer o auxílio da equipe ou responsável pela manutenção do sistema, que indicará para cada entrada (em tela) e saída (relatório existente) o usuário responsável pela informação.
Deste modo, o engenheiro de software terá uma relação de todos os atores (stakeholders) que são afetados.
d) Validação dos Stakeholders esta diretriz tem por objetivo validar os
stakeholders apontados. Deste modo, o engenheiro de software deve
comparar com os atores já identificados e realizar as alterações
necessárias nos casos de uso identificados.
e) Organizar Casos de Uso esta diretriz tem por objetivo organizar os diagramas de caso de uso de acordo com as notações propostas pela UML. Casos de uso devem ser agrupados em pacotes ou pela especificação de relacionamentos de generalização, inclusão e extensão, existentes entre os mesmos.



4. Principais Dificuldades Presentes no Processo de Transição

A experiência já ditava regras desde a Análise Estruturada, uma vez que apenas os analistas experientes tinham conhecimento para discernir o lógico do físico, pois os poucos que conseguiam aprender a fazer esta distinção, não tinham sucesso em passar esta aptidão aos colegas.
Na prática, o que verificamos é que, com pouquíssimas exceções, as pessoas não
conseguem aprender uma nova metodologia de desenvolvimento com tanta facilidade.

Para muitos analistas, uso do RUP envolve diversas dificuldades técnicas e de origem pessoal. A realidade de nossas empresas, tanto privadas, quanto estatais ou do governo, como é o caso do Exército Brasileiro, está começando a mudar. A experiência de um dos autores do presente artigo no Exército Brasileiro mostra que grupos de desenvolvimento de sistemas de Brasília, Capital Federal, se encontram num dilema entre a transição, pois ainda utilizam a Análise Estruturada.
A transição tem se mostrado lenta e gradual buscando um só objetivo: o desenvolvimento e migração de sistemas existentes e a desenvolver. São fruto da experiência de desenvolvimento dos autores, bem como das dificuldades encontradas no âmbito da análise de sistemas do Exército Brasileiro.

5. Considerações Finais e Trabalhos Futuros
Apresentamos, inicialmente, um relato das principais de desenvolvimento de sistemas existentes, buscando facilitar o estudo dos fatores envolvidos no processo de migração de projetos elaborados através da Análise Estruturada ou a Análise Essencial para projetos elaborados utilizando processos Orientadas a Objeto.

Com base neste estudo, propomos um conjunto para auxiliar
engenheiros de software/requisitos no processo de transição entre metodologias
tradicionais e orientadas a objetos. Basicamente, propõe-se de forma sistemática,
mapear as informações existentes na documentação do processo tradicional para o processo de desenvolvimento orientado a objetos. Apoiamo-nos no fato de que as informações presentes que podem auxiliar o processo de construção e descrição de casos de uso em UML. Defende-se a idéia de que as diretrizes propostas devem ser aplicadas de acordo com a documentação disponível em relação aos sistemas legados sendo tratados.

Verificamos neste trabalho que o processo de transição de abordagens de
desenvolvimento tradicionais para as utilizadas na orientação a objetos implica,
inicialmente, em uma mudança de cultura bastante complexa dentro da empresa.
Consideramos também que outros aspectos importantes tais como rastreamento de requisitos, modelagem organizacional e tratamento de requisitos não-funcionais, não considerados na análise estruturada e essencial de sistemas, devem ser inseridos gradualmente na equipe de desenvolvimento aumentando progressivamente o grau de maturidade dessas organizações.

a) Associar a modelagem organizacional com a modelagem funcional da empresa
com base na documentação existente dos sistemas legados;
b) Desenvolver uma ferramenta que suporte a conversão do DFDs para Casos de Uso usando as propostas, pois como já mencionamos, a técnica de
casos de uso é chave na UML, bem como nos principais processos de
desenvolvimento Orientado a Objetos.
6. Conclusão
Sistema legado é o termo utilizado em referência aos sistemas computacionais de uma organização que, apesar de serem bastante antigos, fornecem serviços essenciais. Geralmente utilizam bancos de dados obsoletos.
Normalmente são aplicações complexas, de difícil manutenção e que pelo grau de criticidade e custo para modernização, continuam ativas.
Por falta de documentação e com a saída do pessoal técnico que participou originalmente no seu desenvolvimento os sistemas legados podem apresentar problemas como: dificuldade de compreensão das regras de negócio neles implementadas, desconhecimento das razões que levaram a determinadas decisões, problemas na estruturação dos módulos de código, miscelânea de estilos de programação, obsolescência das ferramentas de desenvolvimento e impossibilidade de eaproveitamento dos equipamentos nos quais são executados para execução de softwares mais atuais.

7. Referências Bibliográficas
Filho, T. L. Metodologia de Desenvolvimento de Sistemas , Axcel Books, Rio de Janeiro,2003.
Scott, Kendall. O Processo Unificado Explicado . Bookman,, Porto Alegre,2003
Chung, L.; Nixon, B.; Yu,Eric;Mylopoulos,John. Non-Functional requirements in Software engineering , USA: Kluwer Academic Publishers, 2000,439p.
Booch, G.; Rumbaugh, J., Jacobson, I. The Unified Modeling Language, Addison- Wesley,1999.
Shlaer,S.; Mellor,S. Análise de Sistemas Orientada para Objetos , Makron Books, São Paulo,1990. Gane, C.; Sarson,Trish. Structured Systems Analysis , New York, Improved System Technologies, 1977. Jacobson, I.; Booch, G.; Rumbaugh, J. The Unified Software Development Process , Addison-Wesley (1999).
D Souza, D. and A.Wills. Objects, Components and Frameworks with UML: The
Catalysis Approach , USA: Addison-Wesley, (1995). ISO International Standard Organization. ISSO 9000 Quality Management system. 1.ed.
Geneva: ISSO 2000. McMenamin, S.; Palmer,J. F. Análise Essencial de Sistemas, Makron Books, São Paulo,1984. Toranzo, Marco A., Uma Proposta para Melhorar o Rastreamento de Requisitos de Software , Centro de Informática, Universidade Federal de Pernambuco, Tese de Doutorado, Dezembro, (2002).
Fukuda, A. P. Refinamento Automático de sistemas Orientados a Objetos Distruidos São Carlos/SP, 2000. Dissertação de Mestrado. Universidade Federal de São Carlos Fontanete,V. et al. Reengenharia de Sistemas Legados Baseada em Componentes usando Transformações . São Carlos/SP,2003. Artigo. Universidade Federal de São Carlos. Jesus,E.S. Engenharia Reversa de Sistemas Legados Usando Transformações . São Carlos/SP, 2002, Dissertação de Mestrado, Universidade Federal de São Carlos. Werner, C.M.L.; Braga, R. M.M. Desenvolvimento Baseado em Componentes . XIV Simpósio Brasileiro de Engenharia de Software SBES2000 Minicursos e Tutoriais pg. 297- 329 2-6 de Outubro, 2000. Jesus, E. S. Engenharia Reversa de Sistemas Legados Usando Transformações , 2000 - Dissertação de Mestrado, Ciências da Computação, UFSCAR. Chikofsky, E. Reverse Engineering and Design Recovery A Taxonomy . IEEE Software Santander, Victor F.A. Integração de Modelagem Organizacional com Modelagem Funcional na Engenharia de Requisitos . Centro de Informática, Universidade Federal de Pernambuco, Tese de Doutorado, Dezembro, (2003).

Cartilha de Segurança para Internet

A Cartilha de Segurança para Internet contém recomendações e dicas sobre como o usuário pode aumentar a sua segurança na Internet. O documento apresenta o significado de diversos termos e conceitos utilizados na Internet e fornece uma série de procedimentos que visam melhorar a segurança de um computador.

clique aqui para baixar a cartilha completa

Ética na Internet ou Internet com Ética?

Não precisamos ser gurus para perceber que o mundo está passando por uma quarta onda de transformações. É cada vez mais repetitivo dizer que estamos vivendo a era da revolução da informação, lastreada na tecnologia disponível, que elimina as barreiras da distância relacionada à língua e à cultura e nos conduz a novos processos de produção, a novas formas de diversão, a um novo modo de viver e pensar, agir e interagir.

Mas, quanto mais veloz e voraz é o avanço tecnológico, maior é o abismo que separa o mundo tecnologicamente "in" do mundo tecnologicamente "out".

Conseqüentemente, estas transformações na escola estão relacionadas aos alunos de hoje, que já não são iguais aos de ontem, principalmente no que se refere aos comportamentos ético e disciplinar. Não adianta nos lamentarmos diante disso, pois tal fato é conseqüência de que os pais também não são iguais aos de antigamente; as cidades mudaram, os valores humanos, enfim, o mundo todo mudou. As transformações dos últimos quinze anos foram muito mais significativas do que as ocorridas de 1900 a 1990.

As principais mudanças mundiais, entretanto, concentram-se nas formas de comunicação, especialmente em razão do avanço da informática e dos meios eletrônicos. Os diálogos entre amigos, que até a década de 1970 ocorriam pessoalmente, no final do século XX passaram a acontecer por telefone e hoje se dão pelo computador.

Seguindo o “velho conselho” de um sábio pensador, vale lembrar que “Há coisas que pensamos, mas não dizemos; e outras que dizemos, mas não escrevemos, sob pena de nos arrependermos”.

Entretanto, sem levar em conta a lição acima, as conversas de hoje são registradas. As comunidades Orkut, os e-mails, torpedos via telefone celular e os bate-papos virtuais imperam entre os jovens. Temos nos deparado com diversos relatos de abusos no uso dessas formas de comunicação.

Pensamos que o grande desafio é conscientizar as crianças e adolescentes, de que alguns comportamentos na utilização dos meios eletrônicos são “atos infracionais” e devem ser restringidos.

É importante que todos saibam que suas comunicações virtuais não lhes garantem o anonimato, como muitos parecem acreditar. É fundamental que tenham a informação de que não podem ofender as pessoas impunemente, nem imputar conduta imoral ou desonrosa a alguém, sob pena de responderem por tais atos. Mesmo sendo menores de idade, na medida em que cometam “crimes”, podem ser responsabilizados em consonância com o Estatuto da Criança e do Adolescente. Essa lei oferece vários direitos à criança (menor de 12 anos) e ao adolescente (menor entre 12 e 18 anos), mas é preciso alertá-los de que ela também pune.

É oportuno destacar que os “atos infracionais” podem gerar punições, especialmente aos adolescentes, que são as seguintes: I - advertência; II - obrigação de reparar o dano; III - prestação de serviços à comunidade; IV - liberdade assistida; V - inserção em regime de semiliberdade; e VI - internação em reformatórios (estabelecimento correcional privado).

É de extrema importância saber que se pode estar cometendo crimes de injúria, calúnia ou difamação. Como reforço, devemos mencionar que ao “ofendido” é possível pedir que o Judiciário faça a identificação do autor, pois ele que não conta com o anonimato. O autor das mensagens deve pensar mais antes de escrevê-las, pois poderá responder legalmente pelos seus atos.

Para tanto, sugerimos que todos reflitam sobre o que é ética e se conscientizem de que a boa convivência na Internet depende de uma série de regras conhecidas como netiqueta ou etiqueta na rede. As regras incluídas na netiqueta não foram definidas por uma autoridade no assunto, mas criadas pelos próprios usuários ao longo do tempo. Também não existe um texto único e definitivo sobre o tema, mas várias interpretações espalhadas pela rede.

Diante disso temos que fazer uma pergunta para nos mesmos, Eu sei o que é ética?

Segundo o Dicionário Aurélio Buarque de Holanda, ÉTICA é "o estudo dos juízos de apreciação que se referem à conduta humana susceptível de qualificação do ponto de vista do bem e do mal, seja relativamente a determinada sociedade, seja de modo absoluto”.

Alguns diferenciam ética e moral de vários modos:

1. Ética é princípio, moral são aspectos de condutas específicas;
2. Ética é permanente, moral é temporal;
3. Ética é universal, moral é cultural;
4. Ética é regra, moral é conduta da regra;
5. Ética é teoria, moral é prática.

Etimologicamente falando, ética vem do grego "ethos", e tem seu correlato no latim "morale", com o mesmo significado: Conduta, ou relativo aos costumes. Podemos concluir que etimologicamente ética e moral são palavras sinônimas.

Leia os Dez Mandamentos da Ética na Internet

* Não use o computador para prejudicar as pessoas.
* Não interfira no trabalho de outras pessoas.
* Não altere arquivos alheios.
* Não use o computador para roubar.
* Não use o computador para obter falsos testemunhos.
* Não use nem copie softwares pelos quais você não pagou.
* Não use os recursos de computadores alheios sem pedir permissão.
* Não se aproprie de idéias que não são suas.
* Pense nas conseqüências sociais causadas pelo que você escreve.
* Use o computador de modo que demonstre consideração e respeito.

E concluindo nosso papo, acredito que poderíamos refletir de novo.

Afinal, o que é ética?
ÉTICA. é algo que todos precisam ter.
Alguns dizem que têm.
Poucos levam a sério.
Mas temos que nos conscientizar de que ela é essencial para nossa sobrevivência social.

Os 10 mandamentos de Ética da Internet

1. Não deverá utilizar o computador para prejudicar terceiros;

2. Não deverá interferir com o trabalho informático de terceiros;

3. Não deverá vasculhar os ficheiros informáticos de terceiros;

4. Não deverá utilizar o computador para roubar;

5. Não deverá utilizar o computador para prestar falsos testemunhos;

6. Não deverá utilizar ou copiar software pelo o qual não pagou;

7. Não deverá utilizar recursos informáticos de terceiros sem autorização;

8. Não deverá apropriar-se do trabalho intelectual de terceiros;

9. Deverá pensar nas consequências sociais daquilo que escreve;

10. Deverá utilizar o computador com respeito e consideração por terceiros

SCRUM metodologia ágil

Scrum, Metodologia ágil e práticas do XP, como pair programming
Das muitas definições sobre agilidade que podemos encontrar em livros, revistas e na internet, uma das que mais gosto é: "Agilidade é a habilidade de criar e responder a mudanças com respeito ao resultado financeiro do projeto em um turbulento ambiente de negócios. Agilidade é a habilidade de balancear flexibilidade com estabilidade". (Highsmith, Jim. Agile Project Management, 2002)
Agilidade é uma proposta de desenvolver projetos com uma estrutura e organização "suficientes". Muita estrutura e organização reduz a criatividade e a flexibilidade de suportar mudanças, pouca estrutura e organização permeia a ineficiência e resulta em esforços maiores que os necessários.
A diferença entre caos e agilidade pode ser verificada nos produtos resultantes. Considerando o mesmo cenário turbulento de negócios, nas equipes que convivem com o caos verificamos atrasos constantes, baixíssima qualidade dos sistemas, problemas com estimativas e estouro de orçamento. Nas equipes que utilizam-se de métodos ágeis percebemos entregas parciais constantes, interação com clientes para revisão de estimativas e orçamento conjuntamente com antecedência salutar ao projeto e principalmente dois pontos fundamentais: compromisso com a satisfação do cliente e responsabilidade com o resultado financeiro do projeto.
Empresas procuram métodos ágeis
As metodologias ágeis estão disponíveis desde a década passada, porém foi no ano de 2001 que houve a formalização com a assinatura do manifesto ágil.
Inicialmente houve uma desconfiança geral por parte da indústria de software, certamente impulsionada pelas diferenças aos métodos tradicionais e as questões das dificuldades de quebra de paradigmas por parte das pessoas. Nesta época tornou-se bastante famosa a metodologia XP (eXtreme Programming), pois propunha sem hipocrisia uma série de métodos polêmicos, muitos deles questionáveis até hoje como por exemplo a programação em pares e o cliente ao lado do desenvolvedor durante o projeto.
Lentamente, a indústria de software, impulsionada pela necessidade de obter resultados diferentes dos obtidos pelos métodos tradicionais, verificou que pessoas válidas estavam propondo métodos sérios e factíveis. Desta forma, determinadas práticas ágeis começaram a ser utilizadas em projetos de software sem a agressividade pela adoção plena de uma metodologia ágil.
Alguns destes métodos, compreendidos de forma inadequada, causavam uma dificuldade de percepção dos resultados. Um ótimo exemplo disto é a iteração. Iteração (iteration), que em tradução simples quer dizer repetição, é confundido com "interação" ou compreendido como processos repetíveis. Na verdadeira definição ágil, iteração está mais para processos confiáveis do que processos repetíveis. Na língua inglesa também verificamos este desentendimento quando estudamos em textos ágeis as palavras "repeatable" e "reliable".
A confusão entre confiável e repetível acontece porque muitos gestores de empresas gostam de formalizar processos muito estruturados e precisos (repetíveis) no lugar de formalizar processos suficientemente estruturados e flexíveis (confiáveis). Processos repetíveis focam na entrada das atividades, processos confiáveis focam no resultado das atividades.
Outros métodos, por oferecerem propostas mais simples de compreensão e apuração de resultado, começaram a chamar a atenção positivamente da indústria de software. Face a isso, iniciou-se um movimento liderado pelas universidades no Brasil (hoje sou consultor de metodologias ágeis da USP) que objetiva esclarecer os métodos e gerar conteúdos práticos que facilitem a implantação de tais propostas metodológicas.
Certificadas de que estes métodos funcionam, as empresas de software começaram a estudar uma proposta de metodologia classificada como ágil, que propõe novos métodos em substituição aos métodos praticados tradicionalmente. Este critério de escolha, que em minha opinião está suficientemente maduro, buscou primeiramente resolver as questões acerca da organização, distribuição e controle das atividades de um projeto de software. Eis a explicação da escolha da metodologia SCRUM pelo mercado de empresas desenvolvedoras de software.
SCRUM, muito simples de usar
A metodologia SCRUM está entrando na moda aqui no Brasil, após já haver conquistados inúmeras empresas da indústria de software na América do Norte.
Particularmente, eu considero o SCRUM uma proposta extremamente prática e honesta. Defino por prática neste contexto a facilidade de compreensão e aplicação em nosso ambiente de desenvolvimento de software. Defino por honesta a fidelidade entre a proposta do método e o resultado que podemos obter após aplicá-lo.
SCRUM, nome utilizado inicialmente pelos japoneses Hirotaka Takeuchi e Ikujiro Nonaka, descrevia um tipo de processo de desenvolvimento de produto utilizado no Japão.Também o nome SCRUM foi escolhido pela similaridade entre o jogo de Rugby e o tipo de desenvolvimento de produto comentado. Ambos são adaptativos, rápidos e promovem a auto-organização.
Para explicar SCRUM, utilizarei uma estratégia que foi usada pelo Ken Schwaber em seu livro chamado Agile Project Development with SCRUM. Na minha leitura, este é o melhor livro disponível lançado até a presente data.
Iniciando um projeto, há uma formalização de todas as coisas que se pretende fazer ou que se precisa construir no projeto. Cada item desta lista representa um requisito funcional, ou requisito não funcional, ou questão de tecnologia / infra-estrutura. Esta lista é denominada Product Backlog.
Podemos traduzir Product Backlog como uma lista de todos os requisitos de um produto priorizados, ou, em outras palavras, é qualquer coisa que represente um trabalho que precisa ser feito para o produto. Os itens com maior prioridade nesta lista são os requisitos mais desejados pelo produto. No projeto real, o Product Backlog nunca é finalizado. Existe uma natural evolução e maturidade dos requisitos nesta lista. Requisitos novos podem aparecer, requisitos existentes podem perder prioridade e podem até serem eliminados. Apesar de se permitir que áreas usuárias manifestem seus pedidos nesta lista, somente o Product Owner pode priorizar o Backlog.
O Product Owner possui a responsabilidade de definir a ordem que os requisitos serão produzidos pela equipe de desenvolvimento. Esta equipe deve ser pequena, multi-disciplinar e capaz de desenvolver todos os requisitos. Esta equipe recebe o nome de SCRUM Teams. A preparação dos trabalhos é denominada SPRINT Planning.
SPRINT Planning é composta dos seguintes ingredientes: Product Backlog, a capacidade de desenvolvimento da equipe, as condições e exigências do negócio, as características da tecnologia a ser usada e o comprometimento em entregar produtos executáveis incrementais. A mistura são revisões, administração e organização. Os resultados são SPRINT Goal e SPRINT.
O SCRUM Team deve desenvolver os itens separados pelo Product Owner em um determinado prazo previamente combinado. Este prazo é definido como Time Box e o trabalho de desenvolver os itens separados neste time box é denominado SPRINT. Estes itens separados do Product Backlog fazem parte de uma nova lista. Esta lista, chamada SPRINT Backlog, será de total responsabilidade do SCRUM Team que deverá mantê-la e organizá-la de tal forma a atender os objetivos do específico SPRINT.
É permitido ter mais de um SCRUM Team trabalhando no mesmo Product Backlog, por isso os requisitos são devidamente separados em SPRINT Backlog distintos por equipe. Uma idéia deste ciclo é verificada na imagem abaixo.

A liderança destas equipes é exercida por um papel denominado SCRUM Master. O SCRUM Master é um facilitador da gestão dos requisitos e direcionador da gestão das equipes. Este papel deve garantir a correta utilização das práticas de SCRUM, deve ajudar a equipe a tomar decisões e apoiar a equipe para adquirir os recursos necessários para o desenvolvimento do produto.
Este método de liderança é exercido através de 3 recorrentes tipos de reunião: SCRUM Daily Meeting, SPRINT Review e Retrospective. Começando pelo SPRINT Review que é a reunião típica de final de SPRINT (alguns SCRUM Team também a fazem no meio do SPRINT) para validar o produto executável que a equipe conseguiu incrementar.
Explicando a Retrospective, é uma reunião que também acontece ao final do SPRINT com o objetivo de fortalecer a unidade de ação da equipe. Três perguntas deverão ser respondidas com seriedade por todos os membros do SCRUM Team:
• O que você fez e gostou neste SPRINT?
• O que você fez e não gostou neste SPRINT?
• O que você vai fazer diferente no próximo SPRINT?
O desenvolvimento de projetos de software é um desafio constante, é uma atividade complexa. Todo processo complexo exige uma intensa comunicação entre todos os membros do projeto. SCRUM Daily Meeting é a resposta para promover a comunicação da equipe.
Todos os dias, obrigatoriamente, todo o SCRUM Team irá se reunir por 15 minutos aproximadamente para responder a 3 importantes perguntas. Sugerimos que está reunião seja de pé, pois temos verificado bons resultados em nossas práticas.
As perguntas são:
• O que eu fiz desde a última SCRUM Daily Meeting até agora?
• O que eu vou fazer hoje?
• O que pode me impedir?
Adicionalmente as técnicas apresentadas neste artigo, temos observado que a utilização de KANBAN (ver figura abaixo) ajuda a maximizar o comprometimento da equipe e a comunicação de todos os comprometidos e envolvidos com o projeto.

As cores amarela e laranja representam diferentes complexidades das atividades. A cor pink representa atividades não planejadas no SPRINT que foram incluídas por motivo de força maior.
Por se tratar de um extenso assunto, abordaremos detalhes explicativos sobre o que é KANBAN e como se utiliza em projetos de software no nosso próximo artigo técnico.

Para saber mais recomendamos os livros:
Agile Project Management by Jim Highsmith.
Agile Software Development with SCRUM by Ken Schwaber e Mike Beedle.
Agile Project Management with SCRUM by Ken Schwaber.
Treinamento MSF Agile + SCRUM + Agile Methods em http://www.fcamara.com.br
Considerações Finais
Nós, praticantes das metodologias ágeis, acreditamos que todos os projetos são diferentes. As tecnologias destes projetos são diferentes. As pessoas, os requisitos, idem. Nós não queremos ser indivíduos críticos do que existe há muito tempo na engenharia de software, nós queremos sugerir, proporcionar e fundamentar alternativas novas para resolver problemas antigos.
Na grande maioria das consultorias que ministro sob a titulação de "coaching" para fins de crescimento dos resultados qualitativos e produtivos de equipes de desenvolvimento de software, encontro pessoas que, utilizando-se de métodos tradicionais ou simplesmente de improviso diário (também denominado "ausência de métodos"), revelam-me uma estranha e frustrante sensação - A Síndrome do Trabalho Vazio.
A STV é a sensação que ocorre depois de um intenso dia de trabalho repleto de aborrecimentos e de atividades urgentes, quando percebe-se que, no final, todas as atividades planejadas para aquele dia não puderam ser implementadas. É uma constatação que é uma espécie de marionete do tempo, da empresa e dos clientes.
A utilização de métodos ágeis, com a adequação mental conforme os princípios estabelecidos pelas metodologias ágeis, mudaram minha vida profissional perante o cenário anteriormente descrito. Eu consigo fazer atividades planejadas, consigo priorizar atividades importantes e tenho um pequeno índice de atividades urgentes no meu dia-a-dia. Eu me sinto protagonista do meu dia.
As metodologias ágeis são uma positiva proposta para as empresas desgastadas com os resultados proporcionados por "waterfall approach to software development" ou pela ausência de métodos. Para iniciantes em metodologias ágeis, eu recomendo o SCRUM. Para praticantes de métodos ágeis que não conhecem o SCRUM, permitam-se mais uma evolução.




3 Conclusões
A metodologia de desenvolvimento Extreme Programming pode ser considerada extremamente nova, porém vem acompanhando as necessidades humanas dos desenvolvedores pelo mundo.
Gurus da tecnologia da informação vem aprimorando as concepções desta metodologia para atender as necessidades do mercado e principalmente das pessoas.
Um empresa ao utilizar este processo por completo, só estará agregando valor aos seus negócios e melhorando o ambiente de seus colaboradores e clientes, tratando-os como pessoas e parceiros. Está é chave no mundo dos negócios, o bem estar de seus colaboradores e a parceria entre o fornecedor e seus clientes, criando um laço de confiança ou até mesmo um sentimento de amizade.
Entender as necessidades do cliente não é ciência, é arte. Dar incentivo a ela é o mínimo que podemos fazer.

Extreme Programming

Extreme Programming , Engenharia de Software, Qualidade de Software, Metodologia de Desenvolvimento, Processos Ágeis de Desenvolvimento, XP.

Resumo: Este artigo tem por objetivo apresentar a metodologia de desenvolvimento ágil de software denominada Extreme Programming. Serão abordadas, de forma resumida, as práticas, valores, e os papéis disponíveis a cada integrante de uma equipe de XP. Alguns comparativos com outras metodologias são feitas ao decorrer do trabalho enaltecendo as propriedades que definem a Extreme Programming.
Palavras-chave: Extreme Programming , Engenharia de Software, Qualidade de Software, Metodologia de Desenvolvimento, Processos Ágeis de Desenvolvimento, XP.
Índice
• 1. Introdução
• 2. Extreme Programming (XP)
o 2.1. Valores da XP
 2.1.1 Feedback
 2.1.2 Comunicação
 2.1.3. Simplicidade
 2.1.4. Coragem
o 2.2. Práticas
 2.2.1. Cliente Disponível ou Presente
 2.2.2. Jogo do Planejamento
 2.2.3. Stand up meeting
 2.2.4. Programação em par
 2.2.5. Refactoring
 2.2.6. Desenvolvimento guiado por testes
 2.2.7. Código coletivo
 2.2.8. Padrões de desenvolvimento
 2.2.9. Design Simples
 2.2.10. Metáfora
 2.2.11. Ritmo Sustentável
 2.2.12. Integração contínua
 2.2.13. Releases curtos
o 2.3. Equipe XP
 2.3.1. Gerente de projeto
 2.3.2. Coach
 2.3.3. Analista de teste
 2.3.4. Redator técnico
 2.3.5. Desenvolvedor
• 3. Conclusões
• 4. Referências
• 5. Autores

1. Introdução
A muito tempo a indústria de software vem passando por grandes transformações e novos desafios, entre eles desenvolver softwares com qualidade, no menor tempo possível e que atendam as necessidades dos clientes.
Com estes novos desafios a indústria de software passou a dar valor a algumas áreas da informática, como a engenharia de software e qualidade de software, com intuito de atender as exigências do mercado.
A indústria começou a utilizar metodologias de desenvolvimento de software, adotou métricas e padrões para alcançar níveis aceitáveis de qualidade, prever custos e prazos em seus projetos. Porém ainda são poucos os projetos que conseguem obter pleno sucesso em seu desenvolvimento, onde prazo e orçamento estabelecidos e as necessidades do cliente sejam realmente atendidas.
Pesquisa feitas pelo Standish Group International em 1994, um pouco antes da adoção de metodologia de desenvolvimento pelas indústrias, apontam que apenas 16, 2 % dos projetos de software atingiam sucesso (prazo, orçamento e funcionalidades atendidas). Em 2002 esta taxa havia subido para 34 %, ou seja, um aumento de 100 % em 8 anos. Mas estas taxas ainda se encontram muito aquém do esperado pelo mercado.
As metodologias utilizadas nos projetos pesquisados eram as mais variadas, podemos citar modelo em cascata, modelo iterativo e alguns com modelo em prototipação. Neste trabalho será utilizado o termo desenvolvimento tradicional para os projetos que se utilizem do modelo em cascata e todos os outros que se baseiam nele.
Analisando os motivos para a baixa taxa de sucesso dos projetos desenvolvidos com modelos tradicionais, cita-se os principais motivos e bastante comuns entre eles:
•
Tempo elevado entre cada fase do projeto, não acompanhando as mudanças de requisitos do projeto;
•
Falta de conhecimento por parte do cliente da sua real necessidade, dando margem às especulações dos desenvolvedores;
•
Forte linearidade no desenvolvimento do projeto;
Focando nas fragilidades do modelo tradicional, surgiram metodologias para desenvolvimento ágil de software. Cita-se algumas características destas metodologias:
•
Foco nas pessoas, não no processo, evitando especulações dos desenvolvedores;
•
Atender as reais necessidades do cliente, na velocidade e praticidade por ele desejada;
•
Ausência de linearidade no desenvolvimento do projeto;
•
O cliente aprender a suas reais necessidades durante o projeto e repassar esta novas necessidades a equipe de desenvolvimento;

Uma destas metodologias de desenvolvimento ágil é o Extreme Programming , metodologia que prima a qualidade do software desenvolvido, que atenda as reais necessidades do cliente e seja entregue dentro do prazo definido. Esta metodologia será detalhada a seguir.
2. Extreme Programming (XP)
XP é uma metodologia para desenvolvimento de software ágil, com qualidade e que atenda as necessidades do cliente. Alguns praticantes definem a XP como a prática e a perseguição da mais clara simplicidade, aplicado ao desenvolvimento de software.
Uma metodologia voltada para projetos cujos requisitos mudem com freqüência, utilizem desenvolvimento orientado a objetos, equipes de até 12 desenvolvedores e desenvolvimento incremental.
A XP Busca o máximo de valor a cada dia de trabalho da equipe para o seu cliente. Em um curto espaço de tempo o cliente terá um produto que possa ser utilizado, podendo aprender com o mesmo e reavaliar se o que foi desenvolvido é realmente o desejado.
Por ser uma metodologia recente, a XP sofre mudanças em suas concepções e, portanto, é comum encontrar variações. A adaptação ao ambiente de desenvolvimento deve ser levada em conta, se um valor trouxer mais prejuízos do que benefícios é necessário relavaliar a utilização desta metodologia.
A XP é organizada em torno de um conjunto de práticas e valores que atuam perfeitamente para assegurar um alto retorno do investimento efetuado pelo cliente. A seguir serão apresentados os valores e em seguida as práticas.
2.1 Valores da XP
Os valores são as diretrizes da XP. Eles definirão as atitudes das equipes e as principais prioridades da metodologia.
Para uma empresa estar realmente utilizando o XP, ela deve respeitar e utilizar todos os valores e práticas listadas nos próximos capítulos e caso um destes valores ou práticas não seja utilizado pela empresa, esta empresa não está trabalhando com a metodologia XP.
2.1.1 Feedback
O cliente aprende com o sistema que utiliza e com este aprendizado consegue reavaliar o produto recebido, com isso pode realimentar a equipe de desenvolvimento com as suas reais necessidades. Com o feedback , o cliente conduz o desenvolvimento do seu produto, estabelece prioridades e informa aquilo que é realmente importante.
Analogamente, há o feedback dado pelo desenvolvedor ao cliente, onde o mesmo aponta riscos, estimativas e alternativas de design . Este retorno é o aprendizado do desenvolvedor sobre o que o cliente deseja.
Com este valor, o tempo de defasagem entre as fases do projeto são extremamente pequenos, o cliente está o tempo todo em contato com a equipe de desenvolvimento, muito diferente dos modelos tradicionais, onde o cliente entrava em contato com a equipe um bom tempo depois do último feedback dado.
Um ponto que muitas empresas de software falham é não dar valor ao que o cliente realmente deseja, utilizam cegamente metodologias e acabam esquecendo o real propósito de um software: facilitar o trabalho de pessoas.
Com isto muitos sistemas acabam dificultando e burocratizando as tarefas das pessoas e como defesa as empresas alegam ter um produto genérico e que atenda as normais legais.
2.1.2 Comunicação
Para que o feedback entre cliente e desenvolvedor possa ser efetuado com sucesso é necessário ter uma boa comunicação entre eles. A XP prega que esta comunicação ocorra da forma mais direta e eficaz possível, oferecendo agilidade aos assuntos tratados. Recomenda-se o contato direto (face-a-face) entre cliente e desenvolvedor, para evitar qualquer tipo de especulação ou mal entendido entre as partes e para que possíveis dúvidas possam ser resolvidas de imediato.
Além de sanar as dúvidas no desenvolvimento, o cliente deverá estar disponível para a equipe, ou mesmo presente no ambiente de trabalho da empresa. Isto fará com que o cliente entenda o sistema e enriquecerá os relacionamentos pessoais, criando um elo de parceria e confiança mútua.
Algumas equipes não se adaptam bem a este valor. Este problema deve ser trabalhado em conjunto com a equipe. Enquanto não se acostumarem a falar e a trocar idéias com seus companheiros o sucesso da metodologia estará comprometido. Membros introvertidos são deseconselháveis para equipes de XP.
2.1.3 Simplicidade
Para que o cliente possa aprender durante o projeto e consiga dar o feedback necessário à equipe, não basta apenas uma boa comunicação, é necessário que os desenvolvedores implementem da forma mais simples possível o que o cliente deseja.
A lei é: faça a coisa mais simples que pode funcionar. Com esta filosofia, o cliente terá a funcionalidade rapidamente e da forma desejada, dando um feedback instantaneamente evitando especulações. O desenvolvedor deve implementar apenas o necessário para que o cliente tenha seu pedido atendido.
Ser simples não é um ato de desespero, é um ato de consciência e absoluta precisão. Muitas pessoas confundem simplicidade e facilidade. O mais simples nem sempre é o mais fácil e também não é escrever menos código. Simplicidade significa codificar o necessário para que um requisito seja atendido e entregue ao cliente.
Evita-se suposições, o futuro é incerto e por causa disso não necessita atenção. Os requisitos evoluem gradativamente em conjunto com o sistema e a arquitetura do projeto. Algumas vezes, o que é necessário hoje será descartado amanhã, e outras vezes o que seria necessário num futuro próximo nunca será utilizado.
2.1.4 Coragem
Por ser um processo de desenvolvimento novo e baseado em diversas premissas que contrariam o modelo tradicional, o XP exige que os desenvolvedores tenham coragem para:
•
Desenvolver software de forma incremental;
•
Manter o sistema simples;
•
Permitir que o cliente defina prioridades;
•
Fazer desenvolvedores trabalharem em pares:
•
Investir tempo em refactoring ;
•
Investir tempo em testes automatizados;
•
Estimar estórias na presença do cliente;
•
Expor código a todos os membros da equipe;
•
Integrar o sistema diversas vezes ao dia;
•
Adotar ritmo sustentável de desenvolvimento;
•
Abrir mão de documentos que servem como defesa;
•
Propor contratos de escopo variável;
•
Propor a adoção de um processo novo.
•
Assumir em relação ao cliente possíveis atrasos e problemas de implementação;
•
Colocar desenvolvedores e clientes frente a frente;
•
Implantar uma nova versão do sistema no cliente semanalmente;
•
Apostar em seus colaboradores aumentando suas responsabilidades;
•
Modelar e documentar apenas quando for de extrema necessidade.
2.2 Praticas da XP
Como o nome já diz, as práticas são um conjunto de atividades que deverão ser seguidas pelas equipes que desejam utilizar a XP.
Os valores já apresentados somados a estas práticas são um conjunto ? entrelaçado ? de boas atitudes. A fraquesa de umas é compensado por outra e assim fecha-se um ciclo fortemente dependente.
2.2.1 Cliente disponível ou presente
O XP trabalha com uma visão diferente do modelo tradicional em relação ao cliente. O XP sugere que o cliente esteja no dia-a-dia do projeto, acompanhando os passos dos desenvolvedores, onde a sua ausência representa sérios riscos ao projeto.
As funcionalidades do sistema são descritas brevemente em estórias em conjunto com os testes conceituais e serão estes os indicadores para uma boa implementação. No momento que os desenvolvedores irão implementar as estórias nada mais eficaz do que dialogar com o cliente para entender a estória, fazendo-se necessária a presença do cliente no ambiente de desenvolvimento.
Ao terminar uma estória, com a presença do cliente, a mesma poderá ser validada rapidamente e a equipe receber o feedback necessário sobre a funcionalidade, criando ciclos rápidos e precisos.
2.2.2 Jogo de planejamento
A XP utiliza o planejamento para assegurar que a equipe de desenvolvimento esteja trabalhando naquilo que gere o máximo de valor para o cliente. Este planejamento é feito várias vezes durante o projeto. é o momento onde o cliente solicita as funcionalidades desejadas através de estórias, onde a equipe estima o custo de cada estória e planeja as releases e as iterações.
Todas as funcionalidades do sistema são descritas em estórias, pequenos cartões em que o cliente deve descrever o que deseja com suas palavras e da forma mais simples possível. Lembrando que a simplicidade também deve ser respeitada pelo cliente.
Após a definição das estórias é necessário estimar o tempo das mesmas para que o cliente priorize o que deve ser implementado. A XP utiliza uma unidade chamada ponto , que refere-se a um dia de trabalho ideal do desenvolvedor, onde o mesmo não precisaria atender telefonemas, participar de reuniões, ou seja, estaria preocupado apenas com a estória em questão.
Muitas vezes algumas estórias consomem semanas de trabalho, oferecendo uma certa dificuldade de serem estimadas. A XP recomenda que estas estórias sejam quebradas em tarefas menores e que as mesmas não utilizem mais que alguns pontos de um desenvolvedor, recomenda-se 4 pontos ao máximo.
Em cada estória é escrita a quantidade de pontos estimadas pelo desenvolvedor, o XP recomenda que as estimativas sejam efetuadas em equipe e se possível com a presença do cliente para que durante a estimativa eventuais dúvidas sejam sanadas.
O XP tem por objetivo gerar valor para o cliente ao longo do projeto, para isto o software é desenvolvido de forma incremental, onde a cada entrega o cliente possa utilizar o sistema e obter benefícios do mesmo. Estas entregas o XP denomina como sendo releases , pequenos intervalos de tempo, máximo 2 meses, onde funcionalidades que gerem valor ao cliente sejam entregues.
A divisão dos releases é efetuada no início do projeto, geralmente com tamanhos fixos e pequenos. Após esta divisão o cliente define as estórias que farão parte dos releases e tenta-se evitar um planejamento muito longo, pois na entrega de cada release o cliente aprenderá com o sistema e possivelmente irá alterar as estórias para o próximo release .
Mesmo os releases sendo efetuados em curto espaço de tempo, continua representando um tempo muito longo para o feedback do cliente. Por esta razão os releases são divididos em espaços menores, chamados de iterações .
Uma iteração contêm um conjunto de estórias a serem implementadas, com duração entre uma a três semanas, onde ao final da mesma o cliente possa validar as implementações efetuadas e fornecer o feedback necessário à equipe.
2.2.3 Stand up meeting
O dia de trabalho de uma equipe XP sempre começa com um stand up meeting . é uma reunião rápida pela manhã, com aproximadamente 20 minutos de duração e onde seus integrantes permaneçam preferencialmente em pé.
Segundo estudos uma reunião em pé é mais rápida, evita bate-papos paralelos e faz os integrantes irem diretamente ao assunto. Mais uma vez, ágil e simples.
A reunião tem por objetivo atualizar a equipe sobre o que foi implementado no dia anterior e trocar experiências das dificuldades enfrentadas. Neste momento também são decididas as estórias que serão implementadas no dia e em conjunto definir os responsáveis por cada uma delas.
2.2.4 Programação em par
O XP exige que todo e qualquer código implementado no projeto seja efetuado em dupla, chamada de programação em par. é uma técnica onde dois desenvolvedores trabalham no mesmo problema, ao mesmo tempo e no mesmo computador. Um deles é responsável pela digitação (condutor) e outro acompanhando o trabalho do parceiro (navegador).
Esta prática agrega diversas técnicas de programação, enquanto o condutor codifica o problema o navegador permanentemente revisa o código digitado, onde pequenos erros de programação que demoraria algumas horas para serem depurados, facilmente são percebidos pelo navegador da dupla.
Um dos grandes benefícios da programação em par é a troca de experiências e idéias entre os desenvolvedores. A solução para um problema geralmente é a soma das idéias da dupla, tornando uma solução e codificação muito mais simples e eficaz.
é com esta prática que o XP uniformiza o nível dos desenvolvedores da equipe, através da troca de experiências. Após alguns meses trabalhando em duplas todos os desenvolvedores conhecerão todas rotinas do sistema, prontos para qualquer modificação ou para auxiliar algum iniciante.
Um grande questionamento sobre esta prática é com questão a produtividade dos desenvolvedores. Porém, é um erro pensar que somente uma pessoa estará codificando enquanto o outro apenas observa. O membro que não está codificando não apenas observa, mas também troca idéias, gera soluções e evita praticamente todos erros de codificação além de cobrar padrões de desenvolvimento da equipe.
Estudos indicam que a produtividade de uma equipe que utiliza pair programming e de equipes que tenham desenvolvedores sozinhos é praticamente a mesma, porém a qualidade do código gera facilidade de manutenção e outros ganhos a médio e longo prazo.
2.2.5 Refactoring
Um desenvolvedor ao deparar com um código mal escrito ou pouco legível mas que esteja funcionando, nos modelos tradicionais de desenvolvimento, dificilmente efetuaria alterações neste código, mesmo que tivesse que implementar novas funcionalidades.
O XP prega que todo desenvolvedor ao encontrar um código duplicado, pouco legível, mal codificado, sem padronização, lento, com código legado ou uso incorreto de outras implementações, tem por obrigação alterar este código deixando-o mais legível e simples, porém esta alteração não pode mudar o comportamento do código em questão.
Esta prática anda de mãos dadas com o código coletivo, já que todo desenvolvedor tem a possibilidade de melhorar qualquer código do sistema.
A padronização oferece facilidades aos desenvolvedores no momento de implementar novas funcionalidades ou efetuar qualquer tipo de manutenção, uma vez que o código se encontra simples e claro.
Uma questão importante é que a prática de refactoring esta apoiada pelos testes automatizados, pois facilmente o desenvolvedor terá um feedback se a alteração por ele efetuada irá gerar qualquer tipo de comportamento anormal no sistema, sofrendo o aprendizado sobre a alteração por ele efetuada.
2.2.6 Desenvolvimento guiado por testes
Esta atividade é considerada extremamente chata e dispendiosa por muitos desenvolvedores na modelagem tradicional, porém para os desenvolvedores de uma equipe XP esta atividade deve ser encarada com extrema naturalidade. Todo código implementando deve coexistir com um teste automatizado, assim garantindo o pleno funcionamento da nova funcionalidade.
é com base nestes testes automatizados que qualquer desenvolvedor terá coragem para alterar uma parte do código que não tenha sido implementada por ele, já que executando os testes automatizados poderá verificar instantaneamente se a modificação efetuada alterou o comportamento do sistema.
Com a implementação de testes o desenvolvedor poderá amadurecer o entendimento sobre o problema que irá solucionar, já que os testes são codificados antes da nova implementação.
No XP existem dois tipos de testes, os testes de unidade e de aceitação. O teste de unidade tem por objetivo verificar se os resultados gerados por cada classe estão corretos, já o teste de aceitação tem por objetivo verificar se a interação entre as classes que implementam uma funcionalidade (estória) atendem a necessidade de forma correta. Os testes de aceitação são descritos pelo cliente e implementados pelos desenvolvedores, facilitando ainda mais a interação entre as partes.
2.2.7 Código coletivo
No modelo tradicional de desenvolvimento, é comum dividir o projeto em partes e colocar responsáveis por cada uma destas partes. Porém apenas uma pessoa torna-se conhecedora daquela parte.
Este tipo de divisão traz sérios problemas ao projeto, uma vez que se aquela parte necessitar inúmeras alterações, apenas uma pessoa estará capacitada para alterá-la. Com estas inúmeras alterações, esta pessoa pode se tornar um gargalo no projeto.
O XP trava uma batalha contra este tipo de divisão, já que não existe uma pessoa responsável por uma parte do código. Cada desenvolvedor tem acesso a qualquer parte do sistema e tem liberdade para alterá-la a qualquer momento e sem qualquer tipo de aviso.
Esta prática tem como conseqüência um código revisado por diversas pessoas e caso algo não esteja claro, com certeza será alterado por alguma pessoa ( refactoring ) para que o mesmo torne-se legível.
2.2.8 Padrões de desenvolvimento
Um dos valores do XP é a comunicação, e o código também é uma forma da equipe se comunicar. Uma forma clara de se comunicar através do código, é manter um padrão no projeto para que qualquer um possa rapidamente entender o código lido.
O XP recomenda a adoção de um padrão desde o início do projeto, preferencialmente padrões utilizados pela comunidade da linguagem de desenvolvimento. Havendo a necessidade de modificações e adaptações durante o projeto, que visam agilizar o desenvolvimento, as mesmas devem ser efetuadas.
2.2.9 Design simples
Nota-se que todas as práticas do XP focam que o maior valor possível seja gerado para o cliente, para tal premissa ser verdadeira o XP prega um design do sistema da forma mais simples possível para que atenda a necessidade do cliente.
Umas das premissas do desenvolvimento tradicional é que o custo de uma alteração no sistema cresce exponencialmente ao longo do projeto, com isto tenta-se criar soluções genéricas preparando o sistema para futuras alterações.
Este tipo de pensamento dá margens para especulações e implementações que na maioria dos casos não terá utilidade para o cliente. O XP parte do princípio que o custo de uma alteração tende a crescer lentamente e se estabilizar ao longo do projeto, esta premissa é dita em função dos avanços nas linguagens e práticas de programação, novos ambientes e ferramentas de desenvolvimento, utilização de orientação a objetos no desenvolvimento e em conjunto com estes novos avanços existe o fruto das outras práticas XP, deixando o código simples, legível e passível de alteração a qualquer momento.
2.2.10 Metáfora
Muitas vezes pessoas tentam explicar um assunto ou problema a outras pessoas por um período sem obter o êxito necessário na explicação dada, simplesmente as outras pessoas não conseguem entender a mensagem que está se tentando repassar.
Ao criar comparações e analogias com o assunto que está em questão as pessoas passarão a entender deste assunto de uma forma muito mais rápida e possivelmente não a esquecerão mais. Este tipo de artifício é chamado de metáfora no XP, e deve ser utilizado com intensidade durante o projeto, uma vez que facilita a comunicação e fixação dos assuntos entre as partes.
Esta prática anda em conjunto com o ritmo sustentável, já que para o desenvolvedor criar boas metáforas exige criatividade e desenvolvimento de idéias, o que torna necessário uma boa condição física e bem estar por parte do desenvolvedor.
2.2.11 Ritmo sustentável
Uma grande problema nos projetos de software é a falta de tempo para encerrar o mesmo, e uma das técnicas mais adotadas para compensar a falta de tempo é submeter os desenvolvedores (humanos) a trabalharem até mais tarde e muitas vezes sacrificarem seus finais de semana.
Nos primeiros momentos este tipo de atitude tem efeitos positivos, porém passado alguns dias o rendimento da equipe cai drasticamente, dando margens a erros pela falta de concentração no desenvolvimento, justamente pelo cansaço físico do desenvolvedor.
O XP proíbe que os desenvolvedores trabalhem até mais tarde. O XP sugere um ritmo sustentável de 40 horas semanais, respeitando assim a individualidade e o físico de cada desenvolvedor. Desta forma a equipe estará sempre concentrada e muito menos propensa a pequenas falhas na implementação.
2.2.12 Integração contínua
No desenvolvimento tradicional geralmente as equipes são organizadas de modo que uma parte (módulo) fiquei sob responsabilidade de um desenvolvedor, cabe a esta pessoa efetuar testes e codificação que dizem respeito a sua parte. Esta estratégia reduz a complexidade e as preocupações de um desenvolvedor.
Interfaces de integração são convencionadas para que futuramente estas partes possam se comunicar, este tipo de desenvolvimento esta propenso a sérios erros de integração, uma vez que os períodos em que as partes são integradas e testadas são extremamente longos.
O XP propõe uma integração contínua, se possível deve ser efetuada diversas vezes ao dia para que toda a equipe tenha conhecimento do código recém desenvolvido. Com esta prática o feedback sobre a alteração efetuada será retornado em um menor espaço de tempo.
2.2.13 Releases curtos
No modelo tradicional o projeto é dividido em fases, de um modo que o cliente começará a ter benefício com o sistema muito próximo de o mesmo estar finalizado. A maior parte do investimento do projeto é feita antes mesmo de estar concluído, sem ter gerado qualquer tipo de valor econômico ao cliente.
O XP recomenda que pequenos investimento sejam efetuados de forma gradual e que busque grandes recompensas o mais rapidamente possível. Com a prática de releases curtos, o XP pretende dar o máximo de valor econômico ao cliente em um curto espaço de tempo.
Release é um conjunto de funcionalidade bem definidas e que representam algum valor para o cliente. Um projeto XP pode ter um ou mais releases no seu ciclo de desenvolvimento.
2.3 Equipe XP
Em uma equipe de XP existem papéis a serem desempenhados por um ou mais desenvolvedores. Estes papéis serão listados a seguir.
2.3.1 Gerente de projeto
Pessoa responsável pelos assuntos administrativos do projeto, mantendo um forte relacionamento com o cliente para que o mesmo participe das atividades do desenvolvimento.
O gerente de projeto é responsável por filtrar assuntos não relevantes aos desenvolvedores e aspectos que só devam ser implementados em iterações futuras.
Para um bom exercício de gerente de projeto é necessário que a pessoa conheça e acredite nos valores e práticas do XP para que possa cobrar isto da sua equipe.
2.3.2 Coach
Pessoa responsável pelas questões técnicas do projeto, recomenda-se que esta pessoa seja a com maior conhecimento do processo de desenvolvimento, dos valores e práticas do XP. é de responsabilidade do coach verificar o comportamento da equipe frente o processo XP, sinalizando os eventuais erros cometidos pela equipe.
2.3.3 Analista de teste
Pessoa responsável em garantir a qualidade do sistema através dos testes escritos. Ele deve ajudar o cliente a escrever os casos de testes e no final de cada iteração verificar se o software atende todos os casos de testes.
Recomenda-se que esta pessoa não seja um desenvolvedor, para evitar uma visão tendenciosa já que não conhece o código desenvolvido. O analista de teste deve ter uma visão muito parecida com a do cliente e em muitos projetos esta pessoa acaba exercendo o papel de redator técnico.
2.3.4 Redator técnico
Pessoa responsável em documentar o sistema, evitando um forte trabalho dos desenvolvedores neste tipo de atividade, permitindo uma maior dedicação ao trabalho de codificação.
Esta pessoa deve estar em plena sintonia com os desenvolvedores e cliente para que a documentação reflita o código escrito e as regras de negócio atendidas pelo sistema.
2.3.5 Desenvolvedor
Pessoa responsável em analisar, projetar e codificar o sistema. No XP não existe diferença entre analista, projetista e programador uma vez que em vários momentos do projeto o desenvolvedor estará exercendo alguma destas atividades.
Naturalmente existe níveis distintos de desenvolvedores dentro de uma equipe, mas com as práticas do XP, como pair programming , a tendência é a equipe se tornar uniforme em suas habilidades.
3 Conclusões
A metodologia de desenvolvimento Extreme Programming pode ser considerada extremamente nova, porém vem acompanhando as necessidades humanas dos desenvolvedores pelo mundo.
Gurus da tecnologia da informação vem aprimorando as concepções desta metodologia para atender as necessidades do mercado e principalmente das pessoas.
Um empresa ao utilizar este processo por completo, só estará agregando valor aos seus negócios e melhorando o ambiente de seus colaboradores e clientes, tratando-os como pessoas e parceiros. Está é chave no mundo dos negócios, o bem estar de seus colaboradores e a parceria entre o fornecedor e seus clientes, criando um laço de confiança ou até mesmo um sentimento de amizade.
Entender as necessidades do cliente não é ciência, é arte. Dar incentivo a ela é o mínimo que podemos fazer.

Extreme Programming , Engenharia de Software, Qualidade de Software, Metodologia de Desenvolvimento, Processos Ágeis de Desenvolvimento, XP.

1. Introdução

A muito tempo a indústria de software vem passando por grandes transformações e novos desafios, entre eles desenvolver softwares com qualidade, no menor tempo possível e que atendam as necessidades dos clientes.

Com estes novos desafios a indústria de software passou a dar valor a algumas áreas da informática, como a engenharia de software e qualidade de software, com intuito de atender as exigências do mercado.

A indústria começou a utilizar metodologias de desenvolvimento de software, adotou métricas e padrões para alcançar níveis aceitáveis de qualidade, prever custos e prazos em seus projetos. Porém ainda são poucos os projetos que conseguem obter pleno sucesso em seu desenvolvimento, onde prazo e orçamento estabelecidos e as necessidades do cliente sejam realmente atendidas.

Pesquisa feitas pelo Standish Group International em 1994, um pouco antes da adoção de metodologia de desenvolvimento pelas indústrias, apontam que apenas 16, 2 % dos projetos de software atingiam sucesso (prazo, orçamento e funcionalidades atendidas). Em 2002 esta taxa havia subido para 34 %, ou seja, um aumento de 100 % em 8 anos. Mas estas taxas ainda se encontram muito aquém do esperado pelo mercado.

As metodologias utilizadas nos projetos pesquisados eram as mais variadas, podemos citar modelo em cascata, modelo iterativo e alguns com modelo em prototipação. Neste trabalho será utilizado o termo desenvolvimento tradicional para os projetos que se utilizem do modelo em cascata e todos os outros que se baseiam nele.

Analisando os motivos para a baixa taxa de sucesso dos projetos desenvolvidos com modelos tradicionais, cita-se os principais motivos e bastante comuns entre eles:

*

Tempo elevado entre cada fase do projeto, não acompanhando as mudanças de requisitos do projeto;
*

Falta de conhecimento por parte do cliente da sua real necessidade, dando margem às especulações dos desenvolvedores;
*

Forte linearidade no desenvolvimento do projeto;

Focando nas fragilidades do modelo tradicional, surgiram metodologias para desenvolvimento ágil de software. Cita-se algumas características destas metodologias:

*

Foco nas pessoas, não no processo, evitando especulações dos desenvolvedores;
*

Atender as reais necessidades do cliente, na velocidade e praticidade por ele desejada;
*

Ausência de linearidade no desenvolvimento do projeto;
*

O cliente aprender a suas reais necessidades durante o projeto e repassar esta novas necessidades a equipe de desenvolvimento;


Uma destas metodologias de desenvolvimento ágil é o Extreme Programming , metodologia que prima a qualidade do software desenvolvido, que atenda as reais necessidades do cliente e seja entregue dentro do prazo definido. Esta metodologia será detalhada a seguir.
2. Extreme Programming (XP)

XP é uma metodologia para desenvolvimento de software ágil, com qualidade e que atenda as necessidades do cliente. Alguns praticantes definem a XP como a prática e a perseguição da mais clara simplicidade, aplicado ao desenvolvimento de software.

Uma metodologia voltada para projetos cujos requisitos mudem com freqüência, utilizem desenvolvimento orientado a objetos, equipes de até 12 desenvolvedores e desenvolvimento incremental.

A XP Busca o máximo de valor a cada dia de trabalho da equipe para o seu cliente. Em um curto espaço de tempo o cliente terá um produto que possa ser utilizado, podendo aprender com o mesmo e reavaliar se o que foi desenvolvido é realmente o desejado.

Por ser uma metodologia recente, a XP sofre mudanças em suas concepções e, portanto, é comum encontrar variações. A adaptação ao ambiente de desenvolvimento deve ser levada em conta, se um valor trouxer mais prejuízos do que benefícios é necessário relavaliar a utilização desta metodologia.

A XP é organizada em torno de um conjunto de práticas e valores que atuam perfeitamente para assegurar um alto retorno do investimento efetuado pelo cliente. A seguir serão apresentados os valores e em seguida as práticas.
2.1 Valores da XP

Os valores são as diretrizes da XP. Eles definirão as atitudes das equipes e as principais prioridades da metodologia.

Para uma empresa estar realmente utilizando o XP, ela deve respeitar e utilizar todos os valores e práticas listadas nos próximos capítulos e caso um destes valores ou práticas não seja utilizado pela empresa, esta empresa não está trabalhando com a metodologia XP.
2.1.1 Feedback

O cliente aprende com o sistema que utiliza e com este aprendizado consegue reavaliar o produto recebido, com isso pode realimentar a equipe de desenvolvimento com as suas reais necessidades. Com o feedback , o cliente conduz o desenvolvimento do seu produto, estabelece prioridades e informa aquilo que é realmente importante.

Analogamente, há o feedback dado pelo desenvolvedor ao cliente, onde o mesmo aponta riscos, estimativas e alternativas de design . Este retorno é o aprendizado do desenvolvedor sobre o que o cliente deseja.

Com este valor, o tempo de defasagem entre as fases do projeto são extremamente pequenos, o cliente está o tempo todo em contato com a equipe de desenvolvimento, muito diferente dos modelos tradicionais, onde o cliente entrava em contato com a equipe um bom tempo depois do último feedback dado.

Um ponto que muitas empresas de software falham é não dar valor ao que o cliente realmente deseja, utilizam cegamente metodologias e acabam esquecendo o real propósito de um software: facilitar o trabalho de pessoas.

Com isto muitos sistemas acabam dificultando e burocratizando as tarefas das pessoas e como defesa as empresas alegam ter um produto genérico e que atenda as normais legais.
2.1.2 Comunicação

Para que o feedback entre cliente e desenvolvedor possa ser efetuado com sucesso é necessário ter uma boa comunicação entre eles. A XP prega que esta comunicação ocorra da forma mais direta e eficaz possível, oferecendo agilidade aos assuntos tratados. Recomenda-se o contato direto (face-a-face) entre cliente e desenvolvedor, para evitar qualquer tipo de especulação ou mal entendido entre as partes e para que possíveis dúvidas possam ser resolvidas de imediato.

Além de sanar as dúvidas no desenvolvimento, o cliente deverá estar disponível para a equipe, ou mesmo presente no ambiente de trabalho da empresa. Isto fará com que o cliente entenda o sistema e enriquecerá os relacionamentos pessoais, criando um elo de parceria e confiança mútua.

Algumas equipes não se adaptam bem a este valor. Este problema deve ser trabalhado em conjunto com a equipe. Enquanto não se acostumarem a falar e a trocar idéias com seus companheiros o sucesso da metodologia estará comprometido. Membros introvertidos são deseconselháveis para equipes de XP.
2.1.3 Simplicidade

Para que o cliente possa aprender durante o projeto e consiga dar o feedback necessário à equipe, não basta apenas uma boa comunicação, é necessário que os desenvolvedores implementem da forma mais simples possível o que o cliente deseja.

A lei é: faça a coisa mais simples que pode funcionar. Com esta filosofia, o cliente terá a funcionalidade rapidamente e da forma desejada, dando um feedback instantaneamente evitando especulações. O desenvolvedor deve implementar apenas o necessário para que o cliente tenha seu pedido atendido.

Ser simples não é um ato de desespero, é um ato de consciência e absoluta precisão. Muitas pessoas confundem simplicidade e facilidade. O mais simples nem sempre é o mais fácil e também não é escrever menos código. Simplicidade significa codificar o necessário para que um requisito seja atendido e entregue ao cliente.

Evita-se suposições, o futuro é incerto e por causa disso não necessita atenção. Os requisitos evoluem gradativamente em conjunto com o sistema e a arquitetura do projeto. Algumas vezes, o que é necessário hoje será descartado amanhã, e outras vezes o que seria necessário num futuro próximo nunca será utilizado.
2.1.4 Coragem

Por ser um processo de desenvolvimento novo e baseado em diversas premissas que contrariam o modelo tradicional, o XP exige que os desenvolvedores tenham coragem para:

*

Desenvolver software de forma incremental;
*

Manter o sistema simples;
*

Permitir que o cliente defina prioridades;
*

Fazer desenvolvedores trabalharem em pares:
*

Investir tempo em refactoring ;
*

Investir tempo em testes automatizados;
*

Estimar estórias na presença do cliente;
*

Expor código a todos os membros da equipe;
*

Integrar o sistema diversas vezes ao dia;
*

Adotar ritmo sustentável de desenvolvimento;
*

Abrir mão de documentos que servem como defesa;
*

Propor contratos de escopo variável;
*

Propor a adoção de um processo novo.
*

Assumir em relação ao cliente possíveis atrasos e problemas de implementação;
*

Colocar desenvolvedores e clientes frente a frente;
*

Implantar uma nova versão do sistema no cliente semanalmente;
*

Apostar em seus colaboradores aumentando suas responsabilidades;
*

Modelar e documentar apenas quando for de extrema necessidade.

2.2 Praticas da XP

Como o nome já diz, as práticas são um conjunto de atividades que deverão ser seguidas pelas equipes que desejam utilizar a XP.

Os valores já apresentados somados a estas práticas são um conjunto ? entrelaçado ? de boas atitudes. A fraquesa de umas é compensado por outra e assim fecha-se um ciclo fortemente dependente.
2.2.1 Cliente disponível ou presente

O XP trabalha com uma visão diferente do modelo tradicional em relação ao cliente. O XP sugere que o cliente esteja no dia-a-dia do projeto, acompanhando os passos dos desenvolvedores, onde a sua ausência representa sérios riscos ao projeto.

As funcionalidades do sistema são descritas brevemente em estórias em conjunto com os testes conceituais e serão estes os indicadores para uma boa implementação. No momento que os desenvolvedores irão implementar as estórias nada mais eficaz do que dialogar com o cliente para entender a estória, fazendo-se necessária a presença do cliente no ambiente de desenvolvimento.

Ao terminar uma estória, com a presença do cliente, a mesma poderá ser validada rapidamente e a equipe receber o feedback necessário sobre a funcionalidade, criando ciclos rápidos e precisos.
2.2.2 Jogo de planejamento

A XP utiliza o planejamento para assegurar que a equipe de desenvolvimento esteja trabalhando naquilo que gere o máximo de valor para o cliente. Este planejamento é feito várias vezes durante o projeto. é o momento onde o cliente solicita as funcionalidades desejadas através de estórias, onde a equipe estima o custo de cada estória e planeja as releases e as iterações.

Todas as funcionalidades do sistema são descritas em estórias, pequenos cartões em que o cliente deve descrever o que deseja com suas palavras e da forma mais simples possível. Lembrando que a simplicidade também deve ser respeitada pelo cliente.

Após a definição das estórias é necessário estimar o tempo das mesmas para que o cliente priorize o que deve ser implementado. A XP utiliza uma unidade chamada ponto , que refere-se a um dia de trabalho ideal do desenvolvedor, onde o mesmo não precisaria atender telefonemas, participar de reuniões, ou seja, estaria preocupado apenas com a estória em questão.

Muitas vezes algumas estórias consomem semanas de trabalho, oferecendo uma certa dificuldade de serem estimadas. A XP recomenda que estas estórias sejam quebradas em tarefas menores e que as mesmas não utilizem mais que alguns pontos de um desenvolvedor, recomenda-se 4 pontos ao máximo.

Em cada estória é escrita a quantidade de pontos estimadas pelo desenvolvedor, o XP recomenda que as estimativas sejam efetuadas em equipe e se possível com a presença do cliente para que durante a estimativa eventuais dúvidas sejam sanadas.

O XP tem por objetivo gerar valor para o cliente ao longo do projeto, para isto o software é desenvolvido de forma incremental, onde a cada entrega o cliente possa utilizar o sistema e obter benefícios do mesmo. Estas entregas o XP denomina como sendo releases , pequenos intervalos de tempo, máximo 2 meses, onde funcionalidades que gerem valor ao cliente sejam entregues.

A divisão dos releases é efetuada no início do projeto, geralmente com tamanhos fixos e pequenos. Após esta divisão o cliente define as estórias que farão parte dos releases e tenta-se evitar um planejamento muito longo, pois na entrega de cada release o cliente aprenderá com o sistema e possivelmente irá alterar as estórias para o próximo release .

Mesmo os releases sendo efetuados em curto espaço de tempo, continua representando um tempo muito longo para o feedback do cliente. Por esta razão os releases são divididos em espaços menores, chamados de iterações .

Uma iteração contêm um conjunto de estórias a serem implementadas, com duração entre uma a três semanas, onde ao final da mesma o cliente possa validar as implementações efetuadas e fornecer o feedback necessário à equipe.
2.2.3 Stand up meeting

O dia de trabalho de uma equipe XP sempre começa com um stand up meeting . é uma reunião rápida pela manhã, com aproximadamente 20 minutos de duração e onde seus integrantes permaneçam preferencialmente em pé.

Segundo estudos uma reunião em pé é mais rápida, evita bate-papos paralelos e faz os integrantes irem diretamente ao assunto. Mais uma vez, ágil e simples.

A reunião tem por objetivo atualizar a equipe sobre o que foi implementado no dia anterior e trocar experiências das dificuldades enfrentadas. Neste momento também são decididas as estórias que serão implementadas no dia e em conjunto definir os responsáveis por cada uma delas.
2.2.4 Programação em par

O XP exige que todo e qualquer código implementado no projeto seja efetuado em dupla, chamada de programação em par. é uma técnica onde dois desenvolvedores trabalham no mesmo problema, ao mesmo tempo e no mesmo computador. Um deles é responsável pela digitação (condutor) e outro acompanhando o trabalho do parceiro (navegador).

Esta prática agrega diversas técnicas de programação, enquanto o condutor codifica o problema o navegador permanentemente revisa o código digitado, onde pequenos erros de programação que demoraria algumas horas para serem depurados, facilmente são percebidos pelo navegador da dupla.

Um dos grandes benefícios da programação em par é a troca de experiências e idéias entre os desenvolvedores. A solução para um problema geralmente é a soma das idéias da dupla, tornando uma solução e codificação muito mais simples e eficaz.

é com esta prática que o XP uniformiza o nível dos desenvolvedores da equipe, através da troca de experiências. Após alguns meses trabalhando em duplas todos os desenvolvedores conhecerão todas rotinas do sistema, prontos para qualquer modificação ou para auxiliar algum iniciante.

Um grande questionamento sobre esta prática é com questão a produtividade dos desenvolvedores. Porém, é um erro pensar que somente uma pessoa estará codificando enquanto o outro apenas observa. O membro que não está codificando não apenas observa, mas também troca idéias, gera soluções e evita praticamente todos erros de codificação além de cobrar padrões de desenvolvimento da equipe.

Estudos indicam que a produtividade de uma equipe que utiliza pair programming e de equipes que tenham desenvolvedores sozinhos é praticamente a mesma, porém a qualidade do código gera facilidade de manutenção e outros ganhos a médio e longo prazo.
2.2.5 Refactoring

Um desenvolvedor ao deparar com um código mal escrito ou pouco legível mas que esteja funcionando, nos modelos tradicionais de desenvolvimento, dificilmente efetuaria alterações neste código, mesmo que tivesse que implementar novas funcionalidades.

O XP prega que todo desenvolvedor ao encontrar um código duplicado, pouco legível, mal codificado, sem padronização, lento, com código legado ou uso incorreto de outras implementações, tem por obrigação alterar este código deixando-o mais legível e simples, porém esta alteração não pode mudar o comportamento do código em questão.

Esta prática anda de mãos dadas com o código coletivo, já que todo desenvolvedor tem a possibilidade de melhorar qualquer código do sistema.

A padronização oferece facilidades aos desenvolvedores no momento de implementar novas funcionalidades ou efetuar qualquer tipo de manutenção, uma vez que o código se encontra simples e claro.

Uma questão importante é que a prática de refactoring esta apoiada pelos testes automatizados, pois facilmente o desenvolvedor terá um feedback se a alteração por ele efetuada irá gerar qualquer tipo de comportamento anormal no sistema, sofrendo o aprendizado sobre a alteração por ele efetuada.
2.2.6 Desenvolvimento guiado por testes

Esta atividade é considerada extremamente chata e dispendiosa por muitos desenvolvedores na modelagem tradicional, porém para os desenvolvedores de uma equipe XP esta atividade deve ser encarada com extrema naturalidade. Todo código implementando deve coexistir com um teste automatizado, assim garantindo o pleno funcionamento da nova funcionalidade.

é com base nestes testes automatizados que qualquer desenvolvedor terá coragem para alterar uma parte do código que não tenha sido implementada por ele, já que executando os testes automatizados poderá verificar instantaneamente se a modificação efetuada alterou o comportamento do sistema.

Com a implementação de testes o desenvolvedor poderá amadurecer o entendimento sobre o problema que irá solucionar, já que os testes são codificados antes da nova implementação.

No XP existem dois tipos de testes, os testes de unidade e de aceitação. O teste de unidade tem por objetivo verificar se os resultados gerados por cada classe estão corretos, já o teste de aceitação tem por objetivo verificar se a interação entre as classes que implementam uma funcionalidade (estória) atendem a necessidade de forma correta. Os testes de aceitação são descritos pelo cliente e implementados pelos desenvolvedores, facilitando ainda mais a interação entre as partes.
2.2.7 Código coletivo

No modelo tradicional de desenvolvimento, é comum dividir o projeto em partes e colocar responsáveis por cada uma destas partes. Porém apenas uma pessoa torna-se conhecedora daquela parte.

Este tipo de divisão traz sérios problemas ao projeto, uma vez que se aquela parte necessitar inúmeras alterações, apenas uma pessoa estará capacitada para alterá-la. Com estas inúmeras alterações, esta pessoa pode se tornar um gargalo no projeto.

O XP trava uma batalha contra este tipo de divisão, já que não existe uma pessoa responsável por uma parte do código. Cada desenvolvedor tem acesso a qualquer parte do sistema e tem liberdade para alterá-la a qualquer momento e sem qualquer tipo de aviso.

Esta prática tem como conseqüência um código revisado por diversas pessoas e caso algo não esteja claro, com certeza será alterado por alguma pessoa ( refactoring ) para que o mesmo torne-se legível.
2.2.8 Padrões de desenvolvimento

Um dos valores do XP é a comunicação, e o código também é uma forma da equipe se comunicar. Uma forma clara de se comunicar através do código, é manter um padrão no projeto para que qualquer um possa rapidamente entender o código lido.

O XP recomenda a adoção de um padrão desde o início do projeto, preferencialmente padrões utilizados pela comunidade da linguagem de desenvolvimento. Havendo a necessidade de modificações e adaptações durante o projeto, que visam agilizar o desenvolvimento, as mesmas devem ser efetuadas.
2.2.9 Design simples

Nota-se que todas as práticas do XP focam que o maior valor possível seja gerado para o cliente, para tal premissa ser verdadeira o XP prega um design do sistema da forma mais simples possível para que atenda a necessidade do cliente.

Umas das premissas do desenvolvimento tradicional é que o custo de uma alteração no sistema cresce exponencialmente ao longo do projeto, com isto tenta-se criar soluções genéricas preparando o sistema para futuras alterações.

Este tipo de pensamento dá margens para especulações e implementações que na maioria dos casos não terá utilidade para o cliente. O XP parte do princípio que o custo de uma alteração tende a crescer lentamente e se estabilizar ao longo do projeto, esta premissa é dita em função dos avanços nas linguagens e práticas de programação, novos ambientes e ferramentas de desenvolvimento, utilização de orientação a objetos no desenvolvimento e em conjunto com estes novos avanços existe o fruto das outras práticas XP, deixando o código simples, legível e passível de alteração a qualquer momento.
2.2.10 Metáfora

Muitas vezes pessoas tentam explicar um assunto ou problema a outras pessoas por um período sem obter o êxito necessário na explicação dada, simplesmente as outras pessoas não conseguem entender a mensagem que está se tentando repassar.

Ao criar comparações e analogias com o assunto que está em questão as pessoas passarão a entender deste assunto de uma forma muito mais rápida e possivelmente não a esquecerão mais. Este tipo de artifício é chamado de metáfora no XP, e deve ser utilizado com intensidade durante o projeto, uma vez que facilita a comunicação e fixação dos assuntos entre as partes.

Esta prática anda em conjunto com o ritmo sustentável, já que para o desenvolvedor criar boas metáforas exige criatividade e desenvolvimento de idéias, o que torna necessário uma boa condição física e bem estar por parte do desenvolvedor.
2.2.11 Ritmo sustentável

Uma grande problema nos projetos de software é a falta de tempo para encerrar o mesmo, e uma das técnicas mais adotadas para compensar a falta de tempo é submeter os desenvolvedores (humanos) a trabalharem até mais tarde e muitas vezes sacrificarem seus finais de semana.

Nos primeiros momentos este tipo de atitude tem efeitos positivos, porém passado alguns dias o rendimento da equipe cai drasticamente, dando margens a erros pela falta de concentração no desenvolvimento, justamente pelo cansaço físico do desenvolvedor.

O XP proíbe que os desenvolvedores trabalhem até mais tarde. O XP sugere um ritmo sustentável de 40 horas semanais, respeitando assim a individualidade e o físico de cada desenvolvedor. Desta forma a equipe estará sempre concentrada e muito menos propensa a pequenas falhas na implementação.
2.2.12 Integração contínua

No desenvolvimento tradicional geralmente as equipes são organizadas de modo que uma parte (módulo) fiquei sob responsabilidade de um desenvolvedor, cabe a esta pessoa efetuar testes e codificação que dizem respeito a sua parte. Esta estratégia reduz a complexidade e as preocupações de um desenvolvedor.

Interfaces de integração são convencionadas para que futuramente estas partes possam se comunicar, este tipo de desenvolvimento esta propenso a sérios erros de integração, uma vez que os períodos em que as partes são integradas e testadas são extremamente longos.

O XP propõe uma integração contínua, se possível deve ser efetuada diversas vezes ao dia para que toda a equipe tenha conhecimento do código recém desenvolvido. Com esta prática o feedback sobre a alteração efetuada será retornado em um menor espaço de tempo.
2.2.13 Releases curtos

No modelo tradicional o projeto é dividido em fases, de um modo que o cliente começará a ter benefício com o sistema muito próximo de o mesmo estar finalizado. A maior parte do investimento do projeto é feita antes mesmo de estar concluído, sem ter gerado qualquer tipo de valor econômico ao cliente.

O XP recomenda que pequenos investimento sejam efetuados de forma gradual e que busque grandes recompensas o mais rapidamente possível. Com a prática de releases curtos, o XP pretende dar o máximo de valor econômico ao cliente em um curto espaço de tempo.

Release é um conjunto de funcionalidade bem definidas e que representam algum valor para o cliente. Um projeto XP pode ter um ou mais releases no seu ciclo de desenvolvimento.
2.3 Equipe XP

Em uma equipe de XP existem papéis a serem desempenhados por um ou mais desenvolvedores. Estes papéis serão listados a seguir.
2.3.1 Gerente de projeto

Pessoa responsável pelos assuntos administrativos do projeto, mantendo um forte relacionamento com o cliente para que o mesmo participe das atividades do desenvolvimento.

O gerente de projeto é responsável por filtrar assuntos não relevantes aos desenvolvedores e aspectos que só devam ser implementados em iterações futuras.

Para um bom exercício de gerente de projeto é necessário que a pessoa conheça e acredite nos valores e práticas do XP para que possa cobrar isto da sua equipe.
2.3.2 Coach

Pessoa responsável pelas questões técnicas do projeto, recomenda-se que esta pessoa seja a com maior conhecimento do processo de desenvolvimento, dos valores e práticas do XP. é de responsabilidade do coach verificar o comportamento da equipe frente o processo XP, sinalizando os eventuais erros cometidos pela equipe.
2.3.3 Analista de teste

Pessoa responsável em garantir a qualidade do sistema através dos testes escritos. Ele deve ajudar o cliente a escrever os casos de testes e no final de cada iteração verificar se o software atende todos os casos de testes.

Recomenda-se que esta pessoa não seja um desenvolvedor, para evitar uma visão tendenciosa já que não conhece o código desenvolvido. O analista de teste deve ter uma visão muito parecida com a do cliente e em muitos projetos esta pessoa acaba exercendo o papel de redator técnico.
2.3.4 Redator técnico

Pessoa responsável em documentar o sistema, evitando um forte trabalho dos desenvolvedores neste tipo de atividade, permitindo uma maior dedicação ao trabalho de codificação.

Esta pessoa deve estar em plena sintonia com os desenvolvedores e cliente para que a documentação reflita o código escrito e as regras de negócio atendidas pelo sistema.
2.3.5 Desenvolvedor

Pessoa responsável em analisar, projetar e codificar o sistema. No XP não existe diferença entre analista, projetista e programador uma vez que em vários momentos do projeto o desenvolvedor estará exercendo alguma destas atividades.

Naturalmente existe níveis distintos de desenvolvedores dentro de uma equipe, mas com as práticas do XP, como pair programming , a tendência é a equipe se tornar uniforme em suas habilidades.
3 Conclusões

A metodologia de desenvolvimento Extreme Programming pode ser considerada extremamente nova, porém vem acompanhando as necessidades humanas dos desenvolvedores pelo mundo.

Gurus da tecnologia da informação vem aprimorando as concepções desta metodologia para atender as necessidades do mercado e principalmente das pessoas.

Um empresa ao utilizar este processo por completo, só estará agregando valor aos seus negócios e melhorando o ambiente de seus colaboradores e clientes, tratando-os como pessoas e parceiros. Está é chave no mundo dos negócios, o bem estar de seus colaboradores e a parceria entre o fornecedor e seus clientes, criando um laço de confiança ou até mesmo um sentimento de amizade.

Entender as necessidades do cliente não é ciência, é arte. Dar incentivo a ela é o mínimo que podemos fazer.
4 Referências

AMBROSI, Cleison Vander; GRAHL, Everaldo Artur. Extreme Programming: Um modelo de processo para o desenvolvimento de software. Blumenau ? SC: Instituto Catarinense de Pós-Graduação.

ASTELS, David; MILLER, Granville; NOVAK, Miroslav. Extreme Programming: Guia prático. Rio de Janeiro ? RJ: Campus, 2002.

BECK, Kent. Programação extrema (XP) explicada: acolha as mudanças. Porto Alegre ? RS: Bookman, 2004.

POHREN, Daniel. XP Manager: Uma Ferramenta de Gerência de Projetos Baseados em Extreme Programming. Novo Hamburgo ? RS: Centro Universitário Feevale, 2004.

TELES, Vinícius Manhães. Extreme Programming: Aprenda como encantar seus usuários desenvolvendo software com agilidade e alta qualidade. São Paulo - SP: Novatec Editora Ltda, 2004.

WUESTEFELD, Klaus. Xispê: Extreme Programming. Disponível em http://www.xispe.com.br/index.html . Acesso em: 23 / 07 / 2004.