O documento aborda metodologias ágeis e tradicionais no desenvolvimento de software, destacando a evolução das práticas ao longo das décadas. Apresenta o modelo cascata como um tradicional, focado em documentação e fases sequenciais, enquanto discute as vantagens dos métodos ágeis, como o Extreme Programming, que priorizam a flexibilidade e a colaboração com o cliente. Conclui que métodos ágeis tendem a gerar melhores resultados em prazo, custo e qualidade, embora possam enfrentar resistência à mudança e de clientes com requisitos menos formais.

1. CIÊNCIA DA COMPUTAÇÃO - FCG
Qualidade de Software
Aula 08: Metodologias Ágeis
(Adaptação do capítulo 10 de Koscianski & Soares, 2006)
Prof.º Msc. Sidney Roberto de Sousa

2. Metodologias de desenvolvimento de software
 Nas últimas décadas, várias metodologias
foram criadas a fim de sistematizar o
desenvolvimento de software
 Tais metodologias podem ser divididas em:
 Tradicionais: ênfase na documentação de cada
passo do desenvolvimento do software
 Ágeis: paradigma mais recente de engenharia de
software, o qual promete melhorias de
produtividade e qualidade
Ciência da Computação - FCG 2

3. Atividades comuns a metodologias
 Especificação: definição das funcionalidades e
demais características do produto
 Projeto e Implementação: produção do software de
acordo com as especificações. Propõe-se modelos os
quais serão implementados em alguma linguagem de
programação
 Validação:revisão e testes quem visam a garantia de
cumprimento dos requisitos
 Evolução: manutenção ou criação de novas
funcionalidade a fim de adaptar o software a novas
necessidades do cliente
Ciência da Computação - FCG 3

4. Metodologias Tradicionais
 Consideradas por muitos com ”pesadas” ou
”orientadas a documentação”
 Surgiram em um contexto de desenvolvimento de
software muito diferente do atual → baseado em
mainframes e terminais burros
 Em tal época, o custo de manutenção era muito caro
→ dificuldade de acesso a computadores e a
escassez de ferramentas de apoio ao
desenvolvimento de software
 Assim, todo o software era planejado e documentado
antes de ser implementado
Ciência da Computação - FCG 4

5. Modelo Cascata
 Também conhecido como modelo clássico, é
considerada a principal metodologia tradicional
 Estabele uma sequência de etapas
 Após o término de cada etapa é criada uma
documentação que deve ser aprovada para
que a próxima etapa possa ser iniciada
Ciência da Computação - FCG 5

6. Modelo Cascata
Ciência da Computação - FCG 6

7. Modelo Cascata
 Divide o projeto em fases de forma inflexível
 Ex.: após a fase de desenvolvimento não são
previstas mudanças de requisitos
 O modelo espiral permite o retorno a etapas
anteriores, porém não dá suporte à execução
de etapas de forma paralela
 Este paralelismo é necessário em alguns tipos
de projeto → ex.: desenvolvimento de módulos
concorrentes
Ciência da Computação - FCG 7

8. Modelo Cascata
Assim, o modelo cascata é recomendável em
projetos com requisitos estáveis → Isto existe?
Ciência da Computação - FCG 8

9. Custo de modificação no Modelo Cascata
Ciência da Computação - FCG 9

10. Modelo Cascata
 O modelo cascata dominou a forma de se
desenvolver software até o inícios dos anos 90
 Tal dominância ocorreu mesmo sob
advertência de pesquisadores de engenharia
de software e o relato negativo de
desenvolvedores de software
 Autores como Brooks (Brooks, 1986)
demonstraram como a idéia de se especificar
um software por inteiro antecipadamente pode
ter riscos sérios
Ciência da Computação - FCG 10

11. Experiências da indústria
 Dados de 1994 usando como base 8380 projetos
mostram que apenas 16,2% destes foram entregues
respeitando prazos, custos e requisitos
 Cerca de 31% foram cancelados antes de seu término
e 52,7% foram entregues → com prazos e custos
maiores OU com diminuição de requisitos
 Causa? Pressão sobre desenvolvedores →
quadruplica o número de erros!
 Modelo cascata → dificuldades em alterar requisitos
Ciência da Computação - FCG 11

