U2-Processo de Software-Paradigmas de Software-Extreme Programming

EAD
Paradigmas
de Desenvolvimento
de Software
1. OBJETIVOS
C
ompreender o que um processo de software.
Entender a importncia do processo para o sucesso do
produto desenvolvido.
Conhecer e aplicar os principais paradigmas de desenvolvimento de software.
2. CONTEDOS
P
rocesso de software.
Paradigmas de software.
Extreme Programming.
3. ORIENTAES PARA O ESTUDO DA UNIDADE

No incio e durante o desenvolvimento das unidades, importante que voc fique sempre atento s informaes contidas
54
Engenharia de Software
neste Material Didtico. Programe, organize seus estudos e participe, ativamente, na Sala de Aula Virtual (SAV). Ter disciplina para
estudar pode ajudar voc a tirar o mximo de proveito em seu
curso na modalidade EaD.
Durante esta unidade voc conhecer os principais modelos
de processo de software. Porm, so muitos os modelos propostos pela Engenharia de Software. Portanto, no limite seu aprendizado apenas aos modelos aqui apresentados, estude, pesquise,
busque novos conhecimentos!
Adquira o hbito da pesquisa, visite sites, pesquise em livros
e peridicos. Sugiro que voc d pequenas pausas na leitura e pesquise sobre os conceitos abordados nas unidades. E lembre-se de
compartilhar suas descobertas com seus colegas de turma.
4. INTRODUO UNIDADE
Na Unidade 1, voc estudou os componentes do sistema computacional. Verificou a importncia do software para o bom funcionamento do sistema e as caractersticas do produto de software.
Conheceu, tambm, as dificuldades envolvidas na produo
de software, o contexto histrico e os mitos que envolvem a indstria do software. Por meio desses conceitos, voc pde compreender o que a Engenharia de Software.
Nesta unidade, voc compreender o que um processo de
software e a importncia desse conceito na Engenharia de Software.
Alm disso, voc conhecer alguns dos paradigmas para o
desenvolvimento de software.
5. PROCESSO DE SOFTWARE
De acordo com Pressman (2006), resolver os problemas levantados at o momento, assim como compreender a existncia
U2 Paradigmas de Desenvolvimento de Software
55
dos mitos, possvel; mas, antes de tudo, preciso ter cincia de

que no existe uma abordagem mgica que seja a melhor soluo.
necessrio que haja uma combinao de mtodos que sejam abrangentes a todas as etapas do desenvolvimento de um software.
Alm disso, importante e desejvel que os mtodos sejam
suportados por um conjunto de ferramentas que permitam automatizar o desenrolar das etapas, juntamente com uma definio
clara de critrios de qualidade e produtividade de software. So
esses os aspectos que mais influenciam a disciplina de Engenharia
de Softwares.
Como j foi dito anteriormente, ao pensarmos sobre a questo: "o que engenharia de software?", podemos dizer que ela
rene metodologias, mtodos e ferramentas a serem utilizados,
desde a percepo do problema at o momento em que o sistema desenvolvido deixa de existir, visando resolver problemas inerentes ao processo de desenvolvimento e ao produto de software
(PFLEEGER, 2004).
A Engenharia de Software auxilia no processo de desenvolvimento de sistemas de forma a produzi-los com:
maior qualidade;
maior rapidez;
menor custo.
Na Engenharia de Software, h dois termos dependentes,
bastante usados, mas que podem ser definidos distintamente:
produto de software e processo de software. Voc j aprendeu
o que um produto de software na Unidade 1. Vamos aprender,
agora, o que um processo de software. Para que voc compreenda os processos de desenvolvimento de software, importante,
antes, contextualizarmos o que um processo.
Antes de continuarmos, pare um pouco e tente definir o
que processo de software, reflita sobre essa palavra. O que voc
entende por processo?
Claretiano - Centro Universitrio
56
Paula Filho (2001) define processo como:

uma receita que seguida por um projeto, o qual concretiza uma abstrao, que o processo;
um conjunto de passos parcialmente ordenados, constitudos por atividades, mtodos, prticas e transformaes,
usado para atingir uma meta.
Alm disso, no se deve confundir o processo com o produto, ou com a execuo do processo por meio de um projeto.
Ainda segundo o autor citado, um processo definido aquele que possui documentao que descreve:
a) o que feito (produto);
b) quando (passos);
c) por quem (agentes);
d) as coisas que usa (insumos);
e) as coisas que produz (resultados).
Pressman (2006) define processo de software como um arcabouo (estrutura) para as tarefas que so necessrias para construir softwares de alta qualidade. Assim, um processo de software
define a abordagem que adotada quando o software desenvolvido. O processo o alicerce da Engenharia de Software e permite
o desenvolvimento racional e oportuno de softwares de computador. Dessa forma, os processos de software formam a base para o
controle gerencial de projetos de software e estabelecem o contexto no qual os mtodos so aplicados.
Devido s inmeras variveis que envolvem o desenvolvimento
de software, no h um mtodo em particular que seja o melhor
para a soluo dos problemas de construo de software. No
entanto, combinando os mtodos e ferramentas, os engenheiros de
software conseguem adaptar um processo de software apropriado
aos produtos que constroem e s diferentes caractersticas dos
ambientes de construo. A definio de um processo envolve a
escolha dos mtodos, ferramentas e procedimentos para projetar,
57
construir e manter grandes sistemas de software de forma

profissional.
Para Sommerville (2005), no h um processo ideal, h muitas oportunidades de trabalho para melhor-los, em muitas organizaes.
O Processo de desenvolvimento corresponde ao conjunto e
ao ordenamento de atividades de forma que o produto desejado
seja obtido (SOMMERVILLE, 1994).
O resultado do esforo de um processo de desenvolvimento
de software, ou simplesmente processo de software, um produto de software. Se o processo de software for ruim, certamente o
produto de software sofrer, inevitavelmente, as consequncias.
H, hoje, vrios modelos de processo de software, tambm,
chamados de Paradigmas da Engenharia de Software, e cada um
representa uma tentativa de colocar ordem em uma atividade inerentemente catica (PRESSMAN, 1996). Voc ver este assunto no
prximo tpico. Acompanhe!
6. PARADIGMAS DA ENGENHARIA DE SOFTWARE

Modelo de desenvolvimento, modelo de processo, paradigma ou ciclo de vida so termos utilizados como sinnimos. Portanto, paradigma uma representao abstrata do processo de
desenvolvimento que, em geral, definir como as etapas relativas
criao do software sero conduzidas e inter-relacionadas para
atingir o objetivo, que a obteno de um produto de software de
alta qualidade a um custo relativamente baixo.
A Engenharia de Software surgiu para minimizar os feitos da
crise do software e props modelos prescritivos de processo, criados, originalmente, para colocar ordem no caos do desenvolvimento de software. A organizao que desenvolve software sem um
processo definido desenvolve de forma catica. Em um ambiente
catico, indisciplinado, a qualidade do produto imprevisvel.
58
Os modelos prescritivos no so perfeitos, mas fornecem um

roteiro til para o trabalho da Engenharia de Software. So prescritivos porque prescrevem um conjunto de elementos de processo atividades, aes, tarefas, produtos de trabalho, mecanismos
de garantia de qualidade e de controle de modificaes para cada
projeto. Esses modelos tambm descrevem um fluxo de trabalho,
ou seja, a forma como cada elemento do processo deve ser interligado aos outros (PAULA FILHO, 2001).
Genericamente, segundo Pressman (1996), os processos de
desenvolvimento de software possuem trs fases: definio, desenvolvimento e manuteno.
Definio: foco no "o qu", isto , nesta fase, o desenvolvedor tenta identificar quais informaes devem ser processadas, quais as funes e os desempenhos desejados,
quais interfaces devem ser estabelecidas, quais as restries e os critrios de validao para definir um sistema
com qualidade.
Desenvolvimento: foco no "como", ou seja, o desenvolvedor deve definir como a estrutura de dados e a arquitetura do software devem ser projetadas e construdas. Nesta
fase, o software deve ser construdo e testado.
Manuteno: o desenvolvedor concentra-se nas mudanas associadas correo de erros, adaptaes e ampliaes a serem feitas no software.
Voc encontrar detalhes sobre essas trs fases na Leitura
Complementar 1. Estas so as atividades bsicas em qualquer paradigma de desenvolvimento de software. Em qualquer modelo
de processo, certamente voc ter que descobrir as necessidades
do cliente. Uma vez descobertas estas necessidades, voc ter que
materializ-las atravs da construo do software. Depois de construdo e entregue inevitavelmente este software ser modificado.
Independentemente do paradigma (modelo) escolhido, de
forma explcita ou implcita, com mais ou menos detalhes, certa-
59
mente estas fases ocorrero durante o processo de desenvolvimento de software.

