modelos de processo de software e x treme p rogramming

Post on 15-Jan-2016

25 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

DESCRIPTION

Modelos de Processo de Software e X treme P rogramming. MO409 – Engenharia de Software Profa. Eliane Martins. André DrummondRA 992640 Danilo BenzattiRA 980942. Assuntos abordados. Introdução Visão Geral Regras e Práticas Planejando Projetando Codificando Testando Qualidade - PowerPoint PPT Presentation

TRANSCRIPT

Modelos de Processo de SoftwareeXtreme Programming

André Drummond RA 992640

Danilo Benzatti RA 980942

MO409 – Engenharia de Software

Profa. Eliane Martins

Assuntos abordados

IntroduçãoVisão GeralRegras e Práticas– Planejando– Projetando– Codificando– Testando

QualidadeConfiguração de SoftwareDificuldades na Vida RealConclusões

Introdução

Desenvolvida nos anos 1990 e primeiramente utilizada em março de 1996 por Kent Beck.Diretrizes– Simplicidade– Comunicação– Coragem– Feedback

Visão Geral

Clientes

Planode

Entregas

Planode

Iteração

DesenvolvimentoVersãoAtual

Testesde

Aceitação

Entregade

Versões

IteraçãoRequisitos

Requisitos

Novos Requisitos

Cenários de Teste

Velocidade

Bugs

Planejando

HistóriasPlano de EntregasPequenas VersõesVelocidade

Clientes

Planode

Entregas

Planode

I teração

DesenvolvimentoVersãoAtual

Testesde

Aceitação

Entregade

Versões

I teraçãoRequisitos

Requisitos

Novos Requisitos

Cenários de Teste

Velocidade

Bugs

Clientes

Planode

Entregas

Planode

I teração

DesenvolvimentoVersãoAtual

Testesde

Aceitação

Entregade

Versões

I teraçãoRequisitos

Requisitos

Novos Requisitos

Cenários de Teste

Velocidade

Bugs

Planejando (II)

IteraçõesPlano de IteraçãoMova as PessoasReuniões RápidasConserte o XP

Clientes

Planode

Entregas

Planode

I teração

DesenvolvimentoVersãoAtual

Testesde

Aceitação

Entregade

Versões

I teraçãoRequisitos

Requisitos

Novos Requisitos

Cenários de Teste

Velocidade

Bugs

Clientes

Planode

Entregas

Planode

I teração

DesenvolvimentoVersãoAtual

Testesde

Aceitação

Entregade

Versões

I teraçãoRequisitos

Requisitos

Novos Requisitos

Cenários de Teste

Velocidade

Bugs

Projetando

SimplicidadeMetáfora do SistemaCartões CRCSoluções RápidasReestruturação

Clientes

Planode

Entregas

Planode

I teração

DesenvolvimentoVersãoAtual

Testesde

Aceitação

Entregade

Versões

I teraçãoRequisitos

Requisitos

Novos Requisitos

Cenários de Teste

Velocidade

Bugs

Clientes

Planode

Entregas

Planode

I teração

DesenvolvimentoVersãoAtual

Testesde

Aceitação

Entregade

Versões

I teraçãoRequisitos

Requisitos

Novos Requisitos

Cenários de Teste

Velocidade

Bugs

Codificando

Disponibilidade do ClientePadrões de CodificaçãoPriorize o Teste UnitárioProgramação em ParesIntegração de CódigoPosse Coletiva do CódigoSem Horas Extras

Clientes

Planode

Entregas

Planode

I teração

DesenvolvimentoVersãoAtual

Testesde

Aceitação

Entregade

Versões

I teraçãoRequisitos

Requisitos

Novos Requisitos

Cenários de Teste

Velocidade

Bugs

Clientes

Planode

Entregas

Planode

I teração

DesenvolvimentoVersãoAtual

Testesde

Aceitação

Entregade

Versões

I teraçãoRequisitos

Requisitos

Novos Requisitos

Cenários de Teste

Velocidade

Bugs

Testando

Teste UnitárioBugsTestes de AceitaçãoClientes

Planode

Entregas

Planode

I teração

DesenvolvimentoVersãoAtual

Testesde

Aceitação

Entregade

Versões

I teraçãoRequisitos

Requisitos

Novos Requisitos

Cenários de Teste

Velocidade

Bugs

Clientes

Planode

Entregas

Planode

I teração

DesenvolvimentoVersãoAtual

Testesde

Aceitação

Entregade

Versões

I teraçãoRequisitos

Requisitos

Novos Requisitos

Cenários de Teste

Velocidade

Bugs

Qualidade

Mova as PessoasSimplicidadeCartões CRCReestruturaçãoCódigo PadronizadoProgramação em Pares [Willians, 2001]

XP vs CMM [Paulk, 2001]

Configuração de Software [Asklund, 2004]

Aspectos Positivos:– Reuniões Rápidas– Plano de Entregas– Teste Unitário– Testes de Aceitação

Aspectos Negativos– Posse Coletiva do Código– Pequenas Entregas

Dificuldades na Vida Real

Equipes com mais de 20 programadores [Crocker, 2001]

Comprometimento com código existente para manter aplicações existentes;Longos períodos requeridos para feedback;Distribuição geográfica de programadores;Sistemas de grande porte.

Conclusões

XP não tenta prever o futuroEquipes Pequenas, Requerimentos Vagos, Freqüente Mudanças de EscopoOrganiza o processo de desenvolvimento sem criar burocracias rígidas Não use Extreme Programming se...– Você já utiliza um processo e os desenvolvedores

e clientes estão satisfeitos;– Seus requisitos são realmente fixos;

Referências

http://www.extremeprogramming.org/http://www.xispe.com.br/[Willians, 2001] Laurie Williams , Richard L. Upchurch, In support of student pair-programming, Proceedings of the thirty-second SIGCSE[Paulk, 2001] Mark C. Paulk, Extreme Programming from a CMM Perspective, IEEE Software, November/December 2001[Asklund, 2004] Ulf Asklund, Lars Bendix, Torbjörn Ekman, Software Configuration Management Practices for eXtreme Programming Teams, Lund Institute of Technology[Crocker, 2001] Ron Crocker. The 5 reasons XP can't scale and what to do about them, Motorola, Inc.

Backup

Backup (II)

Backup (III)

Backup (IV)

Backup (V)

top related