O documento discute métodos de desenvolvimento de software rápido, como desenvolvimento incremental, prototipagem e métodos ágeis. Apresenta o Extreme Programming (XP) como um método ágil popular, destacando suas práticas como testes, programação em pares e entregas frequentes.

1. Engenharia do Software I Manuel Menezes de Sequeira DCTI, ISCTE-IUL Manuel.Sequeira@iscte.pt, D6.02 As apresentações desta série baseiam-se nas apresentações disponibilizadas por IanSommerville, tendo sido alteradas e adaptadas primeiro por Anders Lyhne Christensen e finalmente por Manuel Menezes de Sequeira.

2. Na aula anterior Processos de software Modelos de processos de software Iteração de processos Actividades de processo RUP (RationalUnifiedProcess) CASE (Computer-Aided Software Engineering) 2009/2010 2 Engenharia do Software I

3. Desenvolvimento Rápido de Software 2009/2010 3 Engenharia do Software I

4. Sumário Desenvolvimento rápido de software Métodos ágeis XP (Extreme Programming) Desenvolvimento rápido de aplicações (RAD) Prototipagem de software 2009/2010 Engenharia do Software I 4

5. Objectivos Explicar como processo de desenvolvimento iterativo e incremental leva a entregas mais rápidas do software e a software mais útil Discutir essência de métodos ágeis de desenvolvimento Explicar princípios e práticas do Extreme Programming Explicar papéis da prototipagem no processo de software 2009/2010 5 Engenharia do Software I

6. Desenvolvimento rápido de software Alterações rápidas do contexto dos negócios obrigam empresas a responder a novas oportunidades e à competição Necessário software e seu rápido desenvolvimento Empresas podem estar dispostas a aceitar software de menor qualidade se isso tornar possível a entrega rápida de funcionalidades essenciais 2009/2010 6 Engenharia do Software I

7. Requisitos Contexto em alteração impossibilita conjunto estável e consistente de requisitos de sistema Modelo de desenvolvimento em cascata impraticável Entrega rápida de software possível apenas com desenvolvimento baseado em especificação e entrega iterativas 2009/2010 7 Engenharia do Software I

8. Características de processos RAD Especificação, desenho e implementação são processos concorrentes Sem especificação pormenorizada Documentação mínima 2009/2010 8 Engenharia do Software I

9. Características de processos RAD Sistema desenvolvido numa série de incrementos Utilizadores finais avaliam cada incremento e fazem propostas para incrementos posteriores Interfaces de utilização usualmente desenvolvidas usando sistema de desenvolvimento iterativo 2009/2010 9 Engenharia do Software I

10. Um processo de desenvolvimento iterativo Definir entregáveis Desenhar arquitectura Especificar incremento Construir incremento Validar incremento não Completo? Integrar incremento Validar Entregar sistema final sim 2009/2010 10 Engenharia do Software I

11. Vantagens do desenvolvimento incremental 2009/2010 11 Engenharia do Software I

12. Problemas do desenvolvimento incremental 2009/2010 12 Engenharia do Software I

13. Prototipagem 2009/2010 13 Engenharia do Software I

14. Desenvolvimento incremental e prototipagem Sistema entregue Desenvolvimento incremental Visão geral dos requisitos Protótipo executável e especificação do sistema Prototipagem descartável 2009/2010 14 Engenharia do Software I

15. Diferentes objectivos 2009/2010 15 Engenharia do Software I

16. Métodos ágeis Insatisfação com custos fixos associados a métodos de desenho levou a métodos ágeis Foco no código e não no desenho Com abordagem iterativa ao desenvolvimento Com objectivo de entregar e fazer evoluir rapidamente o software Provavelmente melhor adequados a sistemas empresariais de pequena e média dimensão ou a produtos para computador pessoal 2009/2010 Engenharia do Software I 16

17. Princípios dos métodos ágeis 2009/2010 Engenharia do Software I 17

18. Problemas dos métodos ágeis Pode ser difícil manter interesse dos clientes envolvidos Membros da equipa podem não ser adequados a envolvimento intenso de métodos ágeis Prioritização de mudanças pode ser difícil com múltiplas partes interessadas Manter simplicidade requer trabalho adicional Contratos podem ser problemáticos, tal como noutras abordagens a desenvolvimento iterativo 2009/2010 Engenharia do Software I 18

19. XP (Extreme Programming) Método ágil mais conhecido e usado? Abordagem “extrema” a desenvolvimento iterativo Novas versões podem ser construídas múltiplas vezes por dia Entrega de incrementos a clientes cada duas semanas Todos os testes executados em todas as construções; construções aceites se testes executarem com sucesso 2009/2010 Engenharia do Software I 19

20. Ciclo de entregas do XP 2009/2010 20 Engenharia do Software I Seleccionar estórias do utilizador para esta entrega Dividir estórias em tarefas Planear entrega Entregar sistema Avaliar sistema Desenvolver, integrar e testar software

21. Práticas do XP 2009/2010 Engenharia do Software I 21

22. Práticas do XP 2009/2010 Engenharia do Software I 22