Vrios so os modelos de desenvolvimento existentes na literatura:
1) Sequencial linear:
Modelo cascata ou Ciclo de vida clssico.
Prototipao.
Modelo RAD (Rapid Application Development).
2) Modelos evolutivos de processo de software:
Modelo incremental.
Modelo espiral.
Modelo de montagem de componentes.
Modelo de desenvolvimento concorrente.
3) Modelos de mtodos formais.
4) Tcnicas de quarta gerao.
Como j mencionado, so vrios os modelos propostos pela
Engenharia de Software. Por questo de tempo, veremos neste
Caderno de Referncia de Contedo somente os modelos mais conhecidos. No entanto, no limite seu aprendizado a estes, pesquise sobre outros modelos existentes.
A seguir, sero descritos alguns dos modelos conhecidos e
utilizados em desenvolvimento de software.
Modelo cascata ou ciclo de vida clssico
Caractersticas do modelo:
O modelo cascata ou ciclo de vida clssico o mais simples
de desenvolvimento de software, estabelecendo uma ordenao
linear referente realizao das diferentes etapas.
Esse modelo, que o mais antigo e amplamente utilizado
pela engenharia de software por ter sido modelado em virtude do
ciclo da engenharia convencional.
60
Requer uma abordagem sistemtica, sequencial ao desenvolvimento de software, e o resultado de uma fase constitui-se na
entrada da outra.
H inmeras variaes desse modelo, dependendo da natureza das atividades e do fluxo e do controle entre elas. Os estgios
principais do modelo esto relacionados s atividades fundamentais de desenvolvimento.
Acompanhe, na Figura 1, a descrio grfica desse modelo,
cuja estrutura lembra a queda dgua, derivando da o seu nome.
Pressman (1996) descreve cada uma destas etapas:
1) Engenharia de Sistemas: estabelecem-se os requisitos
gerais de todos os elementos do sistema computacional
(software, hardware, pessoal, banco de dados, documentaes e procedimentos).
2) Anlise de requisitos: so levantados os requisitos especficos do software, de forma mais detalhada.
3) Projeto: so projetados a estrutura dos dados, a arquitetura
do software, os detalhes procedimentais e de interface.
4) Codificao: concretiza-se o projeto, sendo criado o software utilizando uma linguagem de programao.
5) Testes: uma vez gerado o cdigo, este deve ser testado
no que diz respeito a aspectos internos e externos.
6) Manuteno: refere-se s mudanas (correes, adaptaes e expanses) que o software sofrer depois de ser
entregue ao cliente.
Engenharia
Anlise
Projeto
Codificao
Teste
Manuteno
Fonte: Adaptado de Pressman (1996, p.33)
Figura 1 Modelo em Cascata.
61
Observe que o modelo Cascata apresenta caractersticas interessantes, particularmente em razo da definio de um ordenamento linear das etapas de desenvolvimento.
Inicialmente, como forma de identificar precisamente o fim
de uma etapa e o incio da seguinte, um mecanismo de certificao
(ou reviso) implementado ao final de cada etapa; isso realizado,
normalmente, por meio da aplicao de algum mtodo de validao
ou verificao, cujo objetivo ser garantir que a sada de uma dada
etapa coerente com sua entrada (a qual j a sada da etapa precedente). E, ao final de cada etapa realizada, deve existir um resultado (ou sada) que possa ser submetido atividade de certificao.
De acordo com Pressman (2006), duas diretivas que norteiam o desenvolvimento, segundo o modelo Cascata, so:
1) Todas as etapas definidas no modelo devem ser realizadas, isso porque, em projetos de grande complexidade,
a realizao formal das etapas determinar o sucesso ou
no do desenvolvimento.
2) Respeitar rigorosamente a ordenao das etapas na forma como foi apresentada.
A realizao informal e implcita de algumas dessas etapas poderia ser realizada apenas no caso de projetos de pequeno porte.
Vale ressaltar, tambm, que os resultados de um processo

de desenvolvimento de software no devem ser exclusivamente o
programa executvel e a documentao associada.
Cada fase demonstrada na Figura 1 pode nos gerar resultados que daro origem documentao do software. Em cada fase,
documentos especficos so gerados e so denominados como:
documento de especificao de requisitos, projeto do sistema,
plano de teste e relatrio de testes, cdigo final, manuais de utilizao, relatrios de revises etc.
Apesar de ser mais popular, podem-se apontar algumas limitaes apresentadas pelo modelo Cascata:
62
p
rojetos reais raramente seguem o fluxo sequencial que o
modelo prope;
h dificuldade em estabelecer explicitamente todos os
requisitos logo no incio, pois, no comeo dos projetos,
sempre h uma incerteza natural;
pacincia do cliente, porque uma verso executvel do
software s ser disponvel em uma etapa avanada do
desenvolvimento.
Esse modelo apresenta algumas contribuies, tais como:
O processo de desenvolvimento de software deve ser sujeito disciplina, planejamento e gerenciamento.
A implementao do produto deve ser prorrogada at que
os objetivos tenham sido completamente entendidos.
Foi apresentado aqui apenas um resumo do Modelo em
Cascata. Este modelo serviu de base para a construo de muitos
outros modelos que surgiram na tentativa de eliminar as desvantagens do Ciclo de Vida Clssico. Para ampliar seus conhecimentos
sobre o modelo, que a base da Engenharia de Software, pesquise
em livros de Engenharia de Software ou na internet. Depois de
pesquisar, reflita se voc considera o Modelo em Cascata muito
burocrtico para o desenvolvimento de software?
Modelo de prototipao
Prototipao um modelo de processo de desenvolvimento
que busca contornar algumas das limitaes existentes no modelo
cascata. Isso realizado por meio da obteno de um prottipo,
com base no conhecimento dos requisitos iniciais para o sistema.
O desenvolvimento desse prottipo realizado obedecendo
a diferentes etapas mencionadas anteriormente, tais como: a anlise de requisitos, o projeto, a codificao e os testes. Essas etapas
no so realizadas necessariamente de modo explcito ou formal.
A prototipao tem como objetivo entender os requisitos do
usurio e, assim, obter uma melhor definio dos requisitos do sistema, possibilitando que o desenvolvedor crie um modelo (prottipo) do software que ser construdo. apropriado para quando
63
o cliente definiu um conjunto de objetivos gerais para o software,

mas no identificou detalhadamente esses requisitos.
Aps criar o prottipo, ser colocado disposio do cliente,
pois este auxiliar na melhor compreenso do que ser o sistema
desenvolvido. Alm disso, por meio da manipulao desse prottipo, possvel validar ou reformular os requisitos para as etapas
seguintes do sistema.
Segundo Pressman (2006), esse modelo, conforme ilustrado na
Figura 4, apresenta algumas caractersticas interessantes, tais como:
facilita o desenvolvimento para sistemas de grande porte,
os quais representem certo grau de dificuldade para exprimir rigorosamente os requisitos;
ao construir um prottipo do sistema, possvel demonstrar sua possibilidade de desenvolvimento;
possvel obter uma verso, mesmo simplificada, do que
ser o sistema, com um pequeno investimento inicial.
Fonte: Pressman (1996, p.36).
Figura 2 Modelo de Prototipao.
64
Esse modelo apresenta alguns problemas, tais como:

