• Like
Métodos Ágeis
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Métodos Ágeis

  • 605 views
Published

Oitava aula da disciplina Qualidade de Software por mim ministrada, a qual aborda métodos ágeis de desenvolvimento de software.

Oitava aula da disciplina Qualidade de Software por mim ministrada, a qual aborda métodos ágeis de desenvolvimento de software.

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
605
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
19
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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 emprojetos 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áforaDescriçõ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. BibliografiaKOSCIANSKI, 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 SoftwareEngineering. 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