Desenvolvimento rpido de aplicaes

MTODOS GEIS

Com metodologias de desenvolvimento

Supem que possvel prever o futuro Pouca interao com os clientes nfase em burocracias (documentos, formulrios, processos, controles rgidos, etc.) Avaliao do progresso baseado na evoluo da burocracia e no do cdigo

Com software
Grande quantidade de erros Falta de flexibilidade

Melhores Tecnologias
Padres de Projeto (reutilizao de idias) Componentes (reutilizao de cdigo) Middleware (aumenta a abstrao)

Melhores Metodologias
Mtodos geis outras... (RUP, relacionadas a CMM, etc.)

Movimento iniciado por programadores experientes e consultores em desenvolvimento de software. Questionam e se ope a uma srie de mitos/prticas adotadas em abordagens tradicionais de Engenharia de Software e Gerncia de Projetos. Manifesto gil:
Assinado por 17 desenvolvedores em Utah em fevereiro/2001.

1.

2.

3.

4.

Indivduos e interaes so mais importantes que processos e ferramentas. Software funcionando mais importante do que documentao completa e detalhada. Colaborao com o cliente mais importante do que negociao de contratos. Adaptao a mudanas mais importante do que seguir o plano inicial.

Objetivo: satisfazer o cliente entregando, rapidamente e com freqncia, sistemas com algum valor.
Entregar verses funcionais em prazos curtos. Estar preparado para requisitos mutantes. Pessoal de negcios e desenvolvedores juntos. Troca de informaes atravs de conversas diretas.

Outros mtodos geis interessantes:

Programao eXtrema (XP) Scrum Crystal (uma famlia de mtodos) Adaptive Software Development Feature Driven Development

Coloca o foco
Na entrega freqente de sub-verses do software [funcionando] para o cliente. Nos seres humanos que desenvolvem o software.

Retira o foco de
Processos rgidos e burocratizados. Documentaes e contratos detalhados. Ferramentas que so usadas pelos seres humanos.

0. Levantamento de Requisitos 1. Anlise de Requisitos 2. Desenho da Arquitetura 3. Implementao 4. Testes 5. Produo / Manuteno

necessrio fazer uma anlise de requisitos profunda e detalhada antes de projetar a arquitetura do sistema. necessrio fazer um estudo minucioso e elaborar uma descrio detalhada da arquitetura antes de comear a implement-la. necessrio testar o sistema completamente antes de mandar a verso final para o cliente.

` `

Orientao a Objetos: facilita e cria oportunidades para mudanas. Tcnicas de Refatorao. Testes automatizados: nos do segurana quando fazemos mudanas. Prtica / cultura de mudanas: aprendemos tcnicas e adquirimos experincia em lidar com cdigo mutante.

A atitude dos desenvolvedores de software seria completamente diferente:

Tomaramos as grandes decises o mais tarde possvel. Implementaramos agora somente o que precisamos agora. No implementaramos flexibilidade desnecessria (no anteciparamos necessidades).

Uma metodologia de desenvolvimento de software, nascida nos Estados Unidos ao final da dcada de 90. Faz sucesso em diversos pases, por ajudar a criar sistemas de melhor qualidade, que so produzidos em menos tempo e de forma mais econmica que o habitual.

um modelo de processo de desenvolvimento de software:

iterativo e incremental que enfatiza um ciclo de desenvolvimento extremamente curto (entre 60 e 90 dias).

Este mtodo funciona com a participao direta com o cliente. A equipe responsvel est sempre mostrando pequenos resultados e fazendo feedback para que no seja desperdiados tempo e dinheiro.

Estas alteraes nos requisitos so muitas vezes crticas nas metodologias tradicionais, Um outro ponto positivo das metodologias geis so as entregas constantes de partes operacionais do software.

Uma equipe pequena ou mdia (menos de 20 pessoas em toda a equipe) Co-localizada, de preferncia em uma nica rea com um grande espao comum Um cliente ou seu representante, empenhado em tempo integral no mesmo local

Uma equipe pequena ou mdia (menos de 20 pessoas em toda a equipe) Co-localizada, de preferncia em uma nica rea com um grande espao comum Um cliente ou seu representante, empenhado em tempo integral no mesmo local

` ` ` `

Feedback rpido Simplicidade o melhor negcio Mudanas incrementais Carregue a bandeira das mudanas / no valorize o medo (Embrace change) Alta qualidade do cdigo

 Tempo Custo Qualidade Escopo (foco principal de XP)

Fase de Explorao
durao: 2 a 6 meses. termina quando a primeira verso do software enviada ao cliente. clientes escrevem historias (story cards). programadores interagem com clientes e discutem tecnologias. No s discutem, experimentam diferentes tecnologias e arquiteturas para o sistema. Planejamento: 1 a 2 dias.