1) O cliente no sabe que o software que ele v no considerou, durante o desenvolvimento, a qualidade global e
a manutenibilidade a longo prazo.
2) O desenvolvedor, frequentemente, faz uma implementao comprometida (utilizando o que est disponvel)
com o objetivo de produzir rapidamente um prottipo.
3) Os prottipos no so sistemas completos e deixam a
desejar em alguns aspectos, como, por exemplo, na interface com o usurio.
4) Os esforos de desenvolvimento so concentrados, especialmente, nos algoritmos que implementam as principais funes associadas aos requisitos apresentados,
a interface pertence a esse nvel, o qual considerado
parte suprflua do desenvolvimento, o que permite caracterizar essa etapa por um custo relativamente baixo.
A prototipao apresenta algumas contribuies. Observe, a
seguir, a descrio de cada uma.
1) a prototipao um ciclo de vida eficiente, mesmo que
ocorra problemas;
2) as regras do jogo devem ser definidas logo no incio, o
que fundamental para que o sistema seja satisfatrio;
3) o cliente e o desenvolvedor devem concordar que a funo principal do prottipo permitir que ele seja um
mecanismo favorvel definio dos requisitos;
4) a experincia adquirida no desenvolvimento do prottipo ser de extrema utilidade nas etapas posteriores do
desenvolvimento do sistema real, permitindo reduzir o
seu custo, resultando, tambm, em um sistema melhor
concebido.
Modelo incremental
O modelo incremental tambm foi concebido baseado nas
limitaes do modelo cascata e combina as vantagens deste modelo com as do modelo prototipao.
65
A ideia principal deste modelo, conforme ilustrado na Figura

5, a de que um sistema deve ser desenvolvido de forma incremental; dessa forma, cada incremento adiciona ao sistema novas
capacidades funcionais, at a obteno do sistema final. A cada
passo realizado, modificaes podem ser introduzidas.
Uma das vantagens dessa abordagem a facilidade em testar o sistema durante cada fase de desenvolvimento.
A criao de uma lista de controle de projeto um aspecto importante desse modelo. Essa lista dever apresentar todos
os passos a serem realizados para a obteno do sistema final e
servir, tambm, para se medir, em um dado nvel, a distncia da
ltima iterao.
A lista de controle de projeto gerencia todo o desenvolvimento, definindo quais tarefas sero realizadas a cada iterao. As
tarefas na lista podem representar, ainda, redefinies de componentes implementados anteriormente, em razo de erros ou problemas detectados em uma eventual etapa de anlise.
Funcionalidade
Incremento n
Incremento 2
Incremento 1
Tempo
Com unicao
Planejam ento
Modelagem (Anlise e projeto)
Construo (cdigo, teste)
Im plantao (entrega, feedback)
Fonte: Adaptada de Pressman (2006, p. 40).
Figura 3 Modelo de desenvolvimento incremental.

66
fundamental considerar alguns aspectos desse modelo.

1) A verso inicial , frequentemente, o ncleo do produto
(a parte mais importante).
o desenvolvimento comea com as partes do produto
mais bem entendidas.
a evoluo acontece quando novas caractersticas so
adicionadas conforme a sugesto do usurio.
2) O desenvolvimento incremental importante quando
difcil, ou mesmo impossvel, estabelecer a priori uma
especificao detalhada dos requisitos.
3) As primeiras verses podem ser implementadas com
poucas pessoas; se o ncleo do produto for bem recebido, novas pessoas participam do desenvolvimento da
nova verso.
4) As novas verses podem ser planejadas de modo que os
riscos tcnicos possam ser administrados.
Exemplo:
O
sistema pode exigir a disponibilidade de um hardware
que est em desenvolvimento e cuja data de liberao
incerta.
possvel planejar pequenas verses de modo a evitar a
utilizao desse hardware.
O
software com funcionalidade parcial pode ser liberado
para o cliente.
Modelo espiral
O modelo espiral foi proposto em 1988 e sugere uma organizao de desenvolvimento em espiral (por isso tem esse nome).
Esse modelo acopla a natureza iterativa da prototipao
com os aspectos controlados e sistemticos do modelo cascata.
O modelo espiral dividido em uma srie de atividades de
trabalho ou regies de tarefa.
67
H, tipicamente, de trs a seis regies de tarefa, observe

que, na Figura 4, encontra-se um exemplo de quatro regies definidas pelos quadrantes.
Cada ciclo na espiral inicia-se com a identificao dos objetivos e as diferentes alternativas para se atingir aqueles objetivos,
assim como as restries impostas.
O prximo passo no ciclo a avaliao das diferentes alternativas baseadas nos objetivos fixados, o que permitir, tambm,
definir incertezas e riscos de cada alternativa. No passo seguinte, o
desenvolvimento de estratgias ir resolver ou eliminar as incertezas levantadas anteriormente, o que pode envolver atividades de
prototipao, simulao, avaliao de desempenho etc.
Finalmente, o software desenvolvido e o planejamento dos
prximos passos realizado.
A continuidade do processo de desenvolvimento definida
por causa dos riscos remanescentes, como, por exemplo, decidir
se os riscos relacionados ao desempenho ou interface so mais
importantes do que aqueles relacionados ao desenvolvimento do
programa. Fundamentado nas decises tomadas, o prximo passo
pode ser o desenvolvimento de um novo prottipo que elimine os
riscos considerados.
Por outro lado, caso os riscos de desenvolvimento de programa sejam considerados os mais importantes e se o prottipo
obtido no passo corrente resolve boa parte dos riscos relacionados
ao desempenho e interface, ento o prximo passo pode ser,
simplesmente, a evoluo segundo o modelo cascata.
Como possvel observar, o elemento que conduz esse processo , essencialmente, a considerao sobre os riscos, o que permite, de certo modo, a adequao a qualquer poltica de desenvolvimento (baseada em especificao, em simulao, em prottipo
etc.).
68
Fonte: Adaptado de Pressman (1996, p. 39)
Figura 4 Modelo espiral.
Observaes relacionadas ao modelo espiral:

1) cada "loop" no espiral representa uma fase do processo
de software;
2) o "loop" mais interno est concentrado nas possibilidades do sistema;
3) o prximo "loop" est concentrado na definio dos requisitos do sistema;
4) o "loop" um pouco mais externo est concentrado no
projeto do sistema;
5) a anlise de risco engloba as melhores caractersticas do
ciclo de vida clssico e da prototipao, adicionando um
novo elemento;
6) a abordagem de passos sistemticos do ciclo de vida
clssico incorpora-os em uma estrutura iterativa que reflete mais realisticamente o mundo real;
7) a prototipao utilizada em qualquer etapa da evoluo do produto, como mecanismo de reduo de riscos;
69
8) a abordagem mais realstica para o desenvolvimento de

software em grande escala na atualidade;
9) utiliza uma abordagem que capacita o desenvolvedor e
o cliente a entender e a reagir aos riscos em cada etapa
evolutiva;
10) dificuldade em convencer os clientes que uma abordagem "evolutiva" controlvel;
11) exige considervel experincia na determinao de riscos e depende dessa experincia para obter sucesso;
12) o modelo relativamente novo e no tem sido amplamente utilizado;
13) a eficcia desse modelo poder demorar muitos anos,
at que possa ser determinada com certeza absoluta.
Uma caracterstica importante desse modelo o fato de que
cada ciclo encerrado por uma atividade de reviso, na qual todos
os produtos do ciclo so avaliados, incluindo o plano para o prximo passo (ou ciclo).
Esse modelo apropriado, especialmente, a sistemas que
representem um alto risco de investimento para o cliente.
Modelo Codifica-remenda
O que, normalmente, causa o fracasso dos projetos de software,
evidenciando, ainda, a existncia da chamada Crise do Software a ausncia de disciplina no desenvolvimento de software.
Paula Filho (2001) descreve a ausncia de disciplina como o
paradigma "Codifica-Remenda", isto , partindo apenas de uma especificao (ou nem isso), os desenvolvedores comeam, imediatamente, a codificao, "remendando" medida que os erros vo
sendo descobertos. Enfim, nenhum processo definido seguido.
O codifica-remenda tambm conhecido por Modelo Balbrdia, por razes bvias...
Infelizmente, talvez este seja o paradigma mais usado, por
ser considerado o mais fcil e no exigir nenhuma sofisticao tcClaretiano - Centro Universitrio
70
nica ou gerencial. , porm, um modelo de alto risco, difcil de ser

