TRABALHO 01 - DESENVOLVIMENTO ÁGIL DE SOFTWARE

TEST DRIVEN DEVELOPMENT E PROGRAMAÇÃO EXTREMA

COM10015 – ENGENHARIA DE SOFTWARE

CIÊNCIA DA COMPUTAÇÃO

GRUPO 03: 2012204288 – EGLE L. FERREIRA

2012204283 – MATHEUS C. OLIVEIRA 2012204278 – MAYCOWN D. O. MIRANDA

2012204286 – PALOMA O. NOBRE 2012204277 – UESLEI O. MACHADO

ALEGRE, 1º SEMESTRE, 2014

SUMÁRIO

1. Introdução ......................................................................................................... 3

2. Manifesto Ágil - Proposta .................................................................................. 4

2.1 Características ............................................................................................ 5

3. Test Driven Development (TDD) ...................................................................... 8

4. Programação Extrema (XP) .............................................................................. 9

4.1 Programação Extrema Industrial .............................................................. 11

4.2 Debates .................................................................................................... 12

5. Referências .................................................................................................... 14

3

1. INTRODUÇÃO

A insatisfação com essas abordagens pesadas

levou um número de desenvolvedores de software na década de

1990 a propor novos métodos ágeis. Estes permitiam que a

equipe de desenvolvimento se concentrasse no software

somente, em vez de em seu projeto e documentação.

Geralmente, os métodos ágeis contam com uma abordagem

iterativa para especificação, desenvolvimento e entrega de

software, e foram criados principalmente para apoiar o

desenvolvimento de aplicações de negócios nas quais os

requisitos de sistema mudam rapidamente durante o processo

de desenvolvimento. Eles destinam-se a entregar um software

de trabalho rapidamente aos clientes, que podem então propor

novos requisitos e alterações a serem incluídos nas iterações

posteriores do sistema. (2007, SOMMERVILLE, pág. 262).

Métodos ágeis se desenvolveram em um esforço para sanar fraquezas

reais e perceptíveis da engenharia de software convencional. É uma adaptação da

engenharia de software, que tem como foco o desenvolvimento ágil.

As atividades metodológicas como: comunicação, planejamento,

modelagem, construção e emprego permanecem, porém mínimas.

Segundo o dicionário Michaelis, “ágil” é sinônimo de leve, flexível e, é

antônimo de pesado, moroso.

Leve em relação a pouca documentação e projeto, devido a isso, os

softwares são desenvolvidos em curtos períodos, medidos em semanas, realizando

pequenas iterações. Ao final de cada iteração um novo incremento do software.

Como dito, tem como objetivo minimizar o risco pelo desenvolvimento do

software e priorizar mais a entrega do produto, o software, ao projeto e análise. O que

pode ser considerado algo negativo, pois documentação é algo importante.

Deste modo são adotados por equipes pequenas em que priorizam a

comunicação face a face, além do próprio cliente fazer parte da equipe, sempre

ajudando na validação e gerenciamento dos requisitos (mas o sucesso disso depende

4

de o cliente estar disposto e capaz de despender tempo com a equipe de

desenvolvimento).

Flexível pois um método ágil deve ser adaptável e receptível as mudanças,

o que ajuda na forma de se administrar a imprevisibilidade.

Agilidade x Custo de mudanças: O custo de mudanças muda de forma não

linear à medida que o desenvolvimento avança. Quando é adotado uma metodologia

de desenvolvimento convencional em que são priorizados análise e projeto, mudanças

podem ser muito custosas, pois podem causar efeitos colaterais inesperados. No

método ágil, como já se está habituado a serem realizadas frequentes mudanças, o

custo final será menor.

2. MANIFESTO ÁGIL - PROPOSTA

“Estamos descobrindo maneiras melhores de desenvolver softwares,

fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho,

passamos a valorizar:

◦ Indivíduos e interações mais do que processos e ferramentas.

◦ Software em funcionamento mais do que documentação abrangente.

◦ Colaboração com o cliente mais do que negociação de contratos.

◦ Responder a mudanças mais do que seguir planos.

Ou seja, mesmo havendo itens à direita, valorizamos mais os itens à

esquerda.”

O manifesto possui inúmeros aspectos fascinantes. Ao começarmos a lê-

lo, deparamo-nos logo com a palavra “descobrindo” que poderia passar despercebida,

mas que foi colocada de forma precisa. Mas por que?

