Modelo Clássico ou Sequencial vs Extreme Programming (XP)
Descripción
Exercício 03 - Mapa Conceitual
Leia o artigo: Comparação entre Metodologias Ágeis e Tradicionais para o Desenvolvimento de Software, disponível no link: http://www.dcc.ufla.br/infocomp/index.php/INFOCOMP/article/view/68.
E elabore um mapa conceitual.
Modelo Clássico ou Sequencial vs
Extreme Programming (XP)
Projetos em que há muitas mudanças, em que os requisitos
são passíveis de alterações, onde refazer partes do código
não é uma atividade que apresenta alto custo, as equipes são
pequenas, as datas de entrega do software são curtas e o
desenvolvimento rápido é fundamenta.
Metodologias Tradicionais
É um modelo em que existe uma sequência
a ser seguida de uma etapa a outra.
Apenas 16;2% 6 dos projetos foram entregues
respeitando os prazos e os custos e com todas as
funcionalidades especificadas. Aproximadamente 31%
dos projetos foram cancelados antes de estarem
completos e somente 52,7% foram entregues porém, com
prazos maiores, custos maiores ou com me nos
funcionalidades do que especificado no início do projeto.
Fazem parte do modelo Clássico as etapas de
definição de requisitos, projeto do software,
implementação e teste unitário, integração e
teste do sistema, operação e manutenção.
É um modelo que deve ser usado
somente quando os requisitos
forem bem compreendidos.
Alterações nos requisitos são
muitas vezes críticas nas
metodologias tradicionais, que não
apresen tam meios de se adaptar
rapidamente às mudanças.
Metodologias Ágeis
Indivíduos e interações ao invés de processos e ferramentas.
Software executável ao invés de documentação.
Colaboração do cliente ao invés de negociação de contratos.
Respostas rápidas a mudanças ao invés de seguir planos.
A Extreme Programming (XP) é uma metodologia ágil
para equipes pequenas e médias que desenvolvem
soft ware baseado em requisitos vagos e que se
modifica rapidamente [Beck (1999)].
Enfatiza o desenvolvimento rápido do projeto e visa garantir a
satisfação do cliente, além de favorecer o cumprimento das
estimativas. São conduzidos por quatro valores: comunicação,
simplicidade, feedback e coragem [Beck (1999)].
Feedback constante.
Abordagem incremental.
A comunicação entre as
pessoas é encorajada.
Planejamento: consiste em decidir o
que é necessá rio ser feito e o que
pode ser adiado no projeto.
Entregas freqüentes visa à construção de um
software simples, e conforme os requisitos
surgem, há a atu alização do software.
Projeto simples: o programa desenvolvido pelo
método XP deve ser o mais simples possível e
satisfazer os requisitos atuais, sem a preocupação
de requisi tos futuros.
Metáfora são as descrições de um software sem
a uti lização de termos técnicos, com o intuito
de guiar o desenvolvimento do software.
Testes: a XP focaliza a validação do projeto
durante todo o processo de desenvolvimento.
Programação em pares: a implementação do código
é feita em dupla, ou seja, dois desenvolvedores tra
balham em um único computador.
Refatoração: focaliza o aperfeiçoamento
do projeto do software e está presente
em todo o desenvolvimento.
Propriedade coletiva: o código do projeto
pertence a todos os membros da equipe.
Integração contínua: é a prática de interagir e
cons truir o sistema de software várias vezes por
dia, mantendo os programadores em sintonia,
além de possibilitar processos rápidos.
40 horas de trabalho semanal: a XP assume que
não se deve fazer horas extras constantemente.
Cliente presente: é fundamental a participação do
cliente durante todo o desenvolvimento do projeto.
Código padrão: padronização na arquitetura
do código, para que este possa ser
compartilhado entre todos os programadores.
Na XP não existe a preocupação
formal em fazer a análise e o
planejamento de riscos. Como
riscos acontecem normalmente
em projetos de desen volvimento
de software, este é um ponto
negativo da XP.
Mesmo assim, os resultados
iniciais em termos de
qualidade, confiança, datas
de entrega e custo são
promissores.
A XP é ideal para ser usada em
projetos em que os stakeholders
não sabem exatamente o que
desejam e podem mudar muito
de opinião durante o desenvol
vimento do projeto.
Um ponto positivo das
metodologias ágeis são as
entregas constantes de partes
operacionais do software.
Melhor fazer algo simples hoje e pagar
um pouco mais amanhã para fazer
modificações necessárias do que
implementar algo com plicado hoje
que talvez não venha a ser usado,
Uma característica das
metodologias ágeis é que elas são
adaptativas ao invés de serem
preditivas.
A idéia das metodologias ágeis é o
enfoque nas pessoas e não em
processos ou algoritmos.
Metodologias tradicionais são orientadas a documentação.
Metodologias ágeis procuram desenvolver software com o
mínimo de documentação.
As metodologias pesadas devem ser
aplicadas apenas em situações em que
os requisitos do software são estáveis e
requisitos futuros são previsíveis.