gerenciado e que no permite assumir compromissos confiveis.
Como j foi dito, no h um consenso sobre um modelo ideal,
os modelos devem ser escolhidos e adaptados a cada necessidade.
O nico consenso que existe que necessrio que a empresa que
desenvolve software siga um mtodo, seja qual for, pois desenvolver
software sem uma metodologia no mais aceitvel na atual conjuntura da indstria de software. Nossos clientes, como os de qualquer
indstria, querem produtos com qualidade. E a qualidade do produto
s alcanada por meio de um bom processo de desenvolvimento.
Recentemente, surgiram as metodologias consideradas geis
para o desenvolvimento de software. Essa metodologia proporciona a satisfao do cliente e a entrega incremental do software logo
de incio. Essa metodologia prope equipes pequenas, altamente
motivadas; mtodos informais; produtos de trabalhos mnimos e
simplicidade no desenvolvimento. Pesquise na internet sobre as
metodologias geis de desenvolvimento e conhea essa novssima filosofia de desenvolvimento de software.
7. EXTREME PROGRAMMING
medida que as caractersticas dos softwares, dos desenvolvedores e dos clientes mudam, a Engenharia de Software procura
adaptar seus modelos nova realidade. A metodologia Extreme Programming, tambm conhecida como XP, ou Programao Extrema,
proposta por Kent Beck em 1998 (TELES, 2004), um dos mais novos
mtodos da Engenharia de Software e um exemplo de metodologia gil para desenvolvimento de software. Por ser um modelo novo
e bastante aceito, vejamos a seguir alguns de seus detalhes.
O XP um processo de desenvolvimento que busca assegurar que
o cliente receba o mximo de valor de cada dia de trabalho da equipe de desenvolvimento. Ele organizado em torno de conjunto de
valores e prticas que atuam de forma harmnica e coesa para asseguras que o cliente sempre receba um alto retorno do investimento em software (TELES, 2004, p. 21).
71
O ciclo de vida do XP tem quatro atividades bsicas: codificar,

testar, escutar e modelar, demonstradas atravs de quatro valores:
a comunicao, a simplicidade, o feedback e a coragem.
A prtica do XP tem comunicao contnua entre o cliente e
a equipe, com o objetivo de criar o melhor relacionamento entre
o cliente e desenvolvedor, dando preferncia s conversas pessoais do que atravs de outros meios. incentivada tambm a comunicao intensa entre desenvolvedores e gerente do projeto. A
comunicao entre o cliente e a equipe permite que todos os detalhes do projeto sejam tratados com a ateno e a agilidade que
merecem, ou seja, codificar uma funcionalidade preocupando-se
apenas com os problemas de hoje e deixar os problemas do futuro
para o futuro.
A simplicidade foca sempre no mais simples que possa funcionar, visando minimizar o cdigo, desprezando funes consideradas necessrias. O importante ter em mente que os requisitos
so mutveis. Sendo assim, o interessante no XP implementar
apenas que estritamente necessrio.
O contato incessante com o cliente a respeito do projeto o
que se pode chamar de feedback constante. As informaes sobre
o cdigo so dadas por teste peridico, os quais indicam erros tanto individuais quanto do software integrado. O cliente ter sempre
uma parte do software funcional para avaliar.
A grande maioria dos princpios do XP so prticas de senso
comum e que fazem parte de qualquer processo disciplinado. Por
exemplo, simplicidade significa foco nas partes do sistema que so
de alta prioridade e somente depois pensado em solues para
problemas que, at ento, no so relevantes (e talvez nunca sejam devido s grandes modificaes no sistema), pois o cliente
aprende com o sistema que utiliza e re-avalia as suas necessidades, gerando o feedback para a equipe de desenvolvimento.
As equipes XP acreditam que errar natural e quebrar o que
vinha funcionando acontece cedo ou tarde. necessrio ter coraClaretiano - Centro Universitrio
72
gem para lidar com este risco, o que em XP se traduz em confiana

nos seus mecanismos de proteo. A coragem encaixa-se na implantao dos trs valores anteriores. So necessrios profissionais
comunicativos e com facilidade de se relacionar. A coragem auxilia
a simplicidade, quando a possibilidade de simplificar o software
detectada. Desse modo, a coragem necessria para garantir que
o feedback do cliente ocorra com frequncia, pois esta abordagem
implica na possibilidade de mudanas constantes do produto.
Enfim, o sistema desenvolvido de forma incremental, a
equipe est continuamente fazendo a manuteno do software e
criando novas funcionalidades, por isso a equipe precisa ser corajosa e acreditar que, utilizando as prticas e valores do XP, ser
capaz de fazer o software evoluir com segurana e agilidade.
Segundo Teles (2004), a metodologia XP apresenta 13 prticas bsicas, que so relacionadas entre si:
1) Cliente presente.
2) Jogo de planejamento.
3) Stand up meeting.
4) Programao em par.
5) Refactoring.
6) Desenvolvimento guiado pelos testes.
7) Cdigo Coletivo.
8) Padres de codificao.
9) Design Simples.
10) Metfora.
11) Ritmo Sustentvel.
12) Integrao Contnua.
13) Releases Curtos.
Cliente presente
O XP trabalha com uma viso diferente dos outros modelos,
preferindo que o cliente esteja presente no dia a dia do projeto.
A participao do cliente contribui para o sucesso do projeto, enquanto a ausncia um srio fator de risco. Sua participao via-
73
biliza a simplicidade do processo. Alm disso, permite-se que o

projeto seja conduzido atravs de uma srie de pequenos ajustes,
e no atravs de mudanas bruscas ao longo do caminho.
Obviamente que o cliente no pode dedicar-se exclusivamente equipe de desenvolvimento, esta no a proposta da prtica.
A ideia que o cliente, e outras pessoas importantes no projeto,
tenham disponibilidade para ajudar os desenvolvedores sempre
que tiverem dvidas. O objetivo fazer que o cliente seja acessvel e compreenda a importncia disso para o bom andamento do
projeto, pois iro surgir dvidas durante o projeto e estas precisam
ser respondidas imediatamente. Isto contribui com a agilidade do
processo e evita o trabalho especulativo.
A ideia da proximidade fsica entre equipe e cliente de desenvolvimento est relacionada ao valor da comunicao no XP. De
acordo com Teles (2004), apesar da existncia de vrios meios de
comunicao, o dilogo presencial a forma mais eficaz, porque
os interlocutores tm acesso a vrios elementos da comunicao,
tais como palavras verbalizadas, gestos, expresses faciais, postura, tom de voz, entre outros. No conjunto, esses elementos colaboram para a melhor compreenso das mensagens transmitidas.
As expresses faciais que demonstram falta de entendimento no
so visveis por telefone. As percepes destas expresses representam um feedback importante, porque provavelmente faro o
interlocutor explicar melhor o assunto. Por telefone no possvel
observar isso e talvez a pessoa decida no verbalizar sua dvida.
Assim comeam as interpretaes equivocadas.
As equipes XP baseiam-se no princpio de que o resultado
final de um projeto depende no apenas dos desenvolvedores,
mas tambm do cliente e de quaisquer outras pessoas que possam ter algum tipo de contribuio para o projeto. Apesar de ser
um ponto de vista aceito por muitas pessoas, vem sendo ignorado
fortemente em diversos casos, especialmente nas grandes corporaes, onde comum se criar uma distncia significativa entre o
cliente e a equipe de desenvolvimento.
74
Jogo de planejamento
O XP utiliza o planejamento com o objetivo de que a equipe de desenvolvimento esteja sempre trabalhando naquilo que
ir agregar maior valor para o cliente a cada dia de trabalho. Este
planejamento feito diversas vezes ao longo do projeto, para que
todos tenham a oportunidade de revisar as prioridades. Assim, garantir que a equipe esteja sempre trabalhando naquilo que o
mais importante para o cliente.
Todo projeto em XP dividido em releases e iteraes, de
modo que a equipe e o cliente tenham diversas oportunidades de
se reunir para revisar o planejamento. Segundo Teles (2004), releases so mdulos do sistema que geram um valor bem definido
para o cliente. Iteraes so perodos de tempo de poucas semanas, em que a equipe implementa um conjunto de funcionalidade
de acordo com a necessidade do cliente.
No incio de cada release e cada iterao ocorre o jogo do
planejamento, que se trata de uma reunio em que o cliente avalia
as funcionalidades que devem ser implementadas e prioriza aquelas que faro parte do prximo release ou da prxima iterao. No
XP, as funcionalidades so descritas em pequenos cartes e so
chamadas de estrias. Essas estrias devem ser escritas sempre
pelo prprio cliente. No existem regras de formato para escrevlas, mas o cliente deve respeitar o espao do carto, dessa forma
as estrias so sempre criadas e mantidas da forma mais simples
possvel, sendo o suficiente para transmitir a ideia desejada. Quando o cliente escreve uma estria ele forado a pensar melhor
na funcionalidade, pois formaliza pensamento e analisa melhor o
assunto sobre o qual ira tratar. O cliente assume uma responsabilidade sobre aquilo que est sendo solicitado.
A equipe de desenvolvimento utiliza os cartes para identificar as funcionalidades desejadas pelo cliente e escolhem as estrias que iro implementar a cada dia de trabalho. Durante o jogo
do planejamento, as estrias so estimadas para que o cliente possa conhecer o custo da implementao de cada uma delas.
75
No XP o produto software entregue de forma incremental,