12. Experiências da indústria
 No fim da década de 90, pesquisas mostraram
resultados mais ”animadores”
 15% dos projetos terminaram sem mostrar resultados
 66% dos projetos não atenderam as necessidades
dos usuários
 Média de atrasos caiu para 63%
 Projetos custaram em média 45% a mais que o
planejado
 28% dos projetos cumpriram o planejado → porém, a
maioria destes projetos foram superestimados –
exageros de até 150%
Ciência da Computação - FCG 12

13. Experiências da indústria
 Dentre os motivos da melhoria, o principal foi o uso de
ferramentas CASE no processo de modelagem e
implementação
 As ferramentas de gestão de requisitos também foram
responsáveis pela melhoria
 Por fim, também ajudou a melhoria da qualidade dos
processos de desenvolvimento
 As pesquisas do final dos anos 90 recomendaram o
desenvolvimento de software baseado em modelos
incrementais → evitar falhas
Ciência da Computação - FCG 13

14. Métodos ágeis
 Adequados para situações em que a mudança de
requisitos é frequente
 Um método ágil aceita a mudança ao invés de tentar
prever o futuro
 O termo se tornou comum em 2001, quando 17
especialistas em processos de desenvolvimento de
software – representando as metodologias XP, Scrum,
DSDM, Crystal, entre outros, estabeleceram os
princípios comuns compartilhados por todos estes
métodos
 Criou-se assim a Aliança Ágil e o Manifesto Ágil
Ciência da Computação - FCG 14

15. Métodos ágeis
Ciência da Computação - FCG 15

16. Métodos ágeis
 O Manifesto Ágil não rejeita processos e
ferramentas, documentação, negociação de
contratos ou planejamento
 Porém, ele mostra que estes tem menos
importância que os indivíduos, o software
executável, a colaboração dos clientes e as
respostas rápidas às mudanças
 Aproximação da forma como pequenas e
médias empresas trabalham e respondem às
mudanças
Ciência da Computação - FCG 16

17. Conceitos-chave do Manifesto Ágil
 Indivíduos e interações ao invés de processos
e ferramentas
 Software executável ao invés de documentação
 Colaboração com o cliente ao invés de
negociações de contratos
 Respostas rápidas a mudanças ao invés de
seguir planos
Ciência da Computação - FCG 17

18. Extreme Programming (XP)
 Método ágil para equipes pequenas/médias
que desenvolvem software baseado em
requisitos vagos e rapidamente mutáveis
 Principais diferenças entre a XP e as
metodologias clássicas:
 Feedback contínuo
 Abordagem incremental
 Encorajamento da comunicação interpessoal
Ciência da Computação - FCG 18

19. Extreme Programming (XP)
 As práticas da XP podem ser ”chocantes” à primeira vista
→ ou mesmo não fazer sentido, se observadas de forma
isolada
 Porém, a sintonia do seu conjunto que faz com que a
metodologia seja sucessiva
 A XP enfatiza o desenvolvimento rápido do projeto, a
garantia de satisfação do cliente e o cumprimento das
estimativas
 Suas práticas/valores oferecem um ambiente agradável
de desenvolvimento de software aos seus seguidores →
conduzindo-os por quatro valores: comunicação,
simplicidade, feedback e coragem
Ciência da Computação - FCG 19

20. XP - Comunicação
 Manter o melhor relacionamento possível entre
clientes e desenvolvedores
 Prefere-se conversas pessoais ao invés de
outros meios de comunicação
 A comunicação entre desenvolvedores e
gerente de projeto também é encorajada
Ciência da Computação - FCG 20

21. XP - Simplicidade
 Permitir a criação de código enxuto, que não deve
possuir funções desnecessárias
 Código simples → implementar o software com o
menor número possível de componentes como
classes e métodos
 Preocupação com requisitos atuais, evitando-se
adicionar funcionalidades que não são úteis no
momento → escopo bem definido
 XP aposta na implementação rápida de um produto
simples → espera-se que alterações e evoluções
futuras custarão menos do que criar desde o início um
software grande e complexo
Ciência da Computação - FCG 21

22. XP – Feedback constante
 Programador deve ter informações constantes sobre o