Pensado por experientes e reconhecidos desenvolvedores de software, a

palavra “descobrindo” dá ao manifesto a ideia de que os membros não sabem todas

as respostas para o desenvolvimento ágil.

5

Segundo, a frase “fazendo-o nós mesmos”, o que indica que os próprios

membros praticam a utilização dos métodos em seus trabalhos.

Terceiro, os membros da Alliance procuram ajudar, e não somente ditar as

regras. Eles querem ajudar os outros com os métodos ágeis, e melhorar nosso próprio

conhecimento aprendendo a ajuda de todos os desenvolvedores.

Os valores do manifesto possuem um modelo: em cada ponto, o primeiro

item indica uma preferência, enquanto o item seguinte descreve o que é –

consideravelmente importante – de menor prioridade.

A Alliance reconhece o que os processos e ferramentas são importantes,

com um reconhecimento adicional que a interação de indivíduos qualificados são de

maior importância. Similarmente, documentação completa não é necessariamente

ruim, mas o foco primário deve estar no produto final (entregar o software funcionando).

Portanto, todo o time de projeto precisa determinar para si mesmo, qual

documentação é absolutamente essencial.

Contrato de negociação, se pensado em uma licença de projeto interno ou

contrato jurídico externo, não é uma prática ruim, somente insuficiente. Licença de

contratos e projetos podem proporcionar algumas condições no qual as partes podem

trabalhar, mas somente através de colaboração contínua uma equipe de

desenvolvimento pode entender e entregar o que o cliente quer.

Em um mundo turbulento de tecnologia e negócios, seguir um plano à risca

pode resultar em terríveis consequências, mesmo se executado com precisão. Não

importa o quão seguro um projeto é feito, torna-se perigoso se você tem que mudá-lo.

2.1 CARACTERÍSTICAS

Como explicitado anteriormente, reduzir os custos de mudanças ao longo

de todo o processo de software é característica intrínseca dos métodos ágeis.

Como o desenvolvimento deve ser ágil, é difícil e quase impossível definir

ou prever o crescimento futuro do software, e em muitas vezes só é possível coletar

os requisitos após o início do projeto.

6

Como diz Cockburn (2002) “a consciência das ações é uma fraqueza

humana, as metodologias com disciplina elevada são frágeis”. Com isso concluísse

que os modelos de processos devem fornecer um mecanismo que estimule uma

disciplina necessária, nada exagerado.

Pressman (2002, pág. 84) explicita 12 princípios para quem quer ter

agilidade:

1 - A prioridade é satisfazer o cliente com entrega contínua e mais cedo

possível de um software usável. (O software em funcionamento é a principal medida

de progresso).

2 – Acolha bem os pedidos de alterações, mesmo atrasados no

desenvolvimento. (Mudanças de requerimento são sempre bem vindas, mesmo

quando for tarde. E o projeto e construção devem ser inter-conduzidos, ou seja, ser

aplicados em sequência, para que os modelos de projeto sejam aprovados assim que

criados, garantindo a agilidade).

3 – Entregue software em funcionamento frequente, de algumas semanas

para alguns meses, dando preferência a intervalos mais curtos. (Entregar sempre que

possível um versão do software que funcione).

4 – O pessoal comercial e os desenvolvedores devem trabalhar em

conjunto diariamente ao longo de todo projeto. (O cliente tem uma participação maior

no desenvolvimento da aplicação).

5 – Construa projetos em torno de indivíduos motivados. Dê a eles o

ambiente e apoio necessário e confie neles para ter o trabalho feito.

6 – O método mais eficiente e efetivo de transmitir informações para e

dentro de uma equipe é uma conversa aberta, de forma presencial. (Como é

necessário uma rápida comunicação, é importante que a equipe seja pequena).

7 – Software em funcionamento é a principal medida de progresso.

8 – Os processos ágeis promovem desenvolvimento sustentável

7

9 – Atenção contínua para com a excelência técnica e para com bons

projetos aumentar a agilidade.

10 – Simplicidade – a arte de maximizar o volume de trabalho não efetuado

– é essencial. (Deve haver simplicidade para que seja fácil realizar mudanças).

11 – As melhores arquiteturas, requisitos e projetos emergem de equipes

que auto organizam.

12 – A intervalos regulares, a equipe se avalia para ser como torna-se mais

eficiente, então sintoniza e ajusta seu comportamento de acordo.

Já Sommerville (2007, pág. 263), define esses princípios em apenas cinco