de modo que aps cada entrega o cliente possa comear a utilizar
o sistema e obter os benefcios que ele oferece, essas entregas
tratam-se dos releases. O XP trabalha com conceito com releases
pequenos, isto , os releases tm curta durao, em torno de 2
meses (TELES, 2004). Releases pequenos permitem a entrega rpida de algo que tem valor para o cliente, que pode comear a
usufruir dos benefcios do software.
No incio do projeto, o cliente e a equipe devem dividir o
projeto em releases de tamanhos fixos e pequenos, estabelecendo
uma ordem. Em seguida, o cliente atribui as estrias aos releases.
Porm, no necessrio que todas as estrias sejam distribudas,
visto que medida que os releases so desenvolvidos, o cliente
aprende sobre o sistema e pode gerar alteraes nas estrias dos
releases subsequentes.
O cliente poder alterar as estrias se for necessrio. Durante um release, ele pode criar estrias que substitua estrias
existentes, e assim remover as estrias previsveis, incorporando,
desse modo, o seu aprendizado no sistema. Dessa forma, o XP simplifica a incorporao de mudanas ao projeto, que gera benefcios
diretos para o cliente, essas alteraes refletem o crescente aprendizado do cliente quanto ao sistema.
O XP procura dar flexibilidade ao cliente, fazendo com que
a equipe trabalhe de forma eficiente. Durante todo o projeto, o
cliente pode fazer mudanas nas estrias. Porm, dentro de uma
iterao, e somente neste caso, o cliente ter de concordar com o
que foi decidido na reunio de planejamento e, com isso, ter que
esperar o fim da iterao para solicitar mudanas.
Stand up meeting
Um dia de trabalho de uma equipe XP sempre comea com
stand up meeting, que pode ser traduzido por reunio em p. Referindo uma reunio rpida que acontece todos os dias e que enClaretiano - Centro Universitrio
76
volve todos os membros da equipe de desenvolvimento, fazendo

o grande diferencial.
O stand up meeting serve para que todos da equipe comentem rapidamente o trabalho que executaram no dia anterior.
Isto faz com que a equipe fique atualizada sobre o andamento do
projeto naquele dia. Alm disso, tambm uma oportunidade de
apresentar aos demais os desafios enfrentados e as solues criadas por eles. Assim, quando os problemas semelhantes acontecerem, todos sabero o que fazer ou, no mnimo, sabero a quem
procurar.
Esta reunio realizada diariamente, normalmente de manh, pela equipe de desenvolvimento com o objetivo de compartilhar informaes sobre o projeto e priorizar suas atividades. Tratase de um dilogo entre todos os membros da equipe, se possvel
envolvendo tambm a presena do cliente. Referindo-se ao dia
anterior, o stand up meeting d a oportunidade de todos os dias
avaliar o trabalho. Assim, h chance de identificar pontos negativos no processo. A identificao dos pontos fracos essencial para
que possam aperfeioar diariamente o seus trabalhos.
No stand up meeting a equipe decide em conjunto o que
sero abordados naquele dia e quem cuidar de cada carto (chamado de estria). Lembrando que, no incio de cada iterao, o
cliente e a equipe se renem para o jogo do planejamento. O resultado um conjunto de cartes contendo estrias que devero
ser implementadas na iterao.
importante saber que a deciso sobre o que fazer ao longo
do dia no decidida por uma pessoa, mas a deciso tomada em
equipe. Quando todos se renem, possvel ter uma viso de todo
o desenvolvimento e no apenas de uma parte, com isso possvel
decidir com mais eficcia quais so as prioridades do dia. Os participantes no precisam estar em p, embora seja aconselhvel. As
pessoas tm que dar importncia ao contedo da reunio e participao ativamente. Todos tm que falar, ao menos, por alguns mi-
77
nutos. E, por fim, importante que a equipe procure ser objetiva e

gaste pouco tempo na reunio.
Programao em par
Os desenvolvedores no trabalham sozinhos em um projeto
que utilize XP, sempre em pares. A programao em par uma
tcnica na qual dois programadores trabalham em um mesmo problema, ao mesmo tempo e em um mesmo computador. Em outras palavras, uma pessoa (condutor) assume o teclado e digita os
comandos que far parte do programa, a outra (o navegador) a
acompanha fazendo um trabalho de estrategista.
A programao em par utilizada para fazer a reviso do cdigo
em par, enquanto o condutor digita, o navegador est permanentemente revisando o cdigo e tentando evitar que eventuais erros do condutor passem despercebidos. Assim, pequenos erros que so simples de
serem corrigidos no ato gastam muito tempo para serem corrigidos depois. A programao em par elimina estes erros na medida em que so
detectados pelo parceiro que no esto com as mos no teclado.
O uso da programao em par gera ideias mais eficazes e,
ao mesmo tempo, mais simples. A questo da simplicidade bastante ntida. Se um parceiro sugere uma ideia muito complicada, o
outro consegue notar a complexidade, na medida em que ele ter
dvidas o outro poder sempre sugerir simplificaes, tendo como
resultado final uma soluo mais clara e simples. O cdigo feito
quase livre de defeitos. Devido aos processos contnuos de reviso, pouqussimos erros permanecem no cdigo, sendo importante durante o projeto porque significa que a equipe gastar menos
tempo futuro descobrindo defeitos.
No dia a dia de um programador, ele se depara com diversas
fontes de distrao: email, mensagens instantneas, sites de internets, cansao so elementos para que o programador diminua seu
desempenho de trabalho no cdigo. Estes desvios so corrigidos
atravs da presso do par. O programador est acompanhado de
78
outra pessoa, ele deixa de ter um compromisso apenas consigo mesmo. O seu compromisso aumenta e passa a envolver mais algum.
Existe revezamento entre eles (condutor/navegador), s vezes
um ou outro esto cansados e pede substituio. Portanto, o revezamento fundamental e deve ser praticado sempre que se fizer necessrio. E no se aplica o revezamento apenas questo de quem
conduz o teclado, mas tambm entre pares distintos. Em um projeto, preciso que seja trocado o par diariamente, com frequncia,
visto que essa troca importante para a troca de conhecimento.
Refactoring
De acordo com Teles (2004), o refactoring o ato de alterar
um cdigo sem afetar a funcionalidade que ele executa. utilizado
para tornar o software mais simples de ser manipulado e se utiliza
fortemente dos testes para garantir que as modificaes no interrompam seu funcionamento.
Se um desenvolvedor tem uma dvida em uma parte do cdigo, este deve procurar compreend-lo e, em seguida, reescrever de
modo que fique mais legvel, no alterando a funcionalidade, j que
o cdigo deve continuar fazendo a mesma coisa. O XP faz com que o
cdigo se torne mais legvel dando a ele o nome de refactoring.
O cdigo-fonte mal formulado cria dificuldades srias para
quem tiver a necessidade de modificar ou compreender por alguma razo. Quando o cdigo est legvel possvel modificar rapidamente. Em contrapartida, se estiver uma desordem, pode ser
necessrio gastar muito tempo para entend-lo. Assim, o refactoring no deve afetar o comportamento original do cdigo, deve
apenas torn-lo mais legvel.
O refactoring est diretamente relacionado ao cdigo coletivo. Ele permite que os desenvolvedores atuem em qualquer parte
do sistema, mantendo a legibilidade do cdigo e tornando simples
a prtica do cdigo coletivo, pois os desenvolvedores conseguem
ler qualquer parte do cdigo facilmente.
79
Quando no se dedica ateno ao refactoring, o cdigo vai

