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
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
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
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
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