pontos:

Envolvimento do cliente Clientes devem ser

profundamente envolvidos no processo de

desenvolvimento. Seu papel é fornecer e

priorizar novos requisitos do sistema e

avaliar as iterações do sistema.

Entrega incremental O software é desenvolvido em

incrementos e o cliente especifica os

requisitos a serem incluídos em cada

incremento.

Pessoas, não processos As habilidades da equipe de

desenvolvimento devem ser reconhecidas

e exploradas. Os membros da equipe

devem desenvolver suas próprias

maneiras de trabalhar sem processos

prescritivos.

Aceite as mudanças Tenham em mente que os

requisitos do sistema vão mudar, por isso

8

(2007, Sommerville, tabela 17.1, pág. 262)

3. TEST DRIVEN DEVELOPMENT (TDD)

A técnica de Desenvolvimento Guiado por Testes (do inglês, Test Driven

Development - TDD), descrito por Beck (2010), consiste em um processo no qual se

desenvolve primeiro os testes, e depois se codifica o mínimo necessário para que seja

possível passar por esses.

Segundo Beck (2010) o TDD visa qualidade e design de código, além de

influenciar diretamente o tempo gasto com o desenvolvimento do projeto, pois tem-se

o encorajamento de um projeto disciplinado, mais objetivo, e com base em melhorar

a qualidade interna do software. Isto com o foco em corrigir os possíveis defeitos, que

seriam detectados por meio da elaboração de testes.

Este método possui diversos benefícios, tais como: melhor entendimento

do negócio do sistema, pois antes de se codificar algo, há a necessidade de entender

bem o problema ou função, e uma solução para tal. Os testes criados são mais

eficientes, pois ao codificar e depois testar cria-se uma tendência inconsciente a

direcionar o foco ao que já foi produzido, o que pode acarretar em mais erros e mais

testes, sendo que o código que deveria passar no teste em questão. Há uma confiança

maior por parte do desenvolvedor segundo (VASCONCELO, et al., 2012), pois o

progresso é feito a pequenos passos, de forma ágil e segura, tendo a garantia que o

software se comporte da forma que se espera.

Quando se usa o TDD, dificilmente ao correção funcionais nos códigos que

foram implementados, pois se executado de forma correta, os possíveis erros já foram

detectados, e solucionados durante a elaboração de testes.

projete o sistema para acomodar essas

mudanças.

Mantenha a simplicidade

Concentre-se na simplicidade

do software que está sendo desenvolvido e

do processo de desenvolvimento. Sempre

que possível, trabalhe ativamente para

eliminar a complexidade do sistema.

9

O processo pode ser descrito pelas seguintes etapas:

Design do projeto funcional;

Criação do teste;

Compilação somente do código que se elaborou o teste;

Execução do teste;

Implementação do método;

Nova execução do teste;

Refatoração.

4. PROGRAMAÇÃO EXTREMA (XP)

Em Programação Extrema (do inglês Extreming Programming) adota-se o

modelo de programação orientada a objetos, como seu modelo de desenvolvimento

preferido, adota um modelo que é por sua vez dividido em quatros subdivisões:

planejamento, projeto, codificações e testes.

A etapa de planejamento como o próprio nome já diz, é uma etapa onde

se planeja o que vai se fazer, logo é a primeira faze da programação extrema, onde

se tem o levantamentos de requisitos junto ao cliente, mas de forma inicial, já que em

programação extrema o levantamento de requisitos é constante em todas etapas, isso

sendo gerenciado a gosto do cliente que por sua vez está presente em todas etapas

do desenvolvimento do software.

Nesta etapa se tem o desenvolvimento de histórias, que são

mecanismos que tem por função descrever as caraterísticas, resultados e a

funcionalidade que o software terá que ter depois de pronto.

As histórias são escritas e colocadas em fichas pelo cliente, ao mesmo

tempo que este atribui um valor a cada história, de forma que estas sejam avaliadas

de acordo com sua importância para o projeto todo, após isto é estimado um período

para produção de cada história, caso o período estimado seja grande pede-se ao

cliente que este subdivida a história, após isto a equipe escolhe a forma que será

desenvolvida a história, se aquelas de maior importância serão implementadas

primeiro ou não.

10

Após se ter a primeira versão do projeto implementada, a equipe calcula

a velocidade do projeto, neste momento é que equipe observa se algum projeto ira

necessitar de um período maior que originalmente, caso isto ocorra, os prazos de