crescendo e se tornando mais desorganizado e ilegvel a cada dia
e a equipe tendo mais dificuldades em incorporar mudanas. Com
o refactoring a equipe minimiza este problema e consegue ter agilidade e flexibilidade.
importante saber que sem o refactoring um projeto em
XP no tem a menor chance de sobrevivncia. O XP baseia-se em
agilidade de gerar feedback rapidamente para o cliente e s possvel fazer alteraes e adio de novas funcionalidades alterando
o cdigo com facilidade e agilidade. Sem uma boa organizao do
projeto no possvel ser gil e realizar as alteraes necessrias
no cdigo, pois s possvel fazer isso se o projeto for organizado
continuamente atravs do refactoring.
O XP enfatiza uma continua remodelagem utilizando a refatorao a
qualquer momento que seja necessrio, no entanto h uma pequena valorizao a documentao de modelagens detalhadas. Tipicamente os desenvolvedores jogam fora documentao de modelos
aps terem escrito o cdigo, entretanto eles mantm se pode ser
til. As equipes tambm passam a manter a documentao quando
o cliente para de vir com novas estrias (TELES, 2004, p. 101).
Porm, o refactoring tambm tem um preo. Ele acompanhado pelo risco de cdigo parar de funcionar. Trata-se de um risco
srio que nunca deve ser ignorado. Porm, o XP possui mais uma
prtica que tambm combate o risco de se quebrar um cdigo que
esta funcionando. Trata-se de testes automatizados que servem
para informar se o cdigo continua produzindo as mesmas respostas mesmo depois de ter sido alterado. Os testes proveem uma
enorme segurana ao processo de refactoring.
Desenvolvimento guiado pelos testes
A ideia principal da programao guiada pelos testes fazer
com que o tempo total dedicado depurao em um projeto seja
o mnimo possvel. Quando se testa, faz-se um investimento e se
espera que ele gere um retorno no futuro.
80
Os desenvolvedores aprendem sempre, ou seja, aprendem

com os testes. Quanto mais os desenvolvedores tm a oportunidade de aprender, melhor eles codificam e menos defeitos surgem do
sistema. Sempre que um teste detecta uma falha, a equipe ganha
tempo de desenvolvimento, pois tem a oportunidade de corrigir o
problema rapidamente, o que evita longas sesses de depurao
que costumam tomar boa parte do tempo dos projetos.
O XP trabalha com dois tipos de testes, sendo eles: testes de
unidade e teste de aceitao. Voc aprender detalhes sobre teste
de software na Unidade 7 deste material.
O teste de unidade aquele realizado sobre cada classe do
sistema para verificar se os resultados gerados so corretos. Os
testes de aceitao so efetuados sobre cada funcionalidade, ou
estria do sistema, verificando no apenas uma classe em particular, mas a interao entre um conjunto de classes que implementam uma dada funcionalidade.
Cdigo coletivo
Quando um projeto implementado por uma equipe, comum que seja dividido em partes, de forma que cada membro da
equipe fique responsvel por uma ou mais partes.
O XP busca eliminar as ilhas de conhecimento, pois no existe uma pessoa responsvel por um subconjunto do cdigo. Cada
desenvolvedor tem acesso a todas as partes do cdigo e total liberdade para alterar o que necessitar, ou seja, o cdigo coletivo.
Ilhas de conhecimento nos projetos de software ocorrem quando
uma pessoa que possui um domnio sobre uma rea do projeto,
sabendo que s ela conhece aquela parte ou aquele cdigo.
O XP incentiva a propriedade coletiva do software, isto ,
[...] qualquer um pode modificar qualquer parte do cdigo a qualquer momento, fortificando a necessidade de uma integrao contnua, assim como testes de regresso contnua e a programao
em pares que protege contra a perda do controle das configuraes
(TELES, 2004, p. 146).
81
Assim, cada parte do software pode eventualmente ser observada por diferentes desenvolvedores ao longo da sua vida. A
consequncia disso que o cdigo est sempre sendo revisado.
Vale ressaltar que o cdigo coletivo leva a equipe a ser mais gil no
desenvolvimento. Como no existe uma pessoa responsvel por
certa parte do cdigo, qualquer pessoa pode mexer no cdigo, to
logo sinta a necessidade de faz-lo. No necessrio esperar pelo
especialista.
Em compensao, o cdigo coletivo exige coragem por parte
dos desenvolvedores. Afinal, diversas vezes ao dia o desenvolvedor
ter de mexer em partes do sistema que no foram construdas
por ele. Ser preciso coragem para fazer isso e acreditar que o sistema continuar funcionando mesmo depois das suas mudanas.
A prtica do cdigo coletivo depende fortemente de duas outras:
o refactoring e o desenvolvimento guiado pelos testes.
Padres de codificao
Como j dito, um dos valores fundamentais do XP a comunicao, isso vlido tambm ao cdigo do sistema, sendo que a
equipe deve se comunicar de forma clara atravs do cdigo. Para
ajudar, o XP sugere a utilizao de padres de codificao.
Como existem cdigos de diferentes programadores, provavelmente percebe-se a existncia de diferentes estilos. Essas diferenas dificultam a compreenso do cdigo por todos os membros
da equipe. Isso pode ser evitado atravs da adoo de um mesmo
estilo de codificao por todos. Desta forma, qualquer programador poder ler o cdigo com velocidade, sem se preocupar em
compreender estilos de formatao diferentes.
importante que se procure adotar um padro que seja fcil, simples e esteja documentado em algum lugar. Alm disso,
necessrio sempre negociar de modo a construir um padro que
atenda as necessidades do projeto e que seja aceito pela maioria.
82
Design simples
As prticas do XP so voltadas para a criao de valor para
o cliente. O XP determina que a equipe deva sempre assumir o
design mais simples possvel e que seja capaz de fazer uma funcionalidade passar nos testes.
Em um projeto de software a mudana constante, pois requisitos, design, tecnologia, equipe e os membros mudam. O problema no est na mudana em si, mas na incapacidade de lidar
com a mudana. No decorrer dos anos, a Engenharia de Software
dedicou-se para reduzir os custos de uma alterao de software,
atravs da melhoria das linguagens de programao, da tecnologia
de banco de dados, das prticas de programao, novos ambientes e ferramentas de desenvolvimento e novas anotaes.
De acordo com Teles (2004), para se trabalhar com um design
simples, o XP recomenda que o desenvolvedor utilize a seguinte
estratgia:
1) Comunicao: um design simples comunica a sua inteno
de forma mais eficaz que um design complicado. Isto
ocorre porque mais fcil compreend-lo. Geralmente,
o design precisa ser simples, mas tambm deve ser
capaz de comunicar todos os aspectos importantes do
software.
2) Simplicidade: um design simples torna o software mais
leve e mais fcil de ser alterado a qualquer momento,
visto que mais fcil de ser compreendido.
3) Feedback: criando um design simples, a equipe capaz
de avanar de forma mais gil e obter feedback do cliente mais rapidamente.
4) Coragem: a equipe trabalha o design apenas at o ponto
em que ele resolve o problema de hoje. Problemas do
futuro, mesmo que j sejam previstos, so deixados para
o futuro. necessrio coragem para assumir que a equipe ser capaz de resolver o problema no futuro caso ele
realmente se manifeste.
83
Ao longo das iteraes, o design precisa evoluir, mas deve