código e o cliente
 A informação sobre o código é obtida por testes constantes
→ indicação de erros unitários e de integração
 O cliente obtem frequentemente incrementos de software
funcionais para que posso avaliá-los
 Com isto, o cliente tem subsídios para sugerir novas
características e informação aos desenvolvedores
 Não-conformidades são identificadas rapidamente e
corrigidas em novas versões/incrementos
 O produto tende a estar de acordo com as reais expectativas
do cliente
Ciência da Computação - FCG 22

23. XP - Coragem
 Necessária para implantar os três valores
anteriores
 Nem todas as pessoas tem facilidade de
comunicação e têm bom relacionamento
 A coragem também é necessária para
experimentar a simplificidade no software
implementado
 Por fim, é preciso coragem para ouvir o
feedback do cliente!
Ciência da Computação - FCG 23

24. Práticas da XP
 A XP baseia-se em 12 práticas
 Não exige-se a implementação simultânea de
todas as práticas → recomenda-se que sejam
aplicadas gradativamente
 Algumas práticas não são inovadores → na
verdade, são usadas há anos na indústria de
software
Ciência da Computação - FCG 24

25. Prática 1 - Planejamento
 Decidir o que é necessário fazer o que pode ser adiado no
projeto
 A XP baseia-se em requisitos atuais reais para
desenvolvimento de software → não em possíveis requisitos
futuros
 Procura-se evitar problemas de relacionamento entre a área
de negócios e a de desenvolvimento → ambas devem
cooperar para o sucesso e cada uma deve focar partes
específicas do projeto
 Área de negócios → escopo, composição das versões e as
datas de entrega
 Desenvolvedores → estimativas de prazo, processo de
desenvolvimento e cronograma detalhado
Ciência da Computação - FCG 25

26. Prática 2 – Entregas frequentes
 Construir software simples e atualizado à medida que
novos requisitos surgem
 Cada incremento deve ser o mais compacto possível
→ apenas os requisitos mais valiosos
 Incrementos devem ser entregues a cada mês ou no
máximo a cada dois meses → feedback mais rápido
do cliente
 Evita-se surpresas → grandes modificações
 Torna as avaliações mais precisas e aumenta a
chance da concordância do software com as
necessidades do cliente
Ciência da Computação - FCG 26

27. Prática 3 - Metáfora
Descrições de um software sem a utilização de
termos técnicos, com o intuito de guiar o seu
desenvolvimento
Ciência da Computação - FCG 27

28. Prática 4 – Projeto simples
 O software deve ser o mais simples possível e
satisfazer os requisitos atuais
 Possíveis requisitos futuros só são adicionados
ao projeto quando sua implementação é
realmente necessária → K.I.S.S.
 Oposto ao raciocínio ”implemente para hoje e
projete para amanhã”
Ciência da Computação - FCG 28

29. Prática 5 - Testes
 Foco na validação do projeto durante todo o
processo de desenvolvimento
 Os desenvolvedores implementam o software
cirando primeiramente os casos de testes →
TDD
Ciência da Computação - FCG 29

30. Prática 6 – Programação em pares
 Implementação de software feita em dupla → 2 devs
em um único computador
 Um dev implementa; o outro revisa continuamento o
trabalho feito → procura-se identificar erros sintáticos
e semânticos, além de planejar refatorações
 Estes dois papéis devem ser trocados continuamente
 Desenvolvedores aprendem juntos
 Maior possibilidade de corretude de código
 Possibilidade de revisões já na fase de
implementação
Ciência da Computação - FCG 30

31. Prática 7 - Refatoração
 Foco no aperfeiçoamento do projeto do
software
 Presente em todo o desenvolvimento
 Deve ser feita sempre que possível
 A idéia é simplificar código sem que haja perda
de funcionalidades
Ciência da Computação - FCG 31

32. Prática 8 – Propriedade coletiva
 O código é de todos os membros da equipe!
 Qualquem membro pode agregar valor ao código →
mesmo que não o tenha desenvolvido (desde que
realize os testes necessários)
 Todos são responsáveis pelo software inteiro!
 Caso um membro da equipe deixe o projeto
(momentânea ou definitivamente) antes de sua
conclusão, a equipe ainda é capaz de continuar o
projeto com poucas dificuldades
 Menor dependência de heróis individuais