23. Princípios XP e ágeis Entregas pequenas e frequentes suportam desenvolvimento incremental Cliente a tempo inteiro com equipa Ênfase em pessoas e não processos Programação em pares Propriedade colectiva Processo que evita tempo excessivo de trabalho Entregas regulares suportam mudança Refactorização contínua sustenta simplicidade 2009/2010 Engenharia do Software I 23

24. Cenários de requisitos em XP Requisitos do utilizador expressos como cenários ou estórias de utilizador Estórias escritas em cartões e divididas em tarefas de implementação por equipa de desenvolvimento Estórias usadas para estimar custos e esforço Cliente escolhe estórias para entrega seguinte de acordo com prioridades e esforços estimados 2009/2010 Engenharia do Software I 24

25. Cartão de estória para descarregamento de documento 2009/2010 Engenharia do Software I 25

26. XP e mudança “Desenhar para a mudança” é senso comum: investir tempo e esforço antecipando alterações é proveitoso, pois reduzirá custos futuros no ciclo de vida do sistema XP acha que não vale a pena: alterações não são antecipáveis com confiança XP propõe melhoria contínua do código (refactorização): alterações mais fáceis quando implementadas 2009/2010 Engenharia do Software I 26

27. Testes em XP Desenvolvimento com testes primeiro Desenvolvimento incremental de testes partindo de cenários Envolvimento do utilizador no desenvolvimento e validação de testes Sistemas de teste automático para executar todos testes de componentes sempre que nova entrega é construída 2009/2010 Engenharia do Software I 27

28. Cartões de tarefa para descarregamento de documento 2009/2010 Engenharia do Software I 28

29. Descrição de caso de teste 2009/2010 Engenharia do Software I 29 Hmmmm….

30. Desenvolvimento com testes primeiro Escrever testes antes do código clarifica os requisitos a implementar Testes escritos de forma a se poderem executar automaticamente e não na forma de dados Testes reportam seu resultado Testes passados e novos testes executados quando se adiciona nova funcionalidade, verificando-se se se introduziu algum erro 2009/2010 Engenharia do Software I 30

31. Programação em pares Programadores aos pares, sentando-se juntos durante desenvolvimento Favorece sentimento de posse comum do código e dissemina conhecimento Processo de revisão informal: código visto por mais que uma pessoa Encoraja refactorização: equipa toda beneficia Experiências sugerem que produtividade de desenvolvimento é semelhante a trabalho individual 2009/2010 Engenharia do Software I 31

32. Desenvolvimento rápido de aplicações Métodos ágeis têm recebido muita atenção, mas há outras abordagens ao RAD em uso há muitos anos Essas abordagens foram desenhadas para desenvolver aplicações empresariais data-intensive Baseiam-se em programação e apresentação de informação a partir de uma base de dados 2009/2010 Engenharia do Software I 32

33. Ferramentas RAD Linguagens de programação de bases de dados Geradores de interfaces Ligações a aplicações de escritório Geradores de relatórios 2009/2010 Engenharia do Software I 33

34. Prototipagem de software Protótipo: versão inicial do sistema para demonstrar conceitos e experimentar opções de desenho Pode usar-se Processo de engenharia de requisitos: ajuda eliciação e validação de requisitos Processos de desenho: ajuda explorar opções e desenvolver design da interface com utilizador Processo de testes: executar testes comparativos (back-to-back) 2009/2010 34 Engenharia do Software I

35. Benefícios da prototipagem Melhor usabilidade do sistema Melhor correspondência com necessidades reais dos utilizadores Melhor qualidade do desenho Melhor manutenibilidade Menor esforço de desenvolvimento 2009/2010 35 Engenharia do Software I

36. Testes comparativos Dados de teste Protótipo do sistema Sistema Relatório das diferenças 2009/2010 36 Engenharia do Software I Comparador de resultados

37. Processo de prototipagem 2009/2010 37 Engenharia do Software I Estabelecer objectivos Definir funcionalidade Desenvolver Avaliar Plano de prototipagem Definição da estrutura geral Protótipo executável Relatório de avaliação

38. Protótipos descartáveis Protótipos descartados depois de desenvolvidos: não são boa base para sistema de produção Pode ser impossível ajustar sistema para cumprir requisitos não funcionais Protótipos normalmente não documentados Estrutura de protótipos usualmente degradada devido a alterações rápidas Protótipo provavelmente não cumpre normas de qualidade da organização 2009/2010 Engenharia do Software I 38

39. A reter Abordagem iterativa a desenvolvimento de software leva a entregas mais rápidas Métodos ágeis são métodos de desenvolvimento iterativo destinados a reduzir custos fixos de desenvolvimento e assim a produzir software mais rapidamente XP inclui práticas como testes sistemáticos, melhoria contínua e envolvimento do cliente A abordagem aos testes no XP é uma das suas forças; testes executáveis desenvolvidos antes da escrita do código 2009/2010 Engenharia do Software I 39

40. A reter Protótipos descartáveis usados para explorar requisitos e opções de desenho Ao implementar protótipo descartável, começar com requisitos menos compreendidos No desenvolvimento incremental, começar com requisitos mais compreendidos 2009/2010 Engenharia do Software I 40

41. A ler IanSommerville, Software Engineering, 8.ª edição, Addison-Wesley, 2006 Capítulo 17 2009/2010 41 Engenharia do Software I