manter-se simples e claro para que a equipe possa fazer alteraes
no software a qualquer momento, com facilidade. Por esta razo,
o refactoring tem um papel fundamental no design do XP.
Metfora
Muitas vezes, algum est explicando algo e no h nada que
faa o interlocutor compreend-lo. Depois de algumas tentativas,
a pessoa faz uma comparao daquele assunto com algo que o
interlocutor conhece bem. Neste momento, em um instante, consegue entender toda a explicao simplesmente porque a outra
pessoa utilizou um artifcio que chamado de metfora.
O XP utiliza a metfora para comunicar diversos aspectos do
projeto. necessrio usar a metfora para criar uma viso comum
sobre o projeto em si. A equipe deve buscar uma metfora que
permite explicar as ideias centrais do projeto de forma simples e
objetiva, passando a ser capaz de se comunicar com o cliente e
com outros envolvidos no projeto de forma muito mais eficaz.
Falar da metfora muito fcil, o problema cri-la. Desenvolver uma metfora um exerccio de criatividade e abstrao. Segundo
Teles (2004), metfora, muitas vezes, olhar para os lados e pensar
nas coisas mais absurdas, tentando relacion-las com o seu problema
ou o seu projeto. s vezes deixa a mente livre de pensamentos e, de
repente, aparece uma ideia, um estalo. Este estalo, o resultado de um
complexo processamento no subconsciente, um elemento de grande importncia no desenvolvimento do software. Normalmente, um
simples estalo pode economizar meses de trabalho.
A utilizao da metfora uma prtica que anda de mos dadas com ritmo sustentvel. Por isso que os desenvolvedores devem
chegar descansados todos os dias. Pessoas descansadas produzem
melhor, tm ideias eficazes, so mais atentas e poupam tempo do
desenvolvimento, ou seja, no vantagem trabalhar mais, mas
sim trabalhar de forma mais eficaz e inteligente.
84
Ritmo sustentvel
O XP recomenda que ritmos sustentveis sejam mais produtivos, e por isso no seja utilizada hora extra por duas razes:
permitir que os desenvolvedores trabalhem apenas oito horas por
dia mais humano e demonstrar respeito com a individualidade e
a integridade de cada membro da equipe aumenta a agilidade do
projeto.
Programadores exaustos cometem mais erros, assim, a equipe que no trabalha por um tempo excessivo se mantm mais efetiva. Astels (2002, p. 35) ilustra a necessidade de equilbrio entre
a carga de trabalho e a de descanso quando recomenda "trabalhe
a 100% durante as 40 horas e descanse a 100% no resto. Se algum
deles no tiver foco feito com 100%, um afetar o outro".
O Extreme Programming compreende a natureza humana do
desenvolvimento de software e percebe que trabalhar mais horas
significa diminuir o ritmo de produo, significa atrasar o projeto,
por mais estranho que isto possa parecer no incio.
Assim, a adoo do ritmo sustentvel um desafio a ser
vencido. As equipes que conseguiram adotar esta prtica colhem
frutos dela. Seus projetos so mais geis, as pessoas convivem de
forma mais harmoniosa e no precisam sacrificar a vida pessoal
em nome do trabalho.
Integrao contnua
Quando uma nova funcionalidade incorporada ao sistema
ela pode afetar outras que j estavam implementadas e a integrao contnua entra em prtica levando os pares a integrarem seus
cdigos com o restante do sistema diversas vezes ao dia. Quando
o par faz isso ele executa todos os testes para assegurar que a integrao tenha ocorrido de forma satisfatria por outra pessoa para
que o problema seja resolvido.
85
O XP prope uma estratgia de integrao diferente. Ao invs de esperar muito tempo para integrar as partes do sistema,
a equipe deve integrar com a maior frequncia possvel. Normalmente, uma equipe XP deve integrar e testar novamente o sistema
inteiro diversas vezes por dia. Essa prtica chamada de integrao contnua (JEFFRIES, 2001).
Uma das dificuldades de se integrar diversas vezes ao dia diz
respeito ao tempo necessrio para fazer o build de todo o sistema.
Em tempo precisa ser baixo e precisa ser mantido baixo ao longo
de todo o projeto. Existem diversas formas de fazer isso, como por
exemplo:
Fazer com que a interdependncia entre os arquivos seja
baixa.
Fazer com que o compilador s compile os arquivos que
tiverem sido editados e utilize diretamente o cdigo objeto para os demais.
Trabalhar com a carga dinmica de bibliotecas quando
isso for possvel.
Se o build comea a ficar lento, a equipe precisa tratar logo
da questo e descobrir uma forma de manter o build rpido. Isso
uma prioridade para o desenvolvimento. O build tem que ser
executado rapidamente, assim como os testes de unidade. Isso faz
com que a equipe possa avanar com agilidade e a motiva a integrar vrias vezes por dia, o que diminui a possibilidade de erros no
processo de integrao.
O cdigo coletivo permite que a equipe avance mais rapidamente porque no necessrio esperar por outra pessoa para que
o problema seja resolvido. O cdigo permanece mais claro, pois
revisado sempre por diversos programadores e eles no precisam
contornar reas problemticas do sistema.
Para que faa a integrao contnua, sero necessrias duas
categorias de ferramentas: ferramenta de build e sistema de controle de verso, o qual chamado simplesmente de repositrio.
86
A ferramenta de build utilizada para compilar todo o sistema e executar outras atividades que se faam necessrias para
que ele possa ser executado, ajudando os desenvolvedores a ganharem agilidade para que possam acontecer suas mudanas, gerarem o sistema imediatamente e test-lo.
O repositrio armazena todos os cdigos fonte do sistema
mantendo a verso deles. Trata-se de uma ferramenta essencial
no processo de integrao, pois quando utilizado pode fazer uma
diferena enorme na produtividade da equipe.
Segundo Jeffries (2001), o processo de integrao feito correto quando ele no obstrui o avano da equipe. Deve ser fcil e
rpido obter o cdigo fonte do qual o desenvolvedor necessita e
armazenar as suas mudanas. O repositrio deve detectar conflitos e importante que seja simples resolv-los. No deve esperar,
isto , se um par precisa editar alguma coisa, ele deve seguir adiante sem que nada o impea.
Releases curtos
O Extreme Programming tem como objetivo gerar um fluxo
contnuo de valor para o cliente, sendo que a equipe produz um
conjunto reduzido de software no dia a dia e se beneficiam dele
cada vez mais incorporando mais funcionalidades e gerando mais
valor. O XP recomenda que o projeto faa pequenos investimentos
gradualmente e busque grandes recompensas o mais rapidamente
possvel. Para isso acontecer, o XP trabalha com releases curtos.
O XP sugere que a equipe de desenvolvimento implemente
as funcionalidades mais importantes o quanto antes. Ou seja, o
cliente deve selecionar o conjunto de funcionalidades que poder
gerar o valor mais alto mais rapidamente. Assim, os primeiros releases devero fornecer o mximo de valor, de modo que o cliente
consiga obter o mximo de retorno rapidamente.
Trabalhando com releases curtos, o cliente tem oportunidade de avaliar o projeto rapidamente e com frequncia. Tendo a
87
oportunidade de tomar uma deciso informada: continuar o projeto ou suspend-lo para evitar perdas ainda maiores (em certos
casos). Alm disso, na medida em que os clientes comeam a obter
retorno do investimento mais cedo, ele tem mais chances de obter
o retorno total ou, no mnimo, de reduzir eventuais perdas.
A abordagem tradicional mais arriscada que a do XP, pois
os usurios no tm a chance de avaliar o software sempre, e o
projeto s comea a gerar receita aps a concluso.
Segundo Brooks (1995), comum o cliente fazer um grande
investimento na construo de um software e este simplesmente
no atender as suas necessidades levando a lanar um novo projeto para a construo de um software, que assim ir atender aos
anseios dos usurios.
Por todas essas razes, os projetos em XP trabalham com
releases que no consumam mais que dois meses. Isso permite incorporar uma boa quantidade de funcionalidade em cada release
e permite que os usurios aprendam com o software com bastante frequncia.
O XP est sendo aplicado em larga escala em vrios projetos
no mundo todo, porm ainda temos muito a evoluir em sua compreenso e aplicao. Nota-se isso principalmente em pontos polmicos como testes unitrios, programao em dupla, rodzio de
pessoas, propriedade coletiva do cdigo e otimizao de jornadas,
que so prticas que se mal utilizadas podem realmente trazer aumentos no custo e no prazo de projetos. Ou seja, de extrema importncia que se entenda bem a essncia de XP e, principalmente,
que se tenha disciplina e criatividade, duas qualidades bsicas em
quem pretende us-la em projetos. Somente a partir de uma viso criativa sobre a metodologia e uma disciplina equilibrada para
cumpri-la que todos podero usar e ter benefcios atravs de
Extreme Programming.
88
8. QUESTES AUTOAVALIATIVAS
Sugerimos que voc procure responder, discutir e comentar
as questes a seguir que tratam da temtica desenvolvida nesta
unidade. Se voc encontrar dificuldade em respond-las, procure
revisar os contedos estudados para sanar as suas dvidas. A autoavaliao pode ser uma ferramenta importante para voc testar
seu desempenho. Este um momento mpar para voc fazer uma
reviso desta unidade. Lembre-se de que no ensino a distncia a
construo do conhecimento se d de forma cooperativa e colaborativa, portanto compartilhe com seus colegas suas descobertas.
1) Um analista foi contratado para desenvolver um sistema de pesquisa de DVDs
em lojas virtuais. O sistema dever solicitar ao usurio um ttulo de DVD, que
ser usado para realizar a pesquisa nas bases de dados das lojas conveniadas. Ao detectar a disponibilidade do DVD solicitado, o sistema armazenar
temporariamente os dados das lojas (nome, preo, data prevista para entrega do produto) e exibir as informaes ordenadas por preo. Aps analisar
as informaes, o cliente poder efetuar a compra. O contratante dever
testar algumas operaes do sistema antes de ele ser finalizado. H tempo
suficiente para que o analista atenda a essa solicitao e efetue eventuais
modificaes exigidas pelo contratante. Com relao a essa situao, julgue
os itens a seguir quanto ao modelo de ciclo de vida.
I O entendimento do sistema como um todo e a execuo sequencial das
fases sem retorno produzem um sistema que pode ser validado pelo
contratante.
II A elaborao do prottipo pode ser utilizada para resolver dvidas de
comunicao, o que aumenta os riscos de incluso de novas funcionalidades no prioritrias.
III A definio das restries deve ser a segunda fase a ser realizada no
desenvolvimento do projeto, correspondendo etapa de engenharia.
IV Um processo iterativo permite que verses progressivas mais completas do sistema sejam construdas e avaliadas.
Esto corretos apenas os itens.
a)
b)
c)
d)
e)
I e II.
I e III.
II e III.
II e IV.
III e IV
Fonte: ENADE 2008 Tecnologia em Anlise e Desenvolvimento de Sistemas.
2) medida que se avana pelo modelo ocorre uma iterao e o software evolui para estgios superiores, normalmente com aumento da complexidade.
89
Cada iterao est provida das atividades determinadas pelos quadrantes