Ciência da Computação - FCG 32

33. Prática 9 – Integração contínua
 O código (testado) produzido por uma equipe
deve ser integrado ao sistema, o qual também
deve ser testado
 O software é construído e verificado
continuamente
 Maior facilidade de isolar erros e suas causas
 Recomenda-se utilizar uma única máquina de
integração, o qual pode ser acessado
livremente por toda a equipe
Ciência da Computação - FCG 33

34. Prática 10 – Trabalho semanal de 40 horas
 Horas extras não devem se tornar um costume
 Caso seja necessário trabalhar mais de 40 horas pela
segunda semana consecutiva, existe um problema no
projeto!
 Tal problema não deve ser resolvido com mais horas
de trabalho → e sim com planejamento
 Focos na pessoas → não em processos e
planejamentos
 Alteração dos planos Vs. Sobrecarga de pessoal
Ciência da Computação - FCG 34

35. Prática 11 – Cliente presente
 O cliente DEVE participar durante todo o projeto
 O cliente DEVE estar sempre disponível para
sanar todas as dúvidas sobre requisitos
 Evita atrasos e implementações errôneas
 O cliente pode ser mantido como parte
integrande da equipe do desenvolvimento → ex.:
escrevendo história de usuário
 Pergunta: o que são histórias de usuário? (BDD)
Ciência da Computação - FCG 35

36. Prática 12 – Código padrão
 Regras de escrita → estilo, formato de
comentários, nomenclatura de variáveis, etc.
 Favorece o trabalho em equipe e a propriedade
coletiva do código
Ciência da Computação - FCG 36

37. Planejamento na XP
 O cliente participa ativamente no processo de
desenvolvimento → pode até fazer parte da
equipe de desenvolvimento
 Esclarecimento de dúvidas facilitado → uso de
histórias
 Cada tarefa/requisito é descrito como uma
história → possivelmente, pelo cliente
 As história são distribuídas aos
desenvolvedores, os quais se encarregam de
implementar as funcionalidades descritas
Ciência da Computação - FCG 37

38. Scrum
… na próxima aula! ;)
Ciência da Computação - FCG 38

39. Conclusões – Métodos ágeis
 Pesquisas mostram que projetos utilizando métodos
ágeis obtiveram melhores resultados em termos de
cumprimento de prazos, custos e padrões de
qualidade
 Cada vez mais projetos/equipes maiores tem utilizado
métodos ágeis
 Outras pesquisas mostraram que o uso adequado de
XP pode ajudar organizações alcançarem os níveis
CMM 2 e 3 → Boeing, por exemplo, alcançou o nível
CMM 5 sem muitas alterações após adotar o XP
Ciência da Computação - FCG 39

40. Conclusões – Vantagens da XP
 XP é ideal a projetos em que os stakeholders
não sabem exatamente o que desejam
 O feedback contínuo permite a rápida
adaptação do produto
 Entregas frequentes do software executável e
funcional → diminuir a ansiedade do cliente e
obter o seu feedback a respeito do trabalho
realizado
 Integração e testes contínuos → melhoria e
garantia de qualidade
Ciência da Computação - FCG 40

41. Conclusões – Algumas desvantagens da XP
 Muitos acreditam que seja a volta do processo caótico
de desenvolvimento de software → ”codifica-remenda”
 O uso errôneo da XP pode ”mascarar” práticas
positivas de desenvolvimento → ex., análise de
problemas utilizando diagramas
 Alguns clientes podem não gostar da informalidade no
levantamento de requisitos
 Além disso, alguns clientes podem enxergar a
refatoração como amadorismo ou mesmo
incompetência
Ciência da Computação - FCG 41

42. Bibliografia
KOSCIANSKI, A., SOARES, M. S. Qualidade de Software. Segunda edição.
Editora Novatec. São Paulo, 2006.
BROOKS, F. P. No Silver Bullet – Essence and Accident in Software
Engineering. Proceedings of IFIP Tenth World Computing Conference, H.-J.
Kugler, ed., Elsevier Science B. V., Amsterdam, NL (1986) pp. 1069-1076.
Ciência da Computação - FCG 42