entrega são reformulados, em todo processo o cliente poderá modificar as histórias,

da forma que bem entenda.

O projeto em programação extrema segue a filosofia de sempre ser o

mais simples possível, usa-se muito cartões CRC (classe-responsabilidade-

colaborador) para identificar e orientar as classes orientadas a objetos.

Um ponto importante em programação extrema é que a elaboração do

projeto acontece de forma constante ou seja, tanto antes como durante a produção

do código, de forma que a todo momento o projeto está sendo implementado, na

verdade a codificação guia a equipe no desenvolvimento do projeto.

A codificação não se inicia exatamente após as histórias e o projeto

preliminar estiver pronto, primeiramente se desenvolve um conjunto de testes, para

que depois dos testes terem sido desenvolvidos o desenvolvedor poderá se focar

melhor em no que deve ser implementado para passar nos testes.

Um ponto importante na Programação Extrema é a programação em

duplas, adota-se esta política onde, o código e desenvolvido em duplas, acredita-se

que desta forma se tenha desenvolvimento com menos chances de erro e mais

eficiente, normalmente um dos membros da dupla se concentra na codificação

enquanto, o outro observa e procura possíveis erros.

Conforme a dupla completa o trabalho, este é integrado aos demais

códigos das demais duplas, de forma que não deixe-se a integração por último, para

que assim não ocorra o risco de ter incompatibilidade no final do processo.

Como já foi dito anteriormente a etapa de testes tem seu início anterior

à etapa de codificação, o sistema dinâmico que a programação extrema adota permite

que os testes de integração e validação do sistema podem ocorrer diariamente ou seja

o desenvolvimento do software está em constante teste, isto é um vantagem já que

segundo Wells [Wel99] que afirma que corrigir pequenos problemas em intervalos de

11

poucas horas é muito mais fácil que corrigir grandes problemas próximo ao prazo de

entrega do produto.

Os testes de aceitação são uma modalidade de testes que é

desenvolvida pelos clientes, estes testes tem por objetivo manter o foco do software,

sobre o aspectos que são visíveis ao usuário, já que o objetivo do software é atender

as necessidades do cliente e este muita das vezes não sabe expressar com exatidão

o que quer, sendo assim só testando para ver se o produto atende suas necessidades.

4.1 PROGRAMAÇÃO EXTREMA INDUSTRIAL

A programação extrema industrial é uma variante da programação

extrema tradicional que difere da primeira, pois por sua vez esta emprega métodos

para adotar um maior gerenciamento, por ter um papel mais expandido para clientes

e por ter algumas técnicas mais atualizadas, a programação extrema industrial adota

seis novas práticas que possibilitam que a programação extrema possa ser

implementada em projetos de maior escala em grandes empresas.

Avaliação imediata, esta pratica tem por sua vez o objetivo de verificar

se existe um ambiente propicio ao desenvolvimento de uma programação extrema

industrial, fazer com que a equipe seja composta por um grupo de interessados

apropriados, a organização tenha um programa de qualidade diferenciado, a cultura

organizacional apoie os novos valores de uma equipe ágil e que a comunidade do

projeto, ampliada seja composta de forma correta.

Em programação extrema objetiva-se procurar as pessoas certas para

desenvolver a equipe que desenvolvera o projeto, ou seja pessoas, dispostas,

corajosas, bem treinadas, adaptáveis, e experientes em programação extrema

industrial, por sua vez o conceito de equipe é substituído pelo de comunidade, já que

esta é maior, sendo assim a comunidade funcionara como a equipe, porem a

comunidade por sua vez, será muito mais abrangente em numero e diversidade de

seus membros, como por exemplo tendo a participação de representantes da área

de produção ou categoria de vendas, normalmente estes ficam na periferia do projeto,

mas podem a qualquer momento assumirem posições mais ativas, dentro deste, na

12

programação extrema industrial os membros da comunidade e os mecanismos de

comunicação e coordenação devem estar determinados.

A equipe por meio do mapeamento do projeto determina se este é

justificável além de determinar dentro do contexto como o projeto complementa,

amplia ou substitui projetos ou sistemas já existentes.

Um projeto de programação extrema industrial requer critérios que

possam ser mensuráveis para que possa assim ser medido o progresso do projeto

obtido até então, o gerenciamento orientado a testes determina um mecanismo para

se fazer este gerenciamento.

Em programação extrema industrial há o método de retrospectivas que