` ` ` `

Escolhe uma histria do cliente. Procura um par livre. Escolhe um computador para programao pareada. Seleciona um carto de histria contendo uma tarefa claramente relacionada a uma caracterstica (feature) desejada pelo cliente.

` ` ` ` ` `

Discute modificaes recentes no sistema Discute histria do cliente Testes Implementao Projeto (design) Integrao

1. 2. 3. 4. 5. 6. 7.

Planejamento Fases Pequenas Metfora Design Simples Testes Refatorao Programao Pareada

8. Propriedade Coletiva 9. Integrao Contnua 10. Semana de 40 horas 11. Cliente junto aos desenvolvedores 12. Padronizao do cdigo

` ` `

Fundamento mais importante de XP. o que d segurana e coragem ao grupo. Testes de unidades (Unit tests)
escritos pelos programadores para testar cada elemento do sistema (e.g., cada mtodo em cada caso).

Testes de funcionalidades (Functional tests)

escritos pelos clientes para testar a funcionalidade do sistema.

Testes das unidades do sistema

Tem que estar sempre funcionando a 100%. So executados vrias vezes por dia. Executados noite automaticamente.

Testes das funcionalidades

Vo crescendo de 0% a 100%. Quando chegam a 100% acabou o projeto.

` `

Erro de um detectado imediatamente pelo outro (grande economia de tempo). Maior diversidade de idias, tcnicas, algoritmos. Enquanto um escreve, o outro pensa em contraexemplos, problemas de eficincia, etc. Vergonha de escrever cdigo feio (gambiarras) na frente do seu par. Pareamento de acordo com especialidades.
Ex.: Sistema Multimdia Orientado a Objetos

` `

Modelo tradicional: s autor de uma funo pode modific-la. XP: o cdigo pertence a todos. Se algum identifica uma oportunidade para simplificar, consertar ou melhorar cdigo escrito por outra pessoa, que o faa. Mas rode os testes!

Uma [pequena] modificao no sistema que no altera o seu comportamento funcional mas que melhora alguma qualidade nofuncional:
simplicidade flexibilidade clareza desempenho

` ` ` ` `

Mudana do nome de variveis Mudanas nas interfaces dos objetos Pequenas mudanas arquiteturais Encapsular cdigo repetido em um novo mtodo Generalizao de mtodos
raizQuadrada(float x) raiz(float x, int n)

` ` ` ` ` `

Responsvel por escrever histrias. Muitas vezes um programador ou representado por um programador do grupo. Trabalha no mesmo espao fsico do grupo. Novas verses so enviadas para produo todo ms (ou toda semana). Feedback do cliente essencial. Requisitos mudam (e isso no mau).

` ` ` ` `

Em geral, o mais experiente do grupo. Identifica quem bom no que. Lembra a todos as regras do jogo (XP). Eventualmente faz programao pareada. No desenha arquitetura, apenas chama a ateno para oportunidades de melhorias. Seu papel diminui medida em que o time fica mais maduro.

` `

A conscincia do time. Coleta estatsticas sobre o andamento do projeto. Alguns exemplos:

Nmero de histrias definidas e implementadas. Nmero de unit tests. Nmero de testes funcionais definidos e funcionando. Nmero de classes, mtodos, linhas de cdigo

` `

Mantm histrico do progresso. Faz estimativas para o futuro.

VANTAGENS
`

` `

Todos do time devem estar cientes de cada fase do sistema. Um dos benefcios tornar o processo mais gil e flexvel. Anlise prvia de tudo que pode acontecer durante o desenvolvimento do projeto, O XP ideal para ser usada em projetos em que o cliente no sabe exatamente o que deseja e pode mudar muito de opinio durante o desenvolvimento do projeto.

VANTAGENS
`

Estas alteraes nos requisitos so muitas vezes crticas nas metodologias tradicionais, Um outro ponto positivo das metodologias geis so as entregas constantes de partes operacionais do software.

DESVANTAGENS
` `

No existe uma avaliao de riscos A anlise de requisitos informal e com isso pode no ser bem vista pelos clientes. Refatorao do cdigo pode ser vista como irresponsabilidade e incompetncia.

DESVANTAGENS
`

A falta de documentao caracterstica do processo XP, no h nfase em burocracias (documentos, formulrios, processos, controles rgidos, etc.). Sendo, portanto, importante a elaborao de documentos e diagramas A maior barreira para o sucesso de um projeto XP a cultura empresarial.

Compare a Metodologia proposta no RUP com a metodologia XP

Utilizamos RUP quando:

Projeto grande, ou seja, mais riscos Existem muitos programadores + 100 Necessitamos de mais controle

Receita de bolo para o XP:

Projeto pequeno, ou seja, menos riscos Existem poucos programadores - 10 Necessitamos de menos controle e + agilidade