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

Métodos Ágeis

on

  • 812 views

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.

Statistics

Views

Total Views
812
Slideshare-icon Views on SlideShare
812
Embed Views
0

Actions

Likes
0
Downloads
15
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Métodos Ágeis Métodos Ágeis Presentation Transcript

    • 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
    • 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
    • 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
    • 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
    • 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
    • Modelo Cascata Ciência da Computação - FCG 6
    • 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
    • Modelo Cascata Assim, o modelo cascata é recomendável emprojetos com requisitos estáveis → Isto existe? Ciência da Computação - FCG 8
    • Custo de modificação no Modelo Cascata Ciência da Computação - FCG 9
    • 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
    • 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
    • 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
    • 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
    • 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
    • Métodos ágeis Ciência da Computação - FCG 15
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • Scrum… na próxima aula! ;) Ciência da Computação - FCG 38
    • 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
    • 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
    • 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
    • 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