planejamento, avaliao de alternativas e riscos, desenvolvimento do software e avaliao do cliente. No ciclo de vida de desenvolvimento de software, trata-se da propriedade do modelo:
a) Cascata.
b) Incremental.
c) Espiral.
d) Prototipao.
e) Balbrdia.
Fonte: Prova aplicada em 03/2010 para o concurso do(a) TRT - 20 REGIO (SE) - 2009, realizado pelo
rgo/instituio Tribunal Regional do Trabalho da 20 Regio - Sergipe, rea de atuao Jurdica,
organizada pela banca FCC, para o cargo de Analista Administrativo - Informtica, nvel superior,
rea de formao Tecnologia da Informao .
Gabarito
Depois de responder s questes autoavaliativas, importante que voc confira o seu desempenho, a fim de que possa saber se preciso retomar o estudo desta unidade. Assim, confira, a
seguir, as respostas corretas para as questes autoavaliativas propostas anteriormente:
1) (d)
2) (c)
9. CONSIDERAES
Chegamos ao final do estudo da Unidade 2, na qual voc
teve a oportunidade de aprender o que um processo de
software e perceber a importncia de ter um processo definido e
que o processo utilizado para desenvolver um software influencia
diretamente na qualidade do produto desenvolvido.
Voc verificou, ainda, que a Engenharia de Software prope
vrios modelos para o desenvolvimento de sistemas com o objetivo de minimizar custo, tempo e maximizar qualidade.
Percebeu, tambm, que h inmeros modelos e a escolha de
qual utilizar est diretamente relacionada s caractersticas especficas do sistema a ser desenvolvido.
90
Na prxima unidade, voc poder verificar que, alm de ter

um processo de software bem definido, necessrio que se tenha
mecanismos para gerenciar o processo para que se atinja o objetivo de um software com qualidade.
10. REFERNCIAS BIBLIOGRFICAS

ASTELS, David; MILLER, Granville; NOVAK, Miroslav. Extreme Programming: Guia prtico.
Rio de Janeiro, Campus, 2002.
PAULA FILHO, W. P. Engenharia de Software: fundamentos, mtodos e padres. 2. ed. Rio
de janeiro: LTC, 2001.
PRESSMAN, R. S. Engenharia de software. So Paulo: Makron Books, 1996.
______. Engenharia de software. So Paulo: Makron Books, 2006.
SOMMERVILE, I. Software engineering. 4th ed. Addison: Wesley, 1994.
______. Engenharia de Software. 6. ed. So Paulo: PearsonAddison Wesley, 2005.
TELES, V. M. Extreme Programming. So Paulo: Novatec, 2004.

U2-Processo de Software-Paradigmas de Software-Extreme Programming

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

U2-Processo de Software-Paradigmas de Software-Extreme Programming

Caricato da

Copyright:

Formati disponibili

EAD

3. ORIENTAES PARA O ESTUDO DA UNIDADE

U2 Paradigmas de Desenvolvimento de Software

dos mitos, possvel; mas, antes de tudo, preciso ter cincia de

Paula Filho (2001) define processo como:

U2 Paradigmas de Desenvolvimento de Software

construir e manter grandes sistemas de software de forma

6. PARADIGMAS DA ENGENHARIA DE SOFTWARE

Os modelos prescritivos no so perfeitos, mas fornecem um

U2 Paradigmas de Desenvolvimento de Software

mente estas fases ocorrero durante o processo de desenvolvimento de software.

Fonte: Adaptado de Pressman (1996, p.33)

Figura 1 Modelo em Cascata.

U2 Paradigmas de Desenvolvimento de Software

Vale ressaltar, tambm, que os resultados de um processo

U2 Paradigmas de Desenvolvimento de Software

o cliente definiu um conjunto de objetivos gerais para o software,

Fonte: Pressman (1996, p.36).

Figura 2 Modelo de Prototipao.

Claretiano - Centro Universitrio

Esse modelo apresenta alguns problemas, tais como:

U2 Paradigmas de Desenvolvimento de Software

A ideia principal deste modelo, conforme ilustrado na Figura

Fonte: Adaptada de Pressman (2006, p. 40).

Figura 3 Modelo de desenvolvimento incremental.

fundamental considerar alguns aspectos desse modelo.

U2 Paradigmas de Desenvolvimento de Software

H, tipicamente, de trs a seis regies de tarefa, observe

Fonte: Adaptado de Pressman (1996, p. 39)

Figura 4 Modelo espiral.

Observaes relacionadas ao modelo espiral:

U2 Paradigmas de Desenvolvimento de Software

8) a abordagem mais realstica para o desenvolvimento de

nica ou gerencial. , porm, um modelo de alto risco, difcil de ser

U2 Paradigmas de Desenvolvimento de Software

O ciclo de vida do XP tem quatro atividades bsicas: codificar,

gem para lidar com este risco, o que em XP se traduz em confiana

U2 Paradigmas de Desenvolvimento de Software

biliza a simplicidade do processo. Alm disso, permite-se que o

U2 Paradigmas de Desenvolvimento de Software

No XP o produto software entregue de forma incremental,

volve todos os membros da equipe de desenvolvimento, fazendo

U2 Paradigmas de Desenvolvimento de Software

nutos. E, por fim, importante que a equipe procure ser objetiva e

U2 Paradigmas de Desenvolvimento de Software

Quando no se dedica ateno ao refactoring, o cdigo vai

Claretiano - Centro Universitrio

Os desenvolvedores aprendem sempre, ou seja, aprendem

U2 Paradigmas de Desenvolvimento de Software

Claretiano - Centro Universitrio

U2 Paradigmas de Desenvolvimento de Software

Ao longo das iteraes, o design precisa evoluir, mas deve

U2 Paradigmas de Desenvolvimento de Software

U2 Paradigmas de Desenvolvimento de Software

Claretiano - Centro Universitrio

Fonte: ENADE 2008 Tecnologia em Anlise e Desenvolvimento de Sistemas.

U2 Paradigmas de Desenvolvimento de Software

Cada iterao est provida das atividades determinadas pelos quadrantes

Na prxima unidade, voc poder verificar que, alm de ter

10. REFERNCIAS BIBLIOGRFICAS

Potrebbero piacerti anche