1 / 16

Modelos de processo de software:

Modelos de processo de software:. e X treme P rogramming. A rthur B ispo de C astro ra992659 L uciano A ntonio D igiampietri ra992075. Tópicos abordados:. Porque surgiu o XP Princípios, regras e diretrizes para o desenvolvimento Ciclo das atividades Qualidade

brede
Download Presentation

Modelos de processo de software:

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Modelos de processo de software: eXtreme Programming Arthur Bispo de Castro ra992659 Luciano Antonio Digiampietri ra992075

  2. Tópicos abordados: • Porque surgiu o XP • Princípios, regras e diretrizes para o desenvolvimento • Ciclo das atividades • Qualidade • Estratégias de testes • Diretrizes para o gerenciamento do projeto • Conclusão

  3. Porque surgiu o XP? • Atrasos na programação; • Cancelamento de projeto; • Sistema demora muito para fazer algo; • Taxa de falhas é muito grande; • Software não atende aos requisitos; • Mudanças de requisitos; • Mudança na equipe de funcionários.

  4. Princípios, regras e diretrizes para o desenvolvimento (I) • O Jogo do planejamento • Pequenas liberações • Metáfora • Projeto simplificado • Teste • Re-fatoração

  5. Princípios, regras e diretrizes para o desenvolvimento (II) • Programação em pares • Posse coletiva • Integração contínua • 40 horas por semana • Cliente no local (feedback rápido) • Padronização do código

  6. Ciclo das atividades (I) • Fase de Exploração • duração: 2 a 6 meses. • clientes escrevem “historias” (story cards). • programadores interagem com clientes e discutem o problem, soluções e tecnologias. • Planejamento: 1 a 2 dias.

  7. Ciclo das atividades (II) • Escolha de uma história do cliente; • Pair programming para aquela história; • Discução da história do cliente; • Elaboração de testes; • Implementação; • Execução dos testes;

  8. Ciclo das atividades (III) • Busca de oportunidades para simplificação; • Modificações do projeto e implementação baseadas na funcionalidade exigida no momento; • Elaboração e execução de novos testes; • Correção do código até que todos os testes passem; • Integração do novo código ao repositório e liberação ao cliente.

  9. Qualidade (I) • Um processo de desenvolvimento é essencial • No modelo tradicional: • Tempo, escopo e custo • Manipula-se a Qualidade • No modelo XP • Tempo, custo e qualidade • Manipula-se o Escopo • Comunicação, simplicidade, feedback e coragem

  10. Qualidade (II) • Força o (mau) programador a se comportar de forma similar ao bom programador • Simplicidade é o melhor negócio • Cartões de CRC (Classe, Responsabilidade e Colaboração) • Refatoração para melhorar a manutenibilidade

  11. Estratégias de testes (I) • Determina as funcionalidades • Falsos negativos • Automático • Criado por Programadores e Clientes • Outros testes • Paralelos • Stress • Monkey

  12. Estratégias de testes (II) • Testes de unidade • Escrito pelo desenvolvedor, antes do código • Código deve passar no teste antes da integração • Testes de aceitação • Escrito pelo cliente, pelas suas necessidades • Executado com freqüência

  13. Diretrizes para o gerenciamento do projeto (I) • Responsabilidade • Qualidade • Mudança incremental • Adaptação • Travel light • Honestidade • Metrica • Intervenção

  14. Diretrizes para o gerenciamento do projeto (II) • Planejamento • História do cliente e cronograma • Design • Simplicidade, cartões CRC e refatoração • Teste • Unidade e aceitação • Codificação • Duplas, cliente disponível e sem sobrecarga.

  15. Conclusão • XP não é para todo mundo • Mas todo mundo pode aprender com ela

  16. Bibliografia • Beck, Kent. Extreme programming explained: embrace change. 2000. Addison-Wesley. • http://www.xispe.com.br • http://www.xp2003.org • http://www.extremeprogramming.org • Santos, Jefferson. Extraindo o Melhor de XP, Agile Modeling e RUP para melhor produzir software. PUC-Rio. • Bonato, Antonio. Extreme Programming e Software de Qualidade. 2002. Politécnica-USP. • Kon, Fabio. Goldman, Alfredo. Programação eXtrema - Desenvolvendo Software com Qualidade e Agilidade. 2002. IME-USP.

More Related