faz uma revisão dos itens, eventos e lições aprendidas ao longo do processo de

incremento de software, com objetivo de aprimorar a programação estrema industrial.

Há também um processo de aprendizagem continua, onde objetiva-se

que os membros da equipe tenha um processo de aperfeiçoamento continuo, sendo

incentivados a sempre aprenderem formas, técnicas e métodos que assim possam

produzir um produto sempre com uma qualidade superior ao anterior.

Em suma a programação extrema industrial modifica diversas partes na

programação extrema tradicional, o emparelhamento aumenta o conceito de

programação em duplas, adicionando gerentes e outras partes que na forma

tradicional, ficavam mais na periferia do processo, a programação extrema industrial

modifica os processos para que estes fiquem mais compatíveis com projetos de

abrangência maior.

4.2 DEBATES

Computação é uma área altamente dinâmica, devido a isto todos novos

modelos de processos estimulam a debates interessantes ou debates acalorados, em

programação extrema presenciamos os dois. Stephens e Rosenberg argumentam que

muitas práticas de programação extrema são eficientes, mas já outras foram

subestimadas e outras podem ser problemáticas, os autores dizem que o fato de os

pontos da programação extrema serem codependentes faz com que esta caraterística

seja seu ponto forte em alguns casos e sua fraqueza em outros, já que muitas

13

empresas adotam somente alguns pontos da programação extrema, acaba

enfraquecendo o processo como um todo, já que alguns processos dos quais são

dependentes não são adotados pela empresa, os defensores da programação

extrema dizem que os pontos em que são criticados vão ser sanados gradativamente

ao longo do período que programação extrema ganha maturidade e que alguns pontos

já foram até corrigidos, devido a caraterística de constante mutação que a

programação extrema possui.

Nos pontos que mais são discutidos pelos críticos da extrema

programação tem-se a volatilidade dos requisitos, os críticos argumentam que devido

ao fato de que o cliente se torne um membro ativo da equipe, os requisitos mudam

com muita facilidade, e isto obviamente torna o trabalho, mais dificultoso, os

defensores argumentam que há métodos para evitar mudanças demasiadas nos

requisitos.

Outro problema é o surgimento de necessidades conflitantes de clientes

já que em programação extrema trabalha-se muitas vezes com projetos com muitos

clientes, estes com requisitos diferentes, que eventualmente podem entrar em conflito,

cabe a equipe gerenciar este problema, mas muitas vezes isto está acima de seu

poder.

Ha também o problema de que os requisitos são levantados de forma

informalmente os críticos desta pratica argumentam que necessita-se de um modelo

mais formal, para que assegurar que erros sejam encontrados antes que o sistema

seja construídos, os defensores afirmam que a natureza mutável da programação

extrema faria com que tais modelos ficariam obsoletos.

Por último a ausência de projeto formal em programação extrema faz

com que os críticos argumentem que em sistemas complexos seja necessário

elaboração de um projeto de forma formal para que se assegure que a estrutura geral

do software apresente qualidade e facilidade de manutenção, os defensores da

programação extrema afirmam que a natureza incremental do processo faz com que

ele se mantenha simples, tornando desnecessário a confecção de um projeto mais

elaborado.

14

Deve se deixar claro que todos diferentes processos de software tem

suas falhas, e determinadas situações que são mais adequados, de forma que cabe

a equipe avaliar em qual situação o processo melhor se adapta e quando se deve

modifica-lo para se adaptar melhor ao seu fim.

5. REFERÊNCIAS

COCKBURN, A. Agile Software Development, Addison – Wesley, 2002

BECK, K. TDD Desenvolvimento Guiado por Testes, Bookman, São Paulo, 2010.

EVANS, E. Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison Wesley, Greenvile, 2003.

FOWLER, M., et al. Refactoring: Improving the Design of Existing Code, Addison – Wesley, Greenvile, 2000.

PRESSMAN, R. S. Engenharia de Software, McGrawHill, 6ª ed., São Paulo, 2006.

SOMMERVILLE, I. Engenharia de Software, Pearson Education, 8ª ed., São Paulo, 2007.

VASCONCELO, J, L., et al. Um Estudo de Caso sobre o Aumento de Qualidade de

Software em Projetos de Sistemas de Informação que Utilizam Test Driven Development, SBSI, São Paulo, 2012.

WELLS, D. “XPfUnit Test", disponível em: wwwextremeprogramming.org/ rules/ unittests.